> > using vmalloc is one of two ways to use capture buffers. The other > > one (which is used in the mmap case) is anonymous userspace memory. > > So that's why it's not in the kernel address space... Exactly. > > There is a scatter list which points to the pages used for the > > video buffer. But that doesn't help you. IIRC it isn't allowed > > call kmap() in IRQ context, so you can't access the actual data. > > I know that in IRQ handler things can be done is very restricted > but because the BT chip transfers the image via DMA it's sure > that the address is in the physical memory, so in theory there is > nothing to do about exception handler etc. If I can reach somehow > a physical memory (not translating to virtual address, because it's > not in the kernel addr. space) then I can access the image. Well, in general you can't. There is no way to bypass the MMU, you can't access physical pages without an page table entry. > I found out that the scatterlist contains the pages but I don't > know how to access these pages in the IRQ handler. There is some page_to_virt() function, which may give you a pointer to the kernel virtual address of the page. Be prepared to get a NULL pointer. IIRC this works for LOWMEM pages (because they are mapped all the time into the kernel address space for performance reasons) and doesn't for HIGHMEM pages (which must be kmapped() to access them). > Now I'm trying to calculate from the time needed to grab the image > measured from the last grabbed image on that channel. If the > (time/20)%2 is 0 then the field is the same as the last one if not 0 > then it's not the same and it should not be processed. What is wrong with the timestamp in v4l2_buffer->ts? If that doesn't work for some reason: there are still two reserved fields in the v4l2_buffer struct which can be (ab)used to pass buffer meta data to the application. Gerd -- Weil die späten Diskussionen nicht mal mehr den Rotwein lohnen. -- Wacholder in “Melanie”
