headers
Eric Nelson | 2 Jul 2010 22:47
Favicon
Gravatar

Contiguous memory allocations

Does anyone know if there's a common infrastructure for allocation
of DMA'able memory by drivers and applications above the straight
kernel API (dma_alloc_coherent)?

I'm working with Freescale i.MX51 drivers to do 720P video 
input and output and the embedded calls to dma_alloc_coherent
fail except when used right after boot because of fragmentation.

I'm fighting the urge to write yet another special-purpose allocator
for video buffers thinking this must be a common problem with a
solution already, but I can't seem to locate one.

The closest thing I've found is the bigphysarea patch, which doesn't
appear to be supported or headed toward main-line.

Thanks in advance,

Eric Nelson

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 4 comments |
headers
Emmanuel CHANSON | 2 Jul 2010 23:43
Picon
Gravatar

Re: V4L & VLC 1.0.6 and standard selection

Many thanks Andy,

Using SECAM-DK is Ok with SECAM_K1

BR,

Emmanuel

2010/6/27 Andy Walls <awalls <at> md.metrocast.net>

> On Tue, 2010-06-22 at 22:07 -0700, manunc wrote:
> > I am trying to catch my tuner card signal by using vlc and v4l
> >
> > Under Fedora 12:
> > vlc-1.0.6-1.fc12.i686
> > vlc-core-1.0.6-1.fc12.i686
> >
> >
> > libv4l-0.6.4-1.fc12.i686
> > xorg-x11-drv-v4l-0.2.0-3.fc12.1.i686
> > v4l2-tool-1.0.3-5.fc12.i686
> >
> >
> > By using the cvlc command to catch the tuner card signal and setting
> > standard in the command line I did not see the SECAM K1, so I wonder if
> the
> > fix has been committed or not in this release or if I have to patch the
> > sources:
> >
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Simmonds | 5 Jul 2010 12:10
Picon

Re: Contiguous memory allocations

On 02/07/10 21:47, Eric Nelson wrote:
> Does anyone know if there's a common infrastructure for allocation
> of DMA'able memory by drivers and applications above the straight
> kernel API (dma_alloc_coherent)?
>
> I'm working with Freescale i.MX51 drivers to do 720P video
> input and output and the embedded calls to dma_alloc_coherent
> fail except when used right after boot because of fragmentation.
>
> I'm fighting the urge to write yet another special-purpose allocator
> for video buffers thinking this must be a common problem with a
> solution already, but I can't seem to locate one.
>
> The closest thing I've found is the bigphysarea patch, which doesn't
> appear to be supported or headed toward main-line.
>
> Thanks in advance,
>

dma_alloc_coherent is pretty much just a wrapper round get_free_pages, 
which is the lowest level allocator in the kernel. So, no there is no 
other option (but see below). The simplest thing is to make sure your 
driver is loaded at boot time and to grab all the memory you need then 
and never let it go. That's what I do.

If you are desperate, you can use the bigphysarea patch - it's quite 
common on streaming video devices - but you will have to port it to your 
kernel. Or, you can restrict the memory the kernel uses with something 
like "mem=128M" on the command line and take that above 128M for 
yourself. You will have to map it in with ioremap(_nocache).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Nelson | 5 Jul 2010 16:27
Favicon
Gravatar

Re: Contiguous memory allocations

On 07/05/2010 03:10 AM, Chris Simmonds wrote:
> On 02/07/10 21:47, Eric Nelson wrote:
>> Does anyone know if there's a common infrastructure for allocation
>> of DMA'able memory by drivers and applications above the straight
>> kernel API (dma_alloc_coherent)?
>>
>> I'm working with Freescale i.MX51 drivers to do 720P video
>> input and output and the embedded calls to dma_alloc_coherent
>> fail except when used right after boot because of fragmentation.
>>
>> I'm fighting the urge to write yet another special-purpose allocator
>> for video buffers thinking this must be a common problem with a
>> solution already, but I can't seem to locate one.
>>
>> The closest thing I've found is the bigphysarea patch, which doesn't
>> appear to be supported or headed toward main-line.
>>
>> Thanks in advance,
>
> dma_alloc_coherent is pretty much just a wrapper round get_free_pages,
> which is the lowest level allocator in the kernel. So, no there is no
> other option (but see below). The simplest thing is to make sure your
> driver is loaded at boot time and to grab all the memory you need then
> and never let it go. That's what I do.
>
Thanks Chris.

The trouble is always "how much"? If we don't know at startup what kind of
video's needed or what size(s) of camera input may be needed, it's impossible
to tune. In the current Freescale kernels, there are at least 4 separate
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Simmonds | 5 Jul 2010 17:31
Picon

Re: Contiguous memory allocations

On 05/07/10 15:27, Eric Nelson wrote:
> On 07/05/2010 03:10 AM, Chris Simmonds wrote:
>> On 02/07/10 21:47, Eric Nelson wrote:
>>> Does anyone know if there's a common infrastructure for allocation
>>> of DMA'able memory by drivers and applications above the straight
>>> kernel API (dma_alloc_coherent)?
>>>
>>> I'm working with Freescale i.MX51 drivers to do 720P video
>>> input and output and the embedded calls to dma_alloc_coherent
>>> fail except when used right after boot because of fragmentation.
>>>
>>> I'm fighting the urge to write yet another special-purpose allocator
>>> for video buffers thinking this must be a common problem with a
>>> solution already, but I can't seem to locate one.
>>>
>>> The closest thing I've found is the bigphysarea patch, which doesn't
>>> appear to be supported or headed toward main-line.
>>>
>>> Thanks in advance,
>>
>> dma_alloc_coherent is pretty much just a wrapper round get_free_pages,
>> which is the lowest level allocator in the kernel. So, no there is no
>> other option (but see below). The simplest thing is to make sure your
>> driver is loaded at boot time and to grab all the memory you need then
>> and never let it go. That's what I do.
>>
> Thanks Chris.
>
> The trouble is always "how much"? If we don't know at startup what kind of
> video's needed or what size(s) of camera input may be needed, it's
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Nelson | 5 Jul 2010 18:14
Favicon
Gravatar

Re: Contiguous memory allocations

On 07/05/2010 08:31 AM, Chris Simmonds wrote:
> On 05/07/10 15:27, Eric Nelson wrote:
>> On 07/05/2010 03:10 AM, Chris Simmonds wrote:
>>> On 02/07/10 21:47, Eric Nelson wrote:
>>>> Does anyone know if there's a common infrastructure for allocation
>>>> of DMA'able memory by drivers and applications above the straight
>>>> kernel API (dma_alloc_coherent)?
>>>>
>>>> I'm working with Freescale i.MX51 drivers to do 720P video
>>>> input and output and the embedded calls to dma_alloc_coherent
>>>> fail except when used right after boot because of fragmentation.
>>>>
>>>> I'm fighting the urge to write yet another special-purpose allocator
>>>> for video buffers thinking this must be a common problem with a
>>>> solution already, but I can't seem to locate one.
>>>>
>>>> The closest thing I've found is the bigphysarea patch, which doesn't
>>>> appear to be supported or headed toward main-line.
>>>>
>>>> Thanks in advance,
>>>
>>> dma_alloc_coherent is pretty much just a wrapper round get_free_pages,
>>> which is the lowest level allocator in the kernel. So, no there is no
>>> other option (but see below). The simplest thing is to make sure your
>>> driver is loaded at boot time and to grab all the memory you need then
>>> and never let it go. That's what I do.
>>>
>> Thanks Chris.
>>
>> The trouble is always "how much"? If we don't know at startup what
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Appleby | 7 Jul 2010 11:50
Picon

saa7231 Help

Hi,

First time posting on this list, I am hoping someone will be able to help.

I have a compro S800F Hybrid tuner card which which has a saa7231,
which I would like to get working for my MythTV box. I have found the
drivers at http://www.jusst.de/hg/saa7231/ but they are incomplete.
After a few hours of hacking around I have managed to get the card
recognised by the Kernel (2.6.32), and have succesfully gotten
/dev/video0 showing up, as well as the I2C communication returning
sensible looking data.
I was wondering if anyone has any info or data on this device they
could share? My queries to NXP, Trident and Manu Abraham have so far
gone unanswered. Im sort of fumbling around in the dark with a lot of
the chips hardware.

Regards

Simon Appleby

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 2 comments |
headers
Akhilesh Soni | 8 Jul 2010 15:13
Picon

SUGGESTION FOR A Linux based Card

Hello,

I am looking for a linux based card for 4 composite input with unbalanced
audio for full D1 resolution. The idea is to capture live stream and encode
using vlc-ffmpeg for http streaming. It is better to have availability of
these cards in India.

Thanks,
Akhilesh
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 0 comments |
headers
Charlie X. Liu | 8 Jul 2010 21:37
Favicon

RE: SUGGESTION FOR A Linux based Card

Sensoray Company has Model 811 (a 4-channel PCI-Express Capture Card:
http://www.sensoray.com/products/811.htm ) and Model 911 (a 4-channel
PCI/104-Express Capture Card: http://www.sensoray.com/products/911.htm ).
Both have 4 Composite/S-Video inputs, plus 4 channel of stereo audio inputs.
They all work well under Linux.

Charlie X. Liu  <at>  Sensoray Co.

-----Original Message-----
From: video4linux-list-bounces <at> redhat.com
[mailto:video4linux-list-bounces <at> redhat.com] On Behalf Of Akhilesh Soni
Sent: Thursday, July 08, 2010 6:14 AM
To: video4linux-list <at> redhat.com
Subject: SUGGESTION FOR A Linux based Card

Hello,

I am looking for a linux based card for 4 composite input with unbalanced
audio for full D1 resolution. The idea is to capture live stream and encode
using vlc-ffmpeg for http streaming. It is better to have availability of
these cards in India.

Thanks,
Akhilesh
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

--
(Continue reading)

Permalink | Reply | 5 comments |
headers
Norbert Wegener | 8 Jul 2010 22:54
Picon

1b80:d393 Afatech supported?

I got a Conceptronics usb dvb-t stick. lsusb displays it as:
...
Bus 001 Device 007: ID 1b80:d393 Afatech
...
When insterting it /var/log/messages shows:
Jul  8 22:05:24 norbert-laptop kernel: [40109.230106] usb 1-1: new high
speed USB device using ehci_hcd and address 9
Jul  8 22:05:24 norbert-laptop kernel: [40109.390630] usb 1-1:
configuration #1 chosen from 1 choice

but no dvb driver is loaded.
Is this stick supposed to work under a current distribution as Ubuntu
10.04 64Bit?
Thanks
Norbert Wegener

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 1 comment |

Gmane