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)]. 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. - Alex [0] http://www.atmel.com/images/atmel-42002-mcu_wireless-at86rf212b_datasheet.pdf -- 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
