Message-ID: <ZuAXiKjdgMUY1jcV@kekkonen.localdomain>
Date: Tue, 10 Sep 2024 09:55:20 +0000
From: Sakari Ailus <sakari.ailus@...ux.intel.com>
To: Jacopo Mondi <jacopo.mondi@...asonboard.com>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Raspberry Pi Kernel Maintenance <kernel-list@...pberrypi.com>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Florian Fainelli <florian.fainelli@...adcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	oe-kbuild-all@...ts.linux.dev, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	linux-rpi-kernel@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org,
	Naushir Patuck <naush@...pberrypi.com>,
	Kieran Bingham <kieran.bingham@...asonboard.com>,
	kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v4 3/4] media: raspberrypi: Add support for RP1-CFE

Hi Jacopo,

On Tue, Sep 10, 2024 at 11:42:06AM +0200, Jacopo Mondi wrote:
> > > > > > > Ah, I missed that one.
> > > > > > >
> > > > > > > I don't think it fixes the issue I mentioned. If we have PM enabled, and the
> > > > > > > parent device requires powering up for the child device (BE) to be
> > > > > > > accessible, the driver will crash when calling pispbe_hw_init(). I think you
> > > > > > > should call pm_runtime_set_active() before calling pispbe_runtime_resume().
> > > > > >
> > > > > > As discussed, this is not a problem currently for BE, but indeed you
> > > > > > have a point.
> > >
> > > I admit the runtime_pm intrinsics are obscure to me, but Laurent just
> > > made me notice something.
> > >
> > > Consider the following scenario
> > >
> > > *) Kernel compiled with CONFIG_PM
> > > *) i2c sensor driver that supports both CONFIG_PM and !CONFIG_PM by:
> > >   *) Manually power up the sensor during probe
> > >   *) Call pm_runtime_enable() and pm_runtime_set_active() at the end
> > >      of the probe routine after having accessed the chip over i2c
> > >      (like most, if not all the i2c drivers in mainline do including
> > >      ccs)
> > >
> > > All these drivers work, and during the probe routine before accessing
> > > the HW, they don't need to power up the parent i2c controller.
> >
> > This isn't done explicitly by the I²C drivers, indeed but...
> >
> > >
> > > Might it be that during probe() the parent is guaranteed to be enabled ?
> >
> > ...yes.
> >
> 
> Unrelated, but I am wrong the driver core calls pm_request_idle() on
> the just probed device ? Does this mean drivers doesn't have to do
> that by themseleves ? (it's not a big deal, as request_idle() doesn't
> change the usage counter)

Seems like that. This could be omitted from drivers then.

> 
> > >
> > > I add a look in the driver-core and pm Documentation/ but found
> > > nothing.
> > >
> > > A quick stroll in driver/base/ got me to __device_attach() and it
> > > seems parents are powered up before attaching a driver to a device
> > > (which in my understanding should be what ends up calling probe()).
> > > Clearly I've no real understanding of what I'm talking about when it
> > > comes to driver-core, so take this with a grain of salt.
> >
> > This only works with runtime PM enabled.
> >
> 
> It's the CONFIG_PM case that was worrying for Tomi
> 
> > >
> > > > > >
> > > > > > Sad note: most of all the occurrences of "grep set_active" in
> > > > > > drivers/media/platform/ show that set_active() is used as I've done in
> > > > > > my patch
> > > > > >
> > > > > > > However, you said above that "supporting !CONFIG_PM is not that much work".
> > > > > > > Maybe not. But how much work is it to get it right (for both PM and !PM),
> > > > > > > and make sure it stays right? =).
> > > > > > >
> > > > > > > Just my opinion, but if there are zero use cases for the !PM, I would just
> > > > > > > go with "depends on PM" to keep the driver simpler, less bug-prone, and
> > > > > > > easier to maintain.
> > > > >
> > > > > I'm fine with that, and for platform drivers, that's my preferred
> > > > > option. Sakari ?
> > > >
> > > > I'm concerned with your (?) recent finding that many architectures don't
> > > > have support for CONFIG_PM. In this case the device is very unlikely to be
> > > > used outside ARM(64) so I guess it's fine.
> > > >
> > >
> > > Also, this IP is RPi specific, and the !CONFIG_PM case is not used or
> > > tested on Pi.
> > >
> > > However, I think this current patch is correct (assuming the above
> > > reasoning on i2c sensor drivers is correct) and doesn't require
> > > CONFIG_PM, so I would be tempted to keep this version.
> >
> > I understand the current patch does depend on CONFIG_PM: it requires
> > runtime PM to be operational to start the clock, for instance.
> >
> 
> Where do you see that ?
> 
> This version still calls pispbe_runtime_resume() to power up the IP,
> it doesn't go through runtime_pm:
> https://patchwork.linuxtv.org/project/linux-media/patch/20240904095836.344833-5-jacopo.mondi@ideasonboard.com/

cfe_runtime_resume() is only called via runtime PM.

> 
> Thanks!
> 
> > >
> > > > >
> > > > > > I don't see a use case for !PM and we confirmed with RPi they don't
> > > > > > need to support it. During the review of a previous version of the BE
> > > > > > driver iirc I've been asked to support !PM but I'm not sure I recall
> > > > > > the reasons.
> > > > >
> > > > > I hope it wasn't me :-)
> > > >
> > > > Me neither. Although it'd be nice: CONFIG_PM isn't a hardware specific
> > > > option as such. As one part of the kernel requires !CONFIG_PM and another
> > > > CONFIG_PM, we can expect problems, at least in principle.
> > > >
> > > > Ideally all architectures would support it so CONFIG_PM could be removed
> > > > and we could say the problem has been solved. :-)

-- 
Kind regards,

Sakari Ailus

Powered by blists - more mailing lists