How to replace bus_to_virt()?

How to replace bus_to_virt()?

[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 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.
-- 
Stefan Richter
-=====-=-==- -=-- ====-
http://arcgraph.de/sr/

Re: How to replace bus_to_virt()?

[Arjan van de Ven]

On Sun, 2006-04-30 at 16:52 +0200, Stefan Richter wrote:
> 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)?

Re: How to replace bus_to_virt()?

[Stefan Richter]

Arjan van de Ven wrote:
> On Sun, 2006-04-30 at 16:52 +0200, Stefan Richter wrote:
>>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
-- 
Stefan Richter
-=====-=-==- -=-= ----=
http://arcgraph.de/sr/

Re: How to replace bus_to_virt()?

[Guennadi Liakhovetski]

On Mon, 1 May 2006, Stefan Richter wrote:

> Arjan van de Ven wrote:
> > On Sun, 2006-04-30 at 16:52 +0200, Stefan Richter wrote:
> > > 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

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

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: How to replace bus_to_virt()?

[linux-os (Dick Johnson)]

On Wed, 3 May 2006, Guennadi Liakhovetski wrote:

> On Mon, 1 May 2006, Stefan Richter wrote:
>
>> Arjan van de Ven wrote:
>>> On Sun, 2006-04-30 at 16:52 +0200, Stefan Richter wrote:
>>>> 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
>
> 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
_
\x1a\x04

****************************************************************
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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: How to replace bus_to_virt()?

[Arjan van de Ven]

> 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 ;)

>  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. 

Re: How to replace bus_to_virt()?

[Segher Boessenkool]

> 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