>>
>> I will make this an instance parameter if the idea to reduce as many
>> global variables as possible. But if the objection is because each
>> adapter
>> may have different value for variable, then it is indeed a global
>> value.
>> "is_dma64" - which is computed using the size of dma_addr_t - is
>> telling
>> something about the kernel rather than the controller feature.
>>
>
>then having it as variable sounds really really wrong; the size of
>dma_addr_t is a compile time property...
>(and why do you care about it? you see high dma addresses when
>they come
>in, right?)
>
During the module load time, I allocate 32 bit or 64 bit SGLs based on
whether I can receive 64 bit DMA addresses or not. If size of dma_addr_t
is 4, then I allocate only 32 bit SGLs. During the run time, I prepare
32/64 bit SGLs based on this variable. And since this is compile time
system-wide property, I kept it as driver global.
> . And since this is compile time
> system-wide property, I kept it as driver global.
that step I don't understand... why is it a global *VARIABLE* if it's
compile time system-wide property...
On Wed, Mar 09, 2005 at 09:43:47AM -0500, Bagalkote, Sreenivas wrote:
> During the module load time, I allocate 32 bit or 64 bit SGLs based on
> whether I can receive 64 bit DMA addresses or not. If size of dma_addr_t
> is 4, then I allocate only 32 bit SGLs. During the run time, I prepare
> 32/64 bit SGLs based on this variable. And since this is compile time
> system-wide property, I kept it as driver global.
Even for kernels with a 64bit dma_addr_t you can get 32bit dma addresses
only. As a start check whether the pci_set_dma_mask for the 64bit mask
failed - in that case you can always use 32bit SGLs.