2 ==================================
4 - User space interface refinement
5 - Controls should be used when possible rather than private ioctl
6 - No enums should be used
7 - Use of MC and V4L2 subdev APIs when applicable
8 - Single interface header might suffice
9 - Current interface forces to configure everything at once
10 - Get rid of the dm365_ipipe_hw.[ch] layer
11 - Active external sub-devices defined by link configuration; no strcmp
13 - More generic platform data (i2c adapters)
14 - The driver should have no knowledge of possible external subdevs; see
16 - Some of the hardware control should be refactorede
17 - Check proper serialisation (through mutexes and spinlocks)
18 - Names that are visible in kernel global namespace should have a common
20 - While replacing the older driver in media folder, provide a compatibility
21 layer and compatibility tests that warrants (using the libv4l's LD_PRELOAD
22 approach) there is no regression for the users using the older driver.
23 - make it independent of arch-specific APIs (mach/mux.h).
25 Building of uImage and Applications:
26 ==================================
28 As of now since the interface will undergo few changes all the include
29 files are present in staging itself, to build for dm365 follow below steps,
31 - copy vpfe.h from drivers/staging/media/davinci_vpfe/ to
32 include/media/davinci/ folder for building the uImage.
33 - copy davinci_vpfe_user.h from drivers/staging/media/davinci_vpfe/ to
34 include/uapi/linux/davinci_vpfe.h, and add a entry in Kbuild (required
35 for building application).
36 - copy dm365_ipipeif_user.h from drivers/staging/media/davinci_vpfe/ to
37 include/uapi/linux/dm365_ipipeif.h and a entry in Kbuild (required
38 for building application).