[media] v4l2-mc.h: move tuner PAD definitions to this new header

The customer PC hardware can be shipped with lots of different
configurations, as vendors use to replace some of the chips on
their hardware along the time. All drivers that support such
devices are prepared to handle the hardware differences, using
their own auto-probing logic.

They do it in a way that number of inputs and outputs for a given
hardware type doesn't change.

Now that we're adding media controller capabilities to those drivers,
we need to standardize the number of inputs and outputs for each
hardware type, as we want to have a generic function at the V4L2
core that would create the links for the entities that are expected
on such hardware.

Such standard is already there for tuners, but tuner.h is not the
best place to store such data, as we'll need to add definitions also
for analog TV demodulators.

Also, we'll need a place to put a set of MC handling functions. So,
let's create a v4l2-mc.h to store such kind of definitions.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>

Documentation/DocBook/device-drivers.tmpl

@@ -229,6 +229,7 @@ X!Isound/sound_firmware.c
 !Iinclude/media/v4l2-dv-timings.h
 !Iinclude/media/v4l2-event.h
 !Iinclude/media/v4l2-flash-led-class.h
+!Iinclude/media/v4l2-mc.h
 !Iinclude/media/v4l2-mediabus.h
 !Iinclude/media/v4l2-mem2mem.h
 !Iinclude/media/v4l2-of.h

include/media/tuner.h

@@ -20,29 +20,7 @@
 #ifdef __KERNEL__
 
 #include <linux/videodev2.h>
-
-/**
- * enum tuner_pad_index - tuner pad index
- *
- * @TUNER_PAD_RF_INPUT:	Radiofrequency (RF) sink pad, usually linked to a
- *			RF connector entity.
- * @TUNER_PAD_OUTPUT:	Tuner output pad. This is actually more complex than
- *			a single pad output, as, in addition to luminance and
- *			chrominance IF a tuner may have internally an
- *			audio decoder (like xc3028) or it may produce an audio
- *			IF that will be used by an audio decoder like msp34xx.
- *			It may also have an IF-PLL demodulator on it, like
- *			tuners with tda9887. Yet, currently, we don't need to
- *			represent all the dirty details, as this is transparent
- *			for the V4L2 API usage. So, let's represent all kinds
- *			of different outputs as a single source pad.
- * @TUNER_NUM_PADS:	Number of pads of the tuner.
- */
-enum tuner_pad_index {
-	TUNER_PAD_RF_INPUT,
-	TUNER_PAD_OUTPUT,
-	TUNER_NUM_PADS
-};
+#include <media/v4l2-mc.h>
 
 #define ADDR_UNSET (255)
 

include/media/v4l2-mc.h

@@ -0,0 +1,38 @@
+/*
+ * v4l2-mc.h - Media Controller V4L2 types and prototypes
+ *
+ * Copyright (C) 2016 Mauro Carvalho Chehab <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/**
+ * enum tuner_pad_index - tuner pad index for MEDIA_ENT_F_TUNER
+ *
+ * @TUNER_PAD_RF_INPUT:	Radiofrequency (RF) sink pad, usually linked to a
+ *			RF connector entity.
+ * @TUNER_PAD_OUTPUT:	Tuner output pad. This is actually more complex than
+ *			a single pad output, as, in addition to luminance and
+ *			chrominance IF a tuner may have internally an
+ *			audio decoder (like xc3028) or it may produce an audio
+ *			IF that will be used by an audio decoder like msp34xx.
+ *			It may also have an IF-PLL demodulator on it, like
+ *			tuners with tda9887. Yet, currently, we don't need to
+ *			represent all the dirty details, as this is transparent
+ *			for the V4L2 API usage. So, let's represent all kinds
+ *			of different outputs as a single source pad.
+ * @TUNER_NUM_PADS:	Number of pads of the tuner.
+ */
+enum tuner_pad_index {
+	TUNER_PAD_RF_INPUT,
+	TUNER_PAD_OUTPUT,
+	TUNER_NUM_PADS
+};