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

[Ming Qian(OSS)]

On 8/21/2025 8:01 PM, Marek Vasut wrote:
> On 8/21/25 11:42 AM, Ming Qian(OSS) wrote:
> 
> Hello Ming,
> 
>>>> 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.

Regards,
Ming

>> This patch makes the jpeg can support SRAM. Maybe in some scenarios, we
>> can assign the SRAM to jpeg instead of VPU.
>>
>> So for me, I welcome this patch.
> 
> Thank you
>