On 02/02/2024 13:52, Nishanth Menon wrote: > On 11:47-20240202, Krzysztof Kozlowski wrote: >> On 01/02/2024 19:42, Brandon Brnich wrote: >>> Wave521c has capability to use SRAM carveout to store reference data with >>> purpose of reducing memory bandwidth. To properly use this pool, the driver >>> expects to have an sram and sram-size node. Without sram-size node, driver >>> will default value to zero, making sram node irrelevant. >> >> I am sorry, but what driver expects should not be rationale for new >> property. This justification suggests clearly it is not a property for DT. >> > > Yup, the argumentation in the commit message is from the wrong > perspective. bindings are OS agnostic hardware description, and what > driver does with the description is driver's problem. > > I will at least paraphrase my understanding: > In this case, however, the hardware block will limp along with > the usage of DDR (as is the current description), due to the > latencies involved for DDR accesses. However, the hardware block > has capability to use a substantially lower latency SRAM to provide > proper performance and hence for example, deal with higher resolution > data streams. This SRAM is instantiated at SoC level rather than > embedded within the hardware block itself. That sounds like OS policy. Why would different boards with the same component have this set differently? Based on amount of available memory? This, I believe, is runtime configuration because it might depend on user-space you run. Based on purpose (e.g. optimize for decoding or general usage)? Again, run-time because same hardware board can be used for different purposes. Best regards, Krzysztof
