RE: [PATCH] [media] hdpvr: Disable IR receiver by default.
Hans, Jeff,
Yes, the FW instability is a known issue. It's not just the IR
polling. For example frequent polling for video lock will cause
FW crash as well. In windows driver there's a workaround for
this issue - all USB calls are serialized and surrounded by
small delays which makes HDPVR fairly stable. In fact, I implemented
this same workaround on Linux driver about a month ago but stashed
it due to lack of free time. If somebody is interested and willing
to test - I can provide a patch.
To answer the following email from Jeff - as far as I know
HDPVR firmware was released by Ambarella as a binary image only.
Best regards,
-Leo.
Original Message
Subject: Re: [PATCH] [media] hdpvr: Disable IR receiver by default.
From: Hans Verkuil hverk...@xs4all.nl
Date: Thu, May 23, 2013 1:41 am
To: Leonid Kegulskiy l...@lumanate.com
Cc: Jeff Hansen x...@jeffhansen.com, linux-media@vger.kernel.org, Mauro
Carvalho Chehab mche...@redhat.com
On Tue 14 May 2013 06:44:19 Jeff Hansen wrote:
All of the firmwares I've tested, including 0x1e, will inevitably crash
before recording for even 10 minutes. There must be a race condition of
IR RX vs. video-encoding in the firmware, because if you disable IR receiver
polling, then the firmware is stable again. I'd guess that most people don't
use this feature anyway, so we might as well disable it by default, and
warn them that it might be unstable until Hauppauge fixes it in a future
firmware.
Leonid, have you ever seen this? Can you verify that this happens for
you
as well?
Regards,
Hans
Signed-off-by: Jeff Hansen x...@jeffhansen.com
---
drivers/media/usb/hdpvr/hdpvr-core.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/media/usb/hdpvr/hdpvr-core.c
b/drivers/media/usb/hdpvr/hdpvr-core.c
index 8247c19..3e80202 100644
--- a/drivers/media/usb/hdpvr/hdpvr-core.c
+++ b/drivers/media/usb/hdpvr/hdpvr-core.c
@@ -53,6 +53,10 @@ static bool boost_audio;
module_param(boost_audio, bool, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(boost_audio, boost the audio signal);
+int ir_rx_enable;
+module_param(ir_rx_enable, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(ir_rx_enable, Enable HDPVR IR receiver (firmware may be
unstable));
+
/* table of devices that work with this driver */
static struct usb_device_id hdpvr_table[] = {
@@ -394,11 +398,13 @@ static int hdpvr_probe(struct usb_interface *interface,
goto error;
}
- client = hdpvr_register_ir_rx_i2c(dev);
- if (!client) {
- v4l2_err(dev-v4l2_dev, i2c IR RX device register failed\n);
- retval = -ENODEV;
- goto reg_fail;
+ if (ir_rx_enable) {
+ client = hdpvr_register_ir_rx_i2c(dev);
+ if (!client) {
+ v4l2_err(dev-v4l2_dev, i2c IR RX device register failed\n);
+ retval = -ENODEV;
+ goto reg_fail;
+ }
}
client = hdpvr_register_ir_tx_i2c(dev);
--
To unsubscribe from this list: send the line unsubscribe linux-media
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2] media: OF: add sync-on-green endpoint property
Prabhakar, On 05/16/2013 03:18 PM, Lad Prabhakar wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch adds sync-on-green property as part of endpoint properties and also support to parse them in the parser. --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -101,6 +101,8 @@ Optional endpoint properties array contains only one entry. - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous clock mode. +-sync-on-green: a boolean property indicating to sync with the green signal in + RGB. Are you sure this is what you need for the TVP7002 chip ? I think we should differentiate between analog and digital signals and the related device's configuration. AFAIU for the analog part there can be various video sychronisation methods, i.e. ways in which the synchronisation signals are transmitted along side the video component (RGB or luma/chroma) signals. According to [1] (presumably not most reliable source of information) there are following methods of transmitting sync signals: - Separate sync - Composite sync - Sync-on-green (SOG) - Sync-on-luminance - Sync-on-composite And all these seem to refer to analog video signal. From looking at Figure 8 TVP7002 Application Example in the TVP7002's datasheet ([2], p. 52) and your initial TVP7002 patches it looks like what you want is to specify polarity of the SOGOUT signal, so the processor that receives this signal can properly interpret it, is it correct ? If so then wouldn't it be more appropriate to define e.g. 'sog-active' property and media bus flags: V4L2_MBUS_SYNC_ON_GREEN_ACTIVE_LOW V4L2_MBUS_SYNC_ON_GREEN_ACTIVE_HIGH ? And for synchronisation method on the analog part we could perhaps define 'component-sync' or similar property that would enumerate all possible synchronisation methods. We might as well use separate boolean properties, but I'm a bit concerned about the increasing number of properties that need to be parsed for each parallel video bus endpoint. Anyway I'm not sure if we would already have use cases for the 'component-sync' property. [1] http://en.wikipedia.org/wiki/Component_video_sync [2] http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=tvp7002fileType=pdf Example diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index aa59639..b51d61f 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -100,6 +100,9 @@ static void v4l2_of_parse_parallel_bus(const struct device_node *node, if (!of_property_read_u32(node, data-shift,v)) bus-data_shift = v; + if (of_get_property(node, sync-on-green,v)) + flags |= V4L2_MBUS_SYNC_ON_GREEN; + bus-flags = flags; } diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..cf2c66f9 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -40,6 +40,7 @@ #define V4L2_MBUS_FIELD_EVEN_HIGH (1 10) /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */ #define V4L2_MBUS_FIELD_EVEN_LOW (1 11) +#define V4L2_MBUS_SYNC_ON_GREEN(1 12) -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] soc_camera: mt9t112: Remove empty function
After the switch to devm_* functions, the 'remove' function does
not do anything. Delete it.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/i2c/soc_camera/mt9t112.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/mt9t112.c
b/drivers/media/i2c/soc_camera/mt9t112.c
index a7256b7..0af29a4 100644
--- a/drivers/media/i2c/soc_camera/mt9t112.c
+++ b/drivers/media/i2c/soc_camera/mt9t112.c
@@ -1118,11 +1118,6 @@ static int mt9t112_probe(struct i2c_client *client,
return ret;
}
-static int mt9t112_remove(struct i2c_client *client)
-{
- return 0;
-}
-
static const struct i2c_device_id mt9t112_id[] = {
{ mt9t112, 0 },
{ }
@@ -1134,7 +1129,6 @@ static struct i2c_driver mt9t112_i2c_driver = {
.name = mt9t112,
},
.probe= mt9t112_probe,
- .remove = mt9t112_remove,
.id_table = mt9t112_id,
};
--
1.7.9.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 2/2] [media] soc_camera: tw9910: Remove empty function
After the switch to devm_* functions, the 'remove' function does
not do anything. Delete it.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/i2c/soc_camera/tw9910.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/tw9910.c
b/drivers/media/i2c/soc_camera/tw9910.c
index bad90b1..6b9cc2a 100644
--- a/drivers/media/i2c/soc_camera/tw9910.c
+++ b/drivers/media/i2c/soc_camera/tw9910.c
@@ -938,11 +938,6 @@ static int tw9910_probe(struct i2c_client *client,
return tw9910_video_probe(client);
}
-static int tw9910_remove(struct i2c_client *client)
-{
- return 0;
-}
-
static const struct i2c_device_id tw9910_id[] = {
{ tw9910, 0 },
{ }
@@ -954,7 +949,6 @@ static struct i2c_driver tw9910_i2c_driver = {
.name = tw9910,
},
.probe= tw9910_probe,
- .remove = tw9910_remove,
.id_table = tw9910_id,
};
--
1.7.9.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 2/2] [media] s5p-mfc: Remove redundant use of of_match_ptr macro
Hi Sachin,
Thank you for your patch.
Best wishes,
--
Kamil Debski
Linux Kernel Developer
Samsung RD Institute Poland
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Thursday, May 23, 2013 6:51 AM
To: linux-media@vger.kernel.org
Cc: s.nawro...@samsung.com; sylvester.nawro...@gmail.com;
sachin.ka...@linaro.org; patc...@linaro.org; Kamil Debski
Subject: [PATCH 2/2] [media] s5p-mfc: Remove redundant use of
of_match_ptr macro
'exynos_mfc_match' is always compiled in. Hence of_match_ptr is
unnecessary.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Kamil Debski k.deb...@samsung.com
Acked-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 01f9ae0..5d0419b 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1426,7 +1426,7 @@ static void *mfc_get_drv_data(struct
platform_device *pdev)
if (pdev-dev.of_node) {
const struct of_device_id *match;
- match = of_match_node(of_match_ptr(exynos_mfc_match),
+ match = of_match_node(exynos_mfc_match,
pdev-dev.of_node);
if (match)
driver_data = (struct s5p_mfc_variant *)match-data;
--
1.7.9.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] em28xx: add register defines for em25xx/em276x/7x/8x GPIO registers
em25xx/em276x/7x/8x provides 3 GPIO register sets, each of them consisting of separate read and a write registers. Signed-off-by: Frank Schäfer fschaefer@googlemail.com --- drivers/media/usb/em28xx/em28xx-reg.h | 8 1 file changed, 8 insertions(+) diff --git a/drivers/media/usb/em28xx/em28xx-reg.h b/drivers/media/usb/em28xx/em28xx-reg.h index 622871d..17bdb78 100644 --- a/drivers/media/usb/em28xx/em28xx-reg.h +++ b/drivers/media/usb/em28xx/em28xx-reg.h @@ -210,6 +210,14 @@ #define EM2874_TS2_FILTER_ENABLE (1 5) #define EM2874_TS2_NULL_DISCARD (1 6) +/* em25xx, em276x/7x/8x GPIO registers */ +#define EM25XX_R80_GPIO_P0_W0x80 +#define EM25XX_R81_GPIO_P1_W0x81 +#define EM25XX_R83_GPIO_P3_W0x83 +#define EM25XX_R84_GPIO_P0_R0x84 +#define EM25XX_R85_GPIO_P1_R0x85 +#define EM25XX_R87_GPIO_P3_R0x87 + /* register settings */ #define EM2800_AUDIO_SRC_TUNER 0x0d #define EM2800_AUDIO_SRC_LINE 0x0c -- 1.8.1.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
[PATCH 2/2] em28xx: complete GPIO register caching
The current GPIO register caching is incomplete.
Only one GPIO register and one GPO register is cached, but
nearly all chip variants have more than one GPIO register.
Caching of pure GPO registers (reg 0x04) also isn't needed.
At least parts of register 0x0c seem to be assigned to GPIO lines,
so we need to cache this register, too.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 12 -
drivers/media/usb/em28xx/em28xx-core.c | 43 ++---
drivers/media/usb/em28xx/em28xx.h | 15
3 files changed, 39 insertions(+), 31 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 83bfbe4..7486533 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2881,10 +2881,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
em28xx_set_model(dev);
- /* Set the default GPO/GPIO for legacy devices */
- dev-reg_gpo_num = EM2880_R04_GPO;
- dev-reg_gpio_num = EM28XX_R08_GPIO;
-
dev-wait_after_write = 5;
/* Based on the Chip ID, set the device configuration */
@@ -2932,13 +2928,11 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
break;
case CHIP_ID_EM2874:
chip_name = em2874;
- dev-reg_gpio_num = EM2874_R80_GPIO;
dev-wait_after_write = 0;
dev-eeprom_addrwidth_16bit = 1;
break;
case CHIP_ID_EM28174:
chip_name = em28174;
- dev-reg_gpio_num = EM2874_R80_GPIO;
dev-wait_after_write = 0;
dev-eeprom_addrwidth_16bit = 1;
break;
@@ -2948,7 +2942,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
break;
case CHIP_ID_EM2884:
chip_name = em2884;
- dev-reg_gpio_num = EM2874_R80_GPIO;
dev-wait_after_write = 0;
dev-eeprom_addrwidth_16bit = 1;
break;
@@ -2977,11 +2970,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
return 0;
}
- /* Prepopulate cached GPO register content */
- retval = em28xx_read_reg(dev, dev-reg_gpo_num);
- if (retval = 0)
- dev-reg_gpo = retval;
-
em28xx_pre_card_setup(dev);
if (!dev-board.is_em2800) {
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index a802128..58f8d22 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -197,16 +197,19 @@ int em28xx_write_regs(struct em28xx *dev, u16 reg, char
*buf, int len)
rc = em28xx_write_regs_req(dev, USB_REQ_GET_STATUS, reg, buf, len);
- /* Stores GPO/GPIO values at the cache, if changed
- Only write values should be stored, since input on a GPIO
- register will return the input bits.
- Not sure what happens on reading GPO register.
-*/
+
if (rc = 0) {
- if (reg == dev-reg_gpo_num)
- dev-reg_gpo = buf[0];
- else if (reg == dev-reg_gpio_num)
- dev-reg_gpio = buf[0];
+ /* Cache gpio register values (see em28xx_write_reg_bits()) */
+ if (reg == EM28XX_R08_GPIO)
+ dev-gpio_reg08_val = buf[0];
+ else if (reg == EM28XX_R0C_USBSUSP)
+ dev-gpio_reg0C_val = buf[0];
+ else if (reg == EM25XX_R80_GPIO_P0_W)
+ dev-gpio_reg80_val = buf[0];
+ else if (reg == EM25XX_R81_GPIO_P1_W)
+ dev-gpio_reg81_val = buf[0];
+ else if (reg == EM25XX_R83_GPIO_P3_W)
+ dev-gpio_reg83_val = buf[0];
}
return rc;
@@ -231,11 +234,23 @@ int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8
val,
int oldval;
u8 newval;
- /* Uses cache for gpo/gpio registers */
- if (reg == dev-reg_gpo_num)
- oldval = dev-reg_gpo;
- else if (reg == dev-reg_gpio_num)
- oldval = dev-reg_gpio;
+ /* Use cached values for gpio registers */
+ /* NOTE: for unmasked bits corresponding to input lines we can't take
+* the current value from the register, because reads and writes have
+* different meanings in this case:
+* write: enable/disable input; read: current line state (if enenabled)
+* = if input is enabled and line is low, we would disable the input !
+*/
+ if (reg == EM28XX_R08_GPIO)
+
cron job: media_tree daily build: WARNINGS
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: Fri May 24 19:00:22 CEST 2013 git branch: test git hash: 6a084d6b3dc200b855ae8a3c6771abe285a3835d gcc version:i686-linux-gcc (GCC) 4.8.0 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS 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: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.10-rc1-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9.2-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.10-rc1-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
