Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-05 20:54:31 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/include/iotrace.h

157 lines
3.9 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
/* SPDX-License-Identifier: GPL-2.0+ */
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
/*
* Copyright (c) 2014 Google, Inc.
*/
#ifndef __IOTRACE_H
#define __IOTRACE_H
iotrace: move record definitons to header file The header definitions are needed for reading record information in cmd/iotrace.c Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-06-08 17:53:25 +00:00
//#include <common.h>
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
#include <linux/types.h>
iotrace: move record definitons to header file The header definitions are needed for reading record information in cmd/iotrace.c Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-06-08 17:53:25 +00:00
/* Support up to the machine word length for now */
typedef ulong iovalue_t;
enum iotrace_flags {
IOT_8 = 0,
IOT_16,
IOT_32,
IOT_READ = 0 << 3,
IOT_WRITE = 1 << 3,
};
/**
* struct iotrace_record - Holds a single I/O trace record
*
* @flags: I/O access type
* @timestamp: Timestamp of access
* @addr: Address of access
* @value: Value written or read
*/
struct iotrace_record {
enum iotrace_flags flags;
u64 timestamp;
phys_addr_t addr;
iovalue_t value;
};
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
/*
* This file is designed to be included in arch/<arch>/include/asm/io.h.
* It redirects all IO access through a tracing/checksumming feature for
* testing purposes.
*/
#if defined(CONFIG_IO_TRACE) && !defined(IOTRACE_IMPL) && \
!defined(CONFIG_SPL_BUILD)
#undef readl
#define readl(addr) iotrace_readl((const void *)(addr))
#undef writel
trace: Remove the const from write functions The write functions do actually change the contents of memory so it is not correct to use 'const'. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:56:57 +00:00
#define writel(val, addr) iotrace_writel(val, (void *)(addr))
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
#undef readw
#define readw(addr) iotrace_readw((const void *)(addr))
#undef writew
trace: Remove the const from write functions The write functions do actually change the contents of memory so it is not correct to use 'const'. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:56:57 +00:00
#define writew(val, addr) iotrace_writew(val, (void *)(addr))
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
#undef readb
Allow iotrace byte access to use an address of any size If an address is used with readb() and writeb() which is smaller than the expected size (e.g. 32-bit value on a machine with 64-bit addresses), a warning results. Fix this by adding a cast. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-05-01 17:35:53 +00:00
#define readb(addr) iotrace_readb((const void *)(uintptr_t)addr)
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
#undef writeb
trace: Remove the const from write functions The write functions do actually change the contents of memory so it is not correct to use 'const'. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:56:57 +00:00
#define writeb(val, addr) iotrace_writeb(val, (void *)(uintptr_t)addr)
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
#endif
/* Tracing functions which mirror their io.h counterparts */
u32 iotrace_readl(const void *ptr);
trace: Remove the const from write functions The write functions do actually change the contents of memory so it is not correct to use 'const'. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:56:57 +00:00
void iotrace_writel(ulong value, void *ptr);
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
u16 iotrace_readw(const void *ptr);
trace: Remove the const from write functions The write functions do actually change the contents of memory so it is not correct to use 'const'. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:56:57 +00:00
void iotrace_writew(ulong value, void *ptr);
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
u8 iotrace_readb(const void *ptr);
trace: Remove the const from write functions The write functions do actually change the contents of memory so it is not correct to use 'const'. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:56:57 +00:00
void iotrace_writeb(ulong value, void *ptr);
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
/**
* iotrace_reset_checksum() - Reset the iotrace checksum
*/
void iotrace_reset_checksum(void);
/**
* iotrace_get_checksum() - Get the current checksum value
*
* @return currect checksum value
*/
u32 iotrace_get_checksum(void);
iotrace: add IO region limit When dealing with a lot of IO regions, sometimes it makes sense only to trace a specific one. This patch adds support for region limits. If region is not set, the iotrace works the same as it was. If region is set, the iotrace only logs io operation that falls in the defined region. Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-05-30 20:09:58 +00:00
/**
* iotrace_set_region() - Set whether iotrace is limited to a specific
* io region.
*
* Defines the address and size of the limited region.
*
* @start: address of the beginning of the region
* @size: size of the region in bytes.
*/
void iotrace_set_region(ulong start, ulong size);
/**
* iotrace_reset_region() - Reset the region limit
*/
void iotrace_reset_region(void);
/**
* iotrace_get_region() - Get region information
*
* @start: Returns start address of region
* @size: Returns size of region in bytes
*/
void iotrace_get_region(ulong *start, ulong *size);
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
/**
* iotrace_set_enabled() - Set whether iotracing is enabled or not
*
* This controls whether the checksum is updated and a trace record added
* for each I/O access.
*
* @enable: true to enable iotracing, false to disable
*/
void iotrace_set_enabled(int enable);
/**
* iotrace_get_enabled() - Get whether iotracing is enabled or not
*
* @return true if enabled, false if disabled
*/
int iotrace_get_enabled(void);
/**
* iotrace_set_buffer() - Set position and size of iotrace buffer
*
* Defines where the iotrace buffer goes, and resets the output pointer to
* the start of the buffer.
*
* The buffer can be 0 size in which case the checksum is updated but no
* trace records are writen. If the buffer is exhausted, the offset will
* continue to increase but not new data will be written.
*
* @start: Start address of buffer
* @size: Size of buffer in bytes
*/
void iotrace_set_buffer(ulong start, ulong size);
/**
* iotrace_get_buffer() - Get buffer information
*
* @start: Returns start address of buffer
iotrace: fix behaviour when buffer is full Don't continue updating the offset when buffer is full. When the buffer size exhausts and there's no space left to write warn the user and update only the needed size and not both the offset and needed size. Add needed buffer size information in the iotrace command. Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
2018-06-08 17:53:27 +00:00
* @size: Returns actual size of buffer in bytes
* @needed_size: Returns needed size of buffer in bytes
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
* @offset: Returns the byte offset where the next output trace record will
* @count: Returns the number of trace records recorded
* be written (or would be if the buffer was large enough)
*/
iotrace: fix behaviour when buffer is full Don't continue updating the offset when buffer is full. When the buffer size exhausts and there's no space left to write warn the user and update only the needed size and not both the offset and needed size. Add needed buffer size information in the iotrace command. Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
2018-06-08 17:53:27 +00:00
void iotrace_get_buffer(ulong *start, ulong *size, ulong *needed_size, ulong *offset, ulong *count);
Add an I/O tracing feature When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-12 05:29:41 +00:00
#endif /* __IOTRACE_H */
Reference in a new issue Copy permalink