Re: [PATCH] rcar-csi2: Allow configuring of video standard
On 2/16/19 11:57 PM, Niklas Söderlund wrote:
> Allow the hardware to to do proper field detection for interlaced field
> formats by implementing s_std() and g_std(). Depending on which video
> standard is selected the driver needs to setup the hardware to correctly
> identify fields.
>
> Later versions of the datasheet have also been updated to make it clear
> that FLD register should be set to 0 when dealing with none interlaced
> field formats.
Nacked-by: Hans Verkuil
The G/S_STD and QUERYSTD ioctls are specific for SDTV video receivers
(composite, S-Video, analog tuner) and can't be used for CSI devices.
struct v4l2_mbus_framefmt already has a 'field' value that is explicit
about the field ordering (TB vs BT) or the field ordering can be deduced
from the frame height (FIELD_INTERLACED).
Regards,
Hans
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-csi2.c | 33 +++--
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index f3099f3e536d808a..664d3784be2b9db9 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -361,6 +361,7 @@ struct rcar_csi2 {
> struct v4l2_subdev *remote;
>
> struct v4l2_mbus_framefmt mf;
> + v4l2_std_id std;
>
> struct mutex lock;
> int stream_count;
> @@ -389,6 +390,22 @@ static void rcsi2_write(struct rcar_csi2 *priv, unsigned
> int reg, u32 data)
> iowrite32(data, priv->base + reg);
> }
>
> +static int rcsi2_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
> +{
> + struct rcar_csi2 *priv = sd_to_csi2(sd);
> +
> + priv->std = std;
> + return 0;
> +}
> +
> +static int rcsi2_g_std(struct v4l2_subdev *sd, v4l2_std_id *std)
> +{
> + struct rcar_csi2 *priv = sd_to_csi2(sd);
> +
> + *std = priv->std;
> + return 0;
> +}
> +
> static void rcsi2_standby_mode(struct rcar_csi2 *priv, int on)
> {
> if (!on) {
> @@ -475,7 +492,7 @@ static int rcsi2_calc_mbps(struct rcar_csi2 *priv,
> unsigned int bpp)
> static int rcsi2_start_receiver(struct rcar_csi2 *priv)
> {
> const struct rcar_csi2_format *format;
> - u32 phycnt, vcdt = 0, vcdt2 = 0;
> + u32 phycnt, vcdt = 0, vcdt2 = 0, fld = 0;
> unsigned int i;
> int mbps, ret;
>
> @@ -507,6 +524,15 @@ static int rcsi2_start_receiver(struct rcar_csi2 *priv)
> vcdt2 |= vcdt_part << ((i % 2) * 16);
> }
>
> + if (priv->mf.field != V4L2_FIELD_NONE) {
> + fld = FLD_FLD_EN4 | FLD_FLD_EN3 | FLD_FLD_EN2 | FLD_FLD_EN;
> +
> + if (priv->std & V4L2_STD_525_60)
> + fld |= FLD_FLD_NUM(2);
> + else
> + fld |= FLD_FLD_NUM(1);
> + }
> +
> phycnt = PHYCNT_ENABLECLK;
> phycnt |= (1 << priv->lanes) - 1;
>
> @@ -519,8 +545,7 @@ static int rcsi2_start_receiver(struct rcar_csi2 *priv)
> rcsi2_write(priv, PHTC_REG, 0);
>
> /* Configure */
> - rcsi2_write(priv, FLD_REG, FLD_FLD_NUM(2) | FLD_FLD_EN4 |
> - FLD_FLD_EN3 | FLD_FLD_EN2 | FLD_FLD_EN);
> + rcsi2_write(priv, FLD_REG, fld);
> rcsi2_write(priv, VCDT_REG, vcdt);
> if (vcdt2)
> rcsi2_write(priv, VCDT2_REG, vcdt2);
> @@ -662,6 +687,8 @@ static int rcsi2_get_pad_format(struct v4l2_subdev *sd,
> }
>
> static const struct v4l2_subdev_video_ops rcar_csi2_video_ops = {
> + .s_std = rcsi2_s_std,
> + .g_std = rcsi2_g_std,
> .s_stream = rcsi2_s_stream,
> };
>
>
Re: [PATCH RESEND v2 1/2] media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
On 3/1/19 3:24 PM, Biju Das wrote: > Document RZ/G2M (R8A774A1) SoC bindings. Please resend the whole series, not just the dt-bindings patches. Also note that the original v1 series said that there were 5 patches in the series, but only the first 4 were received on linux-media. So I have no idea what the 5th patch was (dts change perhaps?). Having a newly posted patch series avoids confusion. Regards, Hans > > The RZ/G2M SoC is similar to R-Car M3-W (R8A7796). > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > Acked-by: Niklas Söderlund > Reviewed-by: Simon Horman > Reviewed-by: Rob Herring > --- > V1->V2 >* No change > --- > Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > index d63275e..9932458 100644 > --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > @@ -8,6 +8,7 @@ R-Car VIN module, which provides the video capture > capabilities. > Mandatory properties > > - compatible: Must be one or more of the following > + - "renesas,r8a774a1-csi2" for the R8A774A1 device. > - "renesas,r8a774c0-csi2" for the R8A774C0 device. > - "renesas,r8a7795-csi2" for the R8A7795 device. > - "renesas,r8a7796-csi2" for the R8A7796 device. >
Re: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
Hi Biju, Can you do the following: 1) forward both of Rob's replies with his Reviewed-by tag to linux-media, that way I have seen it. 2) rebase the patch series and add all Reviewed-by etc. tags and post as a v2. I'll pick it up and make sure it will get merged. Not sure if we can manage 5.1, but it will certainly get in 5.2. Regards, Hans On 3/1/19 2:12 PM, Biju Das wrote: > Hi Hans, > > Thanks for the feedback. > >> -Original Message- >> From: Hans Verkuil >> Sent: 01 March 2019 13:09 >> To: Geert Uytterhoeven >> Cc: Fabrizio Castro ; Mauro Carvalho >> Chehab ; Biju Das ; >> Niklas Söderlund ; linux- >> me...@vger.kernel.org; linux-renesas-soc@vger.kernel.org; >> devicet...@vger.kernel.org; Simon Horman ; Geert >> Uytterhoeven ; Chris Paterson >> ; Rob Herring ; Mark >> Rutland ; Laurent Pinchart >> >> Subject: Re: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 >> support >> >> On 3/1/19 1:58 PM, Geert Uytterhoeven wrote: >>> Hi Hans, >>> >>> On Fri, Mar 1, 2019 at 1:55 PM Hans Verkuil wrote: >>>> It looks like this series fell through the cracks. >>>> >>>> I looked at it and the main problem is that it is missing a >>>> Reviewed-by from Rob Herring (devicetree maintainer). It's a bit >>>> surprising since he is usually fairly prompt. >>> >>> He actually did provide his Rb on Sep 17. >> >> Hmm, I don't see anything about that in my linux-media archive, and >> patchwork didn't pick that up either. >> >> Was linux-media in the CC list of Rob's reply? > > Yes. Please see below. > >> -Original Message- >> From: Rob Herring >> Sent: 17 September 2018 06:45 >> To: Biju Das >> Cc: Mauro Carvalho Chehab ; Mark Rutland >> ; Biju Das ; Niklas >> Söderlund ; linux-me...@vger.kernel.org; >> linux-renesas-soc@vger.kernel.org; devicet...@vger.kernel.org; Simon >> Horman ; Geert Uytterhoeven >> ; Chris Paterson >> ; Fabrizio Castro >> >> Subject: Re: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 >> support >> >> On Mon, 10 Sep 2018 15:31:14 +0100, Biju Das wrote: >>> Document RZ/G2M (R8A774A1) SoC bindings. >>> >>> The RZ/G2M SoC is similar to R-Car M3-W (R8A7796). >>> >>> Signed-off-by: Biju Das >>> Reviewed-by: Fabrizio Castro >>> --- >>> Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 5 +++-- >>> 1 file changed, 3 insertions(+), 2 deletions(-) >>> >> >> Reviewed-by: Rob Herring > > Regards, > Biju > > > Renesas Electronics Europe GmbH,Geschaeftsfuehrer/President : Michael > Hannawald, Sitz der Gesellschaft/Registered office: Duesseldorf, > Arcadiastrasse 10, 40472 Duesseldorf, Germany,Handelsregister/Commercial > Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE > 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647 >
Re: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
On 3/1/19 1:58 PM, Geert Uytterhoeven wrote:
> Hi Hans,
>
> On Fri, Mar 1, 2019 at 1:55 PM Hans Verkuil wrote:
>> It looks like this series fell through the cracks.
>>
>> I looked at it and the main problem is that it is missing a Reviewed-by
>> from Rob Herring (devicetree maintainer). It's a bit surprising since he
>> is usually fairly prompt.
>
> He actually did provide his Rb on Sep 17.
Hmm, I don't see anything about that in my linux-media archive, and patchwork
didn't pick that up either.
Was linux-media in the CC list of Rob's reply?
Regards,
Hans
>
> Gr{oetje,eeting}s,
>
> Geert
>
Re: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
Hi Fabrizio, It looks like this series fell through the cracks. I looked at it and the main problem is that it is missing a Reviewed-by from Rob Herring (devicetree maintainer). It's a bit surprising since he is usually fairly prompt. I recommend that you rebase and repost it and I'll delegate the v2 series to me so we can hopefully get it in for 5.2 (5.1 is likely too late) once Rob reviews it. BTW, I'm the one who usually processes rcar patches. But it was delegated in patchwork to Laurent, so I never saw it. Regards, Hans On 3/1/19 1:09 PM, Fabrizio Castro wrote: > Hello Mauro, > > This patch has been around for some time now, do you think you can take it? > > Cheers, > Fab > >> From: Biju Das >> Sent: 10 September 2018 15:31 >> Subject: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 >> support >> >> Document RZ/G2M (R8A774A1) SoC bindings. >> >> The RZ/G2M SoC is similar to R-Car M3-W (R8A7796). >> >> Signed-off-by: Biju Das >> Reviewed-by: Fabrizio Castro >> --- >> Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt >> b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt >> index 2d385b6..12fe685 100644 >> --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt >> +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt >> @@ -2,12 +2,13 @@ Renesas R-Car MIPI CSI-2 >> >> >> The R-Car CSI-2 receiver device provides MIPI CSI-2 capabilities for the >> -Renesas R-Car family of devices. It is used in conjunction with the >> -R-Car VIN module, which provides the video capture capabilities. >> +Renesas R-Car Gen3 and RZ/G2 family of devices. It is used in conjunction >> +with the R-Car VIN module, which provides the video capture capabilities. >> >> Mandatory properties >> >> - compatible: Must be one or more of the following >> + - "renesas,r8a774a1-csi2" for the R8A774A1 device. >> - "renesas,r8a7795-csi2" for the R8A7795 device. >> - "renesas,r8a7796-csi2" for the R8A7796 device. >> - "renesas,r8a77965-csi2" for the R8A77965 device. >> -- >> 2.7.4 >
Re: [PATCH 1/2] media: i2c: adv748x: Convert SW reset routine to function
On 1/11/19 6:41 PM, Kieran Bingham wrote:
> The ADV748x is currently reset by writting a small table of registers to
> the device.
>
> The table lacks documentation and contains magic values to perform the
> actions, including using a fake register address to introduce a delay
> loop.
>
> Remove the table, and convert to code, documenting the purpose of the
> specific writes along the way.
>
> Signed-off-by: Kieran Bingham
Hmm, this patch doesn't apply to the master branch.
Does it depend on other patches being merged first, or it is just out-of-date?
Regards,
Hans
> ---
> drivers/media/i2c/adv748x/adv748x-core.c | 32
> drivers/media/i2c/adv748x/adv748x.h | 16
> 2 files changed, 38 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index 02f9c440301c..252bdb28b18b 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -389,15 +389,6 @@ static const struct media_entity_operations
> adv748x_media_ops = {
> * HW setup
> */
>
> -static const struct adv748x_reg_value adv748x_sw_reset[] = {
> -
> - {ADV748X_PAGE_IO, 0xff, 0xff}, /* SW reset */
> - {ADV748X_PAGE_WAIT, 0x00, 0x05},/* delay 5 */
> - {ADV748X_PAGE_IO, 0x01, 0x76}, /* ADI Required Write */
> - {ADV748X_PAGE_IO, 0xf2, 0x01}, /* Enable I2C Read Auto-Increment */
> - {ADV748X_PAGE_EOR, 0xff, 0xff} /* End of register table */
> -};
> -
> /* Initialize CP Core with RGB888 format. */
> static const struct adv748x_reg_value adv748x_init_hdmi[] = {
> /* Disable chip powerdown & Enable HDMI Rx block */
> @@ -474,12 +465,33 @@ static const struct adv748x_reg_value
> adv748x_init_afe[] = {
> {ADV748X_PAGE_EOR, 0xff, 0xff} /* End of register table */
> };
>
> +static int adv748x_sw_reset(struct adv748x_state *state)
> +{
> + int ret;
> +
> + ret = io_write(state, ADV748X_IO_REG_FF, ADV748X_IO_REG_FF_MAIN_RESET);
> + if (ret)
> + return ret;
> +
> + usleep_range(5000, 6000);
> +
> + /* Disable CEC Wakeup from power-down mode */
> + ret = io_clrset(state, ADV748X_IO_REG_01, ADV748X_IO_REG_01_PWRDN_MASK,
> + ADV748X_IO_REG_01_PWRDNB);
> + if (ret)
> + return ret;
> +
> + /* Enable I2C Read Auto-Increment for consecutive reads */
> + return io_write(state, ADV748X_IO_REG_F2,
> + ADV748X_IO_REG_F2_READ_AUTO_INC);
> +}
> +
> static int adv748x_reset(struct adv748x_state *state)
> {
> int ret;
> u8 regval = 0;
>
> - ret = adv748x_write_regs(state, adv748x_sw_reset);
> + ret = adv748x_sw_reset(state);
> if (ret < 0)
> return ret;
>
> diff --git a/drivers/media/i2c/adv748x/adv748x.h
> b/drivers/media/i2c/adv748x/adv748x.h
> index b00c1995efb0..2f8d751cfbb0 100644
> --- a/drivers/media/i2c/adv748x/adv748x.h
> +++ b/drivers/media/i2c/adv748x/adv748x.h
> @@ -211,6 +211,11 @@ struct adv748x_state {
> #define ADV748X_IO_PD0x00/* power down controls
> */
> #define ADV748X_IO_PD_RX_EN BIT(6)
>
> +#define ADV748X_IO_REG_010x01/* pwrdn{2}b, prog_xtal_freq */
> +#define ADV748X_IO_REG_01_PWRDN_MASK (BIT(7) | BIT(6))
> +#define ADV748X_IO_REG_01_PWRDN2BBIT(7) /* CEC Wakeup Support */
> +#define ADV748X_IO_REG_01_PWRDNB BIT(6) /* CEC Wakeup Support */
> +
> #define ADV748X_IO_REG_040x04
> #define ADV748X_IO_REG_04_FORCE_FR BIT(0) /* Force CP free-run */
>
> @@ -229,8 +234,19 @@ struct adv748x_state {
> #define ADV748X_IO_CHIP_REV_ID_1 0xdf
> #define ADV748X_IO_CHIP_REV_ID_2 0xe0
>
> +#define ADV748X_IO_REG_F20xf2
> +#define ADV748X_IO_REG_F2_READ_AUTO_INC BIT(0)
> +
> +/* For PAGE slave address offsets */
> #define ADV748X_IO_SLAVE_ADDR_BASE 0xf2
>
> +/*
> + * The ADV748x_Recommended_Settings_PrA_2014-08-20.pdf details both 0x80 and
> + * 0xff as examples for performing a software reset.
> + */
> +#define ADV748X_IO_REG_FF0xff
> +#define ADV748X_IO_REG_FF_MAIN_RESET 0xff
> +
> /* HDMI RX Map */
> #define ADV748X_HDMI_LW1 0x07/* line width_1 */
> #define ADV748X_HDMI_LW1_VERT_FILTER BIT(7)
>
Re: [PATCH] v4l: Add support for STD ioctls on subdev nodes
On 17/05/18 04:00, Niklas Söderlund wrote:
Missing commit log.
> Signed-off-by: Niklas Söderlund
> ---
> Documentation/media/uapi/v4l/vidioc-g-std.rst| 14 ++
> Documentation/media/uapi/v4l/vidioc-querystd.rst | 11 +++
What about ENUMSTD?
Regards,
Hans
> drivers/media/v4l2-core/v4l2-subdev.c| 12
> include/uapi/linux/v4l2-subdev.h | 3 +++
> 4 files changed, 32 insertions(+), 8 deletions(-)
>
> ---
>
> Hi Hans,
>
> I have tested this on Renesas Gen3 Salvator-XS M3-N using the AFE
> subdevice from the adv748x driver together with the R-Car VIN and CSI-2
> pipeline.
>
> I wrote a prototype patch for v4l2-ctl which adds three new options
> (--get-subdev-standard, --set-subdev-standard and
> --get-subdev-detected-standard) to ease testing which I plan to submit
> after some cleanup if this patch receives positive feedback.
>
> If you or anyone else is interested in testing this patch the v4l2-utils
> prototype patches are available at
>
> git://git.ragnatech.se/v4l-utils#subdev-std
>
> Regards,
> // Niklas
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-g-std.rst
> b/Documentation/media/uapi/v4l/vidioc-g-std.rst
> index 90791ab51a5371b8..8d94f0404df270db 100644
> --- a/Documentation/media/uapi/v4l/vidioc-g-std.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-g-std.rst
> @@ -2,14 +2,14 @@
>
> .. _VIDIOC_G_STD:
>
> -
> -ioctl VIDIOC_G_STD, VIDIOC_S_STD
> -
> +**
> +ioctl VIDIOC_G_STD, VIDIOC_S_STD, VIDIOC_SUBDEV_G_STD, VIDIOC_SUBDEV_S_STD
> +**
>
> Name
>
>
> -VIDIOC_G_STD - VIDIOC_S_STD - Query or select the video standard of the
> current input
> +VIDIOC_G_STD - VIDIOC_S_STD - VIDIOC_SUBDEV_G_STD - VIDIOC_SUBDEV_S_STD -
> Query or select the video standard of the current input
>
>
> Synopsis
> @@ -21,6 +21,12 @@ Synopsis
> .. c:function:: int ioctl( int fd, VIDIOC_S_STD, const v4l2_std_id *argp )
> :name: VIDIOC_S_STD
>
> +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_G_STD, v4l2_std_id *argp )
> +:name: VIDIOC_SUBDEV_G_STD
> +
> +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_S_STD, const v4l2_std_id
> *argp )
> +:name: VIDIOC_SUBDEV_S_STD
> +
>
> Arguments
> =
> diff --git a/Documentation/media/uapi/v4l/vidioc-querystd.rst
> b/Documentation/media/uapi/v4l/vidioc-querystd.rst
> index cf40bca19b9f8665..a8385cc7481869dd 100644
> --- a/Documentation/media/uapi/v4l/vidioc-querystd.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-querystd.rst
> @@ -2,14 +2,14 @@
>
> .. _VIDIOC_QUERYSTD:
>
> -*
> -ioctl VIDIOC_QUERYSTD
> -*
> +*
> +ioctl VIDIOC_QUERYSTD, VIDIOC_SUBDEV_QUERYSTD
> +*
>
> Name
>
>
> -VIDIOC_QUERYSTD - Sense the video standard received by the current input
> +VIDIOC_QUERYSTD - VIDIOC_SUBDEV_QUERYSTD - Sense the video standard received
> by the current input
>
>
> Synopsis
> @@ -18,6 +18,9 @@ Synopsis
> .. c:function:: int ioctl( int fd, VIDIOC_QUERYSTD, v4l2_std_id *argp )
> :name: VIDIOC_QUERYSTD
>
> +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_QUERYSTD, v4l2_std_id *argp
> )
> +:name: VIDIOC_SUBDEV_QUERYSTD
> +
>
> Arguments
> =
> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
> b/drivers/media/v4l2-core/v4l2-subdev.c
> index f9eed938d3480b74..a156b1812e923721 100644
> --- a/drivers/media/v4l2-core/v4l2-subdev.c
> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> @@ -494,6 +494,18 @@ static long subdev_do_ioctl(struct file *file, unsigned
> int cmd, void *arg)
>
> case VIDIOC_SUBDEV_S_DV_TIMINGS:
> return v4l2_subdev_call(sd, video, s_dv_timings, arg);
> +
> + case VIDIOC_SUBDEV_G_STD:
> + return v4l2_subdev_call(sd, video, g_std, arg);
> +
> + case VIDIOC_SUBDEV_S_STD: {
> + v4l2_std_id *std = arg;
> +
> + return v4l2_subdev_call(sd, video, s_std, *std);
> + }
> +
> + case VIDIOC_SUBDEV_QUERYSTD:
> + return v4l2_subdev_call(sd, video, querystd, arg);
> #endif
> default:
> return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
> diff --git a/include/uapi/linux/v4l2-subdev.h
> b/include/uapi/linux/v4l2-subdev.h
> index c95a53e6743cb040..133696a1f324ffdc 100644
> --- a/include/uapi/linux/v4l2-subdev.h
> +++ b/include/uapi/linux/v4l2-subdev.h
> @@ -170,8 +170,11 @@ struct v4l2_subdev_selection {
> #define VIDIOC_SUBDEV_G_SELECTION_IOWR('V', 61, struct
> v4l2_subdev_selection)
> #define VIDIOC_SUBDEV_S_SELECTION_IOWR('V', 62, struct
> v4l2_subdev_selection)
> /* The following ioctls are identical to the ioctls in videodev2.h */
> +#
Re: [PATCH 1/2] Revert "media: rcar-vin: enable field toggle after a set number of lines for Gen3"
On 05/11/18 16:15, Niklas Söderlund wrote:
> This reverts commit 015060cb7795eac34454696cc9c9f8b76926a401.
Why? The cover letter states the reason, but it also needs to be added
here in the commit log.
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 20 +---
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index b41ba9a4a2b3ac90..ac07f99e3516a620 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -124,9 +124,7 @@
> #define VNDMR2_VPS (1 << 30)
> #define VNDMR2_HPS (1 << 29)
> #define VNDMR2_FTEV (1 << 17)
> -#define VNDMR2_FTEH (1 << 16)
> #define VNDMR2_VLV(n)((n & 0xf) << 12)
> -#define VNDMR2_HLV(n)((n) & 0xfff)
>
> /* Video n CSI2 Interface Mode Register (Gen3) */
> #define VNCSI_IFMD_DES1 (1 << 26)
> @@ -614,9 +612,8 @@ void rvin_crop_scale_comp(struct rvin_dev *vin)
>
> static int rvin_setup(struct rvin_dev *vin)
> {
> - u32 vnmc, dmr, dmr2, interrupts, lines;
> + u32 vnmc, dmr, dmr2, interrupts;
> bool progressive = false, output_is_yuv = false, input_is_yuv = false;
> - bool halfsize = false;
>
> switch (vin->format.field) {
> case V4L2_FIELD_TOP:
> @@ -631,15 +628,12 @@ static int rvin_setup(struct rvin_dev *vin)
> /* Use BT if video standard can be read and is 60 Hz format */
> if (!vin->info->use_mc && vin->std & V4L2_STD_525_60)
> vnmc = VNMC_IM_FULL | VNMC_FOC;
> - halfsize = true;
> break;
> case V4L2_FIELD_INTERLACED_TB:
> vnmc = VNMC_IM_FULL;
> - halfsize = true;
> break;
> case V4L2_FIELD_INTERLACED_BT:
> vnmc = VNMC_IM_FULL | VNMC_FOC;
> - halfsize = true;
> break;
> case V4L2_FIELD_NONE:
> vnmc = VNMC_IM_ODD_EVEN;
> @@ -682,15 +676,11 @@ static int rvin_setup(struct rvin_dev *vin)
> break;
> }
>
> - if (vin->info->model == RCAR_GEN3) {
> - /* Enable HSYNC Field Toggle mode after height HSYNC inputs. */
> - lines = vin->format.height / (halfsize ? 2 : 1);
> - dmr2 = VNDMR2_FTEH | VNDMR2_HLV(lines);
> - vin_dbg(vin, "Field Toogle after %u lines\n", lines);
> - } else {
> - /* Enable VSYNC Field Toogle mode after one VSYNC input. */
> + /* Enable VSYNC Field Toogle mode after one VSYNC input */
> + if (vin->info->model == RCAR_GEN3)
> + dmr2 = VNDMR2_FTEV;
> + else
> dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
> - }
>
> /* Hsync Signal Polarity Select */
> if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
>
Re: [PATCH 5/5] media: rcar-vin: Use FTEV for digital input
On 05/11/18 11:59, Jacopo Mondi wrote:
> Since commit (015060cb "media: rcar-vin: enable field toggle after a set
> number of lines for Gen3) the VIN generates an internal field signal
> toggle after a fixed number of received lines, and uses the internal
> field signal to drive capture operations. When capturing from digital
> input, using FTEH driven field signal toggling messes up the received
> image sizes. Fall back to use FTEV driven signal toggling when capturing
> from digital input.
>
> As explained in the comment, this disables buffer overflow protection
> for digital input capture, for which the FOE overflow might be used in
> future.
I don't know the details of the hardware, but this sounds dangerous.
You should know that with HDMI input it is perfectly possible that you get
more data than you should. I.e. instead of 1080 lines (assuming full HD)
you might get more lines. This happens if the vertical sync is missed due
to pin bounce when connecting a source.
Other reasons for this are flaky signals, bad clocks, etc.
It's rare, but it really happens.
A good DMA engine will refuse to write more than fits in the buffer.
If you disable that, then you will get overflows eventually.
The reality with HDMI input is that you should never assume clean valid
data. You do not control the source and it can send anything it likes.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index ea7a120..8dc3455 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -685,11 +685,27 @@ static int rvin_setup(struct rvin_dev *vin)
> break;
> }
>
> - if (vin->info->model == RCAR_GEN3) {
> + if (vin->info->model == RCAR_GEN3 &&
> + vin->mbus_cfg.type == V4L2_MBUS_CSI2) {
> /* Enable HSYNC Field Toggle mode after height HSYNC inputs. */
> lines = vin->format.height / (halfsize ? 2 : 1);
> dmr2 = VNDMR2_FTEH | VNDMR2_HLV(lines);
> vin_dbg(vin, "Field Toogle after %u lines\n", lines);
Typo: Toogle -> Toggle
> + } else if (vin->info->model == RCAR_GEN3 &&
> +vin->mbus_cfg.type == V4L2_MBUS_PARALLEL) {
> + /*
> + * FIXME
> + * Section 26.3.17 specifies that for digital input there's no
> + * need to program FTEH or FTEV to generate internal
> + * field toggle signal to driver capture. Although when
> + * running on GEN3 with digital input no EFE interrupt is ever
> + * generated, and we need to rely on FTEV driven field signal
> + * toggling, as using FTEH as in the CSI-2 case, messes up
> + * the output image size. This implies no protection
> + * against buffer overflow is in place for Gen3 digital input
> + * capture.
> + */
> + dmr2 = VNDMR2_FTEV;
> } else {
> /* Enable VSYNC Field Toogle mode after one VSYNC input. */
Ditto. Search and replace?
> dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
>
Regards,
Hans
Re: [PATCH v13 00/33] rcar-vin: Add Gen3 with media controller
Hi Niklas, It might be a good idea if you can rebase the patch series on the latest master (we've just synced to Linus' master tree) and incorporate the few comments that Laurent had. Then once the merge window closes I can make the pull request, probably on the 16th. Regards, Hans On 03/04/18 14:30, Hans Verkuil wrote: > On 26/03/18 23:44, Niklas Söderlund wrote: >> Hi, >> >> This series adds Gen3 VIN support to rcar-vin driver for Renesas r8a7795, >> r8a7796 and r8a77970. It is based on the media-tree and depends on >> Fabrizio Castro patches as they touches the order of the compatible >> strings in the documentation to reduce merge conflicts. The dependencies >> are included in this series. > > Laurent, Kieran, > > Unless there are any objections I want to make a pull request for this > series once 4.17-rc1 has been merged back into our master tree. It all > looks good to me, and it will be nice to get this in (finally!). > > I don't want to postpone the pull request for small improvements, they > can be applied later. But if there are more serious concerns, then let > us know. > > Regards, > > Hans > >> >> The driver is tested on Renesas H3 (r8a7795, ES2.0), >> M3-W (r8a7796) together with the rcar-csi2 driver (posted separately and >> not yet upstream) and the Salvator-X onboard ADV7482. It is also tested >> on the V3M (r8a77970) on the Eagle board together with its expansion >> board with a ADV7482 and out of tree patches for GMSL capture using the >> max9286 and rdacm20 drivers. >> >> It is possible to capture both CVBS and HDMI video streams, >> v4l2-compliance passes with no errors and media-ctl can be used to >> change the routing and formats for the different entities in the media >> graph. >> >> Gen2 compatibility is verified on Koelsch and no problems where found, >> video can be captured just like before and v4l2-compliance passes >> without errors or warnings just like before this series. >> >> For convenience the series can be fetched from: >> >> git://git.ragnatech.se/linux rcar/vin/mc-v13 >> >> I have started on a very basic test suite for the VIN driver at: >> >> https://git.ragnatech.se/vin-tests >> >> And as before the state of the driver and information about how to test >> it can be found on the elinux wiki: >> >> http://elinux.org/R-Car/Tests:rcar-vin >> >> * Changes from v12 >> - Rebase to latest media-tree/master changed a 'return ret' to a 'goto >> out' in rvin_start_streaming() to take recent changes to the VIN >> driver into account. >> - Moved field != V4L2_FIELD_ANY in 'rcar-vin: set a default field to >> fallback on' check from a later commit 'rcar-vin: simplify how formats >> are set and reset' in the series. This is to avoid ignoring the field >> returned from the sensor if FIELD_ANY was requested by the user. This >> was only a problem between this change and a few patches later, but >> better to fix it now. Reported by Hans, thanks for spotting this. >> - Fix spelling. >> - Add review tags from Hans. >> >> * Changes since v11 >> - Rewrote commit message for '[PATCH v11 22/32] rcar-vin: force default >> colorspace for media centric mode'. Also set fixed values for >> xfer_func, quantization and ycbcr_enc. >> - Reorderd filed order in struct rvin_group_route. >> - Renamed chan to channel in struct rvin_group_route. >> - Rework 'rcar-vin: read subdevice format for crop only when >> needed' into 'rcar-vin: simplify how formats are set and reset'. >> - Keep caching the source dimensions and drop all changes to >> rvin_g_selection() and rvin_s_selection(). >> - Inline rvin_get_vin_format_from_source() into rvin_reset_format() >> which now is the only user left. >> - Add patch to cache the video standard instead of reading it at stream >> on. >> - Fix error labels in rvin_mc_open(). >> - Fixed spelling in commit messages and comment, thanks Laurent! >> - Added reviewed tags from Laurent, Thanks! >> >> * Changes since v10 >> - Corrected spelling in comments and commit messages. >> - Reworked 'rcar-vin: read subdevice format for crop only when needed' >> to only get the source format once per operation. >> - Moved some patches around to make it easier to review, moved: >> - rcar-vin: set a default field to fallback on >> - rcar-vin: fix handling of single field frames (top, bottom and >> alternate fields) >>
Re: [PATCH v13 00/33] rcar-vin: Add Gen3 with media controller
On 26/03/18 23:44, Niklas Söderlund wrote: > Hi, > > This series adds Gen3 VIN support to rcar-vin driver for Renesas r8a7795, > r8a7796 and r8a77970. It is based on the media-tree and depends on > Fabrizio Castro patches as they touches the order of the compatible > strings in the documentation to reduce merge conflicts. The dependencies > are included in this series. Laurent, Kieran, Unless there are any objections I want to make a pull request for this series once 4.17-rc1 has been merged back into our master tree. It all looks good to me, and it will be nice to get this in (finally!). I don't want to postpone the pull request for small improvements, they can be applied later. But if there are more serious concerns, then let us know. Regards, Hans > > The driver is tested on Renesas H3 (r8a7795, ES2.0), > M3-W (r8a7796) together with the rcar-csi2 driver (posted separately and > not yet upstream) and the Salvator-X onboard ADV7482. It is also tested > on the V3M (r8a77970) on the Eagle board together with its expansion > board with a ADV7482 and out of tree patches for GMSL capture using the > max9286 and rdacm20 drivers. > > It is possible to capture both CVBS and HDMI video streams, > v4l2-compliance passes with no errors and media-ctl can be used to > change the routing and formats for the different entities in the media > graph. > > Gen2 compatibility is verified on Koelsch and no problems where found, > video can be captured just like before and v4l2-compliance passes > without errors or warnings just like before this series. > > For convenience the series can be fetched from: > > git://git.ragnatech.se/linux rcar/vin/mc-v13 > > I have started on a very basic test suite for the VIN driver at: > > https://git.ragnatech.se/vin-tests > > And as before the state of the driver and information about how to test > it can be found on the elinux wiki: > > http://elinux.org/R-Car/Tests:rcar-vin > > * Changes from v12 > - Rebase to latest media-tree/master changed a 'return ret' to a 'goto > out' in rvin_start_streaming() to take recent changes to the VIN > driver into account. > - Moved field != V4L2_FIELD_ANY in 'rcar-vin: set a default field to > fallback on' check from a later commit 'rcar-vin: simplify how formats > are set and reset' in the series. This is to avoid ignoring the field > returned from the sensor if FIELD_ANY was requested by the user. This > was only a problem between this change and a few patches later, but > better to fix it now. Reported by Hans, thanks for spotting this. > - Fix spelling. > - Add review tags from Hans. > > * Changes since v11 > - Rewrote commit message for '[PATCH v11 22/32] rcar-vin: force default > colorspace for media centric mode'. Also set fixed values for > xfer_func, quantization and ycbcr_enc. > - Reorderd filed order in struct rvin_group_route. > - Renamed chan to channel in struct rvin_group_route. > - Rework 'rcar-vin: read subdevice format for crop only when > needed' into 'rcar-vin: simplify how formats are set and reset'. > - Keep caching the source dimensions and drop all changes to > rvin_g_selection() and rvin_s_selection(). > - Inline rvin_get_vin_format_from_source() into rvin_reset_format() > which now is the only user left. > - Add patch to cache the video standard instead of reading it at stream > on. > - Fix error labels in rvin_mc_open(). > - Fixed spelling in commit messages and comment, thanks Laurent! > - Added reviewed tags from Laurent, Thanks! > > * Changes since v10 > - Corrected spelling in comments and commit messages. > - Reworked 'rcar-vin: read subdevice format for crop only when needed' > to only get the source format once per operation. > - Moved some patches around to make it easier to review, moved: > - rcar-vin: set a default field to fallback on > - rcar-vin: fix handling of single field frames (top, bottom and > alternate fields) > - rcar-vin: update bytesperline and sizeimage calculation > - rcar-vin: break out format alignment and checking > - rcar-vin: update pixelformat check for M1 > Before: > - rcar-vin: read subdevice format for crop only when needed > - Rename variable 'code' to 'mbus_code' in struct rvin_dev. > - Add comment describing no locking is needed in > rvin_set_channel_routing(). > - Check return value of pm_runtime_get_sync() in > rvin_set_channel_routing(). > - Rework 'rcar-vin: add check for colorspace' to not try to check the > format, instead force a default format. This should be revisited once > either v4l2-compliance or v4l2 framework changes are worked out to > allow for MC centric drivers to validate user supplied colorspace. > - Add error checking for pm_runtime_get_sync() and > v4l2_pipeline_pm_use(). > - Change mutex_lock() to mutex_lock_interruptible() in rvin_mc_open(). > - Rewrote documentation for struct rvin_group_route. > - Rename rvin_mc_parse_v4l2() to rvin_mc_parse_of_endpoint(). >
Re: [PATCH v2 1/4] media: i2c: Copy mt9t112 soc_camera sensor driver
On 03/15/2018 07:38 AM, jacopo mondi wrote: > Hi Sakari, >thanks for looking into this! > > On Thu, Mar 15, 2018 at 01:35:34PM +0200, Sakari Ailus wrote: >> Hi Jacopo, >> >> I wonder if it'd make sense to just make all the changes to the driver and >> then have it reviewed; I'm not sure the old driver can be said to have been >> in a known-good state that'd be useful to compare against. I think you did >> that with another driver as well. >> > > Well, I understand this is still debated, and I see your point. > As far as I can tell the driver had been developed to work with SH4 > Ecovec boards and there tested. > > I'm not sure I fully got you here though. Are you proposing to > squash my next patch that cleans up the driver into this one and > propose it as a completely new driver to be reviewed from scratch? > > In the two previous driver I touched in this "remove soc_camera" > journey (ov772x and tw9910) I have followed this same pattern: copy > the soc_camera driver without removing the existing one, and pile on > top my changes/cleanups in another patch. Then port the board code to > use the new sensor driver, and the new CEU driver as well. > > Also, how would you like to proceed here? Hans sent a pull request for > the series, should I go with incremental changes on top of this? I don't want to postpone this conversion. The i2c/mt9t112.c is bug-compatible with i2c/soc-camera/mt9t112.c which is good enough for me. Being able to remove soc-camera in the (hopefully very) near future is the most important thing here. Once Jacopo can actually test the sensor, then that's a good time to review the driver in more detail. This reminded me that I actually started testing this sensor a year ago (I bought the same sensor on ebay, I completely forgot about that!). My attempt is here: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=mt9t112 I never finished it because I had no documentation on the pinout and never got around to hooking my oscilloscope up to it to figure this out. I was testing this with the atmel-isc.c driver. This might be of some use to you, Jacopo, once you have the sensor. Regards, Hans
Re: [PATCH 3/3] rcar-vin: use scratch buffer and always run in continuous mode
On 03/09/2018 04:09 PM, Niklas Söderlund wrote:
> Instead of switching capture mode depending on how many buffers are
> available use a scratch buffer and always run in continuous mode. By
> using a scratch buffer the responsiveness of the capture loop is
> increased as it can keep running even if there are no buffers available
> from userspace.
>
> As soon as a userspace queues a buffer it is inserted into the capture
> loop and returned as soon as it is filled. This is a improvement on the
> previous logic where the whole capture loop was stopped and switched to
> single capture mode if userspace did not feed the VIN driver buffers at
> the same time it consumed them. To make matters worse it was difficult
> for the driver to reenter continues mode if it entered single mode even
continues -> continuous
> if userspace started to queue buffers faster. This resulted in
> suboptimal performance where if userspace where delayed for a short
> period the ongoing capture would be slowed down and run in single mode
> until the capturing process where restarted.
>
> An additional effect of this change is that the capture logic can be
> made much simple as we know that continues mode will always be used.
ditto
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 187
> -
> drivers/media/platform/rcar-vin/rcar-vin.h | 6 +-
> 2 files changed, 52 insertions(+), 141 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 8ea73cdc9a720abe..208cf8a0ea77002d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -168,12 +168,8 @@ static int rvin_setup(struct rvin_dev *vin)
> break;
> case V4L2_FIELD_ALTERNATE:
> case V4L2_FIELD_NONE:
> - if (vin->continuous) {
> - vnmc = VNMC_IM_ODD_EVEN;
> - progressive = true;
> - } else {
> - vnmc = VNMC_IM_ODD;
> - }
> + vnmc = VNMC_IM_ODD_EVEN;
> + progressive = true;
> break;
> default:
> vnmc = VNMC_IM_ODD;
> @@ -298,14 +294,6 @@ static bool rvin_capture_active(struct rvin_dev *vin)
> return rvin_read(vin, VNMS_REG) & VNMS_CA;
> }
>
> -static int rvin_get_active_slot(struct rvin_dev *vin, u32 vnms)
> -{
> - if (vin->continuous)
> - return (vnms & VNMS_FBS_MASK) >> VNMS_FBS_SHIFT;
> -
> - return 0;
> -}
> -
> static enum v4l2_field rvin_get_active_field(struct rvin_dev *vin, u32 vnms)
> {
> if (vin->format.field == V4L2_FIELD_ALTERNATE) {
> @@ -344,76 +332,47 @@ static void rvin_set_slot_addr(struct rvin_dev *vin,
> int slot, dma_addr_t addr)
> rvin_write(vin, offset, VNMB_REG(slot));
> }
>
> -/* Moves a buffer from the queue to the HW slots */
> -static bool rvin_fill_hw_slot(struct rvin_dev *vin, int slot)
> +/*
> + * Moves a buffer from the queue to the HW slot. If no buffer is
> + * available use the scratch buffer. The scratch buffer is never
> + * returned to userspace, its only function is to enable the capture
> + * loop to keep running.
> + */
> +static void rvin_fill_hw_slot(struct rvin_dev *vin, int slot)
> {
> struct rvin_buffer *buf;
> struct vb2_v4l2_buffer *vbuf;
> - dma_addr_t phys_addr_top;
> -
> - if (vin->queue_buf[slot] != NULL)
> - return true;
> + dma_addr_t phys_addr;
>
> - if (list_empty(&vin->buf_list))
> - return false;
> + /* A already populated slot shall never be overwritten. */
> + if (WARN_ON(vin->queue_buf[slot] != NULL))
> + return;
>
> vin_dbg(vin, "Filling HW slot: %d\n", slot);
>
> - /* Keep track of buffer we give to HW */
> - buf = list_entry(vin->buf_list.next, struct rvin_buffer, list);
> - vbuf = &buf->vb;
> - list_del_init(to_buf_list(vbuf));
> - vin->queue_buf[slot] = vbuf;
> -
> - /* Setup DMA */
> - phys_addr_top = vb2_dma_contig_plane_dma_addr(&vbuf->vb2_buf, 0);
> - rvin_set_slot_addr(vin, slot, phys_addr_top);
> -
> - return true;
> -}
> -
> -static bool rvin_fill_hw(struct rvin_dev *vin)
> -{
> - int slot, limit;
> -
> - limit = vin->continuous ? HW_BUFFER_NUM : 1;
> -
> - for (slot = 0; slot < limit; slot++)
> - if (!rvin_fill_hw_slot(vin, slot))
> - return false;
> - return true;
> -}
> -
> -static void rvin_capture_on(struct rvin_dev *vin)
> -{
> - vin_dbg(vin, "Capture on in %s mode\n",
> - vin->continuous ? "continuous" : "single");
> + if (list_empty(&vin->buf_list)) {
> + vin->queue_buf[slot] = NULL;
> + phys_addr = vin->scratch_phys;
> + } else {
> + /* Keep track of buffer we give to HW */
> + buf = list_entry(vin->buf_list.next, struct rvin_buffer, list);
> +
Re: [PATCH 1/3] rcar-vin: remove duplicated check of state in irq handler
On 03/09/2018 04:09 PM, Niklas Söderlund wrote:
> This is an error from when the driver where converted from soc-camera.
where -> was
> There is absolutely no gain to check the state variable two times to be
> extra sure if the hardware is stopped.
I'll wait for v2 before applying this.
Regards,
Hans
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 23fdff7a7370842e..b4be75d5009080f7 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -916,12 +916,6 @@ static irqreturn_t rvin_irq(int irq, void *data)
> rvin_ack_interrupt(vin);
> handled = 1;
>
> - /* Nothing to do if capture status is 'STOPPED' */
> - if (vin->state == STOPPED) {
> - vin_dbg(vin, "IRQ while state stopped\n");
> - goto done;
> - }
> -
> /* Nothing to do if capture status is 'STOPPING' */
> if (vin->state == STOPPING) {
> vin_dbg(vin, "IRQ while state stopping\n");
>
Re: [PATCH 0/5] Renesas CEU: SH7724 ECOVEC + Aptina mt9t112
Hi Jacopo, On 02/03/18 17:35, Jacopo Mondi wrote: > Hello, >now that CEU has been picked up for inclusion in v4.17, we can start moving > users of old sh_mobile_ceu_camera driver to use the newly introduced one. > > Migo-R has been first, now it's SH7724 ECOVEC board turn. > > ECOVEC has a camera board with two MT9T112 image sensor and one TW9910 video > decoder input. This series moves the mt9t112 driver away from soc_camera > framework and remove dependencies on it in mach-ecovec board code. > > As per Migo-R, memory for CEU is reserved using memblocks APIs and declared > as DMA-capable in board code, power up/down routines have been removed from > board code, and GPIOs lookup table registered for sensor drivers. > > As in the previous series, still no code has been removed or changed in > drivers/media/i2c/soc_camera/ until we do not remove all dependencies on it > in all board files. > > Hans, since you asked me to add frame rate interval support for ov772x I > expect > to receive the same request for mt9t112. Unfortunately I do not have access to > register level documentation, nor can perform any testing as I don't have the > camera modules. For the same reason I cannot run any v4l2-compliance test on > that driver, but just make sure the ECOVEC boots cleanly with the new board > file. I'm in favour of moving the driver to staging if you think that's the > case. > > Series based on media-tree master, and as per Migo-R I would ask SH arch/ > changes to go through media tree as SH maintainers are un-responsive. When compiling this series I get this error: drivers/media/i2c/soc_camera/mt9t112.c: In function ‘mt9t112_init_pll’: drivers/media/i2c/soc_camera/mt9t112.c:426:16: error: dereferencing pointer to incomplete type ‘struct mt9t112_camera_info’ priv->info->divider.m, ^~ Can you take a look? Regards, Hans > > Thanks > j > > Jacopo Mondi (5): > media: i2c: Copy mt9t112 soc_camera sensor driver > media: i2c: mt9t112: Remove soc_camera dependencies > media: i2c: mt9t112: Fix code style issues > arch: sh: ecovec: Use new renesas-ceu camera driver > media: MAINTAINERS: Add entry for Aptina MT9T112 > > MAINTAINERS|7 + > arch/sh/boards/mach-ecovec24/setup.c | 338 +- > arch/sh/kernel/cpu/sh4a/clock-sh7724.c |4 +- > drivers/media/i2c/Kconfig | 11 + > drivers/media/i2c/Makefile |1 + > drivers/media/i2c/mt9t112.c| 1136 > > include/media/i2c/mt9t112.h| 17 +- > 7 files changed, 1333 insertions(+), 181 deletions(-) > create mode 100644 drivers/media/i2c/mt9t112.c > > -- > 2.7.4 >
Re: [PATCH v12 11/33] rcar-vin: set a default field to fallback on
On 09/03/18 18:07, Niklas Söderlund wrote:
> Hi Hans,
>
> Thanks for your feedback.
>
> On 2018-03-09 17:28:39 +0100, Hans Verkuil wrote:
>> On 09/03/18 17:17, Niklas Söderlund wrote:
>>> Hi Hans,
>>>
>>> Thanks for your feedback, I don't think I can appreciate how happy I'm
>>> that you reviewed this patch-set, Thank you!
>>
>> You're welcome!
>>
>>>
>>> On 2018-03-09 16:25:23 +0100, Hans Verkuil wrote:
>>>> On 07/03/18 23:04, Niklas Söderlund wrote:
>>>>> If the field is not supported by the driver it should not try to keep
>>>>> the current field. Instead it should set it to a default fallback. Since
>>>>> trying a format should always result in the same state regardless of the
>>>>> current state of the device.
>>>>>
>>>>> Signed-off-by: Niklas Söderlund
>>>>> Reviewed-by: Laurent Pinchart
>>>>> ---
>>>>> drivers/media/platform/rcar-vin/rcar-v4l2.c | 9 +++--
>>>>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
>>>>> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
>>>>> index c2265324c7c96308..ebcd78b1bb6e8cb6 100644
>>>>> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
>>>>> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
>>>>> @@ -23,6 +23,7 @@
>>>>> #include "rcar-vin.h"
>>>>>
>>>>> #define RVIN_DEFAULT_FORMAT V4L2_PIX_FMT_YUYV
>>>>> +#define RVIN_DEFAULT_FIELD V4L2_FIELD_NONE
>>>>>
>>>>> /*
>>>>> -
>>>>> * Format Conversions
>>>>> @@ -143,7 +144,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
>>>>> case V4L2_FIELD_INTERLACED:
>>>>> break;
>>>>> default:
>>>>> - vin->format.field = V4L2_FIELD_NONE;
>>>>> + vin->format.field = RVIN_DEFAULT_FIELD;
>>>>> break;
>>>>> }
>>>>>
>>>>> @@ -213,10 +214,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
>>>>> u32 walign;
>>>>> int ret;
>>>>>
>>>>> - /* Keep current field if no specific one is asked for */
>>>>> - if (pix->field == V4L2_FIELD_ANY)
>>>>> - pix->field = vin->format.field;
>>>>> -
>>>>> /* If requested format is not supported fallback to the default */
>>>>> if (!rvin_format_from_pixel(pix->pixelformat)) {
>>>>> vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
>>>>> @@ -246,7 +243,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
>>>>> case V4L2_FIELD_INTERLACED:
>>>>> break;
>>>>> default:
>>>>> - pix->field = V4L2_FIELD_NONE;
>>>>> + pix->field = RVIN_DEFAULT_FIELD;
>>>>> break;
>>>>> }
>>>>>
>>>>>
>>>>
>>>> I wonder if this code is correct. What if the adv7180 is the source? Does
>>>> that even
>>>> support FIELD_NONE? I suspect that the default field should actually
>>>> depend on the
>>>> source. FIELD_NONE for dv_timings based or sensor based subdevs and
>>>> FIELD_INTERLACED
>>>> for SDTV (g/s_std) subdevs.
>>>
>>> I see what you mean but I think this is correct. The field is only set
>>> to V4L2_FIELD_NONE if the field returned from the source is not one of
>>> TOP, BOTTOM, ALTERNATE, NONE, INERLACED, INTERLACED_TB, INTERLACED_BT.
>>> So it works perfectly with the adv7180 as it will return
>>> V4L2_FIELD_INTERLACED and then VIN will accept that and not change it.
>>> So the field do depend on the source both before and after this change.
>>
>> Is it? If I pass FIELD_ANY to VIDIOC_TRY_FMT then that is passed to the
>> adv7180 via __rvin_try_format and __rvin_try_format_source. But
>> __rvin_try_format_source puts back the old field value after calling
>> set_fmt for the adv7180 (pix->field = field).
>>
>> So pix->field is still FIELD_ANY when it enters the switch and so falls
>> into the default case and it becomes
Re: [PATCH v12 11/33] rcar-vin: set a default field to fallback on
On 09/03/18 17:17, Niklas Söderlund wrote:
> Hi Hans,
>
> Thanks for your feedback, I don't think I can appreciate how happy I'm
> that you reviewed this patch-set, Thank you!
You're welcome!
>
> On 2018-03-09 16:25:23 +0100, Hans Verkuil wrote:
>> On 07/03/18 23:04, Niklas Söderlund wrote:
>>> If the field is not supported by the driver it should not try to keep
>>> the current field. Instead it should set it to a default fallback. Since
>>> trying a format should always result in the same state regardless of the
>>> current state of the device.
>>>
>>> Signed-off-by: Niklas Söderlund
>>> Reviewed-by: Laurent Pinchart
>>> ---
>>> drivers/media/platform/rcar-vin/rcar-v4l2.c | 9 +++--
>>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
>>> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
>>> index c2265324c7c96308..ebcd78b1bb6e8cb6 100644
>>> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
>>> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
>>> @@ -23,6 +23,7 @@
>>> #include "rcar-vin.h"
>>>
>>> #define RVIN_DEFAULT_FORMATV4L2_PIX_FMT_YUYV
>>> +#define RVIN_DEFAULT_FIELD V4L2_FIELD_NONE
>>>
>>> /*
>>> -
>>> * Format Conversions
>>> @@ -143,7 +144,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
>>> case V4L2_FIELD_INTERLACED:
>>> break;
>>> default:
>>> - vin->format.field = V4L2_FIELD_NONE;
>>> + vin->format.field = RVIN_DEFAULT_FIELD;
>>> break;
>>> }
>>>
>>> @@ -213,10 +214,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
>>> u32 walign;
>>> int ret;
>>>
>>> - /* Keep current field if no specific one is asked for */
>>> - if (pix->field == V4L2_FIELD_ANY)
>>> - pix->field = vin->format.field;
>>> -
>>> /* If requested format is not supported fallback to the default */
>>> if (!rvin_format_from_pixel(pix->pixelformat)) {
>>> vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
>>> @@ -246,7 +243,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
>>> case V4L2_FIELD_INTERLACED:
>>> break;
>>> default:
>>> - pix->field = V4L2_FIELD_NONE;
>>> + pix->field = RVIN_DEFAULT_FIELD;
>>> break;
>>> }
>>>
>>>
>>
>> I wonder if this code is correct. What if the adv7180 is the source? Does
>> that even
>> support FIELD_NONE? I suspect that the default field should actually depend
>> on the
>> source. FIELD_NONE for dv_timings based or sensor based subdevs and
>> FIELD_INTERLACED
>> for SDTV (g/s_std) subdevs.
>
> I see what you mean but I think this is correct. The field is only set
> to V4L2_FIELD_NONE if the field returned from the source is not one of
> TOP, BOTTOM, ALTERNATE, NONE, INERLACED, INTERLACED_TB, INTERLACED_BT.
> So it works perfectly with the adv7180 as it will return
> V4L2_FIELD_INTERLACED and then VIN will accept that and not change it.
> So the field do depend on the source both before and after this change.
Is it? If I pass FIELD_ANY to VIDIOC_TRY_FMT then that is passed to the
adv7180 via __rvin_try_format and __rvin_try_format_source. But
__rvin_try_format_source puts back the old field value after calling
set_fmt for the adv7180 (pix->field = field).
So pix->field is still FIELD_ANY when it enters the switch and so falls
into the default case and it becomes FIELD_NONE.
What's weird is the 'pix->field = field' in __rvin_try_format_source().
Could that be a bug? Without that line what you say here would be correct.
Regards,
Hans
>
> This check is just to block the driver reporting SEQ_TB/BT if a source
> where to report that (I known of no source who reports that) to
> userspace as the driver do not yet support this. I have patches to add
> support for this but I will keep them back until this series are picked
> up :-)
>
>>
>> I might very well be missing something here but it looks suspicious.
>>
>> Regards,
>>
>> Hans
>
Re: [PATCH v12 33/33] rcar-vin: enable support for r8a77970
On 07/03/18 23:05, Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a77970.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 0040f92bfdff947a..a7e65c720f2c191b 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -971,6 +971,25 @@ static const struct rvin_info rcar_info_r8a7796 = {
> .routes = rcar_info_r8a7796_routes,
> };
>
> +static const struct rvin_group_route _rcar_info_r8a77970_routes[] = {
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 0, .mask = BIT(0) | BIT(3) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 1, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 1, .mask = BIT(3) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 2, .mask = BIT(1) },
> + { .csi = RVIN_CSI40, .channel = 2, .vin = 2, .mask = BIT(3) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 3, .mask = BIT(0) },
> + { .csi = RVIN_CSI40, .channel = 3, .vin = 3, .mask = BIT(3) },
> + { /* Sentinel */ }
> +};
> +
> +static const struct rvin_info rcar_info_r8a77970 = {
> + .model = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> + .routes = _rcar_info_r8a77970_routes,
> +};
> +
> static const struct of_device_id rvin_of_id_table[] = {
> {
> .compatible = "renesas,vin-r8a7778",
> @@ -1008,6 +1027,10 @@ static const struct of_device_id rvin_of_id_table[] = {
> .compatible = "renesas,vin-r8a7796",
> .data = &rcar_info_r8a7796,
> },
> + {
> + .compatible = "renesas,vin-r8a77970",
> + .data = &rcar_info_r8a77970,
> + },
> { /* Sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, rvin_of_id_table);
>
Re: [PATCH v12 31/33] rcar-vin: enable support for r8a7795
On 07/03/18 23:05, Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a7795 ES1.x and ES2.0.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/Kconfig | 2 +-
> drivers/media/platform/rcar-vin/rcar-core.c | 120
>
> 2 files changed, 121 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/rcar-vin/Kconfig
> b/drivers/media/platform/rcar-vin/Kconfig
> index af4c98b44d2e22cb..8fa7ee468c63afb9 100644
> --- a/drivers/media/platform/rcar-vin/Kconfig
> +++ b/drivers/media/platform/rcar-vin/Kconfig
> @@ -6,7 +6,7 @@ config VIDEO_RCAR_VIN
> select V4L2_FWNODE
> ---help---
> Support for Renesas R-Car Video Input (VIN) driver.
> - Supports R-Car Gen2 SoCs.
> + Supports R-Car Gen2 and Gen3 SoCs.
>
> To compile this driver as a module, choose M here: the
> module will be called rcar-vin.
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index a1c441c1a314feb7..bc116cc0181171e0 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -832,6 +833,104 @@ static const struct rvin_info rcar_info_gen2 = {
> .max_height = 2048,
> };
>
> +static const struct rvin_group_route rcar_info_r8a7795_routes[] = {
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 0, .mask = BIT(0) | BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 0, .mask = BIT(1) | BIT(4) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 0, .mask = BIT(2) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 1, .mask = BIT(0) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 1, .mask = BIT(1) | BIT(3) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 1, .mask = BIT(2) },
> + { .csi = RVIN_CSI20, .channel = 1, .vin = 1, .mask = BIT(4) },
> + { .csi = RVIN_CSI20, .channel = 1, .vin = 2, .mask = BIT(0) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 2, .mask = BIT(1) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 2, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 2, .vin = 2, .mask = BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 2, .vin = 2, .mask = BIT(4) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 3, .mask = BIT(0) },
> + { .csi = RVIN_CSI20, .channel = 1, .vin = 3, .mask = BIT(1) | BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 3, .vin = 3, .mask = BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 3, .vin = 3, .mask = BIT(4) },
> + { .csi = RVIN_CSI41, .channel = 0, .vin = 4, .mask = BIT(0) | BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 4, .mask = BIT(1) | BIT(4) },
> + { .csi = RVIN_CSI41, .channel = 1, .vin = 4, .mask = BIT(2) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 5, .mask = BIT(0) },
> + { .csi = RVIN_CSI41, .channel = 1, .vin = 5, .mask = BIT(1) | BIT(3) },
> + { .csi = RVIN_CSI41, .channel = 0, .vin = 5, .mask = BIT(2) },
> + { .csi = RVIN_CSI20, .channel = 1, .vin = 5, .mask = BIT(4) },
> + { .csi = RVIN_CSI20, .channel = 1, .vin = 6, .mask = BIT(0) },
> + { .csi = RVIN_CSI41, .channel = 0, .vin = 6, .mask = BIT(1) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 6, .mask = BIT(2) },
> + { .csi = RVIN_CSI41, .channel = 2, .vin = 6, .mask = BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 2, .vin = 6, .mask = BIT(4) },
> + { .csi = RVIN_CSI41, .channel = 1, .vin = 7, .mask = BIT(0) },
> + { .csi = RVIN_CSI20, .channel = 1, .vin = 7, .mask = BIT(1) | BIT(2) },
> + { .csi = RVIN_CSI41, .channel = 3, .vin = 7, .mask = BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 3, .vin = 7, .mask = BIT(4) },
> + { /* Sentinel */ }
> +};
> +
> +static const struct rvin_info rcar_info_r8a7795 = {
> + .model = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> + .routes = rcar_info_r8a7795_routes,
> +};
> +
> +static const struct rvin_group_route rcar_info_r8a7795es1_routes[] = {
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 0, .mask = BIT(0) | BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 0, .mask = BIT(1) | BIT(4) },
> + { .csi = RVIN_CSI21, .channel = 0, .vin = 0, .mask = BIT(2) | BIT(5) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 1, .mask = BIT(0) },
> + { .csi = RVIN_CSI21, .channel = 0, .vin = 1, .mask = BIT(1) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 1, .mask = BIT(2) },
> + { .csi = RV
Re: [PATCH v12 32/33] rcar-vin: enable support for r8a7796
On 07/03/18 23:05, Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a7796.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 44
> +
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index bc116cc0181171e0..0040f92bfdff947a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -931,6 +931,46 @@ static const struct rvin_info rcar_info_r8a7795es1 = {
> .routes = rcar_info_r8a7795es1_routes,
> };
>
> +static const struct rvin_group_route rcar_info_r8a7796_routes[] = {
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 0, .mask = BIT(0) | BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 0, .mask = BIT(1) | BIT(4) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 1, .mask = BIT(0) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 1, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 1, .mask = BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 1, .vin = 1, .mask = BIT(4) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 2, .mask = BIT(1) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 2, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 2, .vin = 2, .mask = BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 2, .vin = 2, .mask = BIT(4) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 3, .mask = BIT(0) },
> + { .csi = RVIN_CSI20, .channel = 1, .vin = 3, .mask = BIT(1) },
> + { .csi = RVIN_CSI40, .channel = 3, .vin = 3, .mask = BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 3, .vin = 3, .mask = BIT(4) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 4, .mask = BIT(0) | BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 4, .mask = BIT(1) | BIT(4) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 5, .mask = BIT(0) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 5, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 5, .mask = BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 1, .vin = 5, .mask = BIT(4) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 6, .mask = BIT(1) },
> + { .csi = RVIN_CSI20, .channel = 0, .vin = 6, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 2, .vin = 6, .mask = BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 2, .vin = 6, .mask = BIT(4) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 7, .mask = BIT(0) },
> + { .csi = RVIN_CSI20, .channel = 1, .vin = 7, .mask = BIT(1) },
> + { .csi = RVIN_CSI40, .channel = 3, .vin = 7, .mask = BIT(3) },
> + { .csi = RVIN_CSI20, .channel = 3, .vin = 7, .mask = BIT(4) },
> + { /* Sentinel */ }
> +};
> +
> +static const struct rvin_info rcar_info_r8a7796 = {
> + .model = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> + .routes = rcar_info_r8a7796_routes,
> +};
> +
> static const struct of_device_id rvin_of_id_table[] = {
> {
> .compatible = "renesas,vin-r8a7778",
> @@ -964,6 +1004,10 @@ static const struct of_device_id rvin_of_id_table[] = {
> .compatible = "renesas,vin-r8a7795",
> .data = &rcar_info_r8a7795,
> },
> + {
> + .compatible = "renesas,vin-r8a7796",
> + .data = &rcar_info_r8a7796,
> + },
> { /* Sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, rvin_of_id_table);
>
Re: [PATCH v12 30/33] rcar-vin: extend {start,stop}_streaming to work with media controller
On 07/03/18 23:05, Niklas Söderlund wrote:
> The procedure to start or stop streaming using the non-MC single
> subdevice and the MC graph and multiple subdevices are quite different.
> Create a new function to abstract which method is used based on which
> mode the driver is running in and add logic to start the MC graph.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 133
> +++--
> 1 file changed, 126 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index da113531f0ce7dc0..580b286acbf2dab6 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1082,15 +1082,136 @@ static void rvin_buffer_queue(struct vb2_buffer *vb)
> spin_unlock_irqrestore(&vin->qlock, flags);
> }
>
> +static int rvin_mc_validate_format(struct rvin_dev *vin, struct v4l2_subdev
> *sd,
> +struct media_pad *pad)
> +{
> + struct v4l2_subdev_format fmt = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> +
> + fmt.pad = pad->index;
> + if (v4l2_subdev_call(sd, pad, get_fmt, NULL, &fmt))
> + return -EPIPE;
> +
> + switch (fmt.format.code) {
> + case MEDIA_BUS_FMT_YUYV8_1X16:
> + case MEDIA_BUS_FMT_UYVY8_2X8:
> + case MEDIA_BUS_FMT_UYVY10_2X10:
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + vin->mbus_code = fmt.format.code;
> + break;
> + default:
> + return -EPIPE;
> + }
> +
> + switch (fmt.format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + case V4L2_FIELD_SEQ_TB:
> + case V4L2_FIELD_SEQ_BT:
> + /* Supported natively */
> + break;
> + case V4L2_FIELD_ALTERNATE:
> + switch (vin->format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + break;
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + case V4L2_FIELD_SEQ_TB:
> + case V4L2_FIELD_SEQ_BT:
> + /* Use VIN hardware to combine the two fields */
> + fmt.format.height *= 2;
> + break;
> + default:
> + return -EPIPE;
> + }
> + break;
> + default:
> + return -EPIPE;
> + }
> +
> + if (fmt.format.width != vin->format.width ||
> + fmt.format.height != vin->format.height ||
> + fmt.format.code != vin->mbus_code)
> + return -EPIPE;
> +
> + return 0;
> +}
> +
> +static int rvin_set_stream(struct rvin_dev *vin, int on)
> +{
> + struct media_pipeline *pipe;
> + struct media_device *mdev;
> + struct v4l2_subdev *sd;
> + struct media_pad *pad;
> + int ret;
> +
> + /* No media controller used, simply pass operation to subdevice. */
> + if (!vin->info->use_mc) {
> + ret = v4l2_subdev_call(vin->digital->subdev, video, s_stream,
> +on);
> +
> + return ret == -ENOIOCTLCMD ? 0 : ret;
> + }
> +
> + pad = media_entity_remote_pad(&vin->pad);
> + if (!pad)
> + return -EPIPE;
> +
> + sd = media_entity_to_v4l2_subdev(pad->entity);
> +
> + if (!on) {
> + media_pipeline_stop(&vin->vdev.entity);
> + return v4l2_subdev_call(sd, video, s_stream, 0);
> + }
> +
> + ret = rvin_mc_validate_format(vin, sd, pad);
> + if (ret)
> + return ret;
> +
> + /*
> + * The graph lock needs to be taken to protect concurrent
> + * starts of multiple VIN instances as they might share
> + * a common subdevice down the line and then should use
> + * the same pipe.
> + */
> + mdev = vin->vdev.entity.graph_obj.mdev;
> + mutex_lock(&mdev->graph_mutex);
> + pipe = sd->entity.pipe ? sd->entity.pipe : &vin->vdev.pipe;
> + ret = __media_pipeline_start(&vin->vdev.entity, pipe);
> + mutex_unlock(&mdev->graph_mutex);
> + if (ret)
Re: [PATCH v12 29/33] rcar-vin: add link notify for Gen3
On 07/03/18 23:05, Niklas Söderlund wrote:
> Add the ability to process media device link change requests. Link
> enabling is a bit complicated on Gen3, whether or not it's possible to
> enable a link depends on what other links already are enabled. On Gen3
> the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a
> routing perspective these two groups are independent of each other.
> Each subgroup's routing is controlled by the subgroup VIN master
> instance (VIN0 and VIN4).
>
> There are a limited number of possible route setups available for each
> subgroup and the configuration of each setup is dictated by the
> hardware. On H3 for example there are 6 possible route setups for each
> subgroup to choose from.
>
> This leads to the media device link notification code being rather large
> since it will find the best routing configuration to try and accommodate
> as many links as possible. When it's not possible to enable a new link
> due to hardware constrains the link_notifier callback will return
> -EMLINK.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Regards,
Hans
>
> ---
>
> * Changes since v11
> - Fixed spelling
> - Updated comment to clarify the intent that no link can be enabled if
> any video node is open.
> - Use container_of() instead of a loop to find struct vin_dev from the
> video device.
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 147
>
> 1 file changed, 147 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 52fad495533bc427..a1c441c1a314feb7 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -24,6 +24,7 @@
>
> #include
> #include
> +#include
>
> #include "rcar-vin.h"
>
> @@ -44,6 +45,151 @@
> */
> #define rvin_group_id_to_master(vin) ((vin) < 4 ? 0 : 4)
>
> +/*
> -
> + * Media Controller link notification
> + */
> +
> +/* group lock should be held when calling this function. */
> +static int rvin_group_entity_to_csi_id(struct rvin_group *group,
> +struct media_entity *entity)
> +{
> + struct v4l2_subdev *sd;
> + unsigned int i;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + for (i = 0; i < RVIN_CSI_MAX; i++)
> + if (group->csi[i].subdev == sd)
> + return i;
> +
> + return -ENODEV;
> +}
> +
> +static unsigned int rvin_group_get_mask(struct rvin_dev *vin,
> + enum rvin_csi_id csi_id,
> + unsigned char channel)
> +{
> + const struct rvin_group_route *route;
> + unsigned int mask = 0;
> +
> + for (route = vin->info->routes; route->mask; route++) {
> + if (route->vin == vin->id &&
> + route->csi == csi_id &&
> + route->channel == channel) {
> + vin_dbg(vin,
> + "Adding route: vin: %d csi: %d channel: %d\n",
> + route->vin, route->csi, route->channel);
> + mask |= route->mask;
> + }
> + }
> +
> + return mask;
> +}
> +
> +/*
> + * Link setup for the links between a VIN and a CSI-2 receiver is a bit
> + * complex. The reason for this is that the register controlling routing
> + * is not present in each VIN instance. There are special VINs which
> + * control routing for themselves and other VINs. There are not many
> + * different possible links combinations that can be enabled at the same
> + * time, therefor all already enabled links which are controlled by a
> + * master VIN need to be taken into account when making the decision
> + * if a new link can be enabled or not.
> + *
> + * 1. Find out which VIN the link the user tries to enable is connected to.
> + * 2. Lookup which master VIN controls the links for this VIN.
> + * 3. Start with a bitmask with all bits set.
> + * 4. For each previously enabled link from the master VIN bitwise AND its
> + *route mask (see documentation for mask in struct rvin_group_route)
> + *with the bitmask.
> + * 5. Bitwise AND the mask for the link the user tries to enable to the
> bitmask.
> + * 6. If the bitmask is not empty at this point the new link can be enabled
> + *while keeping all previous links enabled. Update the CHSEL value of the
> +
Re: [PATCH v12 28/33] rcar-vin: parse Gen3 OF and setup media graph
On 07/03/18 23:05, Niklas Söderlund wrote:
> The parsing and registering CSI-2 subdevices with the v4l2 async
> framework is a collaborative effort shared between the VIN instances
> which are part of the group. When the last VIN in the group is probed it
> asks all other VINs to parse its share of OF and record the async
> subdevices it finds in the notifier belonging to the last probed VIN.
>
> Once all CSI-2 subdevices in this notifier are bound proceed to register
> all VIN video devices of the group and crate media device links between
> all CSI-2 and VIN entities according to the SoC specific routing
> configuration.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 246
> +++-
> drivers/media/platform/rcar-vin/rcar-vin.h | 12 +-
> 2 files changed, 254 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index fd4478095ac4e5b1..52fad495533bc427 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -27,6 +27,23 @@
>
> #include "rcar-vin.h"
>
> +/*
> + * The companion CSI-2 receiver driver (rcar-csi2) is known
> + * and we know it has one source pad (pad 0) and four sink
> + * pads (pad 1-4). So to translate a pad on the remote
> + * CSI-2 receiver to/from the VIN internal channel number simply
> + * subtract/add one from the pad/channel number.
> + */
> +#define rvin_group_csi_pad_to_channel(pad) ((pad) - 1)
> +#define rvin_group_csi_channel_to_pad(channel) ((channel) + 1)
> +
> +/*
> + * Not all VINs are created equal, master VINs control the
> + * routing for other VIN's. We can figure out which VIN is
> + * master by looking at a VINs id.
> + */
> +#define rvin_group_id_to_master(vin) ((vin) < 4 ? 0 : 4)
> +
> /*
> -
> * Gen3 CSI2 Group Allocator
> */
> @@ -409,6 +426,216 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
> return 0;
> }
>
> +/*
> -
> + * Group async notifier
> + */
> +
> +static int rvin_group_notify_complete(struct v4l2_async_notifier *notifier)
> +{
> + struct rvin_dev *vin = notifier_to_vin(notifier);
> + const struct rvin_group_route *route;
> + unsigned int i;
> + int ret;
> +
> + ret = v4l2_device_register_subdev_nodes(&vin->v4l2_dev);
> + if (ret) {
> + vin_err(vin, "Failed to register subdev nodes\n");
> + return ret;
> + }
> +
> + /* Register all video nodes for the group. */
> + for (i = 0; i < RCAR_VIN_NUM; i++) {
> + if (vin->group->vin[i]) {
> + ret = rvin_v4l2_register(vin->group->vin[i]);
> + if (ret)
> + return ret;
> + }
> + }
> +
> + /* Create all media device links between VINs and CSI-2's. */
> + mutex_lock(&vin->group->lock);
> + for (route = vin->info->routes; route->mask; route++) {
> + struct media_pad *source_pad, *sink_pad;
> + struct media_entity *source, *sink;
> + unsigned int source_idx;
> +
> + /* Check that VIN is part of the group. */
> + if (!vin->group->vin[route->vin])
> + continue;
> +
> + /* Check that VIN' master is part of the group. */
> + if (!vin->group->vin[rvin_group_id_to_master(route->vin)])
> + continue;
> +
> + /* Check that CSI-2 is part of the group. */
> + if (!vin->group->csi[route->csi].subdev)
> + continue;
> +
> + source = &vin->group->csi[route->csi].subdev->entity;
> + source_idx = rvin_group_csi_channel_to_pad(route->channel);
> + source_pad = &source->pads[source_idx];
> +
> + sink = &vin->group->vin[route->vin]->vdev.entity;
> + sink_pad = &sink->pads[0];
> +
> + /* Skip if link already exists. */
> + if (media_entity_find_link(source_pad, sink_pad))
> + continue;
> +
> + ret = media_create_pad_link(source, source_idx, sink, 0, 0);
> + if (ret) {
> + vin_err(vin, "
Re: [PATCH v12 27/33] rcar-vin: add chsel information to rvin_info
On 07/03/18 23:05, 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
Reviewed-by: Hans Verkuil
Regards,
Hans
>
> ---
>
> * Changes since v11
> - Fixed spelling.
> - Reorderd filed order in struct rvin_group_route.
> - Renamed chan to channel in struct rvin_group_route.
> ---
> 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 d64cbb5716ab6f6a..9a68a5909fe07ec7 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
> + *
> + * @csi: CSI-2 receiver ID.
> + * @channel: Output channel of the CSI-2 receiver.
> + * @vin: VIN ID.
> + * @mask:Bitmask of the different CHSEL register values that
> + * allow for a route from @csi + @chan to @vin.
> + *
> + * .. 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 is no correlation between channel number and CSI-2 VC. It's
> + * 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 + @channel to @vin. For example
> + * on R-Car H3 both the CHSEL values 0 and 3 allow for a route from
> + * 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 {
> + enum rvin_csi_id csi;
> + unsigned int channel;
> + unsigned int vin;
> + unsigned int 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;
> };
>
> /**
>
Re: [PATCH v12 26/33] rcar-vin: change name of video device
On 07/03/18 23:05, Niklas Söderlund wrote: > The rcar-vin driver needs to be part of a media controller to support > Gen3. Give each VIN instance a unique name so it can be referenced from > userspace. > > Signed-off-by: Niklas Söderlund > Reviewed-by: Laurent Pinchart Reviewed-by: Hans Verkuil Regards, Hans > --- > drivers/media/platform/rcar-vin/rcar-v4l2.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c > b/drivers/media/platform/rcar-vin/rcar-v4l2.c > index ea0759a645e49490..7c10557d965ea6ed 100644 > --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c > +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c > @@ -993,7 +993,7 @@ int rvin_v4l2_register(struct rvin_dev *vin) > /* video node */ > vdev->v4l2_dev = &vin->v4l2_dev; > vdev->queue = &vin->queue; > - strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name)); > + snprintf(vdev->name, sizeof(vdev->name), "VIN%u output", vin->id); > vdev->release = video_device_release_empty; > vdev->lock = &vin->lock; > vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | >
Re: [PATCH v12 25/33] rcar-vin: add group allocator functions
On 07/03/18 23:05, Niklas Söderlund wrote:
> In media controller mode all VIN instances needs to be part of the same
> media graph. There is also a need for each VIN instance to know about
> and in some cases be able to communicate with other VIN instances.
>
> Add an allocator framework where the first VIN instance to be probed
> creates a shared data structure and registers a media device.
> Consecutive VINs insert themself into the global group.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 174
> +++-
> drivers/media/platform/rcar-vin/rcar-vin.h | 31 +
> 2 files changed, 203 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 592dbd8642361f1e..fd4478095ac4e5b1 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -20,12 +20,174 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
>
> #include "rcar-vin.h"
>
> +/*
> -
> + * Gen3 CSI2 Group Allocator
> + */
> +
> +/* FIXME: This should if we find a system that supports more
> + * than one group for the whole system be replaced with a linked
> + * list of groups. And eventually all of this should be replaced
> + * with a global device allocator API.
> + *
> + * But for now this works as on all supported systems there will
> + * be only one group for all instances.
> + */
> +
> +static DEFINE_MUTEX(rvin_group_lock);
> +static struct rvin_group *rvin_group_data;
> +
> +static void rvin_group_cleanup(struct rvin_group *group)
> +{
> + media_device_unregister(&group->mdev);
> + media_device_cleanup(&group->mdev);
> + mutex_destroy(&group->lock);
> +}
> +
> +static int rvin_group_init(struct rvin_group *group, struct rvin_dev *vin)
> +{
> + struct media_device *mdev = &group->mdev;
> + const struct of_device_id *match;
> + struct device_node *np;
> + int ret;
> +
> + mutex_init(&group->lock);
> +
> + /* Count number of VINs in the system */
> + group->count = 0;
> + for_each_matching_node(np, vin->dev->driver->of_match_table)
> + if (of_device_is_available(np))
> + group->count++;
> +
> + vin_dbg(vin, "found %u enabled VIN's in DT", group->count);
> +
> + mdev->dev = vin->dev;
> +
> + match = of_match_node(vin->dev->driver->of_match_table,
> + vin->dev->of_node);
> +
> + strlcpy(mdev->driver_name, KBUILD_MODNAME, sizeof(mdev->driver_name));
> + strlcpy(mdev->model, match->compatible, sizeof(mdev->model));
> + snprintf(mdev->bus_info, sizeof(mdev->bus_info), "platform:%s",
> + dev_name(mdev->dev));
> +
> + media_device_init(mdev);
> +
> + ret = media_device_register(&group->mdev);
> + if (ret)
> + rvin_group_cleanup(group);
> +
> + return ret;
> +}
> +
> +static void rvin_group_release(struct kref *kref)
> +{
> + struct rvin_group *group =
> + container_of(kref, struct rvin_group, refcount);
> +
> + mutex_lock(&rvin_group_lock);
> +
> + rvin_group_data = NULL;
> +
> + rvin_group_cleanup(group);
> +
> + kfree(group);
> +
> + mutex_unlock(&rvin_group_lock);
> +}
> +
> +static int rvin_group_get(struct rvin_dev *vin)
> +{
> + struct rvin_group *group;
> + u32 id;
> + int ret;
> +
> + /* Make sure VIN id is present and sane */
> + ret = of_property_read_u32(vin->dev->of_node, "renesas,id", &id);
> + if (ret) {
> + vin_err(vin, "%pOF: No renesas,id property found\n",
> + vin->dev->of_node);
> + return -EINVAL;
> + }
> +
> + if (id >= RCAR_VIN_NUM) {
> + vin_err(vin, "%pOF: Invalid renesas,id '%u'\n",
> + vin->dev->of_node, id);
> + return -EINVAL;
> + }
> +
> + /* Join or create a VIN group */
> + mutex_lock(&rvin_group_lock);
> + if (rvin_group_data) {
> + group = rvin_group_data;
> + kref_get(&group->refcount);
> + } else {
> + g
Re: [PATCH v12 20/33] rcar-vin: add function to manipulate Gen3 chsel value
On 07/03/18 23:04, Niklas Söderlund wrote:
> On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
> feature of this register is that it's only present in the VIN0 and VIN4
> instances. The register in VIN0 controls the routing for VIN0-3 and the
> register in VIN4 controls routing for VIN4-7.
>
> To be able to control routing from a media device this function is need
> to control runtime PM for the subgroup master (VIN0 and VIN4). The
> subgroup master must be switched on before the register is manipulated,
> once the operation is complete it's safe to switch the master off and
> the new routing will still be in effect.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 38
> ++
> drivers/media/platform/rcar-vin/rcar-vin.h | 2 ++
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 483d31f07b934929..75382ee0f3fc1dde 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -16,6 +16,7 @@
>
> #include
> #include
> +#include
>
> #include
>
> @@ -1224,3 +1225,40 @@ int rvin_dma_register(struct rvin_dev *vin, int irq)
>
> return ret;
> }
> +
> +/*
> -
> + * Gen3 CHSEL manipulation
> + */
> +
> +/*
> + * There is no need to have locking around changing the routing
> + * as it's only possible to do so when no VIN in the group is
> + * streaming so nothing can race with the VNMC register.
> + */
> +int rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel)
> +{
> + u32 ifmd, vnmc;
> + int ret;
> +
> + ret = pm_runtime_get_sync(vin->dev);
> + if (ret < 0)
> + return ret;
> +
> + /* Make register writes take effect immediately. */
> + vnmc = rvin_read(vin, VNMC_REG);
> + rvin_write(vin, vnmc & ~VNMC_VUP, VNMC_REG);
> +
> + ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
> + VNCSI_IFMD_CSI_CHSEL(chsel);
> +
> + rvin_write(vin, ifmd, VNCSI_IFMD_REG);
> +
> + vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
> +
> + /* Restore VNMC. */
> + rvin_write(vin, vnmc, VNMC_REG);
> +
> + pm_runtime_put(vin->dev);
> +
> + return ret;
> +}
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 5e3ea8d401d934d1..8e20455927fe5224 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -169,4 +169,6 @@ const struct rvin_video_format
> *rvin_format_from_pixel(u32 pixelformat);
> /* Cropping, composing and scaling */
> void rvin_crop_scale_comp(struct rvin_dev *vin);
>
> +int rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel);
> +
> #endif
>
Re: [PATCH v12 23/33] rcar-vin: force default colorspace for media centric mode
On 07/03/18 23:05, Niklas Söderlund wrote:
> The V4L2 specification clearly documents the colorspace fields as being
> set by drivers for capture devices. Using the values supplied by
> userspace thus wouldn't comply with the API. Until the API is updated to
> allow for userspace to set these Hans wants the fields to be set by the
> driver to fixed values.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 2280535ca981993f..ea0759a645e49490 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -664,12 +664,29 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
> * V4L2 Media Controller
> */
>
> +static int rvin_mc_try_format(struct rvin_dev *vin, struct v4l2_pix_format
> *pix)
> +{
> + /*
> + * The V4L2 specification clearly documents the colorspace fields
> + * as being set by drivers for capture devices. Using the values
> + * supplied by userspace thus wouldn't comply with the API. Until
> + * the API is updated force fixed vaules.
> + */
> + pix->colorspace = RVIN_DEFAULT_COLORSPACE;
> + pix->xfer_func = V4L2_MAP_XFER_FUNC_DEFAULT(pix->colorspace);
> + pix->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(pix->colorspace);
> + pix->quantization = V4L2_MAP_QUANTIZATION_DEFAULT(true, pix->colorspace,
> + pix->ycbcr_enc);
> +
> + return rvin_format_align(vin, pix);
> +}
> +
> static int rvin_mc_try_fmt_vid_cap(struct file *file, void *priv,
> struct v4l2_format *f)
> {
> struct rvin_dev *vin = video_drvdata(file);
>
> - return rvin_format_align(vin, &f->fmt.pix);
> + return rvin_mc_try_format(vin, &f->fmt.pix);
> }
>
> static int rvin_mc_s_fmt_vid_cap(struct file *file, void *priv,
> @@ -681,7 +698,7 @@ static int rvin_mc_s_fmt_vid_cap(struct file *file, void
> *priv,
> if (vb2_is_busy(&vin->queue))
> return -EBUSY;
>
> - ret = rvin_format_align(vin, &f->fmt.pix);
> + ret = rvin_mc_try_format(vin, &f->fmt.pix);
> if (ret)
> return ret;
>
>
Re: [PATCH v12 17/33] rcar-vin: cache video standard
On 07/03/18 23:04, Niklas Söderlund wrote:
> At stream on time the driver should not query the subdevice for which
> standard are used. Instead it should be cached when userspace sets the
> standard and used at stream on time.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 6 ++
> drivers/media/platform/rcar-vin/rcar-dma.c | 7 ++-
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 10 --
> drivers/media/platform/rcar-vin/rcar-vin.h | 2 ++
> 4 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index cc863e4ec9a4d4b3..ae0339d4ec104e8c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -96,6 +96,12 @@ static int rvin_digital_subdevice_attach(struct rvin_dev
> *vin,
> if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
> return ret;
>
> + /* Read standard */
> + vin->std = V4L2_STD_UNKNOWN;
> + ret = v4l2_subdev_call(subdev, video, g_std, &vin->std);
> + if (ret < 0 && ret != -ENOIOCTLCMD)
> + return ret;
> +
> /* Add the controls */
> ret = v4l2_ctrl_handler_init(&vin->ctrl_handler, 16);
> if (ret < 0)
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index c8831e189d362c8b..7c64f1f8ec63bcf4 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -592,7 +592,6 @@ void rvin_crop_scale_comp(struct rvin_dev *vin)
> static int rvin_setup(struct rvin_dev *vin)
> {
> u32 vnmc, dmr, dmr2, interrupts;
> - v4l2_std_id std;
> bool progressive = false, output_is_yuv = false, input_is_yuv = false;
>
> switch (vin->format.field) {
> @@ -606,10 +605,8 @@ static int rvin_setup(struct rvin_dev *vin)
> /* Default to TB */
> vnmc = VNMC_IM_FULL;
> /* Use BT if video standard can be read and is 60 Hz format */
> - if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, &std)) {
> - if (std & V4L2_STD_525_60)
> - vnmc = VNMC_IM_FULL | VNMC_FOC;
> - }
> + if (vin->std & V4L2_STD_525_60)
> + vnmc = VNMC_IM_FULL | VNMC_FOC;
> break;
> case V4L2_FIELD_INTERLACED_TB:
> vnmc = VNMC_IM_FULL;
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index c4be0bcb8b16f941..43370c57d4b6239a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -477,6 +477,8 @@ static int rvin_s_std(struct file *file, void *priv,
> v4l2_std_id a)
> if (ret < 0)
> return ret;
>
> + vin->std = a;
> +
> /* Changing the standard will change the width/height */
> return rvin_reset_format(vin);
> }
> @@ -484,9 +486,13 @@ static int rvin_s_std(struct file *file, void *priv,
> v4l2_std_id a)
> static int rvin_g_std(struct file *file, void *priv, v4l2_std_id *a)
> {
> struct rvin_dev *vin = video_drvdata(file);
> - struct v4l2_subdev *sd = vin_to_source(vin);
>
> - return v4l2_subdev_call(sd, video, g_std, a);
> + if (v4l2_subdev_has_op(vin_to_source(vin), pad, dv_timings_cap))
> + return -ENOIOCTLCMD;
> +
> + *a = vin->std;
> +
> + return 0;
> }
>
> static int rvin_subscribe_event(struct v4l2_fh *fh,
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 7fcf984f21466855..458373af9e60ea07 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -119,6 +119,7 @@ struct rvin_info {
> * @crop:active cropping
> * @compose: active composing
> * @source: active size of the video source
> + * @std: active video standard of the video source
> */
> struct rvin_dev {
> struct device *dev;
> @@ -146,6 +147,7 @@ struct rvin_dev {
> struct v4l2_rect crop;
> struct v4l2_rect compose;
> struct v4l2_rect source;
> + v4l2_std_id std;
> };
>
> #define vin_to_source(vin) ((vin)->digital->subdev)
>
Re: [PATCH v12 16/33] rcar-vin: simplify how formats are set and reset
On 07/03/18 23:04, Niklas Söderlund wrote:
> With the recent cleanup of the format code to prepare for Gen3 it's
> possible to simplify the Gen2 format code path as well. Clean up the
> process by defining two functions to handle the set format and reset of
> format when the standard is changed.
>
> While at it replace the driver local struct rvin_source_fmt with a
> struct v4l2_rect as all it's used for is keep track of the source
> dimensions.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Regards,
Hans
>
> ---
>
> * Changes since v11
> - This patch where 'rcar-vin: read subdevice format for crop only when
> needed'
> - Keep caching the source dimensions and drop all changes to
> rvin_g_selection() and rvin_s_selection().
> - Inline rvin_get_vin_format_from_source() into rvin_reset_format()
> which now is the only user left.
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 120
>
> drivers/media/platform/rcar-vin/rcar-vin.h | 14 +---
> 2 files changed, 55 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 680b25f610d1d8bb..c4be0bcb8b16f941 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -138,67 +138,60 @@ static int rvin_format_align(struct rvin_dev *vin,
> struct v4l2_pix_format *pix)
> * V4L2
> */
>
> -static void rvin_reset_crop_compose(struct rvin_dev *vin)
> -{
> - vin->crop.top = vin->crop.left = 0;
> - vin->crop.width = vin->source.width;
> - vin->crop.height = vin->source.height;
> -
> - vin->compose.top = vin->compose.left = 0;
> - vin->compose.width = vin->format.width;
> - vin->compose.height = vin->format.height;
> -}
> -
> static int rvin_reset_format(struct rvin_dev *vin)
> {
> struct v4l2_subdev_format fmt = {
> .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + .pad = vin->digital->source_pad,
> };
> - struct v4l2_mbus_framefmt *mf = &fmt.format;
> int ret;
>
> - fmt.pad = vin->digital->source_pad;
> -
> ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, &fmt);
> if (ret)
> return ret;
>
> - vin->format.width = mf->width;
> - vin->format.height = mf->height;
> - vin->format.colorspace = mf->colorspace;
> - vin->format.field = mf->field;
> + v4l2_fill_pix_format(&vin->format, &fmt.format);
>
> - rvin_reset_crop_compose(vin);
> + ret = rvin_format_align(vin, &vin->format);
> + if (ret)
> + return ret;
>
> - vin->format.bytesperline = rvin_format_bytesperline(&vin->format);
> - vin->format.sizeimage = rvin_format_sizeimage(&vin->format);
> + vin->source.top = vin->crop.top = 0;
> + vin->source.left = vin->crop.left = 0;
> + vin->source.width = vin->crop.width = vin->format.width;
> + vin->source.height = vin->crop.height = vin->format.height;
> +
> + vin->compose.top = vin->compose.left = 0;
> + vin->compose.width = vin->format.width;
> + vin->compose.height = vin->format.height;
>
> return 0;
> }
>
> -static int __rvin_try_format_source(struct rvin_dev *vin,
> - u32 which,
> - struct v4l2_pix_format *pix,
> - struct rvin_source_fmt *source)
> +static int rvin_try_format(struct rvin_dev *vin, u32 which,
> +struct v4l2_pix_format *pix,
> +struct v4l2_rect *crop, struct v4l2_rect *compose)
> {
> - struct v4l2_subdev *sd;
> + struct v4l2_subdev *sd = vin_to_source(vin);
> struct v4l2_subdev_pad_config *pad_cfg;
> struct v4l2_subdev_format format = {
> .which = which,
> + .pad = vin->digital->source_pad,
> };
> enum v4l2_field field;
> u32 width, height;
> int ret;
>
> - sd = vin_to_source(vin);
> -
> - v4l2_fill_mbus_format(&format.format, pix, vin->digital->code);
> -
> pad_cfg = v4l2_subdev_alloc_pad_config(sd);
> if (pad_cfg == NULL)
> return -ENOMEM;
>
> - format.pad = vin->digital->source_pad;
> + if (!rvin_format_from_pixel(pix->pixelformat) ||
> + (vin->info->model == RCAR_M1 &&
> + pix
Re: [PATCH v12 15/33] rcar-vin: break out format alignment and checking
On 07/03/18 23:04, Niklas Söderlund wrote:
> Part of the format alignment and checking can be shared with the Gen3
> format handling. Break that part out to a separate function.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 85
> -
> 1 file changed, 48 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 01f2a14169a74ff3..680b25f610d1d8bb 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -87,6 +87,53 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format
> *pix)
> return pix->bytesperline * pix->height;
> }
>
> +static int rvin_format_align(struct rvin_dev *vin, struct v4l2_pix_format
> *pix)
> +{
> + u32 walign;
> +
> + if (!rvin_format_from_pixel(pix->pixelformat) ||
> + (vin->info->model == RCAR_M1 &&
> + pix->pixelformat == V4L2_PIX_FMT_XBGR32))
> + pix->pixelformat = RVIN_DEFAULT_FORMAT;
> +
> + switch (pix->field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + break;
> + case V4L2_FIELD_ALTERNATE:
> + /*
> + * Driver dose not (yet) support outputting ALTERNATE to a
> + * userspace. It does support outputting INTERLACED so use
> + * the VIN hardware to combine the two fields.
> + */
> + pix->field = V4L2_FIELD_INTERLACED;
> + pix->height *= 2;
> + break;
> + default:
> + pix->field = RVIN_DEFAULT_FIELD;
> + break;
> + }
> +
> + /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
> + walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
> +
> + /* Limit to VIN capabilities */
> + v4l_bound_align_image(&pix->width, 2, vin->info->max_width, walign,
> + &pix->height, 4, vin->info->max_height, 2, 0);
> +
> + pix->bytesperline = rvin_format_bytesperline(pix);
> + pix->sizeimage = rvin_format_sizeimage(pix);
> +
> + vin_dbg(vin, "Format %ux%u bpl: %u size: %u\n",
> + pix->width, pix->height, pix->bytesperline, pix->sizeimage);
> +
> + return 0;
> +}
> +
> /*
> -
> * V4L2
> */
> @@ -184,7 +231,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
>struct v4l2_pix_format *pix,
>struct rvin_source_fmt *source)
> {
> - u32 walign;
> int ret;
>
> if (!rvin_format_from_pixel(pix->pixelformat) ||
> @@ -197,42 +243,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
> if (ret)
> return ret;
>
> - switch (pix->field) {
> - case V4L2_FIELD_TOP:
> - case V4L2_FIELD_BOTTOM:
> - case V4L2_FIELD_NONE:
> - case V4L2_FIELD_INTERLACED_TB:
> - case V4L2_FIELD_INTERLACED_BT:
> - case V4L2_FIELD_INTERLACED:
> - break;
> - case V4L2_FIELD_ALTERNATE:
> - /*
> - * Driver dose not (yet) support outputting ALTERNATE to a
> - * userspace. It does support outputting INTERLACED so use
> - * the VIN hardware to combine the two fields.
> - */
> - pix->field = V4L2_FIELD_INTERLACED;
> - pix->height *= 2;
> - break;
> - default:
> - pix->field = RVIN_DEFAULT_FIELD;
> - break;
> - }
> -
> - /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
> - walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
> -
> - /* Limit to VIN capabilities */
> - v4l_bound_align_image(&pix->width, 2, vin->info->max_width, walign,
> - &pix->height, 4, vin->info->max_height, 2, 0);
> -
> - pix->bytesperline = rvin_format_bytesperline(pix);
> - pix->sizeimage = rvin_format_sizeimage(pix);
> -
> - vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
> - pix->width, pix->height, pix->bytesperline, pix->sizeimage);
> -
> - return 0;
> + return rvin_format_align(vin, pix);
> }
>
> static int rvin_querycap(struct file *file, void *priv,
>
Re: [PATCH v12 14/33] rcar-vin: align pixelformat check
On 07/03/18 23:04, Niklas Söderlund wrote:
> If the pixelformat is not supported it should not fail but be set to
> something that works. While we are at it move the two different
> checks of the pixelformat to the same statement.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 55fa69aa7c454928..01f2a14169a74ff3 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -187,12 +187,10 @@ static int __rvin_try_format(struct rvin_dev *vin,
> u32 walign;
> int ret;
>
> - /* If requested format is not supported fallback to the default */
> - if (!rvin_format_from_pixel(pix->pixelformat)) {
> - vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
> - pix->pixelformat, RVIN_DEFAULT_FORMAT);
> + if (!rvin_format_from_pixel(pix->pixelformat) ||
> + (vin->info->model == RCAR_M1 &&
> + pix->pixelformat == V4L2_PIX_FMT_XBGR32))
> pix->pixelformat = RVIN_DEFAULT_FORMAT;
> - }
>
> /* Limit to source capabilities */
> ret = __rvin_try_format_source(vin, which, pix, source);
> @@ -231,12 +229,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
> pix->bytesperline = rvin_format_bytesperline(pix);
> pix->sizeimage = rvin_format_sizeimage(pix);
>
> - if (vin->info->model == RCAR_M1 &&
> - pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
> - vin_err(vin, "pixel format XBGR32 not supported on M1\n");
> - return -EINVAL;
> - }
> -
> vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
> pix->width, pix->height, pix->bytesperline, pix->sizeimage);
>
>
Re: [PATCH v12 13/33] rcar-vin: update bytesperline and sizeimage calculation
On 07/03/18 23:04, Niklas Söderlund wrote:
> Remove over complicated logic to calculate the value for bytesperline
> and sizeimage that was carried over from the soc_camera port. There is
> no need to find the max value of bytesperline and sizeimage from
> user-space as they are set to 0 before the max_t() operation.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
Thanks!
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index b76d59be64e0132d..55fa69aa7c454928 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -194,10 +194,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
> pix->pixelformat = RVIN_DEFAULT_FORMAT;
> }
>
> - /* Always recalculate */
> - pix->bytesperline = 0;
> - pix->sizeimage = 0;
> -
> /* Limit to source capabilities */
> ret = __rvin_try_format_source(vin, which, pix, source);
> if (ret)
> @@ -232,10 +228,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
> v4l_bound_align_image(&pix->width, 2, vin->info->max_width, walign,
> &pix->height, 4, vin->info->max_height, 2, 0);
>
> - pix->bytesperline = max_t(u32, pix->bytesperline,
> - rvin_format_bytesperline(pix));
> - pix->sizeimage = max_t(u32, pix->sizeimage,
> -rvin_format_sizeimage(pix));
> + pix->bytesperline = rvin_format_bytesperline(pix);
> + pix->sizeimage = rvin_format_sizeimage(pix);
>
> if (vin->info->model == RCAR_M1 &&
> pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
>
Re: [PATCH v12 12/33] rcar-vin: fix handling of single field frames (top, bottom and alternate fields)
On 07/03/18 23:04, Niklas Söderlund wrote:
> There was never proper support in the VIN driver to deliver ALTERNATING
> field format to user-space, remove this field option. The problem is
> that ALTERNATING field order requires the sequence numbers of buffers
> returned to userspace to reflect if fields where dropped or not,
where -> were
With that tiny typo fixed you can add my:
Reviewed-by: Hans Verkuil
Regards,
Hans
> something which is not possible with the VIN drivers capture logic.
>
> The VIN driver can still capture from a video source which delivers
> frames in ALTERNATING field order, but needs to combine them using the
> VIN hardware into INTERLACED field order. Before this change if a source
> was delivering fields using ALTERNATE the driver would default to
> combining them using this hardware feature. Only if the user explicitly
> requested ALTERNATE field order would incorrect frames be delivered.
>
> The height should not be cut in half for the format for TOP or BOTTOM
> fields settings. This was a mistake and it was made visible by the
> scaling refactoring. Correct behavior is that the user should request a
> frame size that fits the half height frame reflected in the field
> setting. If not the VIN will do its best to scale the top or bottom to
> the requested format and cropping and scaling do not work as expected.
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 15 +--
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 40
> +++--
> 2 files changed, 10 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index fd14be20a6604d7a..c8831e189d362c8b 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -617,7 +617,6 @@ static int rvin_setup(struct rvin_dev *vin)
> case V4L2_FIELD_INTERLACED_BT:
> vnmc = VNMC_IM_FULL | VNMC_FOC;
> break;
> - case V4L2_FIELD_ALTERNATE:
> case V4L2_FIELD_NONE:
> if (vin->continuous) {
> vnmc = VNMC_IM_ODD_EVEN;
> @@ -757,18 +756,6 @@ static int rvin_get_active_slot(struct rvin_dev *vin,
> u32 vnms)
> return 0;
> }
>
> -static enum v4l2_field rvin_get_active_field(struct rvin_dev *vin, u32 vnms)
> -{
> - if (vin->format.field == V4L2_FIELD_ALTERNATE) {
> - /* If FS is set it's a Even field */
> - if (vnms & VNMS_FS)
> - return V4L2_FIELD_BOTTOM;
> - return V4L2_FIELD_TOP;
> - }
> -
> - return vin->format.field;
> -}
> -
> static void rvin_set_slot_addr(struct rvin_dev *vin, int slot, dma_addr_t
> addr)
> {
> const struct rvin_video_format *fmt;
> @@ -941,7 +928,7 @@ static irqreturn_t rvin_irq(int irq, void *data)
> goto done;
>
> /* Capture frame */
> - vin->queue_buf[slot]->field = rvin_get_active_field(vin, vnms);
> + vin->queue_buf[slot]->field = vin->format.field;
> vin->queue_buf[slot]->sequence = sequence;
> vin->queue_buf[slot]->vb2_buf.timestamp = ktime_get_ns();
> vb2_buffer_done(&vin->queue_buf[slot]->vb2_buf, VB2_BUF_STATE_DONE);
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index ebcd78b1bb6e8cb6..b76d59be64e0132d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -121,33 +121,6 @@ static int rvin_reset_format(struct rvin_dev *vin)
> vin->format.colorspace = mf->colorspace;
> vin->format.field = mf->field;
>
> - /*
> - * If the subdevice uses ALTERNATE field mode and G_STD is
> - * implemented use the VIN HW to combine the two fields to
> - * one INTERLACED frame. The ALTERNATE field mode can still
> - * be requested in S_FMT and be respected, this is just the
> - * default which is applied at probing or when S_STD is called.
> - */
> - if (vin->format.field == V4L2_FIELD_ALTERNATE &&
> - v4l2_subdev_has_op(vin_to_source(vin), video, g_std))
> - vin->format.field = V4L2_FIELD_INTERLACED;
> -
> - switch (vin->format.field) {
> - case V4L2_FIELD_TOP:
> - case V4L2_FIELD_BOTTOM:
> - case V4L2_FIELD_ALTERNATE:
> - vin->format.height /= 2;
> - break;
> - case V4L2_FIELD_NONE:
> - case V4L2_FIELD_INTERLACED_TB:
> - case V4L2_FIELD_INTERLACED_BT:
> - case
Re: [PATCH v12 11/33] rcar-vin: set a default field to fallback on
On 07/03/18 23:04, Niklas Söderlund wrote:
> If the field is not supported by the driver it should not try to keep
> the current field. Instead it should set it to a default fallback. Since
> trying a format should always result in the same state regardless of the
> current state of the device.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index c2265324c7c96308..ebcd78b1bb6e8cb6 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -23,6 +23,7 @@
> #include "rcar-vin.h"
>
> #define RVIN_DEFAULT_FORMAT V4L2_PIX_FMT_YUYV
> +#define RVIN_DEFAULT_FIELD V4L2_FIELD_NONE
>
> /*
> -
> * Format Conversions
> @@ -143,7 +144,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
> case V4L2_FIELD_INTERLACED:
> break;
> default:
> - vin->format.field = V4L2_FIELD_NONE;
> + vin->format.field = RVIN_DEFAULT_FIELD;
> break;
> }
>
> @@ -213,10 +214,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
> u32 walign;
> int ret;
>
> - /* Keep current field if no specific one is asked for */
> - if (pix->field == V4L2_FIELD_ANY)
> - pix->field = vin->format.field;
> -
> /* If requested format is not supported fallback to the default */
> if (!rvin_format_from_pixel(pix->pixelformat)) {
> vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
> @@ -246,7 +243,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
> case V4L2_FIELD_INTERLACED:
> break;
> default:
> - pix->field = V4L2_FIELD_NONE;
> + pix->field = RVIN_DEFAULT_FIELD;
> break;
> }
>
>
I wonder if this code is correct. What if the adv7180 is the source? Does that
even
support FIELD_NONE? I suspect that the default field should actually depend on
the
source. FIELD_NONE for dv_timings based or sensor based subdevs and
FIELD_INTERLACED
for SDTV (g/s_std) subdevs.
I might very well be missing something here but it looks suspicious.
Regards,
Hans
Re: [PATCH v12 06/33] rcar-vin: move subdevice handling to async callbacks
On 07/03/18 23:04, Niklas Söderlund wrote:
> In preparation for Gen3 support move the subdevice initialization and
> clean up from rvin_v4l2_{register,unregister}() directly to the async
> callbacks. This simplifies the addition of Gen3 support as the
> rvin_v4l2_register() can be shared for both Gen2 and Gen3 while direct
> subdevice control are only used on Gen2.
>
> While moving this code drop a large comment which is copied from the
> framework documentation and fold rvin_mbus_supported() into its only
> caller. Also move the initialization and cleanup code to separate
> functions to increase readability.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 108
> +++-
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 35 -
> 2 files changed, 74 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 47f06acde2e698f2..663309ca9c04f208 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -46,46 +46,88 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int
> direction)
> return -EINVAL;
> }
>
> -static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
> +/* The vin lock shuld be held when calling the subdevice attach and detach */
shuld -> should
Actually, I'd say 'shall' instead of 'should'.
After that trivial change you can add my:
Reviewed-by: Hans Verkuil
Regards,
Hans
Re: [PATCH v10 03/10] media: platform: Add Renesas CEU driver
On 02/21/18 18:47, Jacopo Mondi wrote: > Add driver for Renesas Capture Engine Unit (CEU). > > The CEU interface supports capturing 'data' (YUV422) and 'images' > (NV[12|21|16|61]). > > This driver aims to replace the soc_camera-based sh_mobile_ceu one. > > Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ > platform GR-Peach. > > Tested with ov7725 camera sensor on SH4 platform Migo-R. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Laurent Pinchart I get these warnings when I try to compile this driver: CC [M] drivers/media/platform/renesas-ceu.o drivers/media/platform/renesas-ceu.c: In function ‘ceu_start_streaming’: drivers/media/platform/renesas-ceu.c:290:2: warning: ‘cdwdr’ may be used uninitialized in this function [-Wmaybe-uninitialized] iowrite32(data, priv->base + reg_offs); ^~ drivers/media/platform/renesas-ceu.c:338:27: note: ‘cdwdr’ was declared here u32 camcr, cdocr, cfzsr, cdwdr, capwr; ^ drivers/media/platform/renesas-ceu.c:290:2: warning: ‘cfzsr’ may be used uninitialized in this function [-Wmaybe-uninitialized] iowrite32(data, priv->base + reg_offs); ^~ drivers/media/platform/renesas-ceu.c:338:20: note: ‘cfzsr’ was declared here u32 camcr, cdocr, cfzsr, cdwdr, capwr; ^ drivers/media/platform/renesas-ceu.c:418:8: warning: ‘camcr’ may be used uninitialized in this function [-Wmaybe-uninitialized] camcr |= mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW ? 1 << 0 : 0; ~~^~~ drivers/media/platform/renesas-ceu.c:338:6: note: ‘camcr’ was declared here u32 camcr, cdocr, cfzsr, cdwdr, capwr; ^ drivers/media/platform/renesas-ceu.c: In function ‘ceu_probe’: drivers/media/platform/renesas-ceu.c:1632:9: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized] return ret; ^~~ cc1: some warnings being treated as errors The last warning is indeed correct. The others are only right if pixelformat is illegal, which can't happen. I'd add a: default: return -EINVAL; to the switch, this shuts up the warnings. So I need a v11 (just for this patch) after all. Regards, Hans
Re: [PATCH v2] videodev2.h: add helper to validate colorspace
On 02/21/2018 10:01 PM, Sakari Ailus wrote: > Hi Laurent and Hans, > > On Wed, Feb 21, 2018 at 10:16:25PM +0200, Laurent Pinchart wrote: >> No, I'm sorry, for MC-based drivers this isn't correct. The media entity >> that >> symbolizes the DMA engine indeed has a sink pad, but it's a video node, not >> a >> subdev. It thus has no media bus format configured for its sink pad. The >> closest pad in the pipeline that has a media bus format is the source pad of >> the subdev connected to the video node. >> >> There's no communication within the kernel at G/S_FMT time between the video >> node and its connected subdev. The only time we look at the pipeline as a >> whole is when starting the stream to validate that the pipeline is correctly >> configured. We thus have to implement G/S_FMT on the video node without any >> knowledge about the connected subdev, and thus accept any colorspace. > > A few more notes related to this --- there's no propagation of sub-device > format across the entities; there were several reasons for the design > choice. The V4L2 pixel format in the video node must be compatible with the > sub-device format when streaming is started. And... the streaming will > start in the pipeline defined by the enabled links to/from the video node. > In principle nothign prevents having multiple links there, and at the time > S_FMT IOCTL is called on the video node, none of those links could be > enabled. And that's perfectly valid use of the API. > > A lot of the DMA engine drivers are simply devices that receive data and > write that to system memory, they really don't necessarily know anything > else. For the hardware this data is just pixels (or even bits, especially > in the case of CSI-2!). Not in my experience. Most DMA engines I've ever worked with can do at least quantization and RGB <-> YUV conversions. Which is pretty much required functionality if you work with video receivers. And in order to program that correctly in the DMA engine you have to know what you receive. Full-fledged colorspace converters that can convert between different colorspaces and transfer functions are likely to be separate subdevs due to the complexity of that. > So I agree with Laurent here that requiring correct colour space for > [GS]_FMT IOCTLs on video nodes in the general case is not feasible > (especially on MC-centric devices), due to the way the Media controller > pipeline and formats along that pipeline are configured and validated (i.e. > at streamon time). > > But what to do here then? The colourspace field is not verified even in > link validation so there's no guarantee it's correctly set more or less > anywhere else than in the source of the stream. And if the stream has > multiple sources with different colour spaces, then what do you do? That's > perhaps a theoretical case but the current frameworks and APIs do in > principle support that. It's not theoretical at all. But anyway, in that case it is up to userspace to decide. A typical example is an sRGB OSD on top of a Rec.709 video. In practice the differences in color at too small to be a problem, you'd just use Rec. 709 and slight color differences in the sRGB OSD is not something that is noticeable. But with HDR and BT.2020 this becomes much more complicated. However, that is out of scope of the kernel driver. > > Perhaps we should specify that the user should always set the same > colourspace on the sink end of a link that was there in the source? The > same should likely apply to the rest of the fields apart from width, height > and code, too. Before the user configures formats this doesn't work though, > and this does not address the matter with v4l2-compliance. > > Granted that the drivers will themselves handle the colour space > information correctly, it'd still provide a way for the user to gain the > knowledge of the colour space which I believe is what matters. > Urgh. It's really wrong IMHO that the DMA engine's input pad can't be configured. It's inconsistent. I don't think we ever thought this through properly. Let me first fix all the other compliance issues and then I'll have to get back to this. It's a mess. Regards, Hans
Re: [PATCH v2] videodev2.h: add helper to validate colorspace
On 02/21/2018 09:16 PM, Laurent Pinchart wrote: > Hi Hans, > > On Tuesday, 20 February 2018 10:37:22 EET Hans Verkuil wrote: >> On 02/19/2018 11:28 PM, Niklas Söderlund wrote: >>> Hi Hans, >>> >>> Thanks for your feedback. >>> >>> [snip] >>> >>>>>>>> Can you then fix v4l2-compliance to stop testing colorspace >>>>>>>> against 0xff >>>>>>>> ? >>>>>>> >>>>>>> For now I can simply relax this test for subdevs with sources and >>>>>>> sinks. >>>>>> >>>>>> You also need to relax it for video nodes with MC drivers, as the DMA >>>>>> engines don't care about colorspaces. >>>>> >>>>> Yes, they do. Many DMA engines can at least do RGB <-> YUV conversions, >>>>> so they should get the colorspace info from their source and pass it on >>>>> to userspace (after correcting for any conversions done by the DMA >>>>> engine). >>>> >>>> Not in the MC case. Video nodes there only model the DMA engine, and are >>>> thus not aware of colorspaces. What MC drivers do is check at stream on >>>> time when validating the pipeline that the colorspace set by userspace >>>> on the video node corresponds to the colorspace on the source pad of the >>>> connected subdev, but that's only to ensure that userspace gets a >>>> coherent view of colorspace across the pipeline, not to program the >>>> hardware. There could be exceptions, but in the general case, the video >>>> node implementation of an MC driver will accept any colorspace and only >>>> validate it at stream on time, similarly to how it does for the frame >>>> size format instance (and in the frame size case it will usually enforce >>>> min/max limits when the DMA engine limits the frame size).> >>> I'm afraid the issue described above by Laurent is what sparked me to >>> write this commit to begin with. In my never ending VIN Gen3 patch-set I >>> currency need to carry a patch [1] to implement a hack to make sure >>> v4l2-compliance do not fail for the VIN Gen3 MC-centric use-case. This >>> patch was an attempt to be able to validate the colorspace using the >>> magic value 0xff. >> >> This is NOT a magic value. The test that's done here is to memset the >> format structure with 0xff, then call the ioctl. Afterwards it checks >> if there are any remaining 0xff bytes left in the struct since it expects >> the driver to have overwritten it by something else. That's where the 0xff >> comes from. > > It's no less or more magic than using 0xdeadbeef or any fixed value :-) I > think we all agree that it isn't a value that is meant to be handled > specifically by drivers, so it's not magic in that sense. > >>> I don't feel strongly for this patch in particular and I'm happy to drop >>> it. But I would like to receive some guidance on how to then properly >>> be able to handle this problem for the MC-centric VIN driver use-case. >>> One option is as you suggested to relax the test in v4l-compliance to >>> not check colorspace, but commit [2] is not enough to resolve the issue >>> for my MC use-case. >>> >>> As Laurent stated above, the use-case is that the video device shall >>> accept any colorspace set from user-space. This colorspace is then only >>> used as stream on time to validate the MC pipeline. The VIN driver do >>> not care about colorspace, but I care about not breaking v4l2-compliance >>> as I find it's a very useful tool :-) >> >> I think part of my confusion here is that there are two places where you >> deal with colorspaces in a DMA engine: first there is a input pad of the >> DMA engine entity, secondly there is the v4l2_pix_format for the memory >> description. >> >> The second is set by the driver based on what userspace specified for the >> input pad, together with any changes due to additional conversions such >> as quantization range and RGB <-> YUV by the DMA engine. > > No, I'm sorry, for MC-based drivers this isn't correct. The media entity that > symbolizes the DMA engine indeed has a sink pad, but it's a video node, not a > subdev. It thus has no media bus format configured for its sink pad. The > closest pad in the pipeline that has a media bus format is the source pad of > the subdev connected to the video node. > > There's no communication within the kernel at G/S_FMT time between the video > node and its connected subdev. The only time we look at the pipeline as a > whole is when starting the stream to validate that the pipeline is correctly > configured. We thus have to implement G/S_FMT on the video node without any > knowledge about the connected subdev, and thus accept any colorspace. > >> So any colorspace validation is done for the input pad. The question is >> what that validation should be. It's never been defined. > > No format is set on the video node's entity sink pad for the reason above, so > no validation occurs when setting the colorspace on the sink pad as that > never > happens. Is this documented anywhere? Certainly VIDIOC_G/S/TRY_FMT doesn't mention it. It is certainly a surprise to me. Regards, Hans
Re: [PATCH v9 11/11] media: i2c: ov7670: Fully set mbus frame fmt
On 02/21/2018 04:47 PM, jacopo mondi wrote: > Hello again, > > On Tue, Feb 20, 2018 at 09:58:57AM +0100, jacopo mondi wrote: >> Hi Laurent, >> >> On Mon, Feb 19, 2018 at 09:19:32PM +0200, Laurent Pinchart wrote: >>> Hi Jacopo, >>> >>> Thank you for the patch. >>> >>> On Monday, 19 February 2018 18:59:44 EET Jacopo Mondi wrote: The sensor driver sets mbus format colorspace information and sizes, but not ycbcr encoding, quantization and xfer function. When supplied with an badly initialized mbus frame format structure, those fields need to be set explicitly not to leave them uninitialized. This is tested by v4l2-compliance, which supplies a mbus format description structure and checks for all fields to be properly set. Without this commit, v4l2-compliance fails when testing formats with: fail: v4l2-test-formats.cpp(335): ycbcr_enc >= 0xff Signed-off-by: Jacopo Mondi --- drivers/media/i2c/ov7670.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c index 25b26d4..61c472e 100644 --- a/drivers/media/i2c/ov7670.c +++ b/drivers/media/i2c/ov7670.c @@ -996,6 +996,10 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd, fmt->height = wsize->height; fmt->colorspace = ov7670_formats[index].colorspace; >>> >>> On a side note, if I'm not mistaken the colorspace field is set to SRGB for >>> all entries. Shouldn't you hardcode it here and remove the field ? >>> + fmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT; + fmt->quantization = V4L2_QUANTIZATION_DEFAULT; + fmt->xfer_func = V4L2_XFER_FUNC_DEFAULT; >>> >>> How about setting the values explicitly instead of relying on defaults ? >>> That >>> would be V4L2_YCBCR_ENC_601, V4L2_QUANTIZATION_LIM_RANGE and >>> V4L2_XFER_FUNC_SRGB. And could you then check a captured frame to see if the >>> sensor outputs limited or full range ? >>> >> >> This actually makes me wonder if those informations (ycbcb_enc, >> quantization and xfer_func) shouldn't actually be part of the >> supported format list... I blindly added those default fields in the >> try_fmt function, but I doubt they applies to all supported formats. >> >> Eg. the sensor supports YUYV as well as 2 RGB encodings (RGB444 and >> RGB 565) and 1 raw format (BGGR). I now have a question here: >> >> 1) ycbcr_enc transforms non-linear R'G'B' to Y'CbCr: does this >> applies to RGB and raw formats? I don't think so, and what value is >> the correct one for the ycbcr_enc field in this case? I assume >> xfer_func and quantization applies to all formats instead.. >> > > What if I repropose this as separate patch not part of the CEU series > in order not to hold back v10 (which I hope will be the last CEU > iteration)? I would definitely be fine with that. We first need to define what exactly should be done by drivers. See also this thread: https://www.spinics.net/lists/linux-renesas-soc/msg23888.html I'll work on that going forward as part of the compliance tests. Regards, Hans > >> Thanks >>j >> info->format = *fmt; return 0; >>> >>> -- >>> Regards, >>> >>> Laurent Pinchart >>>
Re: [PATCH v9 07/11] media: i2c: ov772x: Support frame interval handling
On 02/21/18 16:16, jacopo mondi wrote:
>>> static const struct v4l2_subdev_pad_ops ov772x_subdev_pad_ops = {
>>> - .enum_mbus_code = ov772x_enum_mbus_code,
>>> - .get_selection = ov772x_get_selection,
>>> - .get_fmt= ov772x_get_fmt,
>>> - .set_fmt= ov772x_set_fmt,
>>> + .enum_frame_interval= ov772x_enum_frame_interval,
>>> + .enum_mbus_code = ov772x_enum_mbus_code,
>>> + .get_selection = ov772x_get_selection,
>>> + .get_fmt= ov772x_get_fmt,
>>> + .set_fmt= ov772x_set_fmt,
>>
>> Shouldn't these last four ops be added in the previous patch?
>> They don't have anything to do with the frame interval support.
>>
>
> If you look closely you'll notice I have just re-aligned them, since I
> was at there to add enum_frame_interval operation
Ah, sorry. I missed that. Never mind then :-)
Hans
>
>> Anyway, after taking care of the memsets and these four ops you can add
>> my:
>>
>> Acked-by: Hans Verkuil
>
> Thanks
>j
>
Re: [PATCH v9 03/11] media: platform: Add Renesas CEU driver
On 02/21/18 13:29, Laurent Pinchart wrote:
> Hi Hans,
>
> On Wednesday, 21 February 2018 14:03:24 EET Hans Verkuil wrote:
>> On 02/19/18 17:59, Jacopo Mondi wrote:
>>> Add driver for Renesas Capture Engine Unit (CEU).
>>>
>>> The CEU interface supports capturing 'data' (YUV422) and 'images'
>>> (NV[12|21|16|61]).
>>>
>>> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
>>>
>>> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
>>> platform GR-Peach.
>>>
>>> Tested with ov7725 camera sensor on SH4 platform Migo-R.
>>>
>>> Signed-off-by: Jacopo Mondi
>>> Reviewed-by: Laurent Pinchart
>>> ---
>>>
>>> drivers/media/platform/Kconfig |9 +
>>> drivers/media/platform/Makefile |1 +
>>> drivers/media/platform/renesas-ceu.c | 1661 +
>>> 3 files changed, 1671 insertions(+)
>>> create mode 100644 drivers/media/platform/renesas-ceu.c
>>
>>
>>
>>> +static int ceu_s_input(struct file *file, void *priv, unsigned int i)
>>> +{
>>> + struct ceu_device *ceudev = video_drvdata(file);
>>> + struct ceu_subdev *ceu_sd_old;
>>> + int ret;
>>> +
>>> + if (i >= ceudev->num_sd)
>>> + return -EINVAL;
>>> +
>>> + if (vb2_is_streaming(&ceudev->vb2_vq))
>>> + return -EBUSY;
>>> +
>>> + if (i == ceudev->sd_index)
>>> + return 0;
>>> +
>>> + ceu_sd_old = ceudev->sd;
>>> + ceudev->sd = &ceudev->subdevs[i];
>>> +
>>> + /* Make sure we can generate output image formats. */
>>> + ret = ceu_init_formats(ceudev);
>>
>> Why is this done for every s_input? I would expect that this is done only
>> once for each subdev.
>>
>> I also expect to see a ceu_set_default_fmt() call here. Or that the v4l2_pix
>> is kept in ceu_subdev (i.e. per subdev) instead of a single fmt in cuedev.
>> I think I prefer that over configuring a new default format every time you
>> switch inputs.
>
> What does userspace expect today ? I don't think we document anywhere that
> formats are stored per-input in drivers. The VIDIOC_S_INPUT documentation is
> very vague:
>
> "To select a video input applications store the number of the desired input
> in
> an integer and call the VIDIOC_S_INPUT ioctl with a pointer to this integer.
> Side effects are possible. For example inputs may support different video
> standards, so the driver may implicitly switch the current standard. Because
> of these possible side effects applications must select an input before
> querying or negotiating any other parameters."
>
> I understand that as meaning "anything can happen when you switch inputs, so
> be prepared to reconfigure everything explicitly without assuming any
> particular parameter to have a sane value".
>
>> This code will work for two subdevs with exactly the same
>> formats/properties. But switching between e.g. a sensor and a video
>> receiver will leave things in an inconsistent state as far as I can see.
>>
>> E.g. if input 1 is the video receiver then switching to that input and
>> running 'v4l2-ctl -V' will show the sensor format, not the video receiver
>> format.
>
> I agree that the format should be consistent with the selected input, as
> calling VIDIOC_S_INPUT immediately followed by a stream start sequence
> without
> configuring formats should work (but produce a format that is not known to
> userspace). My question is whether we should reset to a default format for
> the
> newly select input, or switch back to the previously set format. I'd tend to
> go for the former to keep as little state as possible, but I'm open to
> counter-proposals.
What to do is up to the driver. My personal preference is to make it persistent
per input, but that's just me. I won't block the other approach (resetting it
to a default). Be aware that for video receivers the format depends on the
current
selected standard as well. I think the code does that correctly already, but it
would be good to verify if possible.
BTW, I think it is right that the spec isn't specific about what changes when
you switch inputs. It can be quite complex for drivers to handle this and it
is not unreasonable in my view for userspace to just assume it needs to
configure
from scratch after switching inputs.
Regards,
Hans
>
>>> + if (ret) {
>>> + ceudev->sd = ceu_sd_old;
>>> + return -EINVAL;
>>> + }
>>> +
>>> + /* now that we're sure we can use the sensor, power off the old one. */
>>> + v4l2_subdev_call(ceu_sd_old->v4l2_sd, core, s_power, 0);
>>> + v4l2_subdev_call(ceudev->sd->v4l2_sd, core, s_power, 1);
>>> +
>>> + ceudev->sd_index = i;
>>> +
>>> + return 0;
>>> +}
>>
>> The remainder of this driver looks good.
>
Re: [PATCH v9 07/11] media: i2c: ov772x: Support frame interval handling
);
> + if (ret < 0)
> + goto ov772x_set_fmt_error;
> +
> /*
>* set COM8
>*/
> @@ -1043,6 +1199,24 @@ static const struct v4l2_subdev_core_ops
> ov772x_subdev_core_ops = {
> .s_power= ov772x_s_power,
> };
>
> +static int ov772x_enum_frame_interval(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_frame_interval_enum
> *fie)
> +{
> + if (fie->pad || fie->index >= OV772X_N_FRAME_INTERVALS)
> + return -EINVAL;
> +
> + if (fie->width != VGA_WIDTH && fie->width != QVGA_WIDTH)
> + return -EINVAL;
> + if (fie->height != VGA_HEIGHT && fie->height != QVGA_HEIGHT)
> + return -EINVAL;
> +
> + fie->interval.numerator = 1;
> + fie->interval.denominator = ov772x_frame_intervals[fie->index];
> +
> + return 0;
> +}
> +
> static int ov772x_enum_mbus_code(struct v4l2_subdev *sd,
> struct v4l2_subdev_pad_config *cfg,
> struct v4l2_subdev_mbus_code_enum *code)
> @@ -1055,14 +1229,17 @@ static int ov772x_enum_mbus_code(struct v4l2_subdev
> *sd,
> }
>
> static const struct v4l2_subdev_video_ops ov772x_subdev_video_ops = {
> - .s_stream = ov772x_s_stream,
> + .s_stream = ov772x_s_stream,
> + .s_frame_interval = ov772x_s_frame_interval,
> + .g_frame_interval = ov772x_g_frame_interval,
> };
>
> static const struct v4l2_subdev_pad_ops ov772x_subdev_pad_ops = {
> - .enum_mbus_code = ov772x_enum_mbus_code,
> - .get_selection = ov772x_get_selection,
> - .get_fmt= ov772x_get_fmt,
> - .set_fmt= ov772x_set_fmt,
> + .enum_frame_interval= ov772x_enum_frame_interval,
> + .enum_mbus_code = ov772x_enum_mbus_code,
> + .get_selection = ov772x_get_selection,
> + .get_fmt= ov772x_get_fmt,
> + .set_fmt= ov772x_set_fmt,
Shouldn't these last four ops be added in the previous patch?
They don't have anything to do with the frame interval support.
Anyway, after taking care of the memsets and these four ops you can add
my:
Acked-by: Hans Verkuil
Regards,
Hans
> };
>
> static const struct v4l2_subdev_ops ov772x_subdev_ops = {
> @@ -1134,6 +1311,7 @@ static int ov772x_probe(struct i2c_client *client,
>
> priv->cfmt = &ov772x_cfmts[0];
> priv->win = &ov772x_win_sizes[0];
> + priv->fps = 15;
>
> ret = v4l2_async_register_subdev(&priv->subdev);
> if (ret)
> --
> 2.7.4
>
Re: [PATCH v9 06/11] media: i2c: ov772x: Remove soc_camera dependencies
gt;try_fmt = *mf;
> @@ -997,24 +1054,8 @@ static int ov772x_enum_mbus_code(struct v4l2_subdev *sd,
> return 0;
> }
>
> -static int ov772x_g_mbus_config(struct v4l2_subdev *sd,
> - struct v4l2_mbus_config *cfg)
> -{
> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> -
> - cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
> - V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
> - V4L2_MBUS_DATA_ACTIVE_HIGH;
> - cfg->type = V4L2_MBUS_PARALLEL;
> - cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);
> -
> - return 0;
> -}
> -
> static const struct v4l2_subdev_video_ops ov772x_subdev_video_ops = {
> .s_stream = ov772x_s_stream,
> - .g_mbus_config = ov772x_g_mbus_config,
> };
>
> static const struct v4l2_subdev_pad_ops ov772x_subdev_pad_ops = {
> @@ -1038,12 +1079,11 @@ static int ov772x_probe(struct i2c_client *client,
> const struct i2c_device_id *did)
> {
> struct ov772x_priv *priv;
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> - struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
> + struct i2c_adapter *adapter = client->adapter;
> int ret;
>
> - if (!ssdd || !ssdd->drv_priv) {
> - dev_err(&client->dev, "OV772X: missing platform data!\n");
> + if (!client->dev.platform_data) {
> + dev_err(&client->dev, "Missing ov772x platform data\n");
> return -EINVAL;
> }
>
> @@ -1059,7 +1099,7 @@ static int ov772x_probe(struct i2c_client *client,
> if (!priv)
> return -ENOMEM;
>
> - priv->info = ssdd->drv_priv;
> + priv->info = client->dev.platform_data;
>
> v4l2_i2c_subdev_init(&priv->subdev, client, &ov772x_subdev_ops);
> v4l2_ctrl_handler_init(&priv->hdl, 3);
> @@ -1073,22 +1113,42 @@ static int ov772x_probe(struct i2c_client *client,
> if (priv->hdl.error)
> return priv->hdl.error;
>
> - priv->clk = v4l2_clk_get(&client->dev, "mclk");
> + priv->clk = clk_get(&client->dev, "xclk");
> if (IS_ERR(priv->clk)) {
> + dev_err(&client->dev, "Unable to get xclk clock\n");
> ret = PTR_ERR(priv->clk);
> - goto eclkget;
> + goto error_ctrl_free;
> }
>
> - ret = ov772x_video_probe(priv);
> - if (ret < 0) {
> - v4l2_clk_put(priv->clk);
> -eclkget:
> - v4l2_ctrl_handler_free(&priv->hdl);
> - } else {
> - priv->cfmt = &ov772x_cfmts[0];
> - priv->win = &ov772x_win_sizes[0];
> + priv->pwdn_gpio = gpiod_get_optional(&client->dev, "pwdn",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(priv->pwdn_gpio)) {
> + dev_info(&client->dev, "Unable to get GPIO \"pwdn\"");
> + ret = PTR_ERR(priv->pwdn_gpio);
> + goto error_clk_put;
> }
>
> + ret = ov772x_video_probe(priv);
> + if (ret < 0)
> + goto error_gpio_put;
> +
> + priv->cfmt = &ov772x_cfmts[0];
> + priv->win = &ov772x_win_sizes[0];
> +
> + ret = v4l2_async_register_subdev(&priv->subdev);
> + if (ret)
> + goto error_gpio_put;
> +
> + return 0;
> +
> +error_gpio_put:
> + if (priv->pwdn_gpio)
> + gpiod_put(priv->pwdn_gpio);
> +error_clk_put:
> + clk_put(priv->clk);
> +error_ctrl_free:
> + v4l2_ctrl_handler_free(&priv->hdl);
> +
> return ret;
> }
>
> @@ -1096,7 +1156,9 @@ static int ov772x_remove(struct i2c_client *client)
> {
> struct ov772x_priv *priv = to_ov772x(i2c_get_clientdata(client));
>
> - v4l2_clk_put(priv->clk);
> + clk_put(priv->clk);
> + if (priv->pwdn_gpio)
> + gpiod_put(priv->pwdn_gpio);
> v4l2_device_unregister_subdev(&priv->subdev);
> v4l2_ctrl_handler_free(&priv->hdl);
> return 0;
> @@ -1119,6 +1181,6 @@ static struct i2c_driver ov772x_i2c_driver = {
>
> module_i2c_driver(ov772x_i2c_driver);
>
> -MODULE_DESCRIPTION("SoC Camera driver for ov772x");
> +MODULE_DESCRIPTION("V4L2 driver for OV772x image sensor");
> MODULE_AUTHOR("Kuninori Morimoto");
> MODULE_LICENSE("GPL v2");
> diff --git a/include/media/i2c/ov772x.h b/include/media/i2c/ov772x.h
> index 00dbb7c..27d087b 100644
> --- a/include/media/i2c/ov772x.h
> +++ b/include/media/i2c/ov772x.h
> @@ -48,8 +48,10 @@ struct ov772x_edge_ctrl {
> .threshold = (t & OV772X_EDGE_THRESHOLD_MASK), \
> }
>
> -/*
> - * ov772x camera info
> +/**
> + * ov772x_camera_info - ov772x driver interface structure
> + * @flags: Sensor configuration flags
> + * @edgectrl:Sensor edge control
> */
> struct ov772x_camera_info {
This really should be ov772x_platform_data instead of ov772x_camera_info.
This can be changed in a follow-up patch.
For this patch:
Acked-by: Hans Verkuil
Regards,
Hans
> unsigned long flags;
>
Re: [PATCH v9 03/11] media: platform: Add Renesas CEU driver
On 02/19/18 17:59, Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
>
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
>
> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
>
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
>
> Tested with ov7725 camera sensor on SH4 platform Migo-R.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/Kconfig |9 +
> drivers/media/platform/Makefile |1 +
> drivers/media/platform/renesas-ceu.c | 1661
> ++
> 3 files changed, 1671 insertions(+)
> create mode 100644 drivers/media/platform/renesas-ceu.c
>
> +static int ceu_s_input(struct file *file, void *priv, unsigned int i)
> +{
> + struct ceu_device *ceudev = video_drvdata(file);
> + struct ceu_subdev *ceu_sd_old;
> + int ret;
> +
> + if (i >= ceudev->num_sd)
> + return -EINVAL;
> +
> + if (vb2_is_streaming(&ceudev->vb2_vq))
> + return -EBUSY;
> +
> + if (i == ceudev->sd_index)
> + return 0;
> +
> + ceu_sd_old = ceudev->sd;
> + ceudev->sd = &ceudev->subdevs[i];
> +
> + /* Make sure we can generate output image formats. */
> + ret = ceu_init_formats(ceudev);
Why is this done for every s_input? I would expect that this is done only once
for each subdev.
I also expect to see a ceu_set_default_fmt() call here. Or that the v4l2_pix is
kept
in ceu_subdev (i.e. per subdev) instead of a single fmt in cuedev. I think I
prefer
that over configuring a new default format every time you switch inputs.
This code will work for two subdevs with exactly the same formats/properties.
But
switching between e.g. a sensor and a video receiver will leave things in an
inconsistent state as far as I can see.
E.g. if input 1 is the video receiver then switching to that input and running
'v4l2-ctl -V' will show the sensor format, not the video receiver format.
> + if (ret) {
> + ceudev->sd = ceu_sd_old;
> + return -EINVAL;
> + }
> +
> + /* now that we're sure we can use the sensor, power off the old one. */
> + v4l2_subdev_call(ceu_sd_old->v4l2_sd, core, s_power, 0);
> + v4l2_subdev_call(ceudev->sd->v4l2_sd, core, s_power, 1);
> +
> + ceudev->sd_index = i;
> +
> + return 0;
> +}
The remainder of this driver looks good.
Regards,
Hans
Re: [PATCH v2] videodev2.h: add helper to validate colorspace
Hi Niklas, On 02/19/2018 11:28 PM, Niklas Söderlund wrote: > Hi Hans, > > Thanks for your feedback. > > [snip] > >> Can you then fix v4l2-compliance to stop testing colorspace >> against 0xff >> ? > > For now I can simply relax this test for subdevs with sources and sinks. You also need to relax it for video nodes with MC drivers, as the DMA engines don't care about colorspaces. >>> >>> Yes, they do. Many DMA engines can at least do RGB <-> YUV conversions, so >>> they should get the colorspace info from their source and pass it on to >>> userspace (after correcting for any conversions done by the DMA engine). >> >> Not in the MC case. Video nodes there only model the DMA engine, and are >> thus >> not aware of colorspaces. What MC drivers do is check at stream on time when >> validating the pipeline that the colorspace set by userspace on the video >> node >> corresponds to the colorspace on the source pad of the connected subdev, but >> that's only to ensure that userspace gets a coherent view of colorspace >> across >> the pipeline, not to program the hardware. There could be exceptions, but in >> the general case, the video node implementation of an MC driver will accept >> any colorspace and only validate it at stream on time, similarly to how it >> does for the frame size format instance (and in the frame size case it will >> usually enforce min/max limits when the DMA engine limits the frame size). > > I'm afraid the issue described above by Laurent is what sparked me to > write this commit to begin with. In my never ending VIN Gen3 patch-set I > currency need to carry a patch [1] to implement a hack to make sure > v4l2-compliance do not fail for the VIN Gen3 MC-centric use-case. This > patch was an attempt to be able to validate the colorspace using the > magic value 0xff. This is NOT a magic value. The test that's done here is to memset the format structure with 0xff, then call the ioctl. Afterwards it checks if there are any remaining 0xff bytes left in the struct since it expects the driver to have overwritten it by something else. That's where the 0xff comes from. > > I don't feel strongly for this patch in particular and I'm happy to drop > it. But I would like to receive some guidance on how to then properly > be able to handle this problem for the MC-centric VIN driver use-case. > One option is as you suggested to relax the test in v4l-compliance to > not check colorspace, but commit [2] is not enough to resolve the issue > for my MC use-case. > > As Laurent stated above, the use-case is that the video device shall > accept any colorspace set from user-space. This colorspace is then only > used as stream on time to validate the MC pipeline. The VIN driver do > not care about colorspace, but I care about not breaking v4l2-compliance > as I find it's a very useful tool :-) I think part of my confusion here is that there are two places where you deal with colorspaces in a DMA engine: first there is a input pad of the DMA engine entity, secondly there is the v4l2_pix_format for the memory description. The second is set by the driver based on what userspace specified for the input pad, together with any changes due to additional conversions such as quantization range and RGB <-> YUV by the DMA engine. So any colorspace validation is done for the input pad. The question is what that validation should be. It's never been defined. Also the handling of COLORSPACE_DEFAULT for pad formats needs to be defined. This is not the first time this cropped up, see e.g. this RFC patch: https://patchwork.linuxtv.org/patch/41734/ > I'm basing the following on the latest v4l-utils master > (4665ab1fbab1ddaa) which contains commit [2]. The core issue is that if > I do not have a patch like [1] the v4l2-compliance run fails for format > ioctls: > > Format ioctls (Input 0): > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > test VIDIOC_G/S_PARM: OK (Not Supported) > test VIDIOC_G_FBUF: OK (Not Supported) > fail: v4l2-test-formats.cpp(330): !colorspace > fail: v4l2-test-formats.cpp(439): > testColorspace(pix.pixelformat, pix.colorspace, pix.ycbcr_enc, > pix.quantization) > test VIDIOC_G_FMT: FAIL > test VIDIOC_TRY_FMT: OK (Not Supported) > test VIDIOC_S_FMT: OK (Not Supported) > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > test Cropping: OK (Not Supported) > test Composing: OK (Not Supported) > test Scaling: OK > > Well that is OK as that fails when colorspace is V4L2_COLORSPACE_DEFAULT > and that is not valid. If I instead of reverting [1] only test for > V4L2_COLORSPACE_DEFAULT which would not require this patch to implement: > > - if (!pix->colorspace || pix->colorspace >= 0xff) > + if (pix->colorspace == V4L2_COLORSPACE_DEFAULT) > > I still fail for the format ioctls: > > Format ioctls (Input 0): > test VIDIO
Re: [PATCH v2] videodev2.h: add helper to validate colorspace
On 15/02/18 13:32, Hans Verkuil wrote:
> On 15/02/18 13:06, Laurent Pinchart wrote:
>> Hi Hans,
>>
>> On Thursday, 15 February 2018 13:56:44 EET Hans Verkuil wrote:
>>> On 15/02/18 12:08, Laurent Pinchart wrote:
>>>> On Thursday, 15 February 2018 12:57:44 EET Hans Verkuil wrote:
>>>>> On 14/02/18 16:16, Laurent Pinchart wrote:
>>>>>> On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
>>>>>>> There is no way for drivers to validate a colorspace value, which could
>>>>>>> be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
>>>>>>> validate that the colorspace value is part of enum v4l2_colorspace.
>>>>>>>
>>>>>>> Signed-off-by: Niklas Söderlund
>>>>>>> ---
>>>>>>>
>>>>>>> include/uapi/linux/videodev2.h | 4
>>>>>>> 1 file changed, 4 insertions(+)
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I hope this is the correct header to add this helper to. I think it's
>>>>>>> since if it's in uapi not only can v4l2 drivers use it but tools like
>>>>>>> v4l-compliance gets access to it and can be updated to use this instead
>>>>>>> of the hard-coded check of just < 0xff as it was last time I checked.
>>>>>>>
>>>>>>> * Changes since v1
>>>>>>> - Cast colorspace to u32 as suggested by Sakari and only check the
>>>>>>> upper boundary to address a potential issue brought up by Laurent if
>>>>>>> the data type tested is u32 which is not uncommon:
>>>>>>> enum.c:30:16: warning: comparison of unsigned expression >= 0 is
>>>>>>> always true [-Wtype-limits]
>>>>>>>
>>>>>>> return V4L2_COLORSPACE_IS_VALID(colorspace);
>>>>>>>
>>>>>>> diff --git a/include/uapi/linux/videodev2.h
>>>>>>> b/include/uapi/linux/videodev2.h index
>>>>>>> 9827189651801e12..1f27c0f4187cbded 100644
>>>>>>> --- a/include/uapi/linux/videodev2.h
>>>>>>> +++ b/include/uapi/linux/videodev2.h
>>>>>>> @@ -238,6 +238,10 @@ enum v4l2_colorspace {
>>>>>>> V4L2_COLORSPACE_DCI_P3= 12,
>>>>>>> };
>>>>>>>
>>>>>>> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
>>>>>>> +#define V4L2_COLORSPACE_IS_VALID(colorspace) \
>>>>>>> + ((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)
>>>>>
>>>>> Sorry, this won't work. Use __u32. u32 is only available in the kernel,
>>>>> not in userspace and this is a public header.
>>>>
>>>> Indeed, that I should have caught.
>>>>
>>>>> I am not convinced about the usefulness of this check either. Drivers
>>>>> will typically only support a subset of the available colorspaces, so
>>>>> they need a switch to test for that.
>>>>
>>>> Most MC drivers won't, as they don't care about colorspaces in most
>>>> subdevs. It's important for the colorspace to be propagated within
>>>> subdevs, and validated across the pipeline, but in most case, apart from
>>>> the image source subdev, other subdevs won't care. They should accept any
>>>> valid colorspace given to them and propagate it to their source pads
>>>> unchanged (except of course for subdevs that can change the colorspace,
>>>> but that's the exception, not the rule).
>>>
>>> Right. So 'passthrough' subdevs should just copy this information from
>>> source to sink, and only pure source or pure sink subdevs should validate
>>> these fields. That makes sense.
>>>
>>>>> There is nothing wrong with userspace giving them an unknown colorspace:
>>>>> either they will map anything they don't support to something that they
>>>>> DO
>>>>> support, or they will return -EINVAL.
>>>>
>>>> The former, not the latter. S_FMT should not return -EINVAL for
>>>> unsupported
>>>> colorspace, the same way it doesn't return -EINVAL for unsupported pixel
>>>> formats.
>>>>
>>>>> If memo
Re: [PATCH v2] videodev2.h: add helper to validate colorspace
On 15/02/18 13:06, Laurent Pinchart wrote:
> Hi Hans,
>
> On Thursday, 15 February 2018 13:56:44 EET Hans Verkuil wrote:
>> On 15/02/18 12:08, Laurent Pinchart wrote:
>>> On Thursday, 15 February 2018 12:57:44 EET Hans Verkuil wrote:
>>>> On 14/02/18 16:16, Laurent Pinchart wrote:
>>>>> On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
>>>>>> There is no way for drivers to validate a colorspace value, which could
>>>>>> be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
>>>>>> validate that the colorspace value is part of enum v4l2_colorspace.
>>>>>>
>>>>>> Signed-off-by: Niklas Söderlund
>>>>>> ---
>>>>>>
>>>>>> include/uapi/linux/videodev2.h | 4
>>>>>> 1 file changed, 4 insertions(+)
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I hope this is the correct header to add this helper to. I think it's
>>>>>> since if it's in uapi not only can v4l2 drivers use it but tools like
>>>>>> v4l-compliance gets access to it and can be updated to use this instead
>>>>>> of the hard-coded check of just < 0xff as it was last time I checked.
>>>>>>
>>>>>> * Changes since v1
>>>>>> - Cast colorspace to u32 as suggested by Sakari and only check the
>>>>>> upper boundary to address a potential issue brought up by Laurent if
>>>>>> the data type tested is u32 which is not uncommon:
>>>>>> enum.c:30:16: warning: comparison of unsigned expression >= 0 is
>>>>>> always true [-Wtype-limits]
>>>>>>
>>>>>> return V4L2_COLORSPACE_IS_VALID(colorspace);
>>>>>>
>>>>>> diff --git a/include/uapi/linux/videodev2.h
>>>>>> b/include/uapi/linux/videodev2.h index
>>>>>> 9827189651801e12..1f27c0f4187cbded 100644
>>>>>> --- a/include/uapi/linux/videodev2.h
>>>>>> +++ b/include/uapi/linux/videodev2.h
>>>>>> @@ -238,6 +238,10 @@ enum v4l2_colorspace {
>>>>>> V4L2_COLORSPACE_DCI_P3= 12,
>>>>>> };
>>>>>>
>>>>>> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
>>>>>> +#define V4L2_COLORSPACE_IS_VALID(colorspace)\
>>>>>> +((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)
>>>>
>>>> Sorry, this won't work. Use __u32. u32 is only available in the kernel,
>>>> not in userspace and this is a public header.
>>>
>>> Indeed, that I should have caught.
>>>
>>>> I am not convinced about the usefulness of this check either. Drivers
>>>> will typically only support a subset of the available colorspaces, so
>>>> they need a switch to test for that.
>>>
>>> Most MC drivers won't, as they don't care about colorspaces in most
>>> subdevs. It's important for the colorspace to be propagated within
>>> subdevs, and validated across the pipeline, but in most case, apart from
>>> the image source subdev, other subdevs won't care. They should accept any
>>> valid colorspace given to them and propagate it to their source pads
>>> unchanged (except of course for subdevs that can change the colorspace,
>>> but that's the exception, not the rule).
>>
>> Right. So 'passthrough' subdevs should just copy this information from
>> source to sink, and only pure source or pure sink subdevs should validate
>> these fields. That makes sense.
>>
>>>> There is nothing wrong with userspace giving them an unknown colorspace:
>>>> either they will map anything they don't support to something that they
>>>> DO
>>>> support, or they will return -EINVAL.
>>>
>>> The former, not the latter. S_FMT should not return -EINVAL for
>>> unsupported
>>> colorspace, the same way it doesn't return -EINVAL for unsupported pixel
>>> formats.
>>>
>>>> If memory serves the spec requires the first option, so anything unknown
>>>> will just be replaced.
>>>>
>>>> And anyway, this raises the question of why you do this for the
>>>> colorspace
>>>> but not for all the other enums in the V4L2 API.
>>>
>>> Because v4l2-compliance t
Re: [PATCH v2] videodev2.h: add helper to validate colorspace
On 15/02/18 12:08, Laurent Pinchart wrote:
> Hi Hans,
>
> On Thursday, 15 February 2018 12:57:44 EET Hans Verkuil wrote:
>> On 14/02/18 16:16, Laurent Pinchart wrote:
>>> On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
>>>> There is no way for drivers to validate a colorspace value, which could
>>>> be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
>>>> validate that the colorspace value is part of enum v4l2_colorspace.
>>>>
>>>> Signed-off-by: Niklas Söderlund
>>>> ---
>>>>
>>>> include/uapi/linux/videodev2.h | 4
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> Hi,
>>>>
>>>> I hope this is the correct header to add this helper to. I think it's
>>>> since if it's in uapi not only can v4l2 drivers use it but tools like
>>>> v4l-compliance gets access to it and can be updated to use this instead
>>>> of the hard-coded check of just < 0xff as it was last time I checked.
>>>>
>>>> * Changes since v1
>>>> - Cast colorspace to u32 as suggested by Sakari and only check the upper
>>>>
>>>> boundary to address a potential issue brought up by Laurent if the
>>>>
>>>> data type tested is u32 which is not uncommon:
>>>> enum.c:30:16: warning: comparison of unsigned expression >= 0 is
>>>> always
>>>>
>>>> true [-Wtype-limits]
>>>>
>>>> return V4L2_COLORSPACE_IS_VALID(colorspace);
>>>>
>>>> diff --git a/include/uapi/linux/videodev2.h
>>>> b/include/uapi/linux/videodev2.h index
>>>> 9827189651801e12..1f27c0f4187cbded 100644
>>>> --- a/include/uapi/linux/videodev2.h
>>>> +++ b/include/uapi/linux/videodev2.h
>>>> @@ -238,6 +238,10 @@ enum v4l2_colorspace {
>>>>
>>>>V4L2_COLORSPACE_DCI_P3= 12,
>>>>
>>>> };
>>>>
>>>> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
>>>> +#define V4L2_COLORSPACE_IS_VALID(colorspace) \
>>>> + ((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)
>>
>> Sorry, this won't work. Use __u32. u32 is only available in the kernel, not
>> in userspace and this is a public header.
>
> Indeed, that I should have caught.
>
>> I am not convinced about the usefulness of this check either. Drivers will
>> typically only support a subset of the available colorspaces, so they need
>> a switch to test for that.
>
> Most MC drivers won't, as they don't care about colorspaces in most subdevs.
> It's important for the colorspace to be propagated within subdevs, and
> validated across the pipeline, but in most case, apart from the image source
> subdev, other subdevs won't care. They should accept any valid colorspace
> given to them and propagate it to their source pads unchanged (except of
> course for subdevs that can change the colorspace, but that's the exception,
> not the rule).
Right. So 'passthrough' subdevs should just copy this information from source
to sink, and only pure source or pure sink subdevs should validate these
fields. That makes sense.
>
>> There is nothing wrong with userspace giving them an unknown colorspace:
>> either they will map anything they don't support to something that they DO
>> support, or they will return -EINVAL.
>
> The former, not the latter. S_FMT should not return -EINVAL for unsupported
> colorspace, the same way it doesn't return -EINVAL for unsupported pixel
> formats.
>
>> If memory serves the spec requires the first option, so anything unknown
>> will just be replaced.
>>
>> And anyway, this raises the question of why you do this for the colorspace
>> but not for all the other enums in the V4L2 API.
>
> Because v4l2-compliance tries to set a colorspace > 0xff and expects that to
> be replaced by a colorspace <= 0xff. That seems like a bogus check to me,
> 0xff
> is as random as it can get.
v4l2-compliance fills all fields with 0xff, then it checks after calling the
ioctl if all fields have been set to valid values.
But in this case it should ignore the colorspace-related fields for passthrough
subdevs. The only passthrough devices that should set colorspace are colorspace
converter devices. I'm not sure if we can reliably detect that.
>
>> It all seems rather pointless to me.
>>
>> I won't accept this unless I see it being used in a driver in a useful way.
>>
>> So for now:
>>
>> Nacked-by: Hans Verkuil
>
> Can you then fix v4l2-compliance to stop testing colorspace against 0xff ?
For now I can simply relax this test for subdevs with sources and sinks.
Regards,
Hans
>
>>>> +
>>>
>>> Casting to u32 has the added benefit that the colorspace expression is
>>> evaluated once only, I like that.
>>>
>>> Reviewed-by: Laurent Pinchart
>>>
>>>> /*
>>>> * Determine how COLORSPACE_DEFAULT should map to a proper colorspace.
>>>> * This depends on whether this is a SDTV image (use SMPTE 170M), an
>
Re: [PATCH v2] videodev2.h: add helper to validate colorspace
On 14/02/18 16:16, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
>> There is no way for drivers to validate a colorspace value, which could
>> be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
>> validate that the colorspace value is part of enum v4l2_colorspace.
>>
>> Signed-off-by: Niklas Söderlund
>> ---
>> include/uapi/linux/videodev2.h | 4
>> 1 file changed, 4 insertions(+)
>>
>> Hi,
>>
>> I hope this is the correct header to add this helper to. I think it's
>> since if it's in uapi not only can v4l2 drivers use it but tools like
>> v4l-compliance gets access to it and can be updated to use this instead
>> of the hard-coded check of just < 0xff as it was last time I checked.
>>
>> * Changes since v1
>> - Cast colorspace to u32 as suggested by Sakari and only check the upper
>> boundary to address a potential issue brought up by Laurent if the
>> data type tested is u32 which is not uncommon:
>>
>> enum.c:30:16: warning: comparison of unsigned expression >= 0 is always
>> true [-Wtype-limits]
>> return V4L2_COLORSPACE_IS_VALID(colorspace);
>>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 9827189651801e12..1f27c0f4187cbded 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -238,6 +238,10 @@ enum v4l2_colorspace {
>> V4L2_COLORSPACE_DCI_P3= 12,
>> };
>>
>> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
>> +#define V4L2_COLORSPACE_IS_VALID(colorspace)\
>> +((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)
Sorry, this won't work. Use __u32. u32 is only available in the kernel, not
in userspace and this is a public header.
I am not convinced about the usefulness of this check either. Drivers will
typically only support a subset of the available colorspaces, so they need
a switch to test for that. There is nothing wrong with userspace giving them
an unknown colorspace: either they will map anything they don't support to
something that they DO support, or they will return -EINVAL. If memory serves
the spec requires the first option, so anything unknown will just be replaced.
And anyway, this raises the question of why you do this for the colorspace
but not for all the other enums in the V4L2 API.
It all seems rather pointless to me.
I won't accept this unless I see it being used in a driver in a useful way.
So for now:
Nacked-by: Hans Verkuil
Sorry,
Hans
>> +
>
> Casting to u32 has the added benefit that the colorspace expression is
> evaluated once only, I like that.
>
> Reviewed-by: Laurent Pinchart
>
>> /*
>> * Determine how COLORSPACE_DEFAULT should map to a proper colorspace.
>> * This depends on whether this is a SDTV image (use SMPTE 170M), an
>
>
Re: [PATCH v6 0/9] Renesas Capture Engine Unit (CEU) V4L2 driver
On 21/01/18 18:49, jacopo mondi wrote:
> Hi Hans,
>
> On Fri, Jan 19, 2018 at 12:26:09PM +0100, Hans Verkuil wrote:
>> Hi Jacopo,
>>
>> On 01/16/18 22:44, Jacopo Mondi wrote:
>>> Hello,
>>>new version of CEU after Hans' review.
>>>
>>> Added his Acked-by to most patches and closed review comments.
>>> Running v4l2-compliance, I noticed a new failure introduced by the way I now
>>> calculate the plane sizes in set/try_fmt.
>>>
>>> This is the function used to update per-plane bytesperline and sizeimage:
>>>
>>> static void ceu_update_plane_sizes(struct v4l2_plane_pix_format *plane,
>>>unsigned int bpl, unsigned int szimage)
>>> {
>>> if (plane->bytesperline < bpl)
>>> plane->bytesperline = bpl;
>>> if (plane->sizeimage < szimage)
>>> plane->sizeimage = szimage;
>>> }
>>>
>>> I'm seeing a failure as v4l2-compliance requires buffers with both
>>> bytesperline
>>> and sizeimage set to MAX_INT . Hans, is this expected from v4l2-compliance?
>>> How should I handle this, if that has to be handled by the single drivers?
>>
>> I commented on this in my review of patch 3/9.
>
> Fixed thank you.
>
>>
>>>
>>> Apart from that, here it is the output of v4l2-compliance, with the last
>>> tests
>>> failing due to the above stated reason, and two errors in try/set format
>>> due to
>>> the fact the driver is not setting ycbcr encoding after it receives an
>>> invalid
>>
>> Which driver? The CEU driver or the sensor driver? I don't actually see where
>> it fails.
>>
>
> Here it is:
>
> fail: v4l2-test-formats.cpp(335): ycbcr_enc >= 0xff
> fail: v4l2-test-formats.cpp(451):
> testColorspace(pix_mp.pixelformat, pix_mp.colorspace, pix_mp.ycbcr_enc,
> pix_mp.quantization)
> fail: v4l2-test-formats.cpp(736): Video Capture Multiplanar
> is valid, but TRY_FMT failed to return a format
> test VIDIOC_TRY_FMT: FAIL
> fail: v4l2-test-formats.cpp(335): ycbcr_enc >= 0xff
> fail: v4l2-test-formats.cpp(451):
> testColorspace(pix_mp.pixelformat, pix_mp.colorspace, pix_mp.ycbcr_enc,
> pix_mp.quantization)
> fail: v4l2-test-formats.cpp(996): Video Capture Multiplanar
> is valid, but no S_FMT was implemented
> test VIDIOC_S_FMT: FAIL
Sorry, I was perhaps confusing. I meant that I couldn't see where in the code
ycbcr_enc was not overwritten by 0 (which should have happened). You will need
to debug a bit, I think. It could be a bug in the ceu driver or the sensor
driver.
>
>
>>> format. I would set those, but I'm not sure what it the correct value and
>>> not
>>> all mainline drivers do that.
>>
>> In any case, the default for ycbcr_enc, xfer_func and quantization is 0.
>>
>
> Thanks again. I do expect to be the sensor driver to set ycbcr_enc and
> quantization, but from a very trivial grep on media/i2c/ I see only a
> few drivers taking care of them (adv7511 and adv7842). What about the
> others? I assume v4l2-compliance would not fail on them as it does on
> ov7670, but I don't see where ycbr_enc (and others) are managed.
In most cases these values are initialized to 0 (either a memset or by
initializing the struct), which is typically all you need for sensor
drivers. HDMI drivers are more complicated which is why you see explicit
handling of these fields only there.
>
> Overall, with this addressed, the other issue I mentioned on patch
> [3/9] on readbuffers clarified and frameinterval handled for ov722x, I
> hope we're done with this series. Thanks again your continued effort
> in reviews and guidance.
My pleasure!
Regards,
Hans
Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver
On 21/01/18 18:29, jacopo mondi wrote:
> Hi Hans,
>
> On Sun, Jan 21, 2018 at 11:23:12AM +0100, Hans Verkuil wrote:
>> On 21/01/18 11:21, Hans Verkuil wrote:
>>> On 21/01/18 10:53, jacopo mondi wrote:
>>>> Hi Hans,
>>>>
>>>> On Fri, Jan 19, 2018 at 12:20:19PM +0100, Hans Verkuil wrote:
>>>>> static int ov7670_g_parm(struct v4l2_subdev *sd, struct v4l2_streamparm
>>>>> *parms)
>>>>> {
>>>>> struct v4l2_captureparm *cp = &parms->parm.capture;
>>>>> struct ov7670_info *info = to_state(sd);
>>>>>
>>>>> if (parms->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
>>>>> return -EINVAL;
>>>>>
>>>>> And parms->type is CAPTURE_MPLANE. Just drop this test from the ov7670
>>>>> driver
>>>>> in the g/s_parm functions. It shouldn't test for that since a subdev
>>>>> driver
>>>>> knows nothing about buffer types.
>>>>>
>>>>
>>>> I will drop that test in an additional patch part of next iteration of
>>>> this series,
>>>
>>> Replace g/s_parm by g/s_frame_interval. Consider g/s_parm for subdev
>>> drivers as
>>> deprecated (I'm working on a patch series to replace all g/s_parm uses by
>>> g/s_frame_interval).
>>
>> Take a look here:
>>
>> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=parm
>>
>> You probably want to use the patch 'v4l2-common: add g/s_parm helper
>> functions'
>> for the new ceu driver in your patch series. Feel free to add it.
>
> Thanks, I have now re-based my series on top of your 'parm' branch,
> and now I have silenced those errors on bad frame interval.
>
> CEU g/s_parm now look like this:
>
> static int ceu_g_parm(struct file *file, void *fh, struct v4l2_streamparm *a)
> {
> struct ceu_device *ceudev = video_drvdata(file);
> int ret;
>
> ret = v4l2_g_parm(V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
> ceudev->sd->v4l2_sd, a);
> if (ret)
> return ret;
>
> a->parm.capture.readbuffers = 0;
>
> return 0;
> }
>
> Very similar to what you've done on other platform drivers in this
> commit:
> https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=parm&id=a58956ef45cebaa5ce43a5f740fe04517b24a853
>
> I have a question though (please bear with me a little more :)
> I had to manually set a->parm.capture.readbuffers to 0 to silence the
> following
> error in v4l2_compliance (which I have now updated to the most recent
> remote HEAD):
>
> fail: v4l2-test-formats.cpp(1114): cap->readbuffers
> test VIDIOC_G/S_PARM: FAIL
>
> fail_on_test(cap->readbuffers > VIDEO_MAX_FRAME);
> if (!(node->g_caps() & V4L2_CAP_READWRITE))
> fail_on_test(cap->readbuffers);
> else if (node->g_caps() & V4L2_CAP_STREAMING)
> fail_on_test(!cap->readbuffers);
>
> CEU does not support CAP_READWRITE, as it seems atmel-isc/isi do not, so
> v4l2-compliance wants to have readbuffers set to 0. I wonder why in
> the previously mentioned commit you didn't have to set readbuffers
> explicitly to 0 for atmel-isc/isi as I had to for CEU. Will v4l2-compliance
> fail if run on atmel-isc/isi with your commit, or am I missing something?
I've reworked the g/s_parm helper functions so they will now check for
the READWRITE capability and set readbuffers accordingly. I'll post a new
version later today.
Thanks for testing this, I missed that corner case.
Regards,
Hans
Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver
On 22/01/18 01:52, Laurent Pinchart wrote:
> Hi Hans,
>
> On Friday, 19 January 2018 14:25:39 EET Hans Verkuil wrote:
>> On 01/19/18 13:20, Laurent Pinchart wrote:
>>> On Friday, 19 January 2018 13:20:19 EET Hans Verkuil wrote:
>>>> On 01/16/18 22:44, Jacopo Mondi wrote:
>>>>> Add driver for Renesas Capture Engine Unit (CEU).
>>>>>
>>>>> The CEU interface supports capturing 'data' (YUV422) and 'images'
>>>>> (NV[12|21|16|61]).
>>>>>
>>>>> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
>>>>>
>>>>> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
>>>>> platform GR-Peach.
>>>>>
>>>>> Tested with ov7725 camera sensor on SH4 platform Migo-R.
>>>>>
>>>>> Signed-off-by: Jacopo Mondi
>>>>> Reviewed-by: Laurent Pinchart
>>>>> ---
>>>>>
>>>>> drivers/media/platform/Kconfig |9 +
>>>>> drivers/media/platform/Makefile |1 +
>>>>> drivers/media/platform/renesas-ceu.c | 1659 +++
>>>>> 3 files changed, 1669 insertions(+)
>>>>> create mode 100644 drivers/media/platform/renesas-ceu.c
>>>
>>> [snip]
>>>
>>>>> diff --git a/drivers/media/platform/renesas-ceu.c
>>>>> b/drivers/media/platform/renesas-ceu.c new file mode 100644
>>>>> index 000..1b8f0ef
>>>>> --- /dev/null
>>>>> +++ b/drivers/media/platform/renesas-ceu.c
>>>
>>> [snip]
>>>
>>>>> +static void ceu_update_plane_sizes(struct v4l2_plane_pix_format *plane,
>>>>> +unsigned int bpl, unsigned int szimage)
>>>>> +{
>>>>> + if (plane->bytesperline < bpl)
>>>>> + plane->bytesperline = bpl;
>>>>> + if (plane->sizeimage < szimage)
>>>>> + plane->sizeimage = szimage;
>>>>
>>>> As mentioned in your cover letter, you do need to check for invalid
>>>> bytesperline values. The v4l2-compliance test is to see what happens
>>>> when userspace gives insane values, so yes, drivers need to be able
>>>> to handle that.
>>>
>>> What limit would you set, what is an acceptable large value versus an
>>> invalid large value ? I think we should have rules for this at the API
>>> level (or at least, if not part of the API, rules that are consistent
>>> across drivers).
>>
>> I would expect this to be the max of what the hardware can support. If
>> that's really high, then this can be, say, 4 times the width.
>>
>> Note that there are very few drivers that can handle a user-specified
>> stride.
>
> But that's no reason not to handle it here if the hardware permits, right ?
> :-)
Certainly. But it is the reason why it's hard to find example code in
existing drivers.
>>>> plane->sizeimage is set by the driver, so drop the 'if' before the
>>>> assignment.
>>>
>>> I don't think that's correct. Userspace should be able to control padding
>>> lines at the end of the image, the same way it controls padding pixels at
>>> the end of lines.
>>
>> If userspace wants larger buffers, then it should use VIDIOC_CREATE_BUFS.
>>
>> sizeimage is exclusively set by the driver, applications rely on that.
>
> The API documentation is pretty confusing about this.
>
> In pixfmt-v4l2.rst, the field in the v4l2_pix_format structure is documented
> as
>
> - Size in bytes of the buffer to hold a complete image, set by the
> driver. Usually this is ``bytesperline`` times ``height``. When
> the image consists of variable length compressed data this is the
> maximum number of bytes required to hold an image.
>
> Then in pixfmt-v4l2-mplane.rst, the field in the v4l2_plane_pix_format
> structure is documented as
>
> - Maximum size in bytes required for image data in this plane.
This should contain the same text as in pixfmt-v4l2.rst.
>
> Finally, in vidioc-create-bufs.rst, we have
>
> The buffers created by this ioctl will have as minimum size the size
> defined by the ``format.pix.sizeimage`` field (or the corresponding
> fields for other format types). Usually if the ``format.pix.sizeimage``
> field is less than the minimum required for the given format, then an
&g
Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver
On 21/01/18 11:21, Hans Verkuil wrote:
> On 21/01/18 10:53, jacopo mondi wrote:
>> Hi Hans,
>>
>> On Fri, Jan 19, 2018 at 12:20:19PM +0100, Hans Verkuil wrote:
>>> static int ov7670_g_parm(struct v4l2_subdev *sd, struct v4l2_streamparm
>>> *parms)
>>> {
>>> struct v4l2_captureparm *cp = &parms->parm.capture;
>>> struct ov7670_info *info = to_state(sd);
>>>
>>> if (parms->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
>>> return -EINVAL;
>>>
>>> And parms->type is CAPTURE_MPLANE. Just drop this test from the ov7670
>>> driver
>>> in the g/s_parm functions. It shouldn't test for that since a subdev driver
>>> knows nothing about buffer types.
>>>
>>
>> I will drop that test in an additional patch part of next iteration of this
>> series,
>
> Replace g/s_parm by g/s_frame_interval. Consider g/s_parm for subdev drivers
> as
> deprecated (I'm working on a patch series to replace all g/s_parm uses by
> g/s_frame_interval).
Take a look here:
https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=parm
You probably want to use the patch 'v4l2-common: add g/s_parm helper functions'
for the new ceu driver in your patch series. Feel free to add it.
Regards,
Hans
Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver
On 21/01/18 10:53, jacopo mondi wrote:
> Hi Hans,
>
> On Fri, Jan 19, 2018 at 12:20:19PM +0100, Hans Verkuil wrote:
>> static int ov7670_g_parm(struct v4l2_subdev *sd, struct v4l2_streamparm
>> *parms)
>> {
>> struct v4l2_captureparm *cp = &parms->parm.capture;
>> struct ov7670_info *info = to_state(sd);
>>
>> if (parms->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
>> return -EINVAL;
>>
>> And parms->type is CAPTURE_MPLANE. Just drop this test from the ov7670 driver
>> in the g/s_parm functions. It shouldn't test for that since a subdev driver
>> knows nothing about buffer types.
>>
>
> I will drop that test in an additional patch part of next iteration of this
> series,
Replace g/s_parm by g/s_frame_interval. Consider g/s_parm for subdev drivers as
deprecated (I'm working on a patch series to replace all g/s_parm uses by
g/s_frame_interval).
Regards,
Hans
Re: [PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies
On 21/01/18 10:31, jacopo mondi wrote: > Hello Hans, Laurent, Sakari, > > On Fri, Jan 19, 2018 at 02:23:21PM +0200, Laurent Pinchart wrote: >> Hello, >> >> On Friday, 19 January 2018 13:19:18 EET Sakari Ailus wrote: >>> On Fri, Jan 19, 2018 at 11:47:33AM +0100, Hans Verkuil wrote: >>>> On 01/19/18 11:24, Hans Verkuil wrote: >>>>> On 01/16/18 22:44, Jacopo Mondi wrote: >>>>>> Remove soc_camera framework dependencies from ov772x sensor driver. >>>>>> - Handle clock and gpios >>>>>> - Register async subdevice >>>>>> - Remove soc_camera specific g/s_mbus_config operations >>>>>> - Change image format colorspace from JPEG to SRGB as the two use the >>>>>> same colorspace information but JPEG makes assumptions on color >>>>>> components quantization that do not apply to the sensor >>>>>> - Remove sizes crop from get_selection as driver can't scale >>>>>> - Add kernel doc to driver interface header file >>>>>> - Adjust build system >>>>>> >>>>>> This commit does not remove the original soc_camera based driver as >>>>>> long as other platforms depends on soc_camera-based CEU driver. >>>>>> >>>>>> Signed-off-by: Jacopo Mondi >>>>>> Reviewed-by: Laurent Pinchart >>>>> >>>>> Acked-by: Hans Verkuil >>>> >>>> Un-acked. >>>> >>>> I just noticed that this sensor driver has no enum_frame_interval and >>>> g/s_parm support. How would a driver ever know the frame rate of the >>>> sensor without that? > > Does it make any difference if I point out that this series hasn't > removed any of that code, and the driver was not supporting that > already? Or was it handled through soc_camera? That last question is a good one. Can you check? There are two sh boards that use this sensor. Are you able to test on one of those boards? There is reversed engineered code for the ox772x here: drivers/media/usb/gspca/ov534.c That appears to handle framerates. I am very uncomfortable promoting this driver to drivers/media/i2c without having functioning frame interval handling. It could be as simple as a single fixed framerate, it doesn't have to be fancy. Without it it is basically unusable by applications since those typically expect support for this. Moving it to staging might be another option, with a TODO mentioning this missing feature. > >>> >>> s/_parm/_frame_interval/ ? >>> >>> We should have wrappers for this or rather to convert g/s_parm users to >>> g/s_frame_interval so drivers don't need to implement both. >> >> There are two ways to set the frame interval, either explicitly through the >> s_frame_interval operation, or implicitly through control of the pixel clock, >> horizontal blanking and vertical blanking (which in turn can be influenced by >> the exposure time). >> >> Having two ways to perform the same operation seems sub-optimal to me, but I >> could understand if they covered different use cases. As far as I know we >> don't document the use cases for those methods. What's your opinion on that ? >> > > -If- I have to implement that in this series to have it accepted, > please let me know which one of the two is the preferred one :) g/s_frame_interval. The other is (I think) for highly specialized devices. For regular normal sensors I do not think it makes much sense. Certainly not for fairly old sensors like this one. Regards, Hans
Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver
On 01/19/18 13:20, Laurent Pinchart wrote:
> Hi Hans,
>
> On Friday, 19 January 2018 13:20:19 EET Hans Verkuil wrote:
>> On 01/16/18 22:44, Jacopo Mondi wrote:
>>> Add driver for Renesas Capture Engine Unit (CEU).
>>>
>>> The CEU interface supports capturing 'data' (YUV422) and 'images'
>>> (NV[12|21|16|61]).
>>>
>>> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
>>>
>>> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
>>> platform GR-Peach.
>>>
>>> Tested with ov7725 camera sensor on SH4 platform Migo-R.
>>>
>>> Signed-off-by: Jacopo Mondi
>>> Reviewed-by: Laurent Pinchart
>>> ---
>>>
>>> drivers/media/platform/Kconfig |9 +
>>> drivers/media/platform/Makefile |1 +
>>> drivers/media/platform/renesas-ceu.c | 1659 +
>>> 3 files changed, 1669 insertions(+)
>>> create mode 100644 drivers/media/platform/renesas-ceu.c
>
> [snip]
>
>>> diff --git a/drivers/media/platform/renesas-ceu.c
>>> b/drivers/media/platform/renesas-ceu.c new file mode 100644
>>> index 000..1b8f0ef
>>> --- /dev/null
>>> +++ b/drivers/media/platform/renesas-ceu.c
>
> [snip]
>
>>> +static void ceu_update_plane_sizes(struct v4l2_plane_pix_format *plane,
>>> + unsigned int bpl, unsigned int szimage)
>>> +{
>>> + if (plane->bytesperline < bpl)
>>> + plane->bytesperline = bpl;
>>> + if (plane->sizeimage < szimage)
>>> + plane->sizeimage = szimage;
>>
>> As mentioned in your cover letter, you do need to check for invalid
>> bytesperline values. The v4l2-compliance test is to see what happens
>> when userspace gives insane values, so yes, drivers need to be able
>> to handle that.
>
> What limit would you set, what is an acceptable large value versus an invalid
> large value ? I think we should have rules for this at the API level (or at
> least, if not part of the API, rules that are consistent across drivers).
I would expect this to be the max of what the hardware can support. If
that's really high, then this can be, say, 4 times the width.
Note that there are very few drivers that can handle a user-specified
stride.
>> plane->sizeimage is set by the driver, so drop the 'if' before the
>> assignment.
>
> I don't think that's correct. Userspace should be able to control padding
> lines at the end of the image, the same way it controls padding pixels at the
> end of lines.
If userspace wants larger buffers, then it should use VIDIOC_CREATE_BUFS.
sizeimage is exclusively set by the driver, applications rely on that.
>
>>> +}
>
> [snip]
>
>>> +static const struct v4l2_ioctl_ops ceu_ioctl_ops = {
>>> + .vidioc_querycap= ceu_querycap,
>>> +
>>> + .vidioc_enum_fmt_vid_cap_mplane = ceu_enum_fmt_vid_cap,
>>> + .vidioc_try_fmt_vid_cap_mplane = ceu_try_fmt_vid_cap,
>>> + .vidioc_s_fmt_vid_cap_mplane= ceu_s_fmt_vid_cap,
>>> + .vidioc_g_fmt_vid_cap_mplane= ceu_g_fmt_vid_cap,
>>> +
>>> + .vidioc_enum_input = ceu_enum_input,
>>> + .vidioc_g_input = ceu_g_input,
>>> + .vidioc_s_input = ceu_s_input,
>>> +
>>> + .vidioc_reqbufs = vb2_ioctl_reqbufs,
>>> + .vidioc_querybuf= vb2_ioctl_querybuf,
>>> + .vidioc_qbuf= vb2_ioctl_qbuf,
>>> + .vidioc_expbuf = vb2_ioctl_expbuf,
>>> + .vidioc_dqbuf = vb2_ioctl_dqbuf,
>>> + .vidioc_create_bufs = vb2_ioctl_create_bufs,
>>> + .vidioc_prepare_buf = vb2_ioctl_prepare_buf,
>>> + .vidioc_streamon= vb2_ioctl_streamon,
>>> + .vidioc_streamoff = vb2_ioctl_streamoff,
>>> +
>>> + .vidioc_g_parm = ceu_g_parm,
>>> + .vidioc_s_parm = ceu_s_parm,
>>> + .vidioc_enum_framesizes = ceu_enum_framesizes,
>>> + .vidioc_enum_frameintervals = ceu_enum_frameintervals,
>>
>> You're missing these ioctls:
>>
>> .vidioc_log_status = v4l2_ctrl_log_status,
>
> Is log status mandatory ?
No, but it doesn't hurt to add this one. It comes for free.
>
>> .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
>> .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
>>
>> These missing _event ops are the reason for this compliance failure:
>>
>> fail: v4l2-test-controls.cpp(782): subscribe event for control 'User
>> Controls' failed
>>> +};
>
> [snip]
>
Regards,
Hans
Re: [PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies
On 01/19/18 12:19, Sakari Ailus wrote: > Hi Hans, > > On Fri, Jan 19, 2018 at 11:47:33AM +0100, Hans Verkuil wrote: >> On 01/19/18 11:24, Hans Verkuil wrote: >>> On 01/16/18 22:44, Jacopo Mondi wrote: >>>> Remove soc_camera framework dependencies from ov772x sensor driver. >>>> - Handle clock and gpios >>>> - Register async subdevice >>>> - Remove soc_camera specific g/s_mbus_config operations >>>> - Change image format colorspace from JPEG to SRGB as the two use the >>>> same colorspace information but JPEG makes assumptions on color >>>> components quantization that do not apply to the sensor >>>> - Remove sizes crop from get_selection as driver can't scale >>>> - Add kernel doc to driver interface header file >>>> - Adjust build system >>>> >>>> This commit does not remove the original soc_camera based driver as long >>>> as other platforms depends on soc_camera-based CEU driver. >>>> >>>> Signed-off-by: Jacopo Mondi >>>> Reviewed-by: Laurent Pinchart >>> >>> Acked-by: Hans Verkuil >> >> Un-acked. >> >> I just noticed that this sensor driver has no enum_frame_interval and >> g/s_parm support. How would a driver ever know the frame rate of the >> sensor without that? > > s/_parm/_frame_interval/ ? Yes. > > We should have wrappers for this or rather to convert g/s_parm users to > g/s_frame_interval so drivers don't need to implement both. We should convert them. I wonder why we didn't? Regards, Hans
Re: [PATCH v6 0/9] Renesas Capture Engine Unit (CEU) V4L2 driver
Hi Jacopo,
On 01/16/18 22:44, Jacopo Mondi wrote:
> Hello,
>new version of CEU after Hans' review.
>
> Added his Acked-by to most patches and closed review comments.
> Running v4l2-compliance, I noticed a new failure introduced by the way I now
> calculate the plane sizes in set/try_fmt.
>
> This is the function used to update per-plane bytesperline and sizeimage:
>
> static void ceu_update_plane_sizes(struct v4l2_plane_pix_format *plane,
> unsigned int bpl, unsigned int szimage)
> {
> if (plane->bytesperline < bpl)
> plane->bytesperline = bpl;
> if (plane->sizeimage < szimage)
> plane->sizeimage = szimage;
> }
>
> I'm seeing a failure as v4l2-compliance requires buffers with both
> bytesperline
> and sizeimage set to MAX_INT . Hans, is this expected from v4l2-compliance?
> How should I handle this, if that has to be handled by the single drivers?
I commented on this in my review of patch 3/9.
>
> Apart from that, here it is the output of v4l2-compliance, with the last tests
> failing due to the above stated reason, and two errors in try/set format due
> to
> the fact the driver is not setting ycbcr encoding after it receives an invalid
Which driver? The CEU driver or the sensor driver? I don't actually see where
it fails.
> format. I would set those, but I'm not sure what it the correct value and not
> all mainline drivers do that.
In any case, the default for ycbcr_enc, xfer_func and quantization is 0.
>
> ---
> v4l2-compliance SHA : 1d3c611dee82090d9456730e24af368b51dcb4a9
I can't find this SHA in the v4l-utils repo. You should always compile
v4l2-compliance from the master branch.
Also test with 'v4l2-compliance -f': this tests streaming in all formats.
>
> Driver Info:
> Driver name : renesas-ceu
> Card type : Renesas CEU e821.ceu
> Bus info : platform:renesas-ceu-e821.c
> Driver version: 4.14.0
> Capabilities : 0x84201000
> Video Capture Multiplanar
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps : 0x04201000
> Video Capture Multiplanar
> Streaming
> Extended Pix Format
>
> Compliance test for device /dev/video0 (not using libv4l2):
>
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
>
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
>
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK
> test VIDIOC_LOG_STATUS: OK (Not Supported)
>
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
>
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
>
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
>
> Test input 0:
>
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> fail: v4l2-test-controls.cpp(782): subscribe event for control
> 'User Controls' failed
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 12 Private Controls: 0
>
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> fail: v4l2-test-formats.cpp(1162): ret && node->has_frmintervals
> test VIDIOC_G/S_PARM: FAIL
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> fail: v4l2-test-formats.cpp(335): ycbcr_enc >= 0xff
> fail: v4l2-test-formats.cpp(451):
> testColorspace(pix_mp.pixelformat, pix_mp.colorspace, pix_mp.ycbcr_enc,
> pix_mp.quantization)
> fail: v4l2-test-formats.cpp(736): Video Capture Multiplanar is
> valid, but TRY_FMT failed to return a format
> test VIDIOC_TRY_FMT: FAIL
> fail: v4l2-test-fo
Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver
Some more comments: On 01/16/18 22:44, Jacopo Mondi wrote: > Add driver for Renesas Capture Engine Unit (CEU). > > The CEU interface supports capturing 'data' (YUV422) and 'images' > (NV[12|21|16|61]). > > This driver aims to replace the soc_camera-based sh_mobile_ceu one. > > Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ > platform GR-Peach. > > Tested with ov7725 camera sensor on SH4 platform Migo-R. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Laurent Pinchart > --- > drivers/media/platform/Kconfig |9 + > drivers/media/platform/Makefile |1 + > drivers/media/platform/renesas-ceu.c | 1659 > ++ > 3 files changed, 1669 insertions(+) > create mode 100644 drivers/media/platform/renesas-ceu.c > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index fd0c998..fe7bd26 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI > To compile this driver as a module, choose M here: the module > will be called stm32-dcmi. > > +config VIDEO_RENESAS_CEU > + tristate "Renesas Capture Engine Unit (CEU) driver" > + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA > + depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST > + select VIDEOBUF2_DMA_CONTIG > + select V4L2_FWNODE > + ---help--- > + This is a v4l2 driver for the Renesas CEU Interface > + > source "drivers/media/platform/soc_camera/Kconfig" > source "drivers/media/platform/exynos4-is/Kconfig" > source "drivers/media/platform/am437x/Kconfig" > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile > index 003b0bb..6580a6b 100644 > --- a/drivers/media/platform/Makefile > +++ b/drivers/media/platform/Makefile > @@ -62,6 +62,7 @@ obj-$(CONFIG_VIDEO_SH_VOU) += sh_vou.o > obj-$(CONFIG_SOC_CAMERA) += soc_camera/ > > obj-$(CONFIG_VIDEO_RCAR_DRIF)+= rcar_drif.o > +obj-$(CONFIG_VIDEO_RENESAS_CEU) += renesas-ceu.o > obj-$(CONFIG_VIDEO_RENESAS_FCP) += rcar-fcp.o > obj-$(CONFIG_VIDEO_RENESAS_FDP1) += rcar_fdp1.o > obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o > diff --git a/drivers/media/platform/renesas-ceu.c > b/drivers/media/platform/renesas-ceu.c > new file mode 100644 > index 000..1b8f0ef > --- /dev/null > +++ b/drivers/media/platform/renesas-ceu.c > @@ -0,0 +1,1659 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface > + * Copyright (C) 2017-2018 Jacopo Mondi > + * > + * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c" > + * Copyright (C) 2008 Magnus Damm > + * > + * Based on V4L2 Driver for PXA camera host - "pxa_camera.c", > + * Copyright (C) 2006, Sascha Hauer, Pengutronix > + * Copyright (C) 2008, Guennadi Liakhovetski > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define DRIVER_NAME "renesas-ceu" > + > +/* CEU registers offsets and masks. */ > +#define CEU_CAPSR0x00 /* Capture start register */ > +#define CEU_CAPCR0x04 /* Capture control register*/ > +#define CEU_CAMCR0x08 /* Capture interface control register */ > +#define CEU_CAMOR0x10 /* Capture interface offset register */ > +#define CEU_CAPWR0x14 /* Capture interface width register*/ > +#define CEU_CAIFR0x18 /* Capture interface input format register */ > +#define CEU_CRCNTR 0x28 /* CEU register control register */ > +#define CEU_CRCMPR 0x2c /* CEU register forcible control register */ > +#define CEU_CFLCR0x30 /* Capture filter control register */ > +#define CEU_CFSZR0x34 /* Capture filter size clip register */ > +#define CEU_CDWDR0x38 /* Capture destination width register */ > +#define CEU_CDAYR0x3c /* Capture data address Y register */ > +#define CEU_CDACR0x40 /* Capture data address C register */ > +#define CEU_CFWCR0x5c /* Firewall operation control register */ > +#define CEU_CDOCR0x64 /* Capture data output control register*/ > +#define CEU_CEIER0x70 /* Capture event interrupt enable register */ > +#define CEU_CETCR0x74 /* Capture event flag clear register */ > +#define CEU_CSTSR0x7c /* Capture status register */ > +#define CEU_CSRTR0x80 /* Capture software reset register */ > + > +/* Data synchronous fetch mode. */ > +#define CEU_CAMCR_JPEG BIT(4) > + > +/* Input components ordering: CEU_CAMCR.DTARY field. */ > +#define C
Re: [PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies
On 01/19/18 11:24, Hans Verkuil wrote: > On 01/16/18 22:44, Jacopo Mondi wrote: >> Remove soc_camera framework dependencies from ov772x sensor driver. >> - Handle clock and gpios >> - Register async subdevice >> - Remove soc_camera specific g/s_mbus_config operations >> - Change image format colorspace from JPEG to SRGB as the two use the >> same colorspace information but JPEG makes assumptions on color >> components quantization that do not apply to the sensor >> - Remove sizes crop from get_selection as driver can't scale >> - Add kernel doc to driver interface header file >> - Adjust build system >> >> This commit does not remove the original soc_camera based driver as long >> as other platforms depends on soc_camera-based CEU driver. >> >> Signed-off-by: Jacopo Mondi >> Reviewed-by: Laurent Pinchart > > Acked-by: Hans Verkuil Un-acked. I just noticed that this sensor driver has no enum_frame_interval and g/s_parm support. How would a driver ever know the frame rate of the sensor without that? This looks like a bug to me. Regards, Hans
Re: [PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies
On 01/16/18 22:44, Jacopo Mondi wrote: > Remove soc_camera framework dependencies from ov772x sensor driver. > - Handle clock and gpios > - Register async subdevice > - Remove soc_camera specific g/s_mbus_config operations > - Change image format colorspace from JPEG to SRGB as the two use the > same colorspace information but JPEG makes assumptions on color > components quantization that do not apply to the sensor > - Remove sizes crop from get_selection as driver can't scale > - Add kernel doc to driver interface header file > - Adjust build system > > This commit does not remove the original soc_camera based driver as long > as other platforms depends on soc_camera-based CEU driver. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Laurent Pinchart Acked-by: Hans Verkuil Regards, Hans
Re: [PATCH v5 9/9] arch: sh: migor: Use new renesas-ceu camera driver
On 01/12/2018 03:04 PM, Jacopo Mondi wrote: > Migo-R platform uses sh_mobile_ceu camera driver, which is now being > replaced by a proper V4L2 camera driver named 'renesas-ceu'. > > Move Migo-R platform to use the v4l2 renesas-ceu camera driver > interface and get rid of soc_camera defined components used to register > sensor drivers and of platform specific enable/disable routines. > > Register clock source and GPIOs for sensor drivers, so they can use > clock and gpio APIs. > > Also, memory for CEU video buffers is now reserved with membocks APIs, > and need to be declared as dma_coherent during machine initialization to > remove that architecture specific part from CEU driver. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Laurent Pinchart Acked-by: Hans Verkuil Regards, Hans
Re: [PATCH v5 8/9] media: i2c: tw9910: Remove soc_camera dependencies
On 01/12/2018 03:04 PM, Jacopo Mondi wrote: > Remove soc_camera framework dependencies from tw9910 sensor driver. > - Handle clock and gpios > - Register async subdevice > - Remove soc_camera specific g/s_mbus_config operations > - Add kernel doc to driver interface header file > - Adjust build system > > This commit does not remove the original soc_camera based driver as long > as other platforms depends on soc_camera-based CEU driver. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Laurent Pinchart Acked-by: Hans Verkuil Regards, Hans
Re: [PATCH v5 6/9] media: i2c: ov772x: Remove soc_camera dependencies
On 01/12/2018 03:04 PM, Jacopo Mondi wrote:
> Remove soc_camera framework dependencies from ov772x sensor driver.
> - Handle clock and gpios
> - Register async subdevice
> - Remove soc_camera specific g/s_mbus_config operations
> - Change image format colorspace from JPEG to SRGB as the two use the
> same colorspace information but JPEG makes assumptions on color
> components quantization that do not apply to the sensor
> - Remove sizes crop from get_selection as driver can't scale
> - Add kernel doc to driver interface header file
> - Adjust build system
>
> This commit does not remove the original soc_camera based driver as long
> as other platforms depends on soc_camera-based CEU driver.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Laurent Pinchart
> ---
> drivers/media/i2c/Kconfig | 11 +++
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/ov772x.c | 177
> ++---
> include/media/i2c/ov772x.h | 6 +-
> 4 files changed, 133 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index cb5d7ff..a61d7f4 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -645,6 +645,17 @@ config VIDEO_OV5670
> To compile this driver as a module, choose M here: the
> module will be called ov5670.
>
> +config VIDEO_OV772X
> + tristate "OmniVision OV772x sensor support"
> + depends on I2C && VIDEO_V4L2
> + depends on MEDIA_CAMERA_SUPPORT
> + ---help---
> + This is a Video4Linux2 sensor-level driver for the OmniVision
> + OV772x camera.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ov772x.
> +
> config VIDEO_OV7640
> tristate "OmniVision OV7640 sensor support"
> depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 548a9ef..fb99293 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
> obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
> obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
> obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
> +obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
> obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
> obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
> obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> index 8063835..df2516c 100644
> --- a/drivers/media/i2c/ov772x.c
> +++ b/drivers/media/i2c/ov772x.c
> @@ -1,6 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * ov772x Camera Driver
> *
> + * Copyright (C) 2017 Jacopo Mondi
> + *
> * Copyright (C) 2008 Renesas Solutions Corp.
> * Kuninori Morimoto
> *
> @@ -9,27 +12,25 @@
> * Copyright 2006-7 Jonathan Corbet
> * Copyright (C) 2008 Magnus Damm
> * Copyright (C) 2008, Guennadi Liakhovetski
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> */
>
> +#include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> -#include
> #include
> -#include
> #include
> #include
>
> #include
> -#include
> -#include
> +
> #include
> -#include
> +#include
> #include
> +#include
>
> /*
> * register offset
> @@ -393,8 +394,10 @@ struct ov772x_win_size {
> struct ov772x_priv {
> struct v4l2_subdevsubdev;
> struct v4l2_ctrl_handler hdl;
> - struct v4l2_clk *clk;
> + struct clk *clk;
> struct ov772x_camera_info*info;
> + struct gpio_desc *pwdn_gpio;
> + struct gpio_desc *rstb_gpio;
> const struct ov772x_color_format *cfmt;
> const struct ov772x_win_size *win;
> unsigned shortflag_vflip:1;
> @@ -409,7 +412,7 @@ struct ov772x_priv {
> static const struct ov772x_color_format ov772x_cfmts[] = {
> {
> .code = MEDIA_BUS_FMT_YUYV8_2X8,
> - .colorspace = V4L2_COLORSPACE_JPEG,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> .dsp3 = 0x0,
> .dsp4 = DSP_OFMT_YUV,
> .com3 = SWAP_YUV,
> @@ -417,7 +420,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
> },
> {
> .code = MEDIA_BUS_FMT_YVYU8_2X8,
> - .colorspace = V4L2_COLORSPACE_JPEG,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> .dsp3 = UV_ON,
> .dsp4 = DSP_OFMT_YUV,
> .com3 = SWAP_YUV,
> @@ -425,7 +428,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
> },
> {
> .code = MEDIA_BUS_FMT_UYVY8_2X8,
> -
Re: [PATCH v5 4/9] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
On 01/12/2018 03:04 PM, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Geert Uytterhoeven
> Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> arch/arm/boot/dts/r7s72100.dtsi | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
> index ab9645a..5fe62f9 100644
> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -135,9 +135,9 @@
> #clock-cells = <1>;
> compatible = "renesas,r7s72100-mstp-clocks",
> "renesas,cpg-mstp-clocks";
> reg = <0xfcfe042c 4>;
> - clocks = <&p0_clk>;
> - clock-indices = ;
> - clock-output-names = "rtc";
> + clocks = <&b_clk>, <&p0_clk>;
> + clock-indices = ;
> + clock-output-names = "ceu", "rtc";
> };
>
> mstp7_clks: mstp7_clks@fcfe0430 {
> @@ -667,4 +667,13 @@
> power-domains = <&cpg_clocks>;
> status = "disabled";
> };
> +
> + ceu: ceu@e821 {
> + reg = <0xe821 0x3000>;
> + compatible = "renesas,r7s72100-ceu";
> + interrupts = ;
> + clocks = <&mstp6_clks R7S72100_CLK_CEU>;
> + power-domains = <&cpg_clocks>;
> + status = "disabled";
> + };
> };
>
Re: [PATCH v5 1/9] dt-bindings: media: Add Renesas CEU bindings
On 01/12/2018 03:04 PM, Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Rob Herring
> Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> .../devicetree/bindings/media/renesas,ceu.txt | 81
> ++
> 1 file changed, 81 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..590ee27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,81 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found in the Renesas
> +SH Mobile and RZ SoCs.
> +
> +The interface supports a single parallel input with data bus width of 8 or 16
> +bits.
> +
> +Required properties:
> +- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1-H
> + and RZ/A1-M SoCs.
> +- reg: Registers address base and size.
> +- interrupts: The interrupt specifier.
> +
> +The CEU supports a single parallel input and should contain a single 'port'
> +subnode with a single 'endpoint'. Connection to input devices are modeled
> +according to the video interfaces OF bindings specified in:
> +Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Optional endpoint properties applicable to parallel input bus described in
> +the above mentioned "video-interfaces.txt" file are supported.
> +
> +- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH
> respectively.
> + If property is not present, default is active high.
> +- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH
> respectively.
> + If property is not present, default is active high.
> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and an
> +OV7670 image sensor connected to i2c1 interface.
> +
> +ceu: ceu@e821 {
> + reg = <0xe821 0x209c>;
> + compatible = "renesas,r7s72100-ceu";
> + interrupts = ;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&vio_pins>;
> +
> + status = "okay";
> +
> + port {
> + ceu_in: endpoint {
> + remote-endpoint = <&ov7670_out>;
> +
> + hsync-active = <1>;
> + vsync-active = <0>;
> + };
> + };
> +};
> +
> +i2c1: i2c@fcfee400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins>;
> +
> + status = "okay";
> +
> + clock-frequency = <10>;
> +
> + ov7670: camera@21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&vio_pins>;
> +
> + reset-gpios = <&port3 11 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = <&port3 12 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + ov7670_out: endpoint {
> + remote-endpoint = <&ceu_in>;
> +
> + hsync-active = <1>;
> + vsync-active = <0>;
> + };
> + };
> + };
> +};
>
Re: [PATCH v5 7/9] v4l: i2c: Copy tw9910 soc_camera sensor driver
On 01/12/2018 03:04 PM, Jacopo Mondi wrote: > Copy the soc_camera based driver in v4l2 sensor driver directory. > This commit just copies the original file without modifying it. > No modification to KConfig and Makefile as soc_camera framework > dependencies need to be removed first in next commit. > > Signed-off-by: Jacopo Mondi > Acked-by: Laurent Pinchart Acked-by: Hans Verkuil Regards, Hans
Re: [PATCH v5 2/9] include: media: Add Renesas CEU driver interface
On 01/12/2018 03:04 PM, Jacopo Mondi wrote:
> Add renesas-ceu header file.
>
> Do not remove the existing sh_mobile_ceu.h one as long as the original
> driver does not go away.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> include/media/drv-intf/renesas-ceu.h | 26 ++
> 1 file changed, 26 insertions(+)
> create mode 100644 include/media/drv-intf/renesas-ceu.h
>
> diff --git a/include/media/drv-intf/renesas-ceu.h
> b/include/media/drv-intf/renesas-ceu.h
> new file mode 100644
> index 000..52841d1
> --- /dev/null
> +++ b/include/media/drv-intf/renesas-ceu.h
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * renesas-ceu.h - Renesas CEU driver interface
> + *
> + * Copyright 2017-2018 Jacopo Mondi
> + */
> +
> +#ifndef __MEDIA_DRV_INTF_RENESAS_CEU_H__
> +#define __MEDIA_DRV_INTF_RENESAS_CEU_H__
> +
> +#define CEU_MAX_SUBDEVS 2
> +
> +struct ceu_async_subdev {
> + unsigned long flags;
> + unsigned char bus_width;
> + unsigned char bus_shift;
> + unsigned int i2c_adapter_id;
> + unsigned int i2c_address;
> +};
> +
> +struct ceu_platform_data {
> + unsigned int num_subdevs;
> + struct ceu_async_subdev subdevs[CEU_MAX_SUBDEVS];
> +};
> +
> +#endif /* ___MEDIA_DRV_INTF_RENESAS_CEU_H__ */
>
Re: [PATCH v5 5/9] v4l: i2c: Copy ov772x soc_camera sensor driver
On 01/12/2018 03:04 PM, Jacopo Mondi wrote: > Copy the soc_camera based driver in v4l2 sensor driver directory. > This commit just copies the original file without modifying it. > No modification to KConfig and Makefile as soc_camera framework > dependencies need to be removed first in next commit. > > Signed-off-by: Jacopo Mondi > Acked-by: Laurent Pinchart Acked-by: Hans Verkuil Regards, Hans
Re: [PATCH v5 3/9] v4l: platform: Add Renesas CEU driver
Hi Jacopo,
Sorry for the late review, but here is finally is.
BTW, can you provide the v4l2-compliance output (ideally with the -f option)
in the cover letter for v6?
On 01/12/2018 03:04 PM, Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
>
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
>
> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
>
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
>
> Tested with ov7725 camera sensor on SH4 platform Migo-R.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/Kconfig |9 +
> drivers/media/platform/Makefile |1 +
> drivers/media/platform/renesas-ceu.c | 1648
> ++
> 3 files changed, 1658 insertions(+)
> create mode 100644 drivers/media/platform/renesas-ceu.c
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index fd0c998..fe7bd26 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
> To compile this driver as a module, choose M here: the module
> will be called stm32-dcmi.
>
> +config VIDEO_RENESAS_CEU
> + tristate "Renesas Capture Engine Unit (CEU) driver"
> + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> + depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_FWNODE
> + ---help---
> + This is a v4l2 driver for the Renesas CEU Interface
> +
> source "drivers/media/platform/soc_camera/Kconfig"
> source "drivers/media/platform/exynos4-is/Kconfig"
> source "drivers/media/platform/am437x/Kconfig"
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 003b0bb..6580a6b 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -62,6 +62,7 @@ obj-$(CONFIG_VIDEO_SH_VOU) += sh_vou.o
> obj-$(CONFIG_SOC_CAMERA) += soc_camera/
>
> obj-$(CONFIG_VIDEO_RCAR_DRIF)+= rcar_drif.o
> +obj-$(CONFIG_VIDEO_RENESAS_CEU) += renesas-ceu.o
> obj-$(CONFIG_VIDEO_RENESAS_FCP) += rcar-fcp.o
> obj-$(CONFIG_VIDEO_RENESAS_FDP1) += rcar_fdp1.o
> obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o
> diff --git a/drivers/media/platform/renesas-ceu.c
> b/drivers/media/platform/renesas-ceu.c
> new file mode 100644
> index 000..ccca838
> --- /dev/null
> +++ b/drivers/media/platform/renesas-ceu.c
> +/*
> + * ceu_vb2_setup() - is called to check whether the driver can accept the
> + *requested number of buffers and to fill in plane sizes
> + *for the current frame format, if required.
> + */
> +static int ceu_vb2_setup(struct vb2_queue *vq, unsigned int *count,
> + unsigned int *num_planes, unsigned int sizes[],
> + struct device *alloc_devs[])
> +{
> + struct ceu_device *ceudev = vb2_get_drv_priv(vq);
> + struct v4l2_pix_format_mplane *pix = &ceudev->v4l2_pix;
> + unsigned int i;
> +
> + if (!*count)
> + *count = 2;
Don't do this. Instead set the min_buffers_needed field to 2 in the vb2_queue
struct.
> +
> + /* num_planes is set: just check plane sizes. */
> + if (*num_planes) {
> + for (i = 0; i < pix->num_planes; i++)
> + if (sizes[i] < pix->plane_fmt[i].sizeimage)
> + return -EINVAL;
> +
> + return 0;
> + }
> +
> + /* num_planes not set: called from REQBUFS, just set plane sizes. */
> + *num_planes = pix->num_planes;
> + for (i = 0; i < pix->num_planes; i++)
> + sizes[i] = pix->plane_fmt[i].sizeimage;
> +
> + return 0;
> +}
> +
> +static void ceu_vb2_queue(struct vb2_buffer *vb)
> +{
> + struct ceu_device *ceudev = vb2_get_drv_priv(vb->vb2_queue);
> + struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
> + struct v4l2_pix_format_mplane *pix = &ceudev->v4l2_pix;
> + struct ceu_buffer *buf = vb2_to_ceu(vbuf);
> + unsigned long irqflags;
> + unsigned int i;
> +
> + for (i = 0; i < pix->num_planes; i++) {
> + if (vb2_plane_size(vb, i) < pix->plane_fmt[i].sizeimage) {
> + vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
> + return;
> + }
> +
> + vb2_set_plane_payload(vb, i, pix->plane_fmt[i].sizeimage);
This is not the right vb2 op for this test, this belongs in the buf_prepare
op. There you can just return an error and you don't need to call buffer_done.
> + }
> +
> + spin_lock_irqsave(&ceudev->lock, irqflags);
> + list_add_tail(&buf->queue, &ceudev->capture);
> + spin_unlock_irqrestore(&ceudev->lock, irqflags);
> +}
> +
> +static int ceu_start_streaming(struct vb2_queue *vq, unsigned int count)
Re: [PATCH v2] v4l: doc: Clarify v4l2_mbus_fmt height definition
On 01/08/2018 06:55 PM, Kieran Bingham wrote: > The v4l2_mbus_fmt width and height corresponds directly with the > v4l2_pix_format definitions, yet the differences in documentation make > it ambiguous what to do in the event of field heights. > > Clarify this using the same text as is provided for the v4l2_pix_format > which is explicit on the matter, and by matching the terminology of > 'image height' rather than the misleading 'frame height'. > > Signed-off-by: Kieran Bingham Reviewed-by: Hans Verkuil Regards, Hans > --- > v2: > - Duplicated explicit text from v4l2_pix_format rather than >referencing it. > > Documentation/media/uapi/v4l/subdev-formats.rst | 8 ++-- > include/uapi/linux/v4l2-mediabus.h | 4 ++-- > 2 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst > b/Documentation/media/uapi/v4l/subdev-formats.rst > index b1eea44550e1..9fcabe7f9367 100644 > --- a/Documentation/media/uapi/v4l/subdev-formats.rst > +++ b/Documentation/media/uapi/v4l/subdev-formats.rst > @@ -16,10 +16,14 @@ Media Bus Formats > > * - __u32 >- ``width`` > - - Image width, in pixels. > + - Image width in pixels. > * - __u32 >- ``height`` > - - Image height, in pixels. > + - Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``, > + ``V4L2_FIELD_BOTTOM`` or ``V4L2_FIELD_ALTERNATE`` then height > + refers to the number of lines in the field, otherwise it refers to > + the number of lines in the frame (which is twice the field height > + for interlaced formats). > * - __u32 >- ``code`` >- Format code, from enum > diff --git a/include/uapi/linux/v4l2-mediabus.h > b/include/uapi/linux/v4l2-mediabus.h > index 6e20de63ec59..123a231001a8 100644 > --- a/include/uapi/linux/v4l2-mediabus.h > +++ b/include/uapi/linux/v4l2-mediabus.h > @@ -18,8 +18,8 @@ > > /** > * struct v4l2_mbus_framefmt - frame format on the media bus > - * @width: frame width > - * @height: frame height > + * @width: image width > + * @height: image height > * @code:data format code (from enum v4l2_mbus_pixelcode) > * @field: used interlacing type (from enum v4l2_field) > * @colorspace: colorspace of the data (from enum v4l2_colorspace) >
Re: [PATCH v2] media: i2c: adv748x: fix HDMI field heights
On 01/08/2018 07:14 PM, Kieran Bingham wrote:
> The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field
> types. The correct specification for the height on the mbus is the
> image height, in this instance, the field height.
>
> The AFE component already correctly adjusts the height on the mbus, but
> the HDMI component got left behind.
>
> Adjust the mbus height to correctly describe the image height of the
> fields when processing interlaced video for HDMI pipelines.
>
> Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver")
> Reviewed-by: Niklas Söderlund
> Signed-off-by: Kieran Bingham
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> v2:
> - switch conditional to check the fmt->field, removing the need for
>the comment.
>
> drivers/media/i2c/adv748x/adv748x-hdmi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c
> b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> index 4da4253553fc..10d229a4f088 100644
> --- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
> +++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> @@ -105,6 +105,9 @@ static void adv748x_hdmi_fill_format(struct adv748x_hdmi
> *hdmi,
>
> fmt->width = hdmi->timings.bt.width;
> fmt->height = hdmi->timings.bt.height;
> +
> + if (fmt->field == V4L2_FIELD_ALTERNATE)
> + fmt->height /= 2;
> }
>
> static void adv748x_fill_optional_dv_timings(struct v4l2_dv_timings *timings)
>
Re: [PATCH] v4l: doc: clarify v4l2_mbus_fmt height definition
On 01/08/2018 05:11 PM, Niklas Söderlund wrote: > On 2018-01-08 16:48:35 +0100, Hans Verkuil wrote: >> On 01/08/2018 04:32 PM, Niklas Söderlund wrote: >>> Hi, >>> >>> Thanks for your patch. >>> >>> On 2018-01-08 17:13:53 +0200, Sakari Ailus wrote: >>>> Hi Kieran, >>>> >>>> On Mon, Jan 08, 2018 at 02:45:49PM +, Kieran Bingham wrote: >>>>> The v4l2_mbus_fmt width and height corresponds directly with the >>>>> v4l2_pix_format definitions, yet the differences in documentation make >>>>> it ambiguous what to do in the event of field heights. >>>>> >>>>> Clarify this by referencing the v4l2_pix_format which is explicit on the >>>>> matter, and by matching the terminology of 'image height' rather than >>>>> the misleading 'frame height'. >>> >>> Nice that this relationship is documented as it have contributed to some >>> confusion on my side in the past! >>> >>>>> >>>>> Signed-off-by: Kieran Bingham >>>>> --- >>>>> Documentation/media/uapi/v4l/subdev-formats.rst | 6 -- >>>>> include/uapi/linux/v4l2-mediabus.h | 4 ++-- >>>>> 2 files changed, 6 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst >>>>> b/Documentation/media/uapi/v4l/subdev-formats.rst >>>>> index b1eea44550e1..a2a00202b430 100644 >>>>> --- a/Documentation/media/uapi/v4l/subdev-formats.rst >>>>> +++ b/Documentation/media/uapi/v4l/subdev-formats.rst >>>>> @@ -16,10 +16,12 @@ Media Bus Formats >>>>> >>>>> * - __u32 >>>>>- ``width`` >>>>> - - Image width, in pixels. >>>>> + - Image width in pixels. See struct >>>>> + :c:type:`v4l2_pix_format`. >>>>> * - __u32 >>>>>- ``height`` >>>>> - - Image height, in pixels. >>>>> + - Image height in pixels. See struct >>>>> + :c:type:`v4l2_pix_format`. >>>>> * - __u32 >>>>>- ``code`` >>>>>- Format code, from enum >>>>> diff --git a/include/uapi/linux/v4l2-mediabus.h >>>>> b/include/uapi/linux/v4l2-mediabus.h >>>>> index 6e20de63ec59..6b34108d0338 100644 >>>>> --- a/include/uapi/linux/v4l2-mediabus.h >>>>> +++ b/include/uapi/linux/v4l2-mediabus.h >>>>> @@ -18,8 +18,8 @@ >>>>> >>>>> /** >>>>> * struct v4l2_mbus_framefmt - frame format on the media bus >>>>> - * @width: frame width >>>>> - * @height: frame height >>>>> + * @width: image width >>>>> + * @height: image height (see struct v4l2_pix_format) >>>> >>>> Hmm. This is the media bus format and it has no direct relation to >>>> v4l2_pix_format. So no, I can't see what would be the point in making such >>>> a reference. >>> >>> Well we have functions like v4l2_fill_pix_format() that do >>> >>> pix_fmt->width = mbus_fmt->width; >>> pix_fmt->height = mbus_fmt->height; >>> >>> So I think there at least is an implicit relation between the two >>> structs. The issue I think Kieran is trying to address is in the case of >>> TOP, BOTTOM and ALTERNATE field formats. From the v4l2_pix_format >>> documentation on the height field: >>> >>>"Image height in pixels. If field is one of V4L2_FIELD_TOP, >>>V4L2_FIELD_BOTTOM or V4L2_FIELD_ALTERNATE then height refers to the >>>number of lines in the field, otherwise it refers to the number of >>>lines in the frame (which is twice the field height for interlaced >>>formats)." >> >> Right, and I'd just copy this text to subdev-formats.rst rather than >> referring >> to it. >> >>> >>> But there are no such clear definition of the height field for >>> v4l2_mbus_framefmt. This have cased some confusion for us which would be >>> nice to clarify. I think it would be a good thing to add to the >>> documentation if the height in v4l2_mbus_framefmt should describe the >>> height of a frame or field. And if it should represent the frame height >>> then v4l2_fill_pix_format() and v4l
Re: [PATCH] v4l: doc: clarify v4l2_mbus_fmt height definition
On 01/08/2018 04:32 PM, Niklas Söderlund wrote: > Hi, > > Thanks for your patch. > > On 2018-01-08 17:13:53 +0200, Sakari Ailus wrote: >> Hi Kieran, >> >> On Mon, Jan 08, 2018 at 02:45:49PM +, Kieran Bingham wrote: >>> The v4l2_mbus_fmt width and height corresponds directly with the >>> v4l2_pix_format definitions, yet the differences in documentation make >>> it ambiguous what to do in the event of field heights. >>> >>> Clarify this by referencing the v4l2_pix_format which is explicit on the >>> matter, and by matching the terminology of 'image height' rather than >>> the misleading 'frame height'. > > Nice that this relationship is documented as it have contributed to some > confusion on my side in the past! > >>> >>> Signed-off-by: Kieran Bingham >>> --- >>> Documentation/media/uapi/v4l/subdev-formats.rst | 6 -- >>> include/uapi/linux/v4l2-mediabus.h | 4 ++-- >>> 2 files changed, 6 insertions(+), 4 deletions(-) >>> >>> diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst >>> b/Documentation/media/uapi/v4l/subdev-formats.rst >>> index b1eea44550e1..a2a00202b430 100644 >>> --- a/Documentation/media/uapi/v4l/subdev-formats.rst >>> +++ b/Documentation/media/uapi/v4l/subdev-formats.rst >>> @@ -16,10 +16,12 @@ Media Bus Formats >>> >>> * - __u32 >>>- ``width`` >>> - - Image width, in pixels. >>> + - Image width in pixels. See struct >>> + :c:type:`v4l2_pix_format`. >>> * - __u32 >>>- ``height`` >>> - - Image height, in pixels. >>> + - Image height in pixels. See struct >>> + :c:type:`v4l2_pix_format`. >>> * - __u32 >>>- ``code`` >>>- Format code, from enum >>> diff --git a/include/uapi/linux/v4l2-mediabus.h >>> b/include/uapi/linux/v4l2-mediabus.h >>> index 6e20de63ec59..6b34108d0338 100644 >>> --- a/include/uapi/linux/v4l2-mediabus.h >>> +++ b/include/uapi/linux/v4l2-mediabus.h >>> @@ -18,8 +18,8 @@ >>> >>> /** >>> * struct v4l2_mbus_framefmt - frame format on the media bus >>> - * @width: frame width >>> - * @height:frame height >>> + * @width: image width >>> + * @height:image height (see struct v4l2_pix_format) >> >> Hmm. This is the media bus format and it has no direct relation to >> v4l2_pix_format. So no, I can't see what would be the point in making such >> a reference. > > Well we have functions like v4l2_fill_pix_format() that do > > pix_fmt->width = mbus_fmt->width; > pix_fmt->height = mbus_fmt->height; > > So I think there at least is an implicit relation between the two > structs. The issue I think Kieran is trying to address is in the case of > TOP, BOTTOM and ALTERNATE field formats. From the v4l2_pix_format > documentation on the height field: > >"Image height in pixels. If field is one of V4L2_FIELD_TOP, >V4L2_FIELD_BOTTOM or V4L2_FIELD_ALTERNATE then height refers to the >number of lines in the field, otherwise it refers to the number of >lines in the frame (which is twice the field height for interlaced >formats)." Right, and I'd just copy this text to subdev-formats.rst rather than referring to it. > > But there are no such clear definition of the height field for > v4l2_mbus_framefmt. This have cased some confusion for us which would be > nice to clarify. I think it would be a good thing to add to the > documentation if the height in v4l2_mbus_framefmt should describe the > height of a frame or field. And if it should represent the frame height > then v4l2_fill_pix_format() and v4l2_fill_mbus_format() should be > updated to support converting from the two different formats for height. And that makes no sense as it would make things even more difficult. So I believe it's best to be clear about it and talk about image height instead of frame height. Just double check first in the code if there are any subdevs that support TOP/BOTTOM/ALTERNATE and how they fill in the height, I don't think we have any at the moment, but I'm not 100% certain. Regards, Hans > >> >>> * @code: data format code (from enum v4l2_mbus_pixelcode) >>> * @field: used interlacing type (from enum v4l2_field) >>> * @colorspace:colorspace of the data (from enum v4l2_colorspace) >> >> -- >> Regards, >> >> Sakari Ailus >> e-mail: sakari.ai...@iki.fi >
Re: [PATCH] v4l: rcar-csi2: Don't bail out from probe on no ep
Niklas,
Did you look at this? If I should take it, can you Ack it? If you are
going to squash or add it to our of your own patch series, then let me
know and I can remove it from my todo queue.
Regards,
Hans
On 05/12/17 21:41, Jacopo Mondi wrote:
> When rcar-csi interface is not connected to any endpoint, it fails and
> bails out from probe before registering its own video subdevice.
> This prevents rcar-vin registered notifier from completing and no
> subdevice is ever registered, also for other properly connected csi
> interfaces.
>
> Fix this not returning an error when no endpoint is connected to a csi
> interface and let the driver complete its probe function and register its
> own video subdevice.
>
> ---
> Niklas,
>please squash this patch in your next rcar-csi2 series (if you like it ;)
>
> As we have discussed this is particularly useful for gmsl setup, where adv748x
> is connected to CSI20 and max9286 to CSI40/CSI41. If we disable adv748x from
> DTS
> we need CSI20 probe to complete anyhow otherwise no subdevice gets registered
> for the two deserializers.
>
> Please note we cannot disable CSI20 entirely otherwise VIN's graph parsing
> breaks.
>
> Thanks
>j
>
> ---
> drivers/media/platform/rcar-vin/rcar-csi2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index 2793efb..90c4062 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -928,8 +928,8 @@ static int rcar_csi2_parse_dt(struct rcar_csi2 *priv)
>
> ep = of_graph_get_endpoint_by_regs(priv->dev->of_node, 0, 0);
> if (!ep) {
> - dev_err(priv->dev, "Not connected to subdevice\n");
> - return -EINVAL;
> + dev_dbg(priv->dev, "Not connected to subdevice\n");
> + return 0;
> }
>
> ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &v4l2_ep);
> --
> 2.7.4
>
Re: [PATCH v1 10/10] media: i2c: tw9910: Remove soc_camera dependencies
On 15/11/17 11:56, Jacopo Mondi wrote:
> Remove soc_camera framework dependencies from tw9910 sensor driver.
> - Handle clock directly
> - Register async subdevice
> - Add platform specific enable/disable functions
> - Adjust build system
>
> This commit does not remove the original soc_camera based driver.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/Kconfig | 9 ++
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/tw9910.c | 80
> ++
> include/media/i2c/tw9910.h | 6
> 4 files changed, 75 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index ff251ce..bbd77ee 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -415,6 +415,15 @@ config VIDEO_TW9906
> To compile this driver as a module, choose M here: the
> module will be called tw9906.
>
> +config VIDEO_TW9910
> + tristate "Techwell TW9910 video decoder"
> + depends on VIDEO_V4L2 && I2C
> + ---help---
> + Support for Techwell TW9910 NTSC/PAL/SECAM video decoder.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called tw9910.
> +
> config VIDEO_VPX3220
> tristate "vpx3220a, vpx3216b & vpx3214c video decoders"
> depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index b2459a1..835784a 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
> obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
> obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
> obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
> +obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
> obj-$(CONFIG_VIDEO_CS3308) += cs3308.o
> obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
> obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
> diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
> index bdb5e0a..f422da2 100644
> --- a/drivers/media/i2c/tw9910.c
> +++ b/drivers/media/i2c/tw9910.c
> @@ -16,6 +16,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include
> #include
> #include
> @@ -25,9 +26,7 @@
> #include
> #include
>
> -#include
> #include
> -#include
> #include
>
> #define GET_ID(val) ((val & 0xF8) >> 3)
> @@ -228,7 +227,7 @@ struct tw9910_scale_ctrl {
>
> struct tw9910_priv {
> struct v4l2_subdev subdev;
> - struct v4l2_clk *clk;
> + struct clk *clk;
> struct tw9910_video_info*info;
> const struct tw9910_scale_ctrl *scale;
> v4l2_std_id norm;
> @@ -582,13 +581,40 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
> }
> #endif
>
> +static int tw9910_power_on(struct tw9910_priv *priv)
> +{
> + int ret;
> +
> + if (priv->info->platform_enable) {
> + ret = priv->info->platform_enable();
> + if (ret)
> + return ret;
> + }
> +
> + if (priv->clk)
> + return clk_enable(priv->clk);
> +
> + return 0;
> +}
> +
> +static int tw9910_power_off(struct tw9910_priv *priv)
> +{
> + if (priv->info->platform_enable)
> + priv->info->platform_disable();
> +
> + if (priv->clk)
> + clk_disable(priv->clk);
> +
> + return 0;
> +}
> +
> static int tw9910_s_power(struct v4l2_subdev *sd, int on)
> {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> struct tw9910_priv *priv = to_tw9910(client);
>
> - return soc_camera_set_power(&client->dev, ssdd, priv->clk, on);
> + return on ? tw9910_power_on(priv) :
> + tw9910_power_off(priv);
> }
>
> static int tw9910_set_frame(struct v4l2_subdev *sd, u32 *width, u32 *height)
> @@ -614,7 +640,7 @@ static int tw9910_set_frame(struct v4l2_subdev *sd, u32
> *width, u32 *height)
>* set bus width
>*/
> val = 0x00;
> - if (SOCAM_DATAWIDTH_16 == priv->info->buswidth)
> + if (priv->info->buswidth == TW9910_DATAWIDTH_16)
> val = LEN;
>
> ret = tw9910_mask_set(client, OPFORM, LEN, val);
> @@ -799,8 +825,8 @@ static int tw9910_video_probe(struct i2c_client *client)
> /*
>* tw9910 only use 8 or 16 bit bus width
>*/
> - if (SOCAM_DATAWIDTH_16 != priv->info->buswidth &&
> - SOCAM_DATAWIDTH_8 != priv->info->buswidth) {
> + if (priv->info->buswidth != TW9910_DATAWIDTH_16 &&
> + priv->info->buswidth != TW9910_DATAWIDTH_8) {
> dev_err(&client->dev, "bus width error\n");
> return -ENODEV;
> }
> @@ -859,15 +885,11 @@ static int tw9910_enum_mbus_code(struct v4l2_subdev *sd,
> static int tw9910_g_mbus_config(struct v4l2_subdev *sd,
> struct v4l2_mbus_config *cfg)
> {
> - struct i2c_client *client
Re: [PATCH v1 07/10] v4l: i2c: Copy ov772x soc_camera sensor driver
On 15/11/17 11:56, Jacopo Mondi wrote: > Copy the soc_camera based driver in v4l2 sensor driver directory. > This commit just copies the original file without modifying it. > > Signed-off-by: Jacopo Mondi > --- > drivers/media/i2c/ov772x.c | 1124 > > 1 file changed, 1124 insertions(+) > create mode 100644 drivers/media/i2c/ov772x.c > > diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c > new file mode 100644 > index 000..8063835 > --- /dev/null > +++ b/drivers/media/i2c/ov772x.c > @@ -0,0 +1,1124 @@ > +/* > + * ov772x Camera Driver > + * > + * Copyright (C) 2008 Renesas Solutions Corp. > + * Kuninori Morimoto > + * > + * Based on ov7670 and soc_camera_platform driver, > + * > + * Copyright 2006-7 Jonathan Corbet > + * Copyright (C) 2008 Magnus Damm > + * Copyright (C) 2008, Guennadi Liakhovetski > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* > + * register offset > + */ > +#define GAIN0x00 /* AGC - Gain control gain setting */ > +#define BLUE0x01 /* AWB - Blue channel gain setting */ > +#define RED 0x02 /* AWB - Red channel gain setting */ > +#define GREEN 0x03 /* AWB - Green channel gain setting */ > +#define COM10x04 /* Common control 1 */ > +#define BAVG0x05 /* U/B Average Level */ > +#define GAVG0x06 /* Y/Gb Average Level */ > +#define RAVG0x07 /* V/R Average Level */ > +#define AECH0x08 /* Exposure Value - AEC MSBs */ > +#define COM20x09 /* Common control 2 */ > +#define PID 0x0A /* Product ID Number MSB */ > +#define VER 0x0B /* Product ID Number LSB */ > +#define COM30x0C /* Common control 3 */ > +#define COM40x0D /* Common control 4 */ > +#define COM50x0E /* Common control 5 */ > +#define COM60x0F /* Common control 6 */ > +#define AEC 0x10 /* Exposure Value */ > +#define CLKRC 0x11 /* Internal clock */ > +#define COM70x12 /* Common control 7 */ > +#define COM80x13 /* Common control 8 */ > +#define COM90x14 /* Common control 9 */ > +#define COM10 0x15 /* Common control 10 */ > +#define REG16 0x16 /* Register 16 */ > +#define HSTART 0x17 /* Horizontal sensor size */ > +#define HSIZE 0x18 /* Horizontal frame (HREF column) end high 8-bit */ > +#define VSTART 0x19 /* Vertical frame (row) start high 8-bit */ > +#define VSIZE 0x1A /* Vertical sensor size */ > +#define PSHFT 0x1B /* Data format - pixel delay select */ > +#define MIDH0x1C /* Manufacturer ID byte - high */ > +#define MIDL0x1D /* Manufacturer ID byte - low */ > +#define LAEC0x1F /* Fine AEC value */ > +#define COM11 0x20 /* Common control 11 */ > +#define BDBASE 0x22 /* Banding filter Minimum AEC value */ > +#define DBSTEP 0x23 /* Banding filter Maximum Setp */ > +#define AEW 0x24 /* AGC/AEC - Stable operating region (upper limit) > */ > +#define AEB 0x25 /* AGC/AEC - Stable operating region (lower limit) > */ > +#define VPT 0x26 /* AGC/AEC Fast mode operating region */ > +#define REG28 0x28 /* Register 28 */ > +#define HOUTSIZE0x29 /* Horizontal data output size MSBs */ > +#define EXHCH 0x2A /* Dummy pixel insert MSB */ > +#define EXHCL 0x2B /* Dummy pixel insert LSB */ > +#define VOUTSIZE0x2C /* Vertical data output size MSBs */ > +#define ADVFL 0x2D /* LSB of insert dummy lines in Vertical direction > */ > +#define ADVFH 0x2E /* MSG of insert dummy lines in Vertical direction > */ > +#define YAVE0x2F /* Y/G Channel Average value */ > +#define LUMHTH 0x30 /* Histogram AEC/AGC Luminance high level threshold > */ > +#define LUMLTH 0x31 /* Histogram AEC/AGC Luminance low level threshold > */ > +#define HREF0x32 /* Image start and size control */ > +#define DM_LNL 0x33 /* Dummy line low 8 bits */ > +#define DM_LNH 0x34 /* Dummy line high 8 bits */ > +#define ADOFF_B 0x35 /* AD offset compensation value for B channel */ > +#define ADOFF_R 0x36 /* AD offset compensation value for R channel */ > +#define ADOFF_GB0x37 /* AD offset compensation value for Gb channel */ > +#define ADOFF_GR0x38 /* AD offset compensation value for Gr channel */ > +#define OFF_B 0x39 /* Analog process B channel offset value */ > +#define OFF_R 0x3A /* Analog process R channel offset value */ > +#define OFF_GB 0x3B /* Analog process Gb channel offset value */ > +#define OFF_GR 0x3C /* Analog process Gr channel offset value */ > +#define COM12 0x3D
Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver
On 15/11/17 11:55, Jacopo Mondi wrote: > Add driver for Renesas Capture Engine Unit (CEU). > > The CEU interface supports capturing 'data' (YUV422) and 'images' > (NV[12|21|16|61]). > > This driver aims to replace the soc_camera based sh_mobile_ceu one. > > Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ > platform GR-Peach. > > Tested with ov7725 camera sensor on SH4 platform Migo-R. > > Signed-off-by: Jacopo Mondi > --- > drivers/media/platform/Kconfig |9 + > drivers/media/platform/Makefile |2 + > drivers/media/platform/renesas-ceu.c | 1768 > ++ > 3 files changed, 1779 insertions(+) > create mode 100644 drivers/media/platform/renesas-ceu.c > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 3c4f7fa..401caea 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI > To compile this driver as a module, choose M here: the module > will be called stm32-dcmi. > > +config VIDEO_RENESAS_CEU > + tristate "Renesas Capture Engine Unit (CEU) driver" > + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA > + depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST > + select VIDEOBUF2_DMA_CONTIG > + select V4L2_FWNODE > + ---help--- > + This is a v4l2 driver for the Renesas CEU Interface > + > source "drivers/media/platform/soc_camera/Kconfig" > source "drivers/media/platform/exynos4-is/Kconfig" > source "drivers/media/platform/am437x/Kconfig" > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile > index 327f80a..0d1f02b 100644 > --- a/drivers/media/platform/Makefile > +++ b/drivers/media/platform/Makefile > @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_CODA)+= coda/ > > obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o > > +obj-$(CONFIG_VIDEO_RENESAS_CEU) += renesas-ceu.o > + > obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o > > obj-$(CONFIG_VIDEO_MUX) += video-mux.o > diff --git a/drivers/media/platform/renesas-ceu.c > b/drivers/media/platform/renesas-ceu.c > new file mode 100644 > index 000..aaba3cd > --- /dev/null > +++ b/drivers/media/platform/renesas-ceu.c > @@ -0,0 +1,1768 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface > + * > + * Copyright (C) 2017 Jacopo Mondi > + * > + * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c" > + * Copyright (C) 2008 Magnus Damm > + * > + * Based on V4L2 Driver for PXA camera host - "pxa_camera.c", > + * Copyright (C) 2006, Sascha Hauer, Pengutronix > + * Copyright (C) 2008, Guennadi Liakhovetski > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define DRIVER_NAME "renesas-ceu" > + > +/* > > + * CEU registers offsets and masks > + */ > +#define CEU_CAPSR0x00 /* Capture start register */ > +#define CEU_CAPCR0x04 /* Capture control register*/ > +#define CEU_CAMCR0x08 /* Capture interface control register */ > +#define CEU_CAMOR0x10 /* Capture interface offset register */ > +#define CEU_CAPWR0x14 /* Capture interface width register*/ > +#define CEU_CAIFR0x18 /* Capture interface input format register */ > +#define CEU_CRCNTR 0x28 /* CEU register control register */ > +#define CEU_CRCMPR 0x2c /* CEU register forcible control register */ > +#define CEU_CFLCR0x30 /* Capture filter control register */ > +#define CEU_CFSZR0x34 /* Capture filter size clip register */ > +#define CEU_CDWDR0x38 /* Capture destination width register */ > +#define CEU_CDAYR0x3c /* Capture data address Y register */ > +#define CEU_CDACR0x40 /* Capture data address C register */ > +#define CEU_CFWCR0x5c /* Firewall operation control register */ > +#define CEU_CDOCR0x64 /* Capture data output control register*/ > +#define CEU_CEIER0x70 /* Capture event interrupt enable register */ > +#define CEU_CETCR0x74 /* Capture event flag clear register */ > +#define CEU_CSTSR0x7c /* Capture status register */ > +#define CEU_CSRT
Re: [PATCH v9 19/28] rcar-vin: use different v4l2 operations in media controller mode
Hi Laurent,
>> +static const struct v4l2_ioctl_ops rvin_mc_ioctl_ops = {
>> +.vidioc_querycap= rvin_querycap,
>> +.vidioc_try_fmt_vid_cap = rvin_mc_try_fmt_vid_cap,
>> +.vidioc_g_fmt_vid_cap = rvin_g_fmt_vid_cap,
>> +.vidioc_s_fmt_vid_cap = rvin_mc_s_fmt_vid_cap,
>> +.vidioc_enum_fmt_vid_cap= rvin_enum_fmt_vid_cap,
>> +
>> +.vidioc_enum_input = rvin_mc_enum_input,
>> +.vidioc_g_input = rvin_g_input,
>> +.vidioc_s_input = rvin_s_input,
>
> The input API makes no sense for MC-based devices.
We've had this discussion before:
https://patchwork.linuxtv.org/patch/41857/
There was never a v3 of that patch, so nothing was done with it.
The issue here is that the spec requires G/S_INPUT to be present for
video nodes. There currently is no exception for MC devices.
Regards,
Hans
Re: [PATCH v9 03/28] rcar-vin: unregister video device on driver removal
On 12/08/2017 08:54 AM, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Friday, 8 December 2017 03:08:17 EET Niklas Söderlund wrote:
>> If the video device was registered by the complete() callback it should
>> be unregistered when the driver is removed.
>
> The .remove() operation indicates device removal, not driver removal (or, the
> be more precise, it indicates that the device is unbound from the driver).
> I'd
> update the commit message accordingly.
>
>> Protect from printing an uninitialized video device node name by adding a
>> check in rvin_v4l2_unregister() to identify that the video device is
>> registered.
>>
>> Signed-off-by: Niklas Söderlund
>> Reviewed-by: Kieran Bingham
>> Reviewed-by: Hans Verkuil
>> ---
>> drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
>> drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 +++
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
>> b/drivers/media/platform/rcar-vin/rcar-core.c index
>> f7a4c21909da6923..6d99542ec74b49a7 100644
>> --- a/drivers/media/platform/rcar-vin/rcar-core.c
>> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
>> @@ -272,6 +272,8 @@ static int rcar_vin_remove(struct platform_device *pdev)
>>
>> pm_runtime_disable(&pdev->dev);
>>
>> +rvin_v4l2_unregister(vin);
>
> Unless I'm mistaken, you're unregistering the video device both here and in
> the unbound() function. That's messy, but it's not really your fault, the
> V4L2
> core is very messy in the first place, and registering video devices in the
> complete() handler is a bad idea. As that can't be fixed for now,
>
> Acked-by: Laurent Pinchart
>
> Hans, I still would like to hear your opinion on how this should be solved.
> You've voiced a few weeks ago that register video devices at probe() time
> isn't a good idea but you've never explained how we should fix the problem. I
> still firmly believe that video devices should be registered at probe time,
> and we need to reach an agreement on a technical solution to this problem.
I have tentatively planned to look into this next week. What will very likely
have to happen is that we need to split off allocation from the registration,
just as is done in most other subsystems. Allocation can be done at probe time,
but the final registration step should likely be in the complete().
To what extent that will resolve this specific issue I don't know. It will take
me time to understand this in more detail.
Regards,
Hans
>
>> v4l2_async_notifier_unregister(&vin->notifier);
>> v4l2_async_notifier_cleanup(&vin->notifier);
>>
>> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
>> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
>> 178aecc94962abe2..32a658214f48fa49 100644
>> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
>> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
>> @@ -841,6 +841,9 @@ static const struct v4l2_file_operations rvin_fops = {
>>
>> void rvin_v4l2_unregister(struct rvin_dev *vin)
>> {
>> +if (!video_is_registered(&vin->vdev))
>> +return;
>> +
>> v4l2_info(&vin->v4l2_dev, "Removing %s\n",
>>video_device_node_name(&vin->vdev));
>
Re: [PATCH] v4l: rcar-vin: Implement V4L2 video node release handler
On 12/04/2017 02:34 PM, Niklas Söderlund wrote: > Hi Hans, > > On 2017-12-04 10:05:35 +0100, Hans Verkuil wrote: >> Hi Niklas, >> >> On 11/16/2017 01:27 AM, Laurent Pinchart wrote: >>> Hi Niklas, >>> >>> On Thursday, 16 November 2017 01:34:33 EET Niklas Söderlund wrote: >>>> On 2017-11-16 00:49:07 +0200, Laurent Pinchart wrote: >>>>> The rvin_dev data structure contains driver private data for an instance >>>>> of the VIN. It is allocated dynamically at probe time, and must be freed >>>>> once all users are gone. >>>>> >>>>> The structure is currently allocated with devm_kzalloc(), which results >>>>> in memory being freed when the device is unbound. If a userspace >>>>> application is currently performing an ioctl call, or just keeps the >>>>> device node open and closes it later, this will lead to accessing freed >>>>> memory. >>>>> >>>>> Fix the problem by implementing a V4L2 release handler for the video >>>>> node associated with the VIN instance (called when the last user of the >>>>> video node releases it), and freeing memory explicitly from the release >>>>> handler. >>>>> >>>>> Signed-off-by: Laurent Pinchart >>>>> >>>> >>>> Acked-by: Niklas Söderlund >>>> >>>> This patch is based on-top of the VIN Gen3 enablement series not yet >>>> upstream. This is OK for me, just wanted to check that this was the >>>> intention as to minimize conflicts between the two. >>> >>> Yes, that's my intention. The patch should be included, or possibly >>> squashed >>> in, your development branch. >>> >> >> Has this patch been added in your v8 series? If not, can you add it when you >> post a v9? > > This patch needs more work, with the video device now registered at > complete() time and unregistered at unbind() time. Applying this would > free the rcar-vin private data structure at unbind() which probably not > what we want. > > I think this issue should be addressed but maybe together with a > patch-set targeting the generic problem with video device lifetimes in > v4l2 framework? For now I would be happy to focus on getting Gen3 > support picked-up and observe what Laurent's work on lifetime issues > brings and adept the rcar-vin driver to take advantage of that once it's > ready. OK. I marked the patch as "Obsoleted" so it doesn't stick around in my patch list. Regards, Hans
Re: [PATCH v8 23/28] rcar-vin: parse Gen3 OF and setup media graph
On 11/29/2017 08:43 PM, Niklas Söderlund wrote:
> Parse the VIN Gen3 OF graph and register all CSI-2 devices in the VIN
> group common media device. Once all CSI-2 subdevices are added to the
> common media device create links between them.
>
> The parsing and registering CSI-2 subdevices with the v4l2 async
> framework is a collaborative effort shared between the VIN instances
> which are part of the group. The first rcar-vin instance parses OF and
> finds all other VIN and CSI-2 nodes which are part of the graph. It
> stores a bit mask of all VIN instances found and handles to all CSI-2
> nodes.
>
> The bit mask is used to figure out when all VIN instances have been
> probed. Once the last VIN instance is probed this is detected and this
> instance registers all CSI-2 subdevices in its private async notifier.
> Once the .complete() callback of this notifier is called it register all
register -> registers
> video devices and creates the media controller links between all
> entities.
>
> Signed-off-by: Niklas Söderlund
With that small change and the fix for the issue you found in rvin_group_init():
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 322
> +++-
> drivers/media/platform/rcar-vin/rcar-vin.h | 10 +-
> 2 files changed, 327 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index a6713fd61dd87a88..2081637e493e1941 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -86,6 +86,7 @@ static struct rvin_group *__rvin_group_allocate(struct
> rvin_dev *vin)
> return NULL;
>
> kref_init(&group->refcount);
> + group->notifier = NULL;
> rvin_group_data = group;
>
> vin_dbg(vin, "%s: alloc group=%p\n", __func__, group);
> @@ -392,10 +393,281 @@ static int rvin_digital_graph_init(struct rvin_dev
> *vin)
> * Group async notifier
> */
>
> -static int rvin_group_init(struct rvin_dev *vin)
> +/* group lock should be held when calling this function */
> +static int rvin_group_add_link(struct rvin_dev *vin,
> +struct media_entity *source,
> +unsigned int source_idx,
> +struct media_entity *sink,
> +unsigned int sink_idx,
> +u32 flags)
> +{
> + struct media_pad *source_pad, *sink_pad;
> + int ret = 0;
> +
> + source_pad = &source->pads[source_idx];
> + sink_pad = &sink->pads[sink_idx];
> +
> + if (!media_entity_find_link(source_pad, sink_pad))
> + ret = media_create_pad_link(source, source_idx,
> + sink, sink_idx, flags);
> +
> + if (ret)
> + vin_err(vin, "Error adding link from %s to %s\n",
> + source->name, sink->name);
> +
> + return ret;
> +}
> +
> +static int rvin_group_update_links(struct rvin_dev *vin)
> +{
> + struct media_entity *source, *sink;
> + struct rvin_dev *master;
> + unsigned int i, n, idx, csi;
> + int ret = 0;
> +
> + mutex_lock(&vin->group->lock);
> +
> + for (n = 0; n < RCAR_VIN_NUM; n++) {
> +
> + /* Check that VIN is part of the group */
> + if (!vin->group->vin[n])
> + continue;
> +
> + /* Check that subgroup master is part of the group */
> + master = vin->group->vin[n < 4 ? 0 : 4];
> + if (!master)
> + continue;
> +
> + for (i = 0; i < vin->info->num_chsels; i++) {
> + csi = vin->info->chsels[n][i].csi;
> +
> + /* If the CSI-2 is out of bounds it's a noop, skip */
> + if (csi >= RVIN_CSI_MAX)
> + continue;
> +
> + /* Check that CSI-2 are part of the group */
> + if (!vin->group->csi[csi].subdev)
> + continue;
> +
> + source = &vin->group->csi[csi].subdev->entity;
> + sink = &vin->group->vin[n]->vdev.entity;
> + idx = vin->info->chsels[n][i].chan + 1;
> +
> + ret = rvin_group_add_link(vin, source, idx, sink, 0,
> + 0);
> + if (ret)
> +
Re: [PATCH v8 28/28] rcar-vin: enable support for r8a77970
On 11/29/2017 08:43 PM, Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a77970.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> .../devicetree/bindings/media/rcar_vin.txt | 1 +
> drivers/media/platform/rcar-vin/rcar-core.c| 40
> ++
> 2 files changed, 41 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 314743532bbb4523..6b98f8a3398fa493 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -21,6 +21,7 @@ on Gen3 to a CSI-2 receiver.
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7796" for the R8A7796 device
> + - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 62eb89b36fbb2ee1..bbdf36b5c3c8178d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1145,6 +1145,42 @@ static const struct rvin_info rcar_info_r8a7796 = {
> },
> };
>
> +static const struct rvin_info rcar_info_r8a77970 = {
> + .chip = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> +
> + .num_chsels = 5,
> + .chsels = {
> + {
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + }, {
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 1 },
> + { .csi = RVIN_NC, .chan = 0 },
> + }, {
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 2 },
> + { .csi = RVIN_NC, .chan = 0 },
> + }, {
> + { .csi = RVIN_CSI40, .chan = 1 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 3 },
> + { .csi = RVIN_NC, .chan = 0 },
> + },
> + },
> +};
> +
> static const struct of_device_id rvin_of_id_table[] = {
> {
> .compatible = "renesas,vin-r8a7778",
> @@ -1182,6 +1218,10 @@ static const struct of_device_id rvin_of_id_table[] = {
> .compatible = "renesas,vin-r8a7796",
> .data = &rcar_info_r8a7796,
> },
> + {
> + .compatible = "renesas,vin-r8a77970",
> + .data = &rcar_info_r8a77970,
> + },
> { },
> };
> MODULE_DEVICE_TABLE(of, rvin_of_id_table);
>
Re: [PATCH v8 04/28] rcar-vin: move subdevice handling to async callbacks
On 11/29/2017 08:43 PM, Niklas Söderlund wrote:
> In preparation for Gen3 support move the subdevice initialization and
> clean up from rvin_v4l2_{register,unregister}() directly to the async
> callbacks. This simplifies the addition of Gen3 support as the
> rvin_v4l2_register() can be shared for both Gen2 and Gen3 while direct
> subdevice control are only used on Gen2.
>
> While moving this code drop a large comment which is copied from the
> framework documentation and fold rvin_mbus_supported() into its only
> caller.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 105
> ++--
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 35 --
> 2 files changed, 67 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 6d99542ec74b49a7..6ab51acd676641ec 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -46,47 +46,11 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int
> direction)
> return -EINVAL;
> }
>
> -static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
> -{
> - struct v4l2_subdev *sd = entity->subdev;
> - struct v4l2_subdev_mbus_code_enum code = {
> - .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> - };
> -
> - code.index = 0;
> - code.pad = entity->source_pad;
> - while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, &code)) {
> - code.index++;
> - switch (code.code) {
> - case MEDIA_BUS_FMT_YUYV8_1X16:
> - case MEDIA_BUS_FMT_UYVY8_2X8:
> - case MEDIA_BUS_FMT_UYVY10_2X10:
> - case MEDIA_BUS_FMT_RGB888_1X24:
> - entity->code = code.code;
> - return true;
> - default:
> - break;
> - }
> - }
> -
> - return false;
> -}
> -
> static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
> {
> struct rvin_dev *vin = notifier_to_vin(notifier);
> int ret;
>
> - /* Verify subdevices mbus format */
> - if (!rvin_mbus_supported(vin->digital)) {
> - vin_err(vin, "Unsupported media bus format for %s\n",
> - vin->digital->subdev->name);
> - return -EINVAL;
> - }
> -
> - vin_dbg(vin, "Found media bus format for %s: %d\n",
> - vin->digital->subdev->name, vin->digital->code);
> -
> ret = v4l2_device_register_subdev_nodes(&vin->v4l2_dev);
> if (ret < 0) {
> vin_err(vin, "Failed to register subdev nodes\n");
> @@ -103,8 +67,16 @@ static void rvin_digital_notify_unbind(struct
> v4l2_async_notifier *notifier,
> struct rvin_dev *vin = notifier_to_vin(notifier);
>
> vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
> +
> + mutex_lock(&vin->lock);
> +
> rvin_v4l2_unregister(vin);
> + v4l2_ctrl_handler_free(&vin->ctrl_handler);
> +
> + vin->vdev.ctrl_handler = NULL;
> vin->digital->subdev = NULL;
> +
> + mutex_unlock(&vin->lock);
> }
>
> static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
> @@ -112,12 +84,14 @@ static int rvin_digital_notify_bound(struct
> v4l2_async_notifier *notifier,
>struct v4l2_async_subdev *asd)
> {
> struct rvin_dev *vin = notifier_to_vin(notifier);
> + struct v4l2_subdev_mbus_code_enum code = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> int ret;
>
> v4l2_set_subdev_hostdata(subdev, vin);
>
> /* Find source and sink pad of remote subdevice */
> -
> ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
> if (ret < 0)
> return ret;
> @@ -126,21 +100,74 @@ static int rvin_digital_notify_bound(struct
> v4l2_async_notifier *notifier,
> ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
> vin->digital->sink_pad = ret < 0 ? 0 : ret;
>
> + /* Find compatible subdevices mbus format */
> + vin->digital->code = 0;
> + code.index = 0;
> + code.pad = vin->digital->source_pad;
> + while (!vin->digital->code &&
> +!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, &code)) {
> + code.index++;
> + switch (code.code) {
&
Re: [PATCH v8 03/28] rcar-vin: unregister video device on driver removal
On 11/29/2017 08:43 PM, Niklas Söderlund wrote:
> If the video device was registered by the complete() callback it should
> be unregistered when the driver is removed. Protect from printing a
> uninitialized video device node name by adding a checking in
> rvin_v4l2_unregister() by checking that the video device is registered.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index f7a4c21909da6923..6d99542ec74b49a7 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -272,6 +272,8 @@ static int rcar_vin_remove(struct platform_device *pdev)
>
> pm_runtime_disable(&pdev->dev);
>
> + rvin_v4l2_unregister(vin);
> +
> v4l2_async_notifier_unregister(&vin->notifier);
> v4l2_async_notifier_cleanup(&vin->notifier);
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 178aecc94962abe2..32a658214f48fa49 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -841,6 +841,9 @@ static const struct v4l2_file_operations rvin_fops = {
>
> void rvin_v4l2_unregister(struct rvin_dev *vin)
> {
> + if (!video_is_registered(&vin->vdev))
> + return;
> +
> v4l2_info(&vin->v4l2_dev, "Removing %s\n",
> video_device_node_name(&vin->vdev));
>
>
Re: [PATCH v8 02/28] rcar-vin: rename poorly named initialize and cleanup functions
On 11/29/2017 08:43 PM, Niklas Söderlund wrote:
> The functions to initialize and cleanup the hardware and video device
> where poorly named from the start. Rename them to better describe there
> intended function.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Much better, indeed.
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 10 +-
> drivers/media/platform/rcar-vin/rcar-dma.c | 6 +++---
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 4 ++--
> drivers/media/platform/rcar-vin/rcar-vin.h | 8
> 4 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 108d776f32651b27..f7a4c21909da6923 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -93,7 +93,7 @@ static int rvin_digital_notify_complete(struct
> v4l2_async_notifier *notifier)
> return ret;
> }
>
> - return rvin_v4l2_probe(vin);
> + return rvin_v4l2_register(vin);
> }
>
> static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
> @@ -103,7 +103,7 @@ static void rvin_digital_notify_unbind(struct
> v4l2_async_notifier *notifier,
> struct rvin_dev *vin = notifier_to_vin(notifier);
>
> vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
> - rvin_v4l2_remove(vin);
> + rvin_v4l2_unregister(vin);
> vin->digital->subdev = NULL;
> }
>
> @@ -245,7 +245,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
> if (irq < 0)
> return irq;
>
> - ret = rvin_dma_probe(vin, irq);
> + ret = rvin_dma_register(vin, irq);
> if (ret)
> return ret;
>
> @@ -260,7 +260,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
>
> return 0;
> error:
> - rvin_dma_remove(vin);
> + rvin_dma_unregister(vin);
> v4l2_async_notifier_cleanup(&vin->notifier);
>
> return ret;
> @@ -275,7 +275,7 @@ static int rcar_vin_remove(struct platform_device *pdev)
> v4l2_async_notifier_unregister(&vin->notifier);
> v4l2_async_notifier_cleanup(&vin->notifier);
>
> - rvin_dma_remove(vin);
> + rvin_dma_unregister(vin);
>
> return 0;
> }
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 23fdff7a7370842e..d701b52d198243b5 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1153,14 +1153,14 @@ static const struct vb2_ops rvin_qops = {
> .wait_finish= vb2_ops_wait_finish,
> };
>
> -void rvin_dma_remove(struct rvin_dev *vin)
> +void rvin_dma_unregister(struct rvin_dev *vin)
> {
> mutex_destroy(&vin->lock);
>
> v4l2_device_unregister(&vin->v4l2_dev);
> }
>
> -int rvin_dma_probe(struct rvin_dev *vin, int irq)
> +int rvin_dma_register(struct rvin_dev *vin, int irq)
> {
> struct vb2_queue *q = &vin->queue;
> int i, ret;
> @@ -1208,7 +1208,7 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
>
> return 0;
> error:
> - rvin_dma_remove(vin);
> + rvin_dma_unregister(vin);
>
> return ret;
> }
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index b479b882da12f62d..178aecc94962abe2 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -839,7 +839,7 @@ static const struct v4l2_file_operations rvin_fops = {
> .read = vb2_fop_read,
> };
>
> -void rvin_v4l2_remove(struct rvin_dev *vin)
> +void rvin_v4l2_unregister(struct rvin_dev *vin)
> {
> v4l2_info(&vin->v4l2_dev, "Removing %s\n",
> video_device_node_name(&vin->vdev));
> @@ -866,7 +866,7 @@ static void rvin_notify(struct v4l2_subdev *sd,
> }
> }
>
> -int rvin_v4l2_probe(struct rvin_dev *vin)
> +int rvin_v4l2_register(struct rvin_dev *vin)
> {
> struct video_device *vdev = &vin->vdev;
> struct v4l2_subdev *sd = vin_to_source(vin);
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 5382078143fb3869..85cb7ec53d2b08b5 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -153,11 +153,11 @@ struct rvin_dev {
> #define vin_warn(d, fmt, arg.
Re: [PATCH] v4l: rcar-vin: Implement V4L2 video node release handler
Hi Niklas, On 11/16/2017 01:27 AM, Laurent Pinchart wrote: > Hi Niklas, > > On Thursday, 16 November 2017 01:34:33 EET Niklas Söderlund wrote: >> On 2017-11-16 00:49:07 +0200, Laurent Pinchart wrote: >>> The rvin_dev data structure contains driver private data for an instance >>> of the VIN. It is allocated dynamically at probe time, and must be freed >>> once all users are gone. >>> >>> The structure is currently allocated with devm_kzalloc(), which results >>> in memory being freed when the device is unbound. If a userspace >>> application is currently performing an ioctl call, or just keeps the >>> device node open and closes it later, this will lead to accessing freed >>> memory. >>> >>> Fix the problem by implementing a V4L2 release handler for the video >>> node associated with the VIN instance (called when the last user of the >>> video node releases it), and freeing memory explicitly from the release >>> handler. >>> >>> Signed-off-by: Laurent Pinchart >>> >> >> Acked-by: Niklas Söderlund >> >> This patch is based on-top of the VIN Gen3 enablement series not yet >> upstream. This is OK for me, just wanted to check that this was the >> intention as to minimize conflicts between the two. > > Yes, that's my intention. The patch should be included, or possibly squashed > in, your development branch. > Has this patch been added in your v8 series? If not, can you add it when you post a v9? Thanks, Hans
Re: [PATCH v11 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver
On 11/11/17 01:25, Niklas Söderlund wrote: > A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver > supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2 > hardware blocks are connected between the video sources and the video > grabbers (VIN). > > Driver is based on a prototype by Koji Matsuoka in the Renesas BSP. > > Signed-off-by: Niklas Söderlund I found one small typo (see below). After fixing that you can add my: Reviewed-by: Hans Verkuil I would like to see another Ack before merging this (Sakari?). Regards, Hans > --- > drivers/media/platform/rcar-vin/Kconfig | 12 + > drivers/media/platform/rcar-vin/Makefile| 1 + > drivers/media/platform/rcar-vin/rcar-csi2.c | 896 > > 3 files changed, 909 insertions(+) > create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c > > diff --git a/drivers/media/platform/rcar-vin/Kconfig > b/drivers/media/platform/rcar-vin/Kconfig > index af4c98b44d2e22cb..6875f30c1ae42631 100644 > --- a/drivers/media/platform/rcar-vin/Kconfig > +++ b/drivers/media/platform/rcar-vin/Kconfig > @@ -1,3 +1,15 @@ > +config VIDEO_RCAR_CSI2 > + tristate "R-Car MIPI CSI-2 Receiver" > + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF > + depends on ARCH_RENESAS || COMPILE_TEST > + select V4L2_FWNODE > + ---help--- > + Support for Renesas R-Car MIPI CSI-2 receiver. > + Supports R-Car Gen3 SoCs. > + > + To compile this driver as a module, choose M here: the > + module will be called rcar-csi2. > + > config VIDEO_RCAR_VIN > tristate "R-Car Video Input (VIN) Driver" > depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && > MEDIA_CONTROLLER > diff --git a/drivers/media/platform/rcar-vin/Makefile > b/drivers/media/platform/rcar-vin/Makefile > index 48c5632c21dc060b..5ab803d3e7c1aa57 100644 > --- a/drivers/media/platform/rcar-vin/Makefile > +++ b/drivers/media/platform/rcar-vin/Makefile > @@ -1,3 +1,4 @@ > rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o > > +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o > obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o > diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c > b/drivers/media/platform/rcar-vin/rcar-csi2.c > new file mode 100644 > index ..4202c60b4d0aa7f7 > --- /dev/null > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c > @@ -0,0 +1,896 @@ > +/* > + * Driver for Renesas R-Car MIPI CSI-2 Receiver > + * > + * Copyright (C) 2017 Renesas Electronics Corp. > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > + > +/* Register offsets and bits */ > + > +/* Control Timing Select */ > +#define TREF_REG 0x00 > +#define TREF_TREFBIT(0) > + > +/* Software Reset */ > +#define SRST_REG 0x04 > +#define SRST_SRSTBIT(0) > + > +/* PHY Operation Control */ > +#define PHYCNT_REG 0x08 > +#define PHYCNT_SHUTDOWNZ BIT(17) > +#define PHYCNT_RSTZ BIT(16) > +#define PHYCNT_ENABLECLK BIT(4) > +#define PHYCNT_ENABLE_3 BIT(3) > +#define PHYCNT_ENABLE_2 BIT(2) > +#define PHYCNT_ENABLE_1 BIT(1) > +#define PHYCNT_ENABLE_0 BIT(0) > + > +/* Checksum Control */ > +#define CHKSUM_REG 0x0c > +#define CHKSUM_ECC_ENBIT(1) > +#define CHKSUM_CRC_ENBIT(0) > + > +/* > + * Channel Data Type Select > + * VCDT[0-15]: Channel 1 VCDT[16-31]: Channel 2 > + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4 > + */ > +#define VCDT_REG 0x10 > +#define VCDT2_REG0x14 > +#define VCDT_VCDTN_ENBIT(15) > +#define VCDT_SEL_VC(n) (((n) & 0x3) << 8) > +#define VCDT_SEL_DTN_ON BIT(6) > +#define VCDT_SEL_DT(n) (((n) & 0x3f) << 0) > + > +/* Frame Data Type Select */ > +#define FRDT_REG 0x18 > + > +/* Field Det
Re: [PATCH v7 02/25] rcar-vin: register the video device at probe time
On 11/11/17 01:38, Niklas Söderlund wrote:
> The driver registers the video device from the async complete callback
> and unregistered in the async unbind callback. This creates problems if
> if the subdevice is bound, unbound and later rebound. The second time
"unbound and later rebound": that's a manual operation via /sys bind/unbind?
I remain unhappy about this patch. It's a workaround for a more basic problem
IMHO.
Can you move this patch to the end of the series? That way I can decide later
whether to merge it or not without blocking the rest of the series.
Other than this patch the only blocking patch is the bindings patch which hasn't
got an Ack yet.
Regards,
Hans
> video_register_device() is called it fails:
>
>kobject (eb3be918): tried to init an initialized object, something is
> seriously wrong.
>
> To prevent this register the video device at probe time and don't allow
> user-space to open the video device if the subdevice is not bound yet.
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 124
> +++-
> drivers/media/platform/rcar-vin/rcar-v4l2.c | 47 ++-
> drivers/media/platform/rcar-vin/rcar-vin.h | 5 +-
> 3 files changed, 95 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 108d776f32651b27..856df3e407c05d97 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -46,54 +46,18 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int
> direction)
> return -EINVAL;
> }
>
> -static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
> -{
> - struct v4l2_subdev *sd = entity->subdev;
> - struct v4l2_subdev_mbus_code_enum code = {
> - .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> - };
> -
> - code.index = 0;
> - code.pad = entity->source_pad;
> - while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, &code)) {
> - code.index++;
> - switch (code.code) {
> - case MEDIA_BUS_FMT_YUYV8_1X16:
> - case MEDIA_BUS_FMT_UYVY8_2X8:
> - case MEDIA_BUS_FMT_UYVY10_2X10:
> - case MEDIA_BUS_FMT_RGB888_1X24:
> - entity->code = code.code;
> - return true;
> - default:
> - break;
> - }
> - }
> -
> - return false;
> -}
> -
> static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
> {
> struct rvin_dev *vin = notifier_to_vin(notifier);
> int ret;
>
> - /* Verify subdevices mbus format */
> - if (!rvin_mbus_supported(vin->digital)) {
> - vin_err(vin, "Unsupported media bus format for %s\n",
> - vin->digital->subdev->name);
> - return -EINVAL;
> - }
> -
> - vin_dbg(vin, "Found media bus format for %s: %d\n",
> - vin->digital->subdev->name, vin->digital->code);
> -
> ret = v4l2_device_register_subdev_nodes(&vin->v4l2_dev);
> if (ret < 0) {
> vin_err(vin, "Failed to register subdev nodes\n");
> return ret;
> }
>
> - return rvin_v4l2_probe(vin);
> + return 0;
> }
>
> static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
> @@ -103,8 +67,15 @@ static void rvin_digital_notify_unbind(struct
> v4l2_async_notifier *notifier,
> struct rvin_dev *vin = notifier_to_vin(notifier);
>
> vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
> - rvin_v4l2_remove(vin);
> +
> + mutex_lock(&vin->lock);
> +
> + vin->vdev.ctrl_handler = NULL;
> + v4l2_ctrl_handler_free(&vin->ctrl_handler);
> +
> vin->digital->subdev = NULL;
> +
> + mutex_unlock(&vin->lock);
> }
>
> static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
> @@ -112,12 +83,14 @@ static int rvin_digital_notify_bound(struct
> v4l2_async_notifier *notifier,
>struct v4l2_async_subdev *asd)
> {
> struct rvin_dev *vin = notifier_to_vin(notifier);
> + struct v4l2_subdev_mbus_code_enum code = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> int ret;
>
> v4l2_set_subdev_hostdata(subdev, vin);
>
> /* Find source and sink pad of remote subdevice */
> -
> ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
> if (ret < 0)
> return ret;
> @@ -126,21 +99,82 @@ static int rvin_digital_notify_bound(struct
> v4l2_async_notifier *notifier,
> ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
> vin->digital->sink_pad = ret < 0 ? 0 : ret;
>
> + /* Find compatible subdevices mbus format */
> + vin->digital->code = 0;
> + code.index = 0;
> + code.pad = vin->digital->source_pad;
> + while (!vin->digital->code &&
> +!v4l2_subdev_ca
Re: [PATCH v7 23/25] rcar-vin: extend {start,stop}_streaming to work with media controller
On 11/11/17 01:38, Niklas Söderlund wrote:
> The procedure to start or stop streaming using the non-MC single
> subdevice and the MC graph and multiple subdevices are quite different.
> Create a new function to abstract which method is used based on which
> mode the driver is running in and add logic to start the MC graph.
>
> Signed-off-by: Niklas Söderlund
One tiny typo in a comment, see below. After fixing that you can add my:
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 113
> +++--
> 1 file changed, 106 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index fe1319eb4c5df02d..b16b892a4de876bb 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1087,15 +1087,116 @@ static void rvin_buffer_queue(struct vb2_buffer *vb)
> spin_unlock_irqrestore(&vin->qlock, flags);
> }
>
> +static int rvin_set_stream(struct rvin_dev *vin, int on)
> +{
> + struct v4l2_subdev_format fmt = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> + struct media_pipeline *pipe;
> + struct v4l2_subdev *sd;
> + struct media_pad *pad;
> + int ret;
> +
> + /* No media controller used, simply pass operation to subdevice */
> + if (!vin->info->use_mc) {
> + ret = v4l2_subdev_call(vin->digital->subdev, video, s_stream,
> +on);
> +
> + return ret == -ENOIOCTLCMD ? 0 : ret;
> + }
> +
> + pad = media_entity_remote_pad(&vin->pad);
> + if (!pad)
> + return -EPIPE;
> +
> + sd = media_entity_to_v4l2_subdev(pad->entity);
> + if (!sd)
> + return -EPIPE;
> +
> + if (!on) {
> + media_pipeline_stop(&vin->vdev.entity);
> + ret = v4l2_subdev_call(sd, video, s_stream, 0);
> + return 0;
> + }
> +
> + fmt.pad = pad->index;
> + if (v4l2_subdev_call(sd, pad, get_fmt, NULL, &fmt))
> + return -EPIPE;
> +
> + switch (fmt.format.code) {
> + case MEDIA_BUS_FMT_YUYV8_1X16:
> + case MEDIA_BUS_FMT_UYVY8_2X8:
> + case MEDIA_BUS_FMT_UYVY10_2X10:
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + vin->code = fmt.format.code;
> + break;
> + default:
> + return -EPIPE;
> + }
> +
> + switch (fmt.format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + case V4L2_FIELD_SEQ_TB:
> + case V4L2_FIELD_SEQ_BT:
> + /* Supported nativly */
nativly -> natively
> + break;
> + case V4L2_FIELD_ALTERNATE:
> + switch (vin->format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + break;
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + case V4L2_FIELD_SEQ_TB:
> + case V4L2_FIELD_SEQ_BT:
> + /* Use VIN hardware to combine the two fields */
> + fmt.format.height *= 2;
> + break;
> + default:
> + return -EPIPE;
> + }
> + break;
> + default:
> + return -EPIPE;
> + }
> +
> + if (fmt.format.width != vin->format.width ||
> + fmt.format.height != vin->format.height)
> + return -EPIPE;
> +
> + pipe = sd->entity.pipe ? sd->entity.pipe : &vin->vdev.pipe;
> + if (media_pipeline_start(&vin->vdev.entity, pipe))
> + return -EPIPE;
> +
> + ret = v4l2_subdev_call(sd, video, s_stream, 1);
> + if (ret == -ENOIOCTLCMD)
> + ret = 0;
> + if (ret)
> + media_pipeline_stop(&vin->vdev.entity);
> +
> + return ret;
> +}
> +
> static int rvin_start_streaming(struct vb2_queue *vq, unsigned int count)
> {
> struct rvin_dev *vin = vb2_get_drv_priv(vq);
> - struct v4l2_subdev *sd;
> unsigned long flags;
> int ret;
>
> - sd = vin_to_source(vin);
> - v4l2_subdev_call(sd, video, s_stream, 1);
> + ret = rvin_set_stream(vin, 1);
> + if (ret) {
> + sp
Re: [PATCH v7 14/25] rcar-vin: add function to manipulate Gen3 CHSEL value
On 11/11/17 01:38, Niklas Söderlund wrote:
> On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
> feature of this register is that it's only present in the VIN0 and VIN4
> instances. The register in VIN0 controls the routing for VIN0-3 and the
> register in VIN4 controls routing for VIN4-7.
>
> To be able to control routing from a media device this function is need
> to control runtime PM for the subgroup master (VIN0 and VIN4). The
> subgroup master must be switched on before the register is manipulated,
> once the operation is complete it's safe to switch the master off and
> the new routing will still be in effect.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 25 +
> drivers/media/platform/rcar-vin/rcar-vin.h | 2 ++
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index c4f8e81e88c99e28..463c656b9878be52 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -16,6 +16,7 @@
>
> #include
> #include
> +#include
>
> #include
>
> @@ -1228,3 +1229,27 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
>
> return ret;
> }
> +
> +/*
> -
> + * Gen3 CHSEL manipulation
> + */
> +
> +void rvin_set_chsel(struct rvin_dev *vin, u8 chsel)
> +{
> + u32 ifmd, vnmc;
> +
> + pm_runtime_get_sync(vin->dev);
> +
> + /* Make register writes take effect immediately */
> + vnmc = rvin_read(vin, VNMC_REG) & ~VNMC_VUP;
> + rvin_write(vin, vnmc, VNMC_REG);
> +
> + ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
> + VNCSI_IFMD_CSI_CHSEL(chsel);
> +
> + rvin_write(vin, ifmd, VNCSI_IFMD_REG);
> +
> + vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
> +
> + pm_runtime_put(vin->dev);
> +}
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 1f761518a6cc60b8..8a7c51724a90786c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -164,4 +164,6 @@ int rvin_reset_format(struct rvin_dev *vin);
>
> const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
>
> +void rvin_set_chsel(struct rvin_dev *vin, u8 chsel);
> +
> #endif
>
Re: [PATCH v7 20/25] rcar-vin: add chsel information to rvin_info
On 11/11/17 01:38, Niklas Söderlund wrote:
> Each Gen3 SoC has a limited set of predefined routing possibilities for
> which CSI-2 device and virtual channel can be routed to which VIN
> instance. Prepare to store this information in the struct rvin_info.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-vin.h | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index a9bd570d6635fd47..41c81b8d9fb8e851 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -35,6 +35,9 @@
> /* Max number on VIN instances that can be in a system */
> #define RCAR_VIN_NUM 8
>
> +/* Max number of CHSEL values for any Gen3 SoC */
> +#define RCAR_CHSEL_MAX 6
> +
> enum chip_id {
> RCAR_H1,
> RCAR_M1,
> @@ -91,6 +94,22 @@ struct rvin_graph_entity {
>
> struct rvin_group;
>
> +/** struct rvin_group_chsel - Map a CSI-2 receiver and channel to a CHSEL
> value
> + * @csi: VIN internal number for CSI-2 device
> + * @chan:Output channel of the CSI-2 receiver. Each R-Car CSI-2
> + * receiver has four output channels facing the VIN
> + * devices, each channel can carry one CSI-2 Virtual
> + * Channel (VC) and there are no correlation between
> + * output channel number and CSI-2 VC. It's up to the
> + * CSI-2 receiver driver to configure which VC is
> + * outputted on which channel, the VIN devices only
> + * cares about output channels.
> + */
> +struct rvin_group_chsel {
> + enum rvin_csi_id csi;
> + unsigned int chan;
> +};
> +
> /**
> * struct rvin_info - Information about the particular VIN implementation
> * @chip:type of VIN chip
> @@ -98,6 +117,9 @@ struct rvin_group;
> *
> * max_width:max input width the VIN supports
> * max_height: max input height the VIN supports
> + *
> + * num_chsels: number of possible chsel values for this VIN
> + * chsels: routing table VIN <-> CSI-2 for the chsel values
> */
> struct rvin_info {
> enum chip_id chip;
> @@ -105,6 +127,9 @@ struct rvin_info {
>
> unsigned int max_width;
> unsigned int max_height;
> +
> + unsigned int num_chsels;
> + struct rvin_group_chsel chsels[RCAR_VIN_NUM][RCAR_CHSEL_MAX];
> };
>
> /**
>
Re: [PATCH v7 22/25] rcar-vin: add link notify for Gen3
On 11/11/17 01:38, Niklas Söderlund wrote:
> Add the ability to process media device link change request. Link
> enabling is a bit complicated on Gen3, whether or not it's possible to
> enable a link depends on what other links already are enabled. On Gen3
> the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a
> routing perspective these two groups are independent of each other.
> Each subgroup's routing is controlled by the subgroup VIN master
> instance (VIN0 and VIN4).
>
> There are a limited number of possible route setups available for each
> subgroup and the configuration of each setup is dictated by the
> hardware. On H3 for example there are 6 possible route setups for each
> subgroup to choose from.
>
> This leads to the media device link notification code being rather large
> since it will find the best routing configuration to try and accommodate
> as many links as possible. When it's not possible to enable a new link
> due to hardware constrains the link_notifier callback will return
> -EMLINK.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 205
>
> 1 file changed, 205 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 78a9766eb7114959..79b0334d8c563328 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -27,6 +27,209 @@
>
> #include "rcar-vin.h"
>
> +/*
> -
> + * Media Controller link notification
> + */
> +
> +static unsigned int rvin_group_csi_pad_to_chan(unsigned int pad)
> +{
> + /*
> + * The companion CSI-2 receiver driver (rcar-csi2) is known
> + * and we know it have one source pad (pad 0) and four sink
> + * pads (pad 1-4). So to translate a pad on the remote
> + * CSI-2 receiver to the VIN internal channel number simply
> + * subtract one from the pad number.
> + */
> + return pad - 1;
> +}
> +
> +/* group lock should be held when calling this function */
> +static int rvin_group_entity_to_vin_num(struct rvin_group *group,
> + struct media_entity *entity)
> +{
> + struct video_device *vdev;
> + int i;
> +
> + if (!is_media_entity_v4l2_video_device(entity))
> + return -ENODEV;
> +
> + vdev = media_entity_to_video_device(entity);
> +
> + for (i = 0; i < RCAR_VIN_NUM; i++) {
> + if (!group->vin[i])
> + continue;
> +
> + if (&group->vin[i]->vdev == vdev)
> + return i;
> + }
> +
> + return -ENODEV;
> +}
> +
> +/* group lock should be held when calling this function */
> +static int rvin_group_entity_to_csi_num(struct rvin_group *group,
> + struct media_entity *entity)
> +{
> + struct v4l2_subdev *sd;
> + int i;
> +
> + if (!is_media_entity_v4l2_subdev(entity))
> + return -ENODEV;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + for (i = 0; i < RVIN_CSI_MAX; i++)
> + if (group->csi[i].subdev == sd)
> + return i;
> +
> + return -ENODEV;
> +}
> +
> +/* group lock should be held when calling this function */
> +static void __rvin_group_build_link_list(struct rvin_group *group,
> + struct rvin_group_chsel *map,
> + int start, int len)
> +{
> + struct media_pad *vin_pad, *remote_pad;
> + unsigned int n;
> +
> + for (n = 0; n < len; n++) {
> + map[n].csi = -1;
> + map[n].chan = -1;
> +
> + if (!group->vin[start + n])
> + continue;
> +
> + vin_pad = &group->vin[start + n]->vdev.entity.pads[0];
> +
> + remote_pad = media_entity_remote_pad(vin_pad);
> + if (!remote_pad)
> + continue;
> +
> + map[n].csi =
> + rvin_group_entity_to_csi_num(group, remote_pad->entity);
> + map[n].chan = rvin_group_csi_pad_to_chan(remote_pad->index);
> + }
> +}
> +
> +/* group lock should be held when calling this function */
> +static int __rvin_group_try_get_chsel(struct rvin_group *group,
> + struct rvin_group_chsel *map,
> +
Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race
Hi Laurent,
On 16/11/17 01:33, Laurent Pinchart wrote:
> Device unplug being asynchronous, it naturally races with operations
> performed by userspace through ioctls or other file operations on video
> device nodes.
>
> This leads to potential access to freed memory or to other resources
> during device access if unplug occurs during device access. To solve
> this, we need to wait until all device access completes when unplugging
> the device, and block all further access when the device is being
> unplugged.
>
> Three new functions are introduced. The video_device_enter() and
> video_device_exit() functions must be used to mark entry and exit from
> all code sections where the device can be accessed. The
> video_device_unplug() function is then used in the unplug handler to
> mark the device as being unplugged and wait for all access to complete.
>
> As an example mark the ioctl handler as a device access section. Other
> file operations need to be protected too, and blocking ioctls (such as
> VIDIOC_DQBUF) need to be handled as well.
As long as the queue field in struct video_device is filled in properly
this shouldn't be a problem.
This looks pretty good, simple and straightforward.
Do we need something similar for media_device? Other devices?
Regards,
Hans
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/media/v4l2-core/v4l2-dev.c | 57
> ++
> include/media/v4l2-dev.h | 47 +++
> 2 files changed, 104 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
> b/drivers/media/v4l2-core/v4l2-dev.c
> index c647ba648805..c73c6d49e7cf 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -156,6 +156,52 @@ void video_device_release_empty(struct video_device
> *vdev)
> }
> EXPORT_SYMBOL(video_device_release_empty);
>
> +int video_device_enter(struct video_device *vdev)
> +{
> + bool unplugged;
> +
> + spin_lock(&vdev->unplug_lock);
> + unplugged = vdev->unplugged;
> + if (!unplugged)
> + vdev->access_refcount++;
> + spin_unlock(&vdev->unplug_lock);
> +
> + return unplugged ? -ENODEV : 0;
> +}
> +EXPORT_SYMBOL_GPL(video_device_enter);
> +
> +void video_device_exit(struct video_device *vdev)
> +{
> + bool wake_up;
> +
> + spin_lock(&vdev->unplug_lock);
> + WARN_ON(--vdev->access_refcount < 0);
> + wake_up = vdev->access_refcount == 0;
> + spin_unlock(&vdev->unplug_lock);
> +
> + if (wake_up)
> + wake_up(&vdev->unplug_wait);
> +}
> +EXPORT_SYMBOL_GPL(video_device_exit);
> +
> +void video_device_unplug(struct video_device *vdev)
> +{
> + bool unplug_blocked;
> +
> + spin_lock(&vdev->unplug_lock);
> + unplug_blocked = vdev->access_refcount > 0;
> + vdev->unplugged = true;
> + spin_unlock(&vdev->unplug_lock);
> +
> + if (!unplug_blocked)
> + return;
> +
> + if (!wait_event_timeout(vdev->unplug_wait, !vdev->access_refcount,
> + msecs_to_jiffies(15)))
> + WARN(1, "Timeout waiting for device access to complete\n");
> +}
> +EXPORT_SYMBOL_GPL(video_device_unplug);
> +
> static inline void video_get(struct video_device *vdev)
> {
> get_device(&vdev->dev);
> @@ -351,6 +397,10 @@ static long v4l2_ioctl(struct file *filp, unsigned int
> cmd, unsigned long arg)
> struct video_device *vdev = video_devdata(filp);
> int ret = -ENODEV;
>
> + ret = video_device_enter(vdev);
> + if (ret < 0)
> + return ret;
> +
> if (vdev->fops->unlocked_ioctl) {
> struct mutex *lock = v4l2_ioctl_get_lock(vdev, cmd);
>
> @@ -358,11 +408,14 @@ static long v4l2_ioctl(struct file *filp, unsigned int
> cmd, unsigned long arg)
> return -ERESTARTSYS;
> if (video_is_registered(vdev))
> ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
> + else
> + ret = -ENODEV;
> if (lock)
> mutex_unlock(lock);
> } else
> ret = -ENOTTY;
>
> + video_device_exit(vdev);
> return ret;
> }
>
> @@ -841,6 +894,10 @@ int __video_register_device(struct video_device *vdev,
> int type, int nr,
> if (WARN_ON(!vdev->v4l2_dev))
> return -EINVAL;
>
> + /* unplug support */
> + spin_lock_init(&vdev->unplug_lock);
> + init_waitqueue_head(&vdev->unplug_wait);
> +
> /* v4l2_fh support */
> spin_lock_init(&vdev->fh_lock);
> INIT_LIST_HEAD(&vdev->fh_list);
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index e657614521e3..365a94f91dc9 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -178,6 +179,12 @@ struct v4l2_file_operations {
> * @pipe: &struct media_pipeline
>
Re: [PATCH 04/24] media: v4l2-mediabus: convert flags to enums and document them
On 09/10/17 12:19, Mauro Carvalho Chehab wrote: > There is a mess with media bus flags: there are two sets of > flags, one used by parallel and ITU-R BT.656 outputs, > and another one for CSI2. > > Depending on the type, the same bit has different meanings. > > That's very confusing, and counter-intuitive. So, split them > into two sets of flags, inside an enum. > > This way, it becomes clearer that there are two separate sets > of flags. It also makes easier if CSI1, CSP, CSI3, etc. would > need a different set of flags. > > As a side effect, enums can be documented via kernel-docs, > so there will be an improvement at flags documentation. > > Unfortunately, soc_camera and pxa_camera do a mess with > the flags, using either one set of flags without proper > checks about the type. That could be fixed, but, as both drivers > are obsolete and in the process of cleanings, I opted to just > keep the behavior, using an unsigned int inside those two > drivers. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Hans Verkuil Nice cleanup. Regards, Hans
[PATCHv3 1/2] dt-bindings: adi,adv7511.txt: document cec clock
From: Hans Verkuil Document the cec clock binding. Signed-off-by: Hans Verkuil Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index 06668bca7ffc..0047b1394c70 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt @@ -68,6 +68,8 @@ Optional properties: - adi,disable-timing-generator: Only for ADV7533. Disables the internal timing generator. The chip will rely on the sync signals in the DSI data lanes, rather than generate its own timings for HDMI output. +- clocks: from common clock binding: reference to the CEC clock. +- clock-names: from common clock binding: must be "cec". Required nodes: @@ -89,6 +91,8 @@ Example reg = <39>; interrupt-parent = <&gpio3>; interrupts = <29 IRQ_TYPE_EDGE_FALLING>; + clocks = <&cec_clock>; + clock-names = "cec"; adi,input-depth = <8>; adi,input-colorspace = "rgb"; -- 2.14.1
[PATCHv3 0/2] drm/bridge/adv7511: add CEC support
From: Hans Verkuil This patch series adds CEC support to the drm adv7511/adv7533 drivers. I have tested this with the Qualcomm Dragonboard C410 (adv7533 based) and the Renesas R-Car Koelsch board (adv7511 based). I only have the Koelsch board to test with, but it looks like other R-Car boards use the same adv7511. It would be nice if someone can add CEC support to the other R-Car boards as well. The main thing to check is if they all use the same 12 MHz fixed CEC clock source. Anyone who wants to test this will need the CEC utilities that are part of the v4l-utils git repository: git clone git://linuxtv.org/v4l-utils.git cd v4l-utils ./bootstrap.sh ./configure make sudo make install Now configure the CEC adapter as a Playback device: cec-ctl --playback Discover other CEC devices: cec-ctl -S Regards, Hans Changes since v2: - A small rewording of the 'clocks' property description in the bindings as per Sergei's comment. Changes since v1: - Incorporate Archit's comments: use defines for irq masks combine the adv7511/33 regmap_configs adv7511_cec_init now handles dt parsing & CEC registration - Use the new (4.14) CEC_CAP_DEFAULTS define Hans Verkuil (2): dt-bindings: adi,adv7511.txt: document cec clock drm: adv7511/33: add HDMI CEC support .../bindings/display/bridge/adi,adv7511.txt| 4 + drivers/gpu/drm/bridge/adv7511/Kconfig | 8 + drivers/gpu/drm/bridge/adv7511/Makefile| 1 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 43 ++- drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 337 + drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 116 ++- drivers/gpu/drm/bridge/adv7511/adv7533.c | 38 +-- 7 files changed, 489 insertions(+), 58 deletions(-) create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c -- 2.14.1
[PATCHv3 2/2] drm: adv7511/33: add HDMI CEC support
From: Hans Verkuil
Add support for HDMI CEC to the drm adv7511/adv7533 drivers.
The CEC registers that we need to use are identical for both drivers,
but they appear at different offsets in the register map.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/bridge/adv7511/Kconfig | 8 +
drivers/gpu/drm/bridge/adv7511/Makefile | 1 +
drivers/gpu/drm/bridge/adv7511/adv7511.h | 43 +++-
drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 337 +++
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 116 +++--
drivers/gpu/drm/bridge/adv7511/adv7533.c | 38 +--
6 files changed, 485 insertions(+), 58 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index 2fed567f9943..592b9d2ec034 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -21,3 +21,11 @@ config DRM_I2C_ADV7533
default y
help
Support for the Analog Devices ADV7533 DSI to HDMI encoder.
+
+config DRM_I2C_ADV7511_CEC
+ bool "ADV7511/33 HDMI CEC driver"
+ depends on DRM_I2C_ADV7511
+ select CEC_CORE
+ default y
+ help
+ When selected the HDMI transmitter will support the CEC feature.
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 5ba675534f6e..5bb384938a71 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,4 +1,5 @@
adv7511-y := adv7511_drv.o
adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index fe18a5d2d84b..543a5eb91624 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -195,6 +195,25 @@
#define ADV7511_PACKET_GM(x) ADV7511_PACKET(5, x)
#define ADV7511_PACKET_SPARE(x)ADV7511_PACKET(6, x)
+#define ADV7511_REG_CEC_TX_FRAME_HDR 0x00
+#define ADV7511_REG_CEC_TX_FRAME_DATA0 0x01
+#define ADV7511_REG_CEC_TX_FRAME_LEN 0x10
+#define ADV7511_REG_CEC_TX_ENABLE 0x11
+#define ADV7511_REG_CEC_TX_RETRY 0x12
+#define ADV7511_REG_CEC_TX_LOW_DRV_CNT 0x14
+#define ADV7511_REG_CEC_RX_FRAME_HDR 0x15
+#define ADV7511_REG_CEC_RX_FRAME_DATA0 0x16
+#define ADV7511_REG_CEC_RX_FRAME_LEN 0x25
+#define ADV7511_REG_CEC_RX_ENABLE 0x26
+#define ADV7511_REG_CEC_RX_BUFFERS 0x4a
+#define ADV7511_REG_CEC_LOG_ADDR_MASK 0x4b
+#define ADV7511_REG_CEC_LOG_ADDR_0_1 0x4c
+#define ADV7511_REG_CEC_LOG_ADDR_2 0x4d
+#define ADV7511_REG_CEC_CLK_DIV0x4e
+#define ADV7511_REG_CEC_SOFT_RESET 0x50
+
+#define ADV7533_REG_CEC_OFFSET 0x70
+
enum adv7511_input_clock {
ADV7511_INPUT_CLOCK_1X,
ADV7511_INPUT_CLOCK_2X,
@@ -297,6 +316,8 @@ enum adv7511_type {
ADV7533,
};
+#define ADV7511_MAX_ADDRS 3
+
struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
@@ -343,15 +364,27 @@ struct adv7511 {
enum adv7511_type type;
struct platform_device *audio_pdev;
+
+ struct cec_adapter *cec_adap;
+ u8 cec_addr[ADV7511_MAX_ADDRS];
+ u8 cec_valid_addrs;
+ bool cec_enabled_adap;
+ struct clk *cec_clk;
+ u32 cec_clk_freq;
};
+#ifdef CONFIG_DRM_I2C_ADV7511_CEC
+int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
+unsigned int offset);
+void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
+#endif
+
#ifdef CONFIG_DRM_I2C_ADV7533
void adv7533_dsi_power_on(struct adv7511 *adv);
void adv7533_dsi_power_off(struct adv7511 *adv);
void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode *mode);
int adv7533_patch_registers(struct adv7511 *adv);
-void adv7533_uninit_cec(struct adv7511 *adv);
-int adv7533_init_cec(struct adv7511 *adv);
+int adv7533_patch_cec_registers(struct adv7511 *adv);
int adv7533_attach_dsi(struct adv7511 *adv);
void adv7533_detach_dsi(struct adv7511 *adv);
int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
@@ -374,11 +407,7 @@ static inline int adv7533_patch_registers(struct adv7511
*adv)
return -ENODEV;
}
-static inline void adv7533_uninit_cec(struct adv7511 *adv)
-{
-}
-
-static inline int adv7533_init_cec(struct adv7511 *adv)
+static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
{
return -ENODEV;
}
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
new file mode 100644
index ..b33d730e4d73
--- /dev/null
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
@@ -0,0 +1,337 @@
+/*
+ * adv7511_cec.c - Analog Devices ADV7511/33
Re: [PATCHv2 2/2] drm: adv7511/33: add HDMI CEC support
On 06/10/17 06:26, Archit Taneja wrote: > Hi Hans, > > On 09/19/2017 01:03 PM, Hans Verkuil wrote: >> From: Hans Verkuil >> >> Add support for HDMI CEC to the drm adv7511/adv7533 drivers. >> >> The CEC registers that we need to use are identical for both drivers, >> but they appear at different offsets in the register map. > > The patch looks good to me. I can go ahead an queue it to drm-misc-next. > > There were some minor comments on the DT bindings patch. Are you planning > to send a new patch for that? Yes. Now that this patch has been reviewed I'll post a v3 for the first fixing those comments. Expect to see it Monday at the latest. Regards, Hans
