[Query][soc_camera] How to handle hosts w/color conversion built in?

[Query][soc_camera] How to handle hosts w/color conversion built in?

[Sergio Aguirre]

Hi Guennadi and all,

I've been trying to make my omap4 camera host driver to allow YUYV -> 
NV12 color conversion, and add that to the supported host-client 
formats, but I think I have hit the wall with the host design.

I noticed that the soc_camera seems to be designed to just pass-through 
the client supported formats (i.e. if my sensor supports YUYV and JPEG, 
those will be the supported formats only)

Now, in my host driver, I have a feature to do a color conversion to 
NV12, but I'm still not sure on how to expand the supported formats to, 
say: YUYV, JPEG, and NV12 (which would be available only if the client 
outputs YUYV, of course).

I was trying adding a customized get_formats function, but as 
soc_camera_init_user_formats anyways depends heavly on the sensor's 
enum_mbus_fmt, it's hard to add supported formats that the sensor 
doesn't directly support.

Has this been done before? Any advice?

Regards,
Sergio

Re: [Query][soc_camera] How to handle hosts w/color conversion built in?

[Guennadi Liakhovetski]

On Mon, 7 Mar 2011, Sergio Aguirre wrote:

> Hi Guennadi and all,
> 
> I've been trying to make my omap4 camera host driver to allow YUYV -> NV12
> color conversion, and add that to the supported host-client formats, but I
> think I have hit the wall with the host design.
> 
> I noticed that the soc_camera seems to be designed to just pass-through the
> client supported formats (i.e. if my sensor supports YUYV and JPEG, those will
> be the supported formats only)

No, this is not the case.

> Now, in my host driver, I have a feature to do a color conversion to NV12, but
> I'm still not sure on how to expand the supported formats to, say: YUYV, JPEG,
> and NV12 (which would be available only if the client outputs YUYV, of
> course).
> 
> I was trying adding a customized get_formats function, but as
> soc_camera_init_user_formats anyways depends heavly on the sensor's
> enum_mbus_fmt, it's hard to add supported formats that the sensor doesn't
> directly support.
> 
> Has this been done before? Any advice?

Of course, this is supported. See sh_mobile_ceu.c, mx3_camera, pxa_camera, 
omap1_camera. Just search for the format array defined with "static const 
struct soc_mbus_pixelfmt" and see how it is used. Feel free to ask again, 
if you have more questions.

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

Re: [Query][soc_camera] How to handle hosts w/color conversion built in?

[Sergio Aguirre]

Hi Guennadi,

Thanks for replying.

On 03/07/2011 03:05 PM, Guennadi Liakhovetski wrote:
> On Mon, 7 Mar 2011, Sergio Aguirre wrote:
>
>> Hi Guennadi and all,
>>
>> I've been trying to make my omap4 camera host driver to allow YUYV ->  NV12
>> color conversion, and add that to the supported host-client formats, but I
>> think I have hit the wall with the host design.
>>
>> I noticed that the soc_camera seems to be designed to just pass-through the
>> client supported formats (i.e. if my sensor supports YUYV and JPEG, those will
>> be the supported formats only)
>
> No, this is not the case.

Ok.

>
>> Now, in my host driver, I have a feature to do a color conversion to NV12, but
>> I'm still not sure on how to expand the supported formats to, say: YUYV, JPEG,
>> and NV12 (which would be available only if the client outputs YUYV, of
>> course).
>>
>> I was trying adding a customized get_formats function, but as
>> soc_camera_init_user_formats anyways depends heavly on the sensor's
>> enum_mbus_fmt, it's hard to add supported formats that the sensor doesn't
>> directly support.
>>
>> Has this been done before? Any advice?
>
> Of course, this is supported. See sh_mobile_ceu.c, mx3_camera, pxa_camera,
> omap1_camera. Just search for the format array defined with "static const
> struct soc_mbus_pixelfmt" and see how it is used. Feel free to ask again,
> if you have more questions.

Ahh... OK. I understand now :)

So, you basically first determine the count of sensor formats, by 
looping through enum_mbus_fmt in the sensor, and with every call to 
get_formats with the index range, you can return 2 or more formats.

In my case, when the sensor supports YUYV, I'll return 2 and update the 
xlate array with 2 entries, instead of just one, is that right?

Sorry for the noise, and thanks for the patience :)

I've been focusing more on the actual HW functionality, rather than the 
clean design. But now it's time to clean things up and prepare for 
upstreaming :)

Regards,
Sergio

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

Re: [Query][soc_camera] How to handle hosts w/color conversion built in?

[Guennadi Liakhovetski]

On Mon, 7 Mar 2011, Sergio Aguirre wrote:

> > Of course, this is supported. See sh_mobile_ceu.c, mx3_camera, pxa_camera,
> > omap1_camera. Just search for the format array defined with "static const
> > struct soc_mbus_pixelfmt" and see how it is used. Feel free to ask again,
> > if you have more questions.
> 
> Ahh... OK. I understand now :)
> 
> So, you basically first determine the count of sensor formats, by looping
> through enum_mbus_fmt in the sensor, and with every call to get_formats with
> the index range, you can return 2 or more formats.

Actually 0 or more. Usually you return 1 if you just support the sensor 
format in pass-through mode. If you return more, that usually means, that 
in addition to pass-through you can also convert that sensor format to 
some other format.

> In my case, when the sensor supports YUYV, I'll return 2 and update the xlate
> array with 2 entries, instead of just one, is that right?

Right - because you can pass YUYV 1-to-1 and also convert it to nv12.

Thanks
Guennadi

> Sorry for the noise, and thanks for the patience :)
> 
> I've been focusing more on the actual HW functionality, rather than the clean
> design. But now it's time to clean things up and prepare for upstreaming :)
> 
> Regards,
> Sergio
> 
> > 
> > Thanks
> > Guennadi
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> 

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