Re: omap3isp with DM3730 not working?!
Hi Enrico and Michael, On Thu, Jul 24, 2014 at 05:57:30PM +0200, Enrico wrote: On Thu, Jul 24, 2014 at 5:34 PM, Michael Dietschi michael.diets...@inunum.com wrote: Hello, I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253. It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :( I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c). I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this. Can someone please give me a hint? It's strange that you get the vd1_irq because it should not be set by the driver and never trigger... Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame. Anyway maybe a different pinmux where the camera pins are not setup correctly? This is unlikely to be at least the source of all issues since VD1 is seen. Cc Laurent. -- Kind regards, 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
[PATCH v4 0/3] media: atmel-isi: Add DT support for Atmel ISI driver
This patch series add DT support for atmel ISI driver. It can support the common v4l2 DT interfaces. v3 - v4: if bus-width set to 10, then we support both 8 bits and 10 bits. misc fix according to Guennadi. v2 - v3: support bus-width property for atmel-isi endpoint. v1 - v2: modified the device tree binding document to remove an optonal property. Josh Wu (3): atmel-isi: add v4l2 async probe support atmel-isi: convert the pdata from pointer to structure atmel-isi: add primary DT support .../devicetree/bindings/media/atmel-isi.txt| 51 drivers/media/platform/soc_camera/atmel-isi.c | 90 +++--- include/media/atmel-isi.h | 4 + 3 files changed, 133 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt -- 1.9.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 v4 1/3] media: atmel-isi: add v4l2 async probe support
Signed-off-by: Josh Wu josh...@atmel.com
---
v3 - v4:
no change.
drivers/media/platform/soc_camera/atmel-isi.c | 5 +
include/media/atmel-isi.h | 4
2 files changed, 9 insertions(+)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 14bc886..802c203 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -987,6 +987,11 @@ static int atmel_isi_probe(struct platform_device *pdev)
soc_host-v4l2_dev.dev = pdev-dev;
soc_host-nr= pdev-id;
+ if (isi-pdata.asd_sizes) {
+ soc_host-asd = isi-pdata.asd;
+ soc_host-asd_sizes = isi-pdata.asd_sizes;
+ }
+
ret = soc_camera_host_register(soc_host);
if (ret) {
dev_err(pdev-dev, Unable to register soc camera host\n);
diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h
index 2b02347..c2e5703 100644
--- a/include/media/atmel-isi.h
+++ b/include/media/atmel-isi.h
@@ -106,6 +106,8 @@
#define ISI_DATAWIDTH_80x01
#define ISI_DATAWIDTH_10 0x02
+struct v4l2_async_subdev;
+
struct isi_platform_data {
u8 has_emb_sync;
u8 emb_crc_sync;
@@ -118,6 +120,8 @@ struct isi_platform_data {
u32 frate;
/* Using for ISI_MCK */
u32 mck_hz;
+ struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
+ int *asd_sizes; /* 0-terminated array of asd group sizes */
};
#endif /* __ATMEL_ISI_H__ */
--
1.9.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 v4 2/3] media: atmel-isi: convert the pdata from pointer to structure
Now the platform data is initialized by allocation of isi
structure. In the future, we use pdata to store the dt parameters.
Signed-off-by: Josh Wu josh...@atmel.com
---
v3 - v4:
no change.
v2 - v3:
use sizeof(isi-pdata) instead of using sizeof(struct).
drivers/media/platform/soc_camera/atmel-isi.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 802c203..74af560 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -84,7 +84,7 @@ struct atmel_isi {
struct clk *mck;
unsigned intirq;
- struct isi_platform_data*pdata;
+ struct isi_platform_datapdata;
u16 width_flags;/* max 12 bits */
struct list_headvideo_buffer_list;
@@ -350,7 +350,7 @@ static void start_dma(struct atmel_isi *isi, struct
frame_buffer *buffer)
cfg1 = ~ISI_CFG1_FRATE_DIV_MASK;
/* Enable linked list */
- cfg1 |= isi-pdata-frate | ISI_CFG1_DISCR;
+ cfg1 |= isi-pdata.frate | ISI_CFG1_DISCR;
/* Enable codec path and ISI */
ctrl = ISI_CTRL_CDC | ISI_CTRL_EN;
@@ -795,7 +795,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd)
/* Make choises, based on platform preferences */
if ((common_flags V4L2_MBUS_HSYNC_ACTIVE_HIGH)
(common_flags V4L2_MBUS_HSYNC_ACTIVE_LOW)) {
- if (isi-pdata-hsync_act_low)
+ if (isi-pdata.hsync_act_low)
common_flags = ~V4L2_MBUS_HSYNC_ACTIVE_HIGH;
else
common_flags = ~V4L2_MBUS_HSYNC_ACTIVE_LOW;
@@ -803,7 +803,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd)
if ((common_flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)
(common_flags V4L2_MBUS_VSYNC_ACTIVE_LOW)) {
- if (isi-pdata-vsync_act_low)
+ if (isi-pdata.vsync_act_low)
common_flags = ~V4L2_MBUS_VSYNC_ACTIVE_HIGH;
else
common_flags = ~V4L2_MBUS_VSYNC_ACTIVE_LOW;
@@ -811,7 +811,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd)
if ((common_flags V4L2_MBUS_PCLK_SAMPLE_RISING)
(common_flags V4L2_MBUS_PCLK_SAMPLE_FALLING)) {
- if (isi-pdata-pclk_act_falling)
+ if (isi-pdata.pclk_act_falling)
common_flags = ~V4L2_MBUS_PCLK_SAMPLE_RISING;
else
common_flags = ~V4L2_MBUS_PCLK_SAMPLE_FALLING;
@@ -833,9 +833,9 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd)
if (common_flags V4L2_MBUS_PCLK_SAMPLE_FALLING)
cfg1 |= ISI_CFG1_PIXCLK_POL_ACTIVE_FALLING;
- if (isi-pdata-has_emb_sync)
+ if (isi-pdata.has_emb_sync)
cfg1 |= ISI_CFG1_EMB_SYNC;
- if (isi-pdata-full_mode)
+ if (isi-pdata.full_mode)
cfg1 |= ISI_CFG1_FULL_MODE;
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
@@ -910,7 +910,7 @@ static int atmel_isi_probe(struct platform_device *pdev)
if (IS_ERR(isi-pclk))
return PTR_ERR(isi-pclk);
- isi-pdata = pdata;
+ memcpy(isi-pdata, pdata, sizeof(isi-pdata));
isi-active = NULL;
spin_lock_init(isi-lock);
INIT_LIST_HEAD(isi-video_buffer_list);
@@ -926,7 +926,7 @@ static int atmel_isi_probe(struct platform_device *pdev)
/* Set ISI_MCK's frequency, it should be faster than pixel
* clock.
*/
- ret = clk_set_rate(isi-mck, pdata-mck_hz);
+ ret = clk_set_rate(isi-mck, isi-pdata.mck_hz);
if (ret 0)
return ret;
}
@@ -960,9 +960,9 @@ static int atmel_isi_probe(struct platform_device *pdev)
goto err_ioremap;
}
- if (pdata-data_width_flags ISI_DATAWIDTH_8)
+ if (isi-pdata.data_width_flags ISI_DATAWIDTH_8)
isi-width_flags = 1 7;
- if (pdata-data_width_flags ISI_DATAWIDTH_10)
+ if (isi-pdata.data_width_flags ISI_DATAWIDTH_10)
isi-width_flags |= 1 9;
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
--
1.9.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 v4 3/3] media: atmel-isi: add primary DT support
This patch add the DT support for Atmel ISI driver.
It use the same v4l2 DT interface that defined in video-interfaces.txt.
Signed-off-by: Josh Wu josh...@atmel.com
Cc: devicet...@vger.kernel.org
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
v3 - v4:
When bus width is 10, we support both 8 10 bits.
Use of_match_ptr().
refine the error message.
v2 - v3:
add bus-width property support.
add error handling when calling atmel_isi_probe_dt().
v1 - v2:
refine the binding document.
add port node description.
removed the optional property.
.../devicetree/bindings/media/atmel-isi.txt| 51 +
drivers/media/platform/soc_camera/atmel-isi.c | 65 +-
2 files changed, 114 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt
diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt
b/Documentation/devicetree/bindings/media/atmel-isi.txt
new file mode 100644
index 000..17e71b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isi.txt
@@ -0,0 +1,51 @@
+Atmel Image Sensor Interface (ISI) SoC Camera Subsystem
+--
+
+Required properties:
+- compatible: must be atmel,at91sam9g45-isi
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the ISI;
+- clocks: list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names: must contain isi_clk, which is the isi peripherial clock.
+
+ISI supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+ isi: isi@f0034000 {
+ compatible = atmel,at91sam9g45-isi;
+ reg = 0xf0034000 0x4000;
+ interrupts = 37 IRQ_TYPE_LEVEL_HIGH 5;
+
+ clocks = isi_clk;
+ clock-names = isi_clk;
+
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_isi;
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ isi_0: endpoint {
+ remote-endpoint = ov2640_0;
+ bus-width = 8;
+ };
+ };
+ };
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = omnivision,ov2640;
+ reg = 0x30;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 74af560..e5c1fcf 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -25,6 +25,7 @@
#include media/atmel-isi.h
#include media/soc_camera.h
#include media/soc_mediabus.h
+#include media/v4l2-of.h
#include media/videobuf2-dma-contig.h
#define MAX_BUFFER_NUM 32
@@ -33,6 +34,7 @@
#define VID_LIMIT_BYTES(16 * 1024 * 1024)
#define MIN_FRAME_RATE 15
#define FRAME_INTERVAL_MILLI_SEC (1000 / MIN_FRAME_RATE)
+#define ISI_DEFAULT_MCLK_FREQ 2500
/* Frame buffer descriptor */
struct fbd {
@@ -883,6 +885,51 @@ static int atmel_isi_remove(struct platform_device *pdev)
return 0;
}
+static int atmel_isi_probe_dt(struct atmel_isi *isi,
+ struct platform_device *pdev)
+{
+ struct device_node *np= pdev-dev.of_node;
+ struct v4l2_of_endpoint ep;
+ int err;
+
+ /* Default settings for ISI */
+ isi-pdata.full_mode = 1;
+ isi-pdata.mck_hz = ISI_DEFAULT_MCLK_FREQ;
+ isi-pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
+
+ np = of_graph_get_next_endpoint(np, NULL);
+ if (!np) {
+ dev_err(pdev-dev, Could not find the endpoint\n);
+ return -EINVAL;
+ }
+
+ err = v4l2_of_parse_endpoint(np, ep);
+ if (err) {
+ dev_err(pdev-dev, Could not parse the endpoint\n);
+ goto err_probe_dt;
+ }
+
+ switch (ep.bus.parallel.bus_width) {
+ case 8:
+ isi-pdata.data_width_flags = ISI_DATAWIDTH_8;
+ break;
+ case 10:
+ isi-pdata.data_width_flags =
+ ISI_DATAWIDTH_8 | ISI_DATAWIDTH_10;
+ break;
+ default:
+ dev_err(pdev-dev, Unsupported bus width: %d\n,
+ ep.bus.parallel.bus_width);
+
Re: omap3isp with DM3730 not working?!
Hi Sakari, Enrico and others, first of all I want to thank you for your help but I have to admit that I made a stupid error while struggling with image capturing and the ISP which has led to some false information - I had misconfigured the video source :( The corrected facts are: * Capturing does work with Gumstix Overo with a DM3730 and a TVP5151 chip * It does not work with a LogicPD Torpedo DM3730 and a TVP5150AM1 chip * I configured the Torpedo's pinmux exactly like on the Overo * ...but the only interrupt I am getting is HS_VS_IRQ Please apologize for the confusion and do not stop helping me... Kind regards, Michael -- 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: omap3isp with DM3730 not working?!
On Mon, Jul 28, 2014 at 9:20 AM, Sakari Ailus sakari.ai...@iki.fi wrote: Hi Enrico and Michael, On Thu, Jul 24, 2014 at 05:57:30PM +0200, Enrico wrote: On Thu, Jul 24, 2014 at 5:34 PM, Michael Dietschi michael.diets...@inunum.com wrote: Hello, I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253. It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :( I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c). I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this. Can someone please give me a hint? It's strange that you get the vd1_irq because it should not be set by the driver and never trigger... Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame. Hi Sakari, that's true in normal mode, but with bt656 patches VD1 is not used. 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 2/3] [media] coda: fix coda_g_selection
Am Montag, den 28.07.2014, 00:22 +0200 schrieb Hans Verkuil: On 07/27/2014 11:32 PM, Nicolas Dufresne wrote: Le dimanche 27 juillet 2014 à 20:21 +0200, Hans Verkuil a écrit : If cropcap returns -EINVAL then that means that the current input or output does not support cropping (for input) or composing (for output). In that case the pixel aspect ratio is undefined and you have no way to get hold of that information, which is a bug in the V4L2 API. In the case of an m2m device you can safely assume that whatever the pixel aspect is of the image you give to the m2m device, it will still be the same pixel aspect when you get it back. In fact, I would say that if an m2m device returns cropcap information, then the pixel aspect ratio information is most likely not applicable to the device and will typically be 1:1. Pixel aspect ratio is only relevant if the video comes in or goes out to a physical interface (sensor, video receiver/transmitter). So far not applicable has been interpreted as not implemented / ENOTTY. Can't CODA just do that and we can close this subject ? Yes, that might be the best solution. Just call v4l2_disable_ioctl for CROPCAP and G/S_CROP, since none of them apply to the coda driver. Sounds like a plan, I'll do that. thanks Philipp -- 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: omap3isp with DM3730 not working?!
Hi Enrico, On Monday 28 July 2014 10:30:17 Enrico wrote: On Mon, Jul 28, 2014 at 9:20 AM, Sakari Ailus sakari.ai...@iki.fi wrote: On Thu, Jul 24, 2014 at 05:57:30PM +0200, Enrico wrote: On Thu, Jul 24, 2014 at 5:34 PM, Michael Dietschi wrote: Hello, I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253. It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :( I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c). I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this. Can someone please give me a hint? It's strange that you get the vd1_irq because it should not be set by the driver and never trigger... Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame. Hi Sakari, that's true in normal mode, but with bt656 patches VD1 is not used. That's not correct, VD1 is used in both modes. In BT.656 mode VD1 is even used to increment the frame counter in place of the HS_VS interrupt. -- 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
lockdep warning with 3.16.0-rc6+ + bttv
Hi,
I've upgraded my machine to 3.16.o-rc6+ with lockdep enabled and now
I get the following bttv related lockdep warning:
[4.797234] media: Linux media interface: v0.10
[4.810984] snd_bt87x :04:07.1: bt87x0: Using board 1, analog, digital
(rate 32000 Hz)
[4.836178] Linux video capture interface: v2.00
[4.997442] bttv: driver version 0.9.19 loaded
[4.997446] bttv: using 8 buffers with 2080k (520 pages) each for capture
[5.001339] bttv: Bt8xx card found (0)
[5.001482] bttv: 0: Bt878 (rev 2) at :04:07.0, irq: 20, latency: 32,
mmio: 0xd0001000
[5.001499] bttv: 0: detected: Hauppauge WinTV [card=10], PCI subsystem ID
is 0070:13eb
[5.001501] bttv: 0: using: Hauppauge (bt878) [card=10,autodetected]
[5.004174] bttv: 0: Hauppauge/Voodoo msp34xx: reset line init [5]
[5.039038] tveeprom 9-0050: Hauppauge model 61334, rev B2 , serial# 3211125
[5.039040] tveeprom 9-0050: tuner model is Philips FM1216 (idx 21, type 5)
[5.039042] tveeprom 9-0050: TV standards PAL(B/G) (eeprom 0x04)
[5.039043] tveeprom 9-0050: audio processor is MSP3415 (idx 6)
[5.039044] tveeprom 9-0050: has radio
[5.039045] bttv: 0: Hauppauge eeprom indicates model#61334
[5.039046] bttv: 0: tuner type=5
[5.073212] msp3400 9-0040: MSP3410D-B4 found @ 0x80 (bt878 #0 [sw])
[5.073217] msp3400 9-0040: msp3400 supports nicam, mode is autodetect
[5.114390] tuner 9-0061: Tuner -1 found with type(s) Radio TV.
[5.144779] tuner-simple 9-0061: creating new instance
[5.144782] tuner-simple 9-0061: type set to 5 (Philips PAL_BG (FI1216 and
compatibles))
[5.148047] ==
[5.148048] [ INFO: possible circular locking dependency detected ]
[5.148050] 3.16.0-rc6+ #109 Tainted: G OE
[5.148051] ---
[5.148052] systemd-udevd/545 is trying to acquire lock:
[5.148053] (msp3400_driver:799:(hdl)-_lock){+.+.+.}, at:
[a0282295] find_ref_lock+0x25/0x60 [videodev]
[5.148062]
but task is already holding lock:
[5.148063] (bttv_driver:4066:(hdl)-_lock){+.+...}, at:
[a028323d] v4l2_ctrl_handler_setup+0x3d/0x130 [videodev]
[5.148069]
which lock already depends on the new lock.
[5.148070]
the existing dependency chain (in reverse order) is:
[5.148071]
- #1 (bttv_driver:4066:(hdl)-_lock){+.+...}:
[5.148074][81102054] lock_acquire+0xa4/0x1d0
[5.148077][8180b425] mutex_lock_nested+0x85/0x440
[5.148080][a0282295] find_ref_lock+0x25/0x60 [videodev]
[5.148083][a0284b36] handler_new_ref+0x46/0x1d0 [videodev]
[5.148087][a02857af] v4l2_ctrl_add_handler+0x9f/0xe0
[videodev]
[5.148091][a027ebf6]
v4l2_device_register_subdev+0xe6/0x1e0 [videodev]
[5.148094][a029f743] v4l2_i2c_new_subdev_board+0x93/0x110
[v4l2_common]
[5.148097][a029f82a] v4l2_i2c_new_subdev+0x6a/0x90
[v4l2_common]
[5.148099][a032a8c6] bttv_init_card2+0x1486/0x1990 [bttv]
[5.148106][a032781d] bttv_probe+0x78d/0xd20 [bttv]
[5.148110][8142e515] local_pci_probe+0x45/0xa0
[5.148113][8142f959] pci_device_probe+0xf9/0x150
[5.148115][8151e003] driver_probe_device+0xa3/0x400
[5.148119][8151e42b] __driver_attach+0x8b/0x90
[5.148121][8151bc83] bus_for_each_dev+0x73/0xc0
[5.148123][8151da5e] driver_attach+0x1e/0x20
[5.148125][8151d628] bus_add_driver+0x188/0x260
[5.148128][8151ef04] driver_register+0x64/0xf0
[5.148130][8142ddc0] __pci_register_driver+0x60/0x70
[5.148132][a03470cf] bttv_init_module+0xcf/0xe9 [bttv]
[5.148136][81002148] do_one_initcall+0xd8/0x210
[5.148139][8113a600] load_module+0x2110/0x2740
[5.148142][8113ae16] SyS_finit_module+0xa6/0xe0
[5.148143][81810069] system_call_fastpath+0x16/0x1b
[5.148146]
- #0 (msp3400_driver:799:(hdl)-_lock){+.+.+.}:
[5.148148][8110158b] __lock_acquire+0x1abb/0x1ca0
[5.148150][81102054] lock_acquire+0xa4/0x1d0
[5.148152][8180b425] mutex_lock_nested+0x85/0x440
[5.148153][a0282295] find_ref_lock+0x25/0x60 [videodev]
[5.148157][a02822de] v4l2_ctrl_find+0xe/0x30 [videodev]
[5.148161][a032649d] audio_mute+0x3d/0xb0 [bttv]
[5.148165][a03266a6] bttv_s_ctrl+0x196/0x440 [bttv]
[5.148168][a02832ee] v4l2_ctrl_handler_setup+0xee/0x130
[videodev]
[5.148172][a0327874] bttv_probe+0x7e4/0xd20 [bttv]
[5.148176][8142e515] local_pci_probe+0x45/0xa0
[5.148178]
Re: lockdep warning with 3.16.0-rc6+ + bttv
On 07/28/14 12:35, Hans de Goede wrote:
Hi,
I've upgraded my machine to 3.16.o-rc6+ with lockdep enabled and now
I get the following bttv related lockdep warning:
That lockdep scenario will never happen in practice, although how to tell
lockdep about that I have no idea...
I'm not sure why this suddenly pops up, nothing has changed in that area
for these drivers.
Hans
[4.797234] media: Linux media interface: v0.10
[4.810984] snd_bt87x :04:07.1: bt87x0: Using board 1, analog, digital
(rate 32000 Hz)
[4.836178] Linux video capture interface: v2.00
[4.997442] bttv: driver version 0.9.19 loaded
[4.997446] bttv: using 8 buffers with 2080k (520 pages) each for capture
[5.001339] bttv: Bt8xx card found (0)
[5.001482] bttv: 0: Bt878 (rev 2) at :04:07.0, irq: 20, latency: 32,
mmio: 0xd0001000
[5.001499] bttv: 0: detected: Hauppauge WinTV [card=10], PCI subsystem ID
is 0070:13eb
[5.001501] bttv: 0: using: Hauppauge (bt878) [card=10,autodetected]
[5.004174] bttv: 0: Hauppauge/Voodoo msp34xx: reset line init [5]
[5.039038] tveeprom 9-0050: Hauppauge model 61334, rev B2 , serial#
3211125
[5.039040] tveeprom 9-0050: tuner model is Philips FM1216 (idx 21, type 5)
[5.039042] tveeprom 9-0050: TV standards PAL(B/G) (eeprom 0x04)
[5.039043] tveeprom 9-0050: audio processor is MSP3415 (idx 6)
[5.039044] tveeprom 9-0050: has radio
[5.039045] bttv: 0: Hauppauge eeprom indicates model#61334
[5.039046] bttv: 0: tuner type=5
[5.073212] msp3400 9-0040: MSP3410D-B4 found @ 0x80 (bt878 #0 [sw])
[5.073217] msp3400 9-0040: msp3400 supports nicam, mode is autodetect
[5.114390] tuner 9-0061: Tuner -1 found with type(s) Radio TV.
[5.144779] tuner-simple 9-0061: creating new instance
[5.144782] tuner-simple 9-0061: type set to 5 (Philips PAL_BG (FI1216 and
compatibles))
[5.148047] ==
[5.148048] [ INFO: possible circular locking dependency detected ]
[5.148050] 3.16.0-rc6+ #109 Tainted: G OE
[5.148051] ---
[5.148052] systemd-udevd/545 is trying to acquire lock:
[5.148053] (msp3400_driver:799:(hdl)-_lock){+.+.+.}, at:
[a0282295] find_ref_lock+0x25/0x60 [videodev]
[5.148062]
but task is already holding lock:
[5.148063] (bttv_driver:4066:(hdl)-_lock){+.+...}, at:
[a028323d] v4l2_ctrl_handler_setup+0x3d/0x130 [videodev]
[5.148069]
which lock already depends on the new lock.
[5.148070]
the existing dependency chain (in reverse order) is:
[5.148071]
- #1 (bttv_driver:4066:(hdl)-_lock){+.+...}:
[5.148074][81102054] lock_acquire+0xa4/0x1d0
[5.148077][8180b425] mutex_lock_nested+0x85/0x440
[5.148080][a0282295] find_ref_lock+0x25/0x60 [videodev]
[5.148083][a0284b36] handler_new_ref+0x46/0x1d0
[videodev]
[5.148087][a02857af] v4l2_ctrl_add_handler+0x9f/0xe0
[videodev]
[5.148091][a027ebf6]
v4l2_device_register_subdev+0xe6/0x1e0 [videodev]
[5.148094][a029f743]
v4l2_i2c_new_subdev_board+0x93/0x110 [v4l2_common]
[5.148097][a029f82a] v4l2_i2c_new_subdev+0x6a/0x90
[v4l2_common]
[5.148099][a032a8c6] bttv_init_card2+0x1486/0x1990
[bttv]
[5.148106][a032781d] bttv_probe+0x78d/0xd20 [bttv]
[5.148110][8142e515] local_pci_probe+0x45/0xa0
[5.148113][8142f959] pci_device_probe+0xf9/0x150
[5.148115][8151e003] driver_probe_device+0xa3/0x400
[5.148119][8151e42b] __driver_attach+0x8b/0x90
[5.148121][8151bc83] bus_for_each_dev+0x73/0xc0
[5.148123][8151da5e] driver_attach+0x1e/0x20
[5.148125][8151d628] bus_add_driver+0x188/0x260
[5.148128][8151ef04] driver_register+0x64/0xf0
[5.148130][8142ddc0] __pci_register_driver+0x60/0x70
[5.148132][a03470cf] bttv_init_module+0xcf/0xe9 [bttv]
[5.148136][81002148] do_one_initcall+0xd8/0x210
[5.148139][8113a600] load_module+0x2110/0x2740
[5.148142][8113ae16] SyS_finit_module+0xa6/0xe0
[5.148143][81810069] system_call_fastpath+0x16/0x1b
[5.148146]
- #0 (msp3400_driver:799:(hdl)-_lock){+.+.+.}:
[5.148148][8110158b] __lock_acquire+0x1abb/0x1ca0
[5.148150][81102054] lock_acquire+0xa4/0x1d0
[5.148152][8180b425] mutex_lock_nested+0x85/0x440
[5.148153][a0282295] find_ref_lock+0x25/0x60 [videodev]
[5.148157][a02822de] v4l2_ctrl_find+0xe/0x30 [videodev]
[5.148161]
Re: omap3isp with DM3730 not working?!
On Mon, Jul 28, 2014 at 12:29 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Enrico, On Monday 28 July 2014 10:30:17 Enrico wrote: On Mon, Jul 28, 2014 at 9:20 AM, Sakari Ailus sakari.ai...@iki.fi wrote: On Thu, Jul 24, 2014 at 05:57:30PM +0200, Enrico wrote: On Thu, Jul 24, 2014 at 5:34 PM, Michael Dietschi wrote: Hello, I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253. It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :( I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c). I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this. Can someone please give me a hint? It's strange that you get the vd1_irq because it should not be set by the driver and never trigger... Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame. Hi Sakari, that's true in normal mode, but with bt656 patches VD1 is not used. That's not correct, VD1 is used in both modes. In BT.656 mode VD1 is even used to increment the frame counter in place of the HS_VS interrupt. ...in your new patches. But sleepyrobot's are the old ones and i bet Michael is using those patches. 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
[PATCH] si2135: Declare the structs even if frontend is not enabled
As reported by Kbuildtest:
In file included from drivers/media/usb/cx231xx/cx231xx-dvb.c:35:0:
drivers/media/dvb-frontends/si2165.h:57:9: warning: 'struct si2165_config'
declared inside parameter list [enabled by default]
struct i2c_adapter *i2c)
^
drivers/media/dvb-frontends/si2165.h:57:9: warning: its scope is only this
definition or declaration, which is probably not what you want [enabled by
default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:157:21: error: variable
'hauppauge_930C_HD_1113xx_si2165_config' has initializer but incomplete type
static const struct si2165_config hauppauge_930C_HD_1113xx_si2165_config = {
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:158:2: error: unknown field
'i2c_addr' specified in initializer
.i2c_addr = 0x64,
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:158:2: warning: excess elements in
struct initializer [enabled by default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:158:2: warning: (near initialization
for 'hauppauge_930C_HD_1113xx_si2165_config') [enabled by default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:159:2: error: unknown field
'chip_mode' specified in initializer
.chip_mode = SI2165_MODE_PLL_XTAL,
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:159:15: error:
'SI2165_MODE_PLL_XTAL' undeclared here (not in a function)
.chip_mode = SI2165_MODE_PLL_XTAL,
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:159:2: warning: excess elements in
struct initializer [enabled by default]
.chip_mode = SI2165_MODE_PLL_XTAL,
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:159:2: warning: (near initialization
for 'hauppauge_930C_HD_1113xx_si2165_config') [enabled by default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:160:2: error: unknown field
'ref_freq_Hz' specified in initializer
.ref_freq_Hz = 1600,
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:160:2: warning: excess elements in
struct initializer [enabled by default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:160:2: warning: (near initialization
for 'hauppauge_930C_HD_1113xx_si2165_config') [enabled by default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:163:21: error: variable
'pctv_quatro_stick_1114xx_si2165_config' has initializer but incomplete type
static const struct si2165_config pctv_quatro_stick_1114xx_si2165_config = {
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:164:2: error: unknown field
'i2c_addr' specified in initializer
.i2c_addr = 0x64,
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:164:2: warning: excess elements in
struct initializer [enabled by default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:164:2: warning: (near initialization
for 'pctv_quatro_stick_1114xx_si2165_config') [enabled by default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:165:2: error: unknown field
'chip_mode' specified in initializer
.chip_mode = SI2165_MODE_PLL_EXT,
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:165:15: error: 'SI2165_MODE_PLL_EXT'
undeclared here (not in a function)
.chip_mode = SI2165_MODE_PLL_EXT,
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:165:2: warning: excess elements in
struct initializer [enabled by default]
.chip_mode = SI2165_MODE_PLL_EXT,
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:165:2: warning: (near initialization
for 'pctv_quatro_stick_1114xx_si2165_config') [enabled by default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:166:2: error: unknown field
'ref_freq_Hz' specified in initializer
.ref_freq_Hz = 2400,
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:166:2: warning: excess elements in
struct initializer [enabled by default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:166:2: warning: (near initialization
for 'pctv_quatro_stick_1114xx_si2165_config') [enabled by default]
drivers/media/usb/cx231xx/cx231xx-dvb.c: In function 'dvb_init':
drivers/media/usb/cx231xx/cx231xx-dvb.c:731:3: warning: passing argument 1
of 'si2165_attach' from incompatible pointer type [enabled by default]
dev-dvb-frontend = dvb_attach(si2165_attach,
^
In file included from drivers/media/usb/cx231xx/cx231xx-dvb.c:35:0:
drivers/media/dvb-frontends/si2165.h:55:36: note: expected 'const struct
si2165_config *' but argument is of type 'const struct si2165_config *'
static inline struct dvb_frontend *si2165_attach(
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:764:3: warning: passing argument 1
of 'si2165_attach' from incompatible pointer type [enabled by default]
dev-dvb-frontend = dvb_attach(si2165_attach,
^
In file included from drivers/media/usb/cx231xx/cx231xx-dvb.c:35:0:
drivers/media/dvb-frontends/si2165.h:55:36: note: expected 'const struct
si2165_config *' but argument is of type 'const struct si2165_config *'
static inline struct dvb_frontend *si2165_attach(
^
That happens
Re: [PATCH/RFC v4 07/21] of: add of_node_ncmp wrapper
On Fri, 11 Jul 2014 16:04:10 +0200, Jacek Anaszewski j.anaszew...@samsung.com wrote: The wrapper for strnicmp is required for checking whether a node has expected prefix. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Grant Likely grant.lik...@linaro.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Michal Simek mon...@monstr.eu --- include/linux/of.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/of.h b/include/linux/of.h index 692b56c..9a53eea 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -199,6 +199,7 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size) #define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2)) #define of_prop_cmp(s1, s2) strcmp((s1), (s2)) #define of_node_cmp(s1, s2) strcasecmp((s1), (s2)) +#define of_node_ncmp(s1, s2, n) strnicmp((s1), (s2), (n)) #endif Don't forget to add an of_node_ncmp() define to arch/sparc/include/asm/prom.h. Sparc has its own rules. g. -- 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 vb2 warnings
On 07/25/2014 06:20 PM, Frank Schäfer wrote: Hi Hans, I'm getting the following warnings with the em28xx driver on streaming stop: [ 7597.346168] WARNING: CPU: 1 PID: 3730 at drivers/media/v4l2-core/videobuf2-core.c:2126 __vb2_queue_cancel+0xf5/0x150 [videobuf2_core]() [ 7597.346171] Modules linked in: em28xx_rc snd_usb_audio ov2640 soc_camera soc_mediabus em28xx_v4l videobuf2_core videobuf2_vmalloc videobuf2_memops snd_usbmidi_lib snd_rawmidi em28xx xt_pkttype xt_LOG xt_limit bnep af_packet bluetooth ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables rc_hauppauge ir_kbd_i2c arc4 tuner_simple tuner_types rtl8187 mac80211 tda9887 fuse tda8290 snd_hda_codec_analog tuner snd_hda_codec_hdmi snd_hda_codec_generic sr_mod cdrom snd_hda_intel snd_hda_controller snd_hda_codec msp3400 snd_hwdep cfg80211 bttv snd_pcm v4l2_common snd_seq ppdev powernow_k8 [ 7597.346230] snd_timer snd_seq_device pcspkr videodev serio_raw snd firewire_ohci firewire_core k8temp rfkill eeprom_93cx6 i2c_nforce2 usb_storage videobuf_dma_sg videobuf_core btcx_risc pata_jmicron rc_core usblp soundcore forcedeth crc_itu_t tveeprom ata_generic floppy sata_nv pata_amd asus_atk0110 parport_pc parport button sg dm_mod autofs4 radeon ttm drm_kms_helper drm fan thermal processor thermal_sys i2c_algo_bit scsi_dh_hp_sw scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh [ 7597.346268] CPU: 1 PID: 3730 Comm: qv4l2 Tainted: GW 3.16.0-rc6-0.1-desktop+ #18 [ 7597.346271] Hardware name: System manufacturer System Product Name [...] [ 7597.346273] e09d9d3c c0780b62 e09d9d6c c0243359 c091deec [ 7597.346279] 0001 0e92 f870a4a4 084e f87054e5 f87054e5 e6905040 e2f61640 [ 7597.346285] ef85f4c8 e09d9d7c c02433ed 0009 e09d9d94 f87054e5 e2ef6550 [ 7597.346290] Call Trace: [ 7597.346300] [c0780b62] dump_stack+0x48/0x69 [ 7597.346305] [c0243359] warn_slowpath_common+0x79/0x90 [ 7597.346312] [f87054e5] ? __vb2_queue_cancel+0xf5/0x150 [videobuf2_core] [ 7597.346318] [f87054e5] ? __vb2_queue_cancel+0xf5/0x150 [videobuf2_core] [ 7597.346322] [c02433ed] warn_slowpath_null+0x1d/0x20 [ 7597.346327] [f87054e5] __vb2_queue_cancel+0xf5/0x150 [videobuf2_core] [ 7597.346333] [f8706b35] vb2_internal_streamoff+0x35/0x90 [videobuf2_core] [ 7597.346338] [c04b7cbb] ? _copy_from_user+0x3b/0x50 [ 7597.346344] [f8706bc5] vb2_streamoff+0x35/0x60 [videobuf2_core] [ 7597.346350] [c0699433] ? __sys_recvmsg+0x43/0x70 [ 7597.346356] [f8706c27] vb2_ioctl_streamoff+0x37/0x40 [videobuf2_core] [ 7597.346371] [f7c56805] v4l_streamoff+0x15/0x20 [videodev] [ 7597.346382] [f7c5962c] __video_do_ioctl+0x1fc/0x280 [videodev] [ 7597.346394] [f7c5908e] video_usercopy+0x1ce/0x550 [videodev] [ 7597.346399] [c038aac7] ? fsnotify+0x1e7/0x2b0 [ 7597.346410] [f7c59422] video_ioctl2+0x12/0x20 [videodev] [ 7597.346421] [f7c59430] ? video_ioctl2+0x20/0x20 [videodev] [ 7597.346430] [f7c55615] v4l2_ioctl+0xe5/0x120 [videodev] [ 7597.346439] [f7c55530] ? v4l2_open+0xf0/0xf0 [videodev] [ 7597.346443] [c03668e2] do_vfs_ioctl+0x2e2/0x4d0 [ 7597.346449] [c0356a3c] ? vfs_write+0x13c/0x1c0 [ 7597.346452] [c03575df] ? vfs_writev+0x2f/0x50 [ 7597.346455] [c0366b28] SyS_ioctl+0x58/0x80 [ 7597.346460] [c07870ec] sysenter_do_call+0x12/0x16 [ 7597.346463] ---[ end trace 16421a251cba8f63 ]--- There have been quite a few vb2 changes recently. Any idea what's wrong ? Could you take a look at this ? OK, I looked at it: the problem is in get_next_buf() and finish_field_prepare_next(). In get_next_buf() the driver gets a buffer from the active list and deletes it from that list. In finish_field_prepare_next() that buffer is given back to vb2 via finish_buffer(). But if you stop streaming and em28xx_stop_streaming() is called, then that buffer that is being processed isn't part of the active list anymore and so it is never given back. em28xx_stop_streaming() should give that buffer back as well, and that will keep everything in balance. The easiest solution seems to be to move the list_del() call from get_next_buf() to finish_buffer(). It seemed to work in a quick test, but I haven't looked at vbi support or corner cases. I leave that to you :-) Regards, Hans -- 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/DVB: dvb-usb-v2: Update firmware and driver for performance of ITEtech IT9135
Moikka Bimow!
I did a lot of testing today for that patch. I used only single tuner
device having IT9135 BX chip. Running it against modulator I saw
sensitivity was increased around 5 dBm (TX power).
However, I am not 100% happy with that patch. See comments below.
On 07/25/2014 11:11 AM, Bimow Chen wrote:
Fix performance issue of IT9135 AX and BX chip versions.
0001-Update-firmware-and-driver-for-performance-of-ITEtec.patch
From 57fe102419e83e73080af15cc3ad3fe241d7f8b4 Mon Sep 17 00:00:00 2001
From: Bimow Chenbimow.c...@ite.com.tw
Date: Thu, 24 Jul 2014 13:23:39 +0800
Subject: [PATCH 1/1] Update firmware and driver for performance of ITEtech
IT9135
Fix performance issue of IT9135 AX and BX chip versions.
Signed-off-by: Bimow Chenbimow.c...@ite.com.tw
Signed-off-by: Bimow Chenbimow.c...@ite.com.tw
---
Documentation/dvb/get_dvb_firmware| 24 +---
drivers/media/dvb-frontends/af9033.c | 18 ++
drivers/media/dvb-frontends/af9033_priv.h | 20 +---
drivers/media/tuners/tuner_it913x.c |6 --
drivers/media/usb/dvb-usb-v2/af9035.c | 11 +++
5 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index d91b8be..efa100a 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -708,23 +708,25 @@ sub drxk_terratec_htc_stick {
}
sub it9135 {
- my $sourcefile = dvb-usb-it9135.zip;
- my $url =http://www.ite.com.tw/uploads/firmware/v3.6.0.0/$sourcefile;;
- my $hash = 1e55f6c8833f1d0ae067c2bb2953e6a9;
- my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 0);
- my $outfile = dvb-usb-it9135.fw;
+ my $url =http://www.ite.com.tw/uploads/firmware/v3.25.0.0/;;
+ my $file1 = dvb-usb-it9135-01.zip;
my $fwfile1 = dvb-usb-it9135-01.fw;
+ my $hash1 = 02fcf11174eda84745dae7e61c5ff9ba;
+ my $file2 = dvb-usb-it9135-02.zip;
my $fwfile2 = dvb-usb-it9135-02.fw;
+ my $hash2 = d5e1437dc24358578e07999475d4cac9;
checkstandard();
- wgetfile($sourcefile, $url);
- unzip($sourcefile, $tmpdir);
- verify($tmpdir/$outfile, $hash);
- extract($tmpdir/$outfile, 64, 8128, $fwfile1);
- extract($tmpdir/$outfile, 12866, 5817, $fwfile2);
+ wgetfile($file1, $url . $file1);
+ unzip($file1, );
+ verify($fwfile1, $hash1);
+
+ wgetfile($file2, $url . $file2);
+ unzip($file2, );
+ verify($fwfile2, $hash2);
- $fwfile1 $fwfile2
+ $file1 $file2
}
sub tda10071 {
Split that get_dvb_firmware stuff to own separate patch.
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index be4bec2..e96e655 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -274,6 +274,22 @@ static int af9033_init(struct dvb_frontend *fe)
{ 0x800045, state-cfg.adc_multiplier, 0xff },
};
+ /* power up tuner - for performance */
+ switch (state-cfg.tuner) {
+ case AF9033_TUNER_IT9135_38:
+ case AF9033_TUNER_IT9135_51:
+ case AF9033_TUNER_IT9135_52:
+ case AF9033_TUNER_IT9135_60:
+ case AF9033_TUNER_IT9135_61:
+ case AF9033_TUNER_IT9135_62:
+ ret = af9033_wr_reg(state, 0x80ec40, 0x1);
+ ret |= af9033_wr_reg(state, 0x80fba8, 0x0);
+ ret |= af9033_wr_reg(state, 0x80ec57, 0x0);
+ ret |= af9033_wr_reg(state, 0x80ec58, 0x0);
+ if (ret 0)
+ goto err;
+ }
+
You moved that initialization here from tuner_it913x driver. What I
understand register range 0xec00 - 0xefff belongs to integrated RF
tuner. This is demodulator driver and I really like to separate
functionality as much as possible per correct driver.
I did some testing and find out the actual need here is 0xfba8 register,
which is needed to set before FSM is triggered. That reg is 0 by
default, but tuner_it913x driver set it to 1 during sleep.
Name of 0xfba8 register is p_reg_dyn0_clk, which indicates it is some
sort of clock. I don't have documentation... Maybe it should be
controlled by demod driver power-management?
All the other registers should just go back to tuner_it913x driver.
/* program clock control */
clock_cw = af9033_div(state, state-cfg.clock, 100ul, 19ul);
buf[0] = (clock_cw 0) 0xff;
@@ -440,6 +456,8 @@ static int af9033_init(struct dvb_frontend *fe)
case AF9033_TUNER_IT9135_61:
case AF9033_TUNER_IT9135_62:
ret = af9033_wr_reg(state, 0x80, 0x01);
+ ret |= af9033_wr_reg(state, 0x00d827, 0x00);
+ ret |= af9033_wr_reg(state, 0x00d829, 0x00);
Useless change. Those registers are already set few lines earlier.
if (ret 0)
goto err;
i.MX6 status for IPU/VPU/GPU
Hi there ! We have a custom board, based on i.MX6 SoC. We are currently using Freescale's release of Linux, but this is a 3.10.17 kernel, and several drivers are lacking (adv7611 for instance) or badly written (all the MXC part). As we want to have nice things :) we would like to use a mainline kernel, or at least a tree which can be mainlined. It seems (#v4l told me so) that some people (Steeve :) ?) are working on a rewriting of the IPU and all DRM part for i.MX6. What is the current status (compared to Freescale's release maybe) ? And what can we expect in a near future ? Maybe, how can we help too ? Thanks, JM -- 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
[linuxtv-media:master 488/499] drivers/media/dvb-frontends/si2165.c:324:10-11: WARNING: return of 0/1 in function 'si2165_wait_init_done' with return type bool
tree: git://linuxtv.org/media_tree.git master
head: 7f196789b3ffee243b681d3e7dab8890038db856
commit: 36efec48e2e6016e05364906720a0ec350a5d768 [488/499] [media] cx23885: Add
si2165 support for HVR-5500
coccinelle warnings: (new ones prefixed by )
drivers/media/dvb-frontends/si2165.c:324:10-11: WARNING: return of 0/1 in
function 'si2165_wait_init_done' with return type bool
--
drivers/media/dvb-frontends/si2165.c:925:3-32: duplicated argument to or |
Please consider folding the attached diff :-)
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
From: Fengguang Wu fengguang...@intel.com
Subject: [PATCH] [media] cx23885: fix coccinelle warnings
TO: Mauro Carvalho Chehab m.che...@samsung.com
CC: Matthias Schwarzott z...@gentoo.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
drivers/media/dvb-frontends/si2165.c:324:10-11: WARNING: return of 0/1 in function 'si2165_wait_init_done' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci
CC: Matthias Schwarzott z...@gentoo.org
CC: Mauro Carvalho Chehab m.che...@samsung.com
Signed-off-by: Fengguang Wu fengguang...@intel.com
---
si2165.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -321,7 +321,7 @@ static bool si2165_wait_init_done(struct
for (i = 0; i 3; ++i) {
si2165_readreg8(state, 0x0054, val);
if (val == 0x01)
- return 0;
+ return false;
usleep_range(1000, 5);
}
dev_err(state-i2c-dev, %s: init_done was not set\n,
[PATCH 3/4] au0828: add support for IR on HVR-950Q
HVR-950Q uses an I2C remote controller at address 0x47 (7-bits
notation). Add support for it.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/usb/au0828/Kconfig| 7 +
drivers/media/usb/au0828/Makefile | 4 +
drivers/media/usb/au0828/au0828-cards.c | 1 +
drivers/media/usb/au0828/au0828-core.c | 25 +-
drivers/media/usb/au0828/au0828-input.c | 391
drivers/media/usb/au0828/au0828.h | 11 +
6 files changed, 435 insertions(+), 4 deletions(-)
create mode 100644 drivers/media/usb/au0828/au0828-input.c
diff --git a/drivers/media/usb/au0828/Kconfig b/drivers/media/usb/au0828/Kconfig
index fe48403eadd0..1d410ac8f9a8 100644
--- a/drivers/media/usb/au0828/Kconfig
+++ b/drivers/media/usb/au0828/Kconfig
@@ -27,3 +27,10 @@ config VIDEO_AU0828_V4L2
Choose Y here to include support for v4l2 analog video
capture within the au0828 driver.
+
+config VIDEO_AU0828_RC
+ bool AU0828 Remote Controller support
+ depends on RC_CORE
+ depends on VIDEO_AU0828
+ ---help---
+ Enables Remote Controller support on au0828 driver.
diff --git a/drivers/media/usb/au0828/Makefile
b/drivers/media/usb/au0828/Makefile
index be3bdf698022..3dc7539a5c4e 100644
--- a/drivers/media/usb/au0828/Makefile
+++ b/drivers/media/usb/au0828/Makefile
@@ -4,6 +4,10 @@ ifeq ($(CONFIG_VIDEO_AU0828_V4L2),y)
au0828-objs += au0828-video.o au0828-vbi.o
endif
+ifeq ($(CONFIG_VIDEO_AU0828_RC),y)
+ au0828-objs += au0828-input.o
+endif
+
obj-$(CONFIG_VIDEO_AU0828) += au0828.o
ccflags-y += -Idrivers/media/tuners
diff --git a/drivers/media/usb/au0828/au0828-cards.c
b/drivers/media/usb/au0828/au0828-cards.c
index 3a7924044a87..2c6b7da137ed 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -71,6 +71,7 @@ struct au0828_board au0828_boards[] = {
.name = Hauppauge HVR950Q,
.tuner_type = TUNER_XC5000,
.tuner_addr = 0x61,
+ .has_ir_i2c = 1,
/* The au0828 hardware i2c implementation does not properly
support the xc5000's i2c clock stretching. So we need to
lower the clock frequency enough where the 15us clock
diff --git a/drivers/media/usb/au0828/au0828-core.c
b/drivers/media/usb/au0828/au0828-core.c
index ab45a6f9dcc9..56025e689442 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -32,10 +32,12 @@
* 2 = USB handling
* 4 = I2C related
* 8 = Bridge related
+ * 16 = IR related
*/
int au0828_debug;
module_param_named(debug, au0828_debug, int, 0644);
-MODULE_PARM_DESC(debug, enable debug messages);
+MODULE_PARM_DESC(debug,
+set debug bitmask: 1=general, 2=USB, 4=I2C, 8=bridge, 16=IR);
static unsigned int disable_usb_speed_check;
module_param(disable_usb_speed_check, int, 0444);
@@ -151,6 +153,9 @@ static void au0828_usb_disconnect(struct usb_interface
*interface)
dprintk(1, %s()\n, __func__);
+#ifdef CONFIG_VIDEO_AU0828_RC
+ au0828_rc_unregister(dev);
+#endif
/* Digital TV */
au0828_dvb_unregister(dev);
@@ -261,9 +266,15 @@ static int au0828_usb_probe(struct usb_interface
*interface,
pr_err(%s() au0282_dev_register failed\n,
__func__);
+#ifdef CONFIG_VIDEO_AU0828_RC
+ /* Remote controller */
+ au0828_rc_register(dev);
+#endif
- /* Store the pointer to the au0828_dev so it can be accessed in
- au0828_usb_disconnect */
+ /*
+* Store the pointer to the au0828_dev so it can be accessed in
+* au0828_usb_disconnect
+*/
usb_set_intfdata(interface, dev);
printk(KERN_INFO Registered device AU0828 [%s]\n,
@@ -279,6 +290,8 @@ static struct usb_driver au0828_usb_driver = {
.probe = au0828_usb_probe,
.disconnect = au0828_usb_disconnect,
.id_table = au0828_usb_id_table,
+
+ /* FIXME: Add suspend and resume functions */
};
static int __init au0828_init(void)
@@ -298,6 +311,10 @@ static int __init au0828_init(void)
printk(KERN_INFO %s() Bridge Debugging is enabled\n,
__func__);
+ if (au0828_debug 16)
+ printk(KERN_INFO %s() IR Debugging is enabled\n,
+ __func__);
+
printk(KERN_INFO au0828 driver loaded\n);
ret = usb_register(au0828_usb_driver);
@@ -318,4 +335,4 @@ module_exit(au0828_exit);
MODULE_DESCRIPTION(Driver for Auvitek AU0828 based products);
MODULE_AUTHOR(Steven Toth st...@linuxtv.org);
MODULE_LICENSE(GPL);
-MODULE_VERSION(0.0.2);
+MODULE_VERSION(0.0.3);
diff --git a/drivers/media/usb/au0828/au0828-input.c
b/drivers/media/usb/au0828/au0828-input.c
new file mode 100644
index ..d527446d008f
--- /dev/null
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -0,0
[PATCH 4/4] ir-rc5-decoder: print the failed count
When the decode fails, print on what bit this happened. This helps to discover what's going wrong when fixing an IR decoding bug. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- drivers/media/rc/ir-rc5-decoder.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/rc/ir-rc5-decoder.c b/drivers/media/rc/ir-rc5-decoder.c index 93168daf82eb..2ef763928ca4 100644 --- a/drivers/media/rc/ir-rc5-decoder.c +++ b/drivers/media/rc/ir-rc5-decoder.c @@ -178,8 +178,8 @@ again: } out: - IR_dprintk(1, RC5(x/sz) decode failed at state %i (%uus %s)\n, - data-state, TO_US(ev.duration), TO_STR(ev.pulse)); + IR_dprintk(1, RC5(x/sz) decode failed at state %i count %d (%uus %s)\n, + data-state, data-count, TO_US(ev.duration), TO_STR(ev.pulse)); data-state = STATE_INACTIVE; return -EINVAL; } -- 1.9.3 -- 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] rc-main: allow raw protocol drivers to restrict the allowed protos
On some hardware (au0828/au8522), the hardware is broken with
regards to the initial pulse detection. So, the driver needs to
produce a fake start pulse. That limits the acceptable protocols,
as it is not possible to produce a fake pulse that would cover
all supported protocols.
So, allow the driver to explicitly set the allowed protocols.
If the driver doesn't specify, keep the old behavior.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/rc/rc-main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index dfceeb4e34a8..a7991c7d010a 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -859,10 +859,9 @@ static ssize_t show_protocols(struct device *device,
if (fattr-type == RC_FILTER_NORMAL) {
enabled = dev-enabled_protocols;
- if (dev-raw)
+ allowed = dev-allowed_protocols;
+ if (dev-raw !allowed)
allowed = ir_raw_get_allowed_protocols();
- else
- allowed = dev-allowed_protocols;
} else {
enabled = dev-enabled_wakeup_protocols;
allowed = dev-allowed_wakeup_protocols;
--
1.9.3
--
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/4] au0828: improve I2C speed
Commits 21dc61d3c0a4 and 7a1dd50b89d4 reduced the board I2C
speed to 20 MHz by default, due to a I2C stretch issue:
while xc5000 uses i2c stretch when a command is sent to it,
au0828 doesn't support this feature.
However, this is needed only for Xceive tuners. The other
I2C devices can work at the max speed.
So, revert the workarounds at board level, handling it at
I2C level, only when talking with xc5000.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/usb/au0828/au0828-cards.c | 6 +++---
drivers/media/usb/au0828/au0828-i2c.c | 23 +--
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-cards.c
b/drivers/media/usb/au0828/au0828-cards.c
index 7fdadf9bc90b..3a7924044a87 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -46,7 +46,7 @@ struct au0828_board au0828_boards[] = {
.name = Hauppauge HVR850,
.tuner_type = TUNER_XC5000,
.tuner_addr = 0x61,
- .i2c_clk_divider = AU0828_I2C_CLK_20KHZ,
+ .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
.input = {
{
.type = AU0828_VMUX_TELEVISION,
@@ -77,7 +77,7 @@ struct au0828_board au0828_boards[] = {
stretch fits inside of a normal clock cycle, or else the
au0828 fails to set the STOP bit. A 30 KHz clock puts the
clock pulse width at 18us */
- .i2c_clk_divider = AU0828_I2C_CLK_20KHZ,
+ .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
.input = {
{
.type = AU0828_VMUX_TELEVISION,
@@ -108,7 +108,7 @@ struct au0828_board au0828_boards[] = {
.name = DViCO FusionHDTV USB,
.tuner_type = UNSET,
.tuner_addr = ADDR_UNSET,
- .i2c_clk_divider = AU0828_I2C_CLK_20KHZ,
+ .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
},
[AU0828_BOARD_HAUPPAUGE_WOODBURY] = {
.name = Hauppauge Woodbury,
diff --git a/drivers/media/usb/au0828/au0828-i2c.c
b/drivers/media/usb/au0828/au0828-i2c.c
index 17ec3651b10e..ac8e94795f48 100644
--- a/drivers/media/usb/au0828/au0828-i2c.c
+++ b/drivers/media/usb/au0828/au0828-i2c.c
@@ -141,25 +141,28 @@ static int i2c_sendbytes(struct i2c_adapter *i2c_adap,
{
int i, strobe = 0;
struct au0828_dev *dev = i2c_adap-algo_data;
+ u8 i2c_speed = dev-board.i2c_clk_divider;
dprintk(4, %s()\n, __func__);
au0828_write(dev, AU0828_I2C_MULTIBYTE_MODE_2FF, 0x01);
/* Set the I2C clock */
+
if (((dev-board.tuner_type == TUNER_XC5000) ||
(dev-board.tuner_type == TUNER_XC5000C))
- (dev-board.tuner_addr == msg-addr)
- (msg-len == 64)) {
- /* Hack to speed up firmware load. The xc5000 lets us do up
- to 400 KHz when in firmware download mode */
- au0828_write(dev, AU0828_I2C_CLK_DIVIDER_202,
-AU0828_I2C_CLK_250KHZ);
- } else {
- /* Use the i2c clock speed in the board configuration */
- au0828_write(dev, AU0828_I2C_CLK_DIVIDER_202,
-dev-board.i2c_clk_divider);
+ (dev-board.tuner_addr == msg-addr)) {
+ /*
+* Due to I2C clock stretch, we need to use a lower speed
+* on xc5000 for commands. However, firmware transfer can
+* speed up to 400 KHz.
+*/
+ if (msg-len == 64)
+ i2c_speed = AU0828_I2C_CLK_250KHZ;
+ else
+ i2c_speed = AU0828_I2C_CLK_20KHZ;
}
+ au0828_write(dev, AU0828_I2C_CLK_DIVIDER_202, i2c_speed);
/* Hardware needs 8 bit addresses */
au0828_write(dev, AU0828_I2C_DEST_ADDR_203, msg-addr 1);
--
1.9.3
--
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 0/4] au0828: add support for IR decoding
au0828 chipset have a built-in IR decoder, at au8522. Add support for it to decode both NEC and RC5 protocols. Unfortunately, it is not possible to have a fully generic IR decode, as this chipset is not able to detect the initial pulse. Mauro Carvalho Chehab (4): au0828: improve I2C speed rc-main: allow raw protocol drivers to restrict the allowed protos au0828: add support for IR on HVR-950Q ir-rc5-decoder: print the failed count drivers/media/rc/ir-rc5-decoder.c | 4 +- drivers/media/rc/rc-main.c | 5 +- drivers/media/usb/au0828/Kconfig| 7 + drivers/media/usb/au0828/Makefile | 4 + drivers/media/usb/au0828/au0828-cards.c | 7 +- drivers/media/usb/au0828/au0828-core.c | 25 +- drivers/media/usb/au0828/au0828-i2c.c | 23 +- drivers/media/usb/au0828/au0828-input.c | 391 drivers/media/usb/au0828/au0828.h | 11 + 9 files changed, 455 insertions(+), 22 deletions(-) create mode 100644 drivers/media/usb/au0828/au0828-input.c -- 1.9.3 -- 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
[GIT PULL] soc-camera for 3.17
Hi Mauro, Sorry for a delayed pull-request... A couple of DT documentation patches, I've been recently told, that for such cases, where no new bindings are added, acks from DT-maintainers aren't compulsory. The following changes since commit fe3afdce0da93aad256183bf40ff9c0e86ae8a72: Merge branch 'patchwork' into to_next (2014-07-22 22:12:07 -0300) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.17-1 for you to fetch changes up to 196171191371705756fa69c1c99e97fb3ee1bcf2: media: atmel-isi: add primary DT support (2014-07-28 20:25:46 +0200) Ben Dooks (2): soc_camera: add support for dt binding soc_camera drivers rcar_vin: add devicetree support Josh Wu (3): media: atmel-isi: add v4l2 async probe support media: atmel-isi: convert the pdata from pointer to structure media: atmel-isi: add primary DT support Robert Jarzmik (4): media: mt9m111: add device-tree documentation media: soc_camera: pxa_camera documentation device-tree support media: mt9m111: add device-tree suppport media: pxa_camera device-tree support .../devicetree/bindings/media/atmel-isi.txt| 51 .../devicetree/bindings/media/i2c/mt9m111.txt | 28 + .../devicetree/bindings/media/pxa-camera.txt | 43 +++ .../devicetree/bindings/media/rcar_vin.txt | 86 ++ drivers/media/i2c/soc_camera/mt9m111.c | 12 ++ drivers/media/platform/soc_camera/atmel-isi.c | 90 -- drivers/media/platform/soc_camera/pxa_camera.c | 81 - drivers/media/platform/soc_camera/rcar_vin.c | 72 ++-- drivers/media/platform/soc_camera/soc_camera.c | 129 - include/media/atmel-isi.h | 4 + 10 files changed, 574 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt create mode 100644 Documentation/devicetree/bindings/media/i2c/mt9m111.txt create mode 100644 Documentation/devicetree/bindings/media/pxa-camera.txt create mode 100644 Documentation/devicetree/bindings/media/rcar_vin.txt Thanks Guennadi -- 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: i.MX6 status for IPU/VPU/GPU
Hi, On Mon, Jul 28, 2014 at 06:24:45PM +0200, Jean-Michel Hautbois wrote: We have a custom board, based on i.MX6 SoC. We are currently using Freescale's release of Linux, but this is a 3.10.17 kernel, and several drivers are lacking (adv7611 for instance) or badly written (all the MXC part). As we want to have nice things :) we would like to use a mainline kernel, or at least a tree which can be mainlined. It seems (#v4l told me so) that some people (Steeve :) ?) are working on a rewriting of the IPU and all DRM part for i.MX6. What is the current status (compared to Freescale's release maybe) ? And what can we expect in a near future? Maybe, how can we help too ? Pengutronix is continuously working on mainlining more parts of the i.MX6 video and graphics subsystem, including the components you have mentioned. We are posting patches here when they are ready for mainline review. Regards, Robert (for commercial help, please contact me by email) -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 0/4] au0828: add support for IR decoding
Nobody can help you at the ML. AFAIKT, none of the VGER admins subscribe this list. Yet, the procedure is very simple for you to do... just send an email to the VGER robot (majord...@vger.kernel.org) from the e-mail you're subscribed with: unsubscribe linux-media on its body. No need to add a subject to such email. It will send you a confirmation e-mail. Reply to it with the authentication ID provided by the robot and you'll be unsubscribed. Regards, Mauro Em Mon, 28 Jul 2014 11:40:08 -0700 Raymond Jender ray...@yahoo.com escreveu: Reading the FAQ page, there are a ton of things not to do in this list but only one thing to do if you don't want this list anymore and it doesn't fucking work! Get me the fuck off of this list.somebody?? On Monday, July 28, 2014 11:11 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote: au0828 chipset have a built-in IR decoder, at au8522. Add support for it to decode both NEC and RC5 protocols. Unfortunately, it is not possible to have a fully generic IR decode, as this chipset is not able to detect the initial pulse. Mauro Carvalho Chehab (4): au0828: improve I2C speed rc-main: allow raw protocol drivers to restrict the allowed protos au0828: add support for IR on HVR-950Q ir-rc5-decoder: print the failed count drivers/media/rc/ir-rc5-decoder.c | 4 +- drivers/media/rc/rc-main.c | 5 +- drivers/media/usb/au0828/Kconfig | 7 + drivers/media/usb/au0828/Makefile | 4 + drivers/media/usb/au0828/au0828-cards.c | 7 +- drivers/media/usb/au0828/au0828-core.c | 25 +- drivers/media/usb/au0828/au0828-i2c.c | 23 +- drivers/media/usb/au0828/au0828-input.c | 391 drivers/media/usb/au0828/au0828.h | 11 + 9 files changed, 455 insertions(+), 22 deletions(-) create mode 100644 drivers/media/usb/au0828/au0828-input.c -- 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: i.MX6 status for IPU/VPU/GPU
On 07/28/2014 11:59 AM, Robert Schwebel wrote: Hi, On Mon, Jul 28, 2014 at 06:24:45PM +0200, Jean-Michel Hautbois wrote: We have a custom board, based on i.MX6 SoC. We are currently using Freescale's release of Linux, but this is a 3.10.17 kernel, and several drivers are lacking (adv7611 for instance) or badly written (all the MXC part). As we want to have nice things :) we would like to use a mainline kernel, or at least a tree which can be mainlined. It seems (#v4l told me so) that some people (Steeve :) ?) are working on a rewriting of the IPU and all DRM part for i.MX6. What is the current status (compared to Freescale's release maybe) ? And what can we expect in a near future? Maybe, how can we help too ? Hi Jean-Michel, I did post a v4l2 video capture driver for i.MX6 to linux-media. The main complaint from Philip at Pengutronix is that it does not support the media device framework. The customer I am currently working for has no real interest in the media controller API, and the driver I posted has all the features they require, so any work I do to add that support to the driver would have to be in my spare time, and I don't have much. If our customer were to request and fund media control support, that would be ideal, but as it is I can only spend limited time on it. So if you are interested in helping out in the media device effort I can send what I have so far. I have not provided any patches to i.MX6 DRM/KMS drivers. We have developed new features (overlay plane global/local alpha, hardware gamma correction, color-keying, and others) for for that component but haven't posted them yet. Steve Pengutronix is continuously working on mainlining more parts of the i.MX6 video and graphics subsystem, including the components you have mentioned. We are posting patches here when they are ready for mainline review. Regards, Robert (for commercial help, please contact me by email) -- 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: omap3isp with DM3730 not working?!
Hi Enrico, On Monday 28 July 2014 15:18:04 Enrico wrote: On Mon, Jul 28, 2014 at 12:29 PM, Laurent Pinchart wrote: On Monday 28 July 2014 10:30:17 Enrico wrote: On Mon, Jul 28, 2014 at 9:20 AM, Sakari Ailus wrote: On Thu, Jul 24, 2014 at 05:57:30PM +0200, Enrico wrote: On Thu, Jul 24, 2014 at 5:34 PM, Michael Dietschi wrote: Hello, I have built a Poky image for Gumstix Overo and added support for a TVP5151 module like described here http://www.sleepyrobot.com/?p=253. It does work well with an Overo board which hosts an OMAP3530 SoC. But when I try with an Overo hosting a DM3730 it does not work: yavta just seems to wait forever :( I did track it down to the point that IRQ0STATUS_CCDC_VD0_IRQ seems never be set but always IRQ0STATUS_CCDC_VD1_IRQ VD1 takes place in 2/3 of the frame, and VD0 in the beginning of the last line. You could check perhaps if you do get VD0 if you set it to take place on the previous line (i.e. the register value being height - 3; please see ccdc_configure() in ispccdc.c). I have to admit I haven't used the parallel interface so perhaps others could have more insightful comments on how to debug this. Can someone please give me a hint? It's strange that you get the vd1_irq because it should not be set by the driver and never trigger... Both VD0 and VD1 are used by the omap3isp driver, but in different points of the frame. Hi Sakari, that's true in normal mode, but with bt656 patches VD1 is not used. That's not correct, VD1 is used in both modes. In BT.656 mode VD1 is even used to increment the frame counter in place of the HS_VS interrupt. ...in your new patches. But sleepyrobot's are the old ones and i bet Michael is using those patches. You're right. Maybe that's the first problem to be fixed though ;-) Michael, could you try using the official (and under development) BT.656 support code for the OMAP3 ISP driver ? I've just pushed the branch to git://linuxtv.org/pinchartl/media.git omap3isp/bt656 -- 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
cron job: media_tree daily build: ERRORS
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 Jul 29 04:00:24 CEST 2014 git branch: test git hash: 488046c237f3b78f91046d45662b318cd2415f64 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-16-g1db35d0 host hardware: x86_64 host os:3.15-5.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: ERRORS 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: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-rc1-i686: OK linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS 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 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
Re: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165
On 23.07.2014 22:10, Antonio Ospite wrote:
On Wed, 23 Jul 2014 21:03:14 +0200
Matthias Schwarzott z...@gentoo.org wrote:
[...]
The crc value:
It protects the content of the file until it is in the demod - so
calculating it on my own would only check if the data is correctly
transferred from the driver into the chip.
But for this I needed to know the algorithm and which data is
checksummed exactly.
Are the different algorithms for CRC values that give 16 bit of output?
You could try jacksum[1] and see if any algorithm it supports
gives you the expected result, there is a handful of 16 bits ones:
jacksum -a all -F #ALGONAME{i} = #CHECKSUM{i} payload.bin
Hi Antonio,
I tried jacksum on the complete firmware and on parts - but it never
matched the results from the chip.
I now found out, that the crc register changes after every 32bit write
to the data register - the fw control registers do not affect it.
So I can try what crc results from writing 32bit portions of data.
But even that did not help in guessing the algorithm, because I do not
want to do 100s of experiments.
some of my experiments:
crc=0x, data=0x - crc=0x
crc=0x, data=0x0001 - crc=0x1021
crc=0x, data=0x0002 - crc=0x2042
crc=0x, data=0x0004 - crc=0x4084
crc=0x, data=0x0008 - crc=0x8108
crc=0x, data=0x0010 - crc=0x1231
Is there some systematic way to get the formula?
I can write arbitrary data and check what crc it results in.
I don't know if it is worth using the crc algorithm compared to storing
the crc with the firmware, because currently it is an end to end
verification of firmware data.
Regards
Matthias
--
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] si2135: Declare the structs even if frontend is not enabled
On 28.07.2014 15:38, Mauro Carvalho Chehab wrote:
As reported by Kbuildtest:
In file included from drivers/media/usb/cx231xx/cx231xx-dvb.c:35:0:
drivers/media/dvb-frontends/si2165.h:57:9: warning: 'struct si2165_config'
declared inside parameter list [enabled by default]
struct i2c_adapter *i2c)
^
drivers/media/dvb-frontends/si2165.h:57:9: warning: its scope is only this
definition or declaration, which is probably not what you want [enabled by
default]
drivers/media/usb/cx231xx/cx231xx-dvb.c:157:21: error: variable
'hauppauge_930C_HD_1113xx_si2165_config' has initializer but incomplete type
static const struct si2165_config hauppauge_930C_HD_1113xx_si2165_config
= {
^
drivers/media/usb/cx231xx/cx231xx-dvb.c:158:2: error: unknown field
'i2c_addr' specified in initializer
.i2c_addr = 0x64,
^
Good catch.
Matthias
--
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 6/8] cx231xx: Add digital support for [2040:b131] Hauppauge WinTV 930C-HD (model 1114xx)
On 27.07.2014 21:42, Mauro Carvalho Chehab wrote: Em Sun, 27 Jul 2014 11:59:11 -0300 Mauro Carvalho Chehab m.che...@samsung.com escreveu: Em Sun, 27 Jul 2014 11:32:48 -0300 Mauro Carvalho Chehab m.che...@samsung.com escreveu: Em Sun, 27 Jul 2014 10:44:53 -0300 Mauro Carvalho Chehab m.che...@samsung.com escreveu: Em Sun, 27 Jul 2014 11:32:26 +0200 Matthias Schwarzott z...@gentoo.org escreveu: Hi Mauro. On 26.07.2014 21:27, Mauro Carvalho Chehab wrote: Tried to apply your patch series, but there's something wrong on it. See the enclosed logs. I suspect that you missed a patch adding the proper tuner for this device. The hole issue was due to that: [ 326.770414] cx231xx #0: New device Hauppauge Hauppauge Device @ 12 Mbps (2040:b131) with 4 interfaces The root cause seems to be a bad USB cable, causing errors at USB detection. Just send a patch series that avoids the driver to OOPS in such case. Ah, now I understand why this specific device did not work. Nice errors that can be triggered by faulty hardware. Regards Matthias -- 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] [media] mceusb: select default keytable based on vendor
On 27.07.2014 22:47, Mauro Carvalho Chehab wrote: Some vendors have their on keymap table that are used on all (or almost all) models for that vendor. So, instead of specifying the keymap table per USB ID, let's use the Vendor ID's table by default. At the end, this will mean less code to be added when newer devices for those vendors are added. I also did prepare something to add mceusb support, but with this only vendor dependant rc_map selection, it definitly is less code. Your mceusb patches work correctly for my 930C-HD (b130) and PCTV 522e devices. Regards Matthias -- 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
