Re: RFC: soc_camera, rcar_vin, and adv7604

[Guennadi Liakhovetski <g.liakhovetski@gmx.de>]

Hi all,

(disclaimer: I was away for the last two weeks with no proper access to my 
email, so, will be slowly fighting through my mail backlog, I know there 
have been a few mails re: soc-camera + DT etc., please, bear with me)

On Wed, 9 Jul 2014, Ian Molton wrote:

> Hi folks,
> 
> My colleague and I are trying to work out what to do to support the 
> following combination:
> 
> soc_camera + rcar_vin for capture, and the mainline adv7604 driver 
> (which we have modified to successfully drive the adv7612).
> 
> The problem we face is that the 7604 driver uses the new "pads" API, but 
> soc_camera based drivers like rcar_vin do not.

I'm not a huge expert in the pad-level API, but from what I understand 
there are at least two aspects to it:

1. subdevice pad-level API, which is just a newer, than the used by 
soc-camera subdevice API.

2. pad-level ioctl()s, exported to the user space, IIUC, as a part of the 
media controller API.

For (2) - yes, soc-camera core support would need to be added, possibly 
with larger changes. Whereas for (1) it's only the host that has to use 
the pad-level API to access subdevice drivers. Interaction between camera 
host and subdevice drivers in soc-camera is direct, so, no soc-camera core 
modifications would be needed. Maybe we dould add some support, say, to 
help with (fake) file handles just to aid the transition. We might also 
add wrappers for subdev drivers, not implementing the pad-level API to 
avoid having host drivers support both APIs, but those are just 
convenience modifications.

I might well be wrong. Please, correct me if so.

Thanks
Guennadi

> Obviously, there are a few approaches we could take, but we could use 
> some guidance on this.
> 
> One approach would be to bodge some non-pads older API support into the 
> 7604 driver. This would probably be the easiest solution.
> 
> A better approach might be to add pad API support to soc_camera, but it 
> seems to me that the soc_camera API does not abstract away all of the 
> areas that might need to be touched, which would lead to much 
> pad-related churn in all the other soc_camera drivers.
> 
> The codebase is rather large, and we're struggling to see a clear path 
> through this. Whatever we do, we would like to be acceptable upstream, 
> so we'd like to open a discussion.
> 
> Perhaps a soc_camera2 with pads support?
> 
> -- 
> Ian Molton <ian.molton@codethink.co.uk>
>