2015-07-03 17:47 GMT+02:00 Alexander Aring <alex.aring@xxxxxxxxx>:
> On Fri, Jul 03, 2015 at 03:24:17PM +0200, Baptiste Clenet wrote:
> ...
>>
>> - in at86rf230_async_read_reg, ctx->trx.len = 2 so the spi driver
>> receives 0x8100 instead of 0x81 to read TRX_STATUS which results to no
>> readings (for me)! The transceiver returns 0
>> ---> I set ctx->trx.len to 1 and I receive 8 (TRX_OFF) which seems good.
>>
>
> mhhhh, our buffer for spi_async messages for tx and rx are the same. If
> you now look in datasheet [0] at page 18.
>
> Look at Register Read Access.
>
> This is always two bytes. On MOSI there is at first byte the
> READ_COMMAND then follows on MISO the READ DATA.
>
>
> NOTE:
> Now when you spi controller supports full duplex of MISO/MOSI then the
> first byte is overwritten by PHY_STATUS.
>
> You can setup PHY_STATUS at SPI_CMD_MODE which is defaults to "empy, all
> bits zero".
>
> We don't using the PHY_STATUS thing in the driver, because this required
> that the spi controller supports full duplex.
>
> If you say now making ctx->trx.len = 1 solved some issue then I think
> the READ_COMMAND will be overwritten by READ DATA. But READ DATA should
> be placed after READ_COMMAND (inside the buffer).
>
> I think regmap uses the same behaviour also because, we set:
>
> .reg_bits = 8,
> .val_bits = 8,
>
> This exactly means some buffer [ READ_COMMAND (reg_bits) | READ DATA (val_bits)].
I definitely agree with all of that and I'm wondering why the spi
driver behaves like this (spi-mt7621)
> Don't know why it works for regmap and not for spi_async then. For me it
> looks like that the first byte which is READ_COMMAND will be overwritten
> by READ DATA, but READ DATA should be after READ_COMMAND.
>
>> -- in at86rf230_async_state_change_start, we check if (trx_state ==
>> ctx->to_state), current state are: trx_state 8, ctx->to_state 3, Why
>> are we checking if ctx->to_state 3? Because it's impossible to get 3
>> in TRX_STATUS, isn't it? So we should check for a 8 here?
>>
>
> Where do we check on to_state 3 which is STATE_FORCE_TRX_OFF.
My bad, I didn't see that we change it in at86rf230_async_state_delay:
case STATE_FORCE_TRX_OFF:
ctx->to_state = STATE_TRX_OFF;
>
> - Alex
>
> [0] http://www.atmel.com/images/atmel-42002-mcu_wireless-at86rf212b_datasheet.pdf
I solved my problem by replacing:
1:
const u8 trx_state = buf[1] & TRX_STATE_MASK;
-->
const u8 trx_state = buf[0] & TRX_STATE_MASK;
in at86rf230_async_state_assert and
at86rf230_async_state_change_start(void *context)
2: add
- ctx->trx.len = 1; before ctx->msg.complete = complete; in
at86rf230_async_read_reg
- ctx->trx.len = 2; before buf[0] = (RG_TRX_STATE & CMD_REG_MASK) |
CMD_REG | CMD_WRITE; in at86rf230_async_state_change_start
I don't get the "unexcept state change from ..." now.
First problem seems solved (it's weird but it works, if I've got more
time, will debug deeper)
My last problem is when I set the lowpan interface up!
The spi driver complains because the message seems too big! The spi
driver has got 8 registers of 32 bytes as buffer but the ndisc
messages are bigger than that so spi driver raises WARN_ON
--
Baptiste
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
