All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Leon Woestenberg <leon.woestenberg@gmail.com>
Cc: linux-pci@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: mmap() implementation for pci_alloc_consistent() memory?
Date: Thu, 19 May 2011 17:58:35 +0200	[thread overview]
Message-ID: <4DD53E2B.2090002@ladisch.de> (raw)
In-Reply-To: <20110519145921.GE9854@dumpdata.com>

Konrad Rzeszutek Wilk wrote:
> On Thu, May 19, 2011 at 12:14:40AM +0200, Leon Woestenberg wrote:
> > I cannot get my driver's mmap() to work. I allocate 64 KiB ringbuffer
> > using pci_alloc_consistent(), then implement mmap() to allow programs
> > to map that memory into their user space.
> > ...
> > int ringbuffer_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> > {
> >         /* the buffer allocated with pci_alloc_consistent() */
> > 	void *vaddr = ringbuffer_virt;
> > 	int ret;
> > 
> > 	/* find the struct page that describes vaddr, the buffer
> > 	 * allocated with pci_alloc_consistent() */
> > 	struct page *page = virt_to_page(lro_char->engine->ringbuffer_virt);
> > 	vmf->page = page;
> > 
> >         /*** I have verified that vaddr, page, and the pfn correspond with vaddr = pci_alloc_consistent() ***/
> > 	ret = vm_insert_pfn(vma, address, page_to_pfn(page));
> 
> address is the vmf->virtual_address?
> 
> And is the page_to_pfn(page) value correct? As in:
> 
>   int pfn = page_to_pfn(page);
> 
>   WARN(pfn << PAGE_SIZE != vaddr,"Something fishy.");
> 
> Hm, I think I might have misled you now that I look at that WARN.
> 
> The pfn to be supplied has to be physical page frame number. Which in
> this case should be your bus addr shifted by PAGE_SIZE. Duh! Try that
> value.

There are wildly different implementations of pci_alloc_consistent
(actually dma_alloc_coherent) that can return somewhat different
virtual and/or physical addresses.

> I think a better example might be the 'hpet_mmap' code

Which is x86 and ia64 only.

> > static int ringbuffer_mmap(struct file *file, struct vm_area_struct *vma)
> > {
> > 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);

So is this an architecture without coherent caches?
Or would you want to use pgprot_dmacoherent, if available?


I recently looked into this problem, and ended up with the code below.
I then decided that streaming DMA mappings might be a better idea.


Regards,
Clemens


/* returns the struct page from the result of dma_alloc_coherent() */
struct page *dma_coherent_page(struct device *device,
                               void *address, dma_addr_t bus)
{
#if defined(CONFIG_ALPHA) || \
    defined(CONFIG_CRIS) || \
    defined(CONFIG_IA64) || \
    defined(CONFIG_MIPS) || \
    (defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)) || \
    defined(CONFIG_SPARC64) || \
    defined(CONFIG_TILE) || \
    defined(CONFIG_UNICORE32) || \
    defined(CONFIG_X86)
#ifdef CONFIG_MIPS
	if (!plat_device_is_coherent(device))
		address = CAC_ADDR(address);
#endif
	return virt_to_page(address);
#elif defined(CONFIG_ARM)
	return pfn_to_page(dma_to_pfn(device, bus));
#elif defined(CONFIG_FRV) || \
      defined(CONFIG_MN10300)
#ifdef CONFIG_MN10300
	if (WARN(!IS_ALIGNED(bus, PAGE_SIZE)), "PCI SRAM allocator is broken\n")
		return NULL;
#endif
	return virt_to_page(bus_to_virt(bus));
#elif defined(CONFIG_M68K) || \
      defined(CONFIG_SPARC32)
	return virt_to_page(phys_to_virt(bus));
#elif defined(CONFIG_PARISC)
	return virt_to_page(__va(bus));
#elif defined(CONFIG_SUPERH)
	return pfn_to_page(bus >> PAGE_SHIFT);
#elif defined(CONFIG_MICROBLAZE) || \
      (defined(CONFIG_PPC) && defined(CONFIG_NOT_COHERENT_CACHE))
	unsigned long vaddr = (unsigned long)address;
	pgd_t *pgd = pgd_offset_k(vaddr);
	pud_t *pud = pud_offset(pgd, vaddr);
	pmd_t *pmd = pmd_offset(pud, vaddr);
	pte_t *pte = pte_offset_kernel(pmd, vaddr);
	if (!pte_none(*pte) && pte_present(*pte)) {
		unsigned long pfn = pte_pfn(*pte);
		if (pfn_valid(pfn))
			return pfn_to_page(pfn);
	}
	return NULL;
#elif defined(CONFIG_XTENSA)
#error non-cacheable remapping not implemented
#else
#error unknown architecture
#endif
}

WARNING: multiple messages have this Message-ID (diff)
From: Clemens Ladisch <clemens@ladisch.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Leon Woestenberg <leon.woestenberg@gmail.com>
Cc: linux-pci@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: mmap() implementation for pci_alloc_consistent() memory?
Date: Thu, 19 May 2011 17:58:35 +0200	[thread overview]
Message-ID: <4DD53E2B.2090002@ladisch.de> (raw)
In-Reply-To: <20110519145921.GE9854@dumpdata.com>

Konrad Rzeszutek Wilk wrote:
> On Thu, May 19, 2011 at 12:14:40AM +0200, Leon Woestenberg wrote:
> > I cannot get my driver's mmap() to work. I allocate 64 KiB ringbuffer
> > using pci_alloc_consistent(), then implement mmap() to allow programs
> > to map that memory into their user space.
> > ...
> > int ringbuffer_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> > {
> >         /* the buffer allocated with pci_alloc_consistent() */
> > 	void *vaddr = ringbuffer_virt;
> > 	int ret;
> > 
> > 	/* find the struct page that describes vaddr, the buffer
> > 	 * allocated with pci_alloc_consistent() */
> > 	struct page *page = virt_to_page(lro_char->engine->ringbuffer_virt);
> > 	vmf->page = page;
> > 
> >         /*** I have verified that vaddr, page, and the pfn correspond with vaddr = pci_alloc_consistent() ***/
> > 	ret = vm_insert_pfn(vma, address, page_to_pfn(page));
> 
> address is the vmf->virtual_address?
> 
> And is the page_to_pfn(page) value correct? As in:
> 
>   int pfn = page_to_pfn(page);
> 
>   WARN(pfn << PAGE_SIZE != vaddr,"Something fishy.");
> 
> Hm, I think I might have misled you now that I look at that WARN.
> 
> The pfn to be supplied has to be physical page frame number. Which in
> this case should be your bus addr shifted by PAGE_SIZE. Duh! Try that
> value.

There are wildly different implementations of pci_alloc_consistent
(actually dma_alloc_coherent) that can return somewhat different
virtual and/or physical addresses.

> I think a better example might be the 'hpet_mmap' code

Which is x86 and ia64 only.

> > static int ringbuffer_mmap(struct file *file, struct vm_area_struct *vma)
> > {
> > 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);

So is this an architecture without coherent caches?
Or would you want to use pgprot_dmacoherent, if available?


I recently looked into this problem, and ended up with the code below.
I then decided that streaming DMA mappings might be a better idea.


Regards,
Clemens


/* returns the struct page from the result of dma_alloc_coherent() */
struct page *dma_coherent_page(struct device *device,
                               void *address, dma_addr_t bus)
{
#if defined(CONFIG_ALPHA) || \
    defined(CONFIG_CRIS) || \
    defined(CONFIG_IA64) || \
    defined(CONFIG_MIPS) || \
    (defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)) || \
    defined(CONFIG_SPARC64) || \
    defined(CONFIG_TILE) || \
    defined(CONFIG_UNICORE32) || \
    defined(CONFIG_X86)
#ifdef CONFIG_MIPS
	if (!plat_device_is_coherent(device))
		address = CAC_ADDR(address);
#endif
	return virt_to_page(address);
#elif defined(CONFIG_ARM)
	return pfn_to_page(dma_to_pfn(device, bus));
#elif defined(CONFIG_FRV) || \
      defined(CONFIG_MN10300)
#ifdef CONFIG_MN10300
	if (WARN(!IS_ALIGNED(bus, PAGE_SIZE)), "PCI SRAM allocator is broken\n")
		return NULL;
#endif
	return virt_to_page(bus_to_virt(bus));
#elif defined(CONFIG_M68K) || \
      defined(CONFIG_SPARC32)
	return virt_to_page(phys_to_virt(bus));
#elif defined(CONFIG_PARISC)
	return virt_to_page(__va(bus));
#elif defined(CONFIG_SUPERH)
	return pfn_to_page(bus >> PAGE_SHIFT);
#elif defined(CONFIG_MICROBLAZE) || \
      (defined(CONFIG_PPC) && defined(CONFIG_NOT_COHERENT_CACHE))
	unsigned long vaddr = (unsigned long)address;
	pgd_t *pgd = pgd_offset_k(vaddr);
	pud_t *pud = pud_offset(pgd, vaddr);
	pmd_t *pmd = pmd_offset(pud, vaddr);
	pte_t *pte = pte_offset_kernel(pmd, vaddr);
	if (!pte_none(*pte) && pte_present(*pte)) {
		unsigned long pfn = pte_pfn(*pte);
		if (pfn_valid(pfn))
			return pfn_to_page(pfn);
	}
	return NULL;
#elif defined(CONFIG_XTENSA)
#error non-cacheable remapping not implemented
#else
#error unknown architecture
#endif
}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-05-19 15:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-18 22:14 mmap() implementation for pci_alloc_consistent() memory? Leon Woestenberg
2011-05-18 22:14 ` Leon Woestenberg
2011-05-19  1:04 ` Leon Woestenberg
2011-05-19  1:04   ` Leon Woestenberg
2011-05-19 14:59 ` Konrad Rzeszutek Wilk
2011-05-19 14:59   ` Konrad Rzeszutek Wilk
2011-05-19 15:58   ` Clemens Ladisch [this message]
2011-05-19 15:58     ` Clemens Ladisch
2011-05-19 22:10     ` Leon Woestenberg
2011-05-19 22:10       ` Leon Woestenberg
2011-05-20  6:51       ` Clemens Ladisch
2011-05-20  6:51         ` Clemens Ladisch
2011-05-20  8:17         ` Takashi Iwai
2011-05-20  8:17           ` Takashi Iwai
2011-05-21 10:59           ` Leon Woestenberg
2011-05-21 10:59             ` Leon Woestenberg
2011-05-23  8:30             ` Clemens Ladisch
2011-05-23  8:30               ` Clemens Ladisch
2011-05-24 14:18               ` Leon Woestenberg
2011-05-24 14:18                 ` Leon Woestenberg

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=4DD53E2B.2090002@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=konrad.wilk@oracle.com \
    --cc=leon.woestenberg@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pci@vger.kernel.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.