search for: resource_size_t

...ure contains firmware framebuffer + * + * @base: the aperture's base address in physical memory + * @size: aperture size in bytes + * + * Returns: + * true on if there is a firmware framebuffer belong to the aperture passed in, + * or false otherwise. + */ +bool drm_aperture_contain_firmware_fb(resource_size_t base, resource_size_t size) +{ + return aperture_contain_firmware_fb(base, base + size); +} +EXPORT_SYMBOL(drm_aperture_contain_firmware_fb); diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c index 561be8feca96..5a5422cec669 100644 --- a/drivers/video/aperture.c +++ b/drivers/video/a...

...ions(-) diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 6c2b06fe8beb7..52a91f5fa1a36 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -248,8 +248,8 @@ extern struct resource * __request_region(struct resource *, extern void __release_region(struct resource *, resource_size_t, resource_size_t); #ifdef CONFIG_MEMORY_HOTREMOVE -extern int release_mem_region_adjustable(struct resource *, resource_size_t, - resource_size_t); +extern void release_mem_region_adjustable(struct resource *, resource_size_t, + resource_size_t); #endif /* Wrappers for managed de...

...ions(-) diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 6c2b06fe8beb7..52a91f5fa1a36 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -248,8 +248,8 @@ extern struct resource * __request_region(struct resource *, extern void __release_region(struct resource *, resource_size_t, resource_size_t); #ifdef CONFIG_MEMORY_HOTREMOVE -extern int release_mem_region_adjustable(struct resource *, resource_size_t, - resource_size_t); +extern void release_mem_region_adjustable(struct resource *, resource_size_t, + resource_size_t); #endif /* Wrappers for managed de...

From: Sui Jingfeng <suijingfeng at loongson.cn> Currently, the default VGA device selection is not perfect. Potential problems are: 1) This function is a no-op on non-x86 architectures. 2) It does not take the PCI Bar may get relocated into consideration. 3) It is not effective for the PCI device without a dedicated VRAM Bar. 4) It is device-agnostic, thus it has to waste the effort to

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

This is the follow-up of "[PATCH RFCv1 0/5] mm/memory_hotplug: selective merging of memory resources" [1] Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

...drm/nouveau/include/nvkm/core/device.h b/drm/nouveau/include/nvkm/core/device.h index 7ea8aa7..6bc712f 100644 --- a/drm/nouveau/include/nvkm/core/device.h +++ b/drm/nouveau/include/nvkm/core/device.h @@ -175,6 +175,7 @@ struct nvkm_device_func { void (*fini)(struct nvkm_device *, bool suspend); resource_size_t (*resource_addr)(struct nvkm_device *, unsigned bar); resource_size_t (*resource_size)(struct nvkm_device *, unsigned bar); + bool cpu_coherent; }; struct nvkm_device_quirk { diff --git a/drm/nouveau/nouveau_bo.c b/drm/nouveau/nouveau_bo.c index 528bdef..6887d0a 100644 --- a/drm/nouveau/nouve...

..._tables", 0600, NULL, NULL, diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 12e4d2d..3ba6e06 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -62,8 +62,8 @@ int ioremap_change_attr(unsigned long vaddr, unsigned long size, static void __iomem *__ioremap_caller(resource_size_t phys_addr, unsigned long size, unsigned long prot_val, void *caller) { - unsigned long pfn, offset, vaddr; - resource_size_t last_addr; + unsigned long offset, vaddr; + resource_size_t pfn, last_pfn, last_addr; const resource_size_t unaligned_phys_addr = phys_addr; const unsigned long unali...

...d not find anything on LKML. kernel/resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/resource.c b/kernel/resource.c index ca2a666e4317..3ae2f56cc79d 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -1278,7 +1278,7 @@ void release_mem_region_adjustable(resource_size_t start, resource_size_t size) * similarly). */ retry: - new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0); + new_res = alloc_resource(GFP_KERNEL | (alloc_nofail ? __GFP_NOFAIL : 0)); p = &parent->child; write_lock(&resource_lock); base-commit: 40ee82f47b...

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

...rm/nouveau/include/nvkm/core/device.h > index 7ea8aa7..6bc712f 100644 > --- a/drm/nouveau/include/nvkm/core/device.h > +++ b/drm/nouveau/include/nvkm/core/device.h > @@ -175,6 +175,7 @@ struct nvkm_device_func { > void (*fini)(struct nvkm_device *, bool suspend); > resource_size_t (*resource_addr)(struct nvkm_device *, unsigned bar); > resource_size_t (*resource_size)(struct nvkm_device *, unsigned bar); > + bool cpu_coherent; > }; > > struct nvkm_device_quirk { > diff --git a/drm/nouveau/nouveau_bo.c b/drm/nouveau/nouveau_bo.c > index 52...

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

...55 insertions(+) >> >> diff --git a/include/linux/ioport.h b/include/linux/ioport.h >> index 52a91f5fa1a36..3bb0020cd6ddc 100644 >> --- a/include/linux/ioport.h >> +++ b/include/linux/ioport.h >> @@ -251,6 +251,9 @@ extern void __release_region(struct resource *, resource_size_t, >> extern void release_mem_region_adjustable(struct resource *, resource_size_t, >> resource_size_t); >> #endif >> +#ifdef CONFIG_MEMORY_HOTPLUG >> +extern void merge_system_ram_resources(struct resource *res); >> +#en...

...; index eee069a..9ed5bef 100644 > --- a/arch/ia64/pci/fixup.c > +++ b/arch/ia64/pci/fixup.c > @@ -37,6 +37,27 @@ static void pci_fixup_video(struct pci_dev *pdev) > return; > /* Maybe, this machine supports legacy memory map. */ > > + if (!vga_default_device()) { > + resource_size_t start, end; > + int i; > + > + /* Does firmware framebuffer belong to us? */ > + for (i=0; i < DEVICE_COUNT_RESOURCE; i++) { > + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM)) > + continue; > + > + start = pci_resource_start(pdev, i); > + end = p...

TTM-allocated coherent objects were populated using the DMA API and accessed using the mapping it returned to workaround coherency issues. These issues seem to have been solved, thus remove this extra case to handle and use the regular kernel mapping functions. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nouveau_bo.c | 61

...core/device.h >> index 7ea8aa7..6bc712f 100644 >> --- a/drm/nouveau/include/nvkm/core/device.h >> +++ b/drm/nouveau/include/nvkm/core/device.h >> @@ -175,6 +175,7 @@ struct nvkm_device_func { >> void (*fini)(struct nvkm_device *, bool suspend); >> resource_size_t (*resource_addr)(struct nvkm_device *, unsigned bar); >> resource_size_t (*resource_size)(struct nvkm_device *, unsigned bar); >> + bool cpu_coherent; >> }; >> >> struct nvkm_device_quirk { >> diff --git a/drm/nouveau/nouveau_bo.c b/drm/nouveau/no...

...atomic_pfn_prot(unsigned long pfn, pgprot_t prot); - -static inline void iounmap_atomic(void __iomem *vaddr) -{ - kunmap_local_indexed((void __force *)vaddr); - pagefault_enable(); - preempt_enable(); -} +void __iomem *__iomap_local_pfn_prot(unsigned long pfn, pgprot_t prot); int iomap_create_wc(resource_size_t base, unsigned long size, pgprot_t *prot); --- a/arch/x86/mm/iomap_32.c +++ b/arch/x86/mm/iomap_32.c @@ -44,7 +44,7 @@ void iomap_free(resource_size_t base, un } EXPORT_SYMBOL_GPL(iomap_free); -void __iomem *iomap_atomic_pfn_prot(unsigned long pfn, pgprot_t prot) +void __iomem *__iomap_local_...