On Mon, Jan 13, 2025 at 3:34 AM Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> wrote: > On 1/12/25 4:59 PM, Jassi Brar wrote: > > >>>>> Then I updated the mailbox core to allow clients to request channels by > >>>>> passing some args containing channel identifiers to the controllers, > >>>>> that the controllers xlate() using their own method. > >>>>> > >>>> This is unnecessary. > >>>> If you don't pass the doorbell number from DT, each channel populated > >>>> by the driver is just a s/w construct or a 'virtual' channel. Make use > >>>> of 'void *data' in send_data() to specify the doorbell. > >>>> > >>> I think this introduces concurrency problems if the channel identifiers > >>> passed by 'void *data' don't match the virtual channel used for sending > >>> the messages. Do we want to allow this? > >>> > >>> Also, if we use 'void *data' to pass channel identifiers, the channel > >>> checks will have to be made at send_data() time. Thus if passing wrong > >>> channel type for example, the mailbox client will eventually get a > >>> -ENOBUFS and a "Try increasing MBOX_TX_QUEUE_LEN" message, which I find > >>> misleading. > >> > >> Shall I still use 'void *data' to pass channel identifiers through > >> send_data()? I'd like to respin everything. > >> > > Yes, please do. > > > > What shall I do in driver's of_xlate method, always return > &mbox->chans[0], as bcm2835 does? > No, not the first. The first _free_ channel. One way to identify a free channel is by checking mbox_chan.cl is NULL. thnx
