>
>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.
>
Please help me understand: If dma_addr_t is 64 bit, I will get 64bit
addresses in
>> >
>> >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.
>> >
>>
>> Please help me understand: If dma_addr_t is 64 bit, I will get
On Wed, Mar 09, 2005 at 05:47:27PM -0500, Bagalkote, Sreenivas wrote:
> >
> >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.
> >
>
>
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
>
On Wed, 2005-03-09 at 12:44 -0500, Bagalkote, Sreenivas wrote:
> >> >
> >> >> . 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...
Bagalkote, Sreenivas <[EMAIL PROTECTED]> wrote:
>>> . 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...
>>
>
> I see your point! Are you saying I
>> >
>> >> . 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...
>> >
>>
>> I see your point! Are you saying I should use
On Wed, 2005-03-09 at 11:01 -0500, Bagalkote, Sreenivas wrote:
> >
> >> . 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...
> >
>
> I see your
>
>> . 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...
>
I see your point! Are you saying I should use if(sizeof(dma_addr_t)==8)
instead of the
> . 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...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
>>
>> 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
On Tue, 2005-03-08 at 18:08 -0500, Bagalkote, Sreenivas wrote:
>
> 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.
>
On Tue, 2005-03-08 at 18:08 -0500, Bagalkote, Sreenivas wrote:
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 -
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
. 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...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
. 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...
I see your point! Are you saying I should use if(sizeof(dma_addr_t)==8)
instead of the shortcut
On Wed, 2005-03-09 at 11:01 -0500, Bagalkote, Sreenivas wrote:
. 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...
I see your point! Are you
Bagalkote, Sreenivas [EMAIL PROTECTED] wrote:
. 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...
I see your point! Are you saying I should use
. 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...
I see your point! Are you saying I should use
if(sizeof(dma_addr_t)==8)
instead of the
On Wed, 2005-03-09 at 12:44 -0500, Bagalkote, Sreenivas wrote:
. 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...
I see your point!
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
On Wed, Mar 09, 2005 at 05:47:27PM -0500, Bagalkote, Sreenivas wrote:
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.
Please help me
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.
Please help me understand: If dma_addr_t is 64 bit, I will get 64bit
addresses in
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.
Please help me understand: If dma_addr_t is 64 bit, I will get 64bit
addresses in scatterlist
>
>> +static int is_dma64;
>
>the fact that this is a global variable worries me.
>
Matt also has the same concern. I am pasting my response from my reply
to his comment:
I will make this an instance parameter if the idea to reduce as many
global variables as
>Subject: Re: [ANNOUNCE][PATCH 2.6.11 2/3] megaraid_sas:
>Announcing new module for LSI Logic's SAS based MegaRAID controllers
>
>On Fri, Mar 04, 2005 at 10:06:00PM -0500, Bagalkote, Sreenivas wrote:
>> We are announcing a driver for LSI Logic's new SAS based MegaRAID
>> controllers.
>
>I'd like
Subject: Re: [ANNOUNCE][PATCH 2.6.11 2/3] megaraid_sas:
Announcing new module for LSI Logic's SAS based MegaRAID controllers
On Fri, Mar 04, 2005 at 10:06:00PM -0500, Bagalkote, Sreenivas wrote:
We are announcing a driver for LSI Logic's new SAS based MegaRAID
controllers.
I'd like to start
+static int is_dma64;
the fact that this is a global variable worries me.
Matt also has the same concern. I am pasting my response from my reply
to his comment:
I will make this an instance parameter if the idea to reduce as many
global variables as possible.
28 matches
Mail list logo
