Move from __init__.py to base.py so it can be imported.

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

Consistently use an enum for EPICSubtype (used later) and support the v2
EPICService intializer protocol used by AOP.

Signed-off-by: Eileen Yoon <[email protected]>

DCP only gets two reply types: a u32 retcode or a command reply. It
previously checked for retcode by checking length(data) == 4 and
assuming command otherwise. AOP can get other reply types (e.g. STRING
after probing device). It actually sends us the reply subtype in the
EPICSubHeader, so use that information and handle replies accordingly.

Signed-off-by: Eileen Yoon <[email protected]>

Much simpler than the command messages. We just write directly into the
TX ringbuffer.

Signed-off-by: Eileen Yoon <[email protected]>

Because AOP gets a lot of reports ;)

Signed-off-by: Eileen Yoon <[email protected]>

Default to version=4 as to not break DCP

Signed-off-by: Eileen Yoon <[email protected]>

Make the ringbuffer class robust to various block sizes to generalize to
both DCP and AOP.

The first three blocks of the ringbuffer is reserved for exchanging size,
rptr, wptr:

```
           bufsize      unk
00000000  00007e80 00070006 00000000 00000000 00000000 00000000 00000000 00000000
00000020  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000040  *   rptr
00000080  00000600 00000000 00000000 00000000 00000000 00000000 00000000 00000000
000000a0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
000000c0  *   wptr
00000100  00000680 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000120  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000140  *
```

Each block is spread out by some block_size multiple of 0x40 (step). The
0th block holds the size of the ringbuffer contents, the 1st block holds
the rptr, and the 2nd block holds the wptr. The actual contents of the
ringbuffer starts after the first three blocks, which will be
collectively called the "header".

However, this block_size isn't constant. DCP seems to consistently use
0x40, but AOP can use both 0x40/0x80. Since we're not given the block_size,
so wemust bootstrap it. Recall we are given the total size of the
rinbuffer in the mailbox message. Since we're always given the size of
the ringbuffer `bufsize` at offset +block_size * 0 (or simply 0), and we
can find the header size by subtracting `bufsize` from the total size.
Since we also know that the header is always 3 blocks wide, we can
divide the header size by 3 to obtain the block_size.

Signed-off-by: Eileen Yoon <[email protected]>

Otherwise the previous commit is way too confusing.

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

Output audio format still unknown, not sure if it's garbage (see lpai
commit) or some weird packed float encoding I'm not figuring out.

Signed-off-by: Eileen Yoon <[email protected]>

```
[syslog] * [ALSCT720.cpp:967]updateDynamicIntegrationParameters allAbove=0, anyBelow=1, threshold hit=0, lev
> 02:0x50000000000005 (TYPE=0x5, INDEX=0x5)
< 24:0x85000000000000
[als.als] Report REPORT/0xc4 #0
[als.als] Container:
    unk0 = 0xEC
    sequence = 4
    timestamp = 0x0000000019352268
    red = 11
    green = 18
    blue = 11
    clear = 40
    lux = 7.277451038360596
    unk_zero = 0
    status = 3
    gain = 256
    unk3 = 68
    unk4 = 35
    unk5 = 17874
    integration_time = 378080
< 02:0x50000000000006
[syslog] * [ALSCT720.cpp:454]handleInterrupt: result: 0 (status=0x3)
> 02:0x50000000000006 (TYPE=0x5, INDEX=0x6)
```

Signed-off-by: Eileen Yoon <[email protected]>

Signed-off-by: Eileen Yoon <[email protected]>

I'm getting garbage from the low-power audio input (lpai) mic which
exists solely for voicetrigger. The garbage specifically is `61 7b`
repeated. Obviously no voicetrigger report because there's nothing
useful in lpai output. I'm suspecting its an mca/clock issue (maybe even
SEP/permissions) because there's nothing suspicious from the aop RX/TX
IPC side.

```
[audio.audio] Report REPORT/0xee #0
[audio.audio] unknown report: 0xee
00000000  c5 96 20 01 00 00 00 00  9c f5 10 00 00 00 00 00  |.. .............|
00000010  b8 07 00 00 20 30 6e 69  01 00 00 00 43 02 00 00  |.... 0ni....C...|
00000020  00 00 00 00 c5 96 20 01  00 00 00 00 00 00 00 00  |...... .........|
00000030  a4 07 00 00 9a 07 00 00  61 7b 61 7b 61 7b 61 7b  |........a{a{a{a{|
00000040  61 7b 61 7b 61 7b 61 7b  61 7b 61 7b 61 7b 61 7b  |a{a{a{a{a{a{a{a{|
00000050  *
000007b0  61 7b 61 7b 61 7b 61 7b                           |a{a{a{a{        |
```

Signed-off-by: Eileen Yoon <[email protected]>