Re: [Q] Interleaved formats on the media bus

[Sylwester Nawrocki <snjw23@gmail.com>]

Hi Sakari,

On 02/04/2012 04:43 PM, Sakari Ailus wrote:
>> As I explained above I suspect that the sensor sends each image data type
>> on separate channels (I'm not 100% sure) but the bridge is unable to DMA
>> it into separate memory regions.
>>
>> Currently we have no support in V4L2 for specifying separate image data
>> format per MIPI-CSI2 channel. Maybe the solution is just about that -
>> adding support for virtual channels and a possibility to specify an image
>> format separately per each channel ?
>> Still, there would be nothing telling how the channels are interleaved :-/
> 
> _If_ the sensor sends YUV and compressed JPEG data in separate CSI-2

As I learned MIPI-CSI2 specifies 3 data interleaving methods, at: packet, 
frame and virtual channel level. I'm almost certain I'm dealing now with
packet level interleaving, but VC interleaving might need to be supported  
very soon.

> channels then definitely the correct way to implement this is to take
> this kind of setup into account in the frame format description --- we
> do need that quite badly.

Yeah, I will probably want to focus more on that after completing the
camera control works.

> However, this doesn't really help you with your current problem, and
> perhaps just creating a custom format for your sensor driver is the best
> way to go for the time being. But. When someone attaches this kind of

Yes, this is what I started with. What do you think about creating media 
bus codes directly corresponding the the user defined MIPI-CSI data types ?

> sensor to another CSI-2 receiver that can separate the data from
> different channels, I think we should start working towards for a
> correct solution which this driver also should support.

Sure. We would also include description of bus receiver/transmitter 
capabilities, e.g. telling explicitly which interleaving methods are 
supported.

> With information on the frame format, the CSI-2 hardware could properly
> write the data into two separate buffers. Possibly it should provide two
> video nodes, but I'm not sure about that. A multi-plane buffer is
> another option.

Indeed. I think both solutions are equally correct and there should be no
need to restrict us to one or the other. I would leave decision up to the
driver authors, as one option will be more appropriate in some cases than
the other.

--

Thanks,
Sylwester