Nvec

Discussions

Small nvec discussion log:

<stuw> marvin24, srwarren I have a question about nvec implementation. http://gitorious.org/~marvin24/ac100/marvin24s-kernel/blobs/rel-15r7-ac100/drivers/staging/nvec/nvec.c#line324  <- in case of error we keep msg allocated. After few errors we have no available slots in msg_pool. I suppose msg is not needed any more if error has occurred. Did I miss something in my reasoning?
<marvin24> stuw: I already send a fix for rpiloose for this
<marvin24> for->from
<marvin24> ah,maybe not - this is a different one
<marvin24> stuw: isn't the message freed in line 337?
<marvin24> ah, no, err == 0 is the error condition
<marvin24> weird
<stuw> marvin24, code looks like we want to wait/get responce at any price
<marvin24> stuw: in the error case the message pointer is just reset
<marvin24> no new buffer will get reserved
<marvin24> it just picks the old one from the list
<stuw> marvin24> stuw: in the error case the message pointer is just reset  <- are you talking about  msg->pos = 0 ?
<stuw> nvec_msg_alloc returns first unused (used flag is 0) msg from pool. nvec_request_master never marks msg as unused (never call nvec_msg_free for this msg) in case of error.
<stuw> I didn't analyze nvec driver enough to understand what msg->pos = 0 means :(
<marvin24> stuw: request_master checks if there is a message queued to be send to the ec
<marvin24> the queue is a list named tx_data
<marvin24> if the list is not empty, it will notify the ec to start the transfer (we can't do it because we are slave)
<marvin24> if after 5 secs the transfer is not finished, it will reset the message pointer (pointing to the next char to send)
<marvin24> the buffer is only freed if the message was transfered successfully
<marvin24> but if we timeout too often, we cannot accept new messages anymore
<marvin24> the problem is that most messages are async and they don't care about return values
<marvin24> if the tx queue is full (because we timeout all the time), we cannot send anymore
<marvin24> in fact, (nearly) all communication should be sync I think
<marvin24> but the sync write is not very robust yet
<marvin24> and still needs a lot of work
<stuw> marvin24, thanks for explanation.
<marvin24> stuw: thanks for review !
<stuw> marvin24, is nvec_request_master (i.e. send to EC) and nvec_dispatch (i.e. read from EC) performed in parallel ? I mean we should read all messages from EC before send anything if send to EC will block read from EC operation (If I understood EC documentation correctly)
<marvin24> stuw: no, they can be on the fly (in theroy)
<marvin24> but it's possible that we are not sending a new message unless the old one is finished
<marvin24> the sending, not the receive of the ack message
<stuw> Prev msg is a little bit wrong: we should read responses before send requests.
<stuw> marvin24, ok. thx once again :)
<marvin24> stuw: feel free to create a hack which improves it
<stuw> marvin24, I should understand code first :)

...
<rpiloose> dump of the code by muromec @ 17 march 2011: http://crap.muromec.org.ua/ac100/ecdump.bin
<rpiloose> of shit, I missed that: http://share.grandou.net/ac100/ec/

Errors

• nvec nvec.2: timeout waiting for ec transfer

We set gpio to initiate transfer but failed to transfer packet to EC for some reason.

• nvec nvec.2: could not allocate RX buffer

Receive pool is full. Looks like rx messages keep used (not freed).

• nvec nvec.2: unexpected status flags 0x18 during state 1
• nvec nvec.2: unexpected status flags 0x08 during state 0
• nvec nvec.2: unexpected status flags 0x1c during state 0
• nvec nvec.2: unexpected status flags 0x18 during state 0

Have no idea yet. 0x08 = 01000b (bits: 3) 0x18 = 11000b (bits: 3,4) 0x1c = 11100b (bits: 2,3,4)

<6>[  113.168691] psmouse.c: Wheel Mouse at nvec/input0 lost synchronization, throwing 2 bytes away.
<6>[  113.705433] psmouse.c: resync failed, issuing reconnect request
<6>[  115.309056] elantech: assuming hardware version 3 (with firmware version 0x150500)
<6>[  115.357593] elantech: Synaptics capabilities query result 0x69, 0x17, 0x09.
<6>[  115.569173] input: ETPS/2 Elantech Touchpad as /devices/serio0/input/input7

Have no idea yet.

Logs

20-th of September 2014 - dmesg from marvin24

Debugging

Hardware:

Openbench Logic Sniffer

Software:

OpenBench Logic Sniffer 3.08 (home page)

sigrok-cli

Notes

Driver must be Communications port (COM and LPT section in device manager)

Sometimes I2C analyzer detects false START event.

Correct:	Ошибка создания миниатюры: Не удаётся сохранить эскиз по месту назначения
Incorrect:	Ошибка создания миниатюры: Не удаётся сохранить эскиз по месту назначения

Results

---

Case 1 - Android 2.1 sound playback (volume tuning)

CSV dump

I2C analysis

EC request line

Ошибка создания миниатюры: Не удаётся сохранить эскиз по месту назначения

Mute line

Ошибка создания миниатюры: Не удаётся сохранить эскиз по месту назначения