gs201 felix: no mainline AOC (Always-On Compute) coprocessor driver

[ccrutchf]

What

The Pixel Fold (gs201) has a Cortex-M4-based Always-On Compute (AOC) coprocessor at platform device 19000000.aoc. AOSP has a substantial driver tree at private/google-modules/aoc/ that handles firmware upload, mailbox/IPC, and the audio/sensor/hotword services on top. Mainline has nothing.

Symptom

In our junkyard-boot-img pipeline, .install_vendor_firmware rsyncs aoc.bin to /vendor/firmware/, and an overlay customservice runs:

echo aoc.bin > /sys/devices/platform/19000000.aoc/firmware

On mainline that sysfs path doesn't exist, so the write fails silently. AOC stays dormant.

Impact

AOC is a post-boot subsystem (audio routing, sensor hub, hotword detection). The kernel boots cleanly to multi-user.target without it — not a boot blocker. But on the felix bring-up roadmap, no AOC means:

• No haptic playback through the audio path (CS40L26 codec is partly AOC-mediated — see also the deferred haptic bring-up note)
• No hotword / always-on sensors
• Audio routing is degraded (some paths go through AOC)

Scope

Multi-month port. The AOSP driver is ~14k lines without the integrated firmware blob. Realistic milestones:

1. Mailbox / IPC binding for the AOC <-> AP channel
2. Firmware load via standard request_firmware (not the sysfs trigger)
3. Service stubs (audio, sensor, hotword) — likely staged

Why filing now

So that we don't keep tripping over the dormant /sys/devices/platform/19000000.aoc/firmware write across new bring-up sessions, and so the dependency chain for haptic / audio is visible.