[prev in list] [next in list] [prev in thread] [next in thread]
List: opensolaris-driver-discuss
Subject: Re: [driver-discuss] MAX physically contigous memory possible in
From: "Garrett D'Amore" <garrett () damore ! org>
Date: 2007-12-12 5:49:50
Message-ID: 475F767E.3010306 () damore ! org
[Download RAW message or body]
Somnath kotur wrote:
> Garett,
> Thanks for your update. Yes the alignment is
> changed depending on the requirement..typically it is
> 4K and yes i am indeed using ddi_dma_mem_alloc() to
> allocate the memory region,what i need to know is that
> would the memory that is returned in that single DMA
> cookie(sg len set to 1) be actually physically
> contigous throughout the pages ...i.e is there a limit
> on that ?
>
> I am not bp_mapin the buffers (struct buf) coming in
> from the OS ,instead i am using the
> ddi_dma_buf_bind_handle to an already allocated
> dma_handle ..isnt that enough ?
>
The way the tran_setup_pkt works, is that the pkt comes with the buf
already bound.
If you need the CDB, or SCDB to be mapped in some region contiguous to
the buffer data, then you cannot use these APIs. Indeed, you'll
probably have to come up with some other solution.
But if you want these metadata to be accessible via DMA (e.g. in a
descriptor block), then you can use your own allocated and mapped
regions. But you will *have* to use a different handle than that used
for the buffers, and you'll have separate cookies, etc.
-- Garrett
>
> --- Garrett D'Amore <garrett@damore.org> wrote:
>
>
>> Somnath kotur wrote:
>>
>>> The problem i am facing with this is that i am
>>> seemingly unable to access physical memory beyond
>>>
>> 1
>>
>>> or 2 pages ,is there a way to know verify that the
>>> physical address obtained in my dma
>>> cookie.dmac_laddress is actually physically
>>>
>> contigous
>>
>>> all the way (more than one page ?)
>>>
>>>
>> A few notes.
>>
>> 1) Your alignment looks really big. Do you really
>> need a 64K aligned
>> segment?
>> 2) Your maximum segment length looks suspicious as
>> well... larger than
>> max transfer?
>> 3) If you're using premapped areas of DMA, then you
>> should allocate
>> memory regions with ddi_dma_mem_alloc(). This will
>> arrange the memory
>> such that they can be covered with a single DMA
>> cookie. (Of course, if
>> your constraints cannot be met, then
>> ddi_dma_mem_alloc will fail.)
>> 4) Preallocation of DMA regions for buffers will
>> yield suboptimal
>> performance. (Because then you'd have to bp_mapin()
>> the buffers and
>> copy them into your premapped region.)
>> 5) You might want to look at the newer
>> tran_setup_pkt() interface.
>> While not as well documented, it allows the
>> framework to deal with most
>> of the gruntwork associated with DMA (including
>> using partial mappings
>> and calling multiple times into tran_start() if
>> necessary.)
>>
>> -- Garrett
>>
>>
>>> --- Somnath kotur <somjk@yahoo.com> wrote:
>>>
>>>
>>>
>>>> Hi
>>>> Im writing a SCSI HBA driver which during
>>>>
>> its
>>
>>>> init preallocates lots of memory for DMA setup of
>>>> the
>>>> card ,some of them being chunks of 128KB
>>>>
>>>> The dma_attr structure i am using is as below: i
>>>>
>> do
>>
>>>> have a few doubts in some of the fields,pls let
>>>>
>> me
>>
>>>> know if im using the right values and is there a
>>>> upper
>>>> bound/limitation on the physically contigous
>>>>
>> memory
>>
>>>> possible that can be allocated using the ddi_dma
>>>> calls?
>>>>
>>>> static ddi_dma_attr_t XXX_dma_attrs= {
>>>> DMA_ATTR_V0, /* version of
>>>>
>> this
>>
>>>> structure */
>>>> 0, /* lowest usable
>>>> address */
>>>> 0xffffffffffffffffULL, /* highest usable
>>>> address */
>>>> 0x7fffffff, /* maximum
>>>>
>> DMAable
>>
>>>> byte count */
>>>> 65536, /* alignment in bytes 4K!
>>>>
>> */
>>
>>>> 0x7ff, /* burst sizes
>>>> (any?)
>>>> */
>>>> 1, /* minimum
>>>>
>> transfer
>>
>>>> */
>>>> 0xffffffffU, /* maximum
>>>>
>> transfer
>>
>>>> */
>>>> 0xffffffffffffffffULL, /* maximum
>>>>
>> segment
>>
>>>> length */
>>>> 1, /* maximum number
>>>>
>> of
>>
>>>> segments */
>>>> 1, /* granularity */
>>>> 0, /* flags
>>>>
>> (reserved)
>>
>>>> */
>>>> };
>>>>
>>>>
>>>> Note: alignment and maximum no: of sgs are
>>>> parameters
>>>> that can be tuned based on request
>>>>
>>>> Thanks n Regards
>>>> Som
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
> ____________________________________________________________________________________
>
>>>
>>>
>>>> Never miss a thing. Make Yahoo your home page.
>>>> http://www.yahoo.com/r/hs
>>>> _______________________________________________
>>>> driver-discuss mailing list
>>>> driver-discuss@opensolaris.org
>>>>
>>>>
>>>>
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>
>>>
>>>
>>>
>>>
>>>
>>>
> ____________________________________________________________________________________
>
>>> Looking for last minute shopping deals?
>>> Find them fast with Yahoo! Search.
>>>
> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>
>>> _______________________________________________
>>> driver-discuss mailing list
>>> driver-discuss@opensolaris.org
>>>
>>>
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>
>>>
>>>
>>
>
>
>
> ____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
>
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic