diff for duplicates of <ecb4efd10504101516482a9785@mail.gmail.com> diff --git a/a/1.txt b/N1/1.txt index 6d29fc4..7634769 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,39 +1,2 @@ I'm working on a Au1550 driver for a PCI based co-processor. The processor exports a 4Mbyte BAR that I want to mmap() into user space. -From inside the driver I can read and write to the BAR using an -address from ioremap_nocache(). I can read location with known values -and get back the expected data and with JTAG on the co-processor I saw -that data written from the 1550 really makes it into the PCI device. -From userspace with the llseek/read interface I can read the data well -known data and the data written by the driver. - -However, I'm not having any luck getting mmap() to work. I must just -be mapping the wrong address... I tried a bunch of different -combinations of addresses, but so far I haven't had any luck getting -the mmap() to work. - -The mmap() handler calls remap_pfn_range with a physical address -returned from pci_resource_start(). - -My driver code has something like: -remap_pfn_range ( vma, vma->vm_start, - ( pci_resource_start ( pdev, BAR ) >> PAGE_SHIFT ) + vma->pgoff, - vma->vm_end - vma->vm_start, vma->vm_page_prot ); - -vma->pgoff is zero, so this should map starting at the beginning of -the BAR. From user space, the data at the mmap()ed address isn't what -I was expecting. - -For a sanity check, I tried using /dev/mem to mmap the PCI address as -returned by lspci. This seems to return similar, but not identical -data as my device driver. But it isn't what I was expecting. - -I tried a similar test using /dev/mem and the address the linear -framebuffer on my desktop machine (as returned by lspci). The mapped -data matches the pixels on the first line (as reported by xmag). - -Has anyone tried something like this on the Alchemy processors with a -recent kernel? - - Many thanks, - Clem Taylor diff --git a/a/content_digest b/N1/content_digest index 7c87a86..ea4cd6d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,43 +5,6 @@ "\00:1\0" "b\0" "I'm working on a Au1550 driver for a PCI based co-processor. The\n" - "processor exports a 4Mbyte BAR that I want to mmap() into user space.\n" - "From inside the driver I can read and write to the BAR using an\n" - "address from ioremap_nocache(). I can read location with known values\n" - "and get back the expected data and with JTAG on the co-processor I saw\n" - "that data written from the 1550 really makes it into the PCI device.\n" - "From userspace with the llseek/read interface I can read the data well\n" - "known data and the data written by the driver.\n" - "\n" - "However, I'm not having any luck getting mmap() to work. I must just\n" - "be mapping the wrong address... I tried a bunch of different\n" - "combinations of addresses, but so far I haven't had any luck getting\n" - "the mmap() to work.\n" - "\n" - "The mmap() handler calls remap_pfn_range with a physical address\n" - "returned from pci_resource_start().\n" - "\n" - "My driver code has something like:\n" - "remap_pfn_range ( vma, vma->vm_start,\n" - " ( pci_resource_start ( pdev, BAR ) >> PAGE_SHIFT ) + vma->pgoff,\n" - " vma->vm_end - vma->vm_start, vma->vm_page_prot );\n" - "\n" - "vma->pgoff is zero, so this should map starting at the beginning of\n" - "the BAR. From user space, the data at the mmap()ed address isn't what\n" - "I was expecting.\n" - "\n" - "For a sanity check, I tried using /dev/mem to mmap the PCI address as\n" - "returned by lspci. This seems to return similar, but not identical\n" - "data as my device driver. But it isn't what I was expecting.\n" - "\n" - "I tried a similar test using /dev/mem and the address the linear\n" - "framebuffer on my desktop machine (as returned by lspci). The mapped\n" - "data matches the pixels on the first line (as reported by xmag).\n" - "\n" - "Has anyone tried something like this on the Alchemy processors with a\n" - "recent kernel?\n" - "\n" - " Many thanks,\n" - Clem Taylor + processor exports a 4Mbyte BAR that I want to mmap() into user space. -2f59c06a1298adc9144eaab9b0d5fd37752cc753ac8057450f82b94525f69c6a +1cd4b7182eb622da14bb6a7307f726488d4369dec59df8b045e43252e8196953
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox