From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.s-osg.org ([54.187.51.154]:60366 "EHLO lists.s-osg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753410AbbH0MXf (ORCPT ); Thu, 27 Aug 2015 08:23:35 -0400 Subject: Re: [RFC bluetooth-next 1/2] at86rf230: change trac status check behaviour References: <1438874501-19971-1-git-send-email-alex.aring@gmail.com> <1438874501-19971-2-git-send-email-alex.aring@gmail.com> <55DEDEDB.1010302@osg.samsung.com> <20150827101318.GA2609@omega> From: Stefan Schmidt Message-ID: <55DF0142.90608@osg.samsung.com> Date: Thu, 27 Aug 2015 14:23:30 +0200 MIME-Version: 1.0 In-Reply-To: <20150827101318.GA2609@omega> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-wpan-owner@vger.kernel.org List-ID: To: Alexander Aring Cc: linux-wpan@vger.kernel.org, kernel@pengutronix.de Hello. On 27/08/15 12:13, Alexander Aring wrote: > On Thu, Aug 27, 2015 at 11:56:43AM +0200, Stefan Schmidt wrote: >> Hello. >> >> On 06/08/15 17:21, Alexander Aring wrote: >>> When transmit is done, indicated by trx_end irq, we do first a force >>> state change to TX_ON and then checking the trac status, if the trac >>> status is unequal zero we do a state change to TRX_OFF. >>> >>> This patch changes to the following behaviour, we first check on trac >>> status after trx_end occurs and then doing a normal change to TX_ON >>> without do the state change to TRX_OFF when trac status is unequal zero. >>> >>> The reasons are that the datasheet doesn't described when the trac >>> status register is cleared, we should doing to evaluate the trac status >>> at first. The reason to remove the TRX_OFF change if the trac status is >>> unequal to zero and it was force is the following paragraph inside The >>> at86rf2xx datasheets: >>> >>> "Using FORCE_PLL_ON to interrupt an TX_ARET transaction, it is >>> recommended to check register bits [7:5] of register address 0x32 for >>> value 0. If this value is different, TRX_CMD sequence FORCE_TRX_OFF shall >>> be used immediately followed by TRX_CMD sequence PLL_ON. This performs a >>> state transition to PLL_ON." >> I had a hard time finding a register description of 0x32 in my copies. Are >> they outdated or am I just blind? Any hints appreciated. :) >> > I think this is a mistake in the datasheet, they mean the "TRAC_STATUS" > here, which is the only value which fits in the range of [7:5] in > Register 0x02. This makes more sense. Thanks. Code 4 and 6 and marked as reserved which is what you are counting aggregated in the reserved counter. Not sure if that really buys us anything. We don't know if we get them at all (something we will see over time with your patches), we don't know which one comes in (count be changed when counting them separately) but most important we don't know what they mean and what we should do. :) I would say ignore them. The counter has no meaning for us. regards Stefan Schmidt