Hi Mauro, On Mon, Aug 26, 2024 at 04:03:14AM +0200, Mauro Carvalho Chehab wrote: > Em Mon, 26 Aug 2024 01:24:55 +0300 Laurent Pinchart escreveu: > > On Tue, Aug 13, 2024 at 10:17:59AM +0200, Hans Verkuil wrote: [snip] > > > 16:30-18:00: TBD > > > > Here's a candidate topic for this time slot: > > > > Should media drivers depend on CONFIG_PM? > > > > Supporting both CONFIG_PM and !CONFIG_PM in drivers requires cumbersome > > constructs, most likely leading to bugs because !CONFIG_PM is hardly > > ever tested. The issue can be at least partly attributed to deficiencies > > in the runtime PM and driver core APIs that should make this task easier > > for drivers, but that will not realistically change any time soon. > > > > In !CONFIG_PM kernels, drivers using runtime PM power up the device at > > probe time, and keep it powered until remove time. The increased power > > consumption really makes !CONFIG_PM a niche use case, if a use case at > > all. > > > > For those reasons, I would like to propose depending on CONFIG_PM for > > media drivers. In an ideal world this could be done for the whole > > subsystem. > > This is not an option. Not all drivers depend on it. Some of them will > never need it - like most USB and PCI tv/capture cards and digital tv ones. That by itself, I think, isn't a problem. We could technical depend on CONFIG_PM even if not all drivers make active use of it. Whether or not we want to is the question I hope this discussion will answer (and I have an increasingly strong feeling the answer will be negative, but let's see). > > However, some architectures don't support CONFIG_PM, namely > > > > - alpha > > - csky > > - hexagon > > - m68k > > - microblaze > > - nios2 > > - openrisc > > - parisc > > - s390 > > - sparc (32-bit version only, sparc64 supports CONFIG_PM) > > Well, arch-dependent drivers, like the ones made to run with ARM SoC > could depend on PM, but then there are sensor drivers and such which > are somewhat independent. > > > I assume we would get complains of the media subsystem became unusable > > on those architectures. The decision could be made per driver, or per > > category of drivers. I'm in particular interested in avoiding the churn > > of supporting !CONFIG_PM in camera sensor drivers, and in platform > > drivers that are used only on platforms that support CONFIG_PM. > > There are a couple of sensor drivers that are used by em28xx, which, as far > as I remember, doesn't use PM. So, even for sensors it could be problematic. I've checked the em28xx driver. Unless I'm mistaken, the only driver it uses from drivers/media/i2c/ is the ov2640. Still, that's more than zero, so this would certainly need to be taken into account. In the em28xx case, power management of the camera sensor is handled by the em28xx driver, outside of the camera sensor driver. Switching to usage of runtime PM in the ov2640 driver and keeping the sensor "powered up" from probe() onwards wouldn't be an issue, as the power on would be a no-op (the ov2640 driver will have no regulator, clock or GPIO to control in this case). Depending on CONFIG_PM, however, could be an issue, even if I doubt anyone would use an em28xx-based device on a platform that doesn't enable CONFIG_PM. > > I'm aware that asking this question may open the door to a more annoying > > one. If we decide that we need to keep supporting those platforms in > > camera sensor drivers, and that keeping the camera sensor powered up > > unconditionally is not good enough, then we will have to reconsider the > > move to runtime PM for sensor drivers that we started years ago (and > > haven't completed yet). > > Having PM support for sensor drivers makes sense, provided that it won't > break support of the existing drivers using them. > > > > Please reply with corrections, questions, etc. to this email. I'll update the agenda > > > over time. Again, these times are very preliminary. -- Regards, Laurent Pinchart
