Skip to contentSkip to conversation

How to replace bus_to_virt()?

DISCUSSION Stefan Richter 5 participants 7 messages Apr 30, 2006 – May 3, 2006 SCSI

lore
Share & tools
lore
#0 lore raw

Hi all,

is there a *direct* future-proof replacement for bus_to_virt()?

It appears there are already architectures which do not define a bus_to_virt() funtion or macro. If there isn't a direct replacement, is there at least a way to detect at compile time whether bus_to_virt() exists?

I am asking because the sbp2 driver uses bus_to_virt() if CONFIG_IEEE1394_SBP2_PHYS_DMA=y. I would like to replace this option by an automatic detection when the respective code in sbp2 is actually required.

The current implementation is this: Sbp2 uses bus_to_virt() to map from 1394 bus addresses (which are currently identical to local host bus addresses) to virtual addresses. These addresses are supplied by SBP-2 target devices and point to *arbitrary* locations within buffers. These buffers are supplied by the SCSI subsystem/ block IO subsystem. That is, sbp2 has no influence on the location of the buffers, nor has it influence on the location of the chunk of data which an SBP-2 target is reading or writing at a particular moment. But thanks to bus_to_virt(), sbp2 does not need to know which SCSI command buffer (and to which scatter/gather element in the buffer) a particular data transfer belongs to.

From what I found out so far, I am afraid I have to implement a totally different address mapping scheme for the cases where physical DMA is not available; i.e. a scheme that enables sbp2 to look up the s/g element to which a transfer is directed, based on the 1394 bus address of the transfer.

Signature · 3 lines
Stefan Richter
-=====-=-==- -=-- ====-
http://arcgraph.de/sr/
#1 lore raw
Quoted 7 lines · Stefan Richter

Hi all,

is there a *direct* future-proof replacement for bus_to_virt()?

It appears there are already architectures which do not define a bus_to_virt() funtion or macro. If there isn't a direct replacement, is there at least a way to detect at compile time whether bus_to_virt() exists?

I'd go one step further: given a world with iommu's, and multiple pci domains etc, how can you know there even IS such a translation possible (without first having set it up from the other direction)?

#2 lore raw
Quoted 9 lines · Arjan van de Ven
Quoted 3 lines · Stefan Richter

is there a *direct* future-proof replacement for bus_to_virt()?

It appears there are already architectures which do not define a bus_to_virt() funtion or macro. If there isn't a direct replacement, is there at least a way to detect at compile time whether bus_to_virt() exists?

I'd go one step further: given a world with iommu's, and multiple pci domains etc, how can you know there even IS such a translation possible (without first having set it up from the other direction)?

Well, we actually do set it up from the other direction. But in a way that does not work with IOMMUs...

AFAIU, the patch "dc395x: dynamically map scatter-gather for PIO" [1] by Guennadi Liakhovetski is dealing with the same issue. I am not yet clear whether I could adopt this method for sbp2.
[1] http://marc.theaimsgroup.com/?l=linux-scsi&t=114400790300004

Signature · 3 lines
Stefan Richter
-=====-=-==- -=-= ----=
http://arcgraph.de/sr/
#3 lore raw
Quoted 14 lines · Stefan Richter
Quoted 9 lines · Arjan van de Ven
Quoted 6 lines · Stefan Richter

is there a *direct* future-proof replacement for bus_to_virt()?

It appears there are already architectures which do not define a bus_to_virt() funtion or macro. If there isn't a direct replacement, is there at least a way to detect at compile time whether bus_to_virt() exists?

Quoted 3 lines

I'd go one step further: given a world with iommu's, and multiple pci domains etc, how can you know there even IS such a translation possible (without first having set it up from the other direction)?

Quoted 7 lines

Well, we actually do set it up from the other direction. But in a way that does not work with IOMMUs...

AFAIU, the patch "dc395x: dynamically map scatter-gather for PIO" [1] by Guennadi Liakhovetski is dealing with the same issue. I am not yet clear whether I could adopt this method for sbp2.
[1] http://marc.theaimsgroup.com/?l=linux-scsi&t=114400790300004

I would be, obviously, interested to hear any results with that one.

Thanks
Guennadi
---
Guennadi Liakhovetski

#4 lore raw
Quoted 24 lines · Guennadi Liakhovetski
Quoted 14 lines · Stefan Richter
Quoted 9 lines · Arjan van de Ven
Quoted 6 lines · Stefan Richter

is there a *direct* future-proof replacement for bus_to_virt()?

It appears there are already architectures which do not define a bus_to_virt() funtion or macro. If there isn't a direct replacement, is there at least a way to detect at compile time whether bus_to_virt() exists?

Quoted 3 lines

I'd go one step further: given a world with iommu's, and multiple pci domains etc, how can you know there even IS such a translation possible (without first having set it up from the other direction)?

Quoted 7 lines

Well, we actually do set it up from the other direction. But in a way that does not work with IOMMUs...

AFAIU, the patch "dc395x: dynamically map scatter-gather for PIO" [1] by Guennadi Liakhovetski is dealing with the same issue. I am not yet clear whether I could adopt this method for sbp2.
[1] http://marc.theaimsgroup.com/?l=linux-scsi&t=114400790300004

Quoted 6 lines

I would be, obviously, interested to hear any results with that one.

Thanks
Guennadi
---
Guennadi Liakhovetski

Just make your own macro! When they change the "@(#*%^+@~%" kernel, which they will continue to do, just adapt your macro. You've probably already figured out that, for ix86-32 bits (no extended addressing), you OR in PAGE_OFFSET. That's an artifact of how the pages tables are set up. Of course the space needs to have been mapped! This means you get the address-space from ioremap_xx() or from get_dma_pages(). You also need to fiddle with SetPageReserved() if you get the pages from get_dma_pages() or else everything pretends to work, but doesn't.

Something like:

Note, since this will fill in a DMA scatter-list with page-size elements, the pages don't need to be continuous so I have a macro called get_dma_page() that just gets a page of "order 1".

//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= //
// Get some physical pages and lock them down into memory. Return
// the number of pages available.
//
static int32_t get_pages(int32_t pages)

{
     int32_t i;
     uint32_t virt;
     release_pages();
     pages = (pages < NR_PAGES) ? pages : NR_PAGES;
     for(i=0; i< pages; i++)
     {
         if((virt = get_dma_page()) == 0)
             break;
         info->dma[i].loc = (void *) virt;
         info->dma[i].ram = virt_to_bus(info->dma[i].loc);
         SetPageReserved(virt_to_page(virt));
         memset(info->dma[i].loc, 0x00, PAGE_SIZE);     // Clear page
         *((char *)info->dma[i].loc) = (char) i;        // Mark it
     }
     return (info->pages = i);
}

Also note that linux-kernel hates posix integer types, even when they are local to this file, so there will be lots of folks who claim that you shouldn't write code like this. Others will claim that everything should be done though pci_alloc_xxx(). Go figure!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips). New book: http://www.lymanschool.com
_


****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

#5 lore raw
Quoted 3 lines

Just make your own macro! When they change the "@(#*%^+@~%" kernel, which they will continue to do,

we're not changing 2.6.12. If you don't want changes you can just keep using the kernel you are using ;)

Quoted 4 lines

just adapt your macro. You've
probably already figured out that, for ix86-32 bits (no extended addressing), you OR in PAGE_OFFSET. That's an artifact of how the pages tables are set up.

and that isn't even possible like that on other architectures, like ones which have IOMMU's. That is actually the reason stuff like this is deprecated, and why we have a real API for dma nowadays.

#6 lore raw
In reply to Stefan Richter
Quoted 7 lines

is there a *direct* future-proof replacement for bus_to_virt()?

It appears there are already architectures which do not define a bus_to_virt() funtion or macro. If there isn't a direct replacement, is there at least a way to detect at compile time whether bus_to_virt() exists?

I am asking because the sbp2 driver uses bus_to_virt() if CONFIG_IEEE1394_SBP2_PHYS_DMA=y. I would like to replace this option by an automatic detection when the respective code in sbp2 is actually required.

The current implementation is this: Sbp2 uses bus_to_virt() to map from 1394 bus addresses (which are currently identical to local host bus addresses) to virtual addresses.

Sounds like you should be using phys_to_virt() anyway?

Segher