All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	linux-bluetooth@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-gpio@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	nouveau@lists.freedesktop.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
	linux-i3c@lists.infradead.org, linux-iio@vger.kernel.org,
	linux-input@vger.kernel.org, patches@opensource.cirrus.com,
	iommu@lists.linux.dev, imx@lists.linux.dev,
	linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
	linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org,
	netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-phy@lists.infradead.org,
	linux-pwm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	linux-sound@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-staging@lists.linux.dev, linux-usb@vger.kernel.org,
	linux-serial@vger.kernel.org, greybus-dev@lists.linaro.org,
	asahi@lists.linux.dev, rafael@kernel.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: [PATCH 00/51] treewide: Switch to __pm_runtime_put_autosuspend()
Date: Tue, 8 Oct 2024 01:25:02 +0300	[thread overview]
Message-ID: <20241007222502.GG30699@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAPDyKFpQVnF7eQv3dup8k-3EijnMjuveCG9sZ=Rpey1Y6MBJEg@mail.gmail.com>

Hi Ulf,

On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote:
> On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote:
> > On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote:
> > > On Fri, 4 Oct 2024 at 11:41, Sakari Ailus wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > This set will switch the users of pm_runtime_put_autosuspend() to
> > > > __pm_runtime_put_autosuspend() while the former will soon be re-purposed
> > > > to include a call to pm_runtime_mark_last_busy(). The two are almost
> > > > always used together, apart from bugs which are likely common. Going
> > > > forward, most new users should be using pm_runtime_put_autosuspend().
> > > >
> > > > Once this conversion is done and pm_runtime_put_autosuspend() re-purposed,
> > > > I'll post another set to merge the calls to __pm_runtime_put_autosuspend()
> > > > and pm_runtime_mark_last_busy().
> > >
> > > That sounds like it could cause a lot of churns.
> > >
> > > Why not add a new helper function that does the
> > > pm_runtime_put_autosuspend() and the pm_runtime_mark_last_busy()
> > > things? Then we can start moving users over to this new interface,
> > > rather than having this intermediate step?
> >
> > I think the API would be nicer if we used the shortest and simplest
> > function names for the most common use cases. Following
> > pm_runtime_put_autosuspend() with pm_runtime_mark_last_busy() is that
> > most common use case. That's why I like Sakari's approach of repurposing
> > pm_runtime_put_autosuspend(), and introducing
> > __pm_runtime_put_autosuspend() for the odd cases where
> > pm_runtime_mark_last_busy() shouldn't be called.
> 
> Okay, so the reason for this approach is because we couldn't find a
> short and descriptive name that could be used in favor of
> pm_runtime_put_autosuspend(). Let me throw some ideas at it and maybe
> you like it - or not. :-)

I like the idea at least :-)

> I don't know what options you guys discussed, but to me the entire
> "autosuspend"-suffix isn't really that necessary in my opinion. There
> are more ways than calling pm_runtime_put_autosuspend() that triggers
> us to use the RPM_AUTO flag for rpm_suspend(). For example, just
> calling pm_runtime_put() has the similar effect.

To be honest, I'm lost there. pm_runtime_put() calls
__pm_runtime_idle(RPM_GET_PUT | RPM_ASYNC), while
pm_runtime_put_autosuspend() calls __pm_runtime_suspend(RPM_GET_PUT |
RPM_ASYNC | RPM_AUTO).

> 
> Moreover, it's similar for pm_runtime_mark_last_busy(), it's called
> during rpm_resume() too, for example. So why bother about having
> "mark_last_busy" in the new name too.
> 
> That said, my suggestion is simply "pm_runtime_put_suspend".

Can we do even better, and make pm_runtime_put() to handle autosuspend
automatically when autosuspend is enabled ?

> If you don't like it, I will certainly not object to your current
> approach, even if I think it leads to unnecessary churns.
> 
> [...]
> 
> Kind regards
> Uffe

-- 
Regards,

Laurent Pinchart

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	linux-bluetooth@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-gpio@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	nouveau@lists.freedesktop.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
	linux-i3c@lists.infradead.org, linux-iio@vger.kernel.org,
	linux-input@vger.kernel.org, patches@opensource.cirrus.com,
	iommu@lists.linux.dev, imx@lists.linux.dev,
	linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
	linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org,
	netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-phy@lists.infradead.org,
	linux-pwm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	linux-sound@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-staging@lists.linux.dev, linux-usb@vger.kernel.org,
	linux-serial@vger.kernel.org, greybus-dev@lists.linaro.org,
	asahi@lists.linux.dev, rafael@kernel.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: [PATCH 00/51] treewide: Switch to __pm_runtime_put_autosuspend()
Date: Tue, 8 Oct 2024 01:25:02 +0300	[thread overview]
Message-ID: <20241007222502.GG30699@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAPDyKFpQVnF7eQv3dup8k-3EijnMjuveCG9sZ=Rpey1Y6MBJEg@mail.gmail.com>

Hi Ulf,

On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote:
> On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote:
> > On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote:
> > > On Fri, 4 Oct 2024 at 11:41, Sakari Ailus wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > This set will switch the users of pm_runtime_put_autosuspend() to
> > > > __pm_runtime_put_autosuspend() while the former will soon be re-purposed
> > > > to include a call to pm_runtime_mark_last_busy(). The two are almost
> > > > always used together, apart from bugs which are likely common. Going
> > > > forward, most new users should be using pm_runtime_put_autosuspend().
> > > >
> > > > Once this conversion is done and pm_runtime_put_autosuspend() re-purposed,
> > > > I'll post another set to merge the calls to __pm_runtime_put_autosuspend()
> > > > and pm_runtime_mark_last_busy().
> > >
> > > That sounds like it could cause a lot of churns.
> > >
> > > Why not add a new helper function that does the
> > > pm_runtime_put_autosuspend() and the pm_runtime_mark_last_busy()
> > > things? Then we can start moving users over to this new interface,
> > > rather than having this intermediate step?
> >
> > I think the API would be nicer if we used the shortest and simplest
> > function names for the most common use cases. Following
> > pm_runtime_put_autosuspend() with pm_runtime_mark_last_busy() is that
> > most common use case. That's why I like Sakari's approach of repurposing
> > pm_runtime_put_autosuspend(), and introducing
> > __pm_runtime_put_autosuspend() for the odd cases where
> > pm_runtime_mark_last_busy() shouldn't be called.
> 
> Okay, so the reason for this approach is because we couldn't find a
> short and descriptive name that could be used in favor of
> pm_runtime_put_autosuspend(). Let me throw some ideas at it and maybe
> you like it - or not. :-)

I like the idea at least :-)

> I don't know what options you guys discussed, but to me the entire
> "autosuspend"-suffix isn't really that necessary in my opinion. There
> are more ways than calling pm_runtime_put_autosuspend() that triggers
> us to use the RPM_AUTO flag for rpm_suspend(). For example, just
> calling pm_runtime_put() has the similar effect.

To be honest, I'm lost there. pm_runtime_put() calls
__pm_runtime_idle(RPM_GET_PUT | RPM_ASYNC), while
pm_runtime_put_autosuspend() calls __pm_runtime_suspend(RPM_GET_PUT |
RPM_ASYNC | RPM_AUTO).

> 
> Moreover, it's similar for pm_runtime_mark_last_busy(), it's called
> during rpm_resume() too, for example. So why bother about having
> "mark_last_busy" in the new name too.
> 
> That said, my suggestion is simply "pm_runtime_put_suspend".

Can we do even better, and make pm_runtime_put() to handle autosuspend
automatically when autosuspend is enabled ?

> If you don't like it, I will certainly not object to your current
> approach, even if I think it leads to unnecessary churns.
> 
> [...]
> 
> Kind regards
> Uffe

-- 
Regards,

Laurent Pinchart

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	linux-bluetooth@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-gpio@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	nouveau@lists.freedesktop.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
	linux-i3c@lists.infradead.org, linux-iio@vger.kernel.org,
	linux-input@vger.kernel.org, patches@opensource.cirrus.com,
	iommu@lists.linux.dev, imx@lists.linux.dev,
	linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
	linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org,
	netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-phy@lists.infradead.org,
	linux-pwm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	linux-sound@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-staging@lists.linux.dev, linux-usb@vger.kernel.org,
	linux-serial@vger.kernel.org, greybus-dev@lists.linaro.org,
	asahi@lists.linux.dev, rafael@kernel.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: [PATCH 00/51] treewide: Switch to __pm_runtime_put_autosuspend()
Date: Tue, 8 Oct 2024 01:25:02 +0300	[thread overview]
Message-ID: <20241007222502.GG30699@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAPDyKFpQVnF7eQv3dup8k-3EijnMjuveCG9sZ=Rpey1Y6MBJEg@mail.gmail.com>

Hi Ulf,

On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote:
> On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote:
> > On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote:
> > > On Fri, 4 Oct 2024 at 11:41, Sakari Ailus wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > This set will switch the users of pm_runtime_put_autosuspend() to
> > > > __pm_runtime_put_autosuspend() while the former will soon be re-purposed
> > > > to include a call to pm_runtime_mark_last_busy(). The two are almost
> > > > always used together, apart from bugs which are likely common. Going
> > > > forward, most new users should be using pm_runtime_put_autosuspend().
> > > >
> > > > Once this conversion is done and pm_runtime_put_autosuspend() re-purposed,
> > > > I'll post another set to merge the calls to __pm_runtime_put_autosuspend()
> > > > and pm_runtime_mark_last_busy().
> > >
> > > That sounds like it could cause a lot of churns.
> > >
> > > Why not add a new helper function that does the
> > > pm_runtime_put_autosuspend() and the pm_runtime_mark_last_busy()
> > > things? Then we can start moving users over to this new interface,
> > > rather than having this intermediate step?
> >
> > I think the API would be nicer if we used the shortest and simplest
> > function names for the most common use cases. Following
> > pm_runtime_put_autosuspend() with pm_runtime_mark_last_busy() is that
> > most common use case. That's why I like Sakari's approach of repurposing
> > pm_runtime_put_autosuspend(), and introducing
> > __pm_runtime_put_autosuspend() for the odd cases where
> > pm_runtime_mark_last_busy() shouldn't be called.
> 
> Okay, so the reason for this approach is because we couldn't find a
> short and descriptive name that could be used in favor of
> pm_runtime_put_autosuspend(). Let me throw some ideas at it and maybe
> you like it - or not. :-)

I like the idea at least :-)

> I don't know what options you guys discussed, but to me the entire
> "autosuspend"-suffix isn't really that necessary in my opinion. There
> are more ways than calling pm_runtime_put_autosuspend() that triggers
> us to use the RPM_AUTO flag for rpm_suspend(). For example, just
> calling pm_runtime_put() has the similar effect.

To be honest, I'm lost there. pm_runtime_put() calls
__pm_runtime_idle(RPM_GET_PUT | RPM_ASYNC), while
pm_runtime_put_autosuspend() calls __pm_runtime_suspend(RPM_GET_PUT |
RPM_ASYNC | RPM_AUTO).

> 
> Moreover, it's similar for pm_runtime_mark_last_busy(), it's called
> during rpm_resume() too, for example. So why bother about having
> "mark_last_busy" in the new name too.
> 
> That said, my suggestion is simply "pm_runtime_put_suspend".

Can we do even better, and make pm_runtime_put() to handle autosuspend
automatically when autosuspend is enabled ?

> If you don't like it, I will certainly not object to your current
> approach, even if I think it leads to unnecessary churns.
> 
> [...]
> 
> Kind regards
> Uffe

-- 
Regards,

Laurent Pinchart

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	linux-bluetooth@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-gpio@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	nouveau@lists.freedesktop.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
	linux-i3c@lists.infradead.org, linux-iio@vger.kernel.org,
	linux-input@vger.kernel.org, patches@opensource.cirrus.com,
	iommu@lists.linux.dev, imx@lists.linux.dev,
	linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
	linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org,
	netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-phy@lists.infradead.org,
	linux-pwm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	linux-sound@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-staging@lists.linux.dev, linux-usb@vger.kernel.org,
	linux-serial@vger.kernel.org, greybus-dev@lists.linaro.org,
	asahi@lists.linux.dev, rafael@kernel.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: [PATCH 00/51] treewide: Switch to __pm_runtime_put_autosuspend()
Date: Tue, 8 Oct 2024 01:25:02 +0300	[thread overview]
Message-ID: <20241007222502.GG30699@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAPDyKFpQVnF7eQv3dup8k-3EijnMjuveCG9sZ=Rpey1Y6MBJEg@mail.gmail.com>

Hi Ulf,

On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote:
> On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote:
> > On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote:
> > > On Fri, 4 Oct 2024 at 11:41, Sakari Ailus wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > This set will switch the users of pm_runtime_put_autosuspend() to
> > > > __pm_runtime_put_autosuspend() while the former will soon be re-purposed
> > > > to include a call to pm_runtime_mark_last_busy(). The two are almost
> > > > always used together, apart from bugs which are likely common. Going
> > > > forward, most new users should be using pm_runtime_put_autosuspend().
> > > >
> > > > Once this conversion is done and pm_runtime_put_autosuspend() re-purposed,
> > > > I'll post another set to merge the calls to __pm_runtime_put_autosuspend()
> > > > and pm_runtime_mark_last_busy().
> > >
> > > That sounds like it could cause a lot of churns.
> > >
> > > Why not add a new helper function that does the
> > > pm_runtime_put_autosuspend() and the pm_runtime_mark_last_busy()
> > > things? Then we can start moving users over to this new interface,
> > > rather than having this intermediate step?
> >
> > I think the API would be nicer if we used the shortest and simplest
> > function names for the most common use cases. Following
> > pm_runtime_put_autosuspend() with pm_runtime_mark_last_busy() is that
> > most common use case. That's why I like Sakari's approach of repurposing
> > pm_runtime_put_autosuspend(), and introducing
> > __pm_runtime_put_autosuspend() for the odd cases where
> > pm_runtime_mark_last_busy() shouldn't be called.
> 
> Okay, so the reason for this approach is because we couldn't find a
> short and descriptive name that could be used in favor of
> pm_runtime_put_autosuspend(). Let me throw some ideas at it and maybe
> you like it - or not. :-)

I like the idea at least :-)

> I don't know what options you guys discussed, but to me the entire
> "autosuspend"-suffix isn't really that necessary in my opinion. There
> are more ways than calling pm_runtime_put_autosuspend() that triggers
> us to use the RPM_AUTO flag for rpm_suspend(). For example, just
> calling pm_runtime_put() has the similar effect.

To be honest, I'm lost there. pm_runtime_put() calls
__pm_runtime_idle(RPM_GET_PUT | RPM_ASYNC), while
pm_runtime_put_autosuspend() calls __pm_runtime_suspend(RPM_GET_PUT |
RPM_ASYNC | RPM_AUTO).

> 
> Moreover, it's similar for pm_runtime_mark_last_busy(), it's called
> during rpm_resume() too, for example. So why bother about having
> "mark_last_busy" in the new name too.
> 
> That said, my suggestion is simply "pm_runtime_put_suspend".

Can we do even better, and make pm_runtime_put() to handle autosuspend
automatically when autosuspend is enabled ?

> If you don't like it, I will certainly not object to your current
> approach, even if I think it leads to unnecessary churns.
> 
> [...]
> 
> Kind regards
> Uffe

-- 
Regards,

Laurent Pinchart

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2024-10-07 22:25 UTC|newest]

Thread overview: 122+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-04  9:41 [PATCH 00/51] treewide: Switch to __pm_runtime_put_autosuspend() Sakari Ailus
2024-10-04  9:41 ` Sakari Ailus
2024-10-04  9:41 ` Sakari Ailus
2024-10-04  9:41 ` Sakari Ailus
2024-10-04  9:41 ` [PATCH 05/51] clk: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 02/51] bluetooth: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 01/51] accel/ivpu: " Sakari Ailus
2024-10-04  9:51   ` Jacek Lawrynowicz
2024-10-04  9:41 ` [PATCH 03/51] bus: sunxi-rsb: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 04/51] hwrng: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 08/51] gpio: " Sakari Ailus
2024-10-04  9:55   ` Bartosz Golaszewski
2024-10-04 10:08     ` Sakari Ailus
2024-10-04  9:41 ` [PATCH 07/51] dmaengine: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 06/51] crypto: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 09/51] drm/amd: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 12/51] drm/panfrost: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 11/51] drm/radeon: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 10/51] drm/nouveau: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 13/51] drivers: drm: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 15/51] stm class: " Sakari Ailus
2024-10-24 10:59   ` Alexander Shishkin
2024-10-04  9:41 ` [PATCH 16/51] i2c: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 18/51] i3c: dw: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 17/51] i3c: master: svc: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 14/51] HSI: omap_ssi_port: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 23/51] irqchip/imx-irqsteer: " Sakari Ailus
2024-10-06 19:52   ` Thomas Gleixner
2024-10-04  9:41 ` [PATCH 22/51] iommu/arm-smmu: " Sakari Ailus
2024-10-10 15:33   ` Pranjal Shrivastava
2024-10-23 16:48     ` Will Deacon
2024-10-24 15:26       ` Pranjal Shrivastava
2024-10-04  9:41 ` [PATCH 20/51] Input: omap4-keypad: " Sakari Ailus
2024-10-04  9:55   ` Andreas Kemnade
2024-10-04 10:26     ` Sakari Ailus
2024-10-04 10:54       ` Andreas Kemnade
2024-10-04 11:08       ` Dmitry Torokhov
2024-10-04  9:41 ` [PATCH 24/51] mailbox: mtk-cmdq-mailbox: " Sakari Ailus
2024-10-07 14:27   ` Matthias Brugger
2024-10-04  9:41 ` [PATCH 19/51] iio: " Sakari Ailus
2024-10-04 13:45   ` Jonathan Cameron
2024-10-04  9:41 ` [PATCH 25/51] media: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 21/51] Input: cs40l50: " Sakari Ailus
2024-10-04 11:09   ` Dmitry Torokhov
2024-10-04  9:41 ` [PATCH 30/51] net: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 26/51] mfd: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 28/51] mmc: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 27/51] mei: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 29/51] mtd: rawnand: gpmi: " Sakari Ailus
2024-10-04 11:12   ` Miquel Raynal
2024-10-04  9:41 ` [PATCH 31/51] nfc: trf7970a: " Sakari Ailus
2024-10-04 14:05   ` Krzysztof Kozlowski
2024-10-04  9:41 ` [PATCH 32/51] PCI/portdrv: " Sakari Ailus
2024-10-04  9:45   ` Ilpo Järvinen
2024-10-04  9:41 ` [PATCH 33/51] phy: motorola: phy-mapphone-mdm6600: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 35/51] power: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 34/51] phy: ti: phy-twl4030-usb: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 36/51] pwm: img: " Sakari Ailus
2024-10-04 12:38   ` Uwe Kleine-König
2024-10-04  9:41 ` [PATCH 37/51] regulator: stm32-vrefbuf: " Sakari Ailus
2024-10-04 11:34   ` Mark Brown
2024-10-04  9:41 ` [PATCH 39/51] slimbus: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 42/51] staging: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 41/51] spi: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 38/51] remoteproc: omap: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 40/51] soundwire: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 45/51] usb: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 43/51] thunderbolt: " Sakari Ailus
2024-10-04 10:07   ` Mika Westerberg
2024-10-04  9:41 ` [PATCH 49/51] ASoC: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 48/51] ALSA: hda: " Sakari Ailus
2024-10-04 10:56   ` Takashi Iwai
2024-10-04 23:57     ` Mark Brown
2024-10-04  9:41 ` [PATCH 46/51] w1: omap-hdq: " Sakari Ailus
2024-10-04 14:05   ` Krzysztof Kozlowski
2024-10-04  9:41 ` [PATCH 44/51] serial: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 51/51] soc: apple: mailbox: " Sakari Ailus
2024-10-04  9:41 ` [PATCH 50/51] ALSA: intel_hdmi: " Sakari Ailus
2024-10-04 14:38 ` [PATCH 00/51] treewide: " Ulf Hansson
2024-10-04 14:38   ` Ulf Hansson
2024-10-04 14:38   ` Ulf Hansson
2024-10-04 14:38   ` Ulf Hansson
2024-10-07 18:49   ` Laurent Pinchart
2024-10-07 18:49     ` Laurent Pinchart
2024-10-07 18:49     ` Laurent Pinchart
2024-10-07 18:49     ` Laurent Pinchart
2024-10-07 22:08     ` Ulf Hansson
2024-10-07 22:08       ` Ulf Hansson
2024-10-07 22:08       ` Ulf Hansson
2024-10-07 22:08       ` Ulf Hansson
2024-10-07 22:25       ` Laurent Pinchart [this message]
2024-10-07 22:25         ` Laurent Pinchart
2024-10-07 22:25         ` Laurent Pinchart
2024-10-07 22:25         ` Laurent Pinchart
2024-10-07 22:34         ` Ulf Hansson
2024-10-07 22:34           ` Ulf Hansson
2024-10-07 22:34           ` Ulf Hansson
2024-10-07 22:34           ` Ulf Hansson
2024-10-08 18:24           ` Rafael J. Wysocki
2024-10-08 18:24             ` Rafael J. Wysocki
2024-10-08 18:24             ` Rafael J. Wysocki
2024-10-08 18:24             ` Rafael J. Wysocki
2024-10-09 10:20             ` Rafael J. Wysocki
2024-10-09 10:20               ` Rafael J. Wysocki
2024-10-09 10:20               ` Rafael J. Wysocki
2024-10-09 10:20               ` Rafael J. Wysocki
2024-10-09 10:27             ` Ulf Hansson
2024-10-09 10:27               ` Ulf Hansson
2024-10-09 10:27               ` Ulf Hansson
2024-10-09 10:27               ` Ulf Hansson
2024-10-09 12:48             ` Richard Fitzgerald
2024-10-09 12:48               ` Richard Fitzgerald
2024-10-09 12:48               ` Richard Fitzgerald
2024-10-09 12:48               ` Richard Fitzgerald
2024-10-09 13:34               ` Rafael J. Wysocki
2024-10-09 13:34                 ` Rafael J. Wysocki
2024-10-09 13:34                 ` Rafael J. Wysocki
2024-10-09 13:34                 ` Rafael J. Wysocki
2024-10-08 20:38     ` Uwe Kleine-König
2024-10-08 20:38       ` Uwe Kleine-König
2024-10-08 20:38       ` Uwe Kleine-König
2024-10-08 20:38       ` Uwe Kleine-König

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=20241007222502.GG30699@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=asahi@lists.linux.dev \
    --cc=dmaengine@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=imx@lists.linux.dev \
    --cc=iommu@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=patches@opensource.cirrus.com \
    --cc=rafael@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=ulf.hansson@linaro.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: 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.