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>
next prev parent reply other threads:[~2011-05-19 15:56 UTC|newest]
Thread overview: 10+ 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-19 1:04 ` Leon Woestenberg
2011-05-19 14:59 ` Konrad Rzeszutek Wilk
2011-05-19 15:58 ` Clemens Ladisch [this message]
2011-05-19 22:10 ` Leon Woestenberg
2011-05-20 6:51 ` Clemens Ladisch
2011-05-20 8:17 ` Takashi Iwai
2011-05-21 10:59 ` Leon Woestenberg
2011-05-23 8:30 ` Clemens Ladisch
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 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).