1The Atmel ISC driver is not compliant with media controller specification.
2In order to evolve this driver, it has to move to media controller, to
3support enhanced features and future products which embed it.
4The move to media controller involves several changes which are
5not backwards compatible with the current usability of the driver.
6
7The best example is the way the format is propagated from the top video
8driver /dev/videoX down to the sensor.
9
10In a simple configuration sensor ==> isc , the isc just calls subdev s_fmt
11and controls the sensor directly. This is achieved by having a lot of code
12inside the driver that will query the subdev at probe time and make a list
13of formats which are usable.
14Basically the user has nothing to configure, as the isc will handle
15everything at the top level. This is an easy way to capture, but also comes
16with the drawback of lack of flexibility.
17In a more complicated pipeline
18sensor ==> controller 1 ==> controller 2 ==> isc
19this will not be achievable, as controller 1 and controller 2 might be
20media-controller configurable, and will not propagate the formats down to
21the sensor.
22
23After discussions with the media maintainers, the decision is to move
24Atmel ISC to staging as-is, to keep the Kconfig symbols and the users
25to the driver in staging. Thus, all the existing users of the non
26media-controller paradigm will continue to be happy and use the old config
27way.
28
29The new driver was added in the media subsystem with a different
30symbol, with the conversion to media controller done, and new users
31of the driver will be able to use all the new features.
32
33The replacement driver is named VIDEO_MICROCHIP_ISC or
34VIDEO_MICROCHIP_XISC depending on the product flavor.
35