[PATCH] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13

[PATCH] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13

[Larry Finger]

The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
has not been supported until now. The changes include the following:

(1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43=
=2E
(2) Add PHY revision 9 to the supported list.
(3) Fix 64-bit addressing errors.
(4) Remove some magic numbers in the DMA setup.

The DMA implementation for this chip supports full 64-bit addressing wi=
th
one exception. Whenever the Descriptor Ring Buffer is in high memory, a
fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
to code to "Bias the placement of kernel pages at lower PFNs". When
commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At pres=
ent,
this problem is thought to arise from a hardware error. The present dri=
ver
allocates one ring buffer for RX and six for TX; however, only one of t=
he
TX buffers is used. To minimize any system impact associated with using=
 low
memory, this patch removes the allocation of the unused buffers.

This patch has been tested by C=C3=A9dric Caumont <icare40@hotmail.com>=
=2E

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---

John,

This patch is intended for the everything branch of wireless-2.6.

Larry
---

 dma.c  |   86 ++++++++++++++++++++++++++++++++++----------------------=
---------
 main.c |    3 +-
 wa.c   |    1
 3 files changed, 49 insertions(+), 41 deletions(-)

Index: wireless-2.6/drivers/net/wireless/b43/dma.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- wireless-2.6.orig/drivers/net/wireless/b43/dma.c
+++ wireless-2.6/drivers/net/wireless/b43/dma.c
@@ -165,7 +165,7 @@ static void op64_fill_descriptor(struct=20
 	addrhi =3D (((u64) dmaaddr >> 32) & ~SSB_DMA_TRANSLATION_MASK);
 	addrext =3D (((u64) dmaaddr >> 32) & SSB_DMA_TRANSLATION_MASK)
 	    >> SSB_DMA_TRANSLATION_SHIFT;
-	addrhi |=3D ssb_dma_translation(ring->dev->dev);
+	addrhi |=3D (ssb_dma_translation(ring->dev->dev) << 1);
 	if (slot =3D=3D ring->nr_slots - 1)
 		ctl0 |=3D B43_DMA64_DCTL0_DTABLEEND;
 	if (start)
@@ -426,9 +426,20 @@ static inline
 static int alloc_ringmemory(struct b43_dmaring *ring)
 {
 	struct device *dev =3D ring->dev->dev->dev;
+	gfp_t flags =3D GFP_KERNEL;
=20
+	/* The specs call for 4K buffers for 30- and 32-bit DMA
+	 * and 8K buffers for 64-bit DMA; however, 4K is sufficient for
+	 * the latter as long as the buffer does not cross an 8K boundary.
+	 *
+	 * For unknown reasons - possibly a hardware error - the BCM4311 rev
+	 * 02, which uses 64-bit DMA, needs the ring buffer in very low memor=
y,
+	 * which accounts for the GFP_DMA flag below.
+	 */
+	if (ring->dma64)
+		flags =3D GFP_DMA;
 	ring->descbase =3D dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
-					    &(ring->dmabase), GFP_KERNEL);
+					    &(ring->dmabase), flags);
 	if (!ring->descbase) {
 		b43err(ring->dev->wl, "DMA ringmemory allocation failed\n");
 		return -ENOMEM;
@@ -483,7 +494,7 @@ int b43_dmacontroller_rx_reset(struct b4
 	return 0;
 }
=20
-/* Reset the RX DMA channel */
+/* Reset the TX DMA channel */
 int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, i=
nt dma64)
 {
 	int i;
@@ -636,18 +647,12 @@ static int dmacontroller_setup(struct b4
 		if (ring->dma64) {
 			u64 ringbase =3D (u64) (ring->dmabase);
=20
-			addrext =3D ((ringbase >> 32) & SSB_DMA_TRANSLATION_MASK)
-			    >> SSB_DMA_TRANSLATION_SHIFT;
-			value =3D B43_DMA64_TXENABLE;
-			value |=3D (addrext << B43_DMA64_TXADDREXT_SHIFT)
-			    & B43_DMA64_TXADDREXT_MASK;
-			b43_dma_write(ring, B43_DMA64_TXCTL, value);
+			b43_dma_write(ring, B43_DMA64_TXCTL,
+				      B43_DMA64_TXENABLE);
 			b43_dma_write(ring, B43_DMA64_TXRINGLO,
 				      (ringbase & 0xFFFFFFFF));
 			b43_dma_write(ring, B43_DMA64_TXRINGHI,
-				      ((ringbase >> 32) &
-				       ~SSB_DMA_TRANSLATION_MASK)
-				      | trans);
+				      (ringbase >> 32));
 		} else {
 			u32 ringbase =3D (u32) (ring->dmabase);
=20
@@ -668,20 +673,15 @@ static int dmacontroller_setup(struct b4
 		if (ring->dma64) {
 			u64 ringbase =3D (u64) (ring->dmabase);
=20
-			addrext =3D ((ringbase >> 32) & SSB_DMA_TRANSLATION_MASK)
-			    >> SSB_DMA_TRANSLATION_SHIFT;
-			value =3D (ring->frameoffset << B43_DMA64_RXFROFF_SHIFT);
-			value |=3D B43_DMA64_RXENABLE;
-			value |=3D (addrext << B43_DMA64_RXADDREXT_SHIFT)
-			    & B43_DMA64_RXADDREXT_MASK;
+			value =3D (ring->frameoffset << B43_DMA64_RXFROFF_SHIFT)
+				| B43_DMA64_RXENABLE;
 			b43_dma_write(ring, B43_DMA64_RXCTL, value);
 			b43_dma_write(ring, B43_DMA64_RXRINGLO,
 				      (ringbase & 0xFFFFFFFF));
 			b43_dma_write(ring, B43_DMA64_RXRINGHI,
-				      ((ringbase >> 32) &
-				       ~SSB_DMA_TRANSLATION_MASK)
-				      | trans);
-			b43_dma_write(ring, B43_DMA64_RXINDEX, 200);
+				      (ringbase >> 32));
+			b43_dma_write(ring, B43_DMA64_RXINDEX, ring->nr_slots *
+				      sizeof(struct b43_dmadesc64));
 		} else {
 			u32 ringbase =3D (u32) (ring->dmabase);
=20
@@ -695,11 +695,12 @@ static int dmacontroller_setup(struct b4
 			b43_dma_write(ring, B43_DMA32_RXRING,
 				      (ringbase & ~SSB_DMA_TRANSLATION_MASK)
 				      | trans);
-			b43_dma_write(ring, B43_DMA32_RXINDEX, 200);
+			b43_dma_write(ring, B43_DMA32_RXINDEX, ring->nr_slots *
+				      sizeof(struct b43_dmadesc32));
 		}
 	}
=20
-      out:
+out:
 	return err;
 }
=20
@@ -954,19 +955,21 @@ int b43_dma_init(struct b43_wldev *dev)
=20
 	err =3D -ENOMEM;
 	/* setup TX DMA channels. */
-	ring =3D b43_setup_dmaring(dev, 0, 1, dma64);
+	ring =3D b43_setup_dmaring(dev, 1, 1, dma64);
 	if (!ring)
 		goto out;
-	dma->tx_ring0 =3D ring;
+	dma->tx_ring1 =3D ring;
=20
-	ring =3D b43_setup_dmaring(dev, 1, 1, dma64);
+	/* The driver only uses ring1 for TX - skip setup for the rest */
+#if 0
+	ring =3D b43_setup_dmaring(dev, 0, 1, dma64);
 	if (!ring)
-		goto err_destroy_tx0;
-	dma->tx_ring1 =3D ring;
+		goto err_destroy_tx1;
+	dma->tx_ring0 =3D ring;
=20
 	ring =3D b43_setup_dmaring(dev, 2, 1, dma64);
 	if (!ring)
-		goto err_destroy_tx1;
+		goto err_destroy_tx0;
 	dma->tx_ring2 =3D ring;
=20
 	ring =3D b43_setup_dmaring(dev, 3, 1, dma64);
@@ -983,6 +986,7 @@ int b43_dma_init(struct b43_wldev *dev)
 	if (!ring)
 		goto err_destroy_tx4;
 	dma->tx_ring5 =3D ring;
+#endif
=20
 	/* setup RX DMA channels. */
 	ring =3D b43_setup_dmaring(dev, 0, 0, dma64);
@@ -1001,30 +1005,32 @@ int b43_dma_init(struct b43_wldev *dev)
 	       (dmamask =3D=3D DMA_64BIT_MASK) ? 64 :
 	       (dmamask =3D=3D DMA_32BIT_MASK) ? 32 : 30);
 	err =3D 0;
-      out:
+out:
 	return err;
=20
-      err_destroy_rx0:
+err_destroy_rx0:
 	b43_destroy_dmaring(dma->rx_ring0);
 	dma->rx_ring0 =3D NULL;
-      err_destroy_tx5:
+err_destroy_tx5:
+#if 0
 	b43_destroy_dmaring(dma->tx_ring5);
 	dma->tx_ring5 =3D NULL;
-      err_destroy_tx4:
+err_destroy_tx4:
 	b43_destroy_dmaring(dma->tx_ring4);
 	dma->tx_ring4 =3D NULL;
-      err_destroy_tx3:
+err_destroy_tx3:
 	b43_destroy_dmaring(dma->tx_ring3);
 	dma->tx_ring3 =3D NULL;
-      err_destroy_tx2:
+err_destroy_tx2:
 	b43_destroy_dmaring(dma->tx_ring2);
 	dma->tx_ring2 =3D NULL;
-      err_destroy_tx1:
-	b43_destroy_dmaring(dma->tx_ring1);
-	dma->tx_ring1 =3D NULL;
-      err_destroy_tx0:
+err_destroy_tx0:
 	b43_destroy_dmaring(dma->tx_ring0);
 	dma->tx_ring0 =3D NULL;
+err_destroy_tx1:
+#endif
+	b43_destroy_dmaring(dma->tx_ring1);
+	dma->tx_ring1 =3D NULL;
 	goto out;
 }
=20
Index: wireless-2.6/drivers/net/wireless/b43/main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c
+++ wireless-2.6/drivers/net/wireless/b43/main.c
@@ -93,6 +93,7 @@ static const struct ssb_device_id b43_ss
 	SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 7),
 	SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 9),
 	SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 10),
+	SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 13),
 	SSB_DEVTABLE_END
 };
=20
@@ -3064,7 +3065,7 @@ static int b43_phy_versioning(struct b43
 			unsupported =3D 1;
 		break;
 	case B43_PHYTYPE_G:
-		if (phy_rev > 8)
+		if (phy_rev > 9)
 			unsupported =3D 1;
 		break;
 	default:
Index: wireless-2.6/drivers/net/wireless/b43/wa.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- wireless-2.6.orig/drivers/net/wireless/b43/wa.c
+++ wireless-2.6/drivers/net/wireless/b43/wa.c
@@ -642,6 +642,7 @@ void b43_wa_all(struct b43_wldev *dev)
 		case 6:
 		case 7:
 		case 8:
+		case 9:
 			b43_wa_tr_ltov(dev);
 			b43_wa_crs_ed(dev);
 			b43_wa_rssi_lt(dev);
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13

[Michael Buesch]

On Wednesday 21 November 2007 20:31:53 Larry Finger wrote:
> The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
> has not been supported until now. The changes include the following:
>=20
> (1) Add the 802.11 rev 13 device to the ssb_device_id table to load b=
43.
> (2) Add PHY revision 9 to the supported list.
> (3) Fix 64-bit addressing errors.
> (4) Remove some magic numbers in the DMA setup.
>=20
> The DMA implementation for this chip supports full 64-bit addressing =
with
> one exception. Whenever the Descriptor Ring Buffer is in high memory,=
 a
> fatal DMA error occurs. This problem was not present in 2.6.24-rc2 du=
e
> to code to "Bias the placement of kernel pages at lower PFNs". When
> commit 44048d70 reverted that code, the DMA error appeared. As a "fix=
",
> use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At pr=
esent,
> this problem is thought to arise from a hardware error. The present d=
river
> allocates one ring buffer for RX and six for TX; however, only one of=
 the
> TX buffers is used. To minimize any system impact associated with usi=
ng low
> memory, this patch removes the allocation of the unused buffers.
>=20
> This patch has been tested by C=C3=A9dric Caumont <icare40@hotmail.co=
m>.
>=20

> @@ -954,19 +955,21 @@ int b43_dma_init(struct b43_wldev *dev)
> =20
>  	err =3D -ENOMEM;
>  	/* setup TX DMA channels. */
> -	ring =3D b43_setup_dmaring(dev, 0, 1, dma64);
> +	ring =3D b43_setup_dmaring(dev, 1, 1, dma64);
>  	if (!ring)
>  		goto out;
> -	dma->tx_ring0 =3D ring;
> +	dma->tx_ring1 =3D ring;
> =20
> -	ring =3D b43_setup_dmaring(dev, 1, 1, dma64);
> +	/* The driver only uses ring1 for TX - skip setup for the rest */
> +#if 0

NACK.

> +	ring =3D b43_setup_dmaring(dev, 0, 1, dma64);
>  	if (!ring)
> -		goto err_destroy_tx0;
> -	dma->tx_ring1 =3D ring;
> +		goto err_destroy_tx1;
> +	dma->tx_ring0 =3D ring;
> =20
>  	ring =3D b43_setup_dmaring(dev, 2, 1, dma64);
>  	if (!ring)
> -		goto err_destroy_tx1;
> +		goto err_destroy_tx0;
>  	dma->tx_ring2 =3D ring;
> =20
>  	ring =3D b43_setup_dmaring(dev, 3, 1, dma64);
> @@ -983,6 +986,7 @@ int b43_dma_init(struct b43_wldev *dev)
>  	if (!ring)
>  		goto err_destroy_tx4;
>  	dma->tx_ring5 =3D ring;
> +#endif


--=20
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13

[Larry Finger]

Michael Buesch wrote:
> On Wednesday 21 November 2007 20:31:53 Larry Finger wrote:
>> The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
>> has not been supported until now. The changes include the following:
>>
>> (1) Add the 802.11 rev 13 device to the ssb_device_id table to load =
b43.
>> (2) Add PHY revision 9 to the supported list.
>> (3) Fix 64-bit addressing errors.
>> (4) Remove some magic numbers in the DMA setup.
>>
>> The DMA implementation for this chip supports full 64-bit addressing=
 with
>> one exception. Whenever the Descriptor Ring Buffer is in high memory=
, a
>> fatal DMA error occurs. This problem was not present in 2.6.24-rc2 d=
ue
>> to code to "Bias the placement of kernel pages at lower PFNs". When
>> commit 44048d70 reverted that code, the DMA error appeared. As a "fi=
x",
>> use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At p=
resent,
>> this problem is thought to arise from a hardware error. The present =
driver
>> allocates one ring buffer for RX and six for TX; however, only one o=
f the
>> TX buffers is used. To minimize any system impact associated with us=
ing low
>> memory, this patch removes the allocation of the unused buffers.
>>
>> This patch has been tested by C=C3=A9dric Caumont <icare40@hotmail.c=
om>.
>>
>=20
>> @@ -954,19 +955,21 @@ int b43_dma_init(struct b43_wldev *dev)
>> =20
>>  	err =3D -ENOMEM;
>>  	/* setup TX DMA channels. */
>> -	ring =3D b43_setup_dmaring(dev, 0, 1, dma64);
>> +	ring =3D b43_setup_dmaring(dev, 1, 1, dma64);
>>  	if (!ring)
>>  		goto out;
>> -	dma->tx_ring0 =3D ring;
>> +	dma->tx_ring1 =3D ring;
>> =20
>> -	ring =3D b43_setup_dmaring(dev, 1, 1, dma64);
>> +	/* The driver only uses ring1 for TX - skip setup for the rest */
>> +#if 0
>=20
> NACK.

Are you NACKing the "if 0" or the elimination of the unused TX rings? P=
erhaps we could have

	if (ring->dma64)
		goto out;

Larry
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13

[Michael Buesch]

On Wednesday 21 November 2007 21:02:25 Larry Finger wrote:
> Michael Buesch wrote:
> > On Wednesday 21 November 2007 20:31:53 Larry Finger wrote:
> >> The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 an=
d
> >> has not been supported until now. The changes include the followin=
g:
> >>
> >> (1) Add the 802.11 rev 13 device to the ssb_device_id table to loa=
d b43.
> >> (2) Add PHY revision 9 to the supported list.
> >> (3) Fix 64-bit addressing errors.
> >> (4) Remove some magic numbers in the DMA setup.
> >>
> >> The DMA implementation for this chip supports full 64-bit addressi=
ng with
> >> one exception. Whenever the Descriptor Ring Buffer is in high memo=
ry, a
> >> fatal DMA error occurs. This problem was not present in 2.6.24-rc2=
 due
> >> to code to "Bias the placement of kernel pages at lower PFNs". Whe=
n
> >> commit 44048d70 reverted that code, the DMA error appeared. As a "=
fix",
> >> use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At=
 present,
> >> this problem is thought to arise from a hardware error. The presen=
t driver
> >> allocates one ring buffer for RX and six for TX; however, only one=
 of the
> >> TX buffers is used. To minimize any system impact associated with =
using low
> >> memory, this patch removes the allocation of the unused buffers.
> >>
> >> This patch has been tested by C=C3=A9dric Caumont <icare40@hotmail=
=2Ecom>.
> >>
> >=20
> >> @@ -954,19 +955,21 @@ int b43_dma_init(struct b43_wldev *dev)
> >> =20
> >>  	err =3D -ENOMEM;
> >>  	/* setup TX DMA channels. */
> >> -	ring =3D b43_setup_dmaring(dev, 0, 1, dma64);
> >> +	ring =3D b43_setup_dmaring(dev, 1, 1, dma64);
> >>  	if (!ring)
> >>  		goto out;
> >> -	dma->tx_ring0 =3D ring;
> >> +	dma->tx_ring1 =3D ring;
> >> =20
> >> -	ring =3D b43_setup_dmaring(dev, 1, 1, dma64);
> >> +	/* The driver only uses ring1 for TX - skip setup for the rest *=
/
> >> +#if 0
> >=20
> > NACK.
>=20
> Are you NACKing the "if 0" or the elimination of the unused TX rings?=
 Perhaps we could have

Both

> 	if (ring->dma64)
> 		goto out;

No,
I am going to submit patches to enable use of multiple TX queues.
See my quilt series.
Simply don't change current behaviour. ;)

The only reason for me holding these patches back is that I could
not sufficiently test them yet.

--=20
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13

[Chuck Ebbert]

On 11/21/2007 02:31 PM, Larry Finger wrote:
> The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
> has not been supported until now. The changes include the following:
> 

I put this in a private build of the Fedora 8 kernel in place of the
the one that was added a few days ago.

This one works, but I get "PHY transmission error", probably because
the rfkill switch has disabled it. I see two LED devices and an input
device were registered but pushing the rfkill switch has no effect.
Googling doesn't yield any directions for enabling the switch...

Re: [PATCH] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13

[Larry Finger]

Chuck Ebbert wrote:
> On 11/21/2007 02:31 PM, Larry Finger wrote:
>> The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
>> has not been supported until now. The changes include the following:
>>
> 
> I put this in a private build of the Fedora 8 kernel in place of the
> the one that was added a few days ago.
> 
> This one works, but I get "PHY transmission error", probably because
> the rfkill switch has disabled it. I see two LED devices and an input
> device were registered but pushing the rfkill switch has no effect.
> Googling doesn't yield any directions for enabling the switch...

I don't think the PHY transmission error is caused by the rfkill switch, but I have no idea where it 
arises. It has been present since I enabled the device with 64-bit DMA.

I have not determined how to get rfkill to react to the LED switch, but now that the BCM4311 rev 02 
card is working, I should have some time to look at it.

Larry