[RFC PATCH 4/4] v4l: Add V4L2_CID_ANTISHAKE button control

[HeungJun, Kim]

It adds the new CID for setting Anti-shake. This CID is provided as
button type. This can commands only if the camera turn on/off this function.

Signed-off-by: HeungJun, Kim 
Signed-off-by: Kyungmin Park 
---
 Documentation/DocBook/media/v4l/controls.xml |   11 +++
 drivers/media/video/v4l2-ctrls.c |2 ++
 include/linux/videodev2.h|1 +
 3 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index bed6c66..73ff05c 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2970,6 +2970,17 @@ it one step further. This is a write-only 
control.
  
 
  
+   V4L2_CID_ANTISHAKE
+   button
+ 
+ 
+   Anti-Shake. It makes
+   the image be more stabilized from the image's shakeness.
+   This function can be provided according to the capability
+   of the hardware(sensor or AP's multimedia block).
+ 
+
+ 
V4L2_CID_PRIVACY 
boolean
  Prevent video from being acquired
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 66110bc..05ff6bb 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -599,6 +599,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRESET_WHITE_BALANCE: return "White Balance, Preset";
case V4L2_CID_SCENEMODE:return "Scenemode";
case V4L2_CID_WDR:  return "Wide Dynamic Range";
+   case V4L2_CID_ANTISHAKE:return "Antishake";
 
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -689,6 +690,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_PAN_RESET:
case V4L2_CID_TILT_RESET:
case V4L2_CID_WDR:
+   case V4L2_CID_ANTISHAKE:
case V4L2_CID_FLASH_STROBE:
case V4L2_CID_FLASH_STROBE_STOP:
*type = V4L2_CTRL_TYPE_BUTTON;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f85ad6c..ddd775f 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1647,6 +1647,7 @@ enum v4l2_scenemode {
 };
 
 #define V4L2_CID_WDR   (V4L2_CID_CAMERA_CLASS_BASE+21)
+#define V4L2_CID_ANTISHAKE (V4L2_CID_CAMERA_CLASS_BASE+22)
 
 /* FM Modulator class control IDs */
 #define V4L2_CID_FM_TX_CLASS_BASE  (V4L2_CTRL_CLASS_FM_TX | 0x900)
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 3/4] v4l: Add V4L2_CID_WDR button control

[HeungJun, Kim]

It adds the new CID for setting White Balance Preset. This CID is provided as
button type. This can commands only if the camera turn on/off this function.

Signed-off-by: HeungJun, Kim 
Signed-off-by: Kyungmin Park 
---
 Documentation/DocBook/media/v4l/controls.xml |   12 
 drivers/media/video/v4l2-ctrls.c |2 ++
 include/linux/videodev2.h|2 ++
 3 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index afe1845..bed6c66 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2958,6 +2958,18 @@ it one step further. This is a write-only 
control.
  
 
  
+   V4L2_CID_WDR
+   button
+ 
+ 
+   Wide Dynamic Range. It makes
+   the image be more clear by adjusting the image's intensity
+   of the illumination. This function can be provided according to
+   the capability of the hardware(sensor or AP's multimedia block).
+   
+ 
+
+ 
V4L2_CID_PRIVACY 
boolean
  Prevent video from being acquired
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index fef58c2..66110bc 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -598,6 +598,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
case V4L2_CID_PRESET_WHITE_BALANCE: return "White Balance, Preset";
case V4L2_CID_SCENEMODE:return "Scenemode";
+   case V4L2_CID_WDR:  return "Wide Dynamic Range";
 
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -687,6 +688,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
break;
case V4L2_CID_PAN_RESET:
case V4L2_CID_TILT_RESET:
+   case V4L2_CID_WDR:
case V4L2_CID_FLASH_STROBE:
case V4L2_CID_FLASH_STROBE_STOP:
*type = V4L2_CTRL_TYPE_BUTTON;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index bc14feb..f85ad6c 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1646,6 +1646,8 @@ enum v4l2_scenemode {
V4L2_SCENEMODE_CANDLE = 14,
 };
 
+#define V4L2_CID_WDR   (V4L2_CID_CAMERA_CLASS_BASE+21)
+
 /* FM Modulator class control IDs */
 #define V4L2_CID_FM_TX_CLASS_BASE  (V4L2_CTRL_CLASS_FM_TX | 0x900)
 #define V4L2_CID_FM_TX_CLASS   (V4L2_CTRL_CLASS_FM_TX | 1)
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 2/4] v4l: Add V4L2_CID_SCENEMODE menu control

[HeungJun, Kim]

It adds the new CID for setting Scenemode. This CID is provided as
menu type using the following items:
enum v4l2_scenemode {
V4L2_SCENEMODE_NONE = 0,
V4L2_SCENEMODE_NORMAL = 1,
V4L2_SCENEMODE_PORTRAIT = 2,
V4L2_SCENEMODE_LANDSCAPE = 3,
V4L2_SCENEMODE_SPORTS = 4,
V4L2_SCENEMODE_PARTY_INDOOR = 5,
V4L2_SCENEMODE_BEACH_SNOW = 6,
V4L2_SCENEMODE_SUNSET = 7,
V4L2_SCENEMODE_DAWN_DUSK = 8,
V4L2_SCENEMODE_FALL = 9,
V4L2_SCENEMODE_NIGHT = 10,
V4L2_SCENEMODE_AGAINST_LIGHT = 11,
V4L2_SCENEMODE_FIRE = 12,
V4L2_SCENEMODE_TEXT = 13,
V4L2_SCENEMODE_CANDLE = 14,
};

Signed-off-by: HeungJun, Kim 
Signed-off-by: Kyungmin Park 
---
 Documentation/DocBook/media/v4l/controls.xml |   88 ++
 drivers/media/video/v4l2-ctrls.c |   21 ++
 include/linux/videodev2.h|   19 ++
 3 files changed, 128 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index 350c138..afe1845 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2879,6 +2879,94 @@ it one step further. This is a write-only 
control.
  
  
 
+ 
+   V4L2_CID_SCENEMODE 
+   enum v4l2_scenemode
+ This control sets
+ the camera's scenemode, and it is provided by the type of
+ the enum values. The "None" mode means the status
+ when scenemode algorithm is not activated, like after booting time.
+ On the other hand, the "Normal" mode means the scenemode algorithm
+ is activated on the normal mode.
+ 
+ 
+   
+ 
+   
+ V4L2_SCENEMODE_NONE 
+ Scenemode None.
+   
+   
+ 
V4L2_SCENEMODE_NORMAL 
+ Scenemode Normal.
+   
+   
+ 
V4L2_SCENEMODE_PORTRAIT 
+ Scenemode Portrait.
+   
+   
+ 
V4L2_SCENEMODE_LANDSCAPE 
+ Scenemode Landscape.
+   
+   
+ 
V4L2_SCENEMODE_SPORTS 
+ Scenemode Sports.
+   
+   
+ 
V4L2_SCENEMODE_PARTY_INDOOR 
+ Scenemode Party Indoor.
+   
+   
+ 
V4L2_SCENEMODE_BEACH_SNOW 
+ Scenemode Beach Snow.
+   
+   
+ 
V4L2_SCENEMODE_SUNSET 
+ Scenemode Beach Snow.
+   
+   
+ 
V4L2_SCENEMODE_DAWN_DUSK 
+ Scenemode Dawn Dusk.
+   
+   
+ V4L2_SCENEMODE_FALL 
+ Scenemode Fall.
+   
+   
+ V4L2_SCENEMODE_NIGHT 
+ Scenemode Night.
+   
+   
+ 
V4L2_SCENEMODE_AGAINST_LIGHT 
+ Scenemode Against Light.
+   
+   
+ V4L2_SCENEMODE_FIRE 
+ Scenemode Fire.
+   
+   
+ V4L2_SCENEMODE_TEXT 
+ Scenemode Text.
+   
+   
+ 
V4L2_SCENEMODE_CANDLE 
+ Scenemode Candle.
+   
+ 
+   
+ 
+ 
+
+ 
+   V4L2_CID_PRIVACY 
+   boolean
+ Prevent video from being acquired
+by the camera. When this control is set to TRUE (1), no
+image can be captured by the camera. Common means to enforce privacy are
+mechanical obturation of the sensor and firmware image processing, but the
+device is not restricted to these methods. Devices that implement the privacy
+control must support read access and may support write access.
+ 
  
V4L2_CID_PRIVACY 
boolean
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index f51b576..fef58c2 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -242,6 +242,23 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Shade",
NULL,
};
+   static const char * const scenemode[] = {
+   "None",
+   "Normal",
+   "Landscape",
+   "Sports",
+   "Party Indoor",
+   "Beach Snow",
+   "Sunset",
+   "Dawn Dusk",
+   "Fall",
+   "Night",
+   "Against Light",
+   "Fire",
+   "Text",
+   "Candle",
+   NULL,
+   };
static const char * const tune_preemphasis[] = {
"No Preemphasis",
"50 useconds",
@@

[RFC PATCH 1/4] v4l: Add V4L2_CID_PRESET_WHITE_BALANCE menu control

[HeungJun, Kim]

It adds the new CID for setting White Balance Preset. This CID is provided as
menu type using the following items:
0 - V4L2_WHITE_BALANCE_INCANDESCENT,
1 - V4L2_WHITE_BALANCE_FLUORESCENT,
2 - V4L2_WHITE_BALANCE_DAYLIGHT,
3 - V4L2_WHITE_BALANCE_CLOUDY,
4 - V4L2_WHITE_BALANCE_SHADE,

Signed-off-by: HeungJun, Kim 
Signed-off-by: Kyungmin Park 
---
 Documentation/DocBook/media/v4l/controls.xml |   38 ++
 drivers/media/video/v4l2-ctrls.c |   12 
 include/linux/videodev2.h|9 ++
 3 files changed, 59 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index c0422c6..350c138 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2841,6 +2841,44 @@ it one step further. This is a write-only 
control.
  
  
 
+ 
+   V4L2_CID_PRESET_WHITE_BALANCE 
+   enum v4l2_preset_white_balance
+ This control sets
+ the camera's white balance by the presets. These preset is provided
+ by the type of the enum values which are generally provided
+ by several digital cameras. But, it dosen't mean that the specific
+ preset always can be counterposed with the unique white balance value.
+ This is a read/write control.
+ 
+ 
+   
+ 
+   
+ 
V4L2_WHITE_BALANCE_INCANDESCENT 
+ White Balance Incandescent/Tungster preset.
+   
+   
+ 
V4L2_WHITE_BALANCE_FLUORESCENT 
+ White Balance Fluorescent preset.
+   
+   
+ 
V4L2_WHITE_BALANCE_DAYLIGHT 
+ White Balance Daylight preset.
+   
+   
+ 
V4L2_WHITE_BALANCE_CLOUDY 
+ White Balance Cloudy preset.
+   
+   
+ 
V4L2_WHITE_BALANCE_SHADE 
+ White Balance Share preset.
+   
+ 
+   
+ 
+ 
+
  
V4L2_CID_PRIVACY 
boolean
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 0f415da..f51b576 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -234,6 +234,14 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Vivid",
NULL
};
+   static const char * const preset_white_balance[] = {
+   "Incandescent",
+   "Fluorescent",
+   "Daylight",
+   "Cloudy",
+   "Shade",
+   NULL,
+   };
static const char * const tune_preemphasis[] = {
"No Preemphasis",
"50 useconds",
@@ -390,6 +398,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_exposure_auto;
case V4L2_CID_COLORFX:
return colorfx;
+   case V4L2_CID_PRESET_WHITE_BALANCE:
+   return preset_white_balance;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
case V4L2_CID_FLASH_LED_MODE:
@@ -567,6 +577,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY:  return "Privacy";
case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
+   case V4L2_CID_PRESET_WHITE_BALANCE: return "White Balance, Preset";
 
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -680,6 +691,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
+   case V4L2_CID_PRESET_WHITE_BALANCE:
case V4L2_CID_TUNE_PREEMPHASIS:
case V4L2_CID_FLASH_LED_MODE:
case V4L2_CID_FLASH_STROBE_SOURCE:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3d62631..a842de0 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1618,6 +1618,15 @@ enum  v4l2_exposure_auto_type {
 #define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
 #define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
 
+#define V4L2_CID_PRESET_WHITE_BALANCE  (V4L2_CID_CAMERA_CLASS_BASE+19)
+enum v4l2_preset_white_balance {
+   V4L2_WHITE_BALANCE_INCANDESCENT = 0,
+   V4L2_WHITE_BALANCE_FLUORESCENT = 1,
+   V4L2_WHITE_BALANCE_DAYLIGHT = 2,
+   V4L2_WHITE_BALANCE_CLOUDY = 3,
+   V4L2_WHITE_BALANCE_SHADE = 4,
+};
+
 /* FM Modulator class control IDs */
 #define V4L2_CID_FM_TX_CLASS_BASE  (V4L2_CTRL_CLASS_FM_TX | 0x900)
 #define V4L2_CID_FM_TX_CLASS   

[RFC PATCH 0/4] Add some new camera controls

[HeungJun, Kim]

Hi everyone,

This RFC patch series include new 4 controls ID for digital camera.
I about to suggest these controls by the necessity enabling the M-5MOLS
sensor's function, and I hope to discuss this in here.

Any opinions and thoughts are very welcome!

It's good to connect Sylwester's suggestion for discussing.
- http://www.mail-archive.com/linux-media@vger.kernel.org/msg39907.html

But it's no problem even if it is considered as seperated subject.

1. White Balance Peset
==

Some camera hardware provides its own preset of white balance,
but fortunately the names of these presets are similar with the others.
So, I thought it can be provided as a generic digital camera API.
I suggest the following as items:

enum v4l2_preset_white_balance {
V4L2_WHITE_BALANCE_INCANDESCENT = 0,
V4L2_WHITE_BALANCE_FLUORESCENT = 1,
V4L2_WHITE_BALANCE_DAYLIGHT = 2,
V4L2_WHITE_BALANCE_CLOUDY = 3,
V4L2_WHITE_BALANCE_SHADE = 4,
};

2. Scenemode


I had suggested it before. :
http://www.mail-archive.com/linux-media@vger.kernel.org/msg29917.html

And I want to continue this subject on this threads.

The scenemode is also needed in the mobile digital .
The reason I about to suggest this function as CID,
is also the items are used widely & generally.

enum v4l2_scenemode {
V4L2_SCENEMODE_NONE = 0,
V4L2_SCENEMODE_NORMAL = 1,
V4L2_SCENEMODE_PORTRAIT = 2,
V4L2_SCENEMODE_LANDSCAPE = 3,
V4L2_SCENEMODE_SPORTS = 4,
V4L2_SCENEMODE_PARTY_INDOOR = 5,
V4L2_SCENEMODE_BEACH_SNOW = 6,
V4L2_SCENEMODE_SUNSET = 7,
V4L2_SCENEMODE_DAWN_DUSK = 8,
V4L2_SCENEMODE_FALL = 9,
V4L2_SCENEMODE_NIGHT = 10,
V4L2_SCENEMODE_AGAINST_LIGHT = 11,
V4L2_SCENEMODE_FIRE = 12,
V4L2_SCENEMODE_TEXT = 13,
V4L2_SCENEMODE_CANDLE = 14,
};

3. WDR(Wide Dynamic Range)
==

This function can be unfamiliar, but it is as known as HDR(High Dynamic Range)
to iPhone users. Although the name is different, but both are the same function.

It makes the image look more clear by adjusting the intensity area of
illumination of the image. This function can be used only turn on/off
like button control, then the actual WDR algorithm are activated in the 
hardware.

4. Antishake


This function compensate and stabilize the shakeness of the stream and image.
So, if this function turned on, the image created without many shakeness.
It means both, the case when compensating the stream's shakeness,
and when stabilizing the image itself.

5. References
=

- This is the example of the various digital camera's upper controls.
You can find that the term of each control is very similiar.

@ White Balance Preset
http://imaging.nikon.com/history/basics/17/index.htm
http://www.dailyphotographytips.net/camera-controls-and-settings/how-to-set-custom-white-balance/
http://www.digitalcamera-hq.com/articles/how-to-white-balance-your-camera
http://www.digital-photography-school.com/introduction-to-white-balance

@ Scenemode
http://www.digital-photography-school.com/digital-camera-modes
http://www.picturecorrect.com/tips/digital-camera-scene-modes/

@ WDR and HDR
http://en.wikipedia.org/wiki/High_dynamic_range_imaging
http://en.wikipedia.org/wiki/Wide_dynamic_range

@ Ahtishake
http://www.digital-slr-guide.com/digital-slr-anti-shake.html


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx_isoc_dvb_max_packetsize for EM2884 (Terratec Cinergy HTC Stick)

[Holger Nelson]

On Mon, 26 Dec 2011, Mauro Carvalho Chehab wrote:


I'm currently without time right now to work on a patch, but I think that 
several hacks
inside the em28xx probe should be removed, including the one that detects the 
endpoint
based on the packet size.

As it is easier to code than to explain in words, the code below could be
a start (ok, it doesn't compile, doesn't remove all hacks, doesn't free memory, 
etc...)
Feel free to use it as a start for a real patch, if you wish.


I think, I filled the missing parts and removed most of the hacks in the 
probe code. The code works with my Cinergy HTC USB XS.


Holger

diff --git a/drivers/media/video/em28xx/em28xx-audio.c 
b/drivers/media/video/em28xx/em28xx-audio.c
index cff0768..e2a7b77 100644
--- a/drivers/media/video/em28xx/em28xx-audio.c
+++ b/drivers/media/video/em28xx/em28xx-audio.c
@@ -193,7 +193,7 @@ static int em28xx_init_audio_isoc(struct em28xx *dev)

urb->dev = dev->udev;
urb->context = dev;
-   urb->pipe = usb_rcvisocpipe(dev->udev, 0x83);
+   urb->pipe = usb_rcvisocpipe(dev->udev, EM28XX_EP_AUDIO);
urb->transfer_flags = URB_ISO_ASAP;
urb->transfer_buffer = dev->adev.transfer_buffer[i];
urb->interval = 1;
diff --git a/drivers/media/video/em28xx/em28xx-cards.c 
b/drivers/media/video/em28xx/em28xx-cards.c
index a7cfded..8082914 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -3087,12 +3087,11 @@ unregister_dev:
 static int em28xx_usb_probe(struct usb_interface *interface,
const struct usb_device_id *id)
 {
-   const struct usb_endpoint_descriptor *endpoint;
struct usb_device *udev;
struct em28xx *dev = NULL;
int retval;
-   bool is_audio_only = false, has_audio = false;
-   int i, nr, isoc_pipe;
+   bool has_audio = false, has_video = false, has_dvb = false;
+   int i, nr, sizedescr, size;
const int ifnum = interface->altsetting[0].desc.bInterfaceNumber;
char *speed;
char descr[255] = "";
@@ -3124,56 +3123,69 @@ static int em28xx_usb_probe(struct usb_interface 
*interface,
goto err;
}

-   /* Get endpoints */
-   for (i = 0; i < interface->num_altsetting; i++) {
-   int ep;
+   /* allocate memory for our device state and initialize it */
+   dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+   if (dev == NULL) {
+   em28xx_err(DRIVER_NAME ": out of memory!\n");
+   retval = -ENOMEM;
+   goto err;
+   }

-   for (ep = 0; ep < interface->altsetting[i].desc.bNumEndpoints; 
ep++) {
-   struct usb_host_endpoint*e;
-   e = &interface->altsetting[i].endpoint[ep];
+   /* compute alternate max packet sizes */
+   dev->alt_video_max_pkt_size = 
kmalloc(sizeof(dev->alt_video_max_pkt_size[0]) * interface->num_altsetting, 
GFP_KERNEL);
+   if (dev->alt_video_max_pkt_size == NULL) {
+   em28xx_errdev("out of memory!\n");
+   kfree(dev);
+   retval = -ENOMEM;
+   goto err;
+   }

-   if (e->desc.bEndpointAddress == 0x83)
-   has_audio = true;
-   }
+   dev->alt_dvb_max_pkt_size = kmalloc(sizeof(dev->alt_dvb_max_pkt_size[0]) * 
interface->num_altsetting, GFP_KERNEL);
+   if (dev->alt_dvb_max_pkt_size == NULL) {
+   em28xx_errdev("out of memory!\n");
+   kfree(dev->alt_video_max_pkt_size);
+   kfree(dev);
+   retval = -ENOMEM;
+   goto err;
}

-   endpoint = &interface->cur_altsetting->endpoint[0].desc;
+   /* Get endpoints */
+   for (i = 0; i < interface->num_altsetting; i++) {
+   int ep;

-   /* check if the device has the iso in endpoint at the correct place */
-   if (usb_endpoint_xfer_isoc(endpoint)
-   &&
-   (interface->altsetting[1].endpoint[0].desc.wMaxPacketSize == 940)) {
-   /* It's a newer em2874/em2875 device */
-   isoc_pipe = 0;
-   } else {
-   int check_interface = 1;
-   isoc_pipe = 1;
-   endpoint = &interface->cur_altsetting->endpoint[1].desc;
-   if (!usb_endpoint_xfer_isoc(endpoint))
-   check_interface = 0;
-
-   if (usb_endpoint_dir_out(endpoint))
-   check_interface = 0;
-
-   if (!check_interface) {
-   if (has_audio) {
-   is_audio_only = true;
-   } else {
-   em28xx_err(DRIVER_NAME " video device (%04x:%04x): 
"
-   "interface %i, class %i found.\n",
-   le16_to_cpu(udev->descriptor.idVend

Re: [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism

[InKi Dae]

2011/12/26 Sumit Semwal :
> This is the first step in defining a dma buffer sharing mechanism.
>
> A new buffer object dma_buf is added, with operations and API to allow easy
> sharing of this buffer object across devices.
>
> The framework allows:
> - creation of a buffer object, its association with a file pointer, and
>   associated allocator-defined operations on that buffer. This operation is
>   called the 'export' operation.
> - different devices to 'attach' themselves to this exported buffer object, to
>  facilitate backing storage negotiation, using dma_buf_attach() API.
> - the exported buffer object to be shared with the other entity by asking for
>   its 'file-descriptor (fd)', and sharing the fd across.
> - a received fd to get the buffer object back, where it can be accessed using
>   the associated exporter-defined operations.
> - the exporter and user to share the scatterlist associated with this buffer
>   object using map_dma_buf and unmap_dma_buf operations.
>
> Atleast one 'attach()' call is required to be made prior to calling the
> map_dma_buf() operation.
>
> Couple of building blocks in map_dma_buf() are added to ease introduction
> of sync'ing across exporter and users, and late allocation by the exporter.
>
> For this first version, this framework will work with certain conditions:
> - *ONLY* exporter will be allowed to mmap to userspace (outside of this
>   framework - mmap is not a buffer object operation),
> - currently, *ONLY* users that do not need CPU access to the buffer are
>   allowed.
>
> More details are there in the documentation patch.
>
> This is based on design suggestions from many people at the mini-summits[1],
> most notably from Arnd Bergmann , Rob Clark  and
> Daniel Vetter .
>
> The implementation is inspired from proof-of-concept patch-set from
> Tomasz Stanislawski , who demonstrated buffer 
> sharing
> between two v4l2 devices. [2]
>
> [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
> [2]: http://lwn.net/Articles/454389
>
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 
> Reviewed-by: Daniel Vetter 
> Reviewed-by: Dave Airlie 
> Reviewed-and-Tested-by: Rob Clark 
> ---
>  drivers/base/Kconfig    |   10 ++
>  drivers/base/Makefile   |    1 +
>  drivers/base/dma-buf.c  |  291 
> +++
>  include/linux/dma-buf.h |  176 
>  4 files changed, 478 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/base/dma-buf.c
>  create mode 100644 include/linux/dma-buf.h
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 21cf46f..8a0e87f 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -174,4 +174,14 @@ config SYS_HYPERVISOR
>
>  source "drivers/base/regmap/Kconfig"
>
> +config DMA_SHARED_BUFFER
> +       bool "Buffer framework to be shared between drivers"
> +       default n
> +       select ANON_INODES
> +       help
> +         This option enables the framework for buffer-sharing between
> +         multiple drivers. A buffer is associated with a file using driver
> +         APIs extension; the file's descriptor can then be passed on to other
> +         driver.
> +
>  endmenu
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index 99a375a..d0df046 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DEVTMPFS)  += devtmpfs.o
>  obj-y                  += power/
>  obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
>  obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
> +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o
>  obj-$(CONFIG_ISA)      += isa.o
>  obj-$(CONFIG_FW_LOADER)        += firmware_class.o
>  obj-$(CONFIG_NUMA)     += node.o
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> new file mode 100644
> index 000..e38ad24
> --- /dev/null
> +++ b/drivers/base/dma-buf.c
> @@ -0,0 +1,291 @@
> +/*
> + * Framework for buffer objects that can be shared across devices/subsystems.
> + *
> + * Copyright(C) 2011 Linaro Limited. All rights reserved.
> + * Author: Sumit Semwal 
> + *
> + * Many thanks to linaro-mm-sig list, and specially
> + * Arnd Bergmann , Rob Clark  and
> + * Daniel Vetter  for their support in creation and
> + * refining of this idea.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static inline in

Re: [PATCH RFC 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

[Mauro Carvalho Chehab]

On 27-12-2011 18:47, Andreas Oberritter wrote:
> On 27.12.2011 18:26, Mauro Carvalho Chehab wrote:
>> One usage of such call would be to retrieve the autodetected properties,
>> after having a frontend lock.
> 
> Btw., dvb_frontend already refreshes the cache whenever the lock status
> changes, i.e. when generating frontend events.

Btw, the event ioctl is DVBv3 only. It probably makes sense to add one DTV
command to implement it.

In a matter of fact, IMO, the better is to implement a set of DTV read status
commands, plus one command for event.

This way, a status call could return the events that are specific for each
delivery system, instead of returning something that will require the userspace
to do a FE_GET_PROPERTY call, in order to get the real parameters for the
newer delivery systems.

The current status API has some limits for some new delivery systems.
For example, on ISDB-T, devices can produce both consolidated and
per-layer status.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

[Mauro Carvalho Chehab]

On 27-12-2011 18:47, Andreas Oberritter wrote:
> On 27.12.2011 18:26, Mauro Carvalho Chehab wrote:
>> One usage of such call would be to retrieve the autodetected properties,
>> after having a frontend lock.
> 
> Btw., dvb_frontend already refreshes the cache whenever the lock status
> changes, i.e. when generating frontend events.

True. Well, if all agree, we can add a patch after this series removing
the extra parameter from get_frontend(), making it symmetric to the set
calls.

(I prefer to code it as a separate patch, as changing the entire chain of
about 80 patches is very painful. Also, a simple perl script is probably
enough to do the trick of changing all at once).

> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

[Mauro Carvalho Chehab]

On 27-12-2011 18:44, Andreas Oberritter wrote:
> On 27.12.2011 18:26, Mauro Carvalho Chehab wrote:
>> On 27-12-2011 12:47, Andreas Oberritter wrote:
>>> On 27.12.2011 14:49, Mauro Carvalho Chehab wrote:
 On 27-12-2011 10:21, Andreas Oberritter wrote:
> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
>> The old method is renamed to get_frontend_legacy(), while not all
>> frontends are converted.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>> ---
>>  drivers/media/dvb/bt8xx/dst.c   |8 +-
>>  drivers/media/dvb/dvb-core/dvb_frontend.c   |  102 
>> --
>>  drivers/media/dvb/dvb-core/dvb_frontend.h   |5 +-
>>  drivers/media/dvb/dvb-usb/af9005-fe.c   |4 +-
>>  drivers/media/dvb/dvb-usb/cinergyT2-fe.c|2 +-
>>  drivers/media/dvb/dvb-usb/dtt200u-fe.c  |2 +-
>>  drivers/media/dvb/dvb-usb/friio-fe.c|2 +-
>>  drivers/media/dvb/dvb-usb/mxl111sf-demod.c  |2 +-
>>  drivers/media/dvb/dvb-usb/vp702x-fe.c   |2 +-
>>  drivers/media/dvb/dvb-usb/vp7045-fe.c   |2 +-
>>  drivers/media/dvb/firewire/firedtv-fe.c |2 +-
>>  drivers/media/dvb/frontends/af9013.c|2 +-
>>  drivers/media/dvb/frontends/atbm8830.c  |2 +-
>>  drivers/media/dvb/frontends/au8522_dig.c|2 +-
>>  drivers/media/dvb/frontends/cx22700.c   |2 +-
>>  drivers/media/dvb/frontends/cx22702.c   |2 +-
>>  drivers/media/dvb/frontends/cx24110.c   |2 +-
>>  drivers/media/dvb/frontends/cx24123.c   |2 +-
>>  drivers/media/dvb/frontends/cxd2820r_core.c |4 +-
>>  drivers/media/dvb/frontends/dib3000mb.c |2 +-
>>  drivers/media/dvb/frontends/dib3000mc.c |2 +-
>>  drivers/media/dvb/frontends/dib7000m.c  |2 +-
>>  drivers/media/dvb/frontends/dib7000p.c  |2 +-
>>  drivers/media/dvb/frontends/dib8000.c   |4 +-
>>  drivers/media/dvb/frontends/dib9000.c   |4 +-
>>  drivers/media/dvb/frontends/drxd_hard.c |2 +-
>>  drivers/media/dvb/frontends/drxk_hard.c |4 +-
>>  drivers/media/dvb/frontends/dvb_dummy_fe.c  |6 +-
>>  drivers/media/dvb/frontends/it913x-fe.c |2 +-
>>  drivers/media/dvb/frontends/l64781.c|2 +-
>>  drivers/media/dvb/frontends/lgdt3305.c  |4 +-
>>  drivers/media/dvb/frontends/lgdt330x.c  |4 +-
>>  drivers/media/dvb/frontends/lgs8gl5.c   |2 +-
>>  drivers/media/dvb/frontends/lgs8gxx.c   |2 +-
>>  drivers/media/dvb/frontends/mb86a20s.c  |2 +-
>>  drivers/media/dvb/frontends/mt312.c |2 +-
>>  drivers/media/dvb/frontends/mt352.c |2 +-
>>  drivers/media/dvb/frontends/or51132.c   |2 +-
>>  drivers/media/dvb/frontends/s5h1409.c   |2 +-
>>  drivers/media/dvb/frontends/s5h1411.c   |2 +-
>>  drivers/media/dvb/frontends/s5h1420.c   |2 +-
>>  drivers/media/dvb/frontends/s5h1432.c   |2 +-
>>  drivers/media/dvb/frontends/s921.c  |2 +-
>>  drivers/media/dvb/frontends/stb0899_drv.c   |2 +-
>>  drivers/media/dvb/frontends/stb6100.c   |4 +-
>>  drivers/media/dvb/frontends/stv0297.c   |2 +-
>>  drivers/media/dvb/frontends/stv0299.c   |2 +-
>>  drivers/media/dvb/frontends/stv0367.c   |4 +-
>>  drivers/media/dvb/frontends/stv0900_core.c  |2 +-
>>  drivers/media/dvb/frontends/tda10021.c  |2 +-
>>  drivers/media/dvb/frontends/tda10023.c  |2 +-
>>  drivers/media/dvb/frontends/tda10048.c  |2 +-
>>  drivers/media/dvb/frontends/tda1004x.c  |4 +-
>>  drivers/media/dvb/frontends/tda10071.c  |2 +-
>>  drivers/media/dvb/frontends/tda10086.c  |2 +-
>>  drivers/media/dvb/frontends/tda8083.c   |2 +-
>>  drivers/media/dvb/frontends/ves1820.c   |2 +-
>>  drivers/media/dvb/frontends/ves1x93.c   |2 +-
>>  drivers/media/dvb/frontends/zl10353.c   |2 +-
>>  drivers/media/dvb/siano/smsdvb.c|2 +-
>>  drivers/media/video/tlg2300/pd-dvb.c|2 +-
>>  drivers/staging/media/as102/as102_fe.c  |2 +-
>>  62 files changed, 157 insertions(+), 100 deletions(-)
>>
>> diff --git a/drivers/media/dvb/bt8xx/dst.c 
>> b/drivers/media/dvb/bt8xx/dst.c
>> index 4658bd6..6afc083 100644
>> --- a/drivers/media/dvb/bt8xx/dst.c
>> +++ b/drivers/media/dvb/bt8xx/dst.c
>> @@ -1778,7 +1778,7 @@ static struct dvb_frontend_ops dst_dvbt_ops = {
>>  .init = dst_init,
>>  .tune = dst_tune_frontend,
>>  .set_frontend_legacy = dst_set_frontend,
>> -.get_frontend = dst_get_frontend,
>> +.get_frontend_legacy = dst_get_frontend,
>>  .get_frontend_algo = dst_get

Re: [PATCH RFC 01/91] [media] dvb-core: allow demods to specify the supported delivery systems supported standards.

[Mauro Carvalho Chehab]

On 27-12-2011 18:37, Andreas Oberritter wrote:
> On 27.12.2011 18:06, Mauro Carvalho Chehab wrote:
>> On 27-12-2011 12:33, Andreas Oberritter wrote:
>>> On 27.12.2011 14:28, Mauro Carvalho Chehab wrote:
 On 27-12-2011 10:11, Andreas Oberritter wrote:
> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
>> DVB-S and DVB-T, as those were the standards supported by DVBv3.
>
> The description seems to be incomplete.
>
>> New standards like DSS, ISDB and CTTB don't fit on any of the
>> above types.
>>
>> while there's a way for the drivers to explicitly change whatever
>> default DELSYS were filled inside the core, still a fake value is
>> needed there, and a "compat" code to allow DVBv3 applications to
>> work with those delivery systems is needed. This is good for a
>> short term solution, while applications aren't using DVBv5 directly.
>>
>> However, at long term, this is bad, as the compat code runs even
>> if the application is using DVBv5. Also, the compat code is not
>> perfect, and only works when the frontend is capable of auto-detecting
>> the parameters that aren't visible by the faked delivery systems.
>>
>> So, let the frontend fill the supported delivery systems at the
>> device properties directly, and, in the future, let the core to use
>> the delsys to fill the reported info::type based on the delsys.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>> ---
>>  drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
>>  drivers/media/dvb/dvb-core/dvb_frontend.h |8 
>>  2 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
>> b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> index 8dedff4..f17c411 100644
>> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
>> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> @@ -1252,6 +1252,19 @@ static void dtv_set_default_delivery_caps(const 
>> struct dvb_frontend *fe, struct
>>  const struct dvb_frontend_info *info = &fe->ops.info;
>>  u32 ncaps = 0;
>>  
>> +/*
>> + * If the frontend explicitly sets a list, use it, instead of
>> + * filling based on the info->type
>> + */
>> +if (fe->ops.delsys[ncaps]) {
>> +while (fe->ops.delsys[ncaps] && ncaps < MAX_DELSYS) {
>> +p->u.buffer.data[ncaps] = fe->ops.delsys[ncaps];
>> +ncaps++;
>> +}
>> +p->u.buffer.len = ncaps;
>> +return;
>> +}
>> +
>
> I don't understand what this is trying to solve. This is already handled
> by the get_property driver callback.
>
> dtv_set_default_delivery_caps() only sets some defaults for drivers not
> implementing get_property yet.

 dtv_set_default_delivery_caps() does the wrong thing for delivery systems
 like ISDB-T, ISDB-S, DSS, DMB-TH, as it fills data with a fake value that
 is there at fe->ops.info.type. 

 The fake values there should be used only for DVBv3 legacy calls emulation
 on those delivery systems that are not fully compatible with a DVBv3 call.
>>>
>>> That's right. Still, there's no need to introduce fe->ops.delsys,
>>> because the drivers in question could just implement get_property
>>> instead. At least that's what we discussed and AFAIR agreed upon when
>>> Manu recently submitted his patches regarding enumeration of delivery
>>> systems.
>>
>> Manu's patches were applied (well, except for two patches related to af9013
>> driver that are/were under discussion between Manu and Antti).
>>
>> Manu's approach is good, as it provided a way to enumerate the 
>> standards without much changes, offering a way for userspace to
>> query the delivery system, at the expense of serializing a driver 
>> call for each property. 
>>
>> Yet, it doesn't allow the DVB core to detect the supported
>> delivery systems on a sane way [1].
>>
>> The addition of fe->ops.delsys is going one step further, as it will
>> allow, at the long term, the removal of info.type.
> 
> You can't remove info.type, as it would break userspace. What you can do
> is deprecate its use inside drivers.

Yes, that's what I'm meaning: remove it from the drivers, and let 
dvb_frontend fill it for DVBv3 calls, according with the delivery
system.

>> There are two reasons why we need to get rid of info.type:
>>
>> 1) dvb_frontend core can be changed to use fe->ops.delsys
>>internally, instead of info.type, in order to fix some
>>bugs inside it, where it does the wrong assumption, because
>>the frontend is lying about the delivery system;
>>
>> 2) There is no sane way to fill fe->ops.info.type for Multi delivery
>>system frontends, like DRX-K, that supports both DVB-T and DVB-C.
>>The type can be 

Re: [RFC PATCH v1 5/7] media: v4l2: introduce two IOCTLs for face detection

[Sylwester Nawrocki]

Hi Ming,

On 12/26/2011 03:00 AM, Ming Lei wrote:
> On Thu, Dec 22, 2011 at 3:32 AM, Sylwester Nawrocki  wrote:
 How is face detection enabled or disabled?
>>>
>>> Currently, streaming on will trigger detection enabling, and streaming
>>> off will trigger detection disabling.
>>
>> We would need to develop a boolean control for this I think, this seems 
>> one of the basic features for the configuration interface.
> 
> Yes, it is another way to do it, but considered that for the current two
> use cases(detect objects on user space image or video, detect objects on
> video stream from internal SoC bus), it is implicit that the video device
> should have stream capability, so I think it is still OK to do it via
> streaming on and streaming off interface.

IMHO for drivers that support FD and don't expose an FD start control
applications could assume that VIDIOC_STREAMON/VIDIOC_STREAMOFF also
enables/disables face detection.
In other words if an FD enable control is present face detection would
be disabled until an FD start control is set.

We will also need a FD status control.

>>> Could you let me know how to do it?
>>
>> You would have to use multi-planar interface for that, which would 
>> introduce additional complexity at user interface. Moreover variable plane
>> count is not supported in vb2. Relatively significant effort is required 
>> to add this IMHO.
> 
> So the the introduced two IOCTLs are good to do it, right?

Yes, and no :-)

Since we have a third case to consider:
 1) camera sensor with an embedded ISP that supports face detection.

Another two are:
 2) image input from memory only (like OMAP4 FDIF),
 3) image input from memory OR from external image sensor.

In case 1) we will eventually have a DMA that captures frames to memory.
It's different from 2) and 3) that registers containing result are accessed
through I2C. Then it may be desirable to retrieve detection result data
separately for each object, due to bus access latencies, rather reading all
data in single ioctl.

> Sylwester, could you help to review the v2 patches if you are available?

Yes, I'll try to find some time for it tomorrow.

I would have a general note - I don't really think we should bother with
generic FD kernel module now. We have already generic building blocks in V4L
and hardware is so different that it's seems inappropriate to try to generalize
the implementation before we have clear user interface semantics settled.

-- 
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

[Andreas Oberritter]

On 27.12.2011 18:26, Mauro Carvalho Chehab wrote:
> One usage of such call would be to retrieve the autodetected properties,
> after having a frontend lock.

Btw., dvb_frontend already refreshes the cache whenever the lock status
changes, i.e. when generating frontend events.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

[Andreas Oberritter]

On 27.12.2011 18:26, Mauro Carvalho Chehab wrote:
> On 27-12-2011 12:47, Andreas Oberritter wrote:
>> On 27.12.2011 14:49, Mauro Carvalho Chehab wrote:
>>> On 27-12-2011 10:21, Andreas Oberritter wrote:
 On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
> The old method is renamed to get_frontend_legacy(), while not all
> frontends are converted.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/dvb/bt8xx/dst.c   |8 +-
>  drivers/media/dvb/dvb-core/dvb_frontend.c   |  102 
> --
>  drivers/media/dvb/dvb-core/dvb_frontend.h   |5 +-
>  drivers/media/dvb/dvb-usb/af9005-fe.c   |4 +-
>  drivers/media/dvb/dvb-usb/cinergyT2-fe.c|2 +-
>  drivers/media/dvb/dvb-usb/dtt200u-fe.c  |2 +-
>  drivers/media/dvb/dvb-usb/friio-fe.c|2 +-
>  drivers/media/dvb/dvb-usb/mxl111sf-demod.c  |2 +-
>  drivers/media/dvb/dvb-usb/vp702x-fe.c   |2 +-
>  drivers/media/dvb/dvb-usb/vp7045-fe.c   |2 +-
>  drivers/media/dvb/firewire/firedtv-fe.c |2 +-
>  drivers/media/dvb/frontends/af9013.c|2 +-
>  drivers/media/dvb/frontends/atbm8830.c  |2 +-
>  drivers/media/dvb/frontends/au8522_dig.c|2 +-
>  drivers/media/dvb/frontends/cx22700.c   |2 +-
>  drivers/media/dvb/frontends/cx22702.c   |2 +-
>  drivers/media/dvb/frontends/cx24110.c   |2 +-
>  drivers/media/dvb/frontends/cx24123.c   |2 +-
>  drivers/media/dvb/frontends/cxd2820r_core.c |4 +-
>  drivers/media/dvb/frontends/dib3000mb.c |2 +-
>  drivers/media/dvb/frontends/dib3000mc.c |2 +-
>  drivers/media/dvb/frontends/dib7000m.c  |2 +-
>  drivers/media/dvb/frontends/dib7000p.c  |2 +-
>  drivers/media/dvb/frontends/dib8000.c   |4 +-
>  drivers/media/dvb/frontends/dib9000.c   |4 +-
>  drivers/media/dvb/frontends/drxd_hard.c |2 +-
>  drivers/media/dvb/frontends/drxk_hard.c |4 +-
>  drivers/media/dvb/frontends/dvb_dummy_fe.c  |6 +-
>  drivers/media/dvb/frontends/it913x-fe.c |2 +-
>  drivers/media/dvb/frontends/l64781.c|2 +-
>  drivers/media/dvb/frontends/lgdt3305.c  |4 +-
>  drivers/media/dvb/frontends/lgdt330x.c  |4 +-
>  drivers/media/dvb/frontends/lgs8gl5.c   |2 +-
>  drivers/media/dvb/frontends/lgs8gxx.c   |2 +-
>  drivers/media/dvb/frontends/mb86a20s.c  |2 +-
>  drivers/media/dvb/frontends/mt312.c |2 +-
>  drivers/media/dvb/frontends/mt352.c |2 +-
>  drivers/media/dvb/frontends/or51132.c   |2 +-
>  drivers/media/dvb/frontends/s5h1409.c   |2 +-
>  drivers/media/dvb/frontends/s5h1411.c   |2 +-
>  drivers/media/dvb/frontends/s5h1420.c   |2 +-
>  drivers/media/dvb/frontends/s5h1432.c   |2 +-
>  drivers/media/dvb/frontends/s921.c  |2 +-
>  drivers/media/dvb/frontends/stb0899_drv.c   |2 +-
>  drivers/media/dvb/frontends/stb6100.c   |4 +-
>  drivers/media/dvb/frontends/stv0297.c   |2 +-
>  drivers/media/dvb/frontends/stv0299.c   |2 +-
>  drivers/media/dvb/frontends/stv0367.c   |4 +-
>  drivers/media/dvb/frontends/stv0900_core.c  |2 +-
>  drivers/media/dvb/frontends/tda10021.c  |2 +-
>  drivers/media/dvb/frontends/tda10023.c  |2 +-
>  drivers/media/dvb/frontends/tda10048.c  |2 +-
>  drivers/media/dvb/frontends/tda1004x.c  |4 +-
>  drivers/media/dvb/frontends/tda10071.c  |2 +-
>  drivers/media/dvb/frontends/tda10086.c  |2 +-
>  drivers/media/dvb/frontends/tda8083.c   |2 +-
>  drivers/media/dvb/frontends/ves1820.c   |2 +-
>  drivers/media/dvb/frontends/ves1x93.c   |2 +-
>  drivers/media/dvb/frontends/zl10353.c   |2 +-
>  drivers/media/dvb/siano/smsdvb.c|2 +-
>  drivers/media/video/tlg2300/pd-dvb.c|2 +-
>  drivers/staging/media/as102/as102_fe.c  |2 +-
>  62 files changed, 157 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/media/dvb/bt8xx/dst.c b/drivers/media/dvb/bt8xx/dst.c
> index 4658bd6..6afc083 100644
> --- a/drivers/media/dvb/bt8xx/dst.c
> +++ b/drivers/media/dvb/bt8xx/dst.c
> @@ -1778,7 +1778,7 @@ static struct dvb_frontend_ops dst_dvbt_ops = {
>   .init = dst_init,
>   .tune = dst_tune_frontend,
>   .set_frontend_legacy = dst_set_frontend,
> - .get_frontend = dst_get_frontend,
> + .get_frontend_legacy = dst_get_frontend,
>   .get_frontend_algo = dst_get_tuning_algo,
>   .read_status = dst_read_status,
>   .read_signal_strength = dst_read_signal_strength,
> @@ -1804,7 +1804,7 @@ static struct dvb_frontend_ops dst_dvbs_ops 

Re: [PATCH RFC 01/91] [media] dvb-core: allow demods to specify the supported delivery systems supported standards.

[Andreas Oberritter]

On 27.12.2011 18:06, Mauro Carvalho Chehab wrote:
> On 27-12-2011 12:33, Andreas Oberritter wrote:
>> On 27.12.2011 14:28, Mauro Carvalho Chehab wrote:
>>> On 27-12-2011 10:11, Andreas Oberritter wrote:
 On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
> DVB-S and DVB-T, as those were the standards supported by DVBv3.

 The description seems to be incomplete.

> New standards like DSS, ISDB and CTTB don't fit on any of the
> above types.
>
> while there's a way for the drivers to explicitly change whatever
> default DELSYS were filled inside the core, still a fake value is
> needed there, and a "compat" code to allow DVBv3 applications to
> work with those delivery systems is needed. This is good for a
> short term solution, while applications aren't using DVBv5 directly.
>
> However, at long term, this is bad, as the compat code runs even
> if the application is using DVBv5. Also, the compat code is not
> perfect, and only works when the frontend is capable of auto-detecting
> the parameters that aren't visible by the faked delivery systems.
>
> So, let the frontend fill the supported delivery systems at the
> device properties directly, and, in the future, let the core to use
> the delsys to fill the reported info::type based on the delsys.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
>  drivers/media/dvb/dvb-core/dvb_frontend.h |8 
>  2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb/dvb-core/dvb_frontend.c
> index 8dedff4..f17c411 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
> @@ -1252,6 +1252,19 @@ static void dtv_set_default_delivery_caps(const 
> struct dvb_frontend *fe, struct
>   const struct dvb_frontend_info *info = &fe->ops.info;
>   u32 ncaps = 0;
>  
> + /*
> +  * If the frontend explicitly sets a list, use it, instead of
> +  * filling based on the info->type
> +  */
> + if (fe->ops.delsys[ncaps]) {
> + while (fe->ops.delsys[ncaps] && ncaps < MAX_DELSYS) {
> + p->u.buffer.data[ncaps] = fe->ops.delsys[ncaps];
> + ncaps++;
> + }
> + p->u.buffer.len = ncaps;
> + return;
> + }
> +

 I don't understand what this is trying to solve. This is already handled
 by the get_property driver callback.

 dtv_set_default_delivery_caps() only sets some defaults for drivers not
 implementing get_property yet.
>>>
>>> dtv_set_default_delivery_caps() does the wrong thing for delivery systems
>>> like ISDB-T, ISDB-S, DSS, DMB-TH, as it fills data with a fake value that
>>> is there at fe->ops.info.type. 
>>>
>>> The fake values there should be used only for DVBv3 legacy calls emulation
>>> on those delivery systems that are not fully compatible with a DVBv3 call.
>>
>> That's right. Still, there's no need to introduce fe->ops.delsys,
>> because the drivers in question could just implement get_property
>> instead. At least that's what we discussed and AFAIR agreed upon when
>> Manu recently submitted his patches regarding enumeration of delivery
>> systems.
> 
> Manu's patches were applied (well, except for two patches related to af9013
> driver that are/were under discussion between Manu and Antti).
> 
> Manu's approach is good, as it provided a way to enumerate the 
> standards without much changes, offering a way for userspace to
> query the delivery system, at the expense of serializing a driver 
> call for each property. 
> 
> Yet, it doesn't allow the DVB core to detect the supported
> delivery systems on a sane way [1].
> 
> The addition of fe->ops.delsys is going one step further, as it will
> allow, at the long term, the removal of info.type.

You can't remove info.type, as it would break userspace. What you can do
is deprecate its use inside drivers.

> There are two reasons why we need to get rid of info.type:
> 
> 1) dvb_frontend core can be changed to use fe->ops.delsys
>internally, instead of info.type, in order to fix some
>bugs inside it, where it does the wrong assumption, because
>the frontend is lying about the delivery system;
> 
> 2) There is no sane way to fill fe->ops.info.type for Multi delivery
>system frontends, like DRX-K, that supports both DVB-T and DVB-C.
>The type can be filled with either FE_QAM or FE_OFDM, not with both.
>So, choosing either type will be plain wrong, and may cause bad
>side effects inside dvb_frontend.
> 
> [1] Ok, it would be possible to do a hack internally, for it to call
> get_property() but it is a way more sane to just read fe->ops.delsys.

I don't see why using the already defined interface to query the
possible deliv

[PATCH 4/4] gspca: zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support

[Sylwester Nawrocki]

The JPEG compression quality control is currently done by means of the
VIDIOC_S/G_JPEGCOMP ioctls. As the quality field of struct v4l2_jpgecomp
is being deprecated, we add the V4L2_CID_JPEG_COMPRESSION_QUALITY control,
so after the deprecation period VIDIOC_S/G_JPEGCOMP ioctl handlers can be
removed, leaving the control the only user interface for compression
quality configuration.

For completeness, the V4L2_CID_JPEG_ACTIVE_MARKER control should be also
added.

Cc: Jean-Francois Moine 
Signed-off-by: Sylwester Nawrocki 
---
 drivers/media/video/gspca/zc3xx.c |   54 +---
 1 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/drivers/media/video/gspca/zc3xx.c 
b/drivers/media/video/gspca/zc3xx.c
index f22e02f..019a93b 100644
--- a/drivers/media/video/gspca/zc3xx.c
+++ b/drivers/media/video/gspca/zc3xx.c
@@ -46,6 +46,7 @@ enum e_ctrl {
AUTOGAIN,
LIGHTFREQ,
SHARPNESS,
+   QUALITY,
NCTRLS  /* number of controls */
 };
 
@@ -57,11 +58,6 @@ struct sd {
 
struct gspca_ctrl ctrls[NCTRLS];
 
-   u8 quality; /* image quality */
-#define QUALITY_MIN 50
-#define QUALITY_MAX 80
-#define QUALITY_DEF 70
-
u8 bridge;
u8 sensor;  /* Type of image sensor chip */
u16 chip_revision;
@@ -101,6 +97,12 @@ static void setexposure(struct gspca_dev *gspca_dev);
 static int sd_setautogain(struct gspca_dev *gspca_dev, __s32 val);
 static void setlightfreq(struct gspca_dev *gspca_dev);
 static void setsharpness(struct gspca_dev *gspca_dev);
+static int sd_setquality(struct gspca_dev *gspca_dev, __s32 val);
+
+/* JPEG image quality */
+#define QUALITY_MIN 50
+#define QUALITY_MAX 80
+#define QUALITY_DEF 70
 
 static const struct ctrl sd_ctrls[NCTRLS] = {
 [BRIGHTNESS] = {
@@ -188,6 +190,18 @@ static const struct ctrl sd_ctrls[NCTRLS] = {
},
.set_control = setsharpness
},
+[QUALITY] = {
+   {
+   .id  = V4L2_CID_JPEG_COMPRESSION_QUALITY,
+   .type= V4L2_CTRL_TYPE_INTEGER,
+   .name= "Compression Quality",
+   .minimum = QUALITY_MIN,
+   .maximum = QUALITY_MAX,
+   .step= 1,
+   .default_value = QUALITY_DEF,
+   },
+   .set = sd_setquality
+   },
 };
 
 static const struct v4l2_pix_format vga_mode[] = {
@@ -6411,7 +6425,7 @@ static int sd_config(struct gspca_dev *gspca_dev,
sd->sensor = id->driver_info;
 
gspca_dev->cam.ctrls = sd->ctrls;
-   sd->quality = QUALITY_DEF;
+   sd->ctrls[QUALITY].val = QUALITY_DEF;
 
return 0;
 }
@@ -6685,7 +6699,7 @@ static int sd_start(struct gspca_dev *gspca_dev)
/* create the JPEG header */
jpeg_define(sd->jpeg_hdr, gspca_dev->height, gspca_dev->width,
0x21);  /* JPEG 422 */
-   jpeg_set_qual(sd->jpeg_hdr, sd->quality);
+   jpeg_set_qual(sd->jpeg_hdr, sd->ctrls[QUALITY].val);
 
mode = gspca_dev->cam.cam_mode[gspca_dev->curr_mode].priv;
switch (sd->sensor) {
@@ -6893,29 +6907,35 @@ static int sd_querymenu(struct gspca_dev *gspca_dev,
return -EINVAL;
 }
 
-static int sd_set_jcomp(struct gspca_dev *gspca_dev,
-   struct v4l2_jpegcompression *jcomp)
+static int sd_setquality(struct gspca_dev *gspca_dev, __s32 val)
 {
struct sd *sd = (struct sd *) gspca_dev;
 
-   if (jcomp->quality < QUALITY_MIN)
-   sd->quality = QUALITY_MIN;
-   else if (jcomp->quality > QUALITY_MAX)
-   sd->quality = QUALITY_MAX;
-   else
-   sd->quality = jcomp->quality;
+   sd->ctrls[QUALITY].val = val;
+
if (gspca_dev->streaming)
-   jpeg_set_qual(sd->jpeg_hdr, sd->quality);
+   jpeg_set_qual(sd->jpeg_hdr, val);
+
return gspca_dev->usb_err;
 }
 
+static int sd_set_jcomp(struct gspca_dev *gspca_dev,
+   struct v4l2_jpegcompression *jcomp)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+
+   sd->ctrls[QUALITY].val = clamp_t(u8, jcomp->quality,
+   QUALITY_MIN, QUALITY_MAX);
+   return sd_setquality(gspca_dev, sd->ctrls[QUALITY].val);
+}
+
 static int sd_get_jcomp(struct gspca_dev *gspca_dev,
struct v4l2_jpegcompression *jcomp)
 {
struct sd *sd = (struct sd *) gspca_dev;
 
memset(jcomp, 0, sizeof *jcomp);
-   jcomp->quality = sd->quality;
+   jcomp->quality = sd->ctrls[QUALITY].val;
jcomp->jpeg_markers = V4L2_JPEG_MARKER_DHT
| V4L2_JPEG_MARKER_DQT;
return 0;
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] gspca: sonixj: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support

[Sylwester Nawrocki]

The JPEG compression quality value can currently be read using the
VIDIOC_G_JPEGCOMP ioctl. As the quality field of struct v4l2_jpgecomp
is being deprecated, we add the V4L2_CID_JPEG_COMPRESSION_QUALITY
control, so after the deprecation period VIDIOC_G_JPEGCOMP ioctl
handler can be removed, leaving the control the only user interface
for retrieving the compression quality.

For completeness the V4L2_CID_JPEG_ACTIVE_MARKER control should be also
added.

Cc: Jean-Francois Moine 
Signed-off-by: Sylwester Nawrocki 
---
 drivers/media/video/gspca/sonixj.c |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/gspca/sonixj.c 
b/drivers/media/video/gspca/sonixj.c
index c55d667..c148081 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -45,6 +45,7 @@ enum e_ctrl {
SHARPNESS,
ILLUM,
FREQ,
+   QUALITY,
NCTRLS  /* number of controls */
 };
 
@@ -126,6 +127,7 @@ static void qual_upd(struct work_struct *work);
 #define DEF_EN 0x80/* defect pixel by 0: soft, 1: hard */
 
 /* V4L2 controls supported by the driver */
+static int getjpegqual(struct gspca_dev *gspca_dev, s32 *val);
 static void setbrightness(struct gspca_dev *gspca_dev);
 static void setcontrast(struct gspca_dev *gspca_dev);
 static void setcolors(struct gspca_dev *gspca_dev);
@@ -286,6 +288,19 @@ static const struct ctrl sd_ctrls[NCTRLS] = {
},
.set_control = setfreq
},
+[QUALITY] = {
+   {
+   .id  = V4L2_CID_JPEG_COMPRESSION_QUALITY,
+   .type= V4L2_CTRL_TYPE_INTEGER,
+   .name= "Compression Quality",
+   .minimum = QUALITY_MIN,
+   .maximum = QUALITY_MAX,
+   .step= 1,
+   .default_value = QUALITY_DEF,
+   .flags   = V4L2_CTRL_FLAG_READ_ONLY,
+   },
+   .get = getjpegqual
+   },
 };
 
 /* table of the disabled controls */
@@ -2960,6 +2975,14 @@ static int sd_get_jcomp(struct gspca_dev *gspca_dev,
return 0;
 }
 
+static int getjpegqual(struct gspca_dev *gspca_dev, s32 *val)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+
+   *val = sd->quality;
+   return 0;
+}
+
 static int sd_querymenu(struct gspca_dev *gspca_dev,
struct v4l2_querymenu *menu)
 {
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] V4L: Add the JPEG compression control class documentation

[Sylwester Nawrocki]

Add DocBook entries for the JPEG control class.

Signed-off-by: Sylwester Nawrocki 
---
 Documentation/DocBook/media/v4l/biblio.xml |   20 +++
 Documentation/DocBook/media/v4l/controls.xml   |  161 
 .../DocBook/media/v4l/vidioc-g-jpegcomp.xml|   16 ++-
 3 files changed, 195 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
b/Documentation/DocBook/media/v4l/biblio.xml
index cea6fd3..7dc65c5 100644
--- a/Documentation/DocBook/media/v4l/biblio.xml
+++ b/Documentation/DocBook/media/v4l/biblio.xml
@@ -128,6 +128,26 @@ 
url="http://www.ijg.org";>http://www.ijg.org)
   Version 1.02
 
 
+
+  ITU-T.81
+  
+   International Telecommunication Union
+(http://www.itu.int";>http://www.itu.int)
+  
+  ITU-T Recommendation T.81
+"Information Technology — Digital Compression and Coding of 
Continous-Tone
+Still Images — Requirements and Guidelines"
+
+
+
+  W3C JPEG JFIF
+  
+   The World Wide Web Consortium (http://www.w3.org/Graphics/JPEG";>http://www.w3.org)
+  
+  JPEG JFIF
+
+
 
   SMPTE 12M
   
diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index c0422c6..ab9e56b 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3364,6 +3364,167 @@ interface and may change in the future.

   
   
+
+
+
+  JPEG Control Reference
+  The JPEG class includes controls for common features of JPEG
+  encoders and decoders. Currently it includes features for codecs
+  implementing progressive baseline DCT compression process with
+  Huffman entrophy coding.
+  
+  JPEG Control IDs
 
+  
+   
+   
+   
+   
+   
+   
+   
+ 
+   ID
+   Type
+ Description
+ 
+   
+   
+ 
+ 
+   V4L2_CID_JPEG_CLASS 
+   class
+ The JPEG class descriptor. Calling
+ &VIDIOC-QUERYCTRL; for this control will return a description of this
+ control class.
+
+   
+ 
+ 
+   V4L2_CID_JPEG_CHROMA_SUBSAMPLING
+   menu
+ 
+ 
+   The chroma subsampling factors describe how
+   each component of an input image is sampled, in respect to maximum
+   sample rate in each spatial dimension. See ,
+   clause A.1.1. for more details. The 
+   V4L2_CID_JPEG_CHROMA_SUBSAMPLING control determines how
+   Cb and Cr components are downsampled after coverting an input image
+   from RGB to Y'CbCr color space.
+   
+ 
+ 
+   
+ 
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_444
+ No chroma subsampling, each pixel has
+ Y, Cr and Cb values.
+   
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_422
+ Horizontally subsample Cr, Cb components
+ by a factor of 2.
+   
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_420
+ Subsample Cr, Cb components horizontally
+ and vertically by 2.
+   
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_411
+ Horizontally subsample Cr, Cb components
+ by a factor of 4.
+   
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_410
+ Subsample Cr, Cb components horizontally
+ by 4 and vertically by 2.
+   
+   
+ V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY
+ Use only luminance component.
+   
+ 
+   
+ 
+ 
+   V4L2_CID_JPEG_RESTART_INTERVAL
+   integer
+ 
+ 
+ The restart interval determines an interval of inserting RSTm
+ markers (m = 0..7). The purpose of these markers is to 
additionally
+ reinitialize the encoder process, in order to process blocks of
+ an image independently.
+ For the lossy compression processes the restart interval unit is
+ MCU (Minimum Coded Unit) and its value is contained in DRI
+ (Define Restart Interval) marker. If 
+ V4L2_CID_JPEG_RESTART_INTERVAL control is set to 0,
+ DRI and RSTm markers will not be inserted.
+   
+ 
+ 
+   V4L2_CID_JPEG_COMPRESION_QUALITY
+   integer
+ 
+ 
+   
+ V4L2_CID_JPEG_COMPRESION_QUALITY control
+ determines trade-off between image quality and size.
+ It provides simpler method for applications to control image 
quality,
+ without a need for direct reconfiguration of luminance and 

[PATCH 1/4] V4L: Add JPEG compression control class

[Sylwester Nawrocki]

The V4L2_CID_JPEG_CLASS control class is intended to expose various
adjustable parameters of JPEG encoders and decoders. Following controls
are defined:

 - V4L2_CID_JPEG_CHROMA_SUBSAMPLING,
 - V4L2_CID_JPEG_RESTART_INTERVAL,
 - V4L2_CID_JPEG_COMPRESSION_QUALITY,
 - V4L2_CID_JPEG_ACTIVE_MARKER.

This covers only a part of relevant standard specifications. More
controls should be added in future if required.

The purpose of V4L2_CID_JPEG_CLASS class is also to replace some
functionality covered by VIDIOC_S/G_JPEGCOMP ioctls, i.e. the JPEG
markers presence and compression quality control. The applications
and drivers should switch from the ioctl to control based API, as
described in the Media API DocBook.

Signed-off-by: Sylwester Nawrocki 
---

It could be relevant to also define at this stage controls for JPEG
compression process distinction, i.e.:

* the compression process type

enum v4l2_jpeg_compression_type {
   V4L2_JPEG_COMPRESSION_BASELINE_DCT  = 0,
   V4L2_JPEG_COMPRESSION_EXTENDED_DCT  = 1,
   V4L2_JPEG_COMPRESSION_LOSSLESS  = 2,
   V4L2_JPEG_COMPRESSION_HIERARCHICAL  = 3,
};

* data scan mode for entropy coding

enum v4l2_jpeg_coding_type {
   V4L2_JPEG_CODING_SCAN_SEQUENTIAL   = 0,
   V4L2_JPEG_CODING_SCAN_PROGRESSIVE  = 1,
};

* entropy coding method

enum v4l2_jpeg_coding_scan_type {
   V4L2_JPEG_ENTROPY_CODING_HUFFMAN   = 0,
   V4L2_JPEG_ENTROPY_CODING_ARITHMETIC= 1,
};

However yet there wouldn't be drivers using those controls, or at most
such controls would have only informational purpose (i.e. no more than
one menu entry). For example, arithmetic coding is rarely used due to
patent claims. And the standard enforces baseline sequential DCT-based
process as a minimum, which most of hardware seem to implement. It all
may change when we see first JPEG 2000 hardware codec, however JPEG 2K
might warrant a separate control class.

Comments ?
---
 drivers/media/video/v4l2-ctrls.c |   24 
 include/linux/videodev2.h|   26 ++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 0f415da..b801d8c 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -353,6 +353,16 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
NULL,
};
 
+   static const char * const jpeg_chroma_subsampling[] = {
+   "4:4:4",
+   "4:2:2",
+   "4:2:0",
+   "4:1:1",
+   "4:1:0",
+   "Gray",
+   NULL,
+   };
+
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
return mpeg_audio_sampling_freq;
@@ -414,6 +424,9 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg_mpeg4_level;
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
return mpeg4_profile;
+   case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
+   return jpeg_chroma_subsampling;
+
default:
return NULL;
}
@@ -606,6 +619,14 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FLASH_CHARGE: return "Charge";
case V4L2_CID_FLASH_READY:  return "Ready to strobe";
 
+   /* JPEG encoder controls */
+   /* Keep the order of the 'case's the same as in videodev2.h! */
+   case V4L2_CID_JPEG_CLASS:   return "JPEG Compression 
Controls";
+   case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:  return "Chroma Subsampling";
+   case V4L2_CID_JPEG_RESTART_INTERVAL:return "Restart Interval";
+   case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality";
+   case V4L2_CID_JPEG_ACTIVE_MARKERS:  return "Active Markers";
+
default:
return NULL;
}
@@ -692,6 +713,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC:
case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
+   case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_RDS_TX_PS_NAME:
@@ -703,6 +725,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_CLASS:
case V4L2_CID_FM_TX_CLASS:
case V4L2_CID_FLASH_CLASS:
+   case V4L2_CID_JPEG_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -716,6 +739,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
*max = 0xFF;
break;
case V4L2_CID_FLASH_FAULT:
+   case V4L2_CID_JPEG_ACTIVE_MARKERS:
*type = V4L2_CTRL_TYPE_BITMASK;
 

[RFC/PATCHv1 0/4] JPEG codecs control class

[Sylwester Nawrocki]

Hi,

This patchset is a follow up of an RFC which can be found here:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg39012.html

It creates a new JPEG control class with a tiny amount of four controls
in it. It also adds V4L2_CID_JPEG_COMPRESSION_QUALITY control to two gspca
sub-devices: sonixj and zc3xx, as these where drivers I had the hardware
handy for. The gspca patches have been tested with v4l2ucp and v4l2-ctl.

The compression quality control together with other controls on a panel
is quite convenient. It allows to improve image quality instantly, without
a need for using additional application that handles VIDIOC_S/G_JPEGCOMP.


Thanks,
Sylwester


Sylwester Nawrocki (4):
  V4L: Add JPEG compression control class
  V4L: Add the JPEG compression control class documentation
  gspca: sonixj: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support
  gspca: zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support

 Documentation/DocBook/media/v4l/biblio.xml |   20 +++
 Documentation/DocBook/media/v4l/controls.xml   |  161 
 .../DocBook/media/v4l/vidioc-g-jpegcomp.xml|   16 ++-
 drivers/media/video/gspca/sonixj.c |   23 +++
 drivers/media/video/gspca/zc3xx.c  |   54 +--
 drivers/media/video/v4l2-ctrls.c   |   24 +++
 include/linux/videodev2.h  |   26 +++
 7 files changed, 305 insertions(+), 19 deletions(-)

--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:Tue Dec 27 19:00:18 CET 2011
git hash:1a5cd29631a6b75e49e6ad8a770ab9d69cda0fa2
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-enoxys: ERRORS
linux-git-arm-eabi-omap: ERRORS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2-rc1-x86_64: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: af9015: Second Tuner hangs after a while

[Thomas Holzeisen]

I managed to get the Oops when disconnecting:

Message from syslogd@xbmc at Dec 27 17:53:32 ...
 kernel:[  493.144450] Oops:  [#1] SMP
Message from syslogd@xbmc at Dec 27 17:53:32 ...
 kernel:[  493.147537] Process kworker/0:4 (pid: 1912, ti=f2f94000 
task=f44d6180 task.ti=f2f94000)
Message from syslogd@xbmc at Dec 27 17:53:32 ...
 kernel:[  493.147682] Stack:
Message from syslogd@xbmc at Dec 27 17:53:32 ...
 kernel:[  493.148008] Call Trace:
Message from syslogd@xbmc at Dec 27 17:53:32 ...
 kernel:[  493.148008] Code: f8 75 09 83 ea 28 74 04 89 d0 eb e7 83 c0 10 e9 ba 
73 d9 c8 55 89 cd 57 56 89 c6 53 bb a1
ff ff ff 83 ec 08 89 54 24 04 8b 40 08
Message from syslogd@xbmc at Dec 27 17:53:32 ...
 kernel:[  493.148008] EIP: [] i2c_transfer+0x17/0xb7 [i2c_core] 
SS:ESP 0068:f2f95eec
Message from syslogd@xbmc at Dec 27 17:53:32 ...
 kernel:[  493.148008] CR2: 0002
Message from syslogd@xbmc at Dec 27 17:53:32 ...
 kernel:[  493.164072] Oops:  [#2] SMP


Antti Palosaari wrote:
> On 12/27/2011 06:44 PM, Thomas Holzeisen wrote:
>> Until some time ago, there was not even a remote chance getting this 
>> Dual-Tuner Stick to work. When trying to tune in a
>> second transponder, the log got spammed with these:
>>
>> [  835.412375] af9015: command failed:1
>> [  835.412383] mxl5005s I2C write failed
>>
>> However, I applied the patches ba730b56cc9afbcb10f329c17320c9e535c43526 and 
>> 61875c55170f2cf275263b4ba77e6cc787596d9f
>> from Antti Palosaari. For the first time I got able to receive two 
>> Transponders at once. Sadly after a while the second
>> adapter stops working, showing the I2C erros above. The first adapter keeps 
>> working. Also attaching and removing the
>> stick does not work out very well.
> 
>> this is repeatable to me every time. Removing the stick when in warm state, 
>> leads to kernel oops every time. Kernel
>> Version is 3.1.2.
> 
> Rather interesting problems. As I understand there is two success reports and 
> of course tests I have done. This is first
> report having problems.
> 
> I have PULL requested those changes about one month ago and hope those will 
> committed soon in order to get more
> testers... It is big change, basically whole driver is rewritten and as it is 
> one of the most popular devices it will be
> big chaos after Kernel merge if there will be problems like you have. For now 
> I will still be and wait more reports.
> 
> 
> regards
> Antti

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv1] add DTMB support for DVB API

[Mauro Carvalho Chehab]

On 27-12-2011 14:26, Patrick Boettcher wrote:
> On Friday 23 December 2011 18:27:12 Patrick Boettcher wrote:
>> On Friday, December 23, 2011 02:38:59 PM Andreas Oberritter wrote:
>>> On 22.12.2011 22:30, Antti Palosaari wrote:
 @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {

  GUARD_INTERVAL_1_128,
  GUARD_INTERVAL_19_128,
  GUARD_INTERVAL_19_256,

 +GUARD_INTERVAL_PN420,
 +GUARD_INTERVAL_PN595,
 +GUARD_INTERVAL_PN945,

  } fe_guard_interval_t;
>>>
>>> What does PN mean in this context?
>>
>> While I (right now) cannot remember what the PN abbreviation stands
>> for, the numbers are the guard time in micro-seconds. At least if I
>> remember correctly.
> 
> Totally wrong.
> 
> The number indicated by the PN-value is in samples. Not in micro-
> seconds.
> 
> To compare the PN value with the guard-time known from DVB-T we could do 
> like that: in DVB-T's 8K mode we have 8192 samples which make one 
> symbol. If the guard time is 1/32 we have 8192/32 samples which 
> represent the protect the symbols from inter-symbol-interference: 256 in 
> this case. 
> 
> In DTMB one symbol consists of 3780 samples + the PN-value. Using the 
> classical representation we could say: PN420 is 1/9, PN595 is about 1/6 
> and PN945 is 1/4.

PN595 is then 595/3780 = 119/756 = 17/108

While we might code it then as:

  GUARD_INTERVAL_1_9,   /* PN 420 */
  GUARD_INTERVAL_17_108,/* PN 595 */
  GUARD_INTERVAL_1_4,   /* PN 945 */

in order to preserve the traditional way, maybe it should be coded, instead, as:

GUARD_INTERVAL_420_SAMPLES, /* PN 420 */
GUARD_INTERVAL_595_SAMPLES, /* PN 595 */
GUARD_INTERVAL_945_SAMPLES, /* PN 945 */

I would avoid "PN", as this meaning is not as clear as "samples" or as
a fraction. Also, the traditional guard interval won't be obvious for the
ones that know the DTMB spec.
> 
> HTH,
> 
> --
> Patrick Boettcher
> 
> Kernel Labs Inc.
> http://www.kernellabs.com/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 01/91] [media] dvb-core: allow demods to specify the supported delivery systems supported standards.

[Mauro Carvalho Chehab]

On 27-12-2011 15:33, Antti Palosaari wrote:
> On 12/27/2011 07:06 PM, Mauro Carvalho Chehab wrote:
>> On 27-12-2011 12:33, Andreas Oberritter wrote:
>>> On 27.12.2011 14:28, Mauro Carvalho Chehab wrote:
 On 27-12-2011 10:11, Andreas Oberritter wrote:
> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
>> DVB-S and DVB-T, as those were the standards supported by DVBv3.
>
> The description seems to be incomplete.
>
>> New standards like DSS, ISDB and CTTB don't fit on any of the
>> above types.
>>
>> while there's a way for the drivers to explicitly change whatever
>> default DELSYS were filled inside the core, still a fake value is
>> needed there, and a "compat" code to allow DVBv3 applications to
>> work with those delivery systems is needed. This is good for a
>> short term solution, while applications aren't using DVBv5 directly.
>>
>> However, at long term, this is bad, as the compat code runs even
>> if the application is using DVBv5. Also, the compat code is not
>> perfect, and only works when the frontend is capable of auto-detecting
>> the parameters that aren't visible by the faked delivery systems.
>>
>> So, let the frontend fill the supported delivery systems at the
>> device properties directly, and, in the future, let the core to use
>> the delsys to fill the reported info::type based on the delsys.
>>
>> Signed-off-by: Mauro Carvalho Chehab
>> ---
>>   drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
>>   drivers/media/dvb/dvb-core/dvb_frontend.h |8 
>>   2 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
>> b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> index 8dedff4..f17c411 100644
>> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
>> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> @@ -1252,6 +1252,19 @@ static void dtv_set_default_delivery_caps(const 
>> struct dvb_frontend *fe, struct
>>   const struct dvb_frontend_info *info =&fe->ops.info;
>>   u32 ncaps = 0;
>>
>> +/*
>> + * If the frontend explicitly sets a list, use it, instead of
>> + * filling based on the info->type
>> + */
>> +if (fe->ops.delsys[ncaps]) {
>> +while (fe->ops.delsys[ncaps]&&  ncaps<  MAX_DELSYS) {
>> +p->u.buffer.data[ncaps] = fe->ops.delsys[ncaps];
>> +ncaps++;
>> +}
>> +p->u.buffer.len = ncaps;
>> +return;
>> +}
>> +
>
> I don't understand what this is trying to solve. This is already handled
> by the get_property driver callback.
>
> dtv_set_default_delivery_caps() only sets some defaults for drivers not
> implementing get_property yet.

 dtv_set_default_delivery_caps() does the wrong thing for delivery systems
 like ISDB-T, ISDB-S, DSS, DMB-TH, as it fills data with a fake value that
 is there at fe->ops.info.type.

 The fake values there should be used only for DVBv3 legacy calls emulation
 on those delivery systems that are not fully compatible with a DVBv3 call.
>>>
>>> That's right. Still, there's no need to introduce fe->ops.delsys,
>>> because the drivers in question could just implement get_property
>>> instead. At least that's what we discussed and AFAIR agreed upon when
>>> Manu recently submitted his patches regarding enumeration of delivery
>>> systems.
>>
>> Manu's patches were applied (well, except for two patches related to af9013
>> driver that are/were under discussion between Manu and Antti).
> 
> For me Manu's CXD2820R driver change is OK. I only opened question what is
> meaning of .init() callback as there is now code I like to see be in .init()
> is now moved to .set_frontend(). And as you explained, .init() is useless
> and I will remove it slowly from all my drivers (maybe others too).

OK, I'll merge Manu's cxd2820r changes then, with your acked-by, during this 
week.

> 
>> Manu's approach is good, as it provided a way to enumerate the
>> standards without much changes, offering a way for userspace to
>> query the delivery system, at the expense of serializing a driver
>> call for each property.
>>
>> Yet, it doesn't allow the DVB core to detect the supported
>> delivery systems on a sane way [1].
>>
>> The addition of fe->ops.delsys is going one step further, as it will
>> allow, at the long term, the removal of info.type.
>>
>> There are two reasons why we need to get rid of info.type:
>>
>> 1) dvb_frontend core can be changed to use fe->ops.delsys
>> internally, instead of info.type, in order to fix some
>> bugs inside it, where it does the wrong assumption, because
>> the frontend is lying about the delivery system;
>>
>> 2) There is no sane way to fill fe->ops.info.type for Multi delivery
>> system frontends, like DRX-K, that suppor

Re: [PATCH RFC 01/91] [media] dvb-core: allow demods to specify the supported delivery systems supported standards.

[Antti Palosaari]

On 12/27/2011 07:06 PM, Mauro Carvalho Chehab wrote:

On 27-12-2011 12:33, Andreas Oberritter wrote:

On 27.12.2011 14:28, Mauro Carvalho Chehab wrote:

On 27-12-2011 10:11, Andreas Oberritter wrote:

On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:

DVB-S and DVB-T, as those were the standards supported by DVBv3.


The description seems to be incomplete.


New standards like DSS, ISDB and CTTB don't fit on any of the
above types.

while there's a way for the drivers to explicitly change whatever
default DELSYS were filled inside the core, still a fake value is
needed there, and a "compat" code to allow DVBv3 applications to
work with those delivery systems is needed. This is good for a
short term solution, while applications aren't using DVBv5 directly.

However, at long term, this is bad, as the compat code runs even
if the application is using DVBv5. Also, the compat code is not
perfect, and only works when the frontend is capable of auto-detecting
the parameters that aren't visible by the faked delivery systems.

So, let the frontend fill the supported delivery systems at the
device properties directly, and, in the future, let the core to use
the delsys to fill the reported info::type based on the delsys.

Signed-off-by: Mauro Carvalho Chehab
---
  drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
  drivers/media/dvb/dvb-core/dvb_frontend.h |8 
  2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 8dedff4..f17c411 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1252,6 +1252,19 @@ static void dtv_set_default_delivery_caps(const struct 
dvb_frontend *fe, struct
const struct dvb_frontend_info *info =&fe->ops.info;
u32 ncaps = 0;

+   /*
+* If the frontend explicitly sets a list, use it, instead of
+* filling based on the info->type
+*/
+   if (fe->ops.delsys[ncaps]) {
+   while (fe->ops.delsys[ncaps]&&  ncaps<  MAX_DELSYS) {
+   p->u.buffer.data[ncaps] = fe->ops.delsys[ncaps];
+   ncaps++;
+   }
+   p->u.buffer.len = ncaps;
+   return;
+   }
+


I don't understand what this is trying to solve. This is already handled
by the get_property driver callback.

dtv_set_default_delivery_caps() only sets some defaults for drivers not
implementing get_property yet.


dtv_set_default_delivery_caps() does the wrong thing for delivery systems
like ISDB-T, ISDB-S, DSS, DMB-TH, as it fills data with a fake value that
is there at fe->ops.info.type.

The fake values there should be used only for DVBv3 legacy calls emulation
on those delivery systems that are not fully compatible with a DVBv3 call.


That's right. Still, there's no need to introduce fe->ops.delsys,
because the drivers in question could just implement get_property
instead. At least that's what we discussed and AFAIR agreed upon when
Manu recently submitted his patches regarding enumeration of delivery
systems.


Manu's patches were applied (well, except for two patches related to af9013
driver that are/were under discussion between Manu and Antti).


For me Manu's CXD2820R driver change is OK. I only opened question what 
is meaning of .init() callback as there is now code I like to see be in 
.init() is now moved to .set_frontend(). And as you explained, .init() 
is useless and I will remove it slowly from all my drivers (maybe others 
too).



Manu's approach is good, as it provided a way to enumerate the
standards without much changes, offering a way for userspace to
query the delivery system, at the expense of serializing a driver
call for each property.

Yet, it doesn't allow the DVB core to detect the supported
delivery systems on a sane way [1].

The addition of fe->ops.delsys is going one step further, as it will
allow, at the long term, the removal of info.type.

There are two reasons why we need to get rid of info.type:

1) dvb_frontend core can be changed to use fe->ops.delsys
internally, instead of info.type, in order to fix some
bugs inside it, where it does the wrong assumption, because
the frontend is lying about the delivery system;

2) There is no sane way to fill fe->ops.info.type for Multi delivery
system frontends, like DRX-K, that supports both DVB-T and DVB-C.
The type can be filled with either FE_QAM or FE_OFDM, not with both.
So, choosing either type will be plain wrong, and may cause bad
side effects inside dvb_frontend.

[1] Ok, it would be possible to do a hack internally, for it to call
get_property() but it is a way more sane to just read fe->ops.delsys.




At the end, I think we should deprecate the fe->ops.info.type, as its
contents is not reliable (as it can represent something else).

Btw, there are several places at dvb_frontend.c that uses the info.type
to assume the de

Re: [PATCH RFC 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

[Mauro Carvalho Chehab]

On 27-12-2011 12:47, Andreas Oberritter wrote:
> On 27.12.2011 14:49, Mauro Carvalho Chehab wrote:
>> On 27-12-2011 10:21, Andreas Oberritter wrote:
>>> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
 The old method is renamed to get_frontend_legacy(), while not all
 frontends are converted.

 Signed-off-by: Mauro Carvalho Chehab 
 ---
  drivers/media/dvb/bt8xx/dst.c   |8 +-
  drivers/media/dvb/dvb-core/dvb_frontend.c   |  102 
 --
  drivers/media/dvb/dvb-core/dvb_frontend.h   |5 +-
  drivers/media/dvb/dvb-usb/af9005-fe.c   |4 +-
  drivers/media/dvb/dvb-usb/cinergyT2-fe.c|2 +-
  drivers/media/dvb/dvb-usb/dtt200u-fe.c  |2 +-
  drivers/media/dvb/dvb-usb/friio-fe.c|2 +-
  drivers/media/dvb/dvb-usb/mxl111sf-demod.c  |2 +-
  drivers/media/dvb/dvb-usb/vp702x-fe.c   |2 +-
  drivers/media/dvb/dvb-usb/vp7045-fe.c   |2 +-
  drivers/media/dvb/firewire/firedtv-fe.c |2 +-
  drivers/media/dvb/frontends/af9013.c|2 +-
  drivers/media/dvb/frontends/atbm8830.c  |2 +-
  drivers/media/dvb/frontends/au8522_dig.c|2 +-
  drivers/media/dvb/frontends/cx22700.c   |2 +-
  drivers/media/dvb/frontends/cx22702.c   |2 +-
  drivers/media/dvb/frontends/cx24110.c   |2 +-
  drivers/media/dvb/frontends/cx24123.c   |2 +-
  drivers/media/dvb/frontends/cxd2820r_core.c |4 +-
  drivers/media/dvb/frontends/dib3000mb.c |2 +-
  drivers/media/dvb/frontends/dib3000mc.c |2 +-
  drivers/media/dvb/frontends/dib7000m.c  |2 +-
  drivers/media/dvb/frontends/dib7000p.c  |2 +-
  drivers/media/dvb/frontends/dib8000.c   |4 +-
  drivers/media/dvb/frontends/dib9000.c   |4 +-
  drivers/media/dvb/frontends/drxd_hard.c |2 +-
  drivers/media/dvb/frontends/drxk_hard.c |4 +-
  drivers/media/dvb/frontends/dvb_dummy_fe.c  |6 +-
  drivers/media/dvb/frontends/it913x-fe.c |2 +-
  drivers/media/dvb/frontends/l64781.c|2 +-
  drivers/media/dvb/frontends/lgdt3305.c  |4 +-
  drivers/media/dvb/frontends/lgdt330x.c  |4 +-
  drivers/media/dvb/frontends/lgs8gl5.c   |2 +-
  drivers/media/dvb/frontends/lgs8gxx.c   |2 +-
  drivers/media/dvb/frontends/mb86a20s.c  |2 +-
  drivers/media/dvb/frontends/mt312.c |2 +-
  drivers/media/dvb/frontends/mt352.c |2 +-
  drivers/media/dvb/frontends/or51132.c   |2 +-
  drivers/media/dvb/frontends/s5h1409.c   |2 +-
  drivers/media/dvb/frontends/s5h1411.c   |2 +-
  drivers/media/dvb/frontends/s5h1420.c   |2 +-
  drivers/media/dvb/frontends/s5h1432.c   |2 +-
  drivers/media/dvb/frontends/s921.c  |2 +-
  drivers/media/dvb/frontends/stb0899_drv.c   |2 +-
  drivers/media/dvb/frontends/stb6100.c   |4 +-
  drivers/media/dvb/frontends/stv0297.c   |2 +-
  drivers/media/dvb/frontends/stv0299.c   |2 +-
  drivers/media/dvb/frontends/stv0367.c   |4 +-
  drivers/media/dvb/frontends/stv0900_core.c  |2 +-
  drivers/media/dvb/frontends/tda10021.c  |2 +-
  drivers/media/dvb/frontends/tda10023.c  |2 +-
  drivers/media/dvb/frontends/tda10048.c  |2 +-
  drivers/media/dvb/frontends/tda1004x.c  |4 +-
  drivers/media/dvb/frontends/tda10071.c  |2 +-
  drivers/media/dvb/frontends/tda10086.c  |2 +-
  drivers/media/dvb/frontends/tda8083.c   |2 +-
  drivers/media/dvb/frontends/ves1820.c   |2 +-
  drivers/media/dvb/frontends/ves1x93.c   |2 +-
  drivers/media/dvb/frontends/zl10353.c   |2 +-
  drivers/media/dvb/siano/smsdvb.c|2 +-
  drivers/media/video/tlg2300/pd-dvb.c|2 +-
  drivers/staging/media/as102/as102_fe.c  |2 +-
  62 files changed, 157 insertions(+), 100 deletions(-)

 diff --git a/drivers/media/dvb/bt8xx/dst.c b/drivers/media/dvb/bt8xx/dst.c
 index 4658bd6..6afc083 100644
 --- a/drivers/media/dvb/bt8xx/dst.c
 +++ b/drivers/media/dvb/bt8xx/dst.c
 @@ -1778,7 +1778,7 @@ static struct dvb_frontend_ops dst_dvbt_ops = {
.init = dst_init,
.tune = dst_tune_frontend,
.set_frontend_legacy = dst_set_frontend,
 -  .get_frontend = dst_get_frontend,
 +  .get_frontend_legacy = dst_get_frontend,
.get_frontend_algo = dst_get_tuning_algo,
.read_status = dst_read_status,
.read_signal_strength = dst_read_signal_strength,
 @@ -1804,7 +1804,7 @@ static struct dvb_frontend_ops dst_dvbs_ops = {
.init = dst_init,
.tune = dst_tune_frontend,
.set_frontend_legacy = dst_set_frontend,
 -  .get_fron

Re: af9015: Second Tuner hangs after a while

[Antti Palosaari]

On 12/27/2011 06:44 PM, Thomas Holzeisen wrote:

Until some time ago, there was not even a remote chance getting this Dual-Tuner 
Stick to work. When trying to tune in a
second transponder, the log got spammed with these:

[  835.412375] af9015: command failed:1
[  835.412383] mxl5005s I2C write failed

However, I applied the patches ba730b56cc9afbcb10f329c17320c9e535c43526 and 
61875c55170f2cf275263b4ba77e6cc787596d9f
from Antti Palosaari. For the first time I got able to receive two Transponders 
at once. Sadly after a while the second
adapter stops working, showing the I2C erros above. The first adapter keeps 
working. Also attaching and removing the
stick does not work out very well.



this is repeatable to me every time. Removing the stick when in warm state, 
leads to kernel oops every time. Kernel
Version is 3.1.2.


Rather interesting problems. As I understand there is two success 
reports and of course tests I have done. This is first report having 
problems.


I have PULL requested those changes about one month ago and hope those 
will committed soon in order to get more testers... It is big change, 
basically whole driver is rewritten and as it is one of the most popular 
devices it will be big chaos after Kernel merge if there will be 
problems like you have. For now I will still be and wait more reports.



regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 01/91] [media] dvb-core: allow demods to specify the supported delivery systems supported standards.

[Mauro Carvalho Chehab]

On 27-12-2011 12:33, Andreas Oberritter wrote:
> On 27.12.2011 14:28, Mauro Carvalho Chehab wrote:
>> On 27-12-2011 10:11, Andreas Oberritter wrote:
>>> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
 DVB-S and DVB-T, as those were the standards supported by DVBv3.
>>>
>>> The description seems to be incomplete.
>>>
 New standards like DSS, ISDB and CTTB don't fit on any of the
 above types.

 while there's a way for the drivers to explicitly change whatever
 default DELSYS were filled inside the core, still a fake value is
 needed there, and a "compat" code to allow DVBv3 applications to
 work with those delivery systems is needed. This is good for a
 short term solution, while applications aren't using DVBv5 directly.

 However, at long term, this is bad, as the compat code runs even
 if the application is using DVBv5. Also, the compat code is not
 perfect, and only works when the frontend is capable of auto-detecting
 the parameters that aren't visible by the faked delivery systems.

 So, let the frontend fill the supported delivery systems at the
 device properties directly, and, in the future, let the core to use
 the delsys to fill the reported info::type based on the delsys.

 Signed-off-by: Mauro Carvalho Chehab 
 ---
  drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
  drivers/media/dvb/dvb-core/dvb_frontend.h |8 
  2 files changed, 21 insertions(+), 0 deletions(-)

 diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
 b/drivers/media/dvb/dvb-core/dvb_frontend.c
 index 8dedff4..f17c411 100644
 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
 +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
 @@ -1252,6 +1252,19 @@ static void dtv_set_default_delivery_caps(const 
 struct dvb_frontend *fe, struct
const struct dvb_frontend_info *info = &fe->ops.info;
u32 ncaps = 0;
  
 +  /*
 +   * If the frontend explicitly sets a list, use it, instead of
 +   * filling based on the info->type
 +   */
 +  if (fe->ops.delsys[ncaps]) {
 +  while (fe->ops.delsys[ncaps] && ncaps < MAX_DELSYS) {
 +  p->u.buffer.data[ncaps] = fe->ops.delsys[ncaps];
 +  ncaps++;
 +  }
 +  p->u.buffer.len = ncaps;
 +  return;
 +  }
 +
>>>
>>> I don't understand what this is trying to solve. This is already handled
>>> by the get_property driver callback.
>>>
>>> dtv_set_default_delivery_caps() only sets some defaults for drivers not
>>> implementing get_property yet.
>>
>> dtv_set_default_delivery_caps() does the wrong thing for delivery systems
>> like ISDB-T, ISDB-S, DSS, DMB-TH, as it fills data with a fake value that
>> is there at fe->ops.info.type. 
>>
>> The fake values there should be used only for DVBv3 legacy calls emulation
>> on those delivery systems that are not fully compatible with a DVBv3 call.
> 
> That's right. Still, there's no need to introduce fe->ops.delsys,
> because the drivers in question could just implement get_property
> instead. At least that's what we discussed and AFAIR agreed upon when
> Manu recently submitted his patches regarding enumeration of delivery
> systems.

Manu's patches were applied (well, except for two patches related to af9013
driver that are/were under discussion between Manu and Antti).

Manu's approach is good, as it provided a way to enumerate the 
standards without much changes, offering a way for userspace to
query the delivery system, at the expense of serializing a driver 
call for each property. 

Yet, it doesn't allow the DVB core to detect the supported
delivery systems on a sane way [1].

The addition of fe->ops.delsys is going one step further, as it will
allow, at the long term, the removal of info.type.

There are two reasons why we need to get rid of info.type:

1) dvb_frontend core can be changed to use fe->ops.delsys
   internally, instead of info.type, in order to fix some
   bugs inside it, where it does the wrong assumption, because
   the frontend is lying about the delivery system;

2) There is no sane way to fill fe->ops.info.type for Multi delivery
   system frontends, like DRX-K, that supports both DVB-T and DVB-C.
   The type can be filled with either FE_QAM or FE_OFDM, not with both.
   So, choosing either type will be plain wrong, and may cause bad
   side effects inside dvb_frontend.

[1] Ok, it would be possible to do a hack internally, for it to call
get_property() but it is a way more sane to just read fe->ops.delsys.

> 
>> At the end, I think we should deprecate the fe->ops.info.type, as its
>> contents is not reliable (as it can represent something else). 
>>
>> Btw, there are several places at dvb_frontend.c that uses the info.type
>> to assume the delivery system. This leads DVB core to do the wrong 
>> assumptions
>> for non-DVBv3 supported systems. The right way i

af9015: Second Tuner hangs after a while

[Thomas Holzeisen]

Hello there,

I got a MSI DigiVox Duo stick identifying as:

Bus 001 Device 005: ID 1462:8801 Micro Star International
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x1462 Micro Star International
  idProduct  0x8801
  bcdDevice2.00
  iManufacturer   1 Afatech
  iProduct2 DVB-T 2
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   46
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x
  (Bus Powered)

Until some time ago, there was not even a remote chance getting this Dual-Tuner 
Stick to work. When trying to tune in a
second transponder, the log got spammed with these:

[  835.412375] af9015: command failed:1
[  835.412383] mxl5005s I2C write failed

However, I applied the patches ba730b56cc9afbcb10f329c17320c9e535c43526 and 
61875c55170f2cf275263b4ba77e6cc787596d9f
from Antti Palosaari. For the first time I got able to receive two Transponders 
at once. Sadly after a while the second
adapter stops working, showing the I2C erros above. The first adapter keeps 
working. Also attaching and removing the
stick does not work out very well.

First plugin attempt:
[   78.552597] dvb-usb: found a 'MSI DIGIVOX Duo' in cold state, will try to 
load a firmware
[   78.592456] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw'
[   78.662114] dvb-usb: found a 'MSI DIGIVOX Duo' in warm state.
[   78.662251] dvb-usb: will pass the complete MPEG2 transport stream to the 
software demuxer.
[   78.663514] DVB: registering new adapter (MSI DIGIVOX Duo)
[   78.709768] af9013: firmware version 0.0.0.0
[   78.711858] DVB: registering adapter 0 frontend 0 (Afatech AF9013)...
[   78.745265] MXL5005S: Attached at address 0xc6
[   78.745278] dvb-usb: will pass the complete MPEG2 transport stream to the 
software demuxer.
[   78.746513] DVB: registering new adapter (MSI DIGIVOX Duo)
[   79.361106] af9015: firmware did not run
[   79.361117] af9015: firmware copy to 2nd frontend failed, will disable it
[   79.361127] dvb-usb: no frontend was attached by 'MSI DIGIVOX Duo'
[   79.361136] dvb-usb: MSI DIGIVOX Duo successfully initialized and connected.
[   79.368407] usbcore: registered new interface driver dvb_usb_af9015

removing and inserting again
[  160.290935] dvb-usb: MSI DIGIVOX Duo successfully deinitialized and 
disconnected.
[  197.576325] af9015: recv bulk message failed:-110
[  197.576338] af9015: eeprom read

Re: [RFCv1] add DTMB support for DVB API

[Patrick Boettcher]

On Friday 23 December 2011 18:27:12 Patrick Boettcher wrote:
> On Friday, December 23, 2011 02:38:59 PM Andreas Oberritter wrote:
> > On 22.12.2011 22:30, Antti Palosaari wrote:
> > > @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
> > > 
> > >  GUARD_INTERVAL_1_128,
> > >  GUARD_INTERVAL_19_128,
> > >  GUARD_INTERVAL_19_256,
> > > 
> > > +GUARD_INTERVAL_PN420,
> > > +GUARD_INTERVAL_PN595,
> > > +GUARD_INTERVAL_PN945,
> > > 
> > >  } fe_guard_interval_t;
> > 
> > What does PN mean in this context?
> 
> While I (right now) cannot remember what the PN abbreviation stands
> for, the numbers are the guard time in micro-seconds. At least if I
> remember correctly.

Totally wrong.

The number indicated by the PN-value is in samples. Not in micro-
seconds.

To compare the PN value with the guard-time known from DVB-T we could do 
like that: in DVB-T's 8K mode we have 8192 samples which make one 
symbol. If the guard time is 1/32 we have 8192/32 samples which 
represent the protect the symbols from inter-symbol-interference: 256 in 
this case. 

In DTMB one symbol consists of 3780 samples + the PN-value. Using the 
classical representation we could say: PN420 is 1/9, PN595 is about 1/6 
and PN945 is 1/4.

HTH,

--
Patrick Boettcher

Kernel Labs Inc.
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DVB-S2 multistream support

[Antti Palosaari]

On 12/27/2011 12:12 PM, Christian Prähauser wrote:


Yes, I'm meaning something like what it was described there. I think
that the code written by Christian were never submitted upstream.



Hello Mauro,

Konstantin drew my attention to this discussion. Indeed, some time ago I wrote
a base-band demux for LinuxDVB. It was part of a project to integrate support
for second-generation IP/DVB encapsulations (GSE). The BB-demux allows to
register filters for different ISIs and data types (raw, generic stream,
transport stream).

I realized that the repo hosted at our University is down. If there is interest,
I can update my patches to the latest LinuxDVB version and we can put them on a
public repo e.g. at linuxdvb.org.

Kind regards,
Christian.


I have a question which is a little bit off-topic for that thread but I 
would like to ask since I think you could have some idea.


FEC Code Rate is often given as k/n, for example FEC 1/4. But nowadays 
there is also seen 0.x like FEC 0.8.
I have feeling that this is due to new inner coding used, LDPC instead 
of traditional convolutional codes. When convolution codes were used it 
was correct to define 1/2 as basic rate and puncture rest from that. But 
as now with LDPC we have larger blocks we cannot represent so easily. 
For example DTMB uses LDPC(7488,6016) = 6016/7488 = ~0.8034 => FEC 0.8 
is used.


I am adding DTMB support for DVB API and that's why I have to think if I 
extend old k/n FECs or define new ones as FEC 0.4/0.6/0.8.


regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

[Andreas Oberritter]

On 27.12.2011 14:49, Mauro Carvalho Chehab wrote:
> On 27-12-2011 10:21, Andreas Oberritter wrote:
>> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
>>> The old method is renamed to get_frontend_legacy(), while not all
>>> frontends are converted.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab 
>>> ---
>>>  drivers/media/dvb/bt8xx/dst.c   |8 +-
>>>  drivers/media/dvb/dvb-core/dvb_frontend.c   |  102 
>>> --
>>>  drivers/media/dvb/dvb-core/dvb_frontend.h   |5 +-
>>>  drivers/media/dvb/dvb-usb/af9005-fe.c   |4 +-
>>>  drivers/media/dvb/dvb-usb/cinergyT2-fe.c|2 +-
>>>  drivers/media/dvb/dvb-usb/dtt200u-fe.c  |2 +-
>>>  drivers/media/dvb/dvb-usb/friio-fe.c|2 +-
>>>  drivers/media/dvb/dvb-usb/mxl111sf-demod.c  |2 +-
>>>  drivers/media/dvb/dvb-usb/vp702x-fe.c   |2 +-
>>>  drivers/media/dvb/dvb-usb/vp7045-fe.c   |2 +-
>>>  drivers/media/dvb/firewire/firedtv-fe.c |2 +-
>>>  drivers/media/dvb/frontends/af9013.c|2 +-
>>>  drivers/media/dvb/frontends/atbm8830.c  |2 +-
>>>  drivers/media/dvb/frontends/au8522_dig.c|2 +-
>>>  drivers/media/dvb/frontends/cx22700.c   |2 +-
>>>  drivers/media/dvb/frontends/cx22702.c   |2 +-
>>>  drivers/media/dvb/frontends/cx24110.c   |2 +-
>>>  drivers/media/dvb/frontends/cx24123.c   |2 +-
>>>  drivers/media/dvb/frontends/cxd2820r_core.c |4 +-
>>>  drivers/media/dvb/frontends/dib3000mb.c |2 +-
>>>  drivers/media/dvb/frontends/dib3000mc.c |2 +-
>>>  drivers/media/dvb/frontends/dib7000m.c  |2 +-
>>>  drivers/media/dvb/frontends/dib7000p.c  |2 +-
>>>  drivers/media/dvb/frontends/dib8000.c   |4 +-
>>>  drivers/media/dvb/frontends/dib9000.c   |4 +-
>>>  drivers/media/dvb/frontends/drxd_hard.c |2 +-
>>>  drivers/media/dvb/frontends/drxk_hard.c |4 +-
>>>  drivers/media/dvb/frontends/dvb_dummy_fe.c  |6 +-
>>>  drivers/media/dvb/frontends/it913x-fe.c |2 +-
>>>  drivers/media/dvb/frontends/l64781.c|2 +-
>>>  drivers/media/dvb/frontends/lgdt3305.c  |4 +-
>>>  drivers/media/dvb/frontends/lgdt330x.c  |4 +-
>>>  drivers/media/dvb/frontends/lgs8gl5.c   |2 +-
>>>  drivers/media/dvb/frontends/lgs8gxx.c   |2 +-
>>>  drivers/media/dvb/frontends/mb86a20s.c  |2 +-
>>>  drivers/media/dvb/frontends/mt312.c |2 +-
>>>  drivers/media/dvb/frontends/mt352.c |2 +-
>>>  drivers/media/dvb/frontends/or51132.c   |2 +-
>>>  drivers/media/dvb/frontends/s5h1409.c   |2 +-
>>>  drivers/media/dvb/frontends/s5h1411.c   |2 +-
>>>  drivers/media/dvb/frontends/s5h1420.c   |2 +-
>>>  drivers/media/dvb/frontends/s5h1432.c   |2 +-
>>>  drivers/media/dvb/frontends/s921.c  |2 +-
>>>  drivers/media/dvb/frontends/stb0899_drv.c   |2 +-
>>>  drivers/media/dvb/frontends/stb6100.c   |4 +-
>>>  drivers/media/dvb/frontends/stv0297.c   |2 +-
>>>  drivers/media/dvb/frontends/stv0299.c   |2 +-
>>>  drivers/media/dvb/frontends/stv0367.c   |4 +-
>>>  drivers/media/dvb/frontends/stv0900_core.c  |2 +-
>>>  drivers/media/dvb/frontends/tda10021.c  |2 +-
>>>  drivers/media/dvb/frontends/tda10023.c  |2 +-
>>>  drivers/media/dvb/frontends/tda10048.c  |2 +-
>>>  drivers/media/dvb/frontends/tda1004x.c  |4 +-
>>>  drivers/media/dvb/frontends/tda10071.c  |2 +-
>>>  drivers/media/dvb/frontends/tda10086.c  |2 +-
>>>  drivers/media/dvb/frontends/tda8083.c   |2 +-
>>>  drivers/media/dvb/frontends/ves1820.c   |2 +-
>>>  drivers/media/dvb/frontends/ves1x93.c   |2 +-
>>>  drivers/media/dvb/frontends/zl10353.c   |2 +-
>>>  drivers/media/dvb/siano/smsdvb.c|2 +-
>>>  drivers/media/video/tlg2300/pd-dvb.c|2 +-
>>>  drivers/staging/media/as102/as102_fe.c  |2 +-
>>>  62 files changed, 157 insertions(+), 100 deletions(-)
>>>
>>> diff --git a/drivers/media/dvb/bt8xx/dst.c b/drivers/media/dvb/bt8xx/dst.c
>>> index 4658bd6..6afc083 100644
>>> --- a/drivers/media/dvb/bt8xx/dst.c
>>> +++ b/drivers/media/dvb/bt8xx/dst.c
>>> @@ -1778,7 +1778,7 @@ static struct dvb_frontend_ops dst_dvbt_ops = {
>>> .init = dst_init,
>>> .tune = dst_tune_frontend,
>>> .set_frontend_legacy = dst_set_frontend,
>>> -   .get_frontend = dst_get_frontend,
>>> +   .get_frontend_legacy = dst_get_frontend,
>>> .get_frontend_algo = dst_get_tuning_algo,
>>> .read_status = dst_read_status,
>>> .read_signal_strength = dst_read_signal_strength,
>>> @@ -1804,7 +1804,7 @@ static struct dvb_frontend_ops dst_dvbs_ops = {
>>> .init = dst_init,
>>> .tune = dst_tune_frontend,
>>> .set_frontend_legacy = dst_set_frontend,
>>> -   .get_frontend = dst_get_frontend,
>>> +   .get_frontend_legacy = dst_get_frontend,
>>> .get_frontend_algo = dst_get_tuning_algo,
>>>

Re: [PATCH RFC 01/91] [media] dvb-core: allow demods to specify the supported delivery systems supported standards.

[Andreas Oberritter]

On 27.12.2011 14:28, Mauro Carvalho Chehab wrote:
> On 27-12-2011 10:11, Andreas Oberritter wrote:
>> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
>>> DVB-S and DVB-T, as those were the standards supported by DVBv3.
>>
>> The description seems to be incomplete.
>>
>>> New standards like DSS, ISDB and CTTB don't fit on any of the
>>> above types.
>>>
>>> while there's a way for the drivers to explicitly change whatever
>>> default DELSYS were filled inside the core, still a fake value is
>>> needed there, and a "compat" code to allow DVBv3 applications to
>>> work with those delivery systems is needed. This is good for a
>>> short term solution, while applications aren't using DVBv5 directly.
>>>
>>> However, at long term, this is bad, as the compat code runs even
>>> if the application is using DVBv5. Also, the compat code is not
>>> perfect, and only works when the frontend is capable of auto-detecting
>>> the parameters that aren't visible by the faked delivery systems.
>>>
>>> So, let the frontend fill the supported delivery systems at the
>>> device properties directly, and, in the future, let the core to use
>>> the delsys to fill the reported info::type based on the delsys.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab 
>>> ---
>>>  drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
>>>  drivers/media/dvb/dvb-core/dvb_frontend.h |8 
>>>  2 files changed, 21 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
>>> b/drivers/media/dvb/dvb-core/dvb_frontend.c
>>> index 8dedff4..f17c411 100644
>>> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
>>> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
>>> @@ -1252,6 +1252,19 @@ static void dtv_set_default_delivery_caps(const 
>>> struct dvb_frontend *fe, struct
>>> const struct dvb_frontend_info *info = &fe->ops.info;
>>> u32 ncaps = 0;
>>>  
>>> +   /*
>>> +* If the frontend explicitly sets a list, use it, instead of
>>> +* filling based on the info->type
>>> +*/
>>> +   if (fe->ops.delsys[ncaps]) {
>>> +   while (fe->ops.delsys[ncaps] && ncaps < MAX_DELSYS) {
>>> +   p->u.buffer.data[ncaps] = fe->ops.delsys[ncaps];
>>> +   ncaps++;
>>> +   }
>>> +   p->u.buffer.len = ncaps;
>>> +   return;
>>> +   }
>>> +
>>
>> I don't understand what this is trying to solve. This is already handled
>> by the get_property driver callback.
>>
>> dtv_set_default_delivery_caps() only sets some defaults for drivers not
>> implementing get_property yet.
> 
> dtv_set_default_delivery_caps() does the wrong thing for delivery systems
> like ISDB-T, ISDB-S, DSS, DMB-TH, as it fills data with a fake value that
> is there at fe->ops.info.type. 
> 
> The fake values there should be used only for DVBv3 legacy calls emulation
> on those delivery systems that are not fully compatible with a DVBv3 call.

That's right. Still, there's no need to introduce fe->ops.delsys,
because the drivers in question could just implement get_property
instead. At least that's what we discussed and AFAIR agreed upon when
Manu recently submitted his patches regarding enumeration of delivery
systems.

> At the end, I think we should deprecate the fe->ops.info.type, as its
> contents is not reliable (as it can represent something else). 
> 
> Btw, there are several places at dvb_frontend.c that uses the info.type
> to assume the delivery system. This leads DVB core to do the wrong assumptions
> for non-DVBv3 supported systems. The right way is to use a new field that
> really represents the supported delivery systems by a given frontend, instead
> of relying on fe->ops.info.type.
> 
> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] s5p-mfc: Fix volatile controls setup

[Kamil Debski]

Signed-off-by: Kamil Debski 
Signed-off-by: Kyungmin Park 
---
 drivers/media/video/s5p-mfc/s5p_mfc_dec.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
index 844a4d7..c25ec02 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
@@ -165,7 +165,7 @@ static struct mfc_control controls[] = {
.maximum = 32,
.step = 1,
.default_value = 1,
-   .flags = V4L2_CTRL_FLAG_VOLATILE,
+   .is_volatile = 1,
},
 };
 
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/91] Only use DVBv5 internally on frontend drivers

[Mauro Carvalho Chehab]

On 27-12-2011 11:19, Mauro Carvalho Chehab wrote:
> On 27-12-2011 10:31, Andreas Oberritter wrote:
>> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
>>> Mauro Carvalho Chehab (91):
>>
>> It would be nice if you could send each message as a reply to the cover
>> letter next time, instead of sending message x as a reply to message x-1.
>>
>> Otherwise, one needs a very wide screen to display all messages in a
>> threaded view. I stopped reading around message 50.
> 
> This is the way git mail-send does, at least by default. Maybe there's an
> option for it to change the way threads are shown. I'll seek if is there
> any way to change it.

Ok, this should fix my git mail-send config:

[sendemail]
chainreplyto = false

Next time, it should send everything as reply to the first message.

Thanks for pointing it!
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

[Mauro Carvalho Chehab]

On 27-12-2011 10:21, Andreas Oberritter wrote:
> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
>> The old method is renamed to get_frontend_legacy(), while not all
>> frontends are converted.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>> ---
>>  drivers/media/dvb/bt8xx/dst.c   |8 +-
>>  drivers/media/dvb/dvb-core/dvb_frontend.c   |  102 
>> --
>>  drivers/media/dvb/dvb-core/dvb_frontend.h   |5 +-
>>  drivers/media/dvb/dvb-usb/af9005-fe.c   |4 +-
>>  drivers/media/dvb/dvb-usb/cinergyT2-fe.c|2 +-
>>  drivers/media/dvb/dvb-usb/dtt200u-fe.c  |2 +-
>>  drivers/media/dvb/dvb-usb/friio-fe.c|2 +-
>>  drivers/media/dvb/dvb-usb/mxl111sf-demod.c  |2 +-
>>  drivers/media/dvb/dvb-usb/vp702x-fe.c   |2 +-
>>  drivers/media/dvb/dvb-usb/vp7045-fe.c   |2 +-
>>  drivers/media/dvb/firewire/firedtv-fe.c |2 +-
>>  drivers/media/dvb/frontends/af9013.c|2 +-
>>  drivers/media/dvb/frontends/atbm8830.c  |2 +-
>>  drivers/media/dvb/frontends/au8522_dig.c|2 +-
>>  drivers/media/dvb/frontends/cx22700.c   |2 +-
>>  drivers/media/dvb/frontends/cx22702.c   |2 +-
>>  drivers/media/dvb/frontends/cx24110.c   |2 +-
>>  drivers/media/dvb/frontends/cx24123.c   |2 +-
>>  drivers/media/dvb/frontends/cxd2820r_core.c |4 +-
>>  drivers/media/dvb/frontends/dib3000mb.c |2 +-
>>  drivers/media/dvb/frontends/dib3000mc.c |2 +-
>>  drivers/media/dvb/frontends/dib7000m.c  |2 +-
>>  drivers/media/dvb/frontends/dib7000p.c  |2 +-
>>  drivers/media/dvb/frontends/dib8000.c   |4 +-
>>  drivers/media/dvb/frontends/dib9000.c   |4 +-
>>  drivers/media/dvb/frontends/drxd_hard.c |2 +-
>>  drivers/media/dvb/frontends/drxk_hard.c |4 +-
>>  drivers/media/dvb/frontends/dvb_dummy_fe.c  |6 +-
>>  drivers/media/dvb/frontends/it913x-fe.c |2 +-
>>  drivers/media/dvb/frontends/l64781.c|2 +-
>>  drivers/media/dvb/frontends/lgdt3305.c  |4 +-
>>  drivers/media/dvb/frontends/lgdt330x.c  |4 +-
>>  drivers/media/dvb/frontends/lgs8gl5.c   |2 +-
>>  drivers/media/dvb/frontends/lgs8gxx.c   |2 +-
>>  drivers/media/dvb/frontends/mb86a20s.c  |2 +-
>>  drivers/media/dvb/frontends/mt312.c |2 +-
>>  drivers/media/dvb/frontends/mt352.c |2 +-
>>  drivers/media/dvb/frontends/or51132.c   |2 +-
>>  drivers/media/dvb/frontends/s5h1409.c   |2 +-
>>  drivers/media/dvb/frontends/s5h1411.c   |2 +-
>>  drivers/media/dvb/frontends/s5h1420.c   |2 +-
>>  drivers/media/dvb/frontends/s5h1432.c   |2 +-
>>  drivers/media/dvb/frontends/s921.c  |2 +-
>>  drivers/media/dvb/frontends/stb0899_drv.c   |2 +-
>>  drivers/media/dvb/frontends/stb6100.c   |4 +-
>>  drivers/media/dvb/frontends/stv0297.c   |2 +-
>>  drivers/media/dvb/frontends/stv0299.c   |2 +-
>>  drivers/media/dvb/frontends/stv0367.c   |4 +-
>>  drivers/media/dvb/frontends/stv0900_core.c  |2 +-
>>  drivers/media/dvb/frontends/tda10021.c  |2 +-
>>  drivers/media/dvb/frontends/tda10023.c  |2 +-
>>  drivers/media/dvb/frontends/tda10048.c  |2 +-
>>  drivers/media/dvb/frontends/tda1004x.c  |4 +-
>>  drivers/media/dvb/frontends/tda10071.c  |2 +-
>>  drivers/media/dvb/frontends/tda10086.c  |2 +-
>>  drivers/media/dvb/frontends/tda8083.c   |2 +-
>>  drivers/media/dvb/frontends/ves1820.c   |2 +-
>>  drivers/media/dvb/frontends/ves1x93.c   |2 +-
>>  drivers/media/dvb/frontends/zl10353.c   |2 +-
>>  drivers/media/dvb/siano/smsdvb.c|2 +-
>>  drivers/media/video/tlg2300/pd-dvb.c|2 +-
>>  drivers/staging/media/as102/as102_fe.c  |2 +-
>>  62 files changed, 157 insertions(+), 100 deletions(-)
>>
>> diff --git a/drivers/media/dvb/bt8xx/dst.c b/drivers/media/dvb/bt8xx/dst.c
>> index 4658bd6..6afc083 100644
>> --- a/drivers/media/dvb/bt8xx/dst.c
>> +++ b/drivers/media/dvb/bt8xx/dst.c
>> @@ -1778,7 +1778,7 @@ static struct dvb_frontend_ops dst_dvbt_ops = {
>>  .init = dst_init,
>>  .tune = dst_tune_frontend,
>>  .set_frontend_legacy = dst_set_frontend,
>> -.get_frontend = dst_get_frontend,
>> +.get_frontend_legacy = dst_get_frontend,
>>  .get_frontend_algo = dst_get_tuning_algo,
>>  .read_status = dst_read_status,
>>  .read_signal_strength = dst_read_signal_strength,
>> @@ -1804,7 +1804,7 @@ static struct dvb_frontend_ops dst_dvbs_ops = {
>>  .init = dst_init,
>>  .tune = dst_tune_frontend,
>>  .set_frontend_legacy = dst_set_frontend,
>> -.get_frontend = dst_get_frontend,
>> +.get_frontend_legacy = dst_get_frontend,
>>  .get_frontend_algo = dst_get_tuning_algo,
>>  .read_status = dst_read_status,
>>  .read_signal_strength = dst_read_signal_strength,
>> @@ -1838,7 +1838,7 @@ static st

Re: [PATCH RFC 01/91] [media] dvb-core: allow demods to specify the supported delivery systems supported standards.

[Mauro Carvalho Chehab]

On 27-12-2011 10:11, Andreas Oberritter wrote:
> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
>> DVB-S and DVB-T, as those were the standards supported by DVBv3.
> 
> The description seems to be incomplete.
> 
>> New standards like DSS, ISDB and CTTB don't fit on any of the
>> above types.
>>
>> while there's a way for the drivers to explicitly change whatever
>> default DELSYS were filled inside the core, still a fake value is
>> needed there, and a "compat" code to allow DVBv3 applications to
>> work with those delivery systems is needed. This is good for a
>> short term solution, while applications aren't using DVBv5 directly.
>>
>> However, at long term, this is bad, as the compat code runs even
>> if the application is using DVBv5. Also, the compat code is not
>> perfect, and only works when the frontend is capable of auto-detecting
>> the parameters that aren't visible by the faked delivery systems.
>>
>> So, let the frontend fill the supported delivery systems at the
>> device properties directly, and, in the future, let the core to use
>> the delsys to fill the reported info::type based on the delsys.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>> ---
>>  drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
>>  drivers/media/dvb/dvb-core/dvb_frontend.h |8 
>>  2 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
>> b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> index 8dedff4..f17c411 100644
>> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
>> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> @@ -1252,6 +1252,19 @@ static void dtv_set_default_delivery_caps(const 
>> struct dvb_frontend *fe, struct
>>  const struct dvb_frontend_info *info = &fe->ops.info;
>>  u32 ncaps = 0;
>>  
>> +/*
>> + * If the frontend explicitly sets a list, use it, instead of
>> + * filling based on the info->type
>> + */
>> +if (fe->ops.delsys[ncaps]) {
>> +while (fe->ops.delsys[ncaps] && ncaps < MAX_DELSYS) {
>> +p->u.buffer.data[ncaps] = fe->ops.delsys[ncaps];
>> +ncaps++;
>> +}
>> +p->u.buffer.len = ncaps;
>> +return;
>> +}
>> +
> 
> I don't understand what this is trying to solve. This is already handled
> by the get_property driver callback.
> 
> dtv_set_default_delivery_caps() only sets some defaults for drivers not
> implementing get_property yet.

dtv_set_default_delivery_caps() does the wrong thing for delivery systems
like ISDB-T, ISDB-S, DSS, DMB-TH, as it fills data with a fake value that
is there at fe->ops.info.type. 

The fake values there should be used only for DVBv3 legacy calls emulation
on those delivery systems that are not fully compatible with a DVBv3 call.

At the end, I think we should deprecate the fe->ops.info.type, as its
contents is not reliable (as it can represent something else). 

Btw, there are several places at dvb_frontend.c that uses the info.type
to assume the delivery system. This leads DVB core to do the wrong assumptions
for non-DVBv3 supported systems. The right way is to use a new field that
really represents the supported delivery systems by a given frontend, instead
of relying on fe->ops.info.type.


> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/91] Only use DVBv5 internally on frontend drivers

[Mauro Carvalho Chehab]

On 27-12-2011 10:31, Andreas Oberritter wrote:
> On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
>> Mauro Carvalho Chehab (91):
> 
> It would be nice if you could send each message as a reply to the cover
> letter next time, instead of sending message x as a reply to message x-1.
> 
> Otherwise, one needs a very wide screen to display all messages in a
> threaded view. I stopped reading around message 50.

This is the way git mail-send does, at least by default. Maybe there's an
option for it to change the way threads are shown. I'll seek if is there
any way to change it.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/91] Only use DVBv5 internally on frontend drivers

[Andreas Oberritter]

On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
> Mauro Carvalho Chehab (91):

It would be nice if you could send each message as a reply to the cover
letter next time, instead of sending message x as a reply to message x-1.

Otherwise, one needs a very wide screen to display all messages in a
threaded view. I stopped reading around message 50.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 24/91] [media] em28xx-dvb: don't initialize drx-d non-used fields with zero

[Andreas Oberritter]

On 27.12.2011 02:08, Mauro Carvalho Chehab wrote:
> There's no need to initialize unused fields with zero, as Kernel does
> it automatically. Don't do that, in order to save some space at the
> data segment.

No space is saved for members of a struct, unless the complete struct is
initialized to zero.

Anyway, it improves readability.

> This also allows the removal of the unused pll_set callback.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/video/em28xx/em28xx-dvb.c |   10 ++
>  1 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/video/em28xx/em28xx-dvb.c 
> b/drivers/media/video/em28xx/em28xx-dvb.c
> index 3868c1e..28be043 100644
> --- a/drivers/media/video/em28xx/em28xx-dvb.c
> +++ b/drivers/media/video/em28xx/em28xx-dvb.c
> @@ -302,10 +302,12 @@ static struct zl10353_config 
> em28xx_zl10353_xc3028_no_i2c_gate = {
>  };
>  
>  static struct drxd_config em28xx_drxd = {
> - .index = 0, .demod_address = 0x70, .demod_revision = 0xa2,
> - .demoda_address = 0x00, .pll_address = 0x00,
> - .pll_type = DRXD_PLL_NONE, .clock = 12000, .insert_rs_byte = 1,
> - .pll_set = NULL, .osc_deviation = NULL, .IF = 4280,
> + .demod_address = 0x70,
> + .demod_revision = 0xa2,
> + .pll_type = DRXD_PLL_NONE,
> + .clock = 12000,
> + .insert_rs_byte = 1,
> + .IF = 4280,
>   .disable_i2c_gate_ctrl = 1,
>  };
>  

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 03/91] [media] dvb-core: add support for a DVBv5 get_frontend() callback

[Andreas Oberritter]

On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
> The old method is renamed to get_frontend_legacy(), while not all
> frontends are converted.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/dvb/bt8xx/dst.c   |8 +-
>  drivers/media/dvb/dvb-core/dvb_frontend.c   |  102 --
>  drivers/media/dvb/dvb-core/dvb_frontend.h   |5 +-
>  drivers/media/dvb/dvb-usb/af9005-fe.c   |4 +-
>  drivers/media/dvb/dvb-usb/cinergyT2-fe.c|2 +-
>  drivers/media/dvb/dvb-usb/dtt200u-fe.c  |2 +-
>  drivers/media/dvb/dvb-usb/friio-fe.c|2 +-
>  drivers/media/dvb/dvb-usb/mxl111sf-demod.c  |2 +-
>  drivers/media/dvb/dvb-usb/vp702x-fe.c   |2 +-
>  drivers/media/dvb/dvb-usb/vp7045-fe.c   |2 +-
>  drivers/media/dvb/firewire/firedtv-fe.c |2 +-
>  drivers/media/dvb/frontends/af9013.c|2 +-
>  drivers/media/dvb/frontends/atbm8830.c  |2 +-
>  drivers/media/dvb/frontends/au8522_dig.c|2 +-
>  drivers/media/dvb/frontends/cx22700.c   |2 +-
>  drivers/media/dvb/frontends/cx22702.c   |2 +-
>  drivers/media/dvb/frontends/cx24110.c   |2 +-
>  drivers/media/dvb/frontends/cx24123.c   |2 +-
>  drivers/media/dvb/frontends/cxd2820r_core.c |4 +-
>  drivers/media/dvb/frontends/dib3000mb.c |2 +-
>  drivers/media/dvb/frontends/dib3000mc.c |2 +-
>  drivers/media/dvb/frontends/dib7000m.c  |2 +-
>  drivers/media/dvb/frontends/dib7000p.c  |2 +-
>  drivers/media/dvb/frontends/dib8000.c   |4 +-
>  drivers/media/dvb/frontends/dib9000.c   |4 +-
>  drivers/media/dvb/frontends/drxd_hard.c |2 +-
>  drivers/media/dvb/frontends/drxk_hard.c |4 +-
>  drivers/media/dvb/frontends/dvb_dummy_fe.c  |6 +-
>  drivers/media/dvb/frontends/it913x-fe.c |2 +-
>  drivers/media/dvb/frontends/l64781.c|2 +-
>  drivers/media/dvb/frontends/lgdt3305.c  |4 +-
>  drivers/media/dvb/frontends/lgdt330x.c  |4 +-
>  drivers/media/dvb/frontends/lgs8gl5.c   |2 +-
>  drivers/media/dvb/frontends/lgs8gxx.c   |2 +-
>  drivers/media/dvb/frontends/mb86a20s.c  |2 +-
>  drivers/media/dvb/frontends/mt312.c |2 +-
>  drivers/media/dvb/frontends/mt352.c |2 +-
>  drivers/media/dvb/frontends/or51132.c   |2 +-
>  drivers/media/dvb/frontends/s5h1409.c   |2 +-
>  drivers/media/dvb/frontends/s5h1411.c   |2 +-
>  drivers/media/dvb/frontends/s5h1420.c   |2 +-
>  drivers/media/dvb/frontends/s5h1432.c   |2 +-
>  drivers/media/dvb/frontends/s921.c  |2 +-
>  drivers/media/dvb/frontends/stb0899_drv.c   |2 +-
>  drivers/media/dvb/frontends/stb6100.c   |4 +-
>  drivers/media/dvb/frontends/stv0297.c   |2 +-
>  drivers/media/dvb/frontends/stv0299.c   |2 +-
>  drivers/media/dvb/frontends/stv0367.c   |4 +-
>  drivers/media/dvb/frontends/stv0900_core.c  |2 +-
>  drivers/media/dvb/frontends/tda10021.c  |2 +-
>  drivers/media/dvb/frontends/tda10023.c  |2 +-
>  drivers/media/dvb/frontends/tda10048.c  |2 +-
>  drivers/media/dvb/frontends/tda1004x.c  |4 +-
>  drivers/media/dvb/frontends/tda10071.c  |2 +-
>  drivers/media/dvb/frontends/tda10086.c  |2 +-
>  drivers/media/dvb/frontends/tda8083.c   |2 +-
>  drivers/media/dvb/frontends/ves1820.c   |2 +-
>  drivers/media/dvb/frontends/ves1x93.c   |2 +-
>  drivers/media/dvb/frontends/zl10353.c   |2 +-
>  drivers/media/dvb/siano/smsdvb.c|2 +-
>  drivers/media/video/tlg2300/pd-dvb.c|2 +-
>  drivers/staging/media/as102/as102_fe.c  |2 +-
>  62 files changed, 157 insertions(+), 100 deletions(-)
> 
> diff --git a/drivers/media/dvb/bt8xx/dst.c b/drivers/media/dvb/bt8xx/dst.c
> index 4658bd6..6afc083 100644
> --- a/drivers/media/dvb/bt8xx/dst.c
> +++ b/drivers/media/dvb/bt8xx/dst.c
> @@ -1778,7 +1778,7 @@ static struct dvb_frontend_ops dst_dvbt_ops = {
>   .init = dst_init,
>   .tune = dst_tune_frontend,
>   .set_frontend_legacy = dst_set_frontend,
> - .get_frontend = dst_get_frontend,
> + .get_frontend_legacy = dst_get_frontend,
>   .get_frontend_algo = dst_get_tuning_algo,
>   .read_status = dst_read_status,
>   .read_signal_strength = dst_read_signal_strength,
> @@ -1804,7 +1804,7 @@ static struct dvb_frontend_ops dst_dvbs_ops = {
>   .init = dst_init,
>   .tune = dst_tune_frontend,
>   .set_frontend_legacy = dst_set_frontend,
> - .get_frontend = dst_get_frontend,
> + .get_frontend_legacy = dst_get_frontend,
>   .get_frontend_algo = dst_get_tuning_algo,
>   .read_status = dst_read_status,
>   .read_signal_strength = dst_read_signal_strength,
> @@ -1838,7 +1838,7 @@ static struct dvb_frontend_ops dst_dvbc_ops = {
>   .init = dst_init,
>   .tune = dst_tune_frontend,
>   .set_frontend_legac

Re: [PATCH RFC 01/91] [media] dvb-core: allow demods to specify the supported delivery systems supported standards.

[Andreas Oberritter]

On 27.12.2011 02:07, Mauro Carvalho Chehab wrote:
> DVB-S and DVB-T, as those were the standards supported by DVBv3.

The description seems to be incomplete.

> New standards like DSS, ISDB and CTTB don't fit on any of the
> above types.
> 
> while there's a way for the drivers to explicitly change whatever
> default DELSYS were filled inside the core, still a fake value is
> needed there, and a "compat" code to allow DVBv3 applications to
> work with those delivery systems is needed. This is good for a
> short term solution, while applications aren't using DVBv5 directly.
> 
> However, at long term, this is bad, as the compat code runs even
> if the application is using DVBv5. Also, the compat code is not
> perfect, and only works when the frontend is capable of auto-detecting
> the parameters that aren't visible by the faked delivery systems.
> 
> So, let the frontend fill the supported delivery systems at the
> device properties directly, and, in the future, let the core to use
> the delsys to fill the reported info::type based on the delsys.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
>  drivers/media/dvb/dvb-core/dvb_frontend.h |8 
>  2 files changed, 21 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb/dvb-core/dvb_frontend.c
> index 8dedff4..f17c411 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
> @@ -1252,6 +1252,19 @@ static void dtv_set_default_delivery_caps(const struct 
> dvb_frontend *fe, struct
>   const struct dvb_frontend_info *info = &fe->ops.info;
>   u32 ncaps = 0;
>  
> + /*
> +  * If the frontend explicitly sets a list, use it, instead of
> +  * filling based on the info->type
> +  */
> + if (fe->ops.delsys[ncaps]) {
> + while (fe->ops.delsys[ncaps] && ncaps < MAX_DELSYS) {
> + p->u.buffer.data[ncaps] = fe->ops.delsys[ncaps];
> + ncaps++;
> + }
> + p->u.buffer.len = ncaps;
> + return;
> + }
> +

I don't understand what this is trying to solve. This is already handled
by the get_property driver callback.

dtv_set_default_delivery_caps() only sets some defaults for drivers not
implementing get_property yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 04/91] [media] af9013: convert set_fontend to use DVBv5 parameters

[Mauro Carvalho Chehab]

On 27-12-2011 08:28, Antti Palosaari wrote:
> Hello
> basically I am done all these changes when rewrote whole af9013 driver. Fist 
> PULL request is sent one month ago and I resend it last week. Could you apply 
> that first?

I'll apply the pending pull requests before those series and rebase what's 
needed. 
As it is written there, this is a RFC ;)

I should be handling the pending stuff later this week.

> 
> Antti
> 
> On 12/27/2011 03:07 AM, Mauro Carvalho Chehab wrote:
>> Instead of using dvb_frontend_parameters struct, that were
>> designed for a subset of the supported standards, use the DVBv5
>> cache information.
>>
>> Also, fill the supported delivery systems at dvb_frontend_ops
>> struct.
>>
>> Signed-off-by: Mauro Carvalho Chehab
>> ---
>>   drivers/media/dvb/frontends/af9013.c  |  110 
>> +++--
>>   drivers/media/dvb/frontends/af9013_priv.h |   24 +++---
>>   2 files changed, 68 insertions(+), 66 deletions(-)
>>
>> diff --git a/drivers/media/dvb/frontends/af9013.c 
>> b/drivers/media/dvb/frontends/af9013.c
>> index 540ed0f..08a0364 100644
>> --- a/drivers/media/dvb/frontends/af9013.c
>> +++ b/drivers/media/dvb/frontends/af9013.c
>> @@ -365,9 +365,10 @@ error:
>>   return ret;
>>   }
>>
>> -static int af9013_set_ofdm_params(struct af9013_state *state,
>> -struct dvb_ofdm_parameters *params, u8 *auto_mode)
>> +static int af9013_set_ofdm_params(struct dvb_frontend *fe, u8 *auto_mode)
>>   {
>> +struct dtv_frontend_properties *c =&fe->dtv_property_cache;
>> +struct af9013_state *state = fe->demodulator_priv;
>>   int ret;
>>   u8 i, buf[3] = {0, 0, 0};
>>   *auto_mode = 0; /* set if parameters are requested to auto set */
>> @@ -376,7 +377,7 @@ static int af9013_set_ofdm_params(struct af9013_state 
>> *state,
>>  garbage parameters given by application for compatibility.
>>  MPlayer seems to provide garbage parameters currently. */
>>
>> -switch (params->transmission_mode) {
>> +switch (c->transmission_mode) {
>>   case TRANSMISSION_MODE_AUTO:
>>   *auto_mode = 1;
>>   case TRANSMISSION_MODE_2K:
>> @@ -389,7 +390,7 @@ static int af9013_set_ofdm_params(struct af9013_state 
>> *state,
>>   *auto_mode = 1;
>>   }
>>
>> -switch (params->guard_interval) {
>> +switch (c->guard_interval) {
>>   case GUARD_INTERVAL_AUTO:
>>   *auto_mode = 1;
>>   case GUARD_INTERVAL_1_32:
>> @@ -408,7 +409,7 @@ static int af9013_set_ofdm_params(struct af9013_state 
>> *state,
>>   *auto_mode = 1;
>>   }
>>
>> -switch (params->hierarchy_information) {
>> +switch (c->hierarchy) {
>>   case HIERARCHY_AUTO:
>>   *auto_mode = 1;
>>   case HIERARCHY_NONE:
>> @@ -423,11 +424,11 @@ static int af9013_set_ofdm_params(struct af9013_state 
>> *state,
>>   buf[0] |= (3<<  4);
>>   break;
>>   default:
>> -deb_info("%s: invalid hierarchy_information\n", __func__);
>> +deb_info("%s: invalid hierarchy\n", __func__);
>>   *auto_mode = 1;
>>   };
>>
>> -switch (params->constellation) {
>> +switch (c->modulation) {
>>   case QAM_AUTO:
>>   *auto_mode = 1;
>>   case QPSK:
>> @@ -439,14 +440,14 @@ static int af9013_set_ofdm_params(struct af9013_state 
>> *state,
>>   buf[1] |= (2<<  6);
>>   break;
>>   default:
>> -deb_info("%s: invalid constellation\n", __func__);
>> +deb_info("%s: invalid modulation\n", __func__);
>>   *auto_mode = 1;
>>   }
>>
>>   /* Use HP. How and which case we can switch to LP? */
>>   buf[1] |= (1<<  4);
>>
>> -switch (params->code_rate_HP) {
>> +switch (c->code_rate_HP) {
>>   case FEC_AUTO:
>>   *auto_mode = 1;
>>   case FEC_1_2:
>> @@ -468,11 +469,11 @@ static int af9013_set_ofdm_params(struct af9013_state 
>> *state,
>>   *auto_mode = 1;
>>   }
>>
>> -switch (params->code_rate_LP) {
>> +switch (c->code_rate_LP) {
>>   case FEC_AUTO:
>>   /* if HIERARCHY_NONE and FEC_NONE then LP FEC is set to FEC_AUTO
>>  by dvb_frontend.c for compatibility */
>> -if (params->hierarchy_information != HIERARCHY_NONE)
>> +if (c->hierarchy != HIERARCHY_NONE)
>>   *auto_mode = 1;
>>   case FEC_1_2:
>>   break;
>> @@ -489,20 +490,20 @@ static int af9013_set_ofdm_params(struct af9013_state 
>> *state,
>>   buf[2] |= (4<<  3);
>>   break;
>>   case FEC_NONE:
>> -if (params->hierarchy_information == HIERARCHY_AUTO)
>> +if (c->hierarchy == HIERARCHY_AUTO)
>>   break;
>>   default:
>>   deb_info("%s: invalid code_rate_LP\n", __func__);
>>   *auto_mode = 1;
>>   }
>>
>> -switch (params->bandwidth) {
>> -case BANDWIDTH_6_MHZ:
>> +switch (c->bandwidth_hz) {
>> +case 600:
>>   break;
>> -case BANDWIDTH_7_MHZ:
>> +case 700:
>>   buf[1] 

ISDB-T channels in Brazil - for Kaffeine

[Mauro Carvalho Chehab]

Hi Christoph,

On the last tests I did with Kaffeine, it is now working properly
with Brazil's video/audio codecs (mpeg4/AAC). So, it makes sense
to add a channel list for it.

At least on the Kaffeine version I have here, it seems to be using
a DVBv3 frontend call, so it appears as if it is a DVB-T, instead
of ISDB-T. Anyway, the table bellow should work for all channels
currently defined by the Brazilian telecommunications agency.

The channel list corresponds to channels 7 to 83. The channel 37
(frequency 611142857) is not used here. I suspect that this frequency
is used by something else in Brazil.

Channels 7 to 13 (the ones at VHF range) will only be available to
broadcasters after the end of analog transmissions (it is scheduled
to happen in 2016). Yet, I added it at the table, to match the
Brazilian standards spec.

Anyway, the same channel list is used in Japan, but I've no idea if 
channel 37 is allowed there.

Please add the enclosed table to kaffeine scanfile.dvb file.

Thanks and Happy Seasons!
Mauro

---

[dvb-t/br-All]
T 177142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 183142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 189142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 195142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 201142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 207142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 213142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 473142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 479142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 485142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 491142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 497142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 503142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 509142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 515142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 521142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 527142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 533142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 539142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 545142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 551142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 557142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 563142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 569142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 575142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 581142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 587142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 593142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 599142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 605142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 617142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 623142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 629142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 635142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 641142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 647142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 653142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 659142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 665142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 671142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 677142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 683142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 689142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 695142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 701142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 707142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 713142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 719142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 725142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 731142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 737142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 743142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 749142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 755142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 761142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 767142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 773142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 779142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 785142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 791142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 797142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE
T 803142857 6MHz AUTO AUTO AUTO AUTO AUTO NONE

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DVB-S2 multistream support

[Christian Prähauser]

> 
> Yes, I'm meaning something like what it was described there. I think
> that the code written by Christian were never submitted upstream.
> 

Hello Mauro,

Konstantin drew my attention to this discussion. Indeed, some time ago I wrote 
a base-band demux for LinuxDVB. It was part of a project to integrate support 
for second-generation IP/DVB encapsulations (GSE). The BB-demux allows to
register filters for different ISIs and data types (raw, generic stream,
transport stream).

I realized that the repo hosted at our University is down. If there is interest,
I can update my patches to the latest LinuxDVB version and we can put them on a 
public repo e.g. at linuxdvb.org.

Kind regards,
Christian.
 





--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 04/91] [media] af9013: convert set_fontend to use DVBv5 parameters

[Antti Palosaari]

Hello
basically I am done all these changes when rewrote whole af9013 driver. 
Fist PULL request is sent one month ago and I resend it last week. Could 
you apply that first?


Antti

On 12/27/2011 03:07 AM, Mauro Carvalho Chehab wrote:

Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.

Also, fill the supported delivery systems at dvb_frontend_ops
struct.

Signed-off-by: Mauro Carvalho Chehab
---
  drivers/media/dvb/frontends/af9013.c  |  110 +++--
  drivers/media/dvb/frontends/af9013_priv.h |   24 +++---
  2 files changed, 68 insertions(+), 66 deletions(-)

diff --git a/drivers/media/dvb/frontends/af9013.c 
b/drivers/media/dvb/frontends/af9013.c
index 540ed0f..08a0364 100644
--- a/drivers/media/dvb/frontends/af9013.c
+++ b/drivers/media/dvb/frontends/af9013.c
@@ -365,9 +365,10 @@ error:
return ret;
  }

-static int af9013_set_ofdm_params(struct af9013_state *state,
-   struct dvb_ofdm_parameters *params, u8 *auto_mode)
+static int af9013_set_ofdm_params(struct dvb_frontend *fe, u8 *auto_mode)
  {
+   struct dtv_frontend_properties *c =&fe->dtv_property_cache;
+   struct af9013_state *state = fe->demodulator_priv;
int ret;
u8 i, buf[3] = {0, 0, 0};
*auto_mode = 0; /* set if parameters are requested to auto set */
@@ -376,7 +377,7 @@ static int af9013_set_ofdm_params(struct af9013_state 
*state,
   garbage parameters given by application for compatibility.
   MPlayer seems to provide garbage parameters currently. */

-   switch (params->transmission_mode) {
+   switch (c->transmission_mode) {
case TRANSMISSION_MODE_AUTO:
*auto_mode = 1;
case TRANSMISSION_MODE_2K:
@@ -389,7 +390,7 @@ static int af9013_set_ofdm_params(struct af9013_state 
*state,
*auto_mode = 1;
}

-   switch (params->guard_interval) {
+   switch (c->guard_interval) {
case GUARD_INTERVAL_AUTO:
*auto_mode = 1;
case GUARD_INTERVAL_1_32:
@@ -408,7 +409,7 @@ static int af9013_set_ofdm_params(struct af9013_state 
*state,
*auto_mode = 1;
}

-   switch (params->hierarchy_information) {
+   switch (c->hierarchy) {
case HIERARCHY_AUTO:
*auto_mode = 1;
case HIERARCHY_NONE:
@@ -423,11 +424,11 @@ static int af9013_set_ofdm_params(struct af9013_state 
*state,
buf[0] |= (3<<  4);
break;
default:
-   deb_info("%s: invalid hierarchy_information\n", __func__);
+   deb_info("%s: invalid hierarchy\n", __func__);
*auto_mode = 1;
};

-   switch (params->constellation) {
+   switch (c->modulation) {
case QAM_AUTO:
*auto_mode = 1;
case QPSK:
@@ -439,14 +440,14 @@ static int af9013_set_ofdm_params(struct af9013_state 
*state,
buf[1] |= (2<<  6);
break;
default:
-   deb_info("%s: invalid constellation\n", __func__);
+   deb_info("%s: invalid modulation\n", __func__);
*auto_mode = 1;
}

/* Use HP. How and which case we can switch to LP? */
buf[1] |= (1<<  4);

-   switch (params->code_rate_HP) {
+   switch (c->code_rate_HP) {
case FEC_AUTO:
*auto_mode = 1;
case FEC_1_2:
@@ -468,11 +469,11 @@ static int af9013_set_ofdm_params(struct af9013_state 
*state,
*auto_mode = 1;
}

-   switch (params->code_rate_LP) {
+   switch (c->code_rate_LP) {
case FEC_AUTO:
/* if HIERARCHY_NONE and FEC_NONE then LP FEC is set to FEC_AUTO
   by dvb_frontend.c for compatibility */
-   if (params->hierarchy_information != HIERARCHY_NONE)
+   if (c->hierarchy != HIERARCHY_NONE)
*auto_mode = 1;
case FEC_1_2:
break;
@@ -489,20 +490,20 @@ static int af9013_set_ofdm_params(struct af9013_state 
*state,
buf[2] |= (4<<  3);
break;
case FEC_NONE:
-   if (params->hierarchy_information == HIERARCHY_AUTO)
+   if (c->hierarchy == HIERARCHY_AUTO)
break;
default:
deb_info("%s: invalid code_rate_LP\n", __func__);
*auto_mode = 1;
}

-   switch (params->bandwidth) {
-   case BANDWIDTH_6_MHZ:
+   switch (c->bandwidth_hz) {
+   case 600:
break;
-   case BANDWIDTH_7_MHZ:
+   case 700:
buf[1] |= (1<<  2);
break;
-   case BANDWIDTH_8_MHZ:
+   case 800:
buf[1] |= (2<<  2);
break;
default:
@@ -594,24 +595,24 @@ static int af9013_lock_led(struct af9013_state *state, u8 
onoff)
return af9013_write_reg_bits(state,

Hauppauge WinTV-HVR900 hybrid TV usb stick

[barry malcolm]

LinuxMint 12 64bit, Kernel 3.0.0-12, does not load this USB stick
 -- part of dmesg output is attached.

When I used kernel 3.0.0-0300 with Ubuntu 11.04 the Micronas DRXD DVB-T 
tuner in this stick was identified and firmware loaded.
I've tried manually placing the 3 bits of firmware in /lib/firmware 
(xc3028-v27.fw, drxd-a2-1.1.fw, drxd-b1-1.1.fw) but with no success.
I've also tried creating a file HVR900.conf in /etc/modprobe.d/ 
containing the line

options EM28xx card=18   (or  card=10) again with no effect.

Regards
Barry

PS My hardware setup is:
Gigabyte GA-Z68MA-D2H-B3 mobo with Intel i5 2500K, 8GB Kingston HyperX 
in Antec 3480 case.
[2.635401] usb 2-1.2: new high speed USB device number 3 using ehci_hcd
[3.002191] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[   12.885895] udevd[394]: starting version 173
[   12.994588] Adding 6072532k swap on /dev/sda5.  Priority:-1 extents:1 
across:6072532k 
[   13.382574] Linux video capture interface: v2.00
[   13.407005] em28xx: New device @ 480 Mbps (eb1a:2883, interface 0, class 0)
[   13.407113] em28xx #0: chip ID is em2882/em2883
[   13.430318] wmi: Mapper loaded
[   13.453036] mei: module is from the staging directory, the quality is 
unknown, you have been warned.
[   13.453346] mei :00:16.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   13.453350] mei :00:16.0: setting latency timer to 64
[   13.487138] em28xx #0: i2c eeprom 00: 05 eb 67 95 40 20 02 65 d0 12 5c 03 82 
1e 6a 18
[   13.487151] em28xx #0: i2c eeprom 10: 00 00 24 57 66 07 01 00 00 00 00 00 00 
00 00 00
[   13.487161] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 
e0 00 00
[   13.487171] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 01 01 00 
00 00 00
[   13.487181] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[   13.487191] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[   13.487200] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 18 03 34 
00 30 00
[   13.487210] em28xx #0: i2c eeprom 70: 32 00 38 00 34 00 39 00 37 00 36 00 30 
00 31 00
[   13.487220] em28xx #0: i2c eeprom 80: 00 00 1e 03 57 00 69 00 6e 00 54 00 56 
00 20 00
[   13.487239] em28xx #0: i2c eeprom 90: 48 00 56 00 52 00 2d 00 39 00 30 00 30 
00 00 00
[   13.487243] em28xx #0: i2c eeprom a0: 84 12 00 00 05 50 1a 7f d4 78 23 fa fd 
d0 28 89
[   13.487248] em28xx #0: i2c eeprom b0: ff 00 00 00 04 84 0a 00 01 01 20 77 00 
40 c1 fe
[   13.487252] em28xx #0: i2c eeprom c0: 1d f0 74 02 01 00 01 79 6e 00 00 00 00 
00 00 00
[   13.487256] em28xx #0: i2c eeprom d0: 84 12 00 00 05 50 1a 7f d4 78 23 fa fd 
d0 28 89
[   13.487261] em28xx #0: i2c eeprom e0: ff 00 00 00 04 84 0a 00 01 01 20 77 00 
40 c1 fe
[   13.487266] em28xx #0: i2c eeprom f0: 1d f0 74 02 01 00 01 79 6e 00 00 00 00 
00 00 00
[   13.487270] em28xx #0: EEPROM ID= 0x9567eb05, EEPROM hash = 0x
[   13.487271] em28xx #0: EEPROM info:
[   13.487272] em28xx #0:   AC97 audio (5 sample rates)
[   13.487273] em28xx #0:   500mA max power
[   13.487274] em28xx #0:   Table at 0x24, strings=0x1e82, 0x186a, 0x
[   13.519347] em28xx #0: found i2c device @ 0xa0 [eeprom]
[   13.525713] em28xx #0: found i2c device @ 0xc2 [tuner (analog)]
[   13.535765] IR NEC protocol handler initialized
[   13.535860] lp: driver loaded but no devices found
[   13.537195] em28xx #0: Your board has no unique USB ID and thus need a hint 
to be detected.
[   13.537200] em28xx #0: You may try to use card= insmod option to 
workaround that.
[   13.537202] em28xx #0: Please send an email with this log to:
[   13.537204] em28xx #0:   V4L Mailing List 
[   13.537206] em28xx #0: Board eeprom hash is 0x
[   13.537208] em28xx #0: Board i2c devicelist hash is 0x6be10080
[   13.537209] em28xx #0: Here is a list of valid choices for the card= 
insmod option:
[   13.537212] em28xx #0: card=0 -> Unknown EM2800 video grabber
[   13.537214] em28xx #0: card=1 -> Unknown EM2750/28xx video grabber
[   13.537216] em28xx #0: card=2 -> Terratec Cinergy 250 USB
[   13.537218] em28xx #0: card=3 -> Pinnacle PCTV USB 2
[   13.537220] em28xx #0: card=4 -> Hauppauge WinTV USB 2
[   13.537222] em28xx #0: card=5 -> MSI VOX USB 2.0
[   13.537224] em28xx #0: card=6 -> Terratec Cinergy 200 USB
[   13.537225] em28xx #0: card=7 -> Leadtek Winfast USB II
[   13.537227] em28xx #0: card=8 -> Kworld USB2800
[   13.537229] em28xx #0: card=9 -> Pinnacle Dazzle DVC 90/100/101/107 / 
Kaiser Baas Video to DVD maker / Kworld DVD Maker 2
[   13.537232] em28xx #0: card=10 -> Hauppauge WinTV HVR 900
[   13.537234] em28xx #0: card=11 -> Terratec Hybrid XS
[   13.537236] em28xx #0: card=12 -> Kworld PVR TV 2800 RF
[   13.537238] em28xx #0: card=13 -> Terratec Prodigy XS
[   13.537240] em28xx #0: card=14 -> SIIG AVTuner-PVR / Pixelview Prolink 
PlayTV USB 2.0
[   13.537243] em28xx #0: card=15 -> V-Gear PocketTV
[   13.