Bug 192567 - [ath] AR9331 regulator programming is checking OTP but reading garbage
Summary: [ath] AR9331 regulator programming is checking OTP but reading garbage
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-11 00:10 UTC by Adrian Chadd
Modified: 2014-08-11 00:10 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Chadd freebsd_committer 2014-08-11 00:10:43 UTC
The AR9331 HAL is programming the regulator during reset. However, it's reading values from the OTP which seems to (a) read correctly from the OTP, but (b) read 0xbadc0ffe. I'm not sure why that is yet (eg is the OTP hardware off?)

Now, on the AR9331 boards I have (eg carambola 2) the calibration data is in the NOR flash rather than OTP.  So, this won't .. work. I'm not sure which boards will use OTP in this instance.

But the code seems to check and use the OTP value. Ie:

ar9300_internal_regulator_apply():
...
                    if ((reg_val & 0x80) == 0x80){
                        usb_valid = 1;
                        reg_usb = reg_val & 0x000000ff;
                    }
...
                    if ((reg_val & 0x80000000) == 0x80000000){
                        pmu_valid = 1;
                        reg_pmu = (reg_val & 0xff000000) >> 24;
                    }

... 0xbadc0ffe has both of those bits set!

ath9k doesn't bother checking the OTP here. It just uses some local values to program in.

So, what should be done?

* Is the code correct but OTP isn't on for some reason?
* Should I be checking the in-flash calibration data?
* should I just ignore OTP and use hard-coded values like ath9k?



-a