[2/2] sh_mobile_ceu: Add FLDPOL operation

  Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
---
 drivers/media/video/sh_mobile_ceu_camera.c |    7 +++++++
 include/media/sh_mobile_ceu.h              |    2 ++
 2 files changed, 9 insertions(+), 0 deletions(-)
  

On Fri, 30 Jan 2009, Kuninori Morimoto wrote:

> 
> Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
> ---
>  drivers/media/video/sh_mobile_ceu_camera.c |    7 +++++++
>  include/media/sh_mobile_ceu.h              |    2 ++
>  2 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/sh_mobile_ceu_camera.c b/drivers/media/video/sh_mobile_ceu_camera.c
> index 07b7b4c..366e5f5 100644
> --- a/drivers/media/video/sh_mobile_ceu_camera.c
> +++ b/drivers/media/video/sh_mobile_ceu_camera.c
> @@ -118,6 +118,12 @@ static unsigned long make_bus_param(struct sh_mobile_ceu_dev *pcdev)
>  	if (pcdev->pdata->flags & SH_CEU_FLAG_USE_16BIT_BUS)
>  		flags |= SOCAM_DATAWIDTH_16;
>  
> +	if (pcdev->pdata->flags & SH_CEU_FLAG_USE_FLDPOL_HIGH)
> +		flags |= SOCAM_FLDPOL_ACTIVE_HIGH;
> +
> +	if (pcdev->pdata->flags & SH_CEU_FLAG_USE_FLDPOL_LOW)
> +		flags |= SOCAM_FLDPOL_ACTIVE_LOW;
> +
>  	if (flags & SOCAM_DATAWIDTH_MASK)
>  		return flags;
>  
> @@ -474,6 +480,7 @@ static int sh_mobile_ceu_set_bus_param(struct soc_camera_device *icd,
>  	    icd->current_fmt->fourcc == V4L2_PIX_FMT_NV61)
>  		value ^= 0x00000100; /* swap U, V to change from NV1x->NVx1 */
>  
> +	value |= common_flags & SOCAM_FLDPOL_ACTIVE_LOW ? 1 << 16 : 0;
>  	value |= common_flags & SOCAM_VSYNC_ACTIVE_LOW ? 1 << 1 : 0;
>  	value |= common_flags & SOCAM_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
>  	value |= buswidth == 16 ? 1 << 12 : 0;

Why are you basing your decision to use active low or high level of the 
Field ID signal upon the platform data? Doesn't it depend on the 
configuration of the connected device, and, possibly, an inverter between 
them? So, looks like it should be handled in exactly the same way as all 
other signals - negotiate with the connected device (sensor / decoder / 
...) and apply platform-defined inverters if any?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Dear Guennadi

> > +	value |= common_flags & SOCAM_FLDPOL_ACTIVE_LOW ? 1 << 16 : 0;
> >  	value |= common_flags & SOCAM_VSYNC_ACTIVE_LOW ? 1 << 1 : 0;
> >  	value |= common_flags & SOCAM_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
> >  	value |= buswidth == 16 ? 1 << 12 : 0;
> 
> Why are you basing your decision to use active low or high level of the 
> Field ID signal upon the platform data? Doesn't it depend on the 
> configuration of the connected device, and, possibly, an inverter between 
> them? So, looks like it should be handled in exactly the same way as all 
> other signals - negotiate with the connected device (sensor / decoder / 
> ...) and apply platform-defined inverters if any?

Hmmm.

The soc_camera framework supports automatic negotiation
for some type of option.
But it doesn't include board configuration.

When board doesn't support Field ID signal,
we will have to modify driver though camera and host support it. 

This is the reason.

I think bus width and field ID are depend on board configuration.
# May be camera strobe. but I'm not sure

Best regards
--
Kuninori Morimoto
 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Mon, 2 Feb 2009, morimoto.kuninori@renesas.com wrote:

> > > +	value |= common_flags & SOCAM_FLDPOL_ACTIVE_LOW ? 1 << 16 : 0;
> > >  	value |= common_flags & SOCAM_VSYNC_ACTIVE_LOW ? 1 << 1 : 0;
> > >  	value |= common_flags & SOCAM_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
> > >  	value |= buswidth == 16 ? 1 << 12 : 0;
> > 
> > Why are you basing your decision to use active low or high level of the 
> > Field ID signal upon the platform data? Doesn't it depend on the 
> > configuration of the connected device, and, possibly, an inverter between 
> > them? So, looks like it should be handled in exactly the same way as all 
> > other signals - negotiate with the connected device (sensor / decoder / 
> > ...) and apply platform-defined inverters if any?
> 
> Hmmm.
> 
> The soc_camera framework supports automatic negotiation
> for some type of option.
> But it doesn't include board configuration.
> 
> When board doesn't support Field ID signal,
> we will have to modify driver though camera and host support it. 

Aha, I didn't realise that the Field ID signal was optional. If it is so, 
then yes, you need a platform flag for it, but not for polarity, but for 
availability. And if it is available, connected, and used, then you should 
negotiate its polarity with the camera driver. Makes sense?

> This is the reason.
> 
> I think bus width and field ID are depend on board configuration.
> # May be camera strobe. but I'm not sure

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html