aop: 13.5 bring up + mics + als + generalize afk/epic #381
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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]>
|
nvm this broke dcp. fixing it |
Signed-off-by: Eileen Yoon <[email protected]>
Signed-off-by: Eileen Yoon <[email protected]>
jannau
reviewed
Jan 20, 2024
proxyclient/m1n1/fw/afk/rbep.py
Outdated
|
|
||
| class AFKError(Exception): | ||
| pass | ||
| # TODO no one else but AOP uses AFKRingBuf right? |
There was a problem hiding this comment.
DCP uses AFKRingBuf on some endpoints via EPICEndpoint. Used in experiments/dcpext_iboot.py
There was a problem hiding this comment.
New commits don't break DCP experiments. DCP/AOP AFKRingbuf are too different to share (e.g. different EPIC header, different ring size, AOP also writes ptrs to DART and etc), everything else is fine though. I think we can move afk to soc/apple/ and just have fn pointers for the rbep r/w calls
eiln
changed the title
eiln
changed the title
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]>
|
@jannau I generalized AFK/EPIC code to both DCP and AOP. I feel like I should send these in a separate series but it obviously depends on the above. I think marcan's on holiday. From my tests (dcp/dcp_iboot; I can't test dptx/dcpext) it doesn't break DCP but I'd like to get your ack |
Signed-off-by: Eileen Yoon <[email protected]>
Signed-off-by: Eileen Yoon <[email protected]>
eiln
changed the title
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]>
|
Hi, could someone familiar with Asahi Linux and Apple audio help to move this PR or more generally the microphone support forward? |
marcan
force-pushed
the
main
branch
3 times, most recently
from
4f95305
to
95d67cf
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
aop_audio: stream hpai device (high power audio input) microphone samples from aop to admac. output seems to be 32-bit LE floats in groups of 3 (3 mic array)
aop_als: monitor/report red, green, blue, clear, lux, gain etc information from ambient light sensor (ALS)
Tested j293ap 13.5
Also includes afk/epic/rbep generalizations which hopefully don't break DCP