W dniu 16 lipca 2011 01:51 użytkownik Rafał Miłecki <[email protected]> napisał: > W dniu 16 lipca 2011 00:34 użytkownik Rafał Miłecki <[email protected]> > 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ł
dump-b43.txt.b43
Description: Binary data
dump-wl.txt.b43
Description: Binary data
diff.patch
Description: Binary data
_______________________________________________ b43-dev mailing list [email protected] http://lists.infradead.org/mailman/listinfo/b43-dev
