Enabling PLL timeout on BCMA bus

Enabling PLL timeout on BCMA bus

[Rafał Miłecki]

While performing core init on BCMA bus we need to enable PLL. This is
performed by wl, but fails with bcma & b43 with timeout.

I've compare MMIO dumps of both and ugly-hacked bcma to do everything
in exactly the same order. The problem is is didn't help.


***** wl *****
First enable HT (0x2):
 read32 0xfaafc1e0 -> 0x00010000
write32 0xfaafc1e0 <- 0x00010002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x030b0002 <- 0x300 already enabled

Now enable PLL for 0x3 (0x300)
 read32 0xfaafc1e0 -> 0x030b0002
write32 0xfaafc1e0 <- 0x030b0302
 read32 0xfaafc1e0 -> 0x030b0302
 read32 0xfaafc1e0 -> 0x030b0302


***** bcma & b43 *****
First enable HT (0x2):
 read32 0xfaafc1e0 -> 0x00050000 <- 0x00040000 == BP_ON_ALP
write32 0xfaafc1e0 <- 0x00050002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x000b0002 <- 0x300 not enabled by def

Now enable PLL for 0x3 (0x300)
 read32 0xfaafc1e0 -> 0x000b0002
write32 0xfaafc1e0 <- 0x000b0302
 read32 0xfaafc1e0 -> 0x000b0002 <- 0x300 ignored?
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
(and so on...)


The only difference seems be be initial state of 0x1e0. Of course both
situations are from cold boot.
wl: 0x00010000
bcma: 0x00050000
HAVEALP	0x00010000 /* ALP available */
BP_ON_ALP	0x00040000 /* RO: running on ALP clock */

In attached dumps you can see init path is exactly the same for wl and bcma&b43.

Does anyone have any idea, why bcma&b43 can not enable PLL (0x300
bits)? Why is it enabled by default when wl does use the bus?

-- 
Rafa?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump-wl.txt.b43
Type: application/octet-stream
Size: 2969 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110716/510eacf9/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump-b43.txt.b43
Type: application/octet-stream
Size: 3464 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110716/510eacf9/attachment-0001.obj>

Enabling PLL timeout on BCMA bus

[Rafał Miłecki]

W dniu 16 lipca 2011 00:34 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> While performing core init on BCMA bus we need to enable PLL. This is
> performed by wl, but fails with bcma & b43 with timeout.
>
> I've compare MMIO dumps of both and ugly-hacked bcma to do everything
> in exactly the same order. The problem is is didn't help.
>
>
> ***** wl *****
> First enable HT (0x2):
> ?read32 0xfaafc1e0 -> 0x00010000
> write32 0xfaafc1e0 <- 0x00010002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x030b0002 <- 0x300 already enabled
>
> Now enable PLL for 0x3 (0x300)
> ?read32 0xfaafc1e0 -> 0x030b0002
> write32 0xfaafc1e0 <- 0x030b0302
> ?read32 0xfaafc1e0 -> 0x030b0302
> ?read32 0xfaafc1e0 -> 0x030b0302
>
>
> ***** bcma & b43 *****
> First enable HT (0x2):
> ?read32 0xfaafc1e0 -> 0x00050000 <- 0x00040000 == BP_ON_ALP
> write32 0xfaafc1e0 <- 0x00050002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x000b0002 <- 0x300 not enabled by def
>
> Now enable PLL for 0x3 (0x300)
> ?read32 0xfaafc1e0 -> 0x000b0002
> write32 0xfaafc1e0 <- 0x000b0302
> ?read32 0xfaafc1e0 -> 0x000b0002 <- 0x300 ignored?
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> (and so on...)
>
>
> The only difference seems be be initial state of 0x1e0. Of course both
> situations are from cold boot.
> wl: 0x00010000
> bcma: 0x00050000
> HAVEALP 0x00010000 /* ALP available */
> BP_ON_ALP ? ? ? 0x00040000 /* RO: running on ALP clock */
>
> In attached dumps you can see init path is exactly the same for wl and bcma&b43.
>
> Does anyone have any idea, why bcma&b43 can not enable PLL (0x300
> bits)? Why is it enabled by default when wl does use the bus?

I've started tracking 0x1e0 register during bcma init and noticed that
at the very beginning it is equal to 0x10000, just like in case of wl
when it starts it's ops on 0x1e0.

When using bcma 0x1e0 changes from default 0x10000 after
1) Reading SPROM
2) Resetting core

So I've temporarily disabled both. This resulted in 0x10000 value at
the beginning of enabling PLL, but didn't really help:
 read32 0xfaafc1e0 -> 0x00010000
write32 0xfaafc1e0 <- 0x00010002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x00050002
 read32 0xfaafc1e0 -> 0x000b0002

 read32 0xfaafc1e0 -> 0x000b0002
write32 0xfaafc1e0 <- 0x000b0302
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
 read32 0xfaafc1e0 -> 0x000b0002
(... and so on)

-- 
Rafa?

Enabling PLL timeout on BCMA bus

[Rafał Miłecki]

W dniu 16 lipca 2011 01:51 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> W dniu 16 lipca 2011 00:34 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>> While performing core init on BCMA bus we need to enable PLL. This is
>> performed by wl, but fails with bcma & b43 with timeout.
>>
>> I've compare MMIO dumps of both and ugly-hacked bcma to do everything
>> in exactly the same order. The problem is is didn't help.
>>
>>
>> ***** wl *****
>> First enable HT (0x2):
>> ?read32 0xfaafc1e0 -> 0x00010000
>> write32 0xfaafc1e0 <- 0x00010002
>> ?read32 0xfaafc1e0 -> 0x00050002
>> ?read32 0xfaafc1e0 -> 0x00050002
>> ?read32 0xfaafc1e0 -> 0x030b0002 <- 0x300 already enabled
>>
>> Now enable PLL for 0x3 (0x300)
>> ?read32 0xfaafc1e0 -> 0x030b0002
>> write32 0xfaafc1e0 <- 0x030b0302
>> ?read32 0xfaafc1e0 -> 0x030b0302
>> ?read32 0xfaafc1e0 -> 0x030b0302
>>
>>
>> ***** bcma & b43 *****
>> First enable HT (0x2):
>> ?read32 0xfaafc1e0 -> 0x00050000 <- 0x00040000 == BP_ON_ALP
>> write32 0xfaafc1e0 <- 0x00050002
>> ?read32 0xfaafc1e0 -> 0x00050002
>> ?read32 0xfaafc1e0 -> 0x00050002
>> ?read32 0xfaafc1e0 -> 0x00050002
>> ?read32 0xfaafc1e0 -> 0x00050002
>> ?read32 0xfaafc1e0 -> 0x000b0002 <- 0x300 not enabled by def
>>
>> Now enable PLL for 0x3 (0x300)
>> ?read32 0xfaafc1e0 -> 0x000b0002
>> write32 0xfaafc1e0 <- 0x000b0302
>> ?read32 0xfaafc1e0 -> 0x000b0002 <- 0x300 ignored?
>> ?read32 0xfaafc1e0 -> 0x000b0002
>> ?read32 0xfaafc1e0 -> 0x000b0002
>> ?read32 0xfaafc1e0 -> 0x000b0002
>> ?read32 0xfaafc1e0 -> 0x000b0002
>> ?read32 0xfaafc1e0 -> 0x000b0002
>> ?read32 0xfaafc1e0 -> 0x000b0002
>> ?read32 0xfaafc1e0 -> 0x000b0002
>> ?read32 0xfaafc1e0 -> 0x000b0002
>> (and so on...)
>>
>>
>> The only difference seems be be initial state of 0x1e0. Of course both
>> situations are from cold boot.
>> wl: 0x00010000
>> bcma: 0x00050000
>> HAVEALP 0x00010000 /* ALP available */
>> BP_ON_ALP ? ? ? 0x00040000 /* RO: running on ALP clock */
>>
>> In attached dumps you can see init path is exactly the same for wl and bcma&b43.
>>
>> Does anyone have any idea, why bcma&b43 can not enable PLL (0x300
>> bits)? Why is it enabled by default when wl does use the bus?
>
> I've started tracking 0x1e0 register during bcma init and noticed that
> at the very beginning it is equal to 0x10000, just like in case of wl
> when it starts it's ops on 0x1e0.
>
> When using bcma 0x1e0 changes from default 0x10000 after
> 1) Reading SPROM
> 2) Resetting core
>
> So I've temporarily disabled both. This resulted in 0x10000 value at
> the beginning of enabling PLL, but didn't really help:
> ?read32 0xfaafc1e0 -> 0x00010000
> write32 0xfaafc1e0 <- 0x00010002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x00050002
> ?read32 0xfaafc1e0 -> 0x000b0002
>
> ?read32 0xfaafc1e0 -> 0x000b0002
> write32 0xfaafc1e0 <- 0x000b0302
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> ?read32 0xfaafc1e0 -> 0x000b0002
> (... and so on)

To be 100% we are identical to wl, I've implemented usage of
additional windows. I've also hacked this support to enable/disable it
for being 100% wl compatible.

There are no more differences other than slightly different EPROM
reading. We have some easier EPROM scanning in bcma which causes more
reads. That are reads only, I can not imagine it affecting anything.

My last hope is to find some magic in PCI config space.

-- 
Rafa?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump-b43.txt.b43
Type: application/octet-stream
Size: 9972 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110716/f04d40b9/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump-wl.txt.b43
Type: application/octet-stream
Size: 9741 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110716/f04d40b9/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff.patch
Type: application/octet-stream
Size: 1296 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110716/f04d40b9/attachment-0005.obj>

Enabling PLL timeout on BCMA bus

[Rafał Miłecki]

W dniu 16 lipca 2011 03:14 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> My last hope is to find some magic in PCI config space.

After dumping PCI config space ops, I've noticed there are writes to 4
uniq registers:
0x0D ? latency timer (setting to 64)
0x40 ? Disabling RETRY_TIMEOUT register (0x41)
0x80 ? PCI_BAR0_WIN
0xAC ? PCI_BAR0_WIN2

No magic here :( I've no idea what now. I don't see a single
difference between b43 and wl.

-- 
Rafa?

Enabling PLL timeout on BCMA bus

[Kalle Valo]

Rafa? Mi?ecki <zajec5@gmail.com> writes:

> W dniu 16 lipca 2011 03:14 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>> My last hope is to find some magic in PCI config space.
>
> After dumping PCI config space ops, I've noticed there are writes to 4
> uniq registers:
> 0x0D ? latency timer (setting to 64)
> 0x40 ? Disabling RETRY_TIMEOUT register (0x41)
> 0x80 ? PCI_BAR0_WIN
> 0xAC ? PCI_BAR0_WIN2
>
> No magic here :( I've no idea what now. I don't see a single
> difference between b43 and wl.

What about timing? Maybe wl is slower in some cases?

-- 
Kalle Valo

Enabling PLL timeout on BCMA bus

[Rafał Miłecki]

W dniu 17 lipca 2011 12:22 u?ytkownik Kalle Valo <kvalo@adurom.com> napisa?:
> Rafa? Mi?ecki <zajec5@gmail.com> writes:
>
>> W dniu 16 lipca 2011 03:14 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>> My last hope is to find some magic in PCI config space.
>>
>> After dumping PCI config space ops, I've noticed there are writes to 4
>> uniq registers:
>> 0x0D ? latency timer (setting to 64)
>> 0x40 ? Disabling RETRY_TIMEOUT register (0x41)
>> 0x80 ? PCI_BAR0_WIN
>> 0xAC ? PCI_BAR0_WIN2
>>
>> No magic here :( I've no idea what now. I don't see a single
>> difference between b43 and wl.
>
> What about timing? Maybe wl is slower in some cases?

I've hacked bcma putting mdelay(1) after ever R/W op. It didn't help.

I've discovered different interesting thing however. Register 0x1E0 is
not ChipCommon specific. It is valid for every core on my boards:
ChipCommon, 80211 and PCIE.

I've already sent patch implementing correct core reset, including PLL.


-- 
Rafa?

Enabling PLL timeout on BCMA bus

[Rafał Miłecki]

W dniu 17 lipca 2011 18:40 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> W dniu 17 lipca 2011 12:22 u?ytkownik Kalle Valo <kvalo@adurom.com> napisa?:
>> Rafa? Mi?ecki <zajec5@gmail.com> writes:
>>
>>> W dniu 16 lipca 2011 03:14 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>>> My last hope is to find some magic in PCI config space.
>>>
>>> After dumping PCI config space ops, I've noticed there are writes to 4
>>> uniq registers:
>>> 0x0D ? latency timer (setting to 64)
>>> 0x40 ? Disabling RETRY_TIMEOUT register (0x41)
>>> 0x80 ? PCI_BAR0_WIN
>>> 0xAC ? PCI_BAR0_WIN2
>>>
>>> No magic here :( I've no idea what now. I don't see a single
>>> difference between b43 and wl.
>>
>> What about timing? Maybe wl is slower in some cases?
>
> I've hacked bcma putting mdelay(1) after ever R/W op. It didn't help.
>
> I've discovered different interesting thing however. Register 0x1E0 is
> not ChipCommon specific. It is valid for every core on my boards:
> ChipCommon, 80211 and PCIE.

To make it clear: wl set clock and enables PLL on 80211 core. For all
the time I misinterpreted wl ops thinking it's performed on CC core.

-- 
Rafa?