On Mon, 2015-04-20 at 21:55 +0100, Mark Brown wrote: > On Mon, Apr 20, 2015 at 02:22:24PM +0800, Koro Chen wrote: > > On Sat, 2015-04-18 at 18:51 +0100, Mark Brown wrote: > > > On Fri, Apr 10, 2015 at 04:14:09PM +0800, Koro Chen wrote: > > > > Ah, so the SRAM is directly memory mappable. Nice. But we have a > > > limited amount of it so need to allocate it to a device somehow based on > > > some factor I guess? > > > Yes, actually SRAM is only used for the main playback path (which is > > memif "DL1") to achieve low power in real use case. Maybe you think it's > > better to not describe this in the device tree, but to choose SRAM > > automatically if memif "DL1" is chosen? > > Since it's directly memory mappable is there actually any cost in > latency terms from using the SRAM in low latency cases (or did I misread > what the code was doing there)? If it can only be used with one > interface and there's no downside from using it... The SRAM size to be used is defined by params_buffer_bytes(params), not fixed (of course limited by the actual available SRAM size on HW), so the latency should be the same compared to a DRAM having the same size. The SRAM can be used by any memif, and that's why the plan was let DT make the decision. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
