> -----Original Message----- > From: Jassi Brar [mailto:jassisinghbrar@xxxxxxxxx] > Sent: Thursday, August 9, 2018 10:56 AM [...] > On Thu, Aug 9, 2018 at 7:52 AM, A.s. Dong <aisheng.dong@xxxxxxx> wrote: > > Hi Jassi, > > > > Do you have any comments about this reply? > > > I did read your post. And my opinion isn't changed. If mailbox is new to you, > please try to see how other subsystems works, especially SPI, I2C and DMA. > Okay. What's your comments about the known issues if doing that way? 1) Many unnecessary and meaningless interrupts handling of Tx and RX 2) Performance downgrading A 4 word SCU MSG may need 8 interrupts to handle which terribly slow down the speed. (Interrupt latency will be terrible if many). SCU msg are mostly handled within 10 us. 3) Complex RX flow in order to align with framework design Are you referring to them as not a real issue? Or even they're issues/limitations, you would still prefer multi channels way In order to be consistent with mailbox subsystem by sacrificing the performance drop? And to be clear, the working flow you want is exactly as follows, right? Sending Word 0 -> Chan 0 interrupt -> (meaningless) Sending Word 1 -> Chan1 interrupt -> (meaningless) Sending Word 2 -> Chan2 interrupt -> (meaningless) Sending Word 3 -> Chan3 interrupt-> (meaningless) Sending Word 4 on Chan 0 again -> Wait for Chan 0 interrupt (meaningless) -> ... Then waiting for Rx: Chan 0 Rx interrupt -> Read Word 0 -> (Then we know response size here) Chan 1 Rx interrupt -> Read Word 1 -> Chan 2 Rx interrupt -> Read Word 2 -> Chan 3 Rx interrupt -> Read Word 3 -> (If msg size > 4 words) Chan 0 Rx interrupt -> Read Word 4 Regards Dong Aisheng > Thanks. ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
