[dvb] Question on dvb-core re-structure
Hi, With the new structure of dvb-core (moved up one directory), previous DVB/ATSC adapters were moved to media/usb, media/pci and media/mmc. For SoC that supports integrated DVB functionality, where should the adapter's code be located in the new structure? I don't see it fit any of the above three options. Thanks, -- Hamad Kadmany, QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [dvb] Question on dvb-core re-structure
On 01/10/2013 1:13 PM, Antti Palosaari wrote: I could guess that even for the SoCs there is some bus used internally. If it is not one of those already existing, then create new directly just like one of those existing and put it there. Thanks for the answer. I just wanted to clarify - it's integrated into the chip and accessed via memory mapped registers, so I'm not sure which category to give the new directory (parallel to pci/mms/usb). Should I just put the adapter's sources directory directly under media directory? Thanks, -- Hamad Kadmany, QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: [media][dvb-core] Question on dvr device copy
Hi, I would appreciate if anyone can feedback on this, I'm considering implementing mmap in demux/dvr devices so that user-space can access the input/output buffers directly without the need for read/write operations. Thanks Hamad -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Hamad Kadmany Sent: Sunday, February 12, 2012 4:19 PM To: linux-media@vger.kernel.org Subject: [media][dvb-core] Question on dvr device copy Hi, Currently when playing stream from memory through dvr device (through write calls), the written buffer is copied from user-space to kernel space. The same applies when recording a stream, the TS packets received from HW are copied to dvr ring-buffer. I'm a bit concerned about the performance due to the copy, and whether we better have a memory mapped ring-buffer in dvr device output and/or dvr device input with user-space to cope with high bitrate streams. Your feedback on this will be mostly appreciated. Thanks Hamad -- 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
[media][dvb-core] Question on dvr device copy
Hi, Currently when playing stream from memory through dvr device (through write calls), the written buffer is copied from user-space to kernel space. The same applies when recording a stream, the TS packets received from HW are copied to dvr ring-buffer. I'm a bit concerned about the performance due to the copy, and whether we better have a memory mapped ring-buffer in dvr device output and/or dvr device input with user-space to cope with high bitrate streams. Your feedback on this will be mostly appreciated. Thanks Hamad -- 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
DVB: Question on TS_DECODER
Hi, dvb_dmxdev_start_feed sets TS_DECODER to ts_type regardless of whether pes-output was set to DMX_OUT_DECODER or not, but depending on the pes-type only. This might cause confusion, there's a hidden assumption that if user is not interested to send data to decoder, the pes type must always be DMX_PES_OTHER, which makes the API a bit un-clear to user-space. If user-space is only interested in recording video packets for example, and by mistake sets DMX_PES_VIDEO (because it just says the pes type which is independent from the pes output type) then packets will make their way to the decoder eventhough this was not the intention. Is there any special reason to have this? Thanks, Hamad -- 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
[dvb] Problem registering demux0 device
Hi, I'm implementing new adapter for DVB, I built a module to register the adapter and demux/net devices. From the kernel log I see all actions are performed fine and dvb_register_device (called by dvb_dmxdev_init) is called successfully for net0/demux0/dvr0, however, demux0/dvr0 devices do not show up, ls /sys/class/dvb shows only dvb0.net0 (and nothing appears under /dev/dvb/ anyhow). What could cause not having demux0/dvr0 registered? Note that net0 shows up fine. Appreciate your help. Thanks Hamad -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [dvb] Problem registering demux0 device
On 07-12-2011 13:50, Mauro Carvalho Chehab wrote:
It is hard to tell the exact problem without looking into the driver. Are you
handling the error codes returned by the register functions?
You can follow what's happening inside your driver by enabling tracepoints.
Here is one of the scripts I used when I need to know what functions are
called:
#!/bin/bash
cd /sys/kernel/debug/tracing
echo disabling trace
echo 0 tracing_enabled
echo getting funcs
FUNC=`cat /sys/kernel/debug/tracing/available_filter_functions|grep -i
drx`
echo setting functions
echo $FUNCset_ftrace_filter
echo set trace type
echo function_graph current_tracer
echo enabling trace
echo 1 tracing_enabled
(the above enables tracing only for functions with drx in the name - you'll
need to tailor it for your specific needs)
Of course, after finishing the device creation, you should disable the trace
and
get its results with:
#!/bin/bash
cd /sys/kernel/debug/tracing
echo 0 tracing_enabled
less trace
I suggest you to compare the trace for a device that is known to create all
dvb
nodes with your driver. This may give you a good hint about what is missing on
your driver.
Regards,
Mauro
I'm checking return error codes, no problems there, I also added traces within
the register functions and they all run fine. Here's my code that registers the
demux device (note that the net device works fine):
static struct dvb_demux demux;
static struct dmxdev dmxdev;
static struct dvb_net net;
static struct dmx_frontend fe_hw;
static struct dmx_frontend fe_mem;
static int test_start_feed(struct dvb_demux_feed *feed)
{
printk(KERN_INFO %s executed\n, __FUNCTION__);
return 0;
}
static int test_stop_feed(struct dvb_demux_feed *feed)
{
printk(KERN_INFO %s executed\n, __FUNCTION__);
return 0;
}
static int test_write_to_decoder(struct dvb_demux_feed *feed, const u8 *buf,
size_t len)
{
printk(KERN_INFO %s executed\n, __FUNCTION__);
return 0;
}
// initialization specific demux device
void test_demux_device_init(struct dvb_adapter* adapter)
{
int result;
printk(KERN_INFO %s executed\n, __FUNCTION__);
memset(demux, 0, sizeof(struct dvb_demux));
demux.dmx.capabilities = DMX_TS_FILTERING |
DMX_PES_FILTERING |
DMX_SECTION_FILTERING |
DMX_MEMORY_BASED_FILTERING |
DMX_CRC_CHECKING |
DMX_TS_DESCRAMBLING;
demux.priv = NULL;
demux.filternum = 31;
demux.feednum = 31;
demux.start_feed = test_start_feed;
demux.stop_feed = test_stop_feed;
demux.write_to_decoder = test_write_to_decoder;
printk(KERN_INFO %s call dvb_dmx_init\n, __FUNCTION__);
if ((result = dvb_dmx_init(demux)) 0)
{
printk(KERN_ERR %s: dvb_dmx_init failed\n, __FUNCTION__);
goto init_failed;
}
dmxdev.filternum = 31;
dmxdev.demux = demux.dmx;
dmxdev.capabilities = 0;
printk(KERN_INFO %s call dvb_dmxdev_init\n, __FUNCTION__);
if ((result = dvb_dmxdev_init(dmxdev, adapter)) 0)
{
printk(KERN_ERR %s: dvb_dmxdev_init failed (errno=%d)\n,
__FUNCTION__, result);
goto init_failed_dmx_release;
}
fe_hw.source = DMX_FRONTEND_0;
printk(KERN_INFO %s call add_frontend\n, __FUNCTION__);
if ((result = demux.dmx.add_frontend(demux.dmx, fe_hw)) 0)
{
printk(KERN_ERR %s: add_frontend (hw) failed (errno=%d)\n,
__FUNCTION__, result);
goto init_failed_dmxdev_release;
}
fe_mem.source = DMX_MEMORY_FE;
if ((result = demux.dmx.add_frontend(demux.dmx, fe_mem)) 0)
{
printk(KERN_ERR %s: add_frontend (mem) failed (errno=%d)\n,
__FUNCTION__, result);
goto init_failed_remove_hw_frontend;
}
if ((result = demux.dmx.connect_frontend(demux.dmx, fe_hw)) 0)
{
printk(KERN_ERR %s: connect_frontend failed (errno=%d)\n,
__FUNCTION__, result);
goto init_failed_remove_mem_frontend;
}
if ((result = dvb_net_init(adapter, net, demux.dmx)) 0)
{
printk(KERN_ERR %s: dvb_net_init failed (errno=%d)\n,
__FUNCTION__, result);
goto init_failed_disconnect_frontend;
}
init_failed_disconnect_frontend:
demux.dmx.disconnect_frontend(demux.dmx);
init_failed_remove_mem_frontend:
demux.dmx.remove_frontend(demux.dmx, fe_mem);
init_failed_remove_hw_frontend:
demux.dmx.remove_frontend(demux.dmx,
RE: Support for multiple section feeds with same PIDs
Hello Andreas So if I understand correctly due to HW limitations back then, if in user-space we want to get data of two PSI tables that share the same PID, we could only setup one section filter with that PID and the user-space needs to do the extra filtering (to parse and separate the sections belonging to each table)? Regards, Hamad -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Andreas Oberritter Sent: Thursday, December 01, 2011 3:37 PM To: Hamad Kadmany Cc: linux-media@vger.kernel.org Subject: Re: Support for multiple section feeds with same PIDs Hello Hamad, On 29.11.2011 09:05, Hamad Kadmany wrote: Question on the current behavior of dvb_dmxdev_filter_start (dmxdev.c) In case of DMXDEV_TYPE_SEC, the code restricts of having multiple sections feeds allocated (allocate_section_feed) with same PID. From my experience, applications might request allocating several section feeds using same PID but with different filters (for example, in DVB standard, SDT and BAT tables have same PID). The current implementation only supports of having multiple filters on the same section feed. Any special reason why it was implemented this way? AFAIR, if you created more than one PID filter on the same PID, only one filter would see data on most or all hardware back then. So if you have multiple filters on the same PID, then the real filter you're setting should be a merged version of those filters. If you use dvb_demux, it will do the necessary post-processing for you. This driver implements section filtering: http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/driver/dvb/drivers/media/dv b/avia/avia_gt_napi.c?rev=1.208view=markup Regards, Andreas -- 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: Support for multiple section feeds with same PIDs
Hello Andreas On 01.12.2011 15:58, Andreas Oberritter wrote: No. dvb_demux will do the extra filtering. Userspace won't notice. Got it now, thanks. The one downside I see to this is that the feed will be stopped momentarily (dvb_dmxdev_feed_stop) before new filter is allocated that have the same PID. Regards, Hamad -- 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: Support for multiple section feeds with same PIDs
Hello Andreas On 01.12.2011 16:30, Andreas Oberritter wrote: Yes. Feel free to enhance the demux API to your needs in order to fully support the features of your hardware. I have another question in that regard: Actually, multiple filter with same PID is assumed to be possible in case we have one filter for TS packets (for DVR device) and another for video PES (for playback). So it seems there's such assumption in this regard but not for sections. Is my understanding correct? Regards, Hamad -- 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: Support for multiple section feeds with same PIDs
Hi, Sorry to repeat the question, anyone has an idea on this? I appreciate your feedback. Thank you Hamad -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Hamad Kadmany Sent: Tuesday, November 29, 2011 10:05 AM To: linux-media@vger.kernel.org Subject: Support for multiple section feeds with same PIDs Hello Question on the current behavior of dvb_dmxdev_filter_start (dmxdev.c) In case of DMXDEV_TYPE_SEC, the code restricts of having multiple sections feeds allocated (allocate_section_feed) with same PID. From my experience, applications might request allocating several section feeds using same PID but with different filters (for example, in DVB standard, SDT and BAT tables have same PID). The current implementation only supports of having multiple filters on the same section feed. Any special reason why it was implemented this way? Thank you Hamad -- 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
Support for multiple section feeds with same PIDs
Hello Question on the current behavior of dvb_dmxdev_filter_start (dmxdev.c) In case of DMXDEV_TYPE_SEC, the code restricts of having multiple sections feeds allocated (allocate_section_feed) with same PID. From my experience, applications might request allocating several section feeds using same PID but with different filters (for example, in DVB standard, SDT and BAT tables have same PID). The current implementation only supports of having multiple filters on the same section feed. Any special reason why it was implemented this way? Thank you Hamad -- 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
