All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.