Re: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran Microelectronics, Ltd Digital Camera EX-20 DSC
On 05/27/2014 03:34 AM, Richie wrote: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1322380 [1.] One line summary of the problem: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran Microelectronics, Ltd Digital Camera EX-20 DSC [2.] Full description of the problem/report: No software recognizes the webcam and this is not a regression. dmesg reports the following additional output after plugging the camera. You can see where I change the camera to PC Mode (in order to use the webcam, users must do this from the camera) at [ 691.147589]. The device is turned off at [ 1094.746444]: [ 688.796908] usb 4-2: new full-speed USB device number 2 using ohci-pci [ 688.965802] usb 4-2: New USB device found, idVendor=0595, idProduct=2002 [ 688.965807] usb 4-2: New USB device strings: Mfr=4, Product=5, SerialNumber=6 [ 688.965809] usb 4-2: Product: COACH DSC [ 688.965811] usb 4-2: Manufacturer: ZORAN [ 688.965813] usb 4-2: SerialNumber: ZORAN01234567 [ 689.012630] usb-storage 4-2:1.0: USB Mass Storage device detected [ 689.021168] scsi6 : usb-storage 4-2:1.0 [ 689.021266] usbcore: registered new interface driver usb-storage [ 690.030971] scsi 6:0:0:0: Direct-Access ZORAN COACH6 (I62) 1.10 PQ: 0 ANSI: 0 CCS [ 690.036147] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 690.044964] sd 6:0:0:0: [sdc] 3962629 512-byte logical blocks: (2.02 GB/1.88 GiB) [ 690.054977] sd 6:0:0:0: [sdc] Write Protect is off [ 690.054984] sd 6:0:0:0: [sdc] Mode Sense: 00 06 00 00 [ 690.064965] sd 6:0:0:0: [sdc] No Caching mode page found [ 690.064971] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 690.108960] sd 6:0:0:0: [sdc] No Caching mode page found [ 690.108966] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 690.156970] sdc: [ 690.210974] sd 6:0:0:0: [sdc] No Caching mode page found [ 690.210980] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 690.210985] sd 6:0:0:0: [sdc] Attached SCSI removable disk [ 691.147589] usb 4-2: USB disconnect, device number 2 [ 691.793364] usb 4-2: new full-speed USB device number 3 using ohci-pci [ 691.962202] usb 4-2: New USB device found, idVendor=0595, idProduct=4343 [ 691.962207] usb 4-2: New USB device strings: Mfr=7, Product=8, SerialNumber=9 [ 691.962209] usb 4-2: Product: COACH DSC [ 691.962211] usb 4-2: Manufacturer: ZORAN [ 691.962213] usb 4-2: SerialNumber: ZORAN0001 [ 691.964262] usb-storage 4-2:1.0: USB Mass Storage device detected [ 691.965410] usb-storage: probe of 4-2:1.0 failed with error -5 [ 692.053929] Linux video capture interface: v2.00 [ 692.091447] zr364xx 4-2:1.0: Zoran 364xx compatible webcam plugged [ 692.091453] zr364xx 4-2:1.0: model 0595:4343 detected [ 692.091461] usb 4-2: 320x240 mode selected [ 692.094356] usb 4-2: Zoran 364xx controlling device video0 Clearly the webcam is recognized and a /dev/video0 node is created. Please check that /dev/video0 exists. Try e.g. v4l2-ctl -D -d /dev/video0, it should list it as using the zr364xx driver. So what exactly doesn't work? Regards, Hans [ 692.094672] usbcore: registered new interface driver zr364xx [ 1094.746444] hub 4-0:1.0: port 2 disabled by hub (EMI?), re-enabling... [ 1094.746451] usb 4-2: USB disconnect, device number 3 [ 1094.747395] zr364xx 4-2:1.0: Zoran 364xx webcam unplugged -- 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] em28xx: add MSI Digivox Trio support
On 05/27/2014 02:04 AM, P. van Gaans wrote:
http://linuxtv.org/wiki/index.php/MSI_DigiVox_Trio
If you're having a deja-vu, yeah, it's still me. I'm still using this
device using my butt-ugly patch by adding:
{ USB_DEVICE(0xeb1a, 0x2885),/* MSI Digivox Trio */
.driver_info = EM2884_BOARD_TERRATEC_H5 },
to linux/drivers/media/usb/em28xx/em28xx-cards.c.
It's starting to bug me more and more that I can never update my kernel
(well not without hassle anyway). I've written this to the mailinglist
before, but with no response.
I just don't have the skill to write this in the neat way it needs to be
to be able to go upstream. Should I try to hire someone to do that? If
so, any suggestions? Just put an ad up on craigslist or something? Does
such a patch have a chance of going upstream? (as that's the whole point
- I want to update my kernel again)
It should be really straightforward given that no reverse engineering or
anything is needed. It's just what it states above - pretend the Digivox
is an H5 and it's done.
Anyone who can tune in on this, please share your thoughts.
I've made it into a proper patch, see below.
Can you reply with your 'Signed-off-by' line?
i.e.: Signed-off-by: John Doe john@foo.com
Since you're the author of the patch (I just formatted it), I need that to
get it upstream.
Regards,
Hans
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 15ad470..9da812b 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2280,6 +2280,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2820_BOARD_UNKNOWN },
{ USB_DEVICE(0xeb1a, 0x2875),
.driver_info = EM2820_BOARD_UNKNOWN },
+ { USB_DEVICE(0xeb1a, 0x2885), /* MSI Digivox Trio */
+ .driver_info = EM2884_BOARD_TERRATEC_H5 },
{ USB_DEVICE(0xeb1a, 0xe300),
.driver_info = EM2861_BOARD_KWORLD_PVRTV_300U },
{ USB_DEVICE(0xeb1a, 0xe303),
--
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 0/2] Propert alpha channel support in pixel formats
On 05/27/2014 12:17 AM, Laurent Pinchart wrote: Hello, This RFC patch series attempts to clean up the current ARGB format mess. The core issue is that the existing ARGB formats are ill-defined. The V4L2 specification doesn't clearly document how the alpha bits should behave. Drivers have thus used the same formats in different, incompatible ways, and applications now rely on the driver-specific behaviours. In a word, that's a mess. I've discussed the issue in the #v4l channel a couple of days ago and we came up to the conclusion that the best (or least painful) way to fix the problem is to define new clean XRGB and ARGB formats, and consider the existing formats as deprecated (meaning that no new driver should use them, they won't disappear in a couple of months, as that would break userspace). The first patch adds the new XRGB and ARGB formats and documents them. Question: should we add all XRGB and ARGB formats even if drivers do not use them? Or just those that are actually used? It purposely includes no core code to handle backward compatibility for existing drivers that may wish to move to the new formats. The reason is that I would first like to get feedback on the proposal before working on compat code, and I believe we should first implement the compat code in a couple of drivers and then see how the approach could be generalized, if possible at all. The second patch allows using the ALPHA_COMPONENT control on output devices to support an ARGB use case documented in the first patch. One possible shortcoming of reusing the existing control is that a mem-to-mem driver that exposes an output and a capture queue on a single video node through the same file handle wouldn't be able to set different alpha component values on the two queues. I'm not sure whether that use case is real though, it seems weird to me to set a fixed alpha value on one side to request a different fixed alpha value on the other side. I prefer a CAP_ALPHA_COMPONENT control. It's easy to add a capture-specific control now, it's much harder to change it in the future. Regards, Hans Laurent Pinchart (2): v4l: Add ARGB and XRGB pixel formats DocBook: media: Document ALPHA_COMPONENT control usage on output devices Documentation/DocBook/media/v4l/controls.xml | 17 +- .../DocBook/media/v4l/pixfmt-packed-rgb.xml| 415 - include/uapi/linux/videodev2.h | 8 + 3 files changed, 413 insertions(+), 27 deletions(-) -- 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/2] media: mx2-emmaprp: Add DT bindings documentation
This patch adds DT binding documentation for the Freescale enhanced
Multimedia Accelerator (eMMA) video Pre-processor (PrP).
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
.../devicetree/bindings/media/fsl-imx-emmaprp.txt| 20
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/fsl-imx-emmaprp.txt
diff --git a/Documentation/devicetree/bindings/media/fsl-imx-emmaprp.txt
b/Documentation/devicetree/bindings/media/fsl-imx-emmaprp.txt
new file mode 100644
index 000..d78b1b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl-imx-emmaprp.txt
@@ -0,0 +1,20 @@
+* Freescale enhanced Multimedia Accelerator (eMMA) video Pre-processor (PrP)
+ for i.MX21 i.MX27 SoCs.
+
+Required properties:
+- compatible : Shall contain fsl,imx21-emmaprp for compatible with
+ the one integrated on i.MX21 SoC.
+- reg: Offset and length of the register set for the device.
+- interrupts : Should contain eMMA PrP interrupt number.
+- clocks : Should contain the ahb and ipg clocks, in the order
+ determined by the clock-names property.
+- clock-names: Should be ahb, ipg.
+
+Example:
+ emmaprp: emmaprp@10026400 {
+ compatible = fsl,imx27-emmaprp, fsl,imx21-emmaprp;
+ reg = 0x10026400 0x100;
+ interrupts = 51;
+ clocks = clks 49, clks 68;
+ clock-names = ipg, ahb;
+ };
--
1.8.5.5
--
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 1/2] media: mx2-emmaprp: Add devicetree support
This patch adds devicetree support for the Freescale enhanced Multimedia
Accelerator (eMMA) video Pre-processor (PrP).
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
drivers/media/platform/mx2_emmaprp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/media/platform/mx2_emmaprp.c
b/drivers/media/platform/mx2_emmaprp.c
index fa8f7ca..0646bda 100644
--- a/drivers/media/platform/mx2_emmaprp.c
+++ b/drivers/media/platform/mx2_emmaprp.c
@@ -18,6 +18,7 @@
*/
#include linux/module.h
#include linux/clk.h
+#include linux/of.h
#include linux/slab.h
#include linux/interrupt.h
#include linux/io.h
@@ -1005,12 +1006,19 @@ static int emmaprp_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id __maybe_unused emmaprp_dt_ids[] = {
+ { .compatible = fsl,imx21-emmaprp, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, emmaprp_dt_ids);
+
static struct platform_driver emmaprp_pdrv = {
.probe = emmaprp_probe,
.remove = emmaprp_remove,
.driver = {
.name = MEM2MEM_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(emmaprp_dt_ids),
},
};
module_platform_driver(emmaprp_pdrv);
--
1.8.5.5
--
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 00/11] OMAP3 ISP BT.656 support
On Mon, May 26, 2014 at 9:50 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hello, This patch sets implements support for BT.656 and interlaced formats in the OMAP3 ISP driver. Better late than never I suppose, although given how long this has been on my to-do list there's probably no valid excuse. Thanks Laurent! I hope to have time soon to test it :) Enrico -- 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 v8 3/3] ARM: sunxi: Add IR controller support in DT on A20
On Mon, May 26, 2014 at 04:26:45AM +0600, Alexander Bersenev wrote: This patch adds IR controller in A20 Device-Tree: - Two IR devices found in A20 user manual - Pins for two devices - One IR device physically found on Cubieboard 2 - One IR device physically found on Cubietruck Signed-off-by: Alexander Bersenev b...@hackerdom.ru Signed-off-by: Alexsey Shestacov wingr...@linux-sunxi.org --- arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 6 ++ arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 6 ++ arch/arm/boot/dts/sun7i-a20.dtsi| 32 + I told you numerous times already that I wanted this patch to be split into at least three of them: - One to add the device to the DTSI. - One to add the pins - and one to enable the devices in the DTS. Please address this comment. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH/RFC 0/2] Propert alpha channel support in pixel formats
Hi Hans, On Tuesday 27 May 2014 09:18:23 Hans Verkuil wrote: On 05/27/2014 12:17 AM, Laurent Pinchart wrote: Hello, This RFC patch series attempts to clean up the current ARGB format mess. The core issue is that the existing ARGB formats are ill-defined. The V4L2 specification doesn't clearly document how the alpha bits should behave. Drivers have thus used the same formats in different, incompatible ways, and applications now rely on the driver-specific behaviours. In a word, that's a mess. I've discussed the issue in the #v4l channel a couple of days ago and we came up to the conclusion that the best (or least painful) way to fix the problem is to define new clean XRGB and ARGB formats, and consider the existing formats as deprecated (meaning that no new driver should use them, they won't disappear in a couple of months, as that would break userspace). The first patch adds the new XRGB and ARGB formats and documents them. Question: should we add all XRGB and ARGB formats even if drivers do not use them? Or just those that are actually used? The VSP1 driver is going to use them all, so we need them all. It purposely includes no core code to handle backward compatibility for existing drivers that may wish to move to the new formats. The reason is that I would first like to get feedback on the proposal before working on compat code, and I believe we should first implement the compat code in a couple of drivers and then see how the approach could be generalized, if possible at all. The second patch allows using the ALPHA_COMPONENT control on output devices to support an ARGB use case documented in the first patch. One possible shortcoming of reusing the existing control is that a mem-to-mem driver that exposes an output and a capture queue on a single video node through the same file handle wouldn't be able to set different alpha component values on the two queues. I'm not sure whether that use case is real though, it seems weird to me to set a fixed alpha value on one side to request a different fixed alpha value on the other side. I prefer a CAP_ALPHA_COMPONENT control. It's easy to add a capture-specific control now, it's much harder to change it in the future. What bothers me with this approach is the duplication of otherwise identical controls. As we'll likely need per-pad controls at some point in the future, wouldn't it better to implement a similar way to distinguish between capture and output controls ? -- Regards, Laurent Pinchart -- 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 1/1] smiapp: I2C address is the last part of the subdev name
Hi Laurent, Laurent Pinchart wrote: Hi Sakari, Thank you for the patch. On Thursday 15 May 2014 10:56:42 Sakari Ailus wrote: The I2C address of the sensor device was in the middle of the sub-device name and not in the end as it should have been. The smiapp sub-device names will change from e.g. vs6555 1-0010 pixel array to vs6555 pixel array 1-0010. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com --- This was already supposed to be fixed by [media] smiapp: Use I2C adapter ID and address in the sub-device name but the I2C address indeed was in the middle of the sub-device name and not in the end as it should have been. I don't mind much whether the I2C bus number is in the middle or at the end of the name. The current vs6555 1-0010 pixel array value looks good to me, as it means the pixel array of the vs6555 1-0010 sensor in English, but I'm fine with vs6555 pixel array 1-0010 as well. However, as discussed privately, I think we need to make sure that applications don't rely on a specific format for the name. Names must be unique, but should not otherwise be parsed by applications to extract device location information (at least in my opinion). That information should be I agree with that; my primary motivation with this patch is consistency: other drivers do the same, i.e. put the bus information at the end of the name. Still I don't think other drivers expose multiple sub-devices, so the question hasn't popped up before. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.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
[PATCH 1/1] smiapp: Implement the test pattern control
Add support for the V4L2_CID_TEST_PATTERN control. When the solid colour
mode is selected, additional controls become available for setting the
solid four solid colour components.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/i2c/smiapp/smiapp-core.c | 120 +++--
drivers/media/i2c/smiapp/smiapp.h | 4 ++
2 files changed, 120 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 446c82c..025342c 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -32,6 +32,7 @@
#include linux/gpio.h
#include linux/module.h
#include linux/slab.h
+#include linux/smiapp.h
#include linux/regulator/consumer.h
#include linux/v4l2-mediabus.h
#include media/v4l2-device.h
@@ -404,6 +405,52 @@ static void smiapp_update_mbus_formats(struct
smiapp_sensor *sensor)
pixel_order_str[pixel_order]);
}
+static const char * const smiapp_test_patterns[] = {
+ Disabled,
+ Solid colour,
+ Eight vertical colour bars,
+ Colour bars with fade to grey,
+ Pseudorandom sequence (PN9),
+};
+
+static const struct v4l2_ctrl_ops smiapp_ctrl_ops;
+
+static struct v4l2_ctrl_config
+smiapp_test_pattern_colours[SMIAPP_COLOUR_COMPONENTS] = {
+ {
+ smiapp_ctrl_ops,
+ V4L2_CID_SMIAPP_TEST_PATTERN_RED,
+ Solid red pixel value,
+ V4L2_CTRL_TYPE_INTEGER,
+ 0, 0, 1, 0,
+ V4L2_CTRL_FLAG_INACTIVE, 0, NULL, NULL, 0
+ },
+ {
+ smiapp_ctrl_ops,
+ V4L2_CID_SMIAPP_TEST_PATTERN_GREENR,
+ Solid green (red) pixel value,
+ V4L2_CTRL_TYPE_INTEGER,
+ 0, 0, 1, 0,
+ V4L2_CTRL_FLAG_INACTIVE, 0, NULL, NULL, 0
+ },
+ {
+ smiapp_ctrl_ops,
+ V4L2_CID_SMIAPP_TEST_PATTERN_BLUE,
+ Solid blue pixel value,
+ V4L2_CTRL_TYPE_INTEGER,
+ 0, 0, 1, 0,
+ V4L2_CTRL_FLAG_INACTIVE, 0, NULL, NULL, 0
+ },
+ {
+ smiapp_ctrl_ops,
+ V4L2_CID_SMIAPP_TEST_PATTERN_GREENB,
+ Solid green (blue) pixel value,
+ V4L2_CTRL_TYPE_INTEGER,
+ 0, 0, 1, 0,
+ V4L2_CTRL_FLAG_INACTIVE, 0, NULL, NULL, 0
+ },
+};
+
static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
{
struct smiapp_sensor *sensor =
@@ -477,6 +524,35 @@ static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
return smiapp_pll_update(sensor);
+ case V4L2_CID_TEST_PATTERN: {
+ unsigned int i;
+
+ for (i = 0; i ARRAY_SIZE(smiapp_test_pattern_colours); i++)
+ v4l2_ctrl_activate(
+ sensor-test_data[i],
+ ctrl-val ==
+ V4L2_SMIAPP_TEST_PATTERN_MODE_SOLID_COLOUR);
+
+ return smiapp_write(
+ sensor, SMIAPP_REG_U16_TEST_PATTERN_MODE, ctrl-val);
+ }
+
+ case V4L2_CID_SMIAPP_TEST_PATTERN_RED:
+ return smiapp_write(
+ sensor, SMIAPP_REG_U16_TEST_DATA_RED, ctrl-val);
+
+ case V4L2_CID_SMIAPP_TEST_PATTERN_GREENR:
+ return smiapp_write(
+ sensor, SMIAPP_REG_U16_TEST_DATA_GREENR, ctrl-val);
+
+ case V4L2_CID_SMIAPP_TEST_PATTERN_BLUE:
+ return smiapp_write(
+ sensor, SMIAPP_REG_U16_TEST_DATA_BLUE, ctrl-val);
+
+ case V4L2_CID_SMIAPP_TEST_PATTERN_GREENB:
+ return smiapp_write(
+ sensor, SMIAPP_REG_U16_TEST_DATA_GREENB, ctrl-val);
+
default:
return -EINVAL;
}
@@ -489,10 +565,10 @@ static const struct v4l2_ctrl_ops smiapp_ctrl_ops = {
static int smiapp_init_controls(struct smiapp_sensor *sensor)
{
struct i2c_client *client = v4l2_get_subdevdata(sensor-src-sd);
- unsigned int max;
+ unsigned int max, i;
int rval;
- rval = v4l2_ctrl_handler_init(sensor-pixel_array-ctrl_handler, 7);
+ rval = v4l2_ctrl_handler_init(sensor-pixel_array-ctrl_handler, 12);
if (rval)
return rval;
sensor-pixel_array-ctrl_handler.lock = sensor-mutex;
@@ -535,6 +611,17 @@ static int smiapp_init_controls(struct smiapp_sensor
*sensor)
sensor-pixel_array-ctrl_handler, smiapp_ctrl_ops,
V4L2_CID_PIXEL_RATE, 0, 0, 1, 0);
+ v4l2_ctrl_new_std_menu_items(sensor-pixel_array-ctrl_handler,
+smiapp_ctrl_ops, V4L2_CID_TEST_PATTERN,
+ARRAY_SIZE(smiapp_test_patterns) - 1,
+0, 0, smiapp_test_patterns);
+
+ for (i = 0; i ARRAY_SIZE(smiapp_test_pattern_colours); i++)
+
[PATCH 1/1] media: Set entity-links NULL in cleanup
Calling media_entity_cleanup() on a cleaned-up entity would result into
double free of the entity-links pointer and likely memory corruption as
well. Setting entity-links as NULL right after the kfree() avoids this.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/media-entity.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 37c334e..c404354 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -83,6 +83,7 @@ void
media_entity_cleanup(struct media_entity *entity)
{
kfree(entity-links);
+ entity-links = NULL;
}
EXPORT_SYMBOL_GPL(media_entity_cleanup);
--
1.8.3.2
--
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] v4l: vsp1: sru: Handle control handler initialization errors
On Tue, May 27, 2014 at 12:46:49AM +0200, Laurent Pinchart wrote:
Bail out when the SRU control handler fails to initialize.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/media/platform/vsp1/vsp1_sru.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/media/platform/vsp1/vsp1_sru.c
b/drivers/media/platform/vsp1/vsp1_sru.c
index aa0e04c..79efcaf 100644
--- a/drivers/media/platform/vsp1/vsp1_sru.c
+++ b/drivers/media/platform/vsp1/vsp1_sru.c
@@ -348,6 +348,14 @@ struct vsp1_sru *vsp1_sru_create(struct vsp1_device
*vsp1)
/* Initialize the control handler. */
v4l2_ctrl_handler_init(sru-ctrls, 1);
v4l2_ctrl_new_custom(sru-ctrls, sru_intensity_control, NULL);
+
+ if (sru-ctrls.error) {
+ dev_err(vsp1-dev, sru: failed to initialize controls\n);
+ ret = sru-ctrls.error;
+ v4l2_ctrl_handler_free(sru-ctrls);
+ return ERR_PTR(ret);
+ }
+
v4l2_ctrl_handler_setup(sru-ctrls);
sru-entity.subdev.ctrl_handler = sru-ctrls;
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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] em28xx: add MSI Digivox Trio support
On 05/27/2014 09:12 AM, Hans Verkuil wrote:
On 05/27/2014 02:04 AM, P. van Gaans wrote:
http://linuxtv.org/wiki/index.php/MSI_DigiVox_Trio
If you're having a deja-vu, yeah, it's still me. I'm still using this
device using my butt-ugly patch by adding:
{ USB_DEVICE(0xeb1a, 0x2885),/* MSI Digivox Trio */
.driver_info = EM2884_BOARD_TERRATEC_H5 },
to linux/drivers/media/usb/em28xx/em28xx-cards.c.
It's starting to bug me more and more that I can never update my kernel
(well not without hassle anyway). I've written this to the mailinglist
before, but with no response.
I just don't have the skill to write this in the neat way it needs to be
to be able to go upstream. Should I try to hire someone to do that? If
so, any suggestions? Just put an ad up on craigslist or something? Does
such a patch have a chance of going upstream? (as that's the whole point
- I want to update my kernel again)
It should be really straightforward given that no reverse engineering or
anything is needed. It's just what it states above - pretend the Digivox
is an H5 and it's done.
Anyone who can tune in on this, please share your thoughts.
I've made it into a proper patch, see below.
Can you reply with your 'Signed-off-by' line?
i.e.: Signed-off-by: John Doe john@foo.com
Since you're the author of the patch (I just formatted it), I need that to
get it upstream.
Regards,
Hans
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 15ad470..9da812b 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2280,6 +2280,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2820_BOARD_UNKNOWN },
{ USB_DEVICE(0xeb1a, 0x2875),
.driver_info = EM2820_BOARD_UNKNOWN },
+ { USB_DEVICE(0xeb1a, 0x2885), /* MSI Digivox Trio */
+ .driver_info = EM2884_BOARD_TERRATEC_H5 },
{ USB_DEVICE(0xeb1a, 0xe300),
.driver_info = EM2861_BOARD_KWORLD_PVRTV_300U },
{ USB_DEVICE(0xeb1a, 0xe303),
--
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
Thank you!
Signed-off-by: P. van Gaans w3ird_n...@gmx.net
--
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 01/12] Add ISDB-T brazilian channels table
Full channel table, as defined by Brazilian regulations. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- dvbv5_isdb-t/br-Brazil | 1446 1 file changed, 1446 insertions(+) create mode 100644 dvbv5_isdb-t/br-Brazil diff --git a/dvbv5_isdb-t/br-Brazil b/dvbv5_isdb-t/br-Brazil new file mode 100644 index ..05cd2b8e209b --- /dev/null +++ b/dvbv5_isdb-t/br-Brazil @@ -0,0 +1,1446 @@ +# ISDB-T channel frequencies as defined in Brazil by ABNT NBR 15608-1 +# +# +# NOTES: +# 1) VHF channels 7 to 13 are also specified but not in usage yet. +# We may need to add support for them in some future, after the +# full migration from analog to digital. +# +# 2) UHF channel 37 is not defined at the standard. +# +# 3) The same frequency range is used by other ISDB-T 6MHz Countries, +# but other Countries may be using already VHF or channel 37. +# +[channel 14] + DELIVERY_SYSTEM = ISDBT + BANDWIDTH_HZ = 600 + FREQUENCY = 473142857 + INVERSION = AUTO + GUARD_INTERVAL = AUTO + TRANSMISSION_MODE = AUTO + ISDBT_LAYER_ENABLED = 7 + ISDBT_SOUND_BROADCASTING = 0 + ISDBT_SB_SUBCHANNEL_ID = 0 + ISDBT_SB_SEGMENT_IDX = 0 + ISDBT_SB_SEGMENT_COUNT = 0 + ISDBT_LAYERA_FEC = AUTO + ISDBT_LAYERA_MODULATION = QAM/AUTO + ISDBT_LAYERA_SEGMENT_COUNT = 0 + ISDBT_LAYERA_TIME_INTERLEAVING = 0 + ISDBT_LAYERB_FEC = AUTO + ISDBT_LAYERB_MODULATION = QAM/AUTO + ISDBT_LAYERB_SEGMENT_COUNT = 0 + ISDBT_LAYERB_TIME_INTERLEAVING = 0 + ISDBT_LAYERC_FEC = AUTO + ISDBT_LAYERC_MODULATION = QAM/AUTO + ISDBT_LAYERC_SEGMENT_COUNT = 0 + ISDBT_LAYERC_TIME_INTERLEAVING = 0 + + +[channel 15] + DELIVERY_SYSTEM = ISDBT + BANDWIDTH_HZ = 600 + FREQUENCY = 479142857 + INVERSION = AUTO + GUARD_INTERVAL = AUTO + TRANSMISSION_MODE = AUTO + ISDBT_LAYER_ENABLED = 7 + ISDBT_SOUND_BROADCASTING = 0 + ISDBT_SB_SUBCHANNEL_ID = 0 + ISDBT_SB_SEGMENT_IDX = 0 + ISDBT_SB_SEGMENT_COUNT = 0 + ISDBT_LAYERA_FEC = AUTO + ISDBT_LAYERA_MODULATION = QAM/AUTO + ISDBT_LAYERA_SEGMENT_COUNT = 0 + ISDBT_LAYERA_TIME_INTERLEAVING = 0 + ISDBT_LAYERB_FEC = AUTO + ISDBT_LAYERB_MODULATION = QAM/AUTO + ISDBT_LAYERB_SEGMENT_COUNT = 0 + ISDBT_LAYERB_TIME_INTERLEAVING = 0 + ISDBT_LAYERC_FEC = AUTO + ISDBT_LAYERC_MODULATION = QAM/AUTO + ISDBT_LAYERC_SEGMENT_COUNT = 0 + ISDBT_LAYERC_TIME_INTERLEAVING = 0 + + +[channel 16] + DELIVERY_SYSTEM = ISDBT + BANDWIDTH_HZ = 600 + FREQUENCY = 485142857 + INVERSION = AUTO + GUARD_INTERVAL = AUTO + TRANSMISSION_MODE = AUTO + ISDBT_LAYER_ENABLED = 7 + ISDBT_SOUND_BROADCASTING = 0 + ISDBT_SB_SUBCHANNEL_ID = 0 + ISDBT_SB_SEGMENT_IDX = 0 + ISDBT_SB_SEGMENT_COUNT = 0 + ISDBT_LAYERA_FEC = AUTO + ISDBT_LAYERA_MODULATION = QAM/AUTO + ISDBT_LAYERA_SEGMENT_COUNT = 0 + ISDBT_LAYERA_TIME_INTERLEAVING = 0 + ISDBT_LAYERB_FEC = AUTO + ISDBT_LAYERB_MODULATION = QAM/AUTO + ISDBT_LAYERB_SEGMENT_COUNT = 0 + ISDBT_LAYERB_TIME_INTERLEAVING = 0 + ISDBT_LAYERC_FEC = AUTO + ISDBT_LAYERC_MODULATION = QAM/AUTO + ISDBT_LAYERC_SEGMENT_COUNT = 0 + ISDBT_LAYERC_TIME_INTERLEAVING = 0 + + +[channel 17] + DELIVERY_SYSTEM = ISDBT + BANDWIDTH_HZ = 600 + FREQUENCY = 491142857 + INVERSION = AUTO + GUARD_INTERVAL = AUTO + TRANSMISSION_MODE = AUTO + ISDBT_LAYER_ENABLED = 7 + ISDBT_SOUND_BROADCASTING = 0 + ISDBT_SB_SUBCHANNEL_ID = 0 + ISDBT_SB_SEGMENT_IDX = 0 + ISDBT_SB_SEGMENT_COUNT = 0 + ISDBT_LAYERA_FEC = AUTO + ISDBT_LAYERA_MODULATION = QAM/AUTO + ISDBT_LAYERA_SEGMENT_COUNT = 0 + ISDBT_LAYERA_TIME_INTERLEAVING = 0 + ISDBT_LAYERB_FEC = AUTO + ISDBT_LAYERB_MODULATION = QAM/AUTO + ISDBT_LAYERB_SEGMENT_COUNT = 0 + ISDBT_LAYERB_TIME_INTERLEAVING = 0 + ISDBT_LAYERC_FEC = AUTO + ISDBT_LAYERC_MODULATION = QAM/AUTO + ISDBT_LAYERC_SEGMENT_COUNT = 0 + ISDBT_LAYERC_TIME_INTERLEAVING = 0 + + +[channel 18] + DELIVERY_SYSTEM = ISDBT + BANDWIDTH_HZ = 600 + FREQUENCY = 497142857 + INVERSION = AUTO + GUARD_INTERVAL = AUTO + TRANSMISSION_MODE = AUTO + ISDBT_LAYER_ENABLED = 7 + ISDBT_SOUND_BROADCASTING = 0 + ISDBT_SB_SUBCHANNEL_ID = 0 + ISDBT_SB_SEGMENT_IDX = 0 + ISDBT_SB_SEGMENT_COUNT = 0 + ISDBT_LAYERA_FEC = AUTO + ISDBT_LAYERA_MODULATION = QAM/AUTO + ISDBT_LAYERA_SEGMENT_COUNT = 0 + ISDBT_LAYERA_TIME_INTERLEAVING = 0 + ISDBT_LAYERB_FEC = AUTO + ISDBT_LAYERB_MODULATION = QAM/AUTO + ISDBT_LAYERB_SEGMENT_COUNT = 0 + ISDBT_LAYERB_TIME_INTERLEAVING
RE: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran Microelectronics, Ltd Digital Camera EX-20 DSC
Date: Tue, 27 May 2014 09:03:33 +0200 From: hverk...@xs4all.nl To: searchfgold67...@live.com; linux-...@vger.kernel.org; linux-media@vger.kernel.org Subject: Re: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran Microelectronics, Ltd Digital Camera EX-20 DSC On 05/27/2014 03:34 AM, Richie wrote: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1322380 [1.] One line summary of the problem: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran Microelectronics, Ltd Digital Camera EX-20 DSC [2.] Full description of the problem/report: No software recognizes the webcam and this is not a regression. dmesg reports the following additional output after plugging the camera. You can see where I change the camera to PC Mode (in order to use the webcam, users must do this from the camera) at [ 691.147589]. The device is turned off at [ 1094.746444]: [ 688.796908] usb 4-2: new full-speed USB device number 2 using ohci-pci [ 688.965802] usb 4-2: New USB device found, idVendor=0595, idProduct=2002 [ 688.965807] usb 4-2: New USB device strings: Mfr=4, Product=5, SerialNumber=6 [ 688.965809] usb 4-2: Product: COACH DSC [ 688.965811] usb 4-2: Manufacturer: ZORAN [ 688.965813] usb 4-2: SerialNumber: ZORAN01234567 [ 689.012630] usb-storage 4-2:1.0: USB Mass Storage device detected [ 689.021168] scsi6 : usb-storage 4-2:1.0 [ 689.021266] usbcore: registered new interface driver usb-storage [ 690.030971] scsi 6:0:0:0: Direct-Access ZORAN COACH6 (I62) 1.10 PQ: 0 ANSI: 0 CCS [ 690.036147] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 690.044964] sd 6:0:0:0: [sdc] 3962629 512-byte logical blocks: (2.02 GB/1.88 GiB) [ 690.054977] sd 6:0:0:0: [sdc] Write Protect is off [ 690.054984] sd 6:0:0:0: [sdc] Mode Sense: 00 06 00 00 [ 690.064965] sd 6:0:0:0: [sdc] No Caching mode page found [ 690.064971] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 690.108960] sd 6:0:0:0: [sdc] No Caching mode page found [ 690.108966] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 690.156970] sdc: [ 690.210974] sd 6:0:0:0: [sdc] No Caching mode page found [ 690.210980] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 690.210985] sd 6:0:0:0: [sdc] Attached SCSI removable disk [ 691.147589] usb 4-2: USB disconnect, device number 2 [ 691.793364] usb 4-2: new full-speed USB device number 3 using ohci-pci [ 691.962202] usb 4-2: New USB device found, idVendor=0595, idProduct=4343 [ 691.962207] usb 4-2: New USB device strings: Mfr=7, Product=8, SerialNumber=9 [ 691.962209] usb 4-2: Product: COACH DSC [ 691.962211] usb 4-2: Manufacturer: ZORAN [ 691.962213] usb 4-2: SerialNumber: ZORAN0001 [ 691.964262] usb-storage 4-2:1.0: USB Mass Storage device detected [ 691.965410] usb-storage: probe of 4-2:1.0 failed with error -5 [ 692.053929] Linux video capture interface: v2.00 [ 692.091447] zr364xx 4-2:1.0: Zoran 364xx compatible webcam plugged [ 692.091453] zr364xx 4-2:1.0: model 0595:4343 detected [ 692.091461] usb 4-2: 320x240 mode selected [ 692.094356] usb 4-2: Zoran 364xx controlling device video0 Clearly the webcam is recognized and a /dev/video0 node is created. Please check that /dev/video0 exists. Try e.g. v4l2-ctl -D -d /dev/video0, it should list it as using the zr364xx driver. So what exactly doesn't work? Regards, Hans [ 692.094672] usbcore: registered new interface driver zr364xx [ 1094.746444] hub 4-0:1.0: port 2 disabled by hub (EMI?), re-enabling... [ 1094.746451] usb 4-2: USB disconnect, device number 3 [ 1094.747395] zr364xx 4-2:1.0: Zoran 364xx webcam unplugged Yes, it does seem to be using the zr364xx driver: $ v4l2-ctl -D -d /dev/video0 Driver Info (not using libv4l2): Driver name : Zoran 364xx Card type : COACH DSC Bus info : 4-1 Driver version: 3.15.0 Capabilities : 0x8501 Video Capture Read/Write Streaming Device Capabilities Device Caps : 0x0501 Video Capture Read/Write Streaming The exact problem is that while the camera is recognized as a camera by software like Skype, Kamoso, and Cheese, there is no picture, just black. A 320x240 mode was mentioned... perhaps that resolution is just too small to use by the software? - Richard -- 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: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran Microelectronics, Ltd Digital Camera EX-20 DSC
On Tuesday, May 27, 2014 01:55:20 PM Richie Gress wrote: Date: Tue, 27 May 2014 09:03:33 +0200 From: hverk...@xs4all.nl To: searchfgold67...@live.com; linux-...@vger.kernel.org; linux-media@vger.kernel.org Subject: Re: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran Microelectronics, Ltd Digital Camera EX-20 DSC On 05/27/2014 03:34 AM, Richie wrote: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1322380 [1.] One line summary of the problem: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran Microelectronics, Ltd Digital Camera EX-20 DSC [2.] Full description of the problem/report: No software recognizes the webcam and this is not a regression. dmesg reports the following additional output after plugging the camera. You can see where I change the camera to PC Mode (in order to use the webcam, users must do this from the camera) at [ 691.147589]. The device is turned off at [ 1094.746444]: [ 688.796908] usb 4-2: new full-speed USB device number 2 using ohci-pci [ 688.965802] usb 4-2: New USB device found, idVendor=0595, idProduct=2002 [ 688.965807] usb 4-2: New USB device strings: Mfr=4, Product=5, SerialNumber=6 [ 688.965809] usb 4-2: Product: COACH DSC [ 688.965811] usb 4-2: Manufacturer: ZORAN [ 688.965813] usb 4-2: SerialNumber: ZORAN01234567 [ 689.012630] usb-storage 4-2:1.0: USB Mass Storage device detected [ 689.021168] scsi6 : usb-storage 4-2:1.0 [ 689.021266] usbcore: registered new interface driver usb-storage [ 690.030971] scsi 6:0:0:0: Direct-Access ZORAN COACH6 (I62) 1.10 PQ: 0 ANSI: 0 CCS [ 690.036147] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 690.044964] sd 6:0:0:0: [sdc] 3962629 512-byte logical blocks: (2.02 GB/1.88 GiB) [ 690.054977] sd 6:0:0:0: [sdc] Write Protect is off [ 690.054984] sd 6:0:0:0: [sdc] Mode Sense: 00 06 00 00 [ 690.064965] sd 6:0:0:0: [sdc] No Caching mode page found [ 690.064971] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 690.108960] sd 6:0:0:0: [sdc] No Caching mode page found [ 690.108966] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 690.156970] sdc: [ 690.210974] sd 6:0:0:0: [sdc] No Caching mode page found [ 690.210980] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 690.210985] sd 6:0:0:0: [sdc] Attached SCSI removable disk [ 691.147589] usb 4-2: USB disconnect, device number 2 [ 691.793364] usb 4-2: new full-speed USB device number 3 using ohci-pci [ 691.962202] usb 4-2: New USB device found, idVendor=0595, idProduct=4343 [ 691.962207] usb 4-2: New USB device strings: Mfr=7, Product=8, SerialNumber=9 [ 691.962209] usb 4-2: Product: COACH DSC [ 691.962211] usb 4-2: Manufacturer: ZORAN [ 691.962213] usb 4-2: SerialNumber: ZORAN0001 [ 691.964262] usb-storage 4-2:1.0: USB Mass Storage device detected [ 691.965410] usb-storage: probe of 4-2:1.0 failed with error -5 [ 692.053929] Linux video capture interface: v2.00 [ 692.091447] zr364xx 4-2:1.0: Zoran 364xx compatible webcam plugged [ 692.091453] zr364xx 4-2:1.0: model 0595:4343 detected [ 692.091461] usb 4-2: 320x240 mode selected [ 692.094356] usb 4-2: Zoran 364xx controlling device video0 Clearly the webcam is recognized and a /dev/video0 node is created. Please check that /dev/video0 exists. Try e.g. v4l2-ctl -D -d /dev/video0, it should list it as using the zr364xx driver. So what exactly doesn't work? Regards, Hans [ 692.094672] usbcore: registered new interface driver zr364xx [ 1094.746444] hub 4-0:1.0: port 2 disabled by hub (EMI?), re-enabling... [ 1094.746451] usb 4-2: USB disconnect, device number 3 [ 1094.747395] zr364xx 4-2:1.0: Zoran 364xx webcam unplugged Yes, it does seem to be using the zr364xx driver: $ v4l2-ctl -D -d /dev/video0 Driver Info (not using libv4l2): Driver name : Zoran 364xx Card type : COACH DSC Bus info : 4-1 Driver version: 3.15.0 Capabilities : 0x8501 Video Capture Read/Write Streaming Device Capabilities Device Caps : 0x0501 Video Capture Read/Write Streaming The exact problem is that while the camera is recognized as a camera by software like Skype, Kamoso, and Cheese, there is no picture, just black. A 320x240 mode was mentioned... perhaps that resolution is just too small to use by the software? - Richard Some more info: when I start Cheese, I get this: $ cheese libv4l2: error setting pixformat: Timer expired libv4l2: error setting pixformat: Timer expired libv4l2: error setting pixformat: Timer expired libv4l2: error setting pixformat: Timer expired libv4l2: error setting pixformat: Timer expired libv4l2: error setting pixformat: Timer expired libv4l2: error setting pixformat: Timer expired libv4l2: error setting pixformat:
Re: [RFC PATCH] [media] mt9v032: Add support for mt9v022 and mt9v024
Hi Philipp,
On Mon, 26 May 2014, Philipp Zabel wrote:
From the looks of it, mt9v022 and mt9v032 are very similar,
as are mt9v024 and mt9v034. With minimal changes it is possible
to support mt9v02[24] with the same driver.
Are you aware of drivers/media/i2c/soc_camera/mt9v022.c? With this patch
you'd duplicate support for both mt9v022 and mt9v024, which doesn't look
like a good idea to me.
Thanks
Guennadi
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/i2c/mt9v032.c | 56
+
1 file changed, 42 insertions(+), 14 deletions(-)
diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
index 052e754..617b77f 100644
--- a/drivers/media/i2c/mt9v032.c
+++ b/drivers/media/i2c/mt9v032.c
@@ -1,5 +1,5 @@
/*
- * Driver for MT9V032 CMOS Image Sensor from Micron
+ * Driver for MT9V022, MT9V024, MT9V032, and MT9V034 CMOS Image Sensors
*
* Copyright (C) 2010, Laurent Pinchart laurent.pinch...@ideasonboard.com
*
@@ -68,6 +68,7 @@
#define MT9V032_CHIP_CONTROL_MASTER_MODE(1 3)
#define MT9V032_CHIP_CONTROL_DOUT_ENABLE(1 7)
#define MT9V032_CHIP_CONTROL_SEQUENTIAL (1 8)
+#define MT9V024_CHIP_CONTROL_DEF_PIX_CORRECT(1 9)
#define MT9V032_SHUTTER_WIDTH1 0x08
#define MT9V032_SHUTTER_WIDTH2 0x09
#define MT9V032_SHUTTER_WIDTH_CONTROL0x0a
@@ -133,8 +134,12 @@
#define MT9V032_THERMAL_INFO 0xc1
enum mt9v032_model {
- MT9V032_MODEL_V032_COLOR,
- MT9V032_MODEL_V032_MONO,
+ MT9V032_MODEL_V022_COLOR, /* MT9V022IX7ATC */
+ MT9V032_MODEL_V022_MONO,/* MT9V022IX7ATM */
+ MT9V032_MODEL_V024_COLOR, /* MT9V024IA7XTC */
+ MT9V032_MODEL_V024_MONO,/* MT9V024IA7XTM */
+ MT9V032_MODEL_V032_COLOR, /* MT9V032C12STM */
+ MT9V032_MODEL_V032_MONO,/* MT9V032C12STC */
MT9V032_MODEL_V034_COLOR,
MT9V032_MODEL_V034_MONO,
};
@@ -160,14 +165,14 @@ struct mt9v032_model_info {
};
static const struct mt9v032_model_version mt9v032_versions[] = {
- { MT9V032_CHIP_ID_REV1, MT9V032 rev1/2 },
- { MT9V032_CHIP_ID_REV3, MT9V032 rev3 },
- { MT9V034_CHIP_ID_REV1, MT9V034 rev1 },
+ { MT9V032_CHIP_ID_REV1, MT9V022/MT9V032 rev1/2 },
+ { MT9V032_CHIP_ID_REV3, MT9V022/MT9V032 rev3 },
+ { MT9V034_CHIP_ID_REV1, MT9V024/MT9V034 rev1 },
};
static const struct mt9v032_model_data mt9v032_model_data[] = {
{
- /* MT9V032 revisions 1/2/3 */
+ /* MT9V022, MT9V032 revisions 1/2/3 */
.min_row_time = 660,
.min_hblank = MT9V032_HORIZONTAL_BLANKING_MIN,
.min_vblank = MT9V032_VERTICAL_BLANKING_MIN,
@@ -176,7 +181,7 @@ static const struct mt9v032_model_data
mt9v032_model_data[] = {
.max_shutter = MT9V032_TOTAL_SHUTTER_WIDTH_MAX,
.pclk_reg = MT9V032_PIXEL_CLOCK,
}, {
- /* MT9V034 */
+ /* MT9V024, MT9V034 */
.min_row_time = 690,
.min_hblank = MT9V034_HORIZONTAL_BLANKING_MIN,
.min_vblank = MT9V034_VERTICAL_BLANKING_MIN,
@@ -188,6 +193,22 @@ static const struct mt9v032_model_data
mt9v032_model_data[] = {
};
static const struct mt9v032_model_info mt9v032_models[] = {
+ [MT9V032_MODEL_V022_COLOR] = {
+ .data = mt9v032_model_data[0],
+ .color = true,
+ },
+ [MT9V032_MODEL_V022_MONO] = {
+ .data = mt9v032_model_data[0],
+ .color = false,
+ },
+ [MT9V032_MODEL_V024_COLOR] = {
+ .data = mt9v032_model_data[1],
+ .color = true,
+ },
+ [MT9V032_MODEL_V024_MONO] = {
+ .data = mt9v032_model_data[1],
+ .color = false,
+ },
[MT9V032_MODEL_V032_COLOR] = {
.data = mt9v032_model_data[0],
.color = true,
@@ -415,7 +436,6 @@ static int mt9v032_s_stream(struct v4l2_subdev *subdev,
int enable)
struct i2c_client *client = v4l2_get_subdevdata(subdev);
struct mt9v032 *mt9v032 = to_mt9v032(subdev);
struct v4l2_rect *crop = mt9v032-crop;
- unsigned int read_mode;
unsigned int hbin;
unsigned int vbin;
int ret;
@@ -426,11 +446,9 @@ static int mt9v032_s_stream(struct v4l2_subdev *subdev,
int enable)
/* Configure the window size and row/column bin */
hbin = fls(mt9v032-hratio) - 1;
vbin = fls(mt9v032-vratio) - 1;
- read_mode = mt9v032_read(client, MT9V032_READ_MODE);
- read_mode = ~0xff; /* bits 0x300 are reserved, on MT9V024 */
- read_mode |= hbin MT9V032_READ_MODE_COLUMN_BIN_SHIFT |
- vbin MT9V032_READ_MODE_ROW_BIN_SHIFT;
- ret = mt9v032_write(client, MT9V032_READ_MODE,
Re: [PATCH] cxd2820r: TS clock inversion in config
This specific cxd2820r option need for Geniatech T220 https://patchwork.linuxtv.org/patch/23836/ On Tuesday 06 May 2014 00:11:17 you wrote: That patch does more than it says and due to that I don't want it. Just implement cxd2820r clock inversion and nothing more. Put the rest stuff, which does not belong to cxd2820r, to another patch. -- 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] technisat-sub2: Fix stream curruption on high bitrate
On Sunday 25 May 2014 15:29:57 Mauro Carvalho Chehab wrote: Could you please better document this patch? Bug catched @ new ABS2 satellite (75E). Transponders with bitrate 70-80mbit. Before some european another users report same issue with ~67mbit transponders (S2,8PSK,27500,5/6). So just another bug in this driver :) I would be expecting a better description of the problem you faced, the version of the board you have (assuming that different versions might have different minimal intervals) and an lsusb -v output from the board you faced issues, showing what the endpoint descriptors say about that. This device have only one hw revision. lsusb -v output: Bus 001 Device 009: ID 14f7:0500 TechniSat Digital GmbH DVB-PC TV Star HD Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x14f7 TechniSat Digital GmbH idProduct 0x0500 DVB-PC TV Star HD bcdDevice0.01 iManufacturer 1 TechniSat Digital iProduct2 TechniSat USB device iSerial 3 0008C9F04C76 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 69 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 300mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 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 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x0c00 2x 1024 bytes bInterval 1 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 0x01 EP 1 OUT 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: 0x0001 Self Powered Btw, if those tables are ok, can't we just retrieve the information directly from the descriptors, instead of hardcoding it, e. g filling it with:
Re: am i in the right list?
what's the process tree like when its looked at? 1d5c:2000 On Thu, May 22, 2014 at 8:44 AM, Steven Toth st...@kernellabs.com wrote: Should i email Hans Verkuil or would he see this already ? Fresco Logic FL2000 USB to VGA adapter He would have seen this already. - Steve -- Steven Toth - Kernel Labs 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
Any USB chip that delivers 60fps?
Hi, I'm looking for any USB-connected device that can give me 60fps from a NTSC signal. I'm either looking for a chip+driver that support V4L2_FIELD_ALTERNATE (which I gather are rare) so that I can construct my own frames at 60Hz by blending each pair of neighboring fields, or ideally, to find hardware or driver that does a good job of it for me. Why NTSC you ask? because I can find high quality cameras that work great in low-light scenarios, where most USB cameras fall flat. And as a follow-up question, is it possible and how hard would it be to add V4L2_FIELD_ALTERNATE support to one of the EasyCap drivers? Does the hardware de-interlace the frames on its own or is that in software? Thanks, -Mike -- 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: OK
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: Wed May 28 04:00:17 CEST 2014 git branch: test git hash: 26f15c1fff5493fc0771248d5a409f2c7815a53a gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API 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
