linux-staging.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Changhuang Liang <changhuang.liang@starfivetech.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Jack Zhu <jack.zhu@starfivetech.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>
Subject: Re: 回复: 回复: 回复: 回复: [PATCH] staging: media: starfive: Add multiple resolution support
Date: Mon, 19 Aug 2024 11:19:53 +0300	[thread overview]
Message-ID: <20240819081953.GM29465@pendragon.ideasonboard.com> (raw)
In-Reply-To: <ZQ0PR01MB1302CE9D6EC726D3FBE8D6EDF28C2@ZQ0PR01MB1302.CHNPR01.prod.partner.outlook.cn>

On Mon, Aug 19, 2024 at 01:37:30AM +0000, Changhuang Liang wrote:
> > On Mon, Aug 12, 2024 at 12:13:03PM +0000, Changhuang Liang wrote:
> > > > On Mon, Aug 12, 2024 at 09:43:47AM +0000, Changhuang Liang wrote:
> > > > > > On Fri, Aug 09, 2024 at 12:12:01PM +0000, Changhuang Liang wrote:
> > > > > > > > On Fri, Apr 19, 2024 at 01:19:55AM -0700, Changhuang Liang wrote:
> > > > > > > > > Add multiple resolution support for video "capture_raw" device.
> > > > > > > > > Otherwise it will capture the wrong image data if the width is not 1920.
> > > > > > > > >
> > > > > > > > > Fixes: e080f339c80a ("media: staging: media: starfive: camss: Add capture driver")
> > > > > > > > >
> > > > > > > > > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > > > > > > > > ---
> > > > > > > > >  drivers/staging/media/starfive/camss/stf-capture.c | 5 ++++-
> > > > > > > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git
> > > > > > > > > a/drivers/staging/media/starfive/camss/stf-capture.c
> > > > > > > > > b/drivers/staging/media/starfive/camss/stf-capture.c
> > > > > > > > > index ec5169e7b391..9e853ff2596a 100644
> > > > > > > > > --- a/drivers/staging/media/starfive/camss/stf-capture.c
> > > > > > > > > +++ b/drivers/staging/media/starfive/camss/stf-capture.c
> > > > > > > > > @@ -177,9 +177,12 @@ static void stf_channel_set(struct stfcamss_video *video)  {
> > > > > > > > >  	struct stf_capture *cap = to_stf_capture(video);
> > > > > > > > >  	struct stfcamss *stfcamss = cap->video.stfcamss;
> > > > > > > > > +	struct v4l2_pix_format *pix;
> > > > > > > >
> > > > > > > > This variable can be const as you don't modify the format.
> > > > > > > >
> > > > > > > > >  	u32 val;
> > > > > > > > >
> > > > > > > > >  	if (cap->type == STF_CAPTURE_RAW) {
> > > > > > > > > +		pix = &video->active_fmt.fmt.pix;
> > > > > > > >
> > > > > > > > And it can be declared and initialized here:
> > > > > > > >
> > > > > > > > 		const struct v4l2_pix_format *pix = &video->active_fmt.fmt.pix;
> > > > > > > >
> > > > > > > > > +
> > > > > > > > >  		val = stf_syscon_reg_read(stfcamss, VIN_CHANNEL_SEL_EN);
> > > > > > > > >  		val &= ~U0_VIN_CHANNEL_SEL_MASK;
> > > > > > > > >  		val |= CHANNEL(0);
> > > > > > > > > @@ -193,7 +196,7 @@ static void stf_channel_set(struct stfcamss_video *video)
> > > > > > > > >  		val |= PIXEL_HEIGH_BIT_SEL(0);
> > > > > > > > >
> > > > > > > > >  		val &= ~U0_VIN_PIX_CNT_END_MASK;
> > > > > > > > > -		val |= PIX_CNT_END(IMAGE_MAX_WIDTH / 4 - 1);
> > > > > > > > > +		val |= PIX_CNT_END(pix->width / 4 - 1);
> > > > > > > >
> > > > > > > > Is there no need to consider the image height as well ? How
> > > > > > > > does the driver prevent buffer overflows if the sensor
> > > > > > > > sends more data than expected ?
> > > > > > >
> > > > > > > Our hardware will confirm a frame of data through vblank
> > > > > > > signal, so there is no image height configuration.
> > > > > >
> > > > > > What happens if the system expects, for instance, a 1920x1080
> > > > > > RAW8 image, and allocates a buffer of of 1920x1080 bytes, but
> > > > > > the sensor outputs more lines ? Does the camera hardware in the
> > > > > > SoC offer an option to prevent buffer overruns ?
> > > > >
> > > > > The hardware can confirm the image height by using the VSYNC signal.
> > > > >
> > > > > Image will transfer when VSYNC is high.
> > > > >
> > > > > VSYNC time = (width + h_blank) * height;
> > > >
> > > > What I'm trying to understand is what happens if the ISP is configured for
> > > > 1080 lines, but the camera sensor sends more than 1080 lines (the
> > > > VSYNC signal is active for more than 1080 lines). Where in the
> > > > driver is the hardware configure with the 1080 lines limit to avoid buffer overflows ?
> > >
> > > If is "capture_raw" video device, no image height can be configured.
> > 
> > In that case what happens if the camera sensor sends more lines than
> > expected ? Will the raw video device write past the end of the buffer ?
> 
> Yes, the buffer will overflows, so we will use the software restrictions.
> Implement .link_validate hooks for the CSI2RX subdev and "capture_raw" video device.

Is there an IOMMU in the system that could help preventing buffer
overflows to reach system memory ?

> > If so, is there a way to guard against that ?
> > 
> > > If is "capture_yuv" video device, it will be set by stf_isp_config_crop.
> > 
> > Thank you, that's the information I was looking for.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2024-08-19  8:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-19  8:19 [PATCH] staging: media: starfive: Add multiple resolution support Changhuang Liang
2024-08-09  8:29 ` 回复: " Changhuang Liang
2024-08-09  8:48   ` Hans Verkuil
2024-08-09  9:57 ` Laurent Pinchart
2024-08-09 12:12   ` 回复: " Changhuang Liang
2024-08-09 13:26     ` Laurent Pinchart
2024-08-12  9:43       ` 回复: " Changhuang Liang
2024-08-12 10:33         ` Laurent Pinchart
2024-08-12 12:13           ` 回复: " Changhuang Liang
2024-08-19  0:13             ` Laurent Pinchart
2024-08-19  1:37               ` 回复: " Changhuang Liang
2024-08-19  8:19                 ` Laurent Pinchart [this message]
2024-08-19 13:18                   ` 回复: " Changhuang Liang
2024-08-23 14:46                     ` Laurent Pinchart

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=20240819081953.GM29465@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=changhuang.liang@starfivetech.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jack.zhu@starfivetech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=mchehab@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).