[PATCH] remoteproc: xlnx: do not send new mailbox notification

[PATCH] remoteproc: xlnx: do not send new mailbox notification

[Tanmay Shah]

Only write a new message to the tx mbox queue if slot is available in
the tx queue. If queue is full, then do not send new mbox notification.

Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---

Depends on: https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@gmail.com/T/#u

 drivers/remoteproc/xlnx_r5_remoteproc.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index bd619a6c42aa..622de733c929 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -332,7 +332,10 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
 	int ret;
 
 	ipi = r5_core->ipi;
-	if (!ipi)
+	if (!ipi || !ipi->tx_chan)
+		return;
+
+	if (mbox_chan_tx_slots_available(ipi->tx_chan) == 0)
 		return;
 
 	mb_msg = (struct zynqmp_ipi_message *)ipi->tx_mc_buf;

base-commit: 462799c088e71b2b8a511c2a9649420fcb569ab7
-- 
2.34.1

Re: [PATCH] remoteproc: xlnx: do not send new mailbox notification

[Shah, Tanmay]

Hi Mathieu,

On 2/19/2026 4:43 PM, Tanmay Shah wrote:
> Only write a new message to the tx mbox queue if slot is available in
> the tx queue. If queue is full, then do not send new mbox notification.
> 
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> 
> Depends on: https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@gmail.com/T/#u
> 

This dependency is now merged in the linux-next branch.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/mailbox?id=57df858a46f0a4cc104716e0ec88864e5c386ca4

I don't know what's the process, but can we merge this patch and
dependency both in the for-next branch?

Thanks,
Tanmay

>  drivers/remoteproc/xlnx_r5_remoteproc.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index bd619a6c42aa..622de733c929 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -332,7 +332,10 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
>  	int ret;
>  
>  	ipi = r5_core->ipi;
> -	if (!ipi)
> +	if (!ipi || !ipi->tx_chan)
> +		return;
> +
> +	if (mbox_chan_tx_slots_available(ipi->tx_chan) == 0)
>  		return;
>  
>  	mb_msg = (struct zynqmp_ipi_message *)ipi->tx_mc_buf;
> 
> base-commit: 462799c088e71b2b8a511c2a9649420fcb569ab7

Re: [PATCH] remoteproc: xlnx: do not send new mailbox notification

[Mathieu Poirier]

On Thu, Feb 19, 2026 at 02:43:30PM -0800, Tanmay Shah wrote:
> Only write a new message to the tx mbox queue if slot is available in
> the tx queue. If queue is full, then do not send new mbox notification.
> 
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> 
> Depends on: https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@gmail.com/T/#u
> 
>  drivers/remoteproc/xlnx_r5_remoteproc.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index bd619a6c42aa..622de733c929 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -332,7 +332,10 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
>  	int ret;
>  
>  	ipi = r5_core->ipi;
> -	if (!ipi)
> +	if (!ipi || !ipi->tx_chan)
> +		return;
> +
> +	if (mbox_chan_tx_slots_available(ipi->tx_chan) == 0)
>  		return;
>

Is see 3 options to handle this situation:

(1) I can provide an RB for this patch and Jassi picks it up in his tree.  The
downside is that if a subsequent submission conflicts with this change, we have
to wait for the next cycle.  In that case:

Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>

(2) Jassi provides me with a pull request to bring the patch in the
rproc-next tree.

(3) I pick it up in the rproc-next tree in 5 weeks when v7.1-rc1 comes out.
  
>  	mb_msg = (struct zynqmp_ipi_message *)ipi->tx_mc_buf;
> 
> base-commit: 462799c088e71b2b8a511c2a9649420fcb569ab7
> -- 
> 2.34.1
> 

Re: [PATCH] remoteproc: xlnx: do not send new mailbox notification

[Shah, Tanmay]

On 3/16/2026 10:18 AM, Mathieu Poirier wrote:
> On Thu, Feb 19, 2026 at 02:43:30PM -0800, Tanmay Shah wrote:
>> Only write a new message to the tx mbox queue if slot is available in
>> the tx queue. If queue is full, then do not send new mbox notification.
>>
>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>> ---
>>
>> Depends on: https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@gmail.com/T/#u
>>
>>  drivers/remoteproc/xlnx_r5_remoteproc.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> index bd619a6c42aa..622de733c929 100644
>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> @@ -332,7 +332,10 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
>>  	int ret;
>>  
>>  	ipi = r5_core->ipi;
>> -	if (!ipi)
>> +	if (!ipi || !ipi->tx_chan)
>> +		return;
>> +
>> +	if (mbox_chan_tx_slots_available(ipi->tx_chan) == 0)
>>  		return;
>>
> 
> Is see 3 options to handle this situation:
> 
> (1) I can provide an RB for this patch and Jassi picks it up in his tree.  The
> downside is that if a subsequent submission conflicts with this change, we have
> to wait for the next cycle.  In that case:
> 
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> 
> (2) Jassi provides me with a pull request to bring the patch in the
> rproc-next tree.
> 

Hi Mathieu,

I am curious what do you mean by pull request?

Jassi had included remoteproc mailing list when sent the original patch
here:
https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@gmail.com/

Since then no other change was introduced in that patch. Isn't it enough
for it to pick-up for rproc-next? I am just asking from the process
point of view, what should have been done differently?

If all looks good, then I think you can pick up original patch from him
for rproc-next, as the same patch got merged in the linux-next.

Thanks,
Tanmay

> (3) I pick it up in the rproc-next tree in 5 weeks when v7.1-rc1 comes out.
>   
>>  	mb_msg = (struct zynqmp_ipi_message *)ipi->tx_mc_buf;
>>
>> base-commit: 462799c088e71b2b8a511c2a9649420fcb569ab7
>> -- 
>> 2.34.1
>>

Re: [PATCH] remoteproc: xlnx: do not send new mailbox notification

[Mathieu Poirier]

On Mon, Mar 16, 2026 at 11:29:49AM -0500, Shah, Tanmay wrote:
> 
> 
> On 3/16/2026 10:18 AM, Mathieu Poirier wrote:
> > On Thu, Feb 19, 2026 at 02:43:30PM -0800, Tanmay Shah wrote:
> >> Only write a new message to the tx mbox queue if slot is available in
> >> the tx queue. If queue is full, then do not send new mbox notification.
> >>
> >> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> >> ---
> >>
> >> Depends on: https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@gmail.com/T/#u
> >>
> >>  drivers/remoteproc/xlnx_r5_remoteproc.c | 5 ++++-
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> index bd619a6c42aa..622de733c929 100644
> >> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> @@ -332,7 +332,10 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
> >>  	int ret;
> >>  
> >>  	ipi = r5_core->ipi;
> >> -	if (!ipi)
> >> +	if (!ipi || !ipi->tx_chan)
> >> +		return;
> >> +
> >> +	if (mbox_chan_tx_slots_available(ipi->tx_chan) == 0)
> >>  		return;
> >>
> > 
> > Is see 3 options to handle this situation:
> > 
> > (1) I can provide an RB for this patch and Jassi picks it up in his tree.  The
> > downside is that if a subsequent submission conflicts with this change, we have
> > to wait for the next cycle.  In that case:
> > 
> > Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> > 
> > (2) Jassi provides me with a pull request to bring the patch in the
> > rproc-next tree.
> > 
> 
> Hi Mathieu,
> 
> I am curious what do you mean by pull request?
>
> Jassi had included remoteproc mailing list when sent the original patch
> here:
> https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@gmail.com/
> 
> Since then no other change was introduced in that patch. Isn't it enough
> for it to pick-up for rproc-next? I am just asking from the process
> point of view, what should have been done differently?
> 
> If all looks good, then I think you can pick up original patch from him
> for rproc-next, as the same patch got merged in the linux-next.

If I apply Jassi's patch to rproc-next, we'll end up with the same patch with
two different SHA1s in two different trees, something that is not compatible
with the linux-next process.  To avoid this kind of situation we work with pull
requests, which doesn't change the patch's SHA1.

Since preparing a pull request takes time that Jassi may not have, I provided my
R-B for your patch, allowing him to merge it in his mailbox tree.

> 
> Thanks,
> Tanmay
> 
> > (3) I pick it up in the rproc-next tree in 5 weeks when v7.1-rc1 comes out.
> >   
> >>  	mb_msg = (struct zynqmp_ipi_message *)ipi->tx_mc_buf;
> >>
> >> base-commit: 462799c088e71b2b8a511c2a9649420fcb569ab7
> >> -- 
> >> 2.34.1
> >>
> 

Re: [PATCH] remoteproc: xlnx: do not send new mailbox notification

[Shah, Tanmay]

On 3/17/2026 10:14 AM, Mathieu Poirier wrote:
> On Mon, Mar 16, 2026 at 11:29:49AM -0500, Shah, Tanmay wrote:
>>
>>
>> On 3/16/2026 10:18 AM, Mathieu Poirier wrote:
>>> On Thu, Feb 19, 2026 at 02:43:30PM -0800, Tanmay Shah wrote:
>>>> Only write a new message to the tx mbox queue if slot is available in
>>>> the tx queue. If queue is full, then do not send new mbox notification.
>>>>
>>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>>> ---
>>>>
>>>> Depends on: https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@gmail.com/T/#u
>>>>
>>>>  drivers/remoteproc/xlnx_r5_remoteproc.c | 5 ++++-
>>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>>> index bd619a6c42aa..622de733c929 100644
>>>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>>>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>>> @@ -332,7 +332,10 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
>>>>  	int ret;
>>>>  
>>>>  	ipi = r5_core->ipi;
>>>> -	if (!ipi)
>>>> +	if (!ipi || !ipi->tx_chan)
>>>> +		return;
>>>> +
>>>> +	if (mbox_chan_tx_slots_available(ipi->tx_chan) == 0)
>>>>  		return;
>>>>
>>>
>>> Is see 3 options to handle this situation:
>>>
>>> (1) I can provide an RB for this patch and Jassi picks it up in his tree.  The
>>> downside is that if a subsequent submission conflicts with this change, we have
>>> to wait for the next cycle.  In that case:
>>>
>>> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>
>>> (2) Jassi provides me with a pull request to bring the patch in the
>>> rproc-next tree.
>>>
>>
>> Hi Mathieu,
>>
>> I am curious what do you mean by pull request?
>>
>> Jassi had included remoteproc mailing list when sent the original patch
>> here:
>> https://lore.kernel.org/linux-remoteproc/20260209234430.512492-1-jassisinghbrar@gmail.com/
>>
>> Since then no other change was introduced in that patch. Isn't it enough
>> for it to pick-up for rproc-next? I am just asking from the process
>> point of view, what should have been done differently?
>>
>> If all looks good, then I think you can pick up original patch from him
>> for rproc-next, as the same patch got merged in the linux-next.
> 
> If I apply Jassi's patch to rproc-next, we'll end up with the same patch with
> two different SHA1s in two different trees, something that is not compatible
> with the linux-next process.  To avoid this kind of situation we work with pull
> requests, which doesn't change the patch's SHA1.
> 
> Since preparing a pull request takes time that Jassi may not have, I provided my
> R-B for your patch, allowing him to merge it in his mailbox tree.
> 

Thanks Mathieu,

It makes sense now. I appreciate your response.
It looks like then option-3 is the cleanest solution then.

I can wait now as I have your R-B anyway now.

I will rebase the patch after 5-weeks on the remoteproc for-next branch.
If I see the merge conflict, then I will resend the patch.

Thanks,
Tanmay

>>
>> Thanks,
>> Tanmay
>>
>>> (3) I pick it up in the rproc-next tree in 5 weeks when v7.1-rc1 comes out.
>>>   
>>>>  	mb_msg = (struct zynqmp_ipi_message *)ipi->tx_mc_buf;
>>>>
>>>> base-commit: 462799c088e71b2b8a511c2a9649420fcb569ab7
>>>> -- 
>>>> 2.34.1
>>>>
>>