soc/mtk_adsp: Remove "msg" API

This is a feature of the 8195 DSP only, which is used only vestigially
by SOF to store data that nothing reads.  The Linux kernel on the
other side uses a shared driver for all 81xx devices, which does not
expose the feature.  It seems to work, but it's not worth maintaining
a driver in tree for legacy hardware that will never use it.

Signed-off-by: Andy Ross <andyross@google.com>
This commit is contained in:
Andy Ross 2024-06-14 11:44:37 -07:00 committed by Benjamin Cabé
commit cdd4cbcc67
3 changed files with 1 additions and 34 deletions

View file

@ -65,25 +65,6 @@ void mtk_adsp_mbox_set_handler(const struct device *mbox, uint32_t chan,
}
}
void mtk_adsp_mbox_set_msg(const struct device *mbox, uint32_t idx, uint32_t val)
{
const struct mbox_cfg *cfg = ((struct device *)mbox)->config;
if (idx < MTK_ADSP_MBOX_MSG_WORDS) {
cfg->mbox->out_msg[idx] = val;
}
}
uint32_t mtk_adsp_mbox_get_msg(const struct device *mbox, uint32_t idx)
{
const struct mbox_cfg *cfg = ((struct device *)mbox)->config;
if (idx < MTK_ADSP_MBOX_MSG_WORDS) {
return cfg->mbox->in_msg[idx];
}
return 0;
}
void mtk_adsp_mbox_signal(const struct device *mbox, uint32_t chan)
{
const struct mbox_cfg *cfg = ((struct device *)mbox)->config;

View file

@ -23,13 +23,6 @@ typedef void (*mtk_adsp_mbox_handler_t)(const struct device *mbox, void *arg);
void mtk_adsp_mbox_set_handler(const struct device *mbox, uint32_t chan,
mtk_adsp_mbox_handler_t handler, void *arg);
/* Mailbox hardware has an array of unstructured "message" data in
* each direction. Any value can be placed in the registers.
*/
#define MTK_ADSP_MBOX_MSG_WORDS 5
void mtk_adsp_mbox_set_msg(const struct device *mbox, uint32_t idx, uint32_t val);
uint32_t mtk_adsp_mbox_get_msg(const struct device *mbox, uint32_t idx);
/* Signal an interrupt on the specified channel for the other side */
void mtk_adsp_mbox_signal(const struct device *mbox, uint32_t chan);

View file

@ -69,10 +69,7 @@ static void mbox_fn(const struct device *mbox, void *arg)
/* Test in/out interrupts from the host. This relies on a SOF driver
* on the host, which has the behavior of "replying" with an interrupt
* on mbox1 after receiving a "command" on mbox0 (you can also see it
* whine about the invalid IPC message in the kernel logs). SOF
* ignores the message bytes (it uses a DRAM area instead), so we just
* write them blindly. It's only a partial test of the hardware, but
* easy to run and exercises the core functionality.
* whine about the invalid IPC message in the kernel logs).
*
* Note that there's a catch: SOF's "reply" comes after a timeout
* (it's an invalid command, afterall) which is 165 seconds! But the
@ -82,10 +79,6 @@ ZTEST(mtk_adsp, mbox)
{
mtk_adsp_mbox_set_handler(MBOX1, 1, mbox_fn, NULL);
for (int i = 0; i < MTK_ADSP_MBOX_MSG_WORDS; i++) {
mtk_adsp_mbox_set_msg(MBOX0, i, 0x01010100 | i);
}
/* First signal the host with a reply on the second channel,
* that effects a reply to anything it thinks it might have
* sent us