Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Dmitriy Tochansky <toch@dfpost.ru>
To: Dan Malek <dan@embeddededge.com>
Cc: linux-mips@linux-mips.org
Subject: Re: mmap problem
Date: Wed, 8 Dec 2004 10:40:17 +0300	[thread overview]
Message-ID: <20041208104017.2f71acc2.toch@dfpost.ru> (raw)
In-Reply-To: <AD0D6ED2-4868-11D9-BB64-003065F9B7DC@embeddededge.com>

On Tue, 7 Dec 2004 10:57:20 -0500
Dan Malek <dan@embeddededge.com> wrote:

> >   ret = remap_page_range( start, 0x40000000, size, vma->vm_page_prot
> >   
> > ); //
> 
> Use io_remap_page_range, it has the same parameters, and is
> designed to work with > 32-bit physical addresses.
  Well, I test it. On module load - unresolved symbol remap_page_range_high. I looking for some ifdefs
where this function blocked, but seems like everithing is ok. :(

> 
> Also, you should really use pci_resource_* functions to get
> information about the pci address, size, etc.  Don't hardcode this,
> even for testing.

There is a new variant. If I by hand make io_remap_page_range visible - system hangs. :(
  

#define MAX_DEV 4

struct pci_dev *devs[MAX_DEV];
struct pci_dev *dev = NULL;

...

static unsigned long *offset;

static int mdrv_mmap(struct file * file, struct vm_area_struct *vma)                                   
{                                                                                                      
                                                                                                       
 int ret;                                                                                              
 struct inode *inode;                                                                                  
 inode = file->f_dentry->d_inode;                                                                      
 
 ret = -EINVAL;                                                                                        
 unsigned long start = vma->vm_start;                                                                  
 unsigned long size = (vma->vm_end-vma->vm_start);                                                     
 
 struct pci_dev *curdev = NULL;
 
 int minor = MINOR(inode->i_rdev);
 
 printk("minor = %d\n",minor);
 
 curdev = (devs[minor]);
 
 offset = (unsigned long *)pci_resource_start(curdev,0);
 
 printk("offset = 0x%X\n", offset );

 ret = io_remap_page_range( start, offset, size, vma->vm_page_prot );

 return ret;                                                               
}

  reply	other threads:[~2004-12-08  7:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-07 15:42 mmap problem Dmitriy Tochansky
2004-12-07 15:42 ` Dmitriy Tochansky
2004-12-07 15:57 ` Dan Malek
2004-12-08  7:40   ` Dmitriy Tochansky [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-12-08  7:28 Alexey Shinkin
2004-12-08  7:35 ` Dmitriy Tochansky

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=20041208104017.2f71acc2.toch@dfpost.ru \
    --to=toch@dfpost.ru \
    --cc=dan@embeddededge.com \
    --cc=linux-mips@linux-mips.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