From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Roskin Date: Sat, 22 Jan 2011 20:05:03 -0500 Subject: [ath9k-devel] AR9220: how do I wake it up? :) In-Reply-To: References: <4D39C820.7020603@gnu.org> Message-ID: <4D3B7EBF.1070904@gnu.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 01/22/2011 07:28 AM, Adrian Chadd wrote: > On 22 January 2011 01:53, Pavel Roskin wrote: > >>> Would someone mind letting me know what this particular fix does and >>> why it's needed? > >> I don't know much about the meaning of that bit. My patch only changes the >> way the fixup is applied. Instead of modifying the common table that is >> shares between all devices, the bit is changed when the data is written to >> the register. This allows peaceful coexistence of the devices with >> different EEPROM in the same system. > > Yup. I saw that's why you did it. I was just wondering what the > particular value in the EEPROM means. It has something to do with the bus clock. >> My patch also was a step towards declaring the init tables constant, but >> there is another fixup for AR9160 that is harder to fix. I never had time >> to do the later. > > I'm thinking of doing the same to the FreeBSD HAL. I may take a copy > of the init tables rather than a reference to them. Then they can be > fiddled as needed. > > There's another eeprom value base fix to the AR9160 code which I > haven't yet put into the freebsd HAL (some baseband bias level) which > also fiddles with an ini array (a radio init one.) That also needs to > be fixed for similar reasons. I wonder if ath9k does the same. Perhaps you misread my words. I believe ath9k still needs to be fixed with regard to AR9160 fixups. As for the copying, it's probably a very high cost if only a few values need to be adjusted. I'd rather go with a list of values to adjust. Initialization is not performance critical (as long as we are not talking about tenths of a second or more), but embedded systems may be short on memory. -- Regards, Pavel Roskin