Hi Jacopo, Thanks for the patch. On Fri, 2020-03-13 at 07:40:31 -0700, Jacopo Mondi wrote: > This series introduces a pad oriented operation, much similar to the existing > s/g_mbus_config subdv video operation, to allow dyanmic negotiation of media > bus parameter. > > The existing s/g_mbus_format are on their way to deprecation, due to the fact > they operate at device level being a video op instead of pad level as this new > implementation does. > > The use case I'm addressing is described here, in the RFC sent one year ago > on top of Sakari's v4l-multiplexed work, where I tried to extend the frame > descriptor to transport media bus information. > > Quoting: > https://patchwork.kernel.org/cover/10855919/ > "The use case this series cover is the following one: > the Gen-3 R-Car boards include an ADV748x HDMI/CVBS to CSI-2 converter > connected to its CSI-2 receivers. The ADV748x chip has recently gained support > for routing both HDMI and analogue video streams through its 4 lanes TXA > transmitter, specifically to support the Ebisu board that has a single CSI-2 > receiver, compared to all other Gen-3 board where the ADV748x TXes are connected > to different CSI-2 receivers, and where analogue video is streamed out from the > ADV748x single lane TXB transmitter. > To properly support transmission of analogue video through TXA, the number of > data lanes shall be dynamically reduced to 1, in order to comply with the MIPI > CSI-2 minimum clock frequency requirements" > > During the discussion of the RFC, Dave reported another use case for media > bus parameter negotiation on his platform: > https://patchwork.kernel.org/patch/10855923/#22569149 And as you know, there's another use case for GMSL, and this patch set helps negotiation between serializer and de-serializer. :-) I added the GMSL config for some parameters on top of this, and it works well. > > Another possible use case is for parallel bus multiplexing, where multiple image > sensor share the parallel bus lines and they get activated alternatively through > an enable signal. While this might not be most clever design, it's often seen > in the wild, and this operation allow receivers to re-configure their bus > parameter in between streaming session. Even for parallel bus, I'm learning how diverse configurations can be. For example, some ISP aligns bits in different way, MSB of color component on d0. I'm sure there are a lot more creative ones out there, so this seems quite useful to handle such accordingly. Thanks, -hyun > > For now I have left untouched definitions and users of the existing > s/g_mbus_config ops, waiting for feedback on this first implementation. > > Thanks > j > > Jacopo Mondi (4): > media: i2c: adv748x: Adjust TXA data lanes number > media: v4l2-subdv: Introduce get_mbus_config pad op > media: i2c: adv748x: Implement get_mbus_config > media: rcar-vin: csi2: Negotiate data lanes number > > drivers/media/i2c/adv748x/adv748x-core.c | 31 +++++++--- > drivers/media/i2c/adv748x/adv748x-csi2.c | 15 +++++ > drivers/media/i2c/adv748x/adv748x.h | 1 + > drivers/media/platform/rcar-vin/rcar-csi2.c | 49 ++++++++++++++- > include/media/v4l2-subdev.h | 67 +++++++++++++++++++++ > 5 files changed, 153 insertions(+), 10 deletions(-) > > -- > 2.25.1 >
