Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting for once, to make this easily accessible to everyone. Paul, what happened to this? It looks like this fall through the cracks, but maybe I'm missing something, that's why I ask. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. #regzbot poke On 02.06.23 12:03, Laurent Pinchart wrote: > On Fri, Jun 02, 2023 at 11:39:54AM +0200, Paul Kocialkowski wrote: >> (Re-adding folks from the original email, adding Laurent and Hans.) >> On Fri 02 Jun 23, 11:24, Martijn Braam wrote: >>> >>> That's basically it yes. My software doesn't expect the bridge block, >>> because it wasn't there. The pipeline always worked "automatically". >>> >>> This is the workaround that's been made now it run on newer kernels: >>> https://gitlab.com/postmarketOS/megapixels/-/merge_requests/31 >>> >>> I'm pretty sure format propagation would fix this issue. >> >> Okay that's good to know. >> >> To be honest it's still not very clear to me if in-driver format propagation is >> a "nice to have" feature or something that all media pipeline drivers are >> supposed to implement. > > For MC-based drivers, in-kernel propagation *inside* subdevs is > mandatory, in-kernel propagration *between* subdevs is not allowed. The > latter is the responsibility of userspace. > > For traditional (I'd say legacy, but I know not everybody likes that > term :-)) drivers that only expose video device nodes and do not expose > subdev nodes to userspace, the driver is responsible for configuring the > full pipeline internally based on the S_FMT call on the video nodes > only. This isn't applicable to the sun6i-csi driver, as it exposes > subdev nodes to userspace. > >> Anyway I feel like this is not really a regression but a result of the driver >> being converted to a newer API. >> >> Also there's a V4L2_CAP_IO_MC flag which should indicate that the video device >> must be controlled via the media controller API instead of being >> video-device-centric, but I've seen comments asking not to set the flag even >> when MC is used so I'm a bit confused here. > > Would you have pointers to those comments ? > >> Perhaps the flag is only required when there is no automatic format >> propagation? > > The flag is more or less required when you expose subdev nodes to > userspace. > >> If anyone has solid answers on these points I'd be happy to read some >> clarification (and act accordingly). >> >>> On 6/2/23 11:16, Paul Kocialkowski wrote: >>>> Hi Martijn, >>>> >>>> On Thu 01 Jun 23, 23:19, Martijn Braam wrote: >>>>> It seems like this commit: >>>>> >>>>> media: sun6i-csi: Add bridge v4l2 subdev with port management >>>>> >>>>> Has changed the way the media pipeline on a64 devices, in my case the PINE64 >>>>> PinePhone works. Since this is an API towards userspace and there's active >>>>> applications that use it I think this counts as a regression. >>>> Do you have more details on what changed specifically? >>>> >>>> The commit added a bridge subdev in addition to the video node, which is >>>> generally a better description of the CSI hardware and also a necessity >>>> to support the ISP data flow. >>>> >>>> Maybe your userspace application is not configuring the bridge media block with >>>> the right format, which results in a mismatch? >>>> >>>> Some work was started to achieve automatic format propagation, perhaps it >>>> would be enough to solve your issue. >>>> >>>> Cheers, >>>> >>>> Paul >>>> >>>>> #regzbot introduced: 0d2b746b1bef73de62d2d311e594a7ffed4ca43 >
