Le jeudi 08 février 2024 à 11:52 +0530, Devarsh Thakkar a écrit : > I think even with the approach selected in [1] i.e. referring the > mmio-sram node using DT property, you can still use dynamic SRAM > allocation. > The driver can still allocate from global sram pool dynamically using > of_gen_pool API as being explained here [3] i.e allocate when first > instance is opened and free up later when no instances are running. > > But I agree with Nishanth's point too that we may not want to give all > of SRAM to VPU. For e.g. on AM62A we have 64KiB SRAM and a 1080p > use-case requires 48KiB and even higher for 4K so if there is another > peripheral who is referring this sram node, then it may not get enough > as VPU will hog the major chunk (or all) of it while it is running and > this is where an optional property like sram-size will help to cap the > max sram usage for VPU and so this helps especially on platforms with > limited SRAM availability. > > As I understand, the sram size allocation is dependent on resolution and > once programmed can't be changed until all instances of VPU are done, > and we can't predict how many instances user will launch and with what > resolutions. > > So here's the flow we had thought of some time back : > 1) Define worst case sram size (per 4K use-case as I believe that's the > max for CnM wave521c) as a macro in driver > > Then the condition for determining sram size to be allocated should be > as below : > > 2) When first instance of VPU is opened, allocate as per sram-size if > sram-size property is specified. > > 3) If sram-size is not specified then : > -> Allocate as per worst case size macro defined in driver from sram > pool, > -> If worst case size of SRAM > max SRAM size, then allocate > max SRAM size > > 4). When all of the instances of VPU are closed, then free up all > allocated SRAM. > > [3] : > https://wiki.analog.com/resources/tools-software/linuxdsp/docs/linux-kernel-and-drivers/sram Only issue here is that DT is not a use case configuration file. That DT parameter is meant for HW that simply cannot be operated without it. This is also edgy, because it also means that it should only be used if that information is not static and vary unpredictably per SoC, which seems generally unlikely. The Wave5 IP *can* work without it, so it should resort to something more dynamic. User configuration should be sorted out at the OS level. Nicolas
