AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-23 12:46:04 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
abd7229626
linux_dsm_epyc7002/arch/arm/include/asm/device.h

40 lines
730 B
C
Raw Normal View History

Driver core: add dev_archdata to struct device Add arch specific dev_archdata to struct device Adds an arch specific struct dev_arch to struct device. This enables architecture to add specific fields to every device in the system, like DMA operation pointers, NUMA node ID, firmware specific data, etc... Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Andi Kleen <ak@suse.de> Acked-By: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-11 13:18:39 +07:00
/*
* Arch specific extensions to struct device
*
* This file is released under the GPLv2
*/
[ARM] Add a reference from struct device to the dma bounce info dmabounce keeps a per-device structure, and finds the correct structure by walking a list. Since architectures can now add fields to struct device, we can attach this structure direct to the struct device, thereby eliminating the code to search the list. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-12 17:28:24 +07:00
#ifndef ASMARM_DEVICE_H
#define ASMARM_DEVICE_H
Driver core: add dev_archdata to struct device Add arch specific dev_archdata to struct device Adds an arch specific struct dev_arch to struct device. This enables architecture to add specific fields to every device in the system, like DMA operation pointers, NUMA node ID, firmware specific data, etc... Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Andi Kleen <ak@suse.de> Acked-By: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-11 13:18:39 +07:00
[ARM] Add a reference from struct device to the dma bounce info dmabounce keeps a per-device structure, and finds the correct structure by walking a list. Since architectures can now add fields to struct device, we can attach this structure direct to the struct device, thereby eliminating the code to search the list. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-12 17:28:24 +07:00
struct dev_archdata {
#ifdef CONFIG_DMABOUNCE
struct dmabounce_device_info *dmabounce;
#endif
ARM: 7130/1: dev_archdata: add private iommu extension Add a private iommu pointer to the ARM-specific arch data in the device struct, which will be used to attach iommu-specific data to devices which require iommu support. Different iommu implementations (on different platforms) will attach different types of data to this pointer, so 'void *' is currently used (the downside is reduced typesafety). Note: ia64, x86 and sparc have this exact iommu extension as well, and if others are likely to adopt it too, we might want to consider adding this to the device struct itself directly. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-10-13 18:53:18 +07:00
#ifdef CONFIG_IOMMU_API
void *iommu; /* private IOMMU data */
#endif
ARM: dma-mapping: add support for IOMMU mapper This patch add a complete implementation of DMA-mapping API for devices which have IOMMU support. This implementation tries to optimize dma address space usage by remapping all possible physical memory chunks into a single dma address space chunk. DMA address space is managed on top of the bitmap stored in the dma_iommu_mapping structure stored in device->archdata. Platform setup code has to initialize parameters of the dma address space (base address, size, allocation precision order) with arm_iommu_create_mapping() function. To reduce the size of the bitmap, all allocations are aligned to the specified order of base 4 KiB pages. dma_alloc_* functions allocate physical memory in chunks, each with alloc_pages() function to avoid failing if the physical memory gets fragmented. In worst case the allocated buffer is composed of 4 KiB page chunks. dma_map_sg() function minimizes the total number of dma address space chunks by merging of physical memory chunks into one larger dma address space chunk. If requested chunk (scatter list entry) boundaries match physical page boundaries, most calls to dma_map_sg() requests will result in creating only one chunk in dma address space. dma_map_page() simply creates a mapping for the given page(s) in the dma address space. All dma functions also perform required cache operation like their counterparts from the arm linear physical memory mapping version. This patch contains code and fixes kindly provided by: - Krishna Reddy <vdumpa@nvidia.com>, - Andrzej Pietrasiewicz <andrzej.p@samsung.com>, - Hiroshi DOYU <hdoyu@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
2012-05-16 20:48:21 +07:00
#ifdef CONFIG_ARM_DMA_USE_IOMMU
struct dma_iommu_mapping *mapping;
xen/arm,arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..." The following commit: commit 815dd18788fe0d41899f51b91d0560279cf16b0d Author: Bart Van Assche <bart.vanassche@sandisk.com> Date: Fri Jan 20 13:04:04 2017 -0800 treewide: Consolidate get_dma_ops() implementations rearranges get_dma_ops in a way that xen_dma_ops are not returned when running on Xen anymore, dev->dma_ops is returned instead (see arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and include/linux/dma-mapping.h:get_dma_ops). Fix the problem by storing dev->dma_ops in dev_archdata, and setting dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from dev_archdata when needed. It also allows us to remove __generic_dma_ops from common headers. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Julien Grall <julien.grall@arm.com> Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Cc: <stable@vger.kernel.org> [4.11+] CC: linux@armlinux.org.uk CC: catalin.marinas@arm.com CC: will.deacon@arm.com CC: boris.ostrovsky@oracle.com CC: jgross@suse.com CC: Julien Grall <julien.grall@arm.com>
2017-04-14 04:04:21 +07:00
#endif
#ifdef CONFIG_XEN
const struct dma_map_ops *dev_dma_ops;
ARM: dma-mapping: add support for IOMMU mapper This patch add a complete implementation of DMA-mapping API for devices which have IOMMU support. This implementation tries to optimize dma address space usage by remapping all possible physical memory chunks into a single dma address space chunk. DMA address space is managed on top of the bitmap stored in the dma_iommu_mapping structure stored in device->archdata. Platform setup code has to initialize parameters of the dma address space (base address, size, allocation precision order) with arm_iommu_create_mapping() function. To reduce the size of the bitmap, all allocations are aligned to the specified order of base 4 KiB pages. dma_alloc_* functions allocate physical memory in chunks, each with alloc_pages() function to avoid failing if the physical memory gets fragmented. In worst case the allocated buffer is composed of 4 KiB page chunks. dma_map_sg() function minimizes the total number of dma address space chunks by merging of physical memory chunks into one larger dma address space chunk. If requested chunk (scatter list entry) boundaries match physical page boundaries, most calls to dma_map_sg() requests will result in creating only one chunk in dma address space. dma_map_page() simply creates a mapping for the given page(s) in the dma address space. All dma functions also perform required cache operation like their counterparts from the arm linear physical memory mapping version. This patch contains code and fixes kindly provided by: - Krishna Reddy <vdumpa@nvidia.com>, - Andrzej Pietrasiewicz <andrzej.p@samsung.com>, - Hiroshi DOYU <hdoyu@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
2012-05-16 20:48:21 +07:00
#endif
arm: introduce is_device_dma_coherent Introduce a boolean flag and an accessor function to check whether a device is dma_coherent. Set the flag from set_arch_dma_coherent_ops. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King <linux@arm.linux.org.uk>
2014-11-20 17:41:40 +07:00
bool dma_coherent;
[ARM] Add a reference from struct device to the dma bounce info dmabounce keeps a per-device structure, and finds the correct structure by walking a list. Since architectures can now add fields to struct device, we can attach this structure direct to the struct device, thereby eliminating the code to search the list. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-12 17:28:24 +07:00
};
ARM: 7082/1: platform_device: pdev_archdata: add omap_device pointer Add omap_device pointer to the ARM-specific arch data in the platform_device. This will be used to attach OMAP-specific device-data to the platform device with device lifetime. Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-09-07 03:04:10 +07:00
struct omap_device;
Driver Core: Add platform device arch data V3 Allow architecture specific data in struct platform_device V3. With this patch struct pdev_archdata is added to struct platform_device, similar to struct dev_archdata in found in struct device. Useful for architecture code that needs to keep extra data associated with each platform device. Struct pdev_archdata is different from dev.platform_data, the convention is that dev.platform_data points to driver-specific data. It may or may not be required by the driver. The format of this depends on driver but is the same across architectures. The structure pdev_archdata is a place for architecture specific data. This data is handled by architecture specific code (for example runtime PM), and since it is architecture specific it should _never_ be touched by device driver code. Exactly like struct dev_archdata but for platform devices. [rjw: This change is for power management mostly and that's why it goes through the suspend tree.] Signed-off-by: Magnus Damm <damm@igel.co.jp> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2009-07-08 18:21:31 +07:00
struct pdev_archdata {
ARM: 7082/1: platform_device: pdev_archdata: add omap_device pointer Add omap_device pointer to the ARM-specific arch data in the platform_device. This will be used to attach OMAP-specific device-data to the platform device with device lifetime. Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-09-07 03:04:10 +07:00
#ifdef CONFIG_ARCH_OMAP
struct omap_device *od;
#endif
Driver Core: Add platform device arch data V3 Allow architecture specific data in struct platform_device V3. With this patch struct pdev_archdata is added to struct platform_device, similar to struct dev_archdata in found in struct device. Useful for architecture code that needs to keep extra data associated with each platform device. Struct pdev_archdata is different from dev.platform_data, the convention is that dev.platform_data points to driver-specific data. It may or may not be required by the driver. The format of this depends on driver but is the same across architectures. The structure pdev_archdata is a place for architecture specific data. This data is handled by architecture specific code (for example runtime PM), and since it is architecture specific it should _never_ be touched by device driver code. Exactly like struct dev_archdata but for platform devices. [rjw: This change is for power management mostly and that's why it goes through the suspend tree.] Signed-off-by: Magnus Damm <damm@igel.co.jp> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2009-07-08 18:21:31 +07:00
};
ARM: dma-mapping: Add macro to_dma_iommu_mapping() This can be built without CONFIG_ARM_DMA_USE_IOMMU. Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2013-01-24 20:16:56 +07:00
#ifdef CONFIG_ARM_DMA_USE_IOMMU
#define to_dma_iommu_mapping(dev) ((dev)->archdata.mapping)
#else
#define to_dma_iommu_mapping(dev) NULL
#endif
[ARM] Add a reference from struct device to the dma bounce info dmabounce keeps a per-device structure, and finds the correct structure by walking a list. Since architectures can now add fields to struct device, we can attach this structure direct to the struct device, thereby eliminating the code to search the list. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-12 17:28:24 +07:00
#endif
Reference in New Issue Copy Permalink