On Sat, Feb 27, 2010 at 5:37 PM, Larry Finger <larry.fin...@lwfinger.net> wrote:
> On 02/27/2010 10:08 AM, Michael Buesch wrote:
>> On Saturday 27 February 2010 17:05:41 Larry Finger wrote:
>>> On 02/27/2010 09:20 AM, Michael Buesch wrote:
>>>> On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
>>>>> Someone should test the following:
>>>>> -Open drivers/ssb/driver_chipcommon_pmu.c
>>>>> -In ssb_pmu_init, replace 0x4325 with 0x4312.
>>>>
>>>> Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the
>>>> SSB?
>>>> If so, you should really make sure the PMU setup is correct. If the PMU
>>>> cuts power to the device at inappropriate times, it sure does result in
>>>> DMA errors (and
>>>> silent MMIO errors).
>>>
>>> Yes, all of the LP PHY 14e4:4315 devices have a PMU. Mine shows "Found rev
>>> 1 PMU
>>> (capabilities 0x02A62F01)". As I recall, at least one of the problem devices
>>> shows the same capabilities.
>>
>> *HINT HINT HINT* ;)
>> Please make sure the PMU code really is correct.
>
> Where are the specs that were used to write the original code? I cannot find
> them in either the V3 or V4 pages.
>
> Larry
> _______________________________________________
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>
So, a quick status update, from what I've found yesterday:
1. We get the PMU setup wrong. Bit 0x200 is being set, despite the
PMU being rev1. Also, PMU setup is done too early - at least wl reads
the SPROM before setting up the PMU. A write of 0xcbb to offset 0x618
is also missing - I seem to remember that this change has been tried
already, to no avail; but it may be a prerequisite of the real fix.
2. Just before the SPROM readout, we are missing a "Set 0x8000 in
MMIO offset 0x280a". This looks curiously like "PCI-E Miscellaneous
Configuration", from http://bcm-v4.sipsolutions.net/PCI-E - and
indeed, the value read out from 0x280a is identical to offset 0xa in
my SPROM. So, the right thing to do here is probably "Switch to the
PCIE core, set 0x8000 in MIMO offset 0x80a (or maybe 0x1000a?), switch
back to ChipCommon". I don't know what core is active during this
write, as mmiotrace doesn't catch pci_read/write_config_dword calls.
Larry, do you know a way to monitor PCI config space access in a way
that can be matched (e.g. using timestamps) to the MMIO trace?
3. Right after the SPROM is read, wl writes zeros to MMIO offsets
0x58 and 0x5c (32-bit), then does the PMU setup. These are not valid
registers for ChipCommon and PCIE, but for 802.11, they fall directly
into the DMA area! So, if these writes happened with the 802.11 core
active, they are probably significant.
I second Larry's question: where are the specs for the PMU init code?
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
