On 12/11/06, Franck Bui-Huu <[email protected]> wrote:
[email protected] wrote:
> + atomic_t ref_count;
> + atomic_t vma_count;
what purpose do these counters deserve ?
You are right. I can remove them.
> +
> +void hcb_wait_for_ack(struct hecubafb_par *par)
> +{
> +
> + int timeout;
> + unsigned char ctl;
> +
> + timeout=500;
> + do {
> + ctl = hcb_get_ctl(par);
> + if ((ctl & HCB_ACK_BIT))
> + return;
> + udelay(1);
> + } while (timeout--);
> + printk(KERN_ERR "timed out waiting for ack\n");
> +}
When timeout occur this function does not return any error values.
the callers needn't to be warn in this case ?
You are right. I need to figure out what exactly to do. Currently, if
a timeout is observed it normally means the display controller is
hung. However, in some cases the controller does seem to recover
after some period of time. I guess I should probably return an error
and terminate pending activity.
> +
> +/* this is to find and return the vmalloc-ed fb pages */
> +static struct page* hecubafb_vm_nopage(struct vm_area_struct *vma,
> + unsigned long vaddr, int *type)
> +{
> + unsigned long offset;
> + struct page *page;
> + struct fb_info *info = vma->vm_private_data;
> +
> + offset = (vaddr - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
> + if (offset >= (DPY_W*DPY_H)/8)
> + return NOPAGE_SIGBUS;
> +
> + page = vmalloc_to_page(info->screen_base + offset);
> + if (!page)
> + return NOPAGE_OOM;
> +
> + get_page(page);
> + if (type)
> + *type = VM_FAULT_MINOR;
> + return page;
> +}
> +
so page can be accessed by using vma->start virtual address....
The userspace app would be doing:
ioctl(fd, FBIOGET_FSCREENINFO, &finfo);
ioctl(fd, FBIOGET_VSCREENINFO, &vinfo);
screensize = ( vinfo.xres * vinfo.yres * vinfo.bits_per_pixel) / 8;
maddr = mmap(finfo.mmio_start, screensize, PROT_WRITE, MAP_SHARED, fd, 0);
> +static int hecubafb_page_mkwrite(struct vm_area_struct *vma,
[snip]
> +
> + if (!(videomemory = vmalloc(videomemorysize)))
> + return retval;
and here the kernel access to the same page by using address returned
by vmalloc which are different from the previous one. So 2 different
addresses map the same physical page. In this case are there any cache
aliasing issues specially for x86 arch ?
I think that PTEs set up by vmalloc are marked cacheable and via the
above nopage end up as cacheable. I'm not doing DMA. So the accesses
are through the cache so I don't think cache aliasing is an issue for
this case. Please let me know if I misunderstood.
Thanks,
jayakumar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
