* Enabling PLL timeout on BCMA bus
@ 2011-07-15 22:34 Rafał Miłecki
2011-07-15 23:51 ` Rafał Miłecki
0 siblings, 1 reply; 7+ messages in thread
From: Rafał Miłecki @ 2011-07-15 22:34 UTC (permalink / raw)
To: b43-dev
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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Enabling PLL timeout on BCMA bus
2011-07-15 22:34 Enabling PLL timeout on BCMA bus Rafał Miłecki
@ 2011-07-15 23:51 ` Rafał Miłecki
2011-07-16 1:14 ` Rafał Miłecki
0 siblings, 1 reply; 7+ messages in thread
From: Rafał Miłecki @ 2011-07-15 23:51 UTC (permalink / raw)
To: b43-dev
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Enabling PLL timeout on BCMA bus
2011-07-15 23:51 ` Rafał Miłecki
@ 2011-07-16 1:14 ` Rafał Miłecki
2011-07-16 9:51 ` Rafał Miłecki
0 siblings, 1 reply; 7+ messages in thread
From: Rafał Miłecki @ 2011-07-16 1:14 UTC (permalink / raw)
To: b43-dev
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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Enabling PLL timeout on BCMA bus
2011-07-16 1:14 ` Rafał Miłecki
@ 2011-07-16 9:51 ` Rafał Miłecki
2011-07-17 10:22 ` Kalle Valo
0 siblings, 1 reply; 7+ messages in thread
From: Rafał Miłecki @ 2011-07-16 9:51 UTC (permalink / raw)
To: b43-dev
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Enabling PLL timeout on BCMA bus
2011-07-16 9:51 ` Rafał Miłecki
@ 2011-07-17 10:22 ` Kalle Valo
2011-07-17 16:40 ` Rafał Miłecki
0 siblings, 1 reply; 7+ messages in thread
From: Kalle Valo @ 2011-07-17 10:22 UTC (permalink / raw)
To: b43-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Enabling PLL timeout on BCMA bus
2011-07-17 10:22 ` Kalle Valo
@ 2011-07-17 16:40 ` Rafał Miłecki
2011-07-17 16:41 ` Rafał Miłecki
0 siblings, 1 reply; 7+ messages in thread
From: Rafał Miłecki @ 2011-07-17 16:40 UTC (permalink / raw)
To: b43-dev
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Enabling PLL timeout on BCMA bus
2011-07-17 16:40 ` Rafał Miłecki
@ 2011-07-17 16:41 ` Rafał Miłecki
0 siblings, 0 replies; 7+ messages in thread
From: Rafał Miłecki @ 2011-07-17 16:41 UTC (permalink / raw)
To: b43-dev
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-07-17 16:41 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-15 22:34 Enabling PLL timeout on BCMA bus Rafał Miłecki
2011-07-15 23:51 ` Rafał Miłecki
2011-07-16 1:14 ` Rafał Miłecki
2011-07-16 9:51 ` Rafał Miłecki
2011-07-17 10:22 ` Kalle Valo
2011-07-17 16:40 ` Rafał Miłecki
2011-07-17 16:41 ` Rafał Miłecki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox