From: Marco Felsch <m.felsch@pengutronix.de>
To: Jacopo Mondi <jacopo@jmondi.org>
Cc: mchehab@kernel.org, sakari.ailus@linux.intel.com,
laurent.pinchart+renesas@ideasonboard.com,
jacopo+renesas@jmondi.org, akinobu.mita@gmail.com,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@pengutronix.de
Subject: Re: [PATCH 4/4] media: mt9m111: remove .s_power callback
Date: Fri, 19 Aug 2022 10:06:26 +0200 [thread overview]
Message-ID: <20220819080626.34ghffj6hmkk5ntm@pengutronix.de> (raw)
In-Reply-To: <20220819073512.ulud7ppnrudxewdn@uno.localdomain>
On 22-08-19, Jacopo Mondi wrote:
> Hi Marco
>
> On Fri, Aug 19, 2022 at 09:18:32AM +0200, Marco Felsch wrote:
> > Hi Jacopo,
> >
> > thanks for your fast feedback :)
> >
> > On 22-08-18, Jacopo Mondi wrote:
> > > Hi Marco
> > >
> > > On Thu, Aug 18, 2022 at 04:47:12PM +0200, Marco Felsch wrote:
> > > > This is in preparation of switching to the generic dev PM mechanism.
> > > > Since the .s_power callback will be removed in the near future move the
> > > > powering into the .s_stream callback. So this driver no longer depends
> > > > on the .s_power mechanism.
> > > >
> > > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > >
> > > If you want to move to runtime_pm, I would implement it first and have
> > > s_power call the _resume and _suspend routines, as some platform
> > > drivers still use s_power() and some of them might depend on it.
> >
> > Do we really have platforms which depend on this? IMHO if that is the
>
> $ git grep "v4l2_subdev_call(.*, s_power" drivers/media/platform/ | cut -d : -f1 | uniq | wc -l
> 8
>
> > case than we should fix those platfoms. Since new drivers shouldn't use
> > this callback anymore.
>
> Patches are clearly welcome I guess..
:)
> > In my case, I worked on [1] and wondered why the sensor was enabled
> > before I told him to do so. Since I didn't implement the s_power()
> > callback, I had no chance to get enabled before.
> >
>
> I'm not sure I got this part
What I mean is, that the MT9M131 sensor gets enabled and immediately
start sending frames before I told him to do so e.g. by calling
s_stream(). This can confuse the downstream device. The only way to get
enable the downstream device first is to add the s_power() callback.
> > Can we please decide:
> > - Do we wanna get rid of the s_power() callback?
>
> I think that would be everyone's desire, but drivers have to be moved
> away from it
>
> > - If not, how do we handle those devices then with drivers not
> > implementing this callback?
>
> By maintaining compatibility. I suggested to move to runtime_pm() and
> wrap _resume/_suspend in s_power().
But then you're introducing new drivers with s_power() callbacks and so
the behaviour isn't really changed.
> My understanding is that the two (runtime_pm/s_power) are mutually
> exclusive, but even if that was not the case, runtime_pm is reference
> counted, hence as long as calls are balanced this should work, right ?
Right but the s_power() behaviour is not changed and drivers still rely
on it to work as right now.
Regards,
Marco
next prev parent reply other threads:[~2022-08-19 8:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 14:47 [PATCH 1/4] media: mt9m111: add V4L2_CID_PIXEL_RATE support Marco Felsch
2022-08-18 14:47 ` [PATCH 2/4] media: mt9m111: fix subdev API usage Marco Felsch
2022-08-19 7:16 ` Jacopo Mondi
2022-08-19 7:28 ` Marco Felsch
2022-08-19 7:40 ` Jacopo Mondi
2022-08-22 6:28 ` Sakari Ailus
2022-08-22 7:51 ` Marco Felsch
2022-08-22 9:17 ` Sakari Ailus
2022-08-18 14:47 ` [PATCH 3/4] media: mt9m111: fix device power usage Marco Felsch
2022-08-19 7:26 ` Jacopo Mondi
2022-08-19 7:32 ` Marco Felsch
2022-08-22 6:31 ` Sakari Ailus
2022-08-22 7:54 ` Marco Felsch
2022-08-22 9:18 ` Sakari Ailus
2022-08-23 14:44 ` Marco Felsch
2023-01-16 22:14 ` Sakari Ailus
2023-01-17 11:29 ` Marco Felsch
2023-01-17 11:32 ` Sakari Ailus
2022-08-18 14:47 ` [PATCH 4/4] media: mt9m111: remove .s_power callback Marco Felsch
2022-08-18 16:14 ` Jacopo Mondi
2022-08-19 7:18 ` Marco Felsch
2022-08-19 7:35 ` Jacopo Mondi
2022-08-19 8:06 ` Marco Felsch [this message]
2022-08-19 8:17 ` Jacopo Mondi
2022-08-18 16:11 ` [PATCH 1/4] media: mt9m111: add V4L2_CID_PIXEL_RATE support Jacopo Mondi
2022-08-19 7:56 ` Marco Felsch
2022-08-19 8:15 ` Jacopo Mondi
2022-08-19 9:04 ` Marco Felsch
2022-08-19 9:46 ` Jacopo Mondi
2022-08-19 10:06 ` Marco Felsch
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=20220819080626.34ghffj6hmkk5ntm@pengutronix.de \
--to=m.felsch@pengutronix.de \
--cc=akinobu.mita@gmail.com \
--cc=jacopo+renesas@jmondi.org \
--cc=jacopo@jmondi.org \
--cc=kernel@pengutronix.de \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).