From: "Shah, Tanmay" <tanmays@amd.com>
To: Bjorn Andersson <andersson@kernel.org>,
Jassi Brar <jassisinghbrar@gmail.com>
Cc: <linux-kernel@vger.kernel.org>,
<linux-remoteproc@vger.kernel.org>, <tanmay.shah@amd.com>,
<mathieu.poirier@linaro.org>
Subject: Re: [PATCH] mailbox: add API to query available TX queue slots
Date: Wed, 4 Mar 2026 09:09:28 -0600 [thread overview]
Message-ID: <6fd87385-1b8b-4b1e-b27f-b06f81096b23@amd.com> (raw)
In-Reply-To: <nelghqxyuwelah3op6ls6pflm5ujwayfzuchode44vjmagymmv@ptisap64ewkl>
On 2/26/2026 9:53 PM, Bjorn Andersson wrote:
> On Mon, Feb 23, 2026 at 06:35:16PM -0600, Jassi Brar wrote:
>> On Mon, Feb 23, 2026 at 9:29 AM Bjorn Andersson <andersson@kernel.org> wrote:
>>>
>>> On Mon, Feb 09, 2026 at 05:44:30PM -0600, jassisinghbrar@gmail.com wrote:
>>>> From: Jassi Brar <jassisinghbrar@gmail.com>
>>>>
>>>> Clients sometimes need to know whether the mailbox TX queue has room
>>>> before posting a new message.
>>>
>>> This is rather vague, could you be more specific?
>>>
>>>> Rather than exposing internal queue state
>>>> through a struct field, provide a proper accessor function that returns
>>>> the number of available slots for a given channel.
>>>>
>>>> This lets clients choose to back off when the queue is full instead of
>>>> hitting the -ENOBUFS error path and the misleading "Try increasing
>>>> MBOX_TX_QUEUE_LEN" warning.
>>>>
>>>
>>> In the event that we're using the mailbox framework as a doorbell, I
>>> presume that the queue is full of duplicate rings already - so backing
>>> off it perfectly fine.
>>>
>>> But in the case where the client actually uses the interface to convey
>>> data, what is the expected way for the client to know when to make
>>> another attempt?
>>>
>> Whatever the client is currently using. It just backs off for another
>> such signal when mbox_chan_tx_slots_available() returns 0.
>> If a client submits periodically, it will back off for another period.
>> If a client submits upon receiving ack packet for last submission, it
>> will back off until it gets another ack packet.
>>
>
> Thanks for clarifying.
>
Hi Jassi,
What is the next step for this patch? When it is expected to merge?
Thank You,
Tanmay
> Regards,
> Bjorn
>
>> Cheers!
>> Jassi
next prev parent reply other threads:[~2026-03-04 15:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 23:44 jassisinghbrar
2026-02-16 18:38 ` Shah, Tanmay
2026-02-23 15:29 ` Bjorn Andersson
2026-02-23 16:06 ` Shah, Tanmay
2026-02-24 0:35 ` Jassi Brar
2026-02-27 3:53 ` Bjorn Andersson
2026-03-04 15:09 ` Shah, Tanmay [this message]
2026-03-29 16:37 ` Jassi Brar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6fd87385-1b8b-4b1e-b27f-b06f81096b23@amd.com \
--to=tanmays@amd.com \
--cc=andersson@kernel.org \
--cc=jassisinghbrar@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=tanmay.shah@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®