linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Mock <jeff@mock.com>
To: fariyaf@gmail.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Sample driver
Date: Wed, 20 Feb 2008 22:54:29 -0800	[thread overview]
Message-ID: <47BD2025.7030001@mock.com> (raw)
In-Reply-To: <8024567.229231203576334424.JavaMail.nabble@isper.nabble.com>



fariyaf@gmail.com wrote:
> Hi,
> 
> Thanks so much for the driver. I have a few doubts.. .may be u cud
> help me out with it.... Basically, I am working on the PPC 405EX
> processor with a peripheral attached to the EBC. I've requested for
> I/O memory & mapped it using ioremap. The following are my doubts:
> 
> 1) How do I ensure that the memory range that I requested is
> non-cacheable. I've to work with non-cacheable memory.  I've
> requested for memory using request_mem_region( ).

In my example the memory range is set to non-cacheable, this needs to be 
done if you are talking to real hardware registers:

   "vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);"

static int
pdev_mmap(struct file *file, struct vm_area_struct *vma)
{
     int fpga_num = iminor(file->f_dentry->d_inode) - PDEV_SPCTL;
     phys_addr_t     paddr;

     paddr = fpga_num ? PDEV_SP1_REG : PDEV_SP0_REG;
#ifdef PDEV_DEBUG
     printk("pdev-gxctl: fpga %d reg mmap() at %016llx\n", fpga_num, paddr);
#endif
     vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
     if (remap_pfn_range(vma,
             vma->vm_start,
             paddr >> PAGE_SHIFT,
             vma->vm_end-vma->vm_start,
             vma->vm_page_prot))
         return -EAGAIN;
     return 0;
}

> 2) Between any consecutive writes or any consecutive reads to the EBC
> peripheral, if I introduce a delay of 500msec, the read/write is
> completing.  Does this have to do anything with caching? What could
> be the  reason for this?


I have no idea where the 500ms delay comes from, this is quite a long 
delay.  Maybe there is some problem with the EBC programming for your 
example.  The EBC is quite flexible and can be programmed in any number 
of insane ways that might cause trouble.

jeff

       reply	other threads:[~2008-02-21  6:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8024567.229231203576334424.JavaMail.nabble@isper.nabble.com>
2008-02-21  6:54 ` Jeff Mock [this message]
2008-02-20  4:13 Sample driver Silwer star
2008-02-20 12:06 ` Josh Boyer
2008-02-20 15:13   ` Jeff Mock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47BD2025.7030001@mock.com \
    --to=jeff@mock.com \
    --cc=fariyaf@gmail.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).