mbox series

[v2,0/6] v4l2-subdev: Introduce get_mbus_format pad op

Message ID 20200415105004.2497356-1-jacopo+renesas@jmondi.org (mailing list archive)
Headers show
Series v4l2-subdev: Introduce get_mbus_format pad op | expand

Message

Jacopo Mondi April 15, 2020, 10:49 a.m. UTC
v2 introduces two new patches that could be likely squashed in later to
deprecate the g_mbus_config() operation in documentation and expand the newly
introduced function documentation by popular demand.

Will report again the use cases I'm trying to address here:
------------------------------------------------------------------------------
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

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.

Hyun is now using this series to configure GMSL devices.
------------------------------------------------------------------------------

v1->v2:
- Address Sakari's comment to use unsigned int in place of bools
- Add two new patches to address documentation
- Adjust rcar-csi2 patch as much as possible according to Niklas comments
- Add Niklas's tags

Jacopo Mondi (6):
  media: v4l2-subdv: Introduce get_mbus_config pad op
  media: v4l2-subdev: Deprecate g_mbus_config video op
  media: v4l2-subdev: Expand get_mbus_config doc
  media: i2c: adv748x: Adjust TXA data lanes number
  media: i2c: adv748x: Implement get_mbus_config
  media: rcar-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 | 53 ++++++++++++-
 include/media/v4l2-subdev.h                 | 82 ++++++++++++++++++++-
 5 files changed, 171 insertions(+), 11 deletions(-)

--
2.26.0

Comments

Laurent Pinchart April 20, 2020, 2:02 a.m. UTC | #1
Hi Jacopo,

Thank you for the patches.

On Wed, Apr 15, 2020 at 12:49:57PM +0200, Jacopo Mondi wrote:
> v2 introduces two new patches that could be likely squashed in later to
> deprecate the g_mbus_config() operation in documentation and expand the newly
> introduced function documentation by popular demand.
> 
> Will report again the use cases I'm trying to address here:
> ------------------------------------------------------------------------------
> 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
> 
> 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.

Isn't this already supported today, with the bus configuration for each
source specified in the corresponding endpoint (on the receiver side) in
DT ?

> Hyun is now using this series to configure GMSL devices.
> ------------------------------------------------------------------------------
> 
> v1->v2:
> - Address Sakari's comment to use unsigned int in place of bools
> - Add two new patches to address documentation
> - Adjust rcar-csi2 patch as much as possible according to Niklas comments
> - Add Niklas's tags
> 
> Jacopo Mondi (6):
>   media: v4l2-subdv: Introduce get_mbus_config pad op
>   media: v4l2-subdev: Deprecate g_mbus_config video op
>   media: v4l2-subdev: Expand get_mbus_config doc
>   media: i2c: adv748x: Adjust TXA data lanes number
>   media: i2c: adv748x: Implement get_mbus_config
>   media: rcar-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 | 53 ++++++++++++-
>  include/media/v4l2-subdev.h                 | 82 ++++++++++++++++++++-
>  5 files changed, 171 insertions(+), 11 deletions(-)
>
Jacopo Mondi May 13, 2020, 6:52 p.m. UTC | #2
Hi Laurent,

On Mon, Apr 20, 2020 at 05:02:28AM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patches.
>
> On Wed, Apr 15, 2020 at 12:49:57PM +0200, Jacopo Mondi wrote:
> > v2 introduces two new patches that could be likely squashed in later to
> > deprecate the g_mbus_config() operation in documentation and expand the newly
> > introduced function documentation by popular demand.
> >
> > Will report again the use cases I'm trying to address here:
> > ------------------------------------------------------------------------------
> > 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
> >
> > 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.
>
> Isn't this already supported today, with the bus configuration for each
> source specified in the corresponding endpoint (on the receiver side) in
> DT ?
>

I think you're right.. One should probably cache each endpoint configuration
parsed at probe time.. I was thinking at multiple connections to the
same endpoint, but seems it's not possible.. good, I'll drop this


> > Hyun is now using this series to configure GMSL devices.
> > ------------------------------------------------------------------------------
> >
> > v1->v2:
> > - Address Sakari's comment to use unsigned int in place of bools
> > - Add two new patches to address documentation
> > - Adjust rcar-csi2 patch as much as possible according to Niklas comments
> > - Add Niklas's tags
> >
> > Jacopo Mondi (6):
> >   media: v4l2-subdv: Introduce get_mbus_config pad op
> >   media: v4l2-subdev: Deprecate g_mbus_config video op
> >   media: v4l2-subdev: Expand get_mbus_config doc
> >   media: i2c: adv748x: Adjust TXA data lanes number
> >   media: i2c: adv748x: Implement get_mbus_config
> >   media: rcar-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 | 53 ++++++++++++-
> >  include/media/v4l2-subdev.h                 | 82 ++++++++++++++++++++-
> >  5 files changed, 171 insertions(+), 11 deletions(-)
> >
>
> --
> Regards,
>
> Laurent Pinchart