Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1140371pxk; Fri, 4 Sep 2020 01:23:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0EiexrLSzIRXBLiVczMnWuQEQCq6nE38xAOWxsdPenxV3aOpnYRZEf6ShOIB7IfY1Ut7K X-Received: by 2002:aa7:c387:: with SMTP id k7mr7070337edq.242.1599207801118; Fri, 04 Sep 2020 01:23:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599207801; cv=none; d=google.com; s=arc-20160816; b=A7Vpqa9L7VAWqqKLTF1+LAG7QagKx0tFilXKYPRVn4+9ujzIAP8wShzTmxEWyIgjG3 tsduwrYPVpYly1LANOhGDArI0+ghSsq81avXdoy5XYW1lWBce2jEGRtYQ7Nt+513XRrB Xi2QDAI6qF43UHB4K2SVNl7qd7GtitAltmsyrg7vBBGUosjhvshjGASqOkZBeCeEb9hl rN85/ey89YOxpgf972XZ3TBkXJ+L/IeSQnxqHIBWn5hWECaYuawg7rT1O7oVOYRNyen9 chlAL7elAMR6C0spzInTMcam18OW1I+PYC5EuxnKSn5wEM1jBCqZq8i/s/T9bghBaGcT zpeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=J/mGQr/vhvcC9U5a6auchI7zeNmjYfgWFquWLfhJxEI=; b=JsN+PDflJaPEZbVngMUlDwrUGW5RXf+3tJnuny5y0K39wO0usVQTwCFuden24XrlXI 5THrLWrG9gVt/tyy9q47QjiDC3fJoS4IoRRZj3FDDqsgox01moc2DUKq3a0FNczNmoD+ W18vd5ss747o5rGXSJOZ2paAq+myDRHOI5lDOUp6jx2xR/JuoTYDZ2+/i1epzrTJ6DQz 04qUoiP+0BeYwfeKto1Ud36OkWs7sGKVs+eH+UqTDOa39sjUgqvK0GOLIx1fa05zwMIK jF48uBCg/Qqhre6FmPB4vb+0PZcGCsnJhOT2pcRPiTy7bkjckzy6y89CLAeB3AED+3AV AyaQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d17si3323706edp.462.2020.09.04.01.22.57; Fri, 04 Sep 2020 01:23:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729584AbgIDIVi (ORCPT + 99 others); Fri, 4 Sep 2020 04:21:38 -0400 Received: from retiisi.org.uk ([95.216.213.190]:57498 "EHLO hillosipuli.retiisi.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726425AbgIDIVi (ORCPT ); Fri, 4 Sep 2020 04:21:38 -0400 Received: from valkosipuli.localdomain (valkosipuli.retiisi.org.uk [IPv6:2a01:4f9:c010:4572::80:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hillosipuli.retiisi.org.uk (Postfix) with ESMTPS id 1024C634C8C; Fri, 4 Sep 2020 11:21:05 +0300 (EEST) Received: from sailus by valkosipuli.localdomain with local (Exim 4.92) (envelope-from ) id 1kE6y0-0001Zg-Vm; Fri, 04 Sep 2020 11:21:04 +0300 Date: Fri, 4 Sep 2020 11:21:04 +0300 From: Sakari Ailus To: Jacopo Mondi Cc: Laurent Pinchart , Lad Prabhakar , Mauro Carvalho Chehab , Hans Verkuil , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Biju Das , Prabhakar Subject: Re: [PATCH v3 1/2] media: i2c: ov772x: Add support for BT656 mode Message-ID: <20200904082104.GE4392@valkosipuli.retiisi.org.uk> References: <20200824190406.27478-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20200824190406.27478-2-prabhakar.mahadev-lad.rj@bp.renesas.com> <20200904012000.GA9369@pendragon.ideasonboard.com> <20200904075553.qjdyskcpext7fxcy@uno.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200904075553.qjdyskcpext7fxcy@uno.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Laurent, Jacopo, On Fri, Sep 04, 2020 at 09:55:53AM +0200, Jacopo Mondi wrote: > Hi Laurent, > > On Fri, Sep 04, 2020 at 04:20:00AM +0300, Laurent Pinchart wrote: > > Hi Prabhakar, > > > > Thank you for the patch. > > > > On Mon, Aug 24, 2020 at 08:04:05PM +0100, Lad Prabhakar wrote: > > > Add support to read the bus-type and enable BT656 mode if needed. > > > > > > Also fail probe if unsupported bus_type is detected. > > > > > > Signed-off-by: Lad Prabhakar > > > Reviewed-by: Biju Das > > > --- > > > drivers/media/i2c/ov772x.c | 32 ++++++++++++++++++++++++++++++++ > > > 1 file changed, 32 insertions(+) > > > > > > diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c > > > index 2cc6a678069a..67764d647526 100644 > > > --- a/drivers/media/i2c/ov772x.c > > > +++ b/drivers/media/i2c/ov772x.c > > > @@ -31,6 +31,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > > > > @@ -434,6 +435,7 @@ struct ov772x_priv { > > > #ifdef CONFIG_MEDIA_CONTROLLER > > > struct media_pad pad; > > > #endif > > > + struct v4l2_fwnode_endpoint ep; > > > }; > > > > > > /* > > > @@ -581,6 +583,13 @@ static int ov772x_s_stream(struct v4l2_subdev *sd, int enable) > > > if (priv->streaming == enable) > > > goto done; > > > > > > + if (priv->ep.bus_type == V4L2_MBUS_BT656) { > > > + ret = regmap_update_bits(priv->regmap, COM7, ITU656_ON_OFF, > > > + enable ? ITU656_ON_OFF : ~ITU656_ON_OFF); > > > + if (ret) > > > + goto done; > > > + } > > > + > > > ret = regmap_update_bits(priv->regmap, COM2, SOFT_SLEEP_MODE, > > > enable ? 0 : SOFT_SLEEP_MODE); > > > if (ret) > > > @@ -1354,6 +1363,7 @@ static const struct v4l2_subdev_ops ov772x_subdev_ops = { > > > > > > static int ov772x_probe(struct i2c_client *client) > > > { > > > + struct fwnode_handle *endpoint; > > > struct ov772x_priv *priv; > > > int ret; > > > static const struct regmap_config ov772x_regmap_config = { > > > @@ -1415,6 +1425,28 @@ static int ov772x_probe(struct i2c_client *client) > > > goto error_clk_put; > > > } > > > > > > + endpoint = fwnode_graph_get_next_endpoint(dev_fwnode(&client->dev), > > > + NULL); > > > + if (!endpoint) { > > > + dev_err(&client->dev, "endpoint node not found\n"); > > > + ret = -EINVAL; > > > + goto error_clk_put; > > > + } > > > + > > > + ret = v4l2_fwnode_endpoint_parse(endpoint, &priv->ep); > > > > v4l2_fwnode_endpoint_parse() is deprecated for new drivers, > > v4l2_fwnode_endpoint_alloc_parse() is recommended instead. Please note > > that v4l2_fwnode_endpoint_free() then needs to be called in the error > > path and in remove(). > > Doesn't alloc_parse() differ from just _parse() as it reserve space > for the 'link-frequencies' array ? As this device does not support > CSI-2 and the 'link-frequencies' property is not allows in bindings, > isn't using endpoint_parse() better as it saves a call to _free() ? Yeah. I think the documentation needs to be updated. The thinking was there would be other variable size properties that drivers would need but that didn't happen. So feel free to continue use v4l2_fwnode_endpoint_parse() where it does the job. > > Or are we deprecating that function unconditionally ? The > documentation suggests "please use v4l2_fwnode_endpoint_alloc_parse() > in new drivers" but here it doesn't seem required.. > > > > > On the other hand, not setting .bus_type and letting the parse() > > function determine the but type automatically is also deprecated, and I > > don't think forcing drivers to call v4l2_fwnode_endpoint_alloc_parse() > > once for each bus type until one succeeds is a good API. As change will > > be needed in that API, you can ignore v4l2_fwnode_endpoint_alloc_parse() > > for the time being if you want. > > But indeed relying on auto-guessing of the bus type is deprecated since > some time now (and the API could be improved, yes). Sorry I missed > that yesterday. There's one case where the bus type does not need to be set: when bindings require it *and* at the same time you have no default configuration that requires something to be set in the bus specific struct. Bindings where bus-type is required were added later so I think the documentation should be changed there, too. I can send the patches. > > As we support parallel and bt.656 only I must be honest I don't mind > it here as otherwise the code would be more complex for no real gain, > but I defer this to Sakari which has been fighting the battle against > auto-guessing since a long time now :) I think you should require bus-type property in bindings in that case. But as it's an existing driver, bus-type will be optional. You'll need to default to what was supported earlier. This is actually an interesting case as bindings do not document it. > > > > > > Reviewed-by: Laurent Pinchart > > > > > + fwnode_handle_put(endpoint); > > > + if (ret) { > > > + dev_err(&client->dev, "Could not parse endpoint\n"); > > > + goto error_clk_put; > > > + } > > > + > > > + if (priv->ep.bus_type != V4L2_MBUS_PARALLEL && > > > + priv->ep.bus_type != V4L2_MBUS_BT656) { > > > + dev_err(&client->dev, "Unsupported bus type %d\n", > > > + priv->ep.bus_type); > > > + goto error_clk_put; > > > + } > > > + > > > ret = ov772x_video_probe(priv); > > > if (ret < 0) > > > goto error_gpio_put; > > > > -- > > Regards, > > > > Laurent Pinchart -- Sakari Ailus