Re: [PATCH] media: imx-jpeg: Add support for descriptor allocation from SRAM

[Marek Vasut <marek.vasut@mailbox.org>]

On 8/22/25 2:58 AM, Ming Qian(OSS) wrote:

Hello Ming,

sorry for the very late reply.

>>>>> Using sram instead of dram only improves timing, but doesn't 
>>>>> completely circumvent the hardware bug
>>>> Does it make sense to upstream this patch anyway ?
>>>
>>> I think this patch is helpful.
>>>
>>> But so far, we don't have any SRAM resources for jpeg.
>>> The i.MX95 does have sram, but it is very limited, and it has been
>>> assigned to arm_scmi and VPU.
>>
>> I found out the SM can work fine with only 192 kiB of SRAM instead of 
>> 256 kiB of SRAM. That frees up 64 kiB of SRAM for NS world. Each JPEG 
>> IP needs 20544 Bytes for descriptors, which fits into those freed up 
>> 64 kiB of SRAM.
>>
>> The alternative would be to handle those AXI read errors and restart 
>> the encoding. I always observe these errors in the CONFIG phase of 
>> encoding. Do you happen to have any details of this issue you could 
>> share ? Do you know whether the problem occurs only during CONFIG 
>> phase, or also during image read phase ?
>>
>> If the problem occurs only during CONFIG phase of encoding, it would 
>> be easy to retrigger the CONFIG I think. If the problem occurs also 
>> during image read, that might need some more creative fix.
>>
> 
> This is a hardware bug that affects not only the jpeg encoder but also
> the jpeg decoder.
> 
> This issue occurs under conditions of high backpressure on the AXI bus,
> meaning the latency on the write/response channel is high, while the
> read channel latency remains low.
> 
> When error occurs during CONFIG phase of encoder, it will trigger a
> interrupt. But in other phase, there is no interrupt, then the running
> job is stalled until timeout.
I sent a V2 now, thank you for the clarification, I tried to include 
that in the commit message too.