Hans,
>
>My last proposal merged subdev and bridge parameters into one struct, thus
>completely describing the bus setup. I realized that there is a problem
>with
>that if you have to define the bus for sub-devices that are in the middle
>of
>a chain: e.g. a sensor sends its video to a image processing subdev and
>from
>there it goes to the bridge. You have to be able to specify both the source
>and
>sink part of each bus for that image processing subdev.
In the above, what you mean by image processing subdev? In the case of DM6446/DM355/DM365, here is the connection
Image sensor/ video decoder -> ccdc -> ipipe/preview engine/resizer -> SDRAM.
In this scenario, ipipe, preview engine and resizer are image processing hardware which are managed by bridge device. So we have just source sub device and bridge device. Which hardware supports the image processing sub device?
>
>Eagle-eyed observers will note that the bus type field has disappeared from
>this proposal. The problem with that is that I have no clue what it is
>supposed
>to do. Is there more than one bus that can be set up? In that case it is
>not a
>bus type but a bus ID. Or does it determine that type of data that is being
>transported over the bus? In that case it does not belong here, since that
>is
At the bridge device, for configuring CCDC, the hardware needs to know if the bus is having raw bayer data or YCbCr data. Similarly, if the bus is YCbCr, the data bus can carry Y and CbCr muxed over 8 lines or dedicated Y lines and CbCr muxed over other 8 lines. Also Y and CbCr can be swapped. How do we convey this information without bus type? May be another field is required in addition to bus type to convey swapped state.
For raw data processing, for example, MT9T031 sensor output 10 bits and MT9P031 outputs 12 bits. DM365 IPIPE handles 12 bits and DM365 IPIPE 10 bits. So in EVM the 10 bits (upper 10 bits for MT9P031)are connected to data 11-2. so bits 0-1 are pulled low. It is required to specify this information in the bus structure. If offset is suggested for this, it could be used to specify it. So in this case offset is related to LSB? So for the above case it is 2 meaning bit2 starts with real data and bit 0 - 1 are zeros. Please confirm.
>something for a s_fmt type API.
>
>This particular API should just setup the physical bus. Nothing more, IMHO.
>
>Please let me know if I am missing something here.
>
>Guennadi, from our meeting I understood that you also want a way provide
>an offset in case the data is actually only on some pins (e.g. the lower
>or upper X pins are always 0). I don't think it is hard to provide support
>for that in this API by adding an offset field or something like that.
>
>Can you give me a pointer to the actual place where that is needed?
>Possibly
>also with references to datasheets? I'd like to understand this better.
>
>Sakari, this proposal is specific to parallel busses. I understood that
>Nokia
>also has to deal with serial busses. Can you take a look at this proposal
>with
>a serial bus in mind?
>
>This bus config stuff has been in limbo for too long, so I'd like to come
>to a conclusion and implementation in 1-2 weeks.
>
>Regards,
>
> Hans
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
