What's wrong with the adi kernel driver for ADV7180?

Technical Support
, , , ,
1

Hello,

We’re using a custom hardware based on the Colibri iMX6S Module with an Analogue Camera Adapter using ADV7180.

We came across some problems that we were able to overcome with the support of this community:

This was because our final board only provides USB connectivity and has 3 analog camera inputs.

I checked the ADI kernel driver for adv7180 located in “drivers/media/i2c/adv7180.c”, and it appears to implement the interfaces for the v4l2 subsystem with more completeness than the mxc driver located in “drivers/media/platform/mxc/capture/adv7180.c”, that relies on the v4l2 interfaces defined in the file “v4l2-int-device.h” that has been removed from the kernel (include/media/v4l2-int-device.h) prior to the version 4.0

I’m still getting acquainted with the v4l2 subsystem, but I see that in the mxc case, a v4l2 device is implemented by multiple device drivers, where the main driver mxc_v4l2_capture controls the driver for the adv7180, which provides some ioctl-like interfaces to be called by mxc_v4l2_capture.

I would like to understand what would be the reasons for this, and how much porting work would be required to use the ADI driver. We need a more complete control of the ADV7180.

2

This really has to do with the fact that NXP’s downstream BSP makes use of a quite completely different camera stack. The adi driver you are referring to is from mainline meant to be used e.g. with our upstream toradex_5.4.y branch. Please note that the mainline V4L2 and with it the media-ctrl API are quite a beast and before something like libcamera is available for the i.MX 6 configuration thereof will be quite demanding.

3

Hello marcel.tx,

Let me get this clearer. The mainline V4L2 subsystem with this media-ctrl API is more hardware-demanding and requires more processing power… and the iMX6 module is likely not able to handle this stack. is that correct?

thanks for the informations.

4

No, it has absolutely nothing to do with any such. It’s just that NXP downstream uses some proprietary camera stack while mainline once it added such support went a slightly different path. Performance wise I would not expect either to be any better or worse.