Re: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting
On 2013년 06월 04일 21:55, Daniel Vetter wrote:
> On Tue, Jun 04, 2013 at 07:42:22PM +0900, 김승우 wrote:
>>
>>
>> On 2013년 06월 01일 00:29, Daniel Vetter wrote:
>>> On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote:
Hello Daniel,
Thanks for your comment.
On 2013년 05월 31일 18:14, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim
> wrote:
>> importer private data in dma-buf attachment can be used by importer to
>> reimport same dma-buf.
>>
>> Seung-Woo Kim (2):
>> dma-buf: add importer private data to attachment
>> drm/prime: find gem object from the reimported dma-buf
>
> Self-import should already work (at least with the latest refcount
> fixes merged). At least the tests to check both re-import on the same
> drm fd and on a different all work as expected now.
Currently, prime works well for all case including self-importing,
importing, and reimporting as you describe. Just, importing dma-buf from
other driver twice with different drm_fd, each import create its own gem
object even two import is done for same buffer because prime_priv is in
struct drm_file. This means mapping to the device is done also twice.
IMHO, these duplicated creations and maps are not necessary if drm can
find previous import in different prime_priv.
>>>
>>> Well, that's imo a bug with the other driver. If it doesn't export
>>> something really simple (e.g. contiguous memory which doesn't require any
>>> mmio resources at all) it should have a cache of exported dma_buf fds so
>>> that it hands out the same dma_buf every time.
>>
>> Hm, all existing dma-buf exporter including i915 driver implements its
>> map_dma_buf callback as allocating scatter-gather table with pages in
>> its buffer and calling dma_map_sg() with the sgt. With different
>> drm_fds, importing one dma-buf *twice*, then importer calls
>> dma_buf_attach() and dma_buf_map_attachment() twice at least in drm
>> importer because re-importing case can only checked with prime_priv in
>> drm_file as I described.
>
> Well, but thanks to all the self-import and re-import checks, it's
> _impossible_ to import the same dma_buf twice without noticing (presuming
> both importer and exporter are drm devices).
No, it is possible. Prime function, drm_gem_prime_fd_to_handle(), checks
re-import with following code.
ret = drm_prime_lookup_buf_handle(&file_priv->prime,
dma_buf, handle);
Unfortunately, file_priv is allocated per each open of drm node so this
code can only find re-import within same drm open context.
And driver specific import functions, like drm_gem_prime_import(), only
check self-import like following code.
if (dma_buf->ops == &drm_gem_prime_dmabuf_ops) {
obj = dma_buf->priv;
if (obj->dev == dev) {
/* ... */
}
}
This means some application like following can make re-import to
different gem objects.
int drm_fd1, drm_fd2, ret;
int dma_buf_fd;
struct drm_prime_handle prime1, prime2;
drm_fd1 = open(DRM_NODE, O_RDWR, 0);
drm_fd2 = open(DRM_NODE, O_RDWR, 0);
/* get some dma-buf_fd from other dma-buf exporter */
prime1.fd = dma_buf_fd;
prime2.fd = dma_buf_fd;
ret = ioctl(drm_fd1, DRM_IOCTL_PRIME_FD_TO_HANDLE, &prime1);
ret = ioctl(drm_fd2, DRM_IOCTL_PRIME_FD_TO_HANDLE, &prime2);
This will import same dma-buf twice as different GEM object because
above checking codes can not check already imported gem object from the
dma-buf.
>>
>>>
>>> Or it needs to be more clever in it's dma_buf_attachment_map functions and
>>> lookup up a pre-existing iommu mapping.
>>>
>>> But dealing with this in the importer is just broken.
>>>
> Second, the dma_buf_attachment is _definitely_ the wrong place to do
> this. If you need iommu mapping caching, that should happen at a lower
> level (i.e. in the map_attachment callback somewhere of the exporter,
> that's what the priv field in the attachment is for). Snatching away
> the attachement from some random other import is certainly not the way
> to go - attachements are _not_ refcounted!
Yes, attachments do not have refcount, so importer should handle and drm
case in my patch, importer private data is gem object and it has, of
course, refcount.
And at current, exporter can not classify map_dma_buf requests of same
importer to same buffer with different attachment because dma_buf_attach
always makes new attachments. To resolve this exporter should search all
different attachment from same importer of dma-buf and it seems more
complex than importer private data to me.
If I misunderstood something, please let me know.
>>>
>>> Like I've said above, just fix this in the exporter. If an importer sees
>>> two different dma_bufs it can very well presume that it those two indeed
>>> point to different backing storage.
>>
>> Yes, my patch does not break this concept. I just fix
Re: TT-USB2.0 and high bitrate packet loss (DVB-C/T)
On 06/03/2013 12:02 AM, Antti Palosaari wrote: On 06/02/2013 03:19 PM, Hans Petter Selasky wrote: I think I will have to get another USB based receiver with CI slot. Any recommendations for DVB-T ? There is no many alternatives available. I suspect Anysee E7 serie is the only one. And I am not even sure if its CI works anymore. Lastly when I tested it I didn't get scrambled channels working - but it could be due to card entitlements were not upgraded. Anyhow, if there is bug then it should be easy to fix. I just tested, actually first bisecting back to Kernel 3.3 and VLC2 and it didn't work... That makes me suspect it was VLC which has gone broken. So I tried gnutv & mplayer and surprise CI was working! Both Anysee E7 TC and Anysee E7 T2C. Tested only DVB-C as I don't have DVB-T subscription card. CI/CAM worked earlier for VLC somehow too. Start tuning on terminal: gnutv -channels /path/to/channels.conf "scrambled channel" Start mplayer on the another terminal: mplayer /dev/dvb/adapter0/dvr0 It is a little bit boring situation as there is no very good Gnome Desktop TV application. Have never been... regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [rtl28xxu] Add support for Crypto Redi PC50A device (rtl2832u + FC0012 tuner)
Applied!
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu
t. Antti
On 06/04/2013 11:10 PM, Alessandro Miceli wrote:
The device has been tested on a MIPSel box with kernel 3.1.1 and backported
media_tree drivers
The kernel detects the device with the following output:
usbcore: registered new interface driver dvb_usb_rtl28xxu
usb 1-2: dvb_usb_v2: found a 'Crypto Redi PC50A' in warm state
usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the
software demuxer
DVB: registering new adapter (Crypto Redi PC50A)
usb 1-2: DVB: registering adapter 1 frontend 0 (Realtek RTL2832 (DVB-T))...
i2c i2c-4: fc0012: Fitipower FC0012 successfully identified
usb 1-2: dvb_usb_v2: 'Crypto Redi PC50A' successfully initialized and connected
Signed-off-by: Alessandro Miceli
---
drivers/media/dvb-core/dvb-usb-ids.h|1 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.c |2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 2e0709a..87bf2eb 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -368,4 +368,5 @@
#define USB_PID_TECHNISAT_AIRSTAR_TELESTICK_2 0x0004
#define USB_PID_TECHNISAT_USB2_DVB_S2 0x0500
#define USB_PID_CTVDIGDUAL_V2 0xe410
+#define USB_PID_CPYTO_REDI_PC50A 0xa803
#endif
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 22015fe..9a0ad1e 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1408,6 +1408,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
&rtl2832u_props, "Compro VideoMate U620F", NULL) },
{ DVB_USB_DEVICE(USB_VID_KWORLD_2, 0xd394,
&rtl2832u_props, "MaxMedia HU394-T", NULL) },
+ { DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_CPYTO_REDI_PC50A,
+ &rtl2832u_props, "Crypto Redi PC50A", NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] rtl28xxu: map remote for TerraTec Cinergy T Stick Black
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 93313f70..04da6be 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1395,7 +1395,7 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
{ DVB_USB_DEVICE(USB_VID_REALTEK, 0x2838,
&rtl2832u_props, "Realtek RTL2832U reference design", NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_T_STICK_BLACK_REV1,
- &rtl2832u_props, "TerraTec Cinergy T Stick Black", NULL) },
+ &rtl2832u_props, "TerraTec Cinergy T Stick Black",
RC_MAP_TERRATEC_SLIM) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_DELOCK_USB2_DVBT,
&rtl2832u_props, "G-Tek Electronics Group Lifeview LV5TDLX
DVB-T", NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK,
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] rtl28xxu: remove redundant IS_ENABLED macro
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 4167011..8bbc6ab 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1231,11 +1231,7 @@ static int rtl2831u_get_rc_config(struct dvb_usb_device
*d,
return 0;
}
-#else
- #define rtl2831u_get_rc_config NULL
-#endif
-#if IS_ENABLED(CONFIG_RC_CORE)
static int rtl2832u_rc_query(struct dvb_usb_device *d)
{
int ret, i, len;
@@ -1338,7 +1334,8 @@ static int rtl2832u_get_rc_config(struct dvb_usb_device
*d,
return 0;
}
#else
- #define rtl2832u_get_rc_config NULL
+#define rtl2831u_get_rc_config NULL
+#define rtl2832u_get_rc_config NULL
#endif
static const struct dvb_usb_device_properties rtl2831u_props = {
--
1.7.11.7
--
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 5/7] rtl28xxu: correct some device names
... just because I want to be perfect ;)
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 0045b19..93313f70 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1419,13 +1419,13 @@ static const struct usb_device_id rtl28xxu_id_table[] =
{
{ DVB_USB_DEVICE(USB_VID_KWORLD_2, 0xd393,
&rtl2832u_props, "GIGABYTE U7300", NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1104,
- &rtl2832u_props, "Digivox Micro Hd", NULL) },
+ &rtl2832u_props, "MSI DIGIVOX Micro HD", NULL) },
{ DVB_USB_DEVICE(USB_VID_COMPRO, 0x0620,
&rtl2832u_props, "Compro VideoMate U620F", NULL) },
{ DVB_USB_DEVICE(USB_VID_KWORLD_2, 0xd394,
&rtl2832u_props, "MaxMedia HU394-T", NULL) },
{ DVB_USB_DEVICE(USB_VID_LEADTEK, 0x6a03,
- &rtl2832u_props, "WinFast DTV Dongle mini", NULL) },
+ &rtl2832u_props, "Leadtek WinFast DTV Dongle mini", NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
1.7.11.7
--
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/7] rtl28xxu changes, mainly remote controller
It contains mainly remote controller implementation for rtl2832u. I will pull request it soon. http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu Antti Palosaari (5): rtl28xxu: reimplement rtl2832u remote controller rtl28xxu: remove redundant IS_ENABLED macro rtl28xxu: correct some device names rtl28xxu: map remote for TerraTec Cinergy T Stick Black rtl28xxu: use masked reg write where possible Miroslav Šustek (1): rtl28xxu: Add USB ID for Leadtek WinFast DTV Dongle mini Rodrigo Tartajo (1): rtl2832u: restore ir remote control support. drivers/media/usb/dvb-usb-v2/dvb_usb.h | 2 +- drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 178 ++-- drivers/media/usb/dvb-usb-v2/rtl28xxu.h | 6 ++ 3 files changed, 85 insertions(+), 101 deletions(-) -- 1.7.11.7 -- 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 7/7] rtl28xxu: use masked reg write where possible
Use masked register write inside rtl2832u_power_ctrl().
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 72 -
1 file changed, 16 insertions(+), 56 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 04da6be..6f5a3d0 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1041,67 +1041,34 @@ err:
static int rtl2832u_power_ctrl(struct dvb_usb_device *d, int onoff)
{
int ret;
- u8 val;
dev_dbg(&d->udev->dev, "%s: onoff=%d\n", __func__, onoff);
if (onoff) {
- /* set output values */
- ret = rtl28xx_rd_reg(d, SYS_GPIO_OUT_VAL, &val);
- if (ret)
- goto err;
-
- val |= 0x08;
- val &= 0xef;
-
- ret = rtl28xx_wr_reg(d, SYS_GPIO_OUT_VAL, val);
- if (ret)
- goto err;
-
- /* demod_ctl_1 */
- ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL1, &val);
- if (ret)
- goto err;
-
- val &= 0xef;
-
- ret = rtl28xx_wr_reg(d, SYS_DEMOD_CTL1, val);
- if (ret)
- goto err;
-
- /* demod control */
- /* PLL enable */
- ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL, &val);
+ /* GPIO3=1, GPIO4=0 */
+ ret = rtl28xx_wr_reg_mask(d, SYS_GPIO_OUT_VAL, 0x08, 0x18);
if (ret)
goto err;
- /* bit 7 to 1 */
- val |= 0x80;
-
- ret = rtl28xx_wr_reg(d, SYS_DEMOD_CTL, val);
+ /* suspend? */
+ ret = rtl28xx_wr_reg_mask(d, SYS_DEMOD_CTL1, 0x00, 0x10);
if (ret)
goto err;
- ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL, &val);
+ /* enable PLL */
+ ret = rtl28xx_wr_reg_mask(d, SYS_DEMOD_CTL, 0x80, 0x80);
if (ret)
goto err;
- val |= 0x20;
-
- ret = rtl28xx_wr_reg(d, SYS_DEMOD_CTL, val);
+ /* disable reset */
+ ret = rtl28xx_wr_reg_mask(d, SYS_DEMOD_CTL, 0x20, 0x20);
if (ret)
goto err;
mdelay(5);
- /*enable ADC_Q and ADC_I */
- ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL, &val);
- if (ret)
- goto err;
-
- val |= 0x48;
-
- ret = rtl28xx_wr_reg(d, SYS_DEMOD_CTL, val);
+ /* enable ADC */
+ ret = rtl28xx_wr_reg_mask(d, SYS_DEMOD_CTL, 0x48, 0x48);
if (ret)
goto err;
@@ -1114,25 +1081,18 @@ static int rtl2832u_power_ctrl(struct dvb_usb_device
*d, int onoff)
if (ret)
goto err;
} else {
- /* set output values */
- ret = rtl28xx_rd_reg(d, SYS_GPIO_OUT_VAL, &val);
- if (ret)
- goto err;
-
- val |= 0x10;
-
- ret = rtl28xx_wr_reg(d, SYS_GPIO_OUT_VAL, val);
+ /* GPIO4=1 */
+ ret = rtl28xx_wr_reg_mask(d, SYS_GPIO_OUT_VAL, 0x10, 0x10);
if (ret)
goto err;
- /* demod control */
- ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL, &val);
+ /* disable ADC */
+ ret = rtl28xx_wr_reg_mask(d, SYS_DEMOD_CTL, 0x00, 0x48);
if (ret)
goto err;
- val &= 0x37;
-
- ret = rtl28xx_wr_reg(d, SYS_DEMOD_CTL, val);
+ /* disable PLL */
+ ret = rtl28xx_wr_reg_mask(d, SYS_DEMOD_CTL, 0x00, 0x80);
if (ret)
goto err;
--
1.7.11.7
--
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/7] rtl28xxu: reimplement rtl2832u remote controller
Thanks to Rodrigo for original implementation!
Cc: Rodrigo Tartajo
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 152
drivers/media/usb/dvb-usb-v2/rtl28xxu.h | 9 +-
2 files changed, 58 insertions(+), 103 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index e592662..4167011 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1114,17 +1114,6 @@ static int rtl2832u_power_ctrl(struct dvb_usb_device *d,
int onoff)
if (ret)
goto err;
} else {
- /* demod_ctl_1 */
- ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL1, &val);
- if (ret)
- goto err;
-
- val |= 0x0c;
-
- ret = rtl28xx_wr_reg(d, SYS_DEMOD_CTL1, val);
- if (ret)
- goto err;
-
/* set output values */
ret = rtl28xx_rd_reg(d, SYS_GPIO_OUT_VAL, &val);
if (ret)
@@ -1249,72 +1238,44 @@ static int rtl2831u_get_rc_config(struct dvb_usb_device
*d,
#if IS_ENABLED(CONFIG_RC_CORE)
static int rtl2832u_rc_query(struct dvb_usb_device *d)
{
-#define TICSAT38KHZTONS(x) ((x) * (10/38000))
- int ret, i;
+ int ret, i, len;
struct rtl28xxu_priv *priv = d->priv;
+ struct ir_raw_event ev;
u8 buf[128];
- int len;
- struct ir_raw_event ev; //encode single ir event (pulse or space)
- struct rtl28xxu_xreg_val rc_sys_init_tab[] = {
- { SYS_DEMOD_CTL1, OP_AND, 0xfb },
- { SYS_DEMOD_CTL1, OP_AND, 0xf7 },
- { USB_CTRL, OP_OR , 0x20 },
- { SYS_SYS1, OP_AND, 0xf7 },
- { SYS_GPIO_OUT_EN, OP_OR , 0x08 },
- { SYS_GPIO_OUT_VAL, OP_OR , 0x08 },
- }; // system hard init
- struct rtl28xxu_reg_val rc_init_tab[] = {
- { IR_RX_CTRL, 0x20 },
- { IR_RX_BUF_CTRL, 0x80 },
- { IR_RX_IF, 0xff },
- { IR_RX_IE, 0xff },
- { IR_MAX_DURATION0, 0xd0 },
- { IR_MAX_DURATION1, 0x07 },
- { IR_IDLE_LEN0, 0xc0 },
- { IR_IDLE_LEN1, 0x00 },
- { IR_GLITCH_LEN, 0x03 },
- { IR_RX_CLK, 0x09 },
- { IR_RX_CFG, 0x1c },
- { IR_MAX_H_TOL_LEN, 0x1e },
- { IR_MAX_L_TOL_LEN, 0x1e },
- { IR_RX_CTRL, 0x80 },
- }; // hard init
- struct rtl28xxu_reg_val rc_reinit_tab[] = {
- { IR_RX_CTRL, 0x20 },
- { IR_RX_BUF_CTRL, 0x80 },
- { IR_RX_IF, 0xff },
- { IR_RX_IE, 0xff },
- { IR_RX_CTRL, 0x80 },
- }; // reinit IR
- struct rtl28xxu_reg_val rc_clear_tab[] = {
- { IR_RX_IF, 0x03 },
- { IR_RX_BUF_CTRL, 0x80 },
- { IR_RX_CTRL, 0x80 },
- }; // clear reception
+ static const struct rtl28xxu_reg_val_mask refresh_tab[] = {
+ {IR_RX_IF, 0x03, 0xff},
+ {IR_RX_BUF_CTRL, 0x80, 0xff},
+ {IR_RX_CTRL, 0x80, 0xff},
+ };
/* init remote controller */
if (!priv->rc_active) {
- for (i = 0; i < ARRAY_SIZE(rc_sys_init_tab); i++) {
- ret = rtl28xx_rd_reg(d, rc_sys_init_tab[i].reg,
&buf[0]);
- if (ret)
- goto err;
- if (rc_sys_init_tab[i].op == OP_AND) {
- buf[0] &= rc_sys_init_tab[i].mask;
- }
- else {//OP_OR
- buf[0] |= rc_sys_init_tab[i].mask;
- }
- ret = rtl28xx_wr_reg(d, rc_sys_init_tab[i].reg,
- buf[0]);
- if (ret)
- goto err;
- }
- for (i = 0; i < ARRAY_SIZE(rc_init_tab); i++) {
- ret = rtl28xx_wr_reg(d, rc_init_tab[i].reg,
- rc_init_tab[i].val);
+ static const struct rtl28xxu_reg_val_mask init_tab[] = {
+ {SYS_DEMOD_CTL1, 0x00, 0x04},
+ {SYS_DEMOD_CTL1, 0x00, 0x08},
+ {USB_CTRL, 0x20, 0x20},
+ {SYS_GPIO_DIR, 0x00, 0x08},
+ {SYS_GPIO_OUT_EN,0x08, 0x08},
+ {SYS_GPIO_OUT_VAL, 0x08, 0x08},
+ {IR_MAX_DURATION0, 0xd0, 0xff},
+
[PATCH 1/7] rtl2832u: restore ir remote control support.
From: Rodrigo Tartajo
Hi,
This patch uses the driver from openpli[1] as a template to restore the remote
control support.
I had to divert from the original to use the in kernel rc protocol decoder. The
key repetition does,
not seem to work but I cant find the problem in the driver. As a raw rc
provider, no key table is
hardcoded.
Rodrigo.
[1]: https://aur.archlinux.org/packages/dvb-usb-rtl2832u-openpli/?comments=all
Signed-off-by: Rodrigo Tartajo
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/dvb_usb.h | 2 +-
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 83 -
drivers/media/usb/dvb-usb-v2/rtl28xxu.h | 11 +
3 files changed, 83 insertions(+), 13 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb.h
b/drivers/media/usb/dvb-usb-v2/dvb_usb.h
index 658c6d4..399916b 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb.h
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb.h
@@ -140,7 +140,7 @@ struct dvb_usb_rc {
int (*change_protocol)(struct rc_dev *dev, u64 *rc_type);
int (*query) (struct dvb_usb_device *d);
unsigned int interval;
- const enum rc_driver_type driver_type;
+ enum rc_driver_type driver_type;
bool bulk_mode;
};
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 22015fe..e592662 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1249,11 +1249,21 @@ static int rtl2831u_get_rc_config(struct dvb_usb_device
*d,
#if IS_ENABLED(CONFIG_RC_CORE)
static int rtl2832u_rc_query(struct dvb_usb_device *d)
{
+#define TICSAT38KHZTONS(x) ((x) * (10/38000))
int ret, i;
struct rtl28xxu_priv *priv = d->priv;
u8 buf[128];
int len;
- struct rtl28xxu_reg_val rc_nec_tab[] = {
+ struct ir_raw_event ev; //encode single ir event (pulse or space)
+ struct rtl28xxu_xreg_val rc_sys_init_tab[] = {
+ { SYS_DEMOD_CTL1, OP_AND, 0xfb },
+ { SYS_DEMOD_CTL1, OP_AND, 0xf7 },
+ { USB_CTRL, OP_OR , 0x20 },
+ { SYS_SYS1, OP_AND, 0xf7 },
+ { SYS_GPIO_OUT_EN, OP_OR , 0x08 },
+ { SYS_GPIO_OUT_VAL, OP_OR , 0x08 },
+ }; // system hard init
+ struct rtl28xxu_reg_val rc_init_tab[] = {
{ IR_RX_CTRL, 0x20 },
{ IR_RX_BUF_CTRL, 0x80 },
{ IR_RX_IF, 0xff },
@@ -1268,13 +1278,40 @@ static int rtl2832u_rc_query(struct dvb_usb_device *d)
{ IR_MAX_H_TOL_LEN, 0x1e },
{ IR_MAX_L_TOL_LEN, 0x1e },
{ IR_RX_CTRL, 0x80 },
- };
+ }; // hard init
+ struct rtl28xxu_reg_val rc_reinit_tab[] = {
+ { IR_RX_CTRL, 0x20 },
+ { IR_RX_BUF_CTRL, 0x80 },
+ { IR_RX_IF, 0xff },
+ { IR_RX_IE, 0xff },
+ { IR_RX_CTRL, 0x80 },
+ }; // reinit IR
+ struct rtl28xxu_reg_val rc_clear_tab[] = {
+ { IR_RX_IF, 0x03 },
+ { IR_RX_BUF_CTRL, 0x80 },
+ { IR_RX_CTRL, 0x80 },
+ }; // clear reception
/* init remote controller */
if (!priv->rc_active) {
- for (i = 0; i < ARRAY_SIZE(rc_nec_tab); i++) {
- ret = rtl28xx_wr_reg(d, rc_nec_tab[i].reg,
- rc_nec_tab[i].val);
+ for (i = 0; i < ARRAY_SIZE(rc_sys_init_tab); i++) {
+ ret = rtl28xx_rd_reg(d, rc_sys_init_tab[i].reg,
&buf[0]);
+ if (ret)
+ goto err;
+ if (rc_sys_init_tab[i].op == OP_AND) {
+ buf[0] &= rc_sys_init_tab[i].mask;
+ }
+ else {//OP_OR
+ buf[0] |= rc_sys_init_tab[i].mask;
+ }
+ ret = rtl28xx_wr_reg(d, rc_sys_init_tab[i].reg,
+ buf[0]);
+ if (ret)
+ goto err;
+ }
+ for (i = 0; i < ARRAY_SIZE(rc_init_tab); i++) {
+ ret = rtl28xx_wr_reg(d, rc_init_tab[i].reg,
+ rc_init_tab[i].val);
if (ret)
goto err;
}
@@ -1286,7 +1323,7 @@ static int rtl2832u_rc_query(struct dvb_usb_device *d)
goto err;
if (buf[0] != 0x83)
- goto exit;
+ goto err;
ret = rtl28xx_rd_reg(d, IR_RX_BC, &buf[0]);
if (ret)
@@ -1295,26 +1332,48 @@ static int rtl2832u_rc_query(struct dvb_usb_device *d)
len = buf[0];
ret = rtl2831_rd_regs(d, IR_RX_BUF, buf, len);
- /* TODO: pass raw IR to
[PATCH 4/7] rtl28xxu: Add USB ID for Leadtek WinFast DTV Dongle mini
From: Miroslav Šustek
USB ID 0413:6a03 is Leadtek WinFast DTV Dongle mini.
Decoder Realtek RTL2832U and tuner Infineon TUA9001.
Signed-off-by: Miroslav Šustek
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 8bbc6ab..0045b19 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1424,6 +1424,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
&rtl2832u_props, "Compro VideoMate U620F", NULL) },
{ DVB_USB_DEVICE(USB_VID_KWORLD_2, 0xd394,
&rtl2832u_props, "MaxMedia HU394-T", NULL) },
+ { DVB_USB_DEVICE(USB_VID_LEADTEK, 0x6a03,
+ &rtl2832u_props, "WinFast DTV Dongle mini", NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
1.7.11.7
--
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] [rtl28xxu] Add support for Crypto Redi PC50A device (rtl2832u + FC0012 tuner)
The device has been tested on a MIPSel box with kernel 3.1.1 and backported
media_tree drivers
The kernel detects the device with the following output:
usbcore: registered new interface driver dvb_usb_rtl28xxu
usb 1-2: dvb_usb_v2: found a 'Crypto Redi PC50A' in warm state
usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the
software demuxer
DVB: registering new adapter (Crypto Redi PC50A)
usb 1-2: DVB: registering adapter 1 frontend 0 (Realtek RTL2832 (DVB-T))...
i2c i2c-4: fc0012: Fitipower FC0012 successfully identified
usb 1-2: dvb_usb_v2: 'Crypto Redi PC50A' successfully initialized and connected
Signed-off-by: Alessandro Miceli
---
drivers/media/dvb-core/dvb-usb-ids.h|1 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.c |2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 2e0709a..87bf2eb 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -368,4 +368,5 @@
#define USB_PID_TECHNISAT_AIRSTAR_TELESTICK_2 0x0004
#define USB_PID_TECHNISAT_USB2_DVB_S2 0x0500
#define USB_PID_CTVDIGDUAL_V2 0xe410
+#define USB_PID_CPYTO_REDI_PC50A 0xa803
#endif
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 22015fe..9a0ad1e 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1408,6 +1408,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
&rtl2832u_props, "Compro VideoMate U620F", NULL) },
{ DVB_USB_DEVICE(USB_VID_KWORLD_2, 0xd394,
&rtl2832u_props, "MaxMedia HU394-T", NULL) },
+ { DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_CPYTO_REDI_PC50A,
+ &rtl2832u_props, "Crypto Redi PC50A", NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
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: Diversity support?
Al 04/06/13 16:33, En/na Luca Olivetti ha escrit: > Unfortunately, the terratec uses the dib0070 (as do most other usb > sticks with diversity), I see some fields for diversity in dib0070.[hc], s/dib0070/dib0700/ (sorry), though the corresponding driver has the same fields about diversity Bye -- Luca -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv2 1/3] libv4l2rds: support RDS-EON and TMC-tuning info
Signed-off-by: Konke Radlow
libv4l2rds: added support to decode RDS-EON information
Signed-off-by: Konke Radlow
libv4l2rds: added support to decode RDS-TMC tuning information
Signed-off-by: Konke Radlow
libv4l2rds.c: fixing compiler warnings due to missing pointer dereferencing
and implementing changes proposed in RFC replies (RDS-EON patch)
Signed-off-by: Konke Radlow
libv4l2rds: implementing changes proposed in RFC replies (TMC-Tuning patch)
Signed-off-by: Konke Radlow
---
lib/include/libv4l2rds.h| 79 +-
lib/libv4l2rds/libv4l2rds.c | 363 ---
2 files changed, 417 insertions(+), 25 deletions(-)
diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
index 6a6c7f3..e1078de 100644
--- a/lib/include/libv4l2rds.h
+++ b/lib/include/libv4l2rds.h
@@ -37,7 +37,7 @@ extern "C" {
#endif
/* used to define the current version (version field) of the v4l2_rds struct */
-#define V4L2_RDS_VERSION (1)
+#define V4L2_RDS_VERSION (2)
/* Constants used to define the size of arrays used to store RDS information */
#define MAX_ODA_CNT 18 /* there are 16 groups each with type a or b.
Of these
@@ -50,6 +50,16 @@ extern "C" {
* Additional data is limited to 112 bit, and the
smallest
* optional tuple has a size of 4 bit (4 bit identifier +
* 0 bits of data) */
+#define MAX_TMC_ALT_STATIONS 32 /* defined by ISO 14819-1:2003, 7.5.3.3 */
+#define MAX_TMC_AF_CNT 4 /* limit for the numbers of AFs stored per
alternative TMC
+ * station. This value is not defined by the standard,
but based on observation
+ * of real-world RDS-TMC streams. The maximum
encountered number of AFs per
+ * station during testing was 2 */
+#define MAX_EON_CNT 20 /* Maximal number of entries in the EON table (for
storing
+ * information about other radio stations, broadcasted
by the current station).
+ * This value is not defined by the standard, but based
on observation
+ * of real-world RDS-TMC streams. EON doesn't seem to be
a widely used feature
+ * and the maximum number of EON encountered during
testing was 8 */
/* Define Constants for the possible types of RDS information
* used to address the relevant bit in the valid_fields bitmask */
@@ -69,7 +79,10 @@ extern "C" {
#define V4L2_RDS_LC0x2000 /* Language Code */
#define V4L2_RDS_TMC_SG0x4000 /* RDS-TMC single group */
#define V4L2_RDS_TMC_MG0x8000 /* RDS-TMC multi group */
-#define V4L2_RDS_TMC_SYS 0x1 /* RDS-TMC system information */
+#define V4L2_RDS_TMC_SYS 0x1 /* RDS-TMC system information */
+#define V4L2_RDS_EON 0x2 /* Enhanced Other Network Info */
+#define V4L2_RDS_LSF 0x4 /* Linkage information */
+#define V4L2_RDS_TMC_TUNING0x8 /* RDS-TMC tuning information */
/* Define Constants for the state of the RDS decoding process
* used to address the relevant bit in the decode_information bitmask */
@@ -84,9 +97,10 @@ extern "C" {
#define V4L2_RDS_FLAG_STATIC_PTY 0x08
/* TMC related codes
- * used to extract TMC fields from RDS groups */
-#define V4L2_TMC_TUNING_INFO 0x08
-#define V4L2_TMC_SINGLE_GROUP 0x04
+ * used to extract TMC fields from RDS-TMC groups
+ * see ISO 14819-1:2003, Figure 2 - RDS-TMC single-grp full message structure
*/
+#define V4L2_TMC_TUNING_INFO 0x10/* Bit 4 indicates Tuning Info / User
msg */
+#define V4L2_TMC_SINGLE_GROUP 0x08/* Bit 3 indicates Single / Multi-group
msg */
/* struct to encapsulate one complete RDS group */
/* This structure is used internally to store data until a complete RDS
@@ -149,6 +163,57 @@ struct v4l2_rds_af_set {
uint32_t af[MAX_AF_CNT];/* AFs defined in Hz */
};
+/* struct to encapsulate one entry in the EON table (Enhanced Other Network) */
+struct v4l2_rds_eon {
+ uint32_t valid_fields;
+ uint16_t pi;
+ uint8_t ps[9];
+ uint8_t pty;
+ bool ta;
+ bool tp;
+ uint16_t lsf; /* Linkage Set Number */
+ struct v4l2_rds_af_set af;
+};
+
+/* struct to encapsulate a table of EON information */
+struct v4l2_rds_eon_set {
+ uint8_t size; /* size of the table */
+ uint8_t index; /* current position in the table */
+ struct v4l2_rds_eon eon[MAX_EON_CNT]; /* Information about other
+* radio channels */
+};
+
+/* struct to encapsulate alternative frequencies (AFs) for RDS-TMC stations.
+ * AFs listed in af[] can be used unconditionally.
+ * AFs listed in mapped_af[n] should only be used if the current
+ * tuner frequency matches the value in mapped_af_tuning[n] */
+struct v4l2_tmc_alt_freq {
+ uint8_t af_size;
[RFC PATCHv2 2/3] rds-ctl: support RDS-EON and TMC-tuning info
Signed-off-by: Konke Radlow
rds-ctl.cpp: added functionality to print RDS-EON information
Signed-off-by: Konke Radlow
rds-ctl.cpp: added functionality to print RDS-TMC tuning information
Signed-off-by: Konke Radlow
rds-ctl.cpp: clarify option description, change
trigger condition for printing TMC Tuning information
Signed-off-by: Konke Radlow
---
utils/rds-ctl/rds-ctl.cpp | 59 +++--
1 file changed, 57 insertions(+), 2 deletions(-)
diff --git a/utils/rds-ctl/rds-ctl.cpp b/utils/rds-ctl/rds-ctl.cpp
index 191cfee..d894ec1 100644
--- a/utils/rds-ctl/rds-ctl.cpp
+++ b/utils/rds-ctl/rds-ctl.cpp
@@ -130,7 +130,7 @@ static void usage_hint(void)
static void usage_common(void)
{
printf("\nGeneral/Common options:\n"
- " --all display all information available\n"
+ " --all display all device information available\n"
" -D, --info show driver info [VIDIOC_QUERYCAP]\n"
" -d, --device= use device \n"
" if is a single digit, then
/dev/radio is used\n"
@@ -172,7 +172,7 @@ static void usage_rds(void)
" : 5000 ms\n"
" --print-block prints all valid RDS fields, whenever a
value is updated\n"
" instead of printing only updated values\n"
- " --tmc enables decoding of TMC (Traffic Message
Channel) data\n"
+ " --tmc print information about TMC (Traffic
Message Channel) messages\n"
" --silent only set the result code, do not print any
messages\n"
" --verbose turn on verbose mode - every received RDS
group\n"
" will be printed\n"
@@ -517,6 +517,30 @@ static void print_rds_tmc(const struct v4l2_rds *handle,
uint32_t updated_fields
}
}
+static void print_rds_tmc_tuning(const struct v4l2_rds *handle, uint32_t
updated_fields)
+{
+ const struct v4l2_tmc_tuning *tuning = &handle->tmc.tuning;
+ const struct v4l2_tmc_station *station;
+
+ if (updated_fields & V4L2_RDS_TMC_TUNING) {
+ printf("\nTMC Service provider: %s, %u alternative stations\n",
handle->tmc.spn, tuning->station_cnt);
+ for (int i = 0; i < tuning->station_cnt; i++) {
+ station = &tuning->station[i];
+ printf("PI(ON %02u) = %04x, AFs: %u, mapped AFs: %u
\n", i, station->pi,
+ station->afi.af_size,
station->afi.mapped_af_size);
+ for (int j = 0; j < station->afi.af_size; j++)
+ printf("AF%02d: %.1fMHz\n", j,
station->afi.af[j] / 100.0);
+ for (int k = 0; k < station->afi.mapped_af_size; k++)
+ printf("m_AF%02d: %.1fMHz =>
%.1fMHz\n", k,
+
station->afi.mapped_af_tuning[k] / 100.0,
+ station->afi.mapped_af[k] /
100.0);
+ if (station->ltn != 0 || station->msg != 0 || station->
sid != 0)
+ printf("ltn: %02x, msg: %02x, sid:
%02x\n", station->ltn,
+ station->msg, station->sid);
+ }
+ }
+}
+
static void print_rds_statistics(const struct v4l2_rds_statistics *statistics)
{
printf("\n\nRDS Statistics: \n");
@@ -557,6 +581,33 @@ static void print_rds_af(const struct v4l2_rds_af_set
*af_set)
}
}
+static void print_rds_eon(const struct v4l2_rds_eon_set *eon_set)
+{
+ int counter = 0;
+
+ printf("\n\nEnhanced Other Network information: %u channels",
eon_set->size);
+ for (int i = 0; i < eon_set->size; i++, counter++) {
+ if (eon_set->eon[i].valid_fields & V4L2_RDS_PI)
+ printf("\nPI(ON %02i) = %04x", i, eon_set->eon[i].pi);
+ if (eon_set->eon[i].valid_fields & V4L2_RDS_PS)
+ printf("\nPS(ON %02i) = %s", i, eon_set->eon[i].ps);
+ if (eon_set->eon[i].valid_fields & V4L2_RDS_PTY)
+ printf("\nPTY(ON %02i) = %0u", i, eon_set->eon[i].pty);
+ if (eon_set->eon[i].valid_fields & V4L2_RDS_LSF)
+ printf("\nLSF(ON %02i) = %0u", i, eon_set->eon[i].lsf);
+ if (eon_set->eon[i].valid_fields & V4L2_RDS_AF)
+ printf("\nPTY(ON %02i) = %0u", i, eon_set->eon[i].pty);
+ if (eon_set->eon[i].valid_fields & V4L2_RDS_TP)
+ printf("\nTP(ON %02i): %s", i, eon_set->eon[i].tp?
"yes":"no");
+ if (eon_set->eon[i].valid_fields & V4L2_RDS_TA)
+ printf("\nTA(ON %02i): %s", i, eon_set->eon[i].tp?
"yes":"no");
[RFC PATCHv2 3/3] libv4l2rds.c: moving functions to get rid of declarations Signed-off-by: Konke Radlow
Signed-off-by: Konke Radlow
---
lib/libv4l2rds/libv4l2rds.c | 243 +--
1 file changed, 120 insertions(+), 123 deletions(-)
diff --git a/lib/libv4l2rds/libv4l2rds.c b/lib/libv4l2rds/libv4l2rds.c
index 28b78ce..333bf95 100644
--- a/lib/libv4l2rds/libv4l2rds.c
+++ b/lib/libv4l2rds/libv4l2rds.c
@@ -92,11 +92,6 @@ enum rds_state {
RDS_C_RECEIVED,
};
-/* function declarations to prevent the need to move large code blocks */
-static int rds_add_tmc_station(struct rds_private_state *priv_state, uint16_t
pi);
-static uint32_t rds_decode_af(uint8_t af, bool is_vhf);
-static bool rds_add_tmc_af(struct rds_private_state *priv_state);
-
static inline uint8_t set_bit(uint8_t input, uint8_t bitmask, bool bitvalue)
{
return bitvalue ? input | bitmask : input & ~bitmask;
@@ -201,6 +196,29 @@ static void rds_decode_d(struct rds_private_state
*priv_state, struct v4l2_rds_d
grp->data_d_lsb = rds_data->lsb;
}
+/* decodes the RDS radio frequency representation into Hz
+ * @af: 8-bit AF value as transmitted in RDS groups
+ * @is_vhf: boolean value defining which conversion table to use
+ * @return: frequency in Hz, 0 in case of wrong input values */
+static uint32_t rds_decode_af(uint8_t af, bool is_vhf) {
+ uint32_t freq = 0;
+
+ /* AF = 0 => "not to be used"
+* AF >= 205 => special meanings */
+ if (af == 0 || af >= 205)
+ return 0;
+
+ /* calculate the AF values in HZ */
+ if (is_vhf)
+ freq = 8750 + af * 10;
+ else if (freq <= 15)
+ freq = 152000 + af * 9000;
+ else
+ freq = 531000 + af * 9000;
+
+ return freq;
+}
+
/* compare two rds-groups for equality */
/* used for decoding RDS-TMC, which has the requirement that the same group
* is at least received twice before it is accepted */
@@ -224,6 +242,103 @@ static bool rds_compare_group(const struct v4l2_rds_group
*a,
return true;
}
+/* checks if an entry for the given PI already exists and returns the index
+ * of that entry if so. Else it adds a new entry to the TMC-Tuning table and
returns
+ * the index of the new field */
+static int rds_add_tmc_station(struct rds_private_state *priv_state, uint16_t
pi)
+{
+ struct v4l2_tmc_tuning *tuning = &priv_state->handle.tmc.tuning;
+ uint8_t index = tuning->index;
+ uint8_t size = tuning->station_cnt;
+
+ /* check if there's an entry for the given PI key */
+ for (int i = 0; i < tuning->station_cnt; i++) {
+ if (tuning->station[i].pi == pi) {
+ return i;
+ }
+ }
+ /* if the the maximum table size is reached, overwrite old
+* entries, starting at the oldest one = 0 */
+ tuning->station[index].pi = pi;
+ tuning->index = (index+1 < MAX_TMC_ALT_STATIONS) ? (index+1) : 0;
+ tuning->station_cnt = (size+1 <= MAX_TMC_ALT_STATIONS) ? (size+1) :
MAX_TMC_ALT_STATIONS;
+ return index;
+}
+
+/* tries to add new AFs to the relevant entry in the list of RDS-TMC providers
*/
+static bool rds_add_tmc_af(struct rds_private_state *priv_state)
+{
+ struct v4l2_rds_group *grp = &priv_state->rds_group;
+ struct v4l2_tmc_alt_freq *afi;
+ uint16_t pi_on = grp->data_d_msb << 8 | grp->data_d_lsb;
+ uint8_t variant = grp->data_b_lsb & 0x0f;
+ uint8_t station_index = rds_add_tmc_station(priv_state, pi_on);
+ uint8_t af_index;
+ uint8_t mapped_af_index;
+ uint32_t freq_a = rds_decode_af(grp->data_c_msb, true);
+ uint32_t freq_b = rds_decode_af(grp->data_c_lsb, true);
+
+ afi = &priv_state->handle.tmc.tuning.station[station_index].afi;
+ af_index = afi->af_index;
+ mapped_af_index = afi->mapped_af_index;
+
+ /* specific frequencies */
+ if (variant == 6) {
+ /* compare the new AFs to the stored ones, reset them to 0 if
the AFs are
+* already known */
+ for (int i = 0; i < afi->af_size; i++) {
+ freq_a = (freq_a == afi->af[i]) ? 0 : freq_a;
+ freq_b = (freq_b == afi->af[i]) ? 0 : freq_b;
+ }
+ /* return early if there is nothing to do */
+ if (freq_a == 0 && freq_b == 0)
+ return false;
+
+ /* add the new AFs if they were previously unknown */
+ if (freq_a != 0) {
+ afi->af[af_index] = freq_a;
+ af_index = (af_index+1 < MAX_TMC_AF_CNT) ? af_index+1 :
0;
+ afi->af_size++;
+ }
+ if (freq_b != 0) {
+ afi->af[af_index] = freq_b;
+ af_index = (af_index+1 < MAX_TMC_AF_CNT) ? af_index+1 :
0;
+ afi->af_size++;
+ }
+ /* update the information in the handle */
+ afi->af_index
[RFC PATCHv2 0/3] libv4l2rds: add support for RDS-EON and TMC-tuning decoding
This patch series is based on the commments to: [RFC PATCH 0/4] libv4l2rds: support for decoding RDS tuning information [RFC PATCH 1/4] libv4l2rds: added support to decode RDS-EON information [RFC PATCH 2/4] rds-ctl.cpp: added functionality to print RDS-EON information [RFC PATCH 3/4] libv4l2rds: added support to decode RDS-TMC tuning information [RFC PATCH 4/4] rds-ctl.cpp: added functionality to print RDS-TMC tuning information The proposed changes have been integrated and the patches (1, 3) and (2, 4) have been merged into one unit. -- 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: 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: Tue Jun 4 19:00:17 CEST 2013 git branch: test git hash: 7eac97d7e714429f7ef1ba5d35f94c07f4c34f8e 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/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 v2] ov10635: Add OmniVision ov10635 SoC camera driver
Hi Jean-Philippe,
Thanks for the review.
> > +static const struct ov10635_reg ov10635_regs_enable[] = {
> > + { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, {
> 0x3042, 0xf0 },
> > + { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, {
> 0x3042, 0xf0 },
> > + { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, {
> 0x3042, 0xf0 },
> > + { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, {
> 0x3042, 0xf0 },
> > + { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, {
> 0x3042, 0xf0 },
> > + { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, {
> 0x3042, 0xf0 },
> > + { 0x3042, 0xf0 }, { 0x3042, 0xf0 }, { 0x301b, 0xf0 }, {
> 0x301c, 0xf0 },
> > + { 0x301a, 0xf0 },
> > +};
>
> Register 0x3042 is only touched by the enable part, not by the "change
> mode" part
> I think you could move the {0x3042, 0xf0} sequence in the
> standard_regs array, and keep
> only the 0x301b, 0x301c, 0x301a registers.
I tried this, but it doesn't work. You have to write to the 0x3042
register after other setup writes.
> By the way, did you test with a single write ? There is the same
> sequence in ov5642
> init, so I believe it is copy pasted in every omnivision init. Is it
> actually useful ?
I tried this & a single write works so I'll change this. iirc, it was
taken from a reference set of writes from OmniVision.
> > +static int ov10635_video_probe(struct i2c_client *client)
> > +{
> > + struct ov10635_priv *priv = to_ov10635(client);
> > + u8 pid, ver;
> > + int ret;
> > +
> > + /* Program all the 'standard' registers */
> > + ret = ov10635_set_regs(client, ov10635_regs_default,
> > + ARRAY_SIZE(ov10635_regs_default));
> > + if (ret)
> > + return ret;
> > +
> > + /* check and show product ID and manufacturer ID */
> > + ret = ov10635_reg_read(client, OV10635_PID, &pid);
> > + if (ret)
> > + return ret;
> > + ret = ov10635_reg_read(client, OV10635_VER, &ver);
> > + if (ret)
> > + return ret;
> > +
> > + if (OV10635_VERSION(pid, ver) != OV10635_VERSION_REG) {
> > + dev_err(&client->dev, "Product ID error %x:%x\n", pid,
ver);
> > + return -ENODEV;
> > + }
>
> Shouldn't the order be reversed here ?
> iow, first chek chip id register, then proceed with the register init ?
Good point! I'll fix this.
Thanks
Phil
--
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 v6] media: i2c: tvp514x: add OF support
From: Lad, Prabhakar
add OF support for the tvp514x driver.
Signed-off-by: Lad, Prabhakar
Acked-by: Laurent Pinchart
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
Cc: Guennadi Liakhovetski
Cc: Sylwester Nawrocki
Cc: Sakari Ailus
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
---
Tested on da850-evm.
RFC v1: https://patchwork.kernel.org/patch/2030061/
RFC v2: https://patchwork.kernel.org/patch/2061811/
Changes for current version from RFC v2:
1: Fixed review comments pointed by Sylwester.
Changes for v2:
1: Listed all the compatible property values in the documentation text file.
2: Removed "-decoder" from compatible property values.
3: Added a reference to the V4L2 DT bindings documentation to explain
what the port and endpoint nodes are for.
4: Fixed some Nits pointed by Laurent.
5: Removed unnecessary header file includes and sort them alphabetically.
Changes for v3:
1: Rebased on patch https://patchwork.kernel.org/patch/2539411/
Changes for v4:
1: added missing call for of_node_put().
2: Rebased the patch on v3.11.
Changes for v5:
1: Fixed calling to a wrong label.
Changes for v6:
1: Fixed minor nits pointed by Laurent.
2: Included the Ack from Laurent.
.../devicetree/bindings/media/i2c/tvp514x.txt | 44 ++
drivers/media/i2c/tvp514x.c| 62 ++--
2 files changed, 100 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp514x.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
new file mode 100644
index 000..46752cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
@@ -0,0 +1,44 @@
+* Texas Instruments TVP514x video decoder
+
+The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
+digital video decoder that digitizes and decodes all popular baseband analog
+video formats into digital video component. The tvp514x decoder supports
analog-
+to-digital (A/D) conversion of component RGB and YPbPr signals as well as A/D
+conversion and decoding of NTSC, PAL and SECAM composite and S-video into
+component YCbCr.
+
+Required Properties :
+- compatible : value should be either one among the following
+ (a) "ti,tvp5146" for tvp5146 decoder.
+ (b) "ti,tvp5146m2" for tvp5146m2 decoder.
+ (c) "ti,tvp5147" for tvp5147 decoder.
+ (d) "ti,tvp5147m1" for tvp5147m1 decoder.
+
+- hsync-active: HSYNC Polarity configuration for endpoint.
+
+- vsync-active: VSYNC Polarity configuration for endpoint.
+
+- pclk-sample: Clock polarity of the endpoint.
+
+For further reading on port node refer to Documentation/devicetree/bindings/
+media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ tvp514x@5c {
+ compatible = "ti,tvp5146";
+ reg = <0x5c>;
+
+ port {
+ tvp514x_1: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ pclk-sample = <0>;
+ };
+ };
+ };
+ ...
+ };
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 01d9757..a1fe823 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1056,6 +1057,42 @@ static struct tvp514x_decoder tvp514x_dev = {
};
+static struct tvp514x_platform_data *
+tvp514x_get_pdata(struct i2c_client *client)
+{
+ struct tvp514x_platform_data *pdata;
+ struct v4l2_of_endpoint bus_cfg;
+ struct device_node *endpoint;
+ unsigned int flags;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
+ return client->dev.platform_data;
+
+ endpoint = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
+ if (!endpoint)
+ return NULL;
+
+ pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto done;
+
+ v4l2_of_parse_endpoint(endpoint, &bus_cfg);
+ flags = bus_cfg.bus.parallel.flags;
+
+ if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ pdata->hs_polarity = 1;
+
+ if (flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ pdata->vs_polarity = 1;
+
+ if (flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
+ pdata->clk_polarity = 1;
+
+done:
+ of_node_put(endpoint);
+ return pdata;
+}
+
/**
* tvp514x_probe() - decoder driver i2c probe handler
* @client: i2c driver client device stru
Re: [PATCHv1 29/38] marvell-ccic: check register address.
On Wed, 29 May 2013 13:00:02 +0200 Hans Verkuil wrote: > From: Hans Verkuil > > Prevent out-of-range register accesses. Certainly I agree with the goal, and what's here is better than what the driver does now. But... > + if (reg->reg > cam->regs_size - 4) > + return -EINVAL; The alleged size of the MMIO region is likely to be quite a bit larger than the offset of the last real register, and I wouldn't count on the hardware to not lock up if you try to access something beyond that last register. So I'd much rather add a MAX_MCAM_REG_OFFSET define to mcam-core.h after the last register define and test against that. I can try to toss something together shortly. Thanks, jon -- 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: Diversity support?
Al 04/06/13 13:23, En/na Patrick Boettcher ha escrit: > On Monday 03 June 2013 17:14:18 Luca Olivetti wrote: So, what's the real status of diversity support? >>> >>> Nobody knows? >> >> I'm not easily discouraged :-) so here's the question again: is there >> some dvb-t usb stick (possibly available on the EU market) with >> diversity support under Linux? > > There is some diversity support hidden in the dib8000-driver and in some > board-drivers which use it. Basically it creates several instances of the > dib8000-driver (one for each demod) but it exposes only one dvb-frontend to > userspace via the API. When the user is tuning the frontend he is, in fact, > tuning all of them in diversity. Mmmh, but, according to the comment, the dib8000 is isdb-t, I'm looking for a dvb-t device. My idea is to do something like this http://www.youtube.com/watch?v=STjQBE3BIYM but using a raspberry pi instead of a windows pc. Unfortunately, the terratec uses the dib0070 (as do most other usb sticks with diversity), I see some fields for diversity in dib0070.[hc], but every report I see it says that it just exposes two frontends and it doesn't support diversity. Of course I can buy a ready-made car tuner, but what's the fun in that? ;-) Bye -- Luca -- 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: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting
On Tue, Jun 04, 2013 at 07:42:22PM +0900, 김승우 wrote: > > > On 2013년 06월 01일 00:29, Daniel Vetter wrote: > > On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote: > >> Hello Daniel, > >> > >> Thanks for your comment. > >> > >> On 2013년 05월 31일 18:14, Daniel Vetter wrote: > >>> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim > >>> wrote: > importer private data in dma-buf attachment can be used by importer to > reimport same dma-buf. > > Seung-Woo Kim (2): > dma-buf: add importer private data to attachment > drm/prime: find gem object from the reimported dma-buf > >>> > >>> Self-import should already work (at least with the latest refcount > >>> fixes merged). At least the tests to check both re-import on the same > >>> drm fd and on a different all work as expected now. > >> > >> Currently, prime works well for all case including self-importing, > >> importing, and reimporting as you describe. Just, importing dma-buf from > >> other driver twice with different drm_fd, each import create its own gem > >> object even two import is done for same buffer because prime_priv is in > >> struct drm_file. This means mapping to the device is done also twice. > >> IMHO, these duplicated creations and maps are not necessary if drm can > >> find previous import in different prime_priv. > > > > Well, that's imo a bug with the other driver. If it doesn't export > > something really simple (e.g. contiguous memory which doesn't require any > > mmio resources at all) it should have a cache of exported dma_buf fds so > > that it hands out the same dma_buf every time. > > Hm, all existing dma-buf exporter including i915 driver implements its > map_dma_buf callback as allocating scatter-gather table with pages in > its buffer and calling dma_map_sg() with the sgt. With different > drm_fds, importing one dma-buf *twice*, then importer calls > dma_buf_attach() and dma_buf_map_attachment() twice at least in drm > importer because re-importing case can only checked with prime_priv in > drm_file as I described. Well, but thanks to all the self-import and re-import checks, it's _impossible_ to import the same dma_buf twice without noticing (presuming both importer and exporter are drm devices). > > > > > Or it needs to be more clever in it's dma_buf_attachment_map functions and > > lookup up a pre-existing iommu mapping. > > > > But dealing with this in the importer is just broken. > > > >>> Second, the dma_buf_attachment is _definitely_ the wrong place to do > >>> this. If you need iommu mapping caching, that should happen at a lower > >>> level (i.e. in the map_attachment callback somewhere of the exporter, > >>> that's what the priv field in the attachment is for). Snatching away > >>> the attachement from some random other import is certainly not the way > >>> to go - attachements are _not_ refcounted! > >> > >> Yes, attachments do not have refcount, so importer should handle and drm > >> case in my patch, importer private data is gem object and it has, of > >> course, refcount. > >> > >> And at current, exporter can not classify map_dma_buf requests of same > >> importer to same buffer with different attachment because dma_buf_attach > >> always makes new attachments. To resolve this exporter should search all > >> different attachment from same importer of dma-buf and it seems more > >> complex than importer private data to me. > >> > >> If I misunderstood something, please let me know. > > > > Like I've said above, just fix this in the exporter. If an importer sees > > two different dma_bufs it can very well presume that it those two indeed > > point to different backing storage. > > Yes, my patch does not break this concept. I just fixed case importing > _one_ dma-buf twice with different drm_fds. See above, if you have two different struct file * for the same underlying buffer object something is wrong already. > > This will be even more important if we attach fences two dma_bufs. If your > > broken exporter creates multiple dma_bufs each one of them will have their > > own fences attached, leading to a complete disasters. Ok, strictly > > speaking if you keep the same reservation pointer for each dma_buf it'll > > work, but that's just a detail of how you solve this in the exporter. > > I can not understand about broken exporter you addressed. I don't mean > exporter makes dma-bufs from one backing storage. > While, my patch prevents not to create drm gem objects from one back > storage by importing one dma-buf with different drm-fds. Well, we also have code in drm prime for that case - if the same dma_buf object shows up multiple times, we'll only import it once. For the second import we'll return the already created drm_gem object from the first import, but with the refcount incremented. > I do not believe the fix of importer is the best way, but at this > moment, I have no idea how I can fix the exporter for this issue. I think if you have drm prime drivers both as impor
Re: Diversity support?
On Monday 03 June 2013 17:14:18 Luca Olivetti wrote: > >> So, what's the real status of diversity support? > > > > Nobody knows? > > I'm not easily discouraged :-) so here's the question again: is there > some dvb-t usb stick (possibly available on the EU market) with > diversity support under Linux? There is some diversity support hidden in the dib8000-driver and in some board-drivers which use it. Basically it creates several instances of the dib8000-driver (one for each demod) but it exposes only one dvb-frontend to userspace via the API. When the user is tuning the frontend he is, in fact, tuning all of them in diversity. IMO, the question which needs to be discussed is for diversity-support is an "how to change the API"-question and how does userspace can control it? In my experience with multi-frontend-hardware, which can do diversity or dual/triple-reception or both at the same time, is that the question is the routing and the grouping of frontend and assigning them to their sinks (stream-interfaces). Right now DVB-API can expose several frontends and dvrs and demuxes for one device, but there is no way to userspace telling the hardware to combine frontend0 and frontend1 to do diversity. When looking at diversity/multi-frontend problems, IMHO, we should not limit ourselves to USB-devices. The real usage of those MFE-devices is in an embedded hardware (STB in a car or at home). -- Patrick -- 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: Diversity support?
On Tuesday 04 June 2013 13:17:49 Antti Palosaari wrote: > On 06/04/2013 10:29 AM, Luca Olivetti wrote: > > Al 04/06/13 01:17, En/na Antti Palosaari ha escrit: > >>> I'm not easily discouraged :-) so here's the question again: is there > >>> some dvb-t usb stick (possibly available on the EU market) with > >>> diversity support under Linux? > >> > >> I have feeling AF9035/IT9135 dual devices could do that. > > > > Looking at the wiki, most devices based on those demodulators are either > > unsupported or have a dual tuner but not diversity. > > Because diversity is not interesting feature at all in normal use case. > Whole DVB-T standard fits poorly for mobile usage and you cannot make > situation that much better using diversity. Well, I have to disagree on this statement. Diversity does not do a lot in fixed reception. That's right, but depending on the TV-standard the diversity gain in mobile reception can be enormous. Several field trials we did in the past years have shown that large parts of the trial route which have not worked at at all in single receiver work like a charm in diversity. Maybe the route-selection in this cases was biased to show off the performance of diversity ... well, it worked - diversity showed off. best regards, -- Patrick -- 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: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting
On 2013년 06월 01일 00:29, Daniel Vetter wrote: > On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote: >> Hello Daniel, >> >> Thanks for your comment. >> >> On 2013년 05월 31일 18:14, Daniel Vetter wrote: >>> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim >>> wrote: importer private data in dma-buf attachment can be used by importer to reimport same dma-buf. Seung-Woo Kim (2): dma-buf: add importer private data to attachment drm/prime: find gem object from the reimported dma-buf >>> >>> Self-import should already work (at least with the latest refcount >>> fixes merged). At least the tests to check both re-import on the same >>> drm fd and on a different all work as expected now. >> >> Currently, prime works well for all case including self-importing, >> importing, and reimporting as you describe. Just, importing dma-buf from >> other driver twice with different drm_fd, each import create its own gem >> object even two import is done for same buffer because prime_priv is in >> struct drm_file. This means mapping to the device is done also twice. >> IMHO, these duplicated creations and maps are not necessary if drm can >> find previous import in different prime_priv. > > Well, that's imo a bug with the other driver. If it doesn't export > something really simple (e.g. contiguous memory which doesn't require any > mmio resources at all) it should have a cache of exported dma_buf fds so > that it hands out the same dma_buf every time. Hm, all existing dma-buf exporter including i915 driver implements its map_dma_buf callback as allocating scatter-gather table with pages in its buffer and calling dma_map_sg() with the sgt. With different drm_fds, importing one dma-buf *twice*, then importer calls dma_buf_attach() and dma_buf_map_attachment() twice at least in drm importer because re-importing case can only checked with prime_priv in drm_file as I described. > > Or it needs to be more clever in it's dma_buf_attachment_map functions and > lookup up a pre-existing iommu mapping. > > But dealing with this in the importer is just broken. > >>> Second, the dma_buf_attachment is _definitely_ the wrong place to do >>> this. If you need iommu mapping caching, that should happen at a lower >>> level (i.e. in the map_attachment callback somewhere of the exporter, >>> that's what the priv field in the attachment is for). Snatching away >>> the attachement from some random other import is certainly not the way >>> to go - attachements are _not_ refcounted! >> >> Yes, attachments do not have refcount, so importer should handle and drm >> case in my patch, importer private data is gem object and it has, of >> course, refcount. >> >> And at current, exporter can not classify map_dma_buf requests of same >> importer to same buffer with different attachment because dma_buf_attach >> always makes new attachments. To resolve this exporter should search all >> different attachment from same importer of dma-buf and it seems more >> complex than importer private data to me. >> >> If I misunderstood something, please let me know. > > Like I've said above, just fix this in the exporter. If an importer sees > two different dma_bufs it can very well presume that it those two indeed > point to different backing storage. Yes, my patch does not break this concept. I just fixed case importing _one_ dma-buf twice with different drm_fds. > > This will be even more important if we attach fences two dma_bufs. If your > broken exporter creates multiple dma_bufs each one of them will have their > own fences attached, leading to a complete disasters. Ok, strictly > speaking if you keep the same reservation pointer for each dma_buf it'll > work, but that's just a detail of how you solve this in the exporter. I can not understand about broken exporter you addressed. I don't mean exporter makes dma-bufs from one backing storage. While, my patch prevents not to create drm gem objects from one back storage by importing one dma-buf with different drm-fds. I do not believe the fix of importer is the best way, but at this moment, I have no idea how I can fix the exporter for this issue. Best Regards, - Seung-Woo Kim > > Cheers, Daniel > -- Seung-Woo Kim Samsung Software R&D Center -- -- 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: Diversity support?
On 06/04/2013 10:29 AM, Luca Olivetti wrote: Al 04/06/13 01:17, En/na Antti Palosaari ha escrit: I'm not easily discouraged :-) so here's the question again: is there some dvb-t usb stick (possibly available on the EU market) with diversity support under Linux? I have feeling AF9035/IT9135 dual devices could do that. Looking at the wiki, most devices based on those demodulators are either unsupported or have a dual tuner but not diversity. Because diversity is not interesting feature at all in normal use case. Whole DVB-T standard fits poorly for mobile usage and you cannot make situation that much better using diversity. Dual hardware could support diversity, but it is not usually enabled by software. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Diversity support?
Al 04/06/13 01:17, En/na Antti Palosaari ha escrit: >> I'm not easily discouraged :-) so here's the question again: is there >> some dvb-t usb stick (possibly available on the EU market) with >> diversity support under Linux? > > I have feeling AF9035/IT9135 dual devices could do that. Looking at the wiki, most devices based on those demodulators are either unsupported or have a dual tuner but not diversity. Bye -- Luca -- 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/2] [media] soc_camera: mt9t112: Remove empty function
On 24 May 2013 16:55, Sachin Kamat wrote:
> After the switch to devm_* functions, the 'remove' function does
> not do anything. Delete it.
>
> Signed-off-by: Sachin Kamat
> Cc: Kuninori Morimoto
> ---
> 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
>
Gentle ping on this series :)
--
With warm regards,
Sachin
--
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 RFC v3] [media] blackfin: add video display device driver
This is a V4L2 driver for Blackfin video display (E)PPI interface.
This module is common for BF537/BF561/BF548/BF609.
Signed-off-by: Scott Jiang
---
drivers/media/platform/blackfin/Kconfig| 15 +-
drivers/media/platform/blackfin/Makefile |1 +
drivers/media/platform/blackfin/bfin_display.c | 929
include/media/blackfin/bfin_display.h | 38 +
4 files changed, 981 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/platform/blackfin/bfin_display.c
create mode 100644 include/media/blackfin/bfin_display.h
diff --git a/drivers/media/platform/blackfin/Kconfig
b/drivers/media/platform/blackfin/Kconfig
index cc23997..10aa435 100644
--- a/drivers/media/platform/blackfin/Kconfig
+++ b/drivers/media/platform/blackfin/Kconfig
@@ -9,7 +9,18 @@ config VIDEO_BLACKFIN_CAPTURE
To compile this driver as a module, choose M here: the
module will be called bfin_capture.
+config VIDEO_BLACKFIN_DISPLAY
+ tristate "Blackfin Video Display Driver"
+ depends on VIDEO_V4L2 && BLACKFIN && I2C
+ select VIDEOBUF2_DMA_CONTIG
+ help
+ V4L2 driver for Blackfin video display (E)PPI interface.
+ This module is common for BF537/BF561/BF548/BF609.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bfin_display.
+
config VIDEO_BLACKFIN_PPI
tristate
- depends on VIDEO_BLACKFIN_CAPTURE
- default VIDEO_BLACKFIN_CAPTURE
+ depends on VIDEO_BLACKFIN_CAPTURE || VIDEO_BLACKFIN_DISPLAY
+ default VIDEO_BLACKFIN_CAPTURE || VIDEO_BLACKFIN_DISPLAY
diff --git a/drivers/media/platform/blackfin/Makefile
b/drivers/media/platform/blackfin/Makefile
index 30421bc..015c8f0 100644
--- a/drivers/media/platform/blackfin/Makefile
+++ b/drivers/media/platform/blackfin/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_VIDEO_BLACKFIN_CAPTURE) += bfin_capture.o
+obj-$(CONFIG_VIDEO_BLACKFIN_DISPLAY) += bfin_display.o
obj-$(CONFIG_VIDEO_BLACKFIN_PPI) += ppi.o
diff --git a/drivers/media/platform/blackfin/bfin_display.c
b/drivers/media/platform/blackfin/bfin_display.c
new file mode 100644
index 000..d35cdcc
--- /dev/null
+++ b/drivers/media/platform/blackfin/bfin_display.c
@@ -0,0 +1,929 @@
+/*
+ * Analog Devices video display driver for (E)PPI interface
+ *
+ * Copyright (c) 2011 - 2013 Analog Devices Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#define DISPLAY_DRV_NAME"bfin_display"
+#define DISP_MIN_NUM_BUF2
+
+struct bfin_disp_format {
+ char *desc;
+ u32 pixelformat;
+ enum v4l2_mbus_pixelcode mbus_code;
+ int bpp; /* bits per pixel */
+ int dlen; /* data length for ppi in bits */
+};
+
+struct bfin_disp_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+struct bfin_disp_device {
+ /* display device instance */
+ struct v4l2_device v4l2_dev;
+ /* v4l2 control handler */
+ struct v4l2_ctrl_handler ctrl_handler;
+ /* device node data */
+ struct video_device video_dev;
+ /* sub device instance */
+ struct v4l2_subdev *sd;
+ /* display config */
+ struct bfin_display_config *cfg;
+ /* ppi interface */
+ struct ppi_if *ppi;
+ /* current output */
+ unsigned int cur_output;
+ /* current selected standard */
+ v4l2_std_id std;
+ /* current selected dv_timings */
+ struct v4l2_dv_timings dv_timings;
+ /* used to store pixel format */
+ struct v4l2_pix_format fmt;
+ /* bits per pixel*/
+ int bpp;
+ /* data length for ppi in bits */
+ int dlen;
+ /* used to store encoder supported format */
+ struct bfin_disp_format *enc_formats;
+ /* number of encoder formats array */
+ int num_enc_formats;
+ /* pointing to current video buffer */
+ struct bfin_disp_buffer *cur_frm;
+ /* buffer queue used in videobuf2 */
+ struct vb2_queue buffer_queue;
+ /* allocator-specific contexts for each plane */
+ struct vb2_alloc_ctx *alloc_ctx;
+ /* que
Re: [PATCH v2] ov10635: Add OmniVision ov10635 SoC camera driver
2013/6/3 Phil Edworthy :
> Signed-off-by: Phil Edworthy
> ---
> v2:
> - Simplified flow in ov10635_s_ctrl.
> - Removed chip ident code - build tested only
>
> drivers/media/i2c/soc_camera/Kconfig |6 +
> drivers/media/i2c/soc_camera/Makefile |1 +
> drivers/media/i2c/soc_camera/ov10635.c | 1141
>
> 3 files changed, 1148 insertions(+)
> create mode 100644 drivers/media/i2c/soc_camera/ov10635.c
>
> diff --git a/drivers/media/i2c/soc_camera/Kconfig
> b/drivers/media/i2c/soc_camera/Kconfig
> index 23d352f..db97ee6 100644
> --- a/drivers/media/i2c/soc_camera/Kconfig
> +++ b/drivers/media/i2c/soc_camera/Kconfig
> @@ -74,6 +74,12 @@ config SOC_CAMERA_OV9740
> help
> This is a ov9740 camera driver
>
> +config SOC_CAMERA_OV10635
> + tristate "ov10635 camera support"
> + depends on SOC_CAMERA && I2C
> + help
> + This is an OmniVision ov10635 camera driver
> +
> config SOC_CAMERA_RJ54N1
> tristate "rj54n1cb0c support"
> depends on SOC_CAMERA && I2C
> diff --git a/drivers/media/i2c/soc_camera/Makefile
> b/drivers/media/i2c/soc_camera/Makefile
> index d0421fe..f3d3403 100644
> --- a/drivers/media/i2c/soc_camera/Makefile
> +++ b/drivers/media/i2c/soc_camera/Makefile
> @@ -10,5 +10,6 @@ obj-$(CONFIG_SOC_CAMERA_OV6650) += ov6650.o
> obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o
> obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o
> obj-$(CONFIG_SOC_CAMERA_OV9740)+= ov9740.o
> +obj-$(CONFIG_SOC_CAMERA_OV10635) += ov10635.o
> obj-$(CONFIG_SOC_CAMERA_RJ54N1)+= rj54n1cb0c.o
> obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o
> diff --git a/drivers/media/i2c/soc_camera/ov10635.c
> b/drivers/media/i2c/soc_camera/ov10635.c
> new file mode 100644
> index 000..bf08aae
> --- /dev/null
> +++ b/drivers/media/i2c/soc_camera/ov10635.c
> @@ -0,0 +1,1141 @@
> +/*
> + * OmniVision OV10635 Camera Driver
> + *
> + * Copyright (C) 2013 Phil Edworthy
> + * Copyright (C) 2013 Renesas Electronics
> + *
> + * This driver has been tested at QVGA, VGA and 720p, and 1280x800 at up to
> + * 30fps and it should work at any resolution in between and any frame rate
> + * up to 30fps.
> + *
> + * FIXME:
> + * Horizontal flip (mirroring) does not work correctly. The image is
> flipped,
> + * but the colors are wrong.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +/* Register definitions */
> +#defineOV10635_VFLIP 0x381c
> +#define OV10635_VFLIP_ON (0x3 << 6)
> +#define OV10635_VFLIP_SUBSAMPLE0x1
> +#defineOV10635_HMIRROR 0x381d
> +#define OV10635_HMIRROR_ON 0x3
> +#define OV10635_PID0x300a
> +#define OV10635_VER0x300b
> +
> +/* IDs */
> +#define OV10635_VERSION_REG0xa635
> +#define OV10635_VERSION(pid, ver) (((pid) << 8) | ((ver) & 0xff))
> +
> +#define OV10635_SENSOR_WIDTH 1312
> +#define OV10635_SENSOR_HEIGHT 814
> +
> +#define OV10635_MAX_WIDTH 1280
> +#define OV10635_MAX_HEIGHT 800
> +
> +struct ov10635_color_format {
> + enum v4l2_mbus_pixelcode code;
> + enum v4l2_colorspace colorspace;
> +};
> +
> +struct ov10635_reg {
> + u16 reg;
> + u8 val;
> +};
> +
> +struct ov10635_priv {
> + struct v4l2_subdev subdev;
> + struct v4l2_ctrl_handlerhdl;
> + int xvclk;
> + int fps_numerator;
> + int fps_denominator;
> + const struct ov10635_color_format *cfmt;
> + int width;
> + int height;
> +};
> +
> +/* default register setup */
> +static const struct ov10635_reg ov10635_regs_default[] = {
> + { 0x0103, 0x01 }, { 0x301b, 0xff }, { 0x301c, 0xff }, { 0x301a, 0xff
> },
> + { 0x3011, 0x02 }, /* drive strength reduced to x1 */
> + { 0x6900, 0x0c }, { 0x6901, 0x11 }, { 0x3503, 0x10 }, { 0x3025, 0x03
> },
> + { 0x3005, 0x20 }, { 0x3006, 0x91 }, { 0x3600, 0x74 }, { 0x3601, 0x2b
> },
> + { 0x3612, 0x00 }, { 0x3611, 0x67 }, { 0x3633, 0xca }, { 0x3602, 0x2f
> },
> + { 0x3603, 0x00 }, { 0x3630, 0x28 }, { 0x3631, 0x16 }, { 0x3714, 0x10
> },
> + { 0x371d, 0x01 }, { 0x4300, 0x38 }, { 0x3007, 0x01 }, { 0x3024, 0x01
> },
> + { 0x3020, 0x0b }, { 0x3702, 0x0d }, { 0x3703, 0x20 }, { 0x3704, 0x15
> },
> + { 0x3709, 0xa8 }, { 0x370c, 0xc7 }, { 0x370d, 0x80 }, { 0x3712, 0x00
> },
> + { 0x3713, 0x20 },
