Yes, thank you very much! 2011/4/12 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: > On Tue, 12 Apr 2011, Kassey Lee wrote: > >> 2011/4/12 Kassey Lee <kassey1216@xxxxxxxxx>: >> > Hi, Guennadi; >> > for sizeimage , I agree with you. that we can overwrite it >> > after a frame is done. >> > >> > for byteperline: on Marvell soc. >> > it needs to know the bytesperline before receive frame from sensor. >> > what we did now is hardcode in host driver for bytesperline. >> > >> > since different sensors have different timing for JPEG, and >> > bytesperline is different. >> > while soc_mbus_bytes_per_line does not support JPEG. >> > >> > So, we want that host driver can get byteperline from sensor >> > driver (sub dev) before transfer a frame for JPEG format. >> > a way to do this: >> > soc_mbus_bytes_per_line return 0 for JPEG, and host driver will >> > try another API to get bytesperline for JPEG from sensor driver. >> > the effort is new API or reused other API. >> > >> > Is that reasonable ? > > If you mean this your patch > > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/31323/match= > > then I've queued it for 2.6.40. > > Thanks > Guennadi > >> > >> > >> > >> > 2011/4/12 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: >> >> Hi >> >> >> >> On Tue, 12 Apr 2011, Kassey Lee wrote: >> >> >> >>> hi, Guennadi: >> >>> a lot of sensors support JPEG output. >> >>> 1) bytesperline is defined by sensor timing. >> >>> 2) and sizeimage is unknow for jpeg. >> >>> >> >>> how about for JPEG >> >>> 1) host driver gets bytesperline from sensor driver. >> >>> 2) sizeimage refilled by host driver after dma transfer done( a >> >>> frame is received) >> >>> thanks. >> >> >> >> How is this done currently on other V4L2 drivers? To transfer a frame you >> >> usually first do at least one of S_FMT and G_FMT, at which time you >> >> already have to report sizeimage to the user - before any transfer has >> >> taken place. Currently with soc-camera it is already possible to override >> >> sizeimage and bytesperline from the host driver. Just set them to whatever >> >> you need in your try_fmt and they will be kept. Not sure how you want to >> >> do that, if you need to first read in a frame - do you want to perform >> >> some dummy frame transfer? You might not even have any buffers queued yet, >> >> so, it has to be a read without writing to RAM. Don't such compressed >> >> formats just put a value in sizeimage, that is a calculated maximum size? >> >> >> >> Thanks >> >> Guennadi >> >> >> >>> 2011/4/11 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: >> >>> > Hi Janusz >> >>> > >> >>> > On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: >> >>> > >> >>> >> Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and >> >>> >> sizeimage memebers of v4l2_pix_format structure have no longer been >> >>> >> calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via >> >>> >> soc_camera_device structure from a host driver callback invoked by >> >>> >> soc_camera_set_fmt(). >> >>> >> >> >>> >> OMAP1 camera host driver has never been providing these parameters, so >> >>> >> it no longer works correctly. Fix it by adding suitable assignments to >> >>> >> omap1_cam_set_fmt(). >> >>> > >> >>> > Thanks for the patch, but now it looks like many soc-camera host drivers >> >>> > are re-implementing this very same calculation in different parts of their >> >>> > code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, >> >>> > implement this centrally in soc_camera.c and remove all those >> >>> > calculations? Could you cook up a patch or maybe several patches - for >> >>> > soc_camera.c and all drivers? >> >>> > >> >>> > Thanks >> >>> > Guennadi >> >>> > >> >>> >> >> >>> >> Signed-off-by: Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> >> >>> >> --- >> >>> >> drivers/media/video/omap1_camera.c | 6 ++++++ >> >>> >> 1 file changed, 6 insertions(+) >> >>> >> >> >>> >> --- linux-2.6.39-rc2/drivers/media/video/omap1_camera.c.orig 2011-04-06 14:30:37.000000000 +0200 >> >>> >> +++ linux-2.6.39-rc2/drivers/media/video/omap1_camera.c 2011-04-09 00:16:36.000000000 +0200 >> >>> >> @@ -1292,6 +1292,12 @@ static int omap1_cam_set_fmt(struct soc_ >> >>> >> pix->colorspace = mf.colorspace; >> >>> >> icd->current_fmt = xlate; >> >>> >> >> >>> >> + pix->bytesperline = soc_mbus_bytes_per_line(pix->width, >> >>> >> + xlate->host_fmt); >> >>> >> + if (pix->bytesperline < 0) >> >>> >> + return pix->bytesperline; >> >>> >> + pix->sizeimage = pix->height * pix->bytesperline; >> >>> >> + >> >>> >> return 0; >> >>> >> } >> >>> >> >> >>> >> >> >>> > >> >>> > --- >> >>> > Guennadi Liakhovetski, Ph.D. >> >>> > Freelance Open-Source Software Developer >> >>> > http://www.open-technology.de/ >> >>> > -- >> >>> > To unsubscribe from this list: send the line "unsubscribe linux-media" in >> >>> > the body of a message to majordomo@xxxxxxxxxxxxxxx >> >>> > More majordomo info at http://vger.kernel.org/majordomo-info.html >> >>> > >> >>> >> >> >> >> --- >> >> Guennadi Liakhovetski, Ph.D. >> >> Freelance Open-Source Software Developer >> >> http://www.open-technology.de/ >> >> -- >> >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> > >> > > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
