Problem with understanding DMA on some machines (known solution!), specs needed?

Problem with understanding DMA on some machines (known solution!), specs needed?

[Rafał Miłecki]

Hey, I've finally came back to my 14e4:4329 with not working DMA. I
hoped disabling parity will make my DMA work, but this didn't do the
trick.

The card is PCI one with following params:
SSB 2.4
BCM4321
SPROM: 4
PMU: ?
Core rev: 11
PHY: N / 1
Radio: 0x2055 / 4

I've dumped wl and b43 ops and compare them. Noticed something
interesting in DMA setup.

wl:
 read32 0xc0200200 -> 0x00000000
write32 0xc0200200 <- 0x00000801
write32 0xc0200208 <- 0x5f310000
write32 0xc020020c <- 0x00000000

b43:
write32 0xc0200200 <- 0x00000801
write32 0xc0200208 <- 0x198b2000
write32 0xc020020c <- 0x80000000

Can you see the difference? wl does not put routing (translation) bits
in 0x20c@all. 0x208 on the other hand is suspicious.

It looks that wl is:
1) Using 0x40000000 routing instead of 0x80000000 routing
2) wl puts routing bits in addrlo instead of addrhi

According to the specs, routing goes always to the addrhi:

> The address 2 field is as follows (address 1 contains all address bits):
> Mask 	Function
> 0x3FFFFFFF 	Address
> 0xC0000000 	Routing

So I've hacked b43 to use 0x40000000 as translation and to put routing
in addrlo. Wohoo, this helped! For the first time I saw packets using
DMA engine.


Now, the question: when for real we should use such a solution?

Larry, could you check your driver? Can you see anything about this?
Is this maybe PCI (not PCIe!) specific?

-- 
Rafa?

Problem with understanding DMA on some machines (known solution!), specs needed?

[Rafał Miłecki]

W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> Hey, I've finally came back to my 14e4:4329 with not working DMA. I
> hoped disabling parity will make my DMA work, but this didn't do the
> trick.
>
> The card is PCI one with following params:
> SSB 2.4
> BCM4321
> SPROM: 4
> PMU: ?
> Core rev: 11
> PHY: N / 1
> Radio: 0x2055 / 4

Some additional details. This is card taken out from Asus WL-500W and
sent to me by Patryk, some Polish Asus owner.

I've put this in my extremely old Acer based on x86_64 CPU, however
running x86 compiled system.

-- 
Rafa?

Problem with understanding DMA on some machines (known solution!), specs needed?

[Larry Finger]

On 07/25/2011 05:40 PM, Rafa? Mi?ecki wrote:
> W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki<zajec5@gmail.com>  napisa?:
>> Hey, I've finally came back to my 14e4:4329 with not working DMA. I
>> hoped disabling parity will make my DMA work, but this didn't do the
>> trick.
>>
>> The card is PCI one with following params:
>> SSB 2.4
>> BCM4321
>> SPROM: 4
>> PMU: ?
>> Core rev: 11
>> PHY: N / 1
>> Radio: 0x2055 / 4
>
> Some additional details. This is card taken out from Asus WL-500W and
> sent to me by Patryk, some Polish Asus owner.
>
> I've put this in my extremely old Acer based on x86_64 CPU, however
> running x86 compiled system.

The reference driver does what we do. It reads SSB_TMSHIGH to see if 
SSB_TMSHIGH_DMA64 is set. In addition, I do not see any place for a fallback 
mechanism such as we have in b43_dma_set_mask(). That might be a good place to 
put in the quirk for 14e4:4329.

Larry

Problem with understanding DMA on some machines (known solution!), specs needed?

[Larry Finger]

On 07/25/2011 04:54 PM, Rafa? Mi?ecki wrote:
> Hey, I've finally came back to my 14e4:4329 with not working DMA. I
> hoped disabling parity will make my DMA work, but this didn't do the
> trick.
>
> The card is PCI one with following params:
> SSB 2.4
> BCM4321
> SPROM: 4
> PMU: ?
> Core rev: 11
> PHY: N / 1
> Radio: 0x2055 / 4
>
> I've dumped wl and b43 ops and compare them. Noticed something
> interesting in DMA setup.
>
> wl:
>   read32 0xc0200200 ->  0x00000000
> write32 0xc0200200<- 0x00000801
> write32 0xc0200208<- 0x5f310000
> write32 0xc020020c<- 0x00000000
>
> b43:
> write32 0xc0200200<- 0x00000801
> write32 0xc0200208<- 0x198b2000
> write32 0xc020020c<- 0x80000000
>
> Can you see the difference? wl does not put routing (translation) bits
> in 0x20c at all. 0x208 on the other hand is suspicious.
>
> It looks that wl is:
> 1) Using 0x40000000 routing instead of 0x80000000 routing
> 2) wl puts routing bits in addrlo instead of addrhi

Does the card report 32- or 64-bit addressing?
>
> According to the specs, routing goes always to the addrhi:
>
>> The address 2 field is as follows (address 1 contains all address bits):
>> Mask 	Function
>> 0x3FFFFFFF 	Address
>> 0xC0000000 	Routing
>
> So I've hacked b43 to use 0x40000000 as translation and to put routing
> in addrlo. Wohoo, this helped! For the first time I saw packets using
> DMA engine.

What wl is doing is exactly what you would expect for 32-bit DMA. Do a few test 
prints in b43_dma_init() to see what dmamask is on input and what value is returned.

> Now, the question: when for real we should use such a solution?

If we detect the number of DMA bits correctly, all else should be OK. It may be 
that we need a quirk for this card.

> Larry, could you check your driver? Can you see anything about this?
> Is this maybe PCI (not PCIe!) specific?

It could be. I don't recall anything as new as a Rev 11 802.11 core in PCI. I 
looked at it a bit, but I didn't see anything. There is no code that says do 
"this" if the card has a 4329 ID. There are some special 4329 routines, but none 
seem to have anything to do with DMA.

Larry

Problem with understanding DMA on some machines (known solution!), specs needed?

[Rafał Miłecki]

W dniu 26 lipca 2011 02:35 u?ytkownik Larry Finger
<Larry.Finger@lwfinger.net> napisa?:
> On 07/25/2011 04:54 PM, Rafa? Mi?ecki wrote:
>>
>> Hey, I've finally came back to my 14e4:4329 with not working DMA. I
>> hoped disabling parity will make my DMA work, but this didn't do the
>> trick.
>>
>> The card is PCI one with following params:
>> SSB 2.4
>> BCM4321
>> SPROM: 4
>> PMU: ?
>> Core rev: 11
>> PHY: N / 1
>> Radio: 0x2055 / 4
>>
>> I've dumped wl and b43 ops and compare them. Noticed something
>> interesting in DMA setup.
>>
>> wl:
>> ?read32 0xc0200200 -> ?0x00000000
>> write32 0xc0200200<- 0x00000801
>> write32 0xc0200208<- 0x5f310000
>> write32 0xc020020c<- 0x00000000
>>
>> b43:
>> write32 0xc0200200<- 0x00000801
>> write32 0xc0200208<- 0x198b2000
>> write32 0xc020020c<- 0x80000000
>>
>> Can you see the difference? wl does not put routing (translation) bits
>> in 0x20c at all. 0x208 on the other hand is suspicious.
>>
>> It looks that wl is:
>> 1) Using 0x40000000 routing instead of 0x80000000 routing
>> 2) wl puts routing bits in addrlo instead of addrhi
>
> Does the card report 32- or 64-bit addressing?

64-bit:
read32 0xc0200f9c -> 0x100c0000
#define  SSB_TMSHIGH_DMA64	0x10000000 /* 64bit DMA supported */
(and b43 of course correctly displays info about 64-bit DMA)


>> According to the specs, routing goes always to the addrhi:
>>
>>> The address 2 field is as follows (address 1 contains all address bits):
>>> Mask ? ?Function
>>> 0x3FFFFFFF ? ? ?Address
>>> 0xC0000000 ? ? ?Routing
>>
>> So I've hacked b43 to use 0x40000000 as translation and to put routing
>> in addrlo. Wohoo, this helped! For the first time I saw packets using
>> DMA engine.
>
> What wl is doing is exactly what you would expect for 32-bit DMA. Do a few
> test prints in b43_dma_init() to see what dmamask is on input and what value
> is returned.

I don't think so. Below are wl ops with my comments:

write32 0xc0200208<- 0x5f310000
This is clearly some address ORed with 0x40000000. If you assume DMA
is really a 32-bit one, this would mean writing address to 0x208 ==
"Descriptor Stop Index".

write32 0xc020020c<- 0x00000000
In case of 32-bit DMA this would mean writing to "Transmit Status
Word". It sounds more like read-only register.

I think
write32 0xc0200208<- 0x5f310000
write32 0xc020020c<- 0x00000000
is just writing to:
Descriptor Ring Address (Low 32 Bits)
Descriptor Ring Address (High 32 Bits)
(and this is really 64-bit DMA with some additional special-support
for this card / PCI cards).


>> Now, the question: when for real we should use such a solution?
>
> If we detect the number of DMA bits correctly, all else should be OK. It may
> be that we need a quirk for this card.
>
>> Larry, could you check your driver? Can you see anything about this?
>> Is this maybe PCI (not PCIe!) specific?
>
> It could be. I don't recall anything as new as a Rev 11 802.11 core in PCI.
> I looked at it a bit, but I didn't see anything. There is no code that says
> do "this" if the card has a 4329 ID. There are some special 4329 routines,
> but none seem to have anything to do with DMA.

-- 
Rafa?

Problem with understanding DMA on some machines (known solution!), specs needed?

[Rafał Miłecki]

W dniu 26 lipca 2011 09:20 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> W dniu 26 lipca 2011 02:35 u?ytkownik Larry Finger
>> What wl is doing is exactly what you would expect for 32-bit DMA. Do a few
>> test prints in b43_dma_init() to see what dmamask is on input and what value
>> is returned.
>
> I don't think so. Below are wl ops with my comments:
>
> write32 0xc0200208<- 0x5f310000
> This is clearly some address ORed with 0x40000000. If you assume DMA
> is really a 32-bit one, this would mean writing address to 0x208 ==
> "Descriptor Stop Index".
>
> write32 0xc020020c<- 0x00000000
> In case of 32-bit DMA this would mean writing to "Transmit Status
> Word". It sounds more like read-only register.
>
> I think
> write32 0xc0200208<- 0x5f310000
> write32 0xc020020c<- 0x00000000
> is just writing to:
> Descriptor Ring Address (Low 32 Bits)
> Descriptor Ring Address (High 32 Bits)
> (and this is really 64-bit DMA with some additional special-support
> for this card / PCI cards).

OK, additional dumps from wl:

 read32 0xc0200200 -> 0x00000000
write32 0xc0200200 <- 0x00000801
write32 0xc0200208 <- 0x5f310000
write32 0xc020020c <- 0x00000000

 read32 0xc0200240 -> 0x00000000
write32 0xc0200240 <- 0x00000801
write32 0xc0200248 <- 0x5f318000
write32 0xc020024c <- 0x00000000

 read32 0xc0200280 -> 0x00000000
write32 0xc0200280 <- 0x00000801
write32 0xc0200288 <- 0x5f31c000
write32 0xc020028c <- 0x00000000

 read32 0xc02002c0 -> 0x00000000
write32 0xc02002c0 <- 0x00000801
write32 0xc02002c8 <- 0x5cb90000
write32 0xc02002cc <- 0x00000000

 read32 0xc0200220 -> 0x00000040
write32 0xc0200220 <- 0x0000084d
write32 0xc0200228 <- 0x5f314000
write32 0xc020022c <- 0x00000000
write32 0xc0200224 <- 0x00000400

wl enables TX channels on DMA engines: 0x200, 0x240, 0x280, 0x2c0.
Then it enables RX channel on channel 0x200 using 0x20 offset.

I'm 100% sure it's 64-bit DMA.

-- 
Rafa?

Problem with understanding DMA on some machines (known solution!), specs needed?

[Rafał Miłecki]

W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> Now, the question: when for real we should use such a solution?
>
> Larry, could you check your driver? Can you see anything about this?
> Is this maybe PCI (not PCIe!) specific?

I've checked thread "Interesting 14e4:4321". It seems both: 14e4:4321
and 14e4:4322 are using PCI slot and both are not working in DMA mode.
I start believing it's PCI specific.

If you take a look at current ssb code and defines:
> if (ssb_read32(dev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64)
> 	return SSB_PCIE_DMA_H32;
> else
> 	return SSB_PCI_DMA;
You can see 0x80000000 (SSB_PCIE_DMA_H32) has actually "PCIE" in it's
name. This can be true that 0x80000000 is *only* for *64-bit DMA* on
*PCIe*.

-- 
Rafa?

Problem with understanding DMA on some machines (known solution!), specs needed?

[Larry Finger]

On 07/26/2011 03:24 AM, Rafa? Mi?ecki wrote:
> W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki<zajec5@gmail.com>  napisa?:
>> Now, the question: when for real we should use such a solution?
>>
>> Larry, could you check your driver? Can you see anything about this?
>> Is this maybe PCI (not PCIe!) specific?
>
> I've checked thread "Interesting 14e4:4321". It seems both: 14e4:4321
> and 14e4:4322 are using PCI slot and both are not working in DMA mode.
> I start believing it's PCI specific.
>
> If you take a look at current ssb code and defines:
>> if (ssb_read32(dev, SSB_TMSHIGH)&  SSB_TMSHIGH_DMA64)
>> 	return SSB_PCIE_DMA_H32;
>> else
>> 	return SSB_PCI_DMA;
> You can see 0x80000000 (SSB_PCIE_DMA_H32) has actually "PCIE" in it's
> name. This can be true that 0x80000000 is *only* for *64-bit DMA* on
> *PCIe*.

That is almost correct. This time I found it. The pseudo code is:

dma_addr_lo = 0
dma_addr_hi = 0
if PCI || PCIe
	if PCIe && 64-bit DMA
		dma_addr_hi = 0x80000000
	else
		if chipID is 0x4322, 43221, 43231, or 43222
			dma_addr_lo = 0x80000000
		else
			dma_addr_lo = 0x40000000    <== your case

Thus it is just a little more complicated than a PCI/PCIe split, as it also 
depends on the chip ID.

I'll add this to the specs.

Larry

Problem with understanding DMA on some machines (known solution!), specs needed?

[Michael Büsch]

On Tue, 26 Jul 2011 10:33:30 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> On 07/26/2011 03:24 AM, Rafa? Mi?ecki wrote:
> > W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki<zajec5@gmail.com>  napisa?:
> >> Now, the question: when for real we should use such a solution?
> >>
> >> Larry, could you check your driver? Can you see anything about this?
> >> Is this maybe PCI (not PCIe!) specific?
> >
> > I've checked thread "Interesting 14e4:4321". It seems both: 14e4:4321
> > and 14e4:4322 are using PCI slot and both are not working in DMA mode.
> > I start believing it's PCI specific.
> >
> > If you take a look at current ssb code and defines:
> >> if (ssb_read32(dev, SSB_TMSHIGH)&  SSB_TMSHIGH_DMA64)
> >> 	return SSB_PCIE_DMA_H32;
> >> else
> >> 	return SSB_PCI_DMA;
> > You can see 0x80000000 (SSB_PCIE_DMA_H32) has actually "PCIE" in it's
> > name. This can be true that 0x80000000 is *only* for *64-bit DMA* on
> > *PCIe*.
> 
> That is almost correct. This time I found it. The pseudo code is:
> 
> dma_addr_lo = 0
> dma_addr_hi = 0
> if PCI || PCIe
> 	if PCIe && 64-bit DMA
> 		dma_addr_hi = 0x80000000
> 	else
> 		if chipID is 0x4322, 43221, 43231, or 43222
> 			dma_addr_lo = 0x80000000
> 		else
> 			dma_addr_lo = 0x40000000    <== your case

Oh dear. I was already wondering: Man, it can't be _that_ simple to just
look@a bit to determine something as trivial as the routing bits.
I'm glad Broadcom finally managed to fix this, though.

-- 
Greetings, Michael.

Problem with understanding DMA on some machines (known solution!), specs needed?

[Rafał Miłecki]

W dniu 26 lipca 2011 17:49 u?ytkownik Michael B?sch <m@bues.ch> napisa?:
> Oh dear. I was already wondering: Man, it can't be _that_ simple to just
> look at a bit to determine something as trivial as the routing bits.
> I'm glad Broadcom finally managed to fix this, though.

I'm glad you're still watching the list and commenting from time to time :D

Actually, I've already used once your comment when doing presentation
about my MSc work:
"People who worked some time with broadcom stuff will recognize the
pattern: Take old stuff -> redesign it -> put lots of workarounds and
patching layers on top of it to be theoretically compatible with old
code -> fail at being fully compatible -> release it."
;)

-- 
Rafa?

Problem with understanding DMA on some machines (known solution!), specs needed?

[Rafał Miłecki]

W dniu 26 lipca 2011 17:33 u?ytkownik Larry Finger
<Larry.Finger@lwfinger.net> napisa?:
> On 07/26/2011 03:24 AM, Rafa? Mi?ecki wrote:
>>
>> W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki<zajec5@gmail.com>
>> ?napisa?:
>>>
>>> Now, the question: when for real we should use such a solution?
>>>
>>> Larry, could you check your driver? Can you see anything about this?
>>> Is this maybe PCI (not PCIe!) specific?
>>
>> I've checked thread "Interesting 14e4:4321". It seems both: 14e4:4321
>> and 14e4:4322 are using PCI slot and both are not working in DMA mode.
>> I start believing it's PCI specific.
>>
>> If you take a look at current ssb code and defines:
>>>
>>> if (ssb_read32(dev, SSB_TMSHIGH)& ?SSB_TMSHIGH_DMA64)
>>> ? ? ? ?return SSB_PCIE_DMA_H32;
>>> else
>>> ? ? ? ?return SSB_PCI_DMA;
>>
>> You can see 0x80000000 (SSB_PCIE_DMA_H32) has actually "PCIE" in it's
>> name. This can be true that 0x80000000 is *only* for *64-bit DMA* on
>> *PCIe*.
>
> That is almost correct. This time I found it. The pseudo code is:
>
> dma_addr_lo = 0
> dma_addr_hi = 0
> if PCI || PCIe
> ? ? ? ?if PCIe && 64-bit DMA
> ? ? ? ? ? ? ? ?dma_addr_hi = 0x80000000
> ? ? ? ?else
> ? ? ? ? ? ? ? ?if chipID is 0x4322, 43221, 43231, or 43222
> ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_lo = 0x80000000
> ? ? ? ? ? ? ? ?else
> ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_lo = 0x40000000 ? ?<== your case
>
> Thus it is just a little more complicated than a PCI/PCIe split, as it also
> depends on the chip ID.
>
> I'll add this to the specs.

Can you (anyone, not just Larry ;) ) give me some tip, how to
implement this correctly? From programming POV.

We should return two infos from ssb code now:
1) Routing bit
2) Address which should be used

Should I add new function for this? Or create struct
dma_translation_info with 2 fields? Or return array? Or...?

-- 
Rafa?

Problem with understanding DMA on some machines (known solution!), specs needed?

[Larry Finger]

On 07/26/2011 11:32 AM, Rafa? Mi?ecki wrote:
> W dniu 26 lipca 2011 17:33 u?ytkownik Larry Finger
> <Larry.Finger@lwfinger.net>  napisa?:
>> On 07/26/2011 03:24 AM, Rafa? Mi?ecki wrote:
>>>
>>> W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki<zajec5@gmail.com>
>>>   napisa?:
>>>>
>>>> Now, the question: when for real we should use such a solution?
>>>>
>>>> Larry, could you check your driver? Can you see anything about this?
>>>> Is this maybe PCI (not PCIe!) specific?
>>>
>>> I've checked thread "Interesting 14e4:4321". It seems both: 14e4:4321
>>> and 14e4:4322 are using PCI slot and both are not working in DMA mode.
>>> I start believing it's PCI specific.
>>>
>>> If you take a look at current ssb code and defines:
>>>>
>>>> if (ssb_read32(dev, SSB_TMSHIGH)&    SSB_TMSHIGH_DMA64)
>>>>         return SSB_PCIE_DMA_H32;
>>>> else
>>>>         return SSB_PCI_DMA;
>>>
>>> You can see 0x80000000 (SSB_PCIE_DMA_H32) has actually "PCIE" in it's
>>> name. This can be true that 0x80000000 is *only* for *64-bit DMA* on
>>> *PCIe*.
>>
>> That is almost correct. This time I found it. The pseudo code is:
>>
>> dma_addr_lo = 0
>> dma_addr_hi = 0
>> if PCI || PCIe
>>         if PCIe&&  64-bit DMA
>>                 dma_addr_hi = 0x80000000
>>         else
>>                 if chipID is 0x4322, 43221, 43231, or 43222
>>                         dma_addr_lo = 0x80000000
>>                 else
>>                         dma_addr_lo = 0x40000000<== your case
>>
>> Thus it is just a little more complicated than a PCI/PCIe split, as it also
>> depends on the chip ID.
>>
>> I'll add this to the specs.
>
> Can you (anyone, not just Larry ;) ) give me some tip, how to
> implement this correctly? From programming POV.
>
> We should return two infos from ssb code now:
> 1) Routing bit
> 2) Address which should be used
>
> Should I add new function for this? Or create struct
> dma_translation_info with 2 fields? Or return array? Or...?

How about more pseudo code? Broadcom sets those dma_addr_hi/lo words in a struct 
when they are setting up the TX/RX rings. Then they do the following when 
actually setting up the 64-bit DMA operation:

dmaaddr_t phys

if !dma_addr_lo || !(phys.loaddr & 0xc0000000)
	ring.address_lo = phys.loaddr + dma_addr_lo
	ring.address_hi = phys.hiaddr + dma_addr_hi
	ring.ctrl1 = ...
else
	u32 addr_ext = phys.loaddr & 0xc0000000
	phys.loaddr &= ~0xc0000000
	ring.address_lo = phys.loaddr + dma_addr_lo
	ring.address_hi = dma_addr_hi
	ring.ctrl1 = ....

On second thought, what I call dma_addr_{lo,hi} might be called 
dma_offset_{lo,hi}, or even dma_mask_{lo,hi}.

As to the programming question, setting up these offsets can easily be done the 
way they do.

Larry

	

Problem with understanding DMA on some machines (known solution!), specs needed?

[Michael Büsch]

On Tue, 26 Jul 2011 18:32:15 +0200
Rafa? Mi?ecki <zajec5@gmail.com> wrote:

> W dniu 26 lipca 2011 17:33 u?ytkownik Larry Finger
> <Larry.Finger@lwfinger.net> napisa?:
> > On 07/26/2011 03:24 AM, Rafa? Mi?ecki wrote:
> >>
> >> W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki<zajec5@gmail.com>
> >> ?napisa?:
> >>>
> >>> Now, the question: when for real we should use such a solution?
> >>>
> >>> Larry, could you check your driver? Can you see anything about this?
> >>> Is this maybe PCI (not PCIe!) specific?
> >>
> >> I've checked thread "Interesting 14e4:4321". It seems both: 14e4:4321
> >> and 14e4:4322 are using PCI slot and both are not working in DMA mode.
> >> I start believing it's PCI specific.
> >>
> >> If you take a look at current ssb code and defines:
> >>>
> >>> if (ssb_read32(dev, SSB_TMSHIGH)& ?SSB_TMSHIGH_DMA64)
> >>> ? ? ? ?return SSB_PCIE_DMA_H32;
> >>> else
> >>> ? ? ? ?return SSB_PCI_DMA;
> >>
> >> You can see 0x80000000 (SSB_PCIE_DMA_H32) has actually "PCIE" in it's
> >> name. This can be true that 0x80000000 is *only* for *64-bit DMA* on
> >> *PCIe*.
> >
> > That is almost correct. This time I found it. The pseudo code is:
> >
> > dma_addr_lo = 0
> > dma_addr_hi = 0
> > if PCI || PCIe
> > ? ? ? ?if PCIe && 64-bit DMA
> > ? ? ? ? ? ? ? ?dma_addr_hi = 0x80000000
> > ? ? ? ?else
> > ? ? ? ? ? ? ? ?if chipID is 0x4322, 43221, 43231, or 43222
> > ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_lo = 0x80000000
> > ? ? ? ? ? ? ? ?else
> > ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_lo = 0x40000000 ? ?<== your case
> >
> > Thus it is just a little more complicated than a PCI/PCIe split, as it also
> > depends on the chip ID.
> >
> > I'll add this to the specs.
> 
> Can you (anyone, not just Larry ;) ) give me some tip, how to
> implement this correctly? From programming POV.
> 
> We should return two infos from ssb code now:
> 1) Routing bit
> 2) Address which should be used
> 
> Should I add new function for this? Or create struct
> dma_translation_info with 2 fields? Or return array? Or...?

I would do it something like this (completely untested. Not even compiled):


Index: wireless-testing/drivers/ssb/main.c
===================================================================
--- wireless-testing.orig/drivers/ssb/main.c	2011-07-21 23:20:56.000000000 +0200
+++ wireless-testing/drivers/ssb/main.c	2011-07-26 20:50:31.920182657 +0200
@@ -1260,16 +1260,32 @@ void ssb_device_disable(struct ssb_devic
 }
 EXPORT_SYMBOL(ssb_device_disable);
 
+static bool let_the_software_guys_fix_it(struct ssb_device *dev)
+{
+	u16 chip_id = dev->bus->chip_id;
+
+	if (dev->id.coreid == SSB_DEV_80211) {
+		return (chip_id == 0x4322 || chip_id == 43221 ||
+			chip_id == 43231 || chip_id == 43222)
+	}
+	return 0;
+}
+
 u32 ssb_dma_translation(struct ssb_device *dev)
 {
 	switch (dev->bus->bustype) {
 	case SSB_BUSTYPE_SSB:
 		return 0;
 	case SSB_BUSTYPE_PCI:
-		if (ssb_read32(dev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64)
+		if (dev->bus->host_pci->is_pcie &&
+		    (ssb_read32(dev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64)) {
 			return SSB_PCIE_DMA_H32;
-		else
-			return SSB_PCI_DMA;
+		} else {
+			if (let_the_software_guys_fix_it(dev))
+				return SSB_PCIE_DMA_H32;
+			else
+				return SSB_PCI_DMA;
+		}
 	default:
 		__ssb_dma_not_implemented(dev);
 	}
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c	2011-07-21 23:20:55.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/dma.c	2011-07-26 20:53:40.688974405 +0200
@@ -1052,6 +1052,21 @@ static int b43_dma_set_mask(struct b43_w
 	return 0;
 }
 
+static bool dma_translation_in_low_word(struct b43_wldev *dev)
+{
+#ifdef CONFIG_B43_SSB
+	if (dev->dev->bus_type != B43_BUS_SSB)
+		return 0;
+	if (dev->dev->sdev->bus->bustype == SSB_BUSTYPE_PCI) {
+		if (dev->dev->sdev->bus->host_pci->is_pcie &&
+		    (ssb_read32(dev->dev->sdev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64))
+			return 0;
+		return 1;
+	}
+#endif
+	return 0;
+}
+
 int b43_dma_init(struct b43_wldev *dev)
 {
 	struct b43_dma *dma = &dev->dma;
@@ -1074,6 +1089,7 @@ int b43_dma_init(struct b43_wldev *dev)
 #ifdef CONFIG_B43_SSB
 	case B43_BUS_SSB:
 		dma->translation = ssb_dma_translation(dev->dev->sdev);
+		//Hurr durr use dma_translation_in_low_word()
 		break;
 #endif
 	}

-- 
Greetings, Michael.

Problem with understanding DMA on some machines (known solution!), specs needed?

[Michael Büsch]

On Tue, 26 Jul 2011 20:55:31 +0200
Michael B?sch <m@bues.ch> wrote:

> On Tue, 26 Jul 2011 18:32:15 +0200
> Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> 
> > W dniu 26 lipca 2011 17:33 u?ytkownik Larry Finger
> > <Larry.Finger@lwfinger.net> napisa?:
> > > On 07/26/2011 03:24 AM, Rafa? Mi?ecki wrote:
> > >>
> > >> W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki<zajec5@gmail.com>
> > >> ?napisa?:
> > >>>
> > >>> Now, the question: when for real we should use such a solution?
> > >>>
> > >>> Larry, could you check your driver? Can you see anything about this?
> > >>> Is this maybe PCI (not PCIe!) specific?
> > >>
> > >> I've checked thread "Interesting 14e4:4321". It seems both: 14e4:4321
> > >> and 14e4:4322 are using PCI slot and both are not working in DMA mode.
> > >> I start believing it's PCI specific.
> > >>
> > >> If you take a look at current ssb code and defines:
> > >>>
> > >>> if (ssb_read32(dev, SSB_TMSHIGH)& ?SSB_TMSHIGH_DMA64)
> > >>> ? ? ? ?return SSB_PCIE_DMA_H32;
> > >>> else
> > >>> ? ? ? ?return SSB_PCI_DMA;
> > >>
> > >> You can see 0x80000000 (SSB_PCIE_DMA_H32) has actually "PCIE" in it's
> > >> name. This can be true that 0x80000000 is *only* for *64-bit DMA* on
> > >> *PCIe*.
> > >
> > > That is almost correct. This time I found it. The pseudo code is:
> > >
> > > dma_addr_lo = 0
> > > dma_addr_hi = 0
> > > if PCI || PCIe
> > > ? ? ? ?if PCIe && 64-bit DMA
> > > ? ? ? ? ? ? ? ?dma_addr_hi = 0x80000000
> > > ? ? ? ?else
> > > ? ? ? ? ? ? ? ?if chipID is 0x4322, 43221, 43231, or 43222
> > > ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_lo = 0x80000000
> > > ? ? ? ? ? ? ? ?else
> > > ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_lo = 0x40000000 ? ?<== your case
> > >
> > > Thus it is just a little more complicated than a PCI/PCIe split, as it also
> > > depends on the chip ID.
> > >
> > > I'll add this to the specs.
> > 
> > Can you (anyone, not just Larry ;) ) give me some tip, how to
> > implement this correctly? From programming POV.
> > 
> > We should return two infos from ssb code now:
> > 1) Routing bit
> > 2) Address which should be used
> > 
> > Should I add new function for this? Or create struct
> > dma_translation_info with 2 fields? Or return array? Or...?
> 
> I would do it something like this (completely untested. Not even compiled):
> 
> 
> Index: wireless-testing/drivers/ssb/main.c
> ===================================================================
> --- wireless-testing.orig/drivers/ssb/main.c	2011-07-21 23:20:56.000000000 +0200
> +++ wireless-testing/drivers/ssb/main.c	2011-07-26 20:50:31.920182657 +0200
> @@ -1260,16 +1260,32 @@ void ssb_device_disable(struct ssb_devic
>  }
>  EXPORT_SYMBOL(ssb_device_disable);
>  
> +static bool let_the_software_guys_fix_it(struct ssb_device *dev)
> +{
> +	u16 chip_id = dev->bus->chip_id;
> +
> +	if (dev->id.coreid == SSB_DEV_80211) {
> +		return (chip_id == 0x4322 || chip_id == 43221 ||
> +			chip_id == 43231 || chip_id == 43222)
> +	}
> +	return 0;
> +}
> +
>  u32 ssb_dma_translation(struct ssb_device *dev)
>  {
>  	switch (dev->bus->bustype) {
>  	case SSB_BUSTYPE_SSB:
>  		return 0;
>  	case SSB_BUSTYPE_PCI:
> -		if (ssb_read32(dev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64)
> +		if (dev->bus->host_pci->is_pcie &&
> +		    (ssb_read32(dev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64)) {
>  			return SSB_PCIE_DMA_H32;
> -		else
> -			return SSB_PCI_DMA;
> +		} else {
> +			if (let_the_software_guys_fix_it(dev))
> +				return SSB_PCIE_DMA_H32;
> +			else
> +				return SSB_PCI_DMA;
> +		}
>  	default:
>  		__ssb_dma_not_implemented(dev);
>  	}
> Index: wireless-testing/drivers/net/wireless/b43/dma.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/b43/dma.c	2011-07-21 23:20:55.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/b43/dma.c	2011-07-26 20:53:40.688974405 +0200
> @@ -1052,6 +1052,21 @@ static int b43_dma_set_mask(struct b43_w
>  	return 0;
>  }
>  
> +static bool dma_translation_in_low_word(struct b43_wldev *dev)
> +{
> +#ifdef CONFIG_B43_SSB
> +	if (dev->dev->bus_type != B43_BUS_SSB)
> +		return 0;
> +	if (dev->dev->sdev->bus->bustype == SSB_BUSTYPE_PCI) {
> +		if (dev->dev->sdev->bus->host_pci->is_pcie &&
> +		    (ssb_read32(dev->dev->sdev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64))
> +			return 0;
> +		return 1;
> +	}
> +#endif
> +	return 0;
> +}
> +
>  int b43_dma_init(struct b43_wldev *dev)
>  {
>  	struct b43_dma *dma = &dev->dma;
> @@ -1074,6 +1089,7 @@ int b43_dma_init(struct b43_wldev *dev)
>  #ifdef CONFIG_B43_SSB
>  	case B43_BUS_SSB:
>  		dma->translation = ssb_dma_translation(dev->dev->sdev);
> +		//Hurr durr use dma_translation_in_low_word()
>  		break;
>  #endif
>  	}
> 

Does that sound sane? Any comments on this?

-- 
Greetings, Michael.

Problem with understanding DMA on some machines (known solution!), specs needed?

[Rafał Miłecki]

W dniu 30 lipca 2011 18:44 u?ytkownik Michael B?sch <m@bues.ch> napisa?:
> On Tue, 26 Jul 2011 20:55:31 +0200
> Michael B?sch <m@bues.ch> wrote:
>
>> On Tue, 26 Jul 2011 18:32:15 +0200
>> Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>>
>> > W dniu 26 lipca 2011 17:33 u?ytkownik Larry Finger
>> > <Larry.Finger@lwfinger.net> napisa?:
>> > > On 07/26/2011 03:24 AM, Rafa? Mi?ecki wrote:
>> > >>
>> > >> W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki<zajec5@gmail.com>
>> > >> ?napisa?:
>> > >>>
>> > >>> Now, the question: when for real we should use such a solution?
>> > >>>
>> > >>> Larry, could you check your driver? Can you see anything about this?
>> > >>> Is this maybe PCI (not PCIe!) specific?
>> > >>
>> > >> I've checked thread "Interesting 14e4:4321". It seems both: 14e4:4321
>> > >> and 14e4:4322 are using PCI slot and both are not working in DMA mode.
>> > >> I start believing it's PCI specific.
>> > >>
>> > >> If you take a look at current ssb code and defines:
>> > >>>
>> > >>> if (ssb_read32(dev, SSB_TMSHIGH)& ?SSB_TMSHIGH_DMA64)
>> > >>> ? ? ? ?return SSB_PCIE_DMA_H32;
>> > >>> else
>> > >>> ? ? ? ?return SSB_PCI_DMA;
>> > >>
>> > >> You can see 0x80000000 (SSB_PCIE_DMA_H32) has actually "PCIE" in it's
>> > >> name. This can be true that 0x80000000 is *only* for *64-bit DMA* on
>> > >> *PCIe*.
>> > >
>> > > That is almost correct. This time I found it. The pseudo code is:
>> > >
>> > > dma_addr_lo = 0
>> > > dma_addr_hi = 0
>> > > if PCI || PCIe
>> > > ? ? ? ?if PCIe && 64-bit DMA
>> > > ? ? ? ? ? ? ? ?dma_addr_hi = 0x80000000
>> > > ? ? ? ?else
>> > > ? ? ? ? ? ? ? ?if chipID is 0x4322, 43221, 43231, or 43222
>> > > ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_lo = 0x80000000
>> > > ? ? ? ? ? ? ? ?else
>> > > ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_lo = 0x40000000 ? ?<== your case
>> > >
>> > > Thus it is just a little more complicated than a PCI/PCIe split, as it also
>> > > depends on the chip ID.
>> > >
>> > > I'll add this to the specs.
>> >
>> > Can you (anyone, not just Larry ;) ) give me some tip, how to
>> > implement this correctly? From programming POV.
>> >
>> > We should return two infos from ssb code now:
>> > 1) Routing bit
>> > 2) Address which should be used
>> >
>> > Should I add new function for this? Or create struct
>> > dma_translation_info with 2 fields? Or return array? Or...?
>>
>> I would do it something like this (completely untested. Not even compiled):
>>
>>
>> Index: wireless-testing/drivers/ssb/main.c
>> ===================================================================
>> --- wireless-testing.orig/drivers/ssb/main.c ?2011-07-21 23:20:56.000000000 +0200
>> +++ wireless-testing/drivers/ssb/main.c ? ? ? 2011-07-26 20:50:31.920182657 +0200
>> @@ -1260,16 +1260,32 @@ void ssb_device_disable(struct ssb_devic
>> ?}
>> ?EXPORT_SYMBOL(ssb_device_disable);
>>
>> +static bool let_the_software_guys_fix_it(struct ssb_device *dev)
>> +{
>> + ? ? u16 chip_id = dev->bus->chip_id;
>> +
>> + ? ? if (dev->id.coreid == SSB_DEV_80211) {
>> + ? ? ? ? ? ? return (chip_id == 0x4322 || chip_id == 43221 ||
>> + ? ? ? ? ? ? ? ? ? ? chip_id == 43231 || chip_id == 43222)
>> + ? ? }
>> + ? ? return 0;
>> +}
>> +
>> ?u32 ssb_dma_translation(struct ssb_device *dev)
>> ?{
>> ? ? ? switch (dev->bus->bustype) {
>> ? ? ? case SSB_BUSTYPE_SSB:
>> ? ? ? ? ? ? ? return 0;
>> ? ? ? case SSB_BUSTYPE_PCI:
>> - ? ? ? ? ? ? if (ssb_read32(dev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64)
>> + ? ? ? ? ? ? if (dev->bus->host_pci->is_pcie &&
>> + ? ? ? ? ? ? ? ? (ssb_read32(dev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64)) {
>> ? ? ? ? ? ? ? ? ? ? ? return SSB_PCIE_DMA_H32;
>> - ? ? ? ? ? ? else
>> - ? ? ? ? ? ? ? ? ? ? return SSB_PCI_DMA;
>> + ? ? ? ? ? ? } else {
>> + ? ? ? ? ? ? ? ? ? ? if (let_the_software_guys_fix_it(dev))
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? return SSB_PCIE_DMA_H32;
>> + ? ? ? ? ? ? ? ? ? ? else
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? return SSB_PCI_DMA;
>> + ? ? ? ? ? ? }
>> ? ? ? default:
>> ? ? ? ? ? ? ? __ssb_dma_not_implemented(dev);
>> ? ? ? }
>> Index: wireless-testing/drivers/net/wireless/b43/dma.c
>> ===================================================================
>> --- wireless-testing.orig/drivers/net/wireless/b43/dma.c ? ? ?2011-07-21 23:20:55.000000000 +0200
>> +++ wireless-testing/drivers/net/wireless/b43/dma.c ? 2011-07-26 20:53:40.688974405 +0200
>> @@ -1052,6 +1052,21 @@ static int b43_dma_set_mask(struct b43_w
>> ? ? ? return 0;
>> ?}
>>
>> +static bool dma_translation_in_low_word(struct b43_wldev *dev)
>> +{
>> +#ifdef CONFIG_B43_SSB
>> + ? ? if (dev->dev->bus_type != B43_BUS_SSB)
>> + ? ? ? ? ? ? return 0;
>> + ? ? if (dev->dev->sdev->bus->bustype == SSB_BUSTYPE_PCI) {
>> + ? ? ? ? ? ? if (dev->dev->sdev->bus->host_pci->is_pcie &&
>> + ? ? ? ? ? ? ? ? (ssb_read32(dev->dev->sdev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64))
>> + ? ? ? ? ? ? ? ? ? ? return 0;
>> + ? ? ? ? ? ? return 1;
>> + ? ? }
>> +#endif
>> + ? ? return 0;
>> +}
>> +
>> ?int b43_dma_init(struct b43_wldev *dev)
>> ?{
>> ? ? ? struct b43_dma *dma = &dev->dma;
>> @@ -1074,6 +1089,7 @@ int b43_dma_init(struct b43_wldev *dev)
>> ?#ifdef CONFIG_B43_SSB
>> ? ? ? case B43_BUS_SSB:
>> ? ? ? ? ? ? ? dma->translation = ssb_dma_translation(dev->dev->sdev);
>> + ? ? ? ? ? ? //Hurr durr use dma_translation_in_low_word()
>> ? ? ? ? ? ? ? break;
>> ?#endif
>> ? ? ? }
>>
>
> Does that sound sane? Any comments on this?

Sorry, I'm on half-vacations now, being on-line from time to time only.

Michael: I'm OK with your idea of additional function
(dma_translation_in_low_word), but I wonder if it should go to ssb.
What do you think about this? In theory this sounds like something bus
specific to me and in theory could be used by other drivers as well.
Routing seems to be bus (ssb) specific.

-- 
Rafa?

Problem with understanding DMA on some machines (known solution!), specs needed?

[Michael Büsch]

On Sun, 31 Jul 2011 01:48:06 +0200
Rafa? Mi?ecki <zajec5@gmail.com> wrote:

> W dniu 30 lipca 2011 18:44 u?ytkownik Michael B?sch <m@bues.ch> napisa?:
> > On Tue, 26 Jul 2011 20:55:31 +0200
> > Michael B?sch <m@bues.ch> wrote:
> >
> >> On Tue, 26 Jul 2011 18:32:15 +0200
> >> Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> >>
> >> > W dniu 26 lipca 2011 17:33 u?ytkownik Larry Finger
> >> > <Larry.Finger@lwfinger.net> napisa?:
> >> > > On 07/26/2011 03:24 AM, Rafa? Mi?ecki wrote:
> >> > >>
> >> > >> W dniu 25 lipca 2011 23:54 u?ytkownik Rafa? Mi?ecki<zajec5@gmail.com>
> >> > >> ?napisa?:
> >> > >>>
> >> > >>> Now, the question: when for real we should use such a solution?
> >> > >>>
> >> > >>> Larry, could you check your driver? Can you see anything about this?
> >> > >>> Is this maybe PCI (not PCIe!) specific?
> >> > >>
> >> > >> I've checked thread "Interesting 14e4:4321". It seems both: 14e4:4321
> >> > >> and 14e4:4322 are using PCI slot and both are not working in DMA mode.
> >> > >> I start believing it's PCI specific.
> >> > >>
> >> > >> If you take a look at current ssb code and defines:
> >> > >>>
> >> > >>> if (ssb_read32(dev, SSB_TMSHIGH)& ?SSB_TMSHIGH_DMA64)
> >> > >>> ? ? ? ?return SSB_PCIE_DMA_H32;
> >> > >>> else
> >> > >>> ? ? ? ?return SSB_PCI_DMA;
> >> > >>
> >> > >> You can see 0x80000000 (SSB_PCIE_DMA_H32) has actually "PCIE" in it's
> >> > >> name. This can be true that 0x80000000 is *only* for *64-bit DMA* on
> >> > >> *PCIe*.
> >> > >
> >> > > That is almost correct. This time I found it. The pseudo code is:
> >> > >
> >> > > dma_addr_lo = 0
> >> > > dma_addr_hi = 0
> >> > > if PCI || PCIe
> >> > > ? ? ? ?if PCIe && 64-bit DMA
> >> > > ? ? ? ? ? ? ? ?dma_addr_hi = 0x80000000
> >> > > ? ? ? ?else
> >> > > ? ? ? ? ? ? ? ?if chipID is 0x4322, 43221, 43231, or 43222
> >> > > ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_lo = 0x80000000
> >> > > ? ? ? ? ? ? ? ?else
> >> > > ? ? ? ? ? ? ? ? ? ? ? ?dma_addr_lo = 0x40000000 ? ?<== your case
> >> > >
> >> > > Thus it is just a little more complicated than a PCI/PCIe split, as it also
> >> > > depends on the chip ID.
> >> > >
> >> > > I'll add this to the specs.
> >> >
> >> > Can you (anyone, not just Larry ;) ) give me some tip, how to
> >> > implement this correctly? From programming POV.
> >> >
> >> > We should return two infos from ssb code now:
> >> > 1) Routing bit
> >> > 2) Address which should be used
> >> >
> >> > Should I add new function for this? Or create struct
> >> > dma_translation_info with 2 fields? Or return array? Or...?
> >>
> >> I would do it something like this (completely untested. Not even compiled):
> >>
> >>
> >> Index: wireless-testing/drivers/ssb/main.c
> >> ===================================================================
> >> --- wireless-testing.orig/drivers/ssb/main.c ?2011-07-21 23:20:56.000000000 +0200
> >> +++ wireless-testing/drivers/ssb/main.c ? ? ? 2011-07-26 20:50:31.920182657 +0200
> >> @@ -1260,16 +1260,32 @@ void ssb_device_disable(struct ssb_devic
> >> ?}
> >> ?EXPORT_SYMBOL(ssb_device_disable);
> >>
> >> +static bool let_the_software_guys_fix_it(struct ssb_device *dev)
> >> +{
> >> + ? ? u16 chip_id = dev->bus->chip_id;
> >> +
> >> + ? ? if (dev->id.coreid == SSB_DEV_80211) {
> >> + ? ? ? ? ? ? return (chip_id == 0x4322 || chip_id == 43221 ||
> >> + ? ? ? ? ? ? ? ? ? ? chip_id == 43231 || chip_id == 43222)
> >> + ? ? }
> >> + ? ? return 0;
> >> +}
> >> +
> >> ?u32 ssb_dma_translation(struct ssb_device *dev)
> >> ?{
> >> ? ? ? switch (dev->bus->bustype) {
> >> ? ? ? case SSB_BUSTYPE_SSB:
> >> ? ? ? ? ? ? ? return 0;
> >> ? ? ? case SSB_BUSTYPE_PCI:
> >> - ? ? ? ? ? ? if (ssb_read32(dev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64)
> >> + ? ? ? ? ? ? if (dev->bus->host_pci->is_pcie &&
> >> + ? ? ? ? ? ? ? ? (ssb_read32(dev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64)) {
> >> ? ? ? ? ? ? ? ? ? ? ? return SSB_PCIE_DMA_H32;
> >> - ? ? ? ? ? ? else
> >> - ? ? ? ? ? ? ? ? ? ? return SSB_PCI_DMA;
> >> + ? ? ? ? ? ? } else {
> >> + ? ? ? ? ? ? ? ? ? ? if (let_the_software_guys_fix_it(dev))
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? return SSB_PCIE_DMA_H32;
> >> + ? ? ? ? ? ? ? ? ? ? else
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? return SSB_PCI_DMA;
> >> + ? ? ? ? ? ? }
> >> ? ? ? default:
> >> ? ? ? ? ? ? ? __ssb_dma_not_implemented(dev);
> >> ? ? ? }
> >> Index: wireless-testing/drivers/net/wireless/b43/dma.c
> >> ===================================================================
> >> --- wireless-testing.orig/drivers/net/wireless/b43/dma.c ? ? ?2011-07-21 23:20:55.000000000 +0200
> >> +++ wireless-testing/drivers/net/wireless/b43/dma.c ? 2011-07-26 20:53:40.688974405 +0200
> >> @@ -1052,6 +1052,21 @@ static int b43_dma_set_mask(struct b43_w
> >> ? ? ? return 0;
> >> ?}
> >>
> >> +static bool dma_translation_in_low_word(struct b43_wldev *dev)
> >> +{
> >> +#ifdef CONFIG_B43_SSB
> >> + ? ? if (dev->dev->bus_type != B43_BUS_SSB)
> >> + ? ? ? ? ? ? return 0;
> >> + ? ? if (dev->dev->sdev->bus->bustype == SSB_BUSTYPE_PCI) {
> >> + ? ? ? ? ? ? if (dev->dev->sdev->bus->host_pci->is_pcie &&
> >> + ? ? ? ? ? ? ? ? (ssb_read32(dev->dev->sdev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64))
> >> + ? ? ? ? ? ? ? ? ? ? return 0;
> >> + ? ? ? ? ? ? return 1;
> >> + ? ? }
> >> +#endif
> >> + ? ? return 0;
> >> +}
> >> +
> >> ?int b43_dma_init(struct b43_wldev *dev)
> >> ?{
> >> ? ? ? struct b43_dma *dma = &dev->dma;
> >> @@ -1074,6 +1089,7 @@ int b43_dma_init(struct b43_wldev *dev)
> >> ?#ifdef CONFIG_B43_SSB
> >> ? ? ? case B43_BUS_SSB:
> >> ? ? ? ? ? ? ? dma->translation = ssb_dma_translation(dev->dev->sdev);
> >> + ? ? ? ? ? ? //Hurr durr use dma_translation_in_low_word()
> >> ? ? ? ? ? ? ? break;
> >> ?#endif
> >> ? ? ? }
> >>
> >
> > Does that sound sane? Any comments on this?
> 
> Sorry, I'm on half-vacations now, being on-line from time to time only.
> 
> Michael: I'm OK with your idea of additional function
> (dma_translation_in_low_word), but I wonder if it should go to ssb.
> What do you think about this? In theory this sounds like something bus
> specific to me and in theory could be used by other drivers as well.
> Routing seems to be bus (ssb) specific.

I would guess that this is a bug in the DMA engine.
Putting routing into the lower 32bits of the address doesn't really make
any sense at all, unless it's a hardware bug that looks at the wrong register
for getting the bits.
I don't think it's really worth to add a new SSB API function here.

-- 
Greetings, Michael.