On Tuesday 09 March 2010 15:45:58 Bob Copeland wrote:
> On Tue, Mar 9, 2010 at 12:56 AM, Bruno Randolf wrote:
> > On Tuesday 09 March 2010 12:32:33 Luis R. Rodriguez wrote:
> >> Perhaps a little more elaboration on the commit log on the impact and
> >> how this helps and how much would help.
> >
On Tue, Mar 9, 2010 at 12:56 AM, Bruno Randolf wrote:
> On Tuesday 09 March 2010 12:32:33 Luis R. Rodriguez wrote:
>> Perhaps a little more elaboration on the commit log on the impact and
>> how this helps and how much would help.
>
> ok. to stop the confusion, i'll add cc: stable.
:) thanks!
FW
On Tuesday 09 March 2010 12:32:33 Luis R. Rodriguez wrote:
> On Mon, Mar 8, 2010 at 7:10 PM, Bob Copeland wrote:
> > On Mon, Mar 8, 2010 at 8:21 PM, Luis R. Rodriguez
wrote:
> >> On Mon, Mar 8, 2010 at 4:50 PM, Bruno Randolf wrote:
> > as i said, in my point of view ath5k has several probl
On Mon, Mar 8, 2010 at 7:10 PM, Bob Copeland wrote:
> On Mon, Mar 8, 2010 at 8:21 PM, Luis R. Rodriguez wrote:
>> On Mon, Mar 8, 2010 at 4:50 PM, Bruno Randolf wrote:
>
> as i said, in my point of view ath5k has several problems right now
> (performace and stability), and i guess nobod
On Mon, Mar 8, 2010 at 8:21 PM, Luis R. Rodriguez wrote:
> On Mon, Mar 8, 2010 at 4:50 PM, Bruno Randolf wrote:
>>> > as i said, in my point of view ath5k has several problems right now
>>> > (performace and stability), and i guess nobody will be using it seriously
>>> > in actual production use
On Mon, Mar 8, 2010 at 4:50 PM, Bruno Randolf wrote:
> On Tuesday 09 March 2010 09:47:09 Luis R. Rodriguez wrote:
>> On Mon, Mar 8, 2010 at 4:34 PM, Bruno Randolf wrote:
>> > On Tuesday 09 March 2010 01:24:48 Luis R. Rodriguez wrote:
>> >> >> Thanks Bruno, are these stable fixes?
>> >> >
>> >> >
On Mon, Mar 8, 2010 at 4:34 PM, Bruno Randolf wrote:
> On Tuesday 09 March 2010 01:24:48 Luis R. Rodriguez wrote:
>> >> Thanks Bruno, are these stable fixes?
>> >
>> > hi luis!
>> >
>> > i think so. the behaviour before was completely broken, now it's better.
>> >
>> > but i'm not sure about that
On Tuesday 09 March 2010 09:47:09 Luis R. Rodriguez wrote:
> On Mon, Mar 8, 2010 at 4:34 PM, Bruno Randolf wrote:
> > On Tuesday 09 March 2010 01:24:48 Luis R. Rodriguez wrote:
> >> >> Thanks Bruno, are these stable fixes?
> >> >
> >> > hi luis!
> >> >
> >> > i think so. the behaviour before was
El 09/03/2010 1:24, Bruno Randolf escribió:
> On Monday 08 March 2010 21:45:55 Jorge Boncompte [DTI2] wrote:
>> El 08/03/2010 3:59, Bruno Randolf escribió:
>>> 4.) we can't use ENABLE_BITS when we want to write a number (the number
>>> can contain zeros). also always write the correction values fir
On Tuesday 09 March 2010 01:24:48 Luis R. Rodriguez wrote:
> >> Thanks Bruno, are these stable fixes?
> >
> > hi luis!
> >
> > i think so. the behaviour before was completely broken, now it's better.
> >
> > but i'm not sure about that whole Cc: sta...@kernel.org thing... (sorry
> > i've been aw
On Monday 08 March 2010 21:45:55 Jorge Boncompte [DTI2] wrote:
> El 08/03/2010 3:59, Bruno Randolf escribió:
> > 4.) we can't use ENABLE_BITS when we want to write a number (the number
> > can contain zeros). also always write the correction values first and
> > set ENABLE bit last, like the HAL do
On Sun, Mar 7, 2010 at 8:17 PM, Bruno Randolf wrote:
> On Monday 08 March 2010 12:56:52 Luis R. Rodriguez wrote:
>> On Sun, Mar 7, 2010 at 6:59 PM, Bruno Randolf wrote:
>> > I/Q calibration was completely broken, resulting in a high number of CRC
>> > errors on received packets. before i could se
El 08/03/2010 3:59, Bruno Randolf escribió:
>
> 4.) we can't use ENABLE_BITS when we want to write a number (the number can
> contain zeros). also always write the correction values first and set ENABLE
> bit last, like the HAL does.
>
Hi Bruno,
does not ath5k_hw_commit_eeprom_se
On Monday 08 March 2010 12:56:52 Luis R. Rodriguez wrote:
> On Sun, Mar 7, 2010 at 6:59 PM, Bruno Randolf wrote:
> > I/Q calibration was completely broken, resulting in a high number of CRC
> > errors on received packets. before i could see around 10% to 20% CRC
> > errors, with this patch they ar
On Sun, Mar 7, 2010 at 6:59 PM, Bruno Randolf wrote:
> I/Q calibration was completely broken, resulting in a high number of CRC
> errors
> on received packets. before i could see around 10% to 20% CRC errors, with
> this
> patch they are between 0% and 3%.
>
> 1.) the removal of the mask in comm
I/Q calibration was completely broken, resulting in a high number of CRC errors
on received packets. before i could see around 10% to 20% CRC errors, with this
patch they are between 0% and 3%.
1.) the removal of the mask in commit "ath5k: Fix I/Q calibration
(f1cf2dbd0f798b71b1590e7aca6647f2caef1
16 matches
Mail list logo
