[PATCH] Add interlace support to sh_mobile_ceu_camera.c

[PATCH] Add interlace support to sh_mobile_ceu_camera.c

[Kuninori Morimoto]

Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
---
This patch needs Magnus's "nv1x/nvx1 support for the sh_mobile_ceu driver" patch

 drivers/media/video/sh_mobile_ceu_camera.c |   47 ++++++++++++++++++++++------
 1 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/drivers/media/video/sh_mobile_ceu_camera.c b/drivers/media/video/sh_mobile_ceu_camera.c
index 5701363..13addd8 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -97,6 +97,7 @@ struct sh_mobile_ceu_dev {
 	spinlock_t lock;
 	struct list_head capture;
 	struct videobuf_buffer *active;
+	int is_interlace;
 
 	struct sh_mobile_ceu_info *pdata;
 
@@ -161,7 +162,7 @@ static void free_buffer(struct videobuf_queue *vq,
 static void sh_mobile_ceu_capture(struct sh_mobile_ceu_dev *pcdev)
 {
 	struct soc_camera_device *icd = pcdev->icd;
-	unsigned long phys_addr;
+	unsigned long phys_addr_t, phys_addr_b = 0;
 
 	ceu_write(pcdev, CEIER, ceu_read(pcdev, CEIER) & ~1);
 	ceu_write(pcdev, CETCR, ~ceu_read(pcdev, CETCR) & 0x0317f313);
@@ -174,16 +175,25 @@ static void sh_mobile_ceu_capture(struct sh_mobile_ceu_dev *pcdev)
 	if (!pcdev->active)
 		return;
 
-	phys_addr = videobuf_to_dma_contig(pcdev->active);
-	ceu_write(pcdev, CDAYR, phys_addr);
+	phys_addr_t = videobuf_to_dma_contig(pcdev->active);
+	ceu_write(pcdev, CDAYR, phys_addr_t);
+	if (pcdev->is_interlace) {
+		phys_addr_b = phys_addr_t + icd->width;
+		ceu_write(pcdev, CDBYR, phys_addr_b);
+	}
+
 
 	switch (icd->current_fmt->fourcc) {
 	case V4L2_PIX_FMT_NV12:
 	case V4L2_PIX_FMT_NV21:
 	case V4L2_PIX_FMT_NV16:
 	case V4L2_PIX_FMT_NV61:
-		phys_addr += (icd->width * icd->height);
-		ceu_write(pcdev, CDACR, phys_addr);
+		phys_addr_t += (icd->width * icd->height);
+		ceu_write(pcdev, CDACR, phys_addr_t);
+		if (pcdev->is_interlace) {
+			phys_addr_b += (icd->width * icd->height);
+			ceu_write(pcdev, CDBCR, phys_addr_b);
+		}
 	}
 
 	pcdev->active->state = VIDEOBUF_ACTIVE;
@@ -379,7 +389,7 @@ static int sh_mobile_ceu_set_bus_param(struct soc_camera_device *icd,
 {
 	struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
 	struct sh_mobile_ceu_dev *pcdev = ici->priv;
-	int ret, buswidth, width, cfszr_width, cdwdr_width;
+	int ret, buswidth, width, height, cfszr_width, cdwdr_width;
 	unsigned long camera_flags, common_flags, value;
 	int yuv_mode, yuv_lineskip;
 
@@ -446,7 +456,7 @@ static int sh_mobile_ceu_set_bus_param(struct soc_camera_device *icd,
 	ceu_write(pcdev, CAMCR, value);
 
 	ceu_write(pcdev, CAPCR, 0x00300000);
-	ceu_write(pcdev, CAIFR, 0);
+	ceu_write(pcdev, CAIFR, (pcdev->is_interlace) ? 0x101 : 0);
 
 	mdelay(1);
 
@@ -461,10 +471,16 @@ static int sh_mobile_ceu_set_bus_param(struct soc_camera_device *icd,
 		cdwdr_width = (buswidth == 16) ? width * 2 : width;
 	}
 
+	height = icd->height;
+	if (pcdev->is_interlace) {
+		height      /= 2;
+		cdwdr_width *= 2;
+	}
+
 	ceu_write(pcdev, CAMOR, 0);
-	ceu_write(pcdev, CAPWR, (icd->height << 16) | width);
+	ceu_write(pcdev, CAPWR, (height << 16) | width);
 	ceu_write(pcdev, CFLCR, 0); /* no scaling */
-	ceu_write(pcdev, CFSZR, (icd->height << 16) | cfszr_width);
+	ceu_write(pcdev, CFSZR, (height << 16) | cfszr_width);
 	ceu_write(pcdev, CLFCR, 0); /* no lowpass filter */
 
 	/* A few words about byte order (observed in Big Endian mode)
@@ -613,8 +629,10 @@ static int sh_mobile_ceu_try_fmt(struct soc_camera_device *icd,
 				 struct v4l2_format *f)
 {
 	struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
+	struct sh_mobile_ceu_dev *pcdev = ici->priv;
 	const struct soc_camera_format_xlate *xlate;
 	__u32 pixfmt = f->fmt.pix.pixelformat;
+	int ret;
 
 	xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
 	if (!xlate) {
@@ -640,8 +658,16 @@ static int sh_mobile_ceu_try_fmt(struct soc_camera_device *icd,
 	f->fmt.pix.sizeimage = f->fmt.pix.height * f->fmt.pix.bytesperline;
 
 	/* limit to sensor capabilities */
-	return icd->ops->try_fmt(icd, f);
+	ret = icd->ops->try_fmt(icd, f);
+
+	pcdev->is_interlace = 0;
+	if (V4L2_FIELD_INTERLACED == f->fmt.pix.field) {
+		pcdev->is_interlace = 1;
+		f->fmt.pix.field = V4L2_FIELD_NONE;
+	}
+
+	return ret;
+
 }
 
 static int sh_mobile_ceu_reqbufs(struct soc_camera_file *icf,
-- 
1.5.6.3

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[morimoto.kuninori]

Dear Guennadi

> Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
> ---
> This patch needs Magnus's "nv1x/nvx1 support for the sh_mobile_ceu driver" patch

I'm sorry that this patch seems to not be able to apply smartly.
The line is wrong.

I will re-send this patch again.
Sorry again.

Best regards
--
Kuninori Morimoto
 

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[Guennadi Liakhovetski]

Hello Morimoto-san

I've got a question to you, regarding your interlaced support 
implementation for the CEU: do I understand it right, that the kind of 
support you actually have implemented is, that if an interlaced format is 
now requested from the CEU, it will interpret incoming data as interlaced 
and deinterlace it internally? If this is really the case, then, I think, 
it is a wrong way to implement this functionality. If a user requests 
interlaced data, it means, (s)he wants it interlaced in memory. Whereas 
deinterlacing should happen transparently - if the user requested 
progressive data and your source provides interlaced, you can decide to 
deinterlace it internally. Or am I misunderstanding your implementation?

Regardless of theoretical correctness - does your patch still work? Have 
you been able back then to get CEU to deinterlace data, and when have you 
last tested it?

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[Kuninori Morimoto]

Dear Guennadi

> I've got a question to you, regarding your interlaced support 
> implementation for the CEU: do I understand it right, that the kind of 
> support you actually have implemented is, that if an interlaced format is 
> now requested from the CEU, it will interpret incoming data as interlaced 
> and deinterlace it internally? 

It is correct excluding "interlaced format is now requested from the CEU". 
Now, the device which request interlace format is video device.
If you use Ecovec, it is tw9910.

> If this is really the case, then, I think, 
> it is a wrong way to implement this functionality. If a user requests 
> interlaced data, it means, (s)he wants it interlaced in memory. Whereas 
> deinterlacing should happen transparently - if the user requested 
> progressive data and your source provides interlaced, you can decide to 
> deinterlace it internally. Or am I misunderstanding your implementation?

Hmm...
Now only "CEU + tw9910" pair use interlace mode in CEU.
But it doesn't support interlace mode from "user space".
(I don't know how to request it from user space)
Now interlace mode is used internally.
This mean, it seems as "progressive mode" from user space.

> Regardless of theoretical correctness - does your patch still work? Have 
> you been able back then to get CEU to deinterlace data, and when have you 
> last tested it?

I tested CEU interlace mode by using Ecovec board.
I can watch correct video image on at least v2.6.34.

I used this command.

VIDIX="-vo fbdev:vidix:sh_veu"
SIZE="-tv width=1280:height=720"
NTSC="-tv norm=NTSC"
OUT="tv:// -tv outfmt=nv12"
DEVICE="-tv device=/dev/video0"
mplayer ${VIDIX} ${SIZE} ${NTSC} ${OUT} ${DEVICE}

Best regards
--
Kuninori Morimoto
 

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[Guennadi Liakhovetski]

On Tue, 13 Jul 2010, Kuninori Morimoto wrote:

> 
> Dear Guennadi
> 
> > I've got a question to you, regarding your interlaced support 
> > implementation for the CEU: do I understand it right, that the kind of 
> > support you actually have implemented is, that if an interlaced format is 
> > now requested from the CEU, it will interpret incoming data as interlaced 
> > and deinterlace it internally? 
> 
> It is correct excluding "interlaced format is now requested from the CEU". 
> Now, the device which request interlace format is video device.
> If you use Ecovec, it is tw9910.

That's one part of the equation, yes.

> > If this is really the case, then, I think, 
> > it is a wrong way to implement this functionality. If a user requests 
> > interlaced data, it means, (s)he wants it interlaced in memory. Whereas 
> > deinterlacing should happen transparently - if the user requested 
> > progressive data and your source provides interlaced, you can decide to 
> > deinterlace it internally. Or am I misunderstanding your implementation?
> 
> Hmm...
> Now only "CEU + tw9910" pair use interlace mode in CEU.
> But it doesn't support interlace mode from "user space".
> (I don't know how to request it from user space)

The S_FMT ioctl() has a field "fmt.pix.field," which carries exactly this 
information. So, by executing this ioctl() with different field values you 
request progressive or one of interlaced formats. And returning 
"interlaced," when you actually supply progressive data to the user is not 
a good idea, and this is what's currently happening, I think. It's just 
our luck, that mplayer (and gstreamer?) ignore returned field value. But 
we'll have to fix this in sh_mobile_ceu_camera.

> Now interlace mode is used internally.
> This mean, it seems as "progressive mode" from user space.

Exactly, we return progressive data, but give "interlaced" back in reply 
to S_FMT. Or at least we do not differentiate between "user field setting" 
and "driver field setting," which we really should.

> > Regardless of theoretical correctness - does your patch still work? Have 
> > you been able back then to get CEU to deinterlace data, and when have you 
> > last tested it?
> 
> I tested CEU interlace mode by using Ecovec board.
> I can watch correct video image on at least v2.6.34.
> 
> I used this command.
> 
> VIDIX="-vo fbdev:vidix:sh_veu"
> SIZE="-tv width=1280:height=720"
> NTSC="-tv norm=NTSC"
> OUT="tv:// -tv outfmt=nv12"
> DEVICE="-tv device=/dev/video0"
> mplayer ${VIDIX} ${SIZE} ${NTSC} ${OUT} ${DEVICE}

Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works 
on migor for me, but not on ecovec, although the chip can be detected. Are 
there any modifications necessary to the kernel or to the board to get it 
to work? Maybe a jumper or something? I plug in a video signal source in 
the "video in" connector, next to the "viceo out" one, using the same 
cable, so, cabling should work too. But I'm only getting select timeouts 
and no interrupts on the CEU.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[Kuninori Morimoto]

Dear Guennadi


> our luck, that mplayer (and gstreamer?) ignore returned field value. But 
> we'll have to fix this in sh_mobile_ceu_camera.

Hmm  I understand.
I guess, at first, we need test program for it.


> Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works 
> on migor for me, but not on ecovec, although the chip can be detected. Are 
> there any modifications necessary to the kernel or to the board to get it 
> to work? Maybe a jumper or something? I plug in a video signal source in 
> the "video in" connector, next to the "viceo out" one, using the same 
> cable, so, cabling should work too. But I'm only getting select timeouts 
> and no interrupts on the CEU.

Hmm..  strange...
No kernel patch is needed to use tw9910 on Ecovec.

Ahh...
Maybe the criminal is dip-switch.
We can not use "tw9910" and "2nd camera" in same time.

Please check DS2[3] on Ecovec.
It should OFF when you use tw9910.

I wrote dip-switch info on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
Please check it too.

Best regards
--
Kuninori Morimoto
 

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[hermann pitton]

Am Mittwoch, den 14.07.2010, 09:12 +0900 schrieb Kuninori Morimoto:
> Dear Guennadi
> 
> 
> > our luck, that mplayer (and gstreamer?) ignore returned field value. But 
> > we'll have to fix this in sh_mobile_ceu_camera.
> 
> Hmm  I understand.
> I guess, at first, we need test program for it.
> 
> 
> > Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works 
> > on migor for me, but not on ecovec, although the chip can be detected. Are 
> > there any modifications necessary to the kernel or to the board to get it 
> > to work? Maybe a jumper or something? I plug in a video signal source in 
> > the "video in" connector, next to the "viceo out" one, using the same 
> > cable, so, cabling should work too. But I'm only getting select timeouts 
> > and no interrupts on the CEU.
> 
> Hmm..  strange...
> No kernel patch is needed to use tw9910 on Ecovec.
> 
> Ahh...
> Maybe the criminal is dip-switch.
> We can not use "tw9910" and "2nd camera" in same time.
> 
> Please check DS2[3] on Ecovec.
> It should OFF when you use tw9910.
> 
> I wrote dip-switch info on top of
> ${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
> Please check it too.
> 
> Best regards
> --
> Kuninori Morimoto
>  


Kuninori,

you are well treated and highly honored by all staying in development
with you. For me it is just some glitch on the edges, but very well
noted.

For now, a dip-switch, you must have been abroad somewhere, can't be a
criminal. Or?

http://www.dip-switch.com/?gclid=COjg9Mn86aICFYSdzAodNEcLkQ

Could you eventually agree with that about what a dip-switch is or do I
miss what you mean?

Do you really tell there are still unclear dip-switches in 2010?

If so, please let's know, but then you can't do anything against such in
software, of course.

Cheers,
Hermann

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[Kuninori Morimoto]

Dear hermann

> For now, a dip-switch, you must have been abroad somewhere, can't be a
> criminal. Or?
> 
> http://www.dip-switch.com/?gclid=COjg9Mn86aICFYSdzAodNEcLkQ
> 
> Could you eventually agree with that about what a dip-switch is or do I
> miss what you mean?
> 
> Do you really tell there are still unclear dip-switches in 2010?
> 
> If so, please let's know, but then you can't do anything against such in
> software, of course.

I'm so sorry about my stupid English.
I should not use the words of "criminal".

I should say
"The reason that there are no video output on Ecovec
 might dip-switch setting issue.
 DS2[3] should be OFF when you use video"

Best regards
--
Kuninori Morimoto
 

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[hermann pitton]

Dear Kuninori,

Am Mittwoch, den 14.07.2010, 14:18 +0900 schrieb Kuninori Morimoto:
> Dear hermann
> 
> > For now, a dip-switch, you must have been abroad somewhere, can't be a
> > criminal. Or?
> > 
> > http://www.dip-switch.com/?gclid=COjg9Mn86aICFYSdzAodNEcLkQ
> > 
> > Could you eventually agree with that about what a dip-switch is or do I
> > miss what you mean?
> > 
> > Do you really tell there are still unclear dip-switches in 2010?
> > 
> > If so, please let's know, but then you can't do anything against such in
> > software, of course.
> 
> I'm so sorry about my stupid English.
> I should not use the words of "criminal".
> 
> I should say
> "The reason that there are no video output on Ecovec
>  might dip-switch setting issue.
>  DS2[3] should be OFF when you use video"
> 
> Best regards
> --
> Kuninori Morimoto
>  

thanks for providing more insight.

I really could not believe that we depend on dip-switch settings on
v4l-dvb. Last I saw such, despite of mobos, was in the mid of the
nineties on some ISA network cards.

Assured for now enough, that such stuff exists, we still have a serious
leak of documentation about hundreds of new devices recently rushed in.

I take this dip-switch just as an example.

Is there any documentation and how can a user know about it?

Without any, "criminal" is fine so far :)

Thanks,
Hermann

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[Kuninori Morimoto]

Dear hermann

> Is there any documentation and how can a user know about it?

"Ecovec board" which I and Guennadi were talking about is an evaluation board.
If you buy this board, you can find DVD including manual in its box.
Please check
${DVD}/hardware/user's_manual/eng/rej10j2027-0101_R0P7724LC001121RL_um_1.03.pdf

"dip-switch settings" is wrote in
3.4 "Switch Specification"

If you don't have this board,
but have kernel source code,
you can watch explain comment on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c

Best regards
--
Kuninori Morimoto
 

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[hermann pitton]

Dear Kuninori,

Am Donnerstag, den 15.07.2010, 14:37 +0900 schrieb Kuninori Morimoto:
> Dear hermann
> 
> > Is there any documentation and how can a user know about it?
> 
> "Ecovec board" which I and Guennadi were talking about is an evaluation board.
> If you buy this board, you can find DVD including manual in its box.
> Please check
> ${DVD}/hardware/user's_manual/eng/rej10j2027-0101_R0P7724LC001121RL_um_1.03.pdf

on that stage it is now, you can't call me to crawl the web or buy any
evaluation board, likely high priced, still not even providing a link.

If you use GNU/Linux, free of charge, you have to provide acceptable
documentation too.

> "dip-switch settings" is wrote in
> 3.4 "Switch Specification"
> 
> If you don't have this board,
> but have kernel source code,
> you can watch explain comment on top of
> ${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
> 
> Best regards
> --
> Kuninori Morimoto

This is lame. I do want to know what is out in the markets already and
no fall back on initial dip-switch comments. Comparable sensors ship
from China directly for some 5 Euros and less here.

This is a change (chance?) in culture too, and was already discussed in
1976 by some, but was at least public for all those a little bit more
interested since, let's say, 1982.

This is going on for a long time now, it did not hit the linuxtv.org
wiki at all until today, but introduces most relevant API changes. To
stop to provide support for older devices, in favor of the like of such
stuff, was mentioned several times already to get quicker to the
bonanza.

All major hardware manufacturers, and/or those claiming to be codec
possessors, have hired linux devel teams around the globe to move this
forward.

What it means, that everyone likely can film his life soon with two HD
cameras on mobile devices at once, let's say with 1080p for now, one
following his view to the "outside world", the other one pointing to
"him/her" at the same time, about that, there is no word on this list.

It is not about missing some dip switch settings on an evaluation board.

It is about missing documentation, but much more about missing
reflection, if GNU/Linux should give the vehicle for such.

And it obviously does, even without any further comments.

Cheers,
Hermann















 

[PATCH] Add interlace support to sh_mobile_ceu_camera.c

[Kuninori Morimoto]

Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
---
 drivers/media/video/sh_mobile_ceu_camera.c |   56 +++++++++++++++++++++++-----
 1 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/drivers/media/video/sh_mobile_ceu_camera.c b/drivers/media/video/sh_mobile_ceu_camera.c
index 4dea1ff..ec44df3 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -97,6 +97,7 @@ struct sh_mobile_ceu_dev {
 	spinlock_t lock;
 	struct list_head capture;
 	struct videobuf_buffer *active;
+	int is_interlace;
 
 	struct sh_mobile_ceu_info *pdata;
 
@@ -165,7 +166,8 @@ static void free_buffer(struct videobuf_queue *vq,
 static void sh_mobile_ceu_capture(struct sh_mobile_ceu_dev *pcdev)
 {
 	struct soc_camera_device *icd = pcdev->icd;
-	dma_addr_t phys_addr;
+	dma_addr_t phys_addr_top;
+	dma_addr_t phys_addr_bottom = icd->width;
 
 	/* The hardware is _very_ picky about this sequence. Especially
 	 * the CEU_CETCR_MAGIC value. It seems like we need to acknowledge
@@ -180,16 +182,24 @@ static void sh_mobile_ceu_capture(struct sh_mobile_ceu_dev *pcdev)
 	if (!pcdev->active)
 		return;
 
-	phys_addr = videobuf_to_dma_contig(pcdev->active);
-	ceu_write(pcdev, CDAYR, phys_addr);
+	phys_addr_top = videobuf_to_dma_contig(pcdev->active);
+	ceu_write(pcdev, CDAYR, phys_addr_top);
+	if (pcdev->is_interlace) {
+		phys_addr_bottom += phys_addr_top;
+		ceu_write(pcdev, CDBYR, phys_addr_bottom);
+	}
 
 	switch (icd->current_fmt->fourcc) {
 	case V4L2_PIX_FMT_NV12:
 	case V4L2_PIX_FMT_NV21:
 	case V4L2_PIX_FMT_NV16:
 	case V4L2_PIX_FMT_NV61:
-		phys_addr += icd->width * icd->height;
-		ceu_write(pcdev, CDACR, phys_addr);
+		phys_addr_top += icd->width * icd->height;
+		ceu_write(pcdev, CDACR, phys_addr_top);
+		if (pcdev->is_interlace) {
+			phys_addr_bottom += icd->width * icd->height;
+			ceu_write(pcdev, CDBCR, phys_addr_bottom);
+		}
 	}
 
 	pcdev->active->state = VIDEOBUF_ACTIVE;
@@ -385,7 +395,7 @@ static int sh_mobile_ceu_set_bus_param(struct soc_camera_device *icd,
 {
 	struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
 	struct sh_mobile_ceu_dev *pcdev = ici->priv;
-	int ret, buswidth, width, cfszr_width, cdwdr_width;
+	int ret, buswidth, width, height, cfszr_width, cdwdr_width;
 	unsigned long camera_flags, common_flags, value;
 	int yuv_mode, yuv_lineskip;
 
@@ -452,7 +462,7 @@ static int sh_mobile_ceu_set_bus_param(struct soc_camera_device *icd,
 	ceu_write(pcdev, CAMCR, value);
 
 	ceu_write(pcdev, CAPCR, 0x00300000);
-	ceu_write(pcdev, CAIFR, 0);
+	ceu_write(pcdev, CAIFR, (pcdev->is_interlace) ? 0x101 : 0);
 
 	mdelay(1);
 
@@ -467,10 +477,16 @@ static int sh_mobile_ceu_set_bus_param(struct soc_camera_device *icd,
 		cdwdr_width = buswidth == 16 ? width * 2 : width;
 	}
 
+	height = icd->height;
+	if (pcdev->is_interlace) {
+		height      /= 2;
+		cdwdr_width *= 2;
+	}
+
 	ceu_write(pcdev, CAMOR, 0);
-	ceu_write(pcdev, CAPWR, (icd->height << 16) | width);
+	ceu_write(pcdev, CAPWR, (height << 16) | width);
 	ceu_write(pcdev, CFLCR, 0); /* no scaling */
-	ceu_write(pcdev, CFSZR, (icd->height << 16) | cfszr_width);
+	ceu_write(pcdev, CFSZR, (height << 16) | cfszr_width);
 	ceu_write(pcdev, CLFCR, 0); /* no lowpass filter */
 
 	/* A few words about byte order (observed in Big Endian mode)
@@ -619,8 +635,10 @@ static int sh_mobile_ceu_try_fmt(struct soc_camera_device *icd,
 				 struct v4l2_format *f)
 {
 	struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
+	struct sh_mobile_ceu_dev *pcdev = ici->priv;
 	const struct soc_camera_format_xlate *xlate;
 	__u32 pixfmt = f->fmt.pix.pixelformat;
+	int ret;
 
 	xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
 	if (!xlate) {
@@ -646,7 +664,25 @@ static int sh_mobile_ceu_try_fmt(struct soc_camera_device *icd,
 	f->fmt.pix.sizeimage = f->fmt.pix.height * f->fmt.pix.bytesperline;
 
 	/* limit to sensor capabilities */
-	return icd->ops->try_fmt(icd, f);
+	ret = icd->ops->try_fmt(icd, f);
+	if (ret < 0)
+		return ret;
+
+	switch (f->fmt.pix.field) {
+	case V4L2_FIELD_INTERLACED:
+		pcdev->is_interlace = 1;
+		break;
+	case V4L2_FIELD_ANY:
+		f->fmt.pix.field = V4L2_FIELD_NONE;
+	case V4L2_FIELD_NONE:
+		pcdev->is_interlace = 0;
+		break;
+	default:
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
 }
 
 static int sh_mobile_ceu_reqbufs(struct soc_camera_file *icf,
-- 
1.5.6.3

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c

[morimoto.kuninori]

Sorry.

> Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
> ---
>  drivers/media/video/sh_mobile_ceu_camera.c |   56 +++++++++++++++++++++++-----
>  1 files changed, 46 insertions(+), 10 deletions(-)

Please ignore this mail.
it is my mistake.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list