>>... how can I use an IOCTL interface like a condition variable?
>
>By using one of RTDM's services in your driver's IOCTL handler,
>typically either a semaphore or an event. See the Xenomai API doc for
>details - and have a look at the existing drivers...
Thank you. I'll take a better look on RT
>>... how can I use an IOCTL interface like a condition variable?
>
>By using one of RTDM's services in your driver's IOCTL handler,
>typically either a semaphore or an event. See the Xenomai API doc for
>details - and have a look at the existing drivers...
Thank you. I'll take a better look on RT
Rodrigo Rosenfeld Rosas wrote:
>>> How could I
>>> share this memory with userspace RT-programs in a deterministic way?
>> Set up the memory mapping between kernel and user space during (non-rt)
>> initialisation. This means that you have to create some mapping from the
>> physical block into the u
>> How could I
>> share this memory with userspace RT-programs in a deterministic way?
>Set up the memory mapping between kernel and user space during (non-rt)
>initialisation. This means that you have to create some mapping from the
>physical block into the user space address range. I think
>remap
Rodrigo Rosenfeld Rosas wrote:
>> Yes, this is a way to obtain this continous memory. The other, more
>> organised way is via the old bigphysarea patch. It's still being update
>> even for 2.6 (http://pv105234.reshsg.uci.edu/~jfeise/Downloads/zr36120).
>> Anyway, as long as you are alone with this
>> >>>continuous physic memory area and I can't get it through kmalloc
>
>I did a quick check and I could easily allocate a 2MB contiguous,
>aligned buffer on my system using the following calls. (See DMA-
>mapping.txt in your kernel Documentation folder):
>
>struct pci_dev *p;
>
>...
>
>pci_set_ma
>Yes, this is a way to obtain this continous memory. The other, more
>organised way is via the old bigphysarea patch. It's still being update
>even for 2.6 (http://pv105234.reshsg.uci.edu/~jfeise/Downloads/zr36120).
>Anyway, as long as you are alone with this requirement on your system,
>this is th
Rodrigo Rosenfeld Rosas wrote:
>>> How could I
>>> share this memory with userspace RT-programs in a deterministic way?
>> Set up the memory mapping between kernel and user space during (non-rt)
>> initialisation. This means that you have to create some mapping from the
>> physical block into the u
>> How could I
>> share this memory with userspace RT-programs in a deterministic way?
>Set up the memory mapping between kernel and user space during (non-rt)
>initialisation. This means that you have to create some mapping from the
>physical block into the user space address range. I think
>remap
Rodrigo Rosenfeld Rosas wrote:
>> Yes, this is a way to obtain this continous memory. The other, more
>> organised way is via the old bigphysarea patch. It's still being update
>> even for 2.6 (http://pv105234.reshsg.uci.edu/~jfeise/Downloads/zr36120).
>> Anyway, as long as you are alone with this
>> >>>continuous physic memory area and I can't get it through kmalloc
>
>I did a quick check and I could easily allocate a 2MB contiguous,
>aligned buffer on my system using the following calls. (See DMA-
>mapping.txt in your kernel Documentation folder):
>
>struct pci_dev *p;
>
>...
>
>pci_set_ma
>Yes, this is a way to obtain this continous memory. The other, more
>organised way is via the old bigphysarea patch. It's still being update
>even for 2.6 (http://pv105234.reshsg.uci.edu/~jfeise/Downloads/zr36120).
>Anyway, as long as you are alone with this requirement on your system,
>this is th
Gilles Chanteperdrix escreveu:
Rodrigo Rosenfeld Rosas wrote:
> The memory is obtained passing the kernel the parameter "mem=510M". So, the
> kernel won't use the last 2 Mb. I know it is not an elegant solution but it's
> pretty simple and I can't imagine another one...
Another one, suggeste
vdkeybus wrote:
>> Argh, I confused something here.
>>
>> Yes, this is a way to obtain this continous memory. The other, more
>> organised way is via the old bigphysarea patch. It's still being
>> update
>> even for 2.6
>> (http://pv105234.reshsg.uci.edu/~jfeise/Downloads/zr36120).
>> Anyway, as lo
vdkeybus wrote:
>> Argh, I confused something here.
>>
>> Yes, this is a way to obtain this continous memory. The other, more
>> organised way is via the old bigphysarea patch. It's still being
>> update
>> even for 2.6
>> (http://pv105234.reshsg.uci.edu/~jfeise/Downloads/zr36120).
>> Anyway, as lo
Rodrigo Rosenfeld Rosas wrote:
> Hi Jan, thank you for replying (I was really guessing that your answer would
> be the first ;) ).
How did you? ;)
>
> I'll comment along the message.
>
>
>>>Hi,
>>>
>>>...
>>>Let me explain how the driver works. It initializes the board with some
>>>PCI writes
Rodrigo Rosenfeld Rosas wrote:
> The memory is obtained passing the kernel the parameter "mem=510M". So, the
> kernel won't use the last 2 Mb. I know it is not an elegant solution but
> it's
> pretty simple and I can't imagine another one...
Another one, suggested in "Linux devices drivers"
Hi Jan, thank you for replying (I was really guessing that your answer would
be the first ;) ).
I'll comment along the message.
>> Hi,
>>
>> ...
>> Let me explain how the driver works. It initializes the board with some
>> PCI writes on startup. It's passed to the kernel the parameter "mem=510M"
Rodrigo Rosenfeld Rosas wrote:
> Hi,
>
> I developed a v4l2 driver for my PCI framegrabber and I need to use it in my
> real-time applications. I think I need to write a new one with real-time
> constrainments. But I'm not sure of which API would be the best one for this
> kind of driver.
>
> I k
Hi,
I developed a v4l2 driver for my PCI framegrabber and I need to use it in my
real-time applications. I think I need to write a new one with real-time
constrainments. But I'm not sure of which API would be the best one for this
kind of driver.
I know about existence of RTDM, but I'm not sure i
Rodrigo Rosenfeld Rosas wrote:
> Hi Jan, thank you for replying (I was really guessing that your answer would
> be the first ;) ).
How did you? ;)
>
> I'll comment along the message.
>
>
>>>Hi,
>>>
>>>...
>>>Let me explain how the driver works. It initializes the board with some
>>>PCI writes
Rodrigo Rosenfeld Rosas wrote:
> The memory is obtained passing the kernel the parameter "mem=510M". So, the
> kernel won't use the last 2 Mb. I know it is not an elegant solution but
> it's
> pretty simple and I can't imagine another one...
Another one, suggested in "Linux devices drivers"
Hi Jan, thank you for replying (I was really guessing that your answer would
be the first ;) ).
I'll comment along the message.
>> Hi,
>>
>> ...
>> Let me explain how the driver works. It initializes the board with some
>> PCI writes on startup. It's passed to the kernel the parameter "mem=510M"
Rodrigo Rosenfeld Rosas wrote:
> Hi,
>
> I developed a v4l2 driver for my PCI framegrabber and I need to use it in my
> real-time applications. I think I need to write a new one with real-time
> constrainments. But I'm not sure of which API would be the best one for this
> kind of driver.
>
> I k
Hi,
I developed a v4l2 driver for my PCI framegrabber and I need to use it in my
real-time applications. I think I need to write a new one with real-time
constrainments. But I'm not sure of which API would be the best one for this
kind of driver.
I know about existence of RTDM, but I'm not sure i
25 matches
Mail list logo
