On 2 February 2016 at 02:31, Al Grant Al.Grant@arm.com wrote:
Hi,
STM has 16 channels per 4KB page, (or 256 channels per 64KB page for the biggest page granule in ARMv8). And the STM supports up to 65k channels, so up to 4096 separate pages (AArch32 with 4KB pages) or 256 separate pages (AArch64 with 64KB pages), using 16MB of address space. This allows the STM channel space to be partitioned up between independent software agents. However implementers often want to allocate a smaller amount of physical space to STM.
Mapping just one page of STM is all right when there is just one agent (e.g. low-level firmware) but if there are multiple software agents it creates a problem. Is there now enough documentation on how the Linux STM driver will map pages of STM channel space, for us to use this in setting expectations on how much should be physically mapped in?
Sorry, I don't understand the question clearly enough to give you an accurate answer. Right now the CS-STM driver reads the amount of available channels in STMDEVID::NUMSP to map the right amount of space. That value can be tuned in the device tree by specifying the amount of IO space allocated to that device - the boot code will take the minimum of the two values. As such the amount of mapped space can be fined tune in the DT.
Get back to me if you still have questions on that topic.
In particular, will the driver support mapping parts of STM channel space into userspace processes, allowing userspace to generate STM messages by storing directly into channel space without going via the kernel?
The generic STM API has an optional mmio_addr() callback used especially for mmap() operations in user space, allowing to bypass the kernel when writing to channels. The CS-STM driver that has just been released for public review doesn't implement this interface (simply because we haven't done it yet).
Thanks, Mathieu
Al IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight