Re: [Xenomai-help] PCI Framegrabber real-time driver

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 4447 bytes --]

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 long as you are alone with this requirement on your
>> system,
>> this is the simpler way to go.
> 
>>>>> 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_master(p);
> pci_set_consistent_dma_mask(p, DMA_32BIT_MASK);
> pci_alloc_consistent(p, 2097152, &phys_ptr);

I think this depends on how long your system already ran, how much of
the physical memory had already been allocated and how it was released
again, probably causing heavy fragmentation. But if you have, say, 512
MB and only require that 2 MB, the probability to get obtain this block
during system startup is quite high. So it's best to place he request in
the driver's module init routine.

> 
> ...
> 
> You can also get the irq line number here from p->irq . Use this for 
> rtdm_irq_request().
> 
>>>>> Please, what do you suggest about the design of my driver?
> 
> 1. Use RTDM and write a kernel module. It allows you to write a 
> specific test program on it, which you can reuse later on every 
> occasion where you need to know whether the driver or the program 
> contains causes a problem. You can also shut an RTDM driver down 
> manually if your RT program ever bails out 'ungracefully'. 

More precisely, you can try to kill stalled RT file descriptors by
writing their number to /proc/xenomai/rtdm/open_fildes. Depends on the
driver if this works, i.e. its closure handler has to support the
enforced cleanup from every device state.

> 
> 2. Use 2 framebuffers and implement a ping-pong buffer, so that the 
> grabber may fill in a second buffer while you're using the contents of 
> number one. Avoid copying of the data.
> 
> 3. Remember to use the PCI DMA API. It is the easiest way to guarantee 
> that CPU L1/2 caching is not going to fool you some day. You do not 
> want to mess yourself with MTRR and friends (?) on the CPU. (Something 
> I think may be a serious issue when using tricks like the ones 
> mentioned earlier.)
> 
> 4. Use portable functions to access your PCI card, such as read[b/w/l]
> () and write[b/w/l](). Don't do *(unsigned int *)ptr = val. Where 
> needed, use memory write barriers such as wmb(), to avoid instruction 
> reordering by the compiler. 
> 
> 5. Don't catch interrupts that weren't meant for you. If your ISR gets 
> called, check some status register of your card to see if it was the 
> cause of the interrupt. If so, finish with return(RTDM_IRQ_ENABLE). 
> Otherwise, return(RTDM_IRQ_PROPAGATE), so other handlers may catch it 
> (and reset the possibly shared IRQ line, which is never going to be 
> deasserted otherwise (== stuck)).

Currently, RTDM_IRQ_PROPAGATE tells the RT-IRQ subsystem to forward
unhandled IRQs to the Linux domain. If you have to do this as there is
an IRQ sharing between a RT and a non-RT device, you are generally
doomed anyway. The non-RT device can then easily break the determinism
of the RT subsystem. We should rework this flag or at least its
documentation soon when RTDM will be extended (slightly) to support
RT-IRQ sharing (which is RT-safe by design).

> 
> (Anyone, feel free to comment on these lines.)
> 
> BTW, when specifying mem=510M, how would you access the range 510-512 
> without causing a segmentation fault ?
> 
>>> Well, there is only one thing I can see at the moment. I would need
>> to rewrite 
>>> the interrupt part to use a real-time interrupt routine instead of
>> the PCI 
>>> interrupt method, am I right?
> 
> I think you are. I have used an RTDM event (rtdm_event_t) to signal the 
> blocking read function that a frame has arrived.
> 
> Also see the 16550A RTDM driver example to see how events are used to 
> accomplish this.
> 

Yep, another example, just "a bit" more complicated than xeno_timerbench.

> 
> Jeroen.
> 
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]