Hi Niklas,
Thank you for the patch.
On Friday, 2 March 2018 03:57:45 EET Niklas Söderlund wrote:
> Each Gen3 SoC has a limited set of predefined routing possibilities for
> which CSI-2 device and channel can be routed to which VIN instance.
> Prepare to store this information in the struct rvin_info.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx>
> ---
> drivers/media/platform/rcar-vin/rcar-vin.h | 42 +++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h index
> 07cde9e1ab01ca51..6150a883e17f8479 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -43,6 +43,14 @@ enum model_id {
> RCAR_GEN3,
> };
>
> +enum rvin_csi_id {
> + RVIN_CSI20,
> + RVIN_CSI21,
> + RVIN_CSI40,
> + RVIN_CSI41,
> + RVIN_CSI_MAX,
> +};
> +
> /**
> * STOPPED - No operation in progress
> * RUNNING - Operation in progress have buffers
> @@ -81,12 +89,45 @@ struct rvin_graph_entity {
> unsigned int sink_pad;
> };
>
> +/**
> + * struct rvin_group_route - describes a route from a channel of a
> + * CSI-2 receiver to a VIN
> + *
> + * @vin: VIN ID.
> + * @csi: CSI-2 receiver ID.
> + * @chan: Output channel of the CSI-2 receiver.
Do you think channel instead of chan would be too long ?
> + * @mask: Bitmask of the different CHSEL register values that
> + * allows for a route from @csi + @chan to @vin.
s/allows/allow/
> + *
> + * .. note::
> + * Each R-Car CSI-2 receiver has four output channels facing the VIN
> + * devices, each channel can carry one CSI-2 Virtual Channel (VC).
> + * There are no correlation between channel number and CSI-2 VC. It's
s/are/is/
> + * up to the CSI-2 receiver driver to configure which VC is output
> + * on which channel, the VIN devices only care about output channels.
> + *
> + * There are in some cases multiple CHSEL register settings which would
> + * allow for the same route from @csi + @chan to @vin. For example
> + * on R-Car H3 both the CHSEL values 0 and 3 allows for a route from
s/allows/allow/
> + * CSI40/VC0 to VIN0. All possible CHSEL values for a route need to be
> + * recorded as a bitmask in @mask, in this example bit 0 and 3 should
> + * be set.
> + */
> +struct rvin_group_route {
> + unsigned int vin;
> + enum rvin_csi_id csi;
> + unsigned char chan;
> + unsigned int mask;
> +};
Repeating my comments on v10,
You can make chan an unsigned int, the compiler will pad the field anyway.
I think it would be clearer to order the fields in "from -> to: configuration"
order (csi, channel, vin, mask).
> /**
> * struct rvin_info - Information about the particular VIN implementation
> * @model: VIN model
> * @use_mc: use media controller instead of controlling subdevice
> * @max_width: max input width the VIN supports
> * @max_height: max input height the VIN supports
> + * @routes: list of possible routes from the CSI-2 recivers to
> + * all VINs. The list mush be NULL terminated.
> */
> struct rvin_info {
> enum model_id model;
> @@ -94,6 +135,7 @@ struct rvin_info {
>
> unsigned int max_width;
> unsigned int max_height;
> + const struct rvin_group_route *routes;
> };
>
> /**
--
Regards,
Laurent Pinchart
