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