All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-staging@lists.linux.dev,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v3 3/4] staging: media: Add support for the Allwinner A31 ISP
Date: Thu, 28 Apr 2022 16:30:11 +0200	[thread overview]
Message-ID: <Ymqk89e+mn/1kLLx@aptenodytes> (raw)
In-Reply-To: <YmqFQSRBsqs4ghNQ@valkosipuli.retiisi.eu>

[-- Attachment #1: Type: text/plain, Size: 10074 bytes --]

Hi Sakari,

On Thu 28 Apr 22, 15:14, Sakari Ailus wrote:
> Hi Paul,
> 
> Thanks for the set.
> 
> A few comments below.

Thanks a lot for your review!

[...]

> >  .../staging/media/sunxi/sun6i-isp/TODO.txt    |   6 +
> 
> This should be called TODO (without .txt).

Understood!

> I understand this is an online ISP. How do you schedule the video buffer
> queues? Say, what happens if it's time to set up buffers for a frame and
> there's a buffer queued in the parameter queue but not in the image data
> queue? Or the other way around?

The ISP works in a quite atypical way, with a DMA buffer that is used to
hold upcoming parameters (including buffer addresses) and a bit in a "direct"
register to schedule the update of the parameters at next vsync.

The update (setting the bit) is triggered whenever new parameters are
submitted via the params video device or whenever there's a capture buffer
available in the capture video device.

So you don't particularly need to have one parameter buffer matching a capture
buffer, the two can be updated independently. Of course, a capture buffer will
only be returned after another buffer becomes active.

I hope this answers your concern!

[...]

> > +static int sun6i_isp_tables_setup(struct sun6i_isp_device *isp_dev)
> > +{
> > +	struct sun6i_isp_tables *tables = &isp_dev->tables;
> > +	int ret;
> > +
> > +	/* Sizes are hardcoded for now but actually depend on the platform. */
> 
> Would it be cleaner to have them defined in a platform-specific way, e.g.
> in a struct you obtain using device_get_match_data()?

Absolutely! I didn't do it at this stage since only one platform is supported
but we could just as well introduce a variant structure already for the table
sizes.

> > +
> > +	tables->load.size = 0x1000;
> > +	ret = sun6i_isp_table_setup(isp_dev, &tables->load);
> > +	if (ret)
> > +		return ret;
> > +
> > +	tables->save.size = 0x1000;
> > +	ret = sun6i_isp_table_setup(isp_dev, &tables->save);
> > +	if (ret)
> > +		return ret;
> > +
> > +	tables->lut.size = 0xe00;
> > +	ret = sun6i_isp_table_setup(isp_dev, &tables->lut);
> > +	if (ret)
> > +		return ret;
> > +
> > +	tables->drc.size = 0x600;
> > +	ret = sun6i_isp_table_setup(isp_dev, &tables->drc);
> > +	if (ret)
> > +		return ret;
> > +
> > +	tables->stats.size = 0x2100;
> > +	ret = sun6i_isp_table_setup(isp_dev, &tables->stats);
> 
> You can return already here.

Sure.

> > +	if (ret)
> > +		return ret;
> > +
> > +	return 0;
> > +}
> > +
> > +static void sun6i_isp_tables_cleanup(struct sun6i_isp_device *isp_dev)
> > +{
> > +	struct sun6i_isp_tables *tables = &isp_dev->tables;
> > +
> > +	sun6i_isp_table_cleanup(isp_dev, &tables->stats);
> > +	sun6i_isp_table_cleanup(isp_dev, &tables->drc);
> > +	sun6i_isp_table_cleanup(isp_dev, &tables->lut);
> > +	sun6i_isp_table_cleanup(isp_dev, &tables->save);
> > +	sun6i_isp_table_cleanup(isp_dev, &tables->load);
> > +}
> > +
> > +/* Media */
> > +
> > +static const struct media_device_ops sun6i_isp_media_ops = {
> > +	.link_notify = v4l2_pipeline_link_notify,
> > +};
> > +
> > +/* V4L2 */
> > +
> > +static int sun6i_isp_v4l2_setup(struct sun6i_isp_device *isp_dev)
> > +{
> > +	struct sun6i_isp_v4l2 *v4l2 = &isp_dev->v4l2;
> > +	struct v4l2_device *v4l2_dev = &v4l2->v4l2_dev;
> > +	struct media_device *media_dev = &v4l2->media_dev;
> > +	struct device *dev = isp_dev->dev;
> > +	int ret;
> > +
> > +	/* Media Device */
> > +
> > +	strscpy(media_dev->model, SUN6I_ISP_DESCRIPTION,
> > +		sizeof(media_dev->model));
> > +	snprintf(media_dev->bus_info, sizeof(media_dev->bus_info),
> > +		 "platform:%s", dev_name(dev));
> 
> This is no longer needed, see commit b0e38610f40a0f89e34939d2c7420590d67d86a3

Thanks!

> > +	media_dev->ops = &sun6i_isp_media_ops;
> > +	media_dev->hw_revision = 0;
> > +	media_dev->dev = dev;
> > +
> > +	media_device_init(media_dev);
> > +
> > +	ret = media_device_register(media_dev);
> > +	if (ret) {
> > +		dev_err(dev, "failed to register media device\n");
> > +		return ret;
> > +	}
> > +
> > +	/* V4L2 Control Handler */
> > +
> > +	ret = v4l2_ctrl_handler_init(&v4l2->ctrl_handler, 0);
> 
> I suppose you intend to add controls later on?

I might be wrong but I thought this was necessary to expose sensor controls
registered by subdevs that end up attached to this v4l2 device.

I doubt the drivers itself will expose controls otherwise.

[...]

> > +	isp_dev->clock_ram = devm_clk_get(dev, "ram");
> > +	if (IS_ERR(isp_dev->clock_ram)) {
> > +		dev_err(dev, "failed to acquire ram clock\n");
> > +		return PTR_ERR(isp_dev->clock_ram);
> > +	}
> > +
> > +	ret = clk_set_rate_exclusive(isp_dev->clock_mod, 297000000);
> 
> Is this also specific to the model?

There is less certainty that another platform that will use this driver
will need another rate, but I think it would look better to have it in the
variant anyway.

[...]

> > +static int sun6i_isp_capture_open(struct file *file)
> > +{
> > +	struct sun6i_isp_device *isp_dev = video_drvdata(file);
> > +	struct video_device *video_dev = &isp_dev->capture.video_dev;
> > +	struct mutex *lock = &isp_dev->capture.lock;
> > +	int ret;
> > +
> > +	if (mutex_lock_interruptible(lock))
> > +		return -ERESTARTSYS;
> > +
> > +	ret = v4l2_pipeline_pm_get(&video_dev->entity);
> 
> Do you need this?
> 
> Drivers should primarily depend on runtime PM, this is only needed for
> compatibility reasons. Instead I'd like to see sensor drivers being moved
> to runtime PM.

Yes it's still needed to support sensor drivers that don't use rpm yet.

[...]

> > +int sun6i_isp_capture_setup(struct sun6i_isp_device *isp_dev)
> > +{
> > +	struct sun6i_isp_capture *capture = &isp_dev->capture;
> > +	struct sun6i_isp_capture_state *state = &capture->state;
> > +	struct v4l2_device *v4l2_dev = &isp_dev->v4l2.v4l2_dev;
> > +	struct v4l2_subdev *proc_subdev = &isp_dev->proc.subdev;
> > +	struct video_device *video_dev = &capture->video_dev;
> > +	struct vb2_queue *queue = &capture->queue;
> > +	struct media_pad *pad = &capture->pad;
> > +	struct v4l2_format *format = &capture->format;
> > +	struct v4l2_pix_format *pix_format = &format->fmt.pix;
> > +	int ret;
> > +
> > +	/* State */
> > +
> > +	INIT_LIST_HEAD(&state->queue);
> > +	spin_lock_init(&state->lock);
> > +
> > +	/* Media Entity */
> > +
> > +	video_dev->entity.ops = &sun6i_isp_capture_entity_ops;
> > +
> > +	/* Media Pads */
> > +
> > +	pad->flags = MEDIA_PAD_FL_SINK | MEDIA_PAD_FL_MUST_CONNECT;
> > +
> > +	ret = media_entity_pads_init(&video_dev->entity, 1, pad);
> > +	if (ret)
> > +		goto error_mutex;
> 
> return ret;

Good catch, thanks!

[...]

> > +	ret = video_register_device(video_dev, VFL_TYPE_VIDEO, -1);
> > +	if (ret) {
> > +		v4l2_err(v4l2_dev, "failed to register video device: %d\n",
> > +			 ret);
> > +		goto error_media_entity;
> > +	}
> > +
> > +	v4l2_info(v4l2_dev, "device %s registered as %s\n", video_dev->name,
> > +		  video_device_node_name(video_dev));
> 
> This isn't really driver specific. I'd drop it.

I agree but I see that many drivers are doing it and the information can
actually be quite useful at times.

> > +
> > +	/* Media Pad Link */
> > +
> > +	ret = media_create_pad_link(&proc_subdev->entity,
> > +				    SUN6I_ISP_PROC_PAD_SOURCE,
> > +				    &video_dev->entity, 0,
> > +				    MEDIA_LNK_FL_ENABLED |
> > +				    MEDIA_LNK_FL_IMMUTABLE);
> > +	if (ret < 0) {
> > +		v4l2_err(v4l2_dev, "failed to create %s:%u -> %s:%u link\n",
> > +			 proc_subdev->entity.name, SUN6I_ISP_PROC_PAD_SOURCE,
> > +			 video_dev->entity.name, 0);
> 
> This error message printing would be better to be added to
> media_create_pad_link().

Yeah that makes sense.

[...]

> > +void sun6i_isp_params_configure(struct sun6i_isp_device *isp_dev)
> > +{
> > +	struct sun6i_isp_params_state *state = &isp_dev->params.state;
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&state->lock, flags);
> > +
> > +	sun6i_isp_params_configure_base(isp_dev);
> > +
> > +	/* Default config is only applied at the very first stream start. */
> > +	if (state->configured)
> > +		goto complete;
> > +
> > +	 sun6i_isp_params_configure_modules(isp_dev,
> 
> Indentation. Doesn't checkpatch.pl complain?

It doesn't, even with --strict, but that's definitely an issue there.

[...]

> > +static int sun6i_isp_params_querycap(struct file *file, void *private,
> > +				     struct v4l2_capability *capability)
> > +{
> > +	struct sun6i_isp_device *isp_dev = video_drvdata(file);
> > +	struct video_device *video_dev = &isp_dev->params.video_dev;
> > +
> > +	strscpy(capability->driver, SUN6I_ISP_NAME, sizeof(capability->driver));
> > +	strscpy(capability->card, video_dev->name, sizeof(capability->card));
> > +	snprintf(capability->bus_info, sizeof(capability->bus_info),
> > +		 "platform:%s", dev_name(isp_dev->dev));
> 
> This is no longer needed with commit
> 2a792fd5cf669d379d82354a99998d9ae9ff7d14 .

Thanks.

[...]

> > +static const struct v4l2_subdev_pad_ops sun6i_isp_proc_pad_ops = {
> > +	.init_cfg	= sun6i_isp_proc_init_cfg,
> > +	.enum_mbus_code	= sun6i_isp_proc_enum_mbus_code,
> > +	.get_fmt	= sun6i_isp_proc_get_fmt,
> > +	.set_fmt	= sun6i_isp_proc_set_fmt,
> > +};
> > +
> > +const struct v4l2_subdev_ops sun6i_isp_proc_subdev_ops = {
> 
> This can be static, can't it?

Oops, yes and it should be. Same applies to sun6i-csi-bridge actually.

[...]

> > +struct sun6i_isp_params_config_bdnf {
> > +	__u8	in_dis_min; // 8
> > +	__u8	in_dis_max; // 10
> 
> Are these default values or something else? Better documentation was in the
> TODO.txt file already.

Yes that's the default register values, but these comments are and overlook on
my side and should be removed.

Thanks!

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-staging@lists.linux.dev,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v3 3/4] staging: media: Add support for the Allwinner A31 ISP
Date: Thu, 28 Apr 2022 16:30:11 +0200	[thread overview]
Message-ID: <Ymqk89e+mn/1kLLx@aptenodytes> (raw)
In-Reply-To: <YmqFQSRBsqs4ghNQ@valkosipuli.retiisi.eu>


[-- Attachment #1.1: Type: text/plain, Size: 10074 bytes --]

Hi Sakari,

On Thu 28 Apr 22, 15:14, Sakari Ailus wrote:
> Hi Paul,
> 
> Thanks for the set.
> 
> A few comments below.

Thanks a lot for your review!

[...]

> >  .../staging/media/sunxi/sun6i-isp/TODO.txt    |   6 +
> 
> This should be called TODO (without .txt).

Understood!

> I understand this is an online ISP. How do you schedule the video buffer
> queues? Say, what happens if it's time to set up buffers for a frame and
> there's a buffer queued in the parameter queue but not in the image data
> queue? Or the other way around?

The ISP works in a quite atypical way, with a DMA buffer that is used to
hold upcoming parameters (including buffer addresses) and a bit in a "direct"
register to schedule the update of the parameters at next vsync.

The update (setting the bit) is triggered whenever new parameters are
submitted via the params video device or whenever there's a capture buffer
available in the capture video device.

So you don't particularly need to have one parameter buffer matching a capture
buffer, the two can be updated independently. Of course, a capture buffer will
only be returned after another buffer becomes active.

I hope this answers your concern!

[...]

> > +static int sun6i_isp_tables_setup(struct sun6i_isp_device *isp_dev)
> > +{
> > +	struct sun6i_isp_tables *tables = &isp_dev->tables;
> > +	int ret;
> > +
> > +	/* Sizes are hardcoded for now but actually depend on the platform. */
> 
> Would it be cleaner to have them defined in a platform-specific way, e.g.
> in a struct you obtain using device_get_match_data()?

Absolutely! I didn't do it at this stage since only one platform is supported
but we could just as well introduce a variant structure already for the table
sizes.

> > +
> > +	tables->load.size = 0x1000;
> > +	ret = sun6i_isp_table_setup(isp_dev, &tables->load);
> > +	if (ret)
> > +		return ret;
> > +
> > +	tables->save.size = 0x1000;
> > +	ret = sun6i_isp_table_setup(isp_dev, &tables->save);
> > +	if (ret)
> > +		return ret;
> > +
> > +	tables->lut.size = 0xe00;
> > +	ret = sun6i_isp_table_setup(isp_dev, &tables->lut);
> > +	if (ret)
> > +		return ret;
> > +
> > +	tables->drc.size = 0x600;
> > +	ret = sun6i_isp_table_setup(isp_dev, &tables->drc);
> > +	if (ret)
> > +		return ret;
> > +
> > +	tables->stats.size = 0x2100;
> > +	ret = sun6i_isp_table_setup(isp_dev, &tables->stats);
> 
> You can return already here.

Sure.

> > +	if (ret)
> > +		return ret;
> > +
> > +	return 0;
> > +}
> > +
> > +static void sun6i_isp_tables_cleanup(struct sun6i_isp_device *isp_dev)
> > +{
> > +	struct sun6i_isp_tables *tables = &isp_dev->tables;
> > +
> > +	sun6i_isp_table_cleanup(isp_dev, &tables->stats);
> > +	sun6i_isp_table_cleanup(isp_dev, &tables->drc);
> > +	sun6i_isp_table_cleanup(isp_dev, &tables->lut);
> > +	sun6i_isp_table_cleanup(isp_dev, &tables->save);
> > +	sun6i_isp_table_cleanup(isp_dev, &tables->load);
> > +}
> > +
> > +/* Media */
> > +
> > +static const struct media_device_ops sun6i_isp_media_ops = {
> > +	.link_notify = v4l2_pipeline_link_notify,
> > +};
> > +
> > +/* V4L2 */
> > +
> > +static int sun6i_isp_v4l2_setup(struct sun6i_isp_device *isp_dev)
> > +{
> > +	struct sun6i_isp_v4l2 *v4l2 = &isp_dev->v4l2;
> > +	struct v4l2_device *v4l2_dev = &v4l2->v4l2_dev;
> > +	struct media_device *media_dev = &v4l2->media_dev;
> > +	struct device *dev = isp_dev->dev;
> > +	int ret;
> > +
> > +	/* Media Device */
> > +
> > +	strscpy(media_dev->model, SUN6I_ISP_DESCRIPTION,
> > +		sizeof(media_dev->model));
> > +	snprintf(media_dev->bus_info, sizeof(media_dev->bus_info),
> > +		 "platform:%s", dev_name(dev));
> 
> This is no longer needed, see commit b0e38610f40a0f89e34939d2c7420590d67d86a3

Thanks!

> > +	media_dev->ops = &sun6i_isp_media_ops;
> > +	media_dev->hw_revision = 0;
> > +	media_dev->dev = dev;
> > +
> > +	media_device_init(media_dev);
> > +
> > +	ret = media_device_register(media_dev);
> > +	if (ret) {
> > +		dev_err(dev, "failed to register media device\n");
> > +		return ret;
> > +	}
> > +
> > +	/* V4L2 Control Handler */
> > +
> > +	ret = v4l2_ctrl_handler_init(&v4l2->ctrl_handler, 0);
> 
> I suppose you intend to add controls later on?

I might be wrong but I thought this was necessary to expose sensor controls
registered by subdevs that end up attached to this v4l2 device.

I doubt the drivers itself will expose controls otherwise.

[...]

> > +	isp_dev->clock_ram = devm_clk_get(dev, "ram");
> > +	if (IS_ERR(isp_dev->clock_ram)) {
> > +		dev_err(dev, "failed to acquire ram clock\n");
> > +		return PTR_ERR(isp_dev->clock_ram);
> > +	}
> > +
> > +	ret = clk_set_rate_exclusive(isp_dev->clock_mod, 297000000);
> 
> Is this also specific to the model?

There is less certainty that another platform that will use this driver
will need another rate, but I think it would look better to have it in the
variant anyway.

[...]

> > +static int sun6i_isp_capture_open(struct file *file)
> > +{
> > +	struct sun6i_isp_device *isp_dev = video_drvdata(file);
> > +	struct video_device *video_dev = &isp_dev->capture.video_dev;
> > +	struct mutex *lock = &isp_dev->capture.lock;
> > +	int ret;
> > +
> > +	if (mutex_lock_interruptible(lock))
> > +		return -ERESTARTSYS;
> > +
> > +	ret = v4l2_pipeline_pm_get(&video_dev->entity);
> 
> Do you need this?
> 
> Drivers should primarily depend on runtime PM, this is only needed for
> compatibility reasons. Instead I'd like to see sensor drivers being moved
> to runtime PM.

Yes it's still needed to support sensor drivers that don't use rpm yet.

[...]

> > +int sun6i_isp_capture_setup(struct sun6i_isp_device *isp_dev)
> > +{
> > +	struct sun6i_isp_capture *capture = &isp_dev->capture;
> > +	struct sun6i_isp_capture_state *state = &capture->state;
> > +	struct v4l2_device *v4l2_dev = &isp_dev->v4l2.v4l2_dev;
> > +	struct v4l2_subdev *proc_subdev = &isp_dev->proc.subdev;
> > +	struct video_device *video_dev = &capture->video_dev;
> > +	struct vb2_queue *queue = &capture->queue;
> > +	struct media_pad *pad = &capture->pad;
> > +	struct v4l2_format *format = &capture->format;
> > +	struct v4l2_pix_format *pix_format = &format->fmt.pix;
> > +	int ret;
> > +
> > +	/* State */
> > +
> > +	INIT_LIST_HEAD(&state->queue);
> > +	spin_lock_init(&state->lock);
> > +
> > +	/* Media Entity */
> > +
> > +	video_dev->entity.ops = &sun6i_isp_capture_entity_ops;
> > +
> > +	/* Media Pads */
> > +
> > +	pad->flags = MEDIA_PAD_FL_SINK | MEDIA_PAD_FL_MUST_CONNECT;
> > +
> > +	ret = media_entity_pads_init(&video_dev->entity, 1, pad);
> > +	if (ret)
> > +		goto error_mutex;
> 
> return ret;

Good catch, thanks!

[...]

> > +	ret = video_register_device(video_dev, VFL_TYPE_VIDEO, -1);
> > +	if (ret) {
> > +		v4l2_err(v4l2_dev, "failed to register video device: %d\n",
> > +			 ret);
> > +		goto error_media_entity;
> > +	}
> > +
> > +	v4l2_info(v4l2_dev, "device %s registered as %s\n", video_dev->name,
> > +		  video_device_node_name(video_dev));
> 
> This isn't really driver specific. I'd drop it.

I agree but I see that many drivers are doing it and the information can
actually be quite useful at times.

> > +
> > +	/* Media Pad Link */
> > +
> > +	ret = media_create_pad_link(&proc_subdev->entity,
> > +				    SUN6I_ISP_PROC_PAD_SOURCE,
> > +				    &video_dev->entity, 0,
> > +				    MEDIA_LNK_FL_ENABLED |
> > +				    MEDIA_LNK_FL_IMMUTABLE);
> > +	if (ret < 0) {
> > +		v4l2_err(v4l2_dev, "failed to create %s:%u -> %s:%u link\n",
> > +			 proc_subdev->entity.name, SUN6I_ISP_PROC_PAD_SOURCE,
> > +			 video_dev->entity.name, 0);
> 
> This error message printing would be better to be added to
> media_create_pad_link().

Yeah that makes sense.

[...]

> > +void sun6i_isp_params_configure(struct sun6i_isp_device *isp_dev)
> > +{
> > +	struct sun6i_isp_params_state *state = &isp_dev->params.state;
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&state->lock, flags);
> > +
> > +	sun6i_isp_params_configure_base(isp_dev);
> > +
> > +	/* Default config is only applied at the very first stream start. */
> > +	if (state->configured)
> > +		goto complete;
> > +
> > +	 sun6i_isp_params_configure_modules(isp_dev,
> 
> Indentation. Doesn't checkpatch.pl complain?

It doesn't, even with --strict, but that's definitely an issue there.

[...]

> > +static int sun6i_isp_params_querycap(struct file *file, void *private,
> > +				     struct v4l2_capability *capability)
> > +{
> > +	struct sun6i_isp_device *isp_dev = video_drvdata(file);
> > +	struct video_device *video_dev = &isp_dev->params.video_dev;
> > +
> > +	strscpy(capability->driver, SUN6I_ISP_NAME, sizeof(capability->driver));
> > +	strscpy(capability->card, video_dev->name, sizeof(capability->card));
> > +	snprintf(capability->bus_info, sizeof(capability->bus_info),
> > +		 "platform:%s", dev_name(isp_dev->dev));
> 
> This is no longer needed with commit
> 2a792fd5cf669d379d82354a99998d9ae9ff7d14 .

Thanks.

[...]

> > +static const struct v4l2_subdev_pad_ops sun6i_isp_proc_pad_ops = {
> > +	.init_cfg	= sun6i_isp_proc_init_cfg,
> > +	.enum_mbus_code	= sun6i_isp_proc_enum_mbus_code,
> > +	.get_fmt	= sun6i_isp_proc_get_fmt,
> > +	.set_fmt	= sun6i_isp_proc_set_fmt,
> > +};
> > +
> > +const struct v4l2_subdev_ops sun6i_isp_proc_subdev_ops = {
> 
> This can be static, can't it?

Oops, yes and it should be. Same applies to sun6i-csi-bridge actually.

[...]

> > +struct sun6i_isp_params_config_bdnf {
> > +	__u8	in_dis_min; // 8
> > +	__u8	in_dis_max; // 10
> 
> Are these default values or something else? Better documentation was in the
> TODO.txt file already.

Yes that's the default register values, but these comments are and overlook on
my side and should be removed.

Thanks!

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-04-28 14:31 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-15 15:37 [PATCH v3 0/4] Allwinner A31/A83T MIPI CSI-2 and A31 ISP / ISP Driver Paul Kocialkowski
2022-04-15 15:37 ` Paul Kocialkowski
2022-04-15 15:37 ` [PATCH v3 1/4] dt-bindings: media: Add Allwinner A31 ISP bindings documentation Paul Kocialkowski
2022-04-15 15:37   ` Paul Kocialkowski
2022-04-16  1:59   ` Samuel Holland
2022-04-16  1:59     ` Samuel Holland
2022-04-19  9:45     ` Paul Kocialkowski
2022-04-19  9:45       ` Paul Kocialkowski
2022-04-19 13:48       ` Rob Herring
2022-04-19 13:48         ` Rob Herring
2022-04-16 22:17   ` Rob Herring
2022-04-16 22:17     ` Rob Herring
2022-04-15 15:37 ` [PATCH v3 2/4] dt-bindings: media: sun6i-a31-csi: Add ISP output port Paul Kocialkowski
2022-04-15 15:37   ` Paul Kocialkowski
2022-04-19 13:08   ` Rob Herring
2022-04-19 13:08     ` Rob Herring
2022-04-19 13:35     ` Paul Kocialkowski
2022-04-19 13:35       ` Paul Kocialkowski
2022-04-15 15:37 ` [PATCH v3 3/4] staging: media: Add support for the Allwinner A31 ISP Paul Kocialkowski
2022-04-15 15:37   ` Paul Kocialkowski
2022-04-20  7:42   ` Dan Carpenter
2022-04-20  7:42     ` Dan Carpenter
2022-04-20  7:50     ` Paul Kocialkowski
2022-04-20  7:50       ` Paul Kocialkowski
2022-04-20  8:51       ` Dan Carpenter
2022-04-20  8:51         ` Dan Carpenter
2022-04-20  8:53         ` Dan Carpenter
2022-04-20  8:53           ` Dan Carpenter
2022-04-28 12:14   ` Sakari Ailus
2022-04-28 12:14     ` Sakari Ailus
2022-04-28 14:30     ` Paul Kocialkowski [this message]
2022-04-28 14:30       ` Paul Kocialkowski
2022-04-28 21:07       ` Sakari Ailus
2022-04-28 21:07         ` Sakari Ailus
2022-05-20 14:57         ` Paul Kocialkowski
2022-05-20 14:57           ` Paul Kocialkowski
2022-05-22 17:34           ` Laurent Pinchart
2022-05-22 17:34             ` Laurent Pinchart
2022-05-23 12:51             ` Paul Kocialkowski
2022-05-23 12:51               ` Paul Kocialkowski
2022-05-23 13:27               ` Laurent Pinchart
2022-05-23 13:27                 ` Laurent Pinchart
2022-05-24 12:37                 ` Paul Kocialkowski
2022-05-24 12:37                   ` Paul Kocialkowski
2022-04-15 15:37 ` [PATCH v3 4/4] MAINTAINERS: Add entry for the Allwinner A31 ISP driver Paul Kocialkowski
2022-04-15 15:37   ` Paul Kocialkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ymqk89e+mn/1kLLx@aptenodytes \
    --to=paul.kocialkowski@bootlin.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hans.verkuil@cisco.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=mchehab@kernel.org \
    --cc=mripard@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@iki.fi \
    --cc=sakari.ailus@linux.intel.com \
    --cc=samuel@sholland.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.