search for: aligned_size

...size_t size, enum dma_data_direction dir, + unsigned long attrs) +{ + struct iommu_domain *domain = iommu_get_dma_domain(dev); + struct iommu_dma_cookie *cookie = domain->iova_cookie; + struct iova_domain *iovad = &cookie->iovad; + size_t iova_off = iova_offset(iovad, dma_addr); + size_t aligned_size = iova_align(iovad, size + iova_off); + phys_addr_t phys; + + phys = iommu_iova_to_phys(domain, dma_addr); + if (WARN_ON(!phys)) + return; + + __iommu_dma_unmap(dev, dma_addr, size); + +#ifdef CONFIG_SWIOTLB + if (unlikely(is_swiotlb_buffer(phys))) + swiotlb_tbl_unmap_single(dev, phys, size, +...

..., phys_addr_t paddr, size_t size, cfb94a372f2d4e Lu Baolu 2019-09-06 3944 enum dma_data_direction dir, unsigned long attrs, cfb94a372f2d4e Lu Baolu 2019-09-06 3945 u64 dma_mask) cfb94a372f2d4e Lu Baolu 2019-09-06 3946 { cfb94a372f2d4e Lu Baolu 2019-09-06 3947 size_t aligned_size = ALIGN(size, VTD_PAGE_SIZE); cfb94a372f2d4e Lu Baolu 2019-09-06 3948 struct dmar_domain *domain; cfb94a372f2d4e Lu Baolu 2019-09-06 3949 struct intel_iommu *iommu; cfb94a372f2d4e Lu Baolu 2019-09-06 3950 unsigned long iova_pfn; cfb94a372f2d4e Lu Baolu 2019-09-06 3951 un...

...#include <drm/drm_gem_framebuffer_helper.h> #include "framebuffer.h" +#include "gem.h" #include "gtt.h" #include "psb_drv.h" #include "psb_intel_drv.h" @@ -285,6 +286,7 @@ static struct gtt_range *psbfb_alloc(struct drm_device *dev, int aligned_size) /* Begin by trying to use stolen memory backing */ backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1, PAGE_SIZE); if (backing) { + backing->gem.funcs = &psb_gem_object_funcs; drm_gem_private_object_init(dev, &backing->gem, aligned_size); return backing;...

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the

...hink we dropped the ball on docs. I still can't see it in the documentation, would it be possible to be clear about it in the docs, please? For first, it's not very intuitive to figure out that (if I've figured out it correctly) on POWER one *must* specify the NVDIMM size S as S == aligned_size + label_size and that size is used for the QEMU device; while on x86_64 one can specify any size S and align_up(S) will be used for the QEMU device (and label size doesn't influence the value). And additional alignment may be required for having any memory hot plug working. For second, a...

...pin(qbo); - - drm_gem_object_put_unlocked(gobj); -} - -static int qxlfb_create_pinned_object(struct qxl_device *qdev, - const struct drm_mode_fb_cmd2 *mode_cmd, - struct drm_gem_object **gobj_p) -{ - struct drm_gem_object *gobj = NULL; - struct qxl_bo *qbo = NULL; - int ret; - int aligned_size, size; - int height = mode_cmd->height; - - size = mode_cmd->pitches[0] * height; - aligned_size = ALIGN(size, PAGE_SIZE); - /* TODO: unallocate and reallocate surface0 for real. Hack to just - * have a large enough surface0 for 1024x768 Xorg 32bpp mode */ - ret = qxl_gem_object_create(qdev,...

...ld it be possible to be >>>> clear about it in the docs, please? For first, it's not very intuitive >>>> to figure out that (if I've figured out it correctly) on POWER one >>>> *must* specify the NVDIMM size S as >>>> >>>> S == aligned_size + label_size >>>> >>>> and that size is used for the QEMU device; while on x86_64 one can >>>> specify any size S and >>>> >>>> align_up(S) >>>> >>>> will be used for the QEMU device (and label size doesn't i...

...n't see it in the documentation, would it be possible to be >> clear about it in the docs, please? For first, it's not very intuitive >> to figure out that (if I've figured out it correctly) on POWER one >> *must* specify the NVDIMM size S as >> >> S == aligned_size + label_size >> >> and that size is used for the QEMU device; while on x86_64 one can >> specify any size S and >> >> align_up(S) >> >> will be used for the QEMU device (and label size doesn't influence the >> value). And additional alignmen...

...gt; > I still can't see it in the documentation, would it be possible to be > clear about it in the docs, please? For first, it's not very intuitive > to figure out that (if I've figured out it correctly) on POWER one > *must* specify the NVDIMM size S as > > S == aligned_size + label_size > > and that size is used for the QEMU device; while on x86_64 one can > specify any size S and > > align_up(S) > > will be used for the QEMU device (and label size doesn't influence the > value). And additional alignment may be required for having any...

...t; > clear about it in the docs, please? For first, it's not very intuitive > > > > > to figure out that (if I've figured out it correctly) on POWER one > > > > > *must* specify the NVDIMM size S as > > > > > > > > > > S == aligned_size + label_size > > > > > > > > > > and that size is used for the QEMU device; while on x86_64 one can > > > > > specify any size S and > > > > > > > > > > align_up(S) > > > > > > > > > > wil...

...umentation, would it be possible to be > >> clear about it in the docs, please? For first, it's not very intuitive > >> to figure out that (if I've figured out it correctly) on POWER one > >> *must* specify the NVDIMM size S as > >> > >> S == aligned_size + label_size > >> > >> and that size is used for the QEMU device; while on x86_64 one can > >> specify any size S and > >> > >> align_up(S) > >> > >> will be used for the QEMU device (and label size doesn't influence the > &...

Hi, I modified my kickstart to do some custom partioning and formating in a pre-install script. I am trying to align the partitions on the RAID stripe (and format with a correct stride). But, sfdisk complains that it does not start/end on a cylinder boundary (used -L option to limit complaining). Since the cylinder size is not a multiple of the stripe size, I cannot align on both. I tried to

Hi, I've met two situations with NVDIMM support in libvirt where I'm not sure all the parties (libvirt & I) do the things correctly. The first problem is with memory alignment and size changes. In addition to the size changes applied to NVDIMMs by QEMU, libvirt also makes some NVDIMM size changes for better alignments, in qemuDomainMemoryDeviceAlignSize. This can lead to the size

Joe Perches (2): drm: Use pr_cont where appropriate gpu: drm: Convert printk(KERN_<LEVEL> to pr_<level> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +-

.../drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c @@ -150,8 +150,7 @@ static int amdgpufb_create_pinned_object(struct amdgpu_fbdev *rfbdev, AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS, true, &gobj); if (ret) { - printk(KERN_ERR "failed to allocate framebuffer (%d)\n", - aligned_size); + pr_err("failed to allocate framebuffer (%d)\n", aligned_size); return -ENOMEM; } abo = gem_to_amdgpu_bo(gobj); diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c index e05a24325eeb..b0483e6e536f 100644 --- a/drivers/gpu/drm/amd/amd...

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Version 3 of this patchset mostly fixes drm_gem_prime_handle_to_fd and updates i.MX's dcss driver. The driver was missing from earlier versions and

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #18 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to an instance of

...dgpu_fb.c > @@ -150,8 +150,7 @@ static int amdgpufb_create_pinned_object(struct amdgpu_fbdev *rfbdev, > AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS, > true, &gobj); > if (ret) { > - printk(KERN_ERR "failed to allocate framebuffer (%d)\n", > - aligned_size); > + pr_err("failed to allocate framebuffer (%d)\n", aligned_size); > return -ENOMEM; > } > abo = gem_to_amdgpu_bo(gobj); > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c > index e05a24325eeb..b0483e6e536f 100644...