Re: drm_dp_mst_topology.c and old compilers
Quoting Alex Deucher (2020-02-20 02:52:32)
> On Wed, Feb 19, 2020 at 7:42 PM Paul E. McKenney wrote:
> >
> > Hello!
> >
> > A box with GCC 4.8.3 compiler didn't like drm_dp_mst_topology.c. The
> > following (lightly tested) patch makes it happy and seems OK for newer
> > compilers as well.
> >
> > Is this of interest?
>
> How about a memset instead? That should be consistent across compilers.
The kernel has adopted the gccism: struct drm_dp_desc desc = {};
git grep '= {}' | wc -l: 2046
git grep '= { }' | wc -l: 694
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: add led-backlight driver
On Wed, 19 Feb 2020, Tony Lindgren wrote: > * Pavel Machek [200219 19:15]: > > From: Tomi Valkeinen > > > > This patch adds a led-backlight driver (led_bl), which is similar to > > pwm_bl except the driver uses a LED class driver to adjust the > > brightness in the HW. Multiple LEDs can be used for a single backlight. > > > > Signed-off-by: Tomi Valkeinen > > Signed-off-by: Jean-Jacques Hiblot > > Acked-by: Pavel Machek > > Reviewed-by: Daniel Thompson > > Acked-by: Lee Jones > > Acked-by: Tony Lindgren > > Tested-by: Tony Lindgren > > Signed-off-by: Pavel Machek > > --- > > drivers/video/backlight/Kconfig | 7 ++ > > drivers/video/backlight/Makefile | 1 + > > drivers/video/backlight/led_bl.c | 260 > > +++ > > 3 files changed, 268 insertions(+) > > create mode 100644 drivers/video/backlight/led_bl.c > > > > Hi! > > > > Here's the version of the driver I have. AFAICT > > default-brightness-level handling is ok, so does not need to be > > changed. > > > > Lee, it would be easiest for me if you could apply it to your tree and > > push, but given enough time I can push it to Linus, too. > > Oh you're using quoted-printable for patches.. Got it applied now, > and it still works. Below is also the related dts change that > I tested with. > > Feel free to pick the dts change too, naturally that should > not be applied before the driver. > > If you guys instead want me to pick these both into my fixes > branch, just let me know and I'll do the explaining why these > are needed as fixes. Basically we no longer have a way to enable > the LCD backlight for droid4 manually starting with v5.6-rc1 > unlike earlier. Please do. You already have my Ack. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/4] msm/gpu/a6xx: use the DMA-API for GMU memory allocations
On Wed, Feb 19, 2020 at 1:33 PM Jordan Crouse wrote: > > When CONFIG_INIT_ON_ALLOC_DEFAULT_ON the GMU memory allocator runs afoul of > cache coherency issues because it is mapped as write-combine without clearing > the cache after it was zeroed. > > Rather than duplicate the hacky workaround we use in the GEM allocator for the > same reason it turns out that we don't need to have a bespoke memory allocator > for the GMU anyway. It uses a flat, global address space and there are only > two relatively minor allocations anyway. In short, this is essentially what > the > DMA API was created for so replace a bunch of memory management code with two > calls to allocate and free DMA memory and we're fine. > > The only wrinkle is that the memory allocations need to be in a very specific > location in the GMU virtual address space so in order to get the iova > allocator > to do the right thing we need to specify the dma-ranges property in the device > tree for the GMU node. Since we've not yet converted the GMU bindings over to > YAML two patches quickly turn into four but at the end of it we have at least > one bindings file converted to YAML and 99 less lines of code to worry about. > > Jordan Crouse (4): > dt-bindings: display: msm: Convert GMU bindings to YAML > dt-bindings: display: msm: Add required dma-range property > arm64: dts: sdm845: Set the virtual address range for GMU allocations > drm/msm/a6xx: Use the DMA API for GMU memory objects Awesome! Thanks so much for the quick turnaround on this! This set resolves the crashes I was seeing with CONFIG_INIT_ON_ALLOC_DEFAULT_ON. Tested-by: John Stultz thanks again! -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_dp_mst_topology.c and old compilers
On Wed, Feb 19, 2020 at 7:42 PM Paul E. McKenney wrote:
>
> Hello!
>
> A box with GCC 4.8.3 compiler didn't like drm_dp_mst_topology.c. The
> following (lightly tested) patch makes it happy and seems OK for newer
> compilers as well.
>
> Is this of interest?
How about a memset instead? That should be consistent across compilers.
Alex
>
> Thanx, Paul
>
> ---
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 20cdaf3..232408a 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -5396,7 +5396,7 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
> drm_dp_mst_port *port)
> {
> struct drm_dp_mst_port *immediate_upstream_port;
> struct drm_dp_mst_port *fec_port;
> - struct drm_dp_desc desc = { 0 };
> + struct drm_dp_desc desc = {{{ 0 }}};
> u8 endpoint_fec;
> u8 endpoint_dsc;
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH 0/3] KVM: x86: honor guest memory type
> From: Tian, Kevin > Sent: Thursday, February 20, 2020 10:05 AM > > > From: Chia-I Wu > > Sent: Thursday, February 20, 2020 3:37 AM > > > > On Wed, Feb 19, 2020 at 1:52 AM Tian, Kevin wrote: > > > > > > > From: Paolo Bonzini > > > > Sent: Wednesday, February 19, 2020 12:29 AM > > > > > > > > On 14/02/20 23:03, Sean Christopherson wrote: > > > > >> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu > wrote: > > > > >>> AFAICT, it is currently allowed on ARM (verified) and AMD (not > > > > >>> verified, but svm_get_mt_mask returns 0 which supposedly means > > the > > > > NPT > > > > >>> does not restrict what the guest PAT can do). This diff would do > > > > >>> the > > > > >>> trick for Intel without needing any uapi change: > > > > >> I would be concerned about Intel CPU errata such as SKX40 and > SKX59. > > > > > The part KVM cares about, #MC, is already addressed by forcing UC > for > > > > MMIO. > > > > > The data corruption issue is on the guest kernel to correctly use WC > > > > > and/or non-temporal writes. > > > > > > > > What about coherency across live migration? The userspace process > > would > > > > use cached accesses, and also a WBINVD could potentially corrupt guest > > > > memory. > > > > > > > > > > In such case the userspace process possibly should conservatively use > > > UC mapping, as if for MMIO regions on a passthrough device. However > > > there remains a problem. the definition of KVM_MEM_DMA implies > > > favoring guest setting, which could be whatever type in concept. Then > > > assuming UC is also problematic. I'm not sure whether inventing another > > > interface to query effective memory type from KVM is a good idea. There > > > is no guarantee that the guest will use same type for every page in the > > > same slot, then such interface might be messy. Alternatively, maybe > > > we could just have an interface for KVM userspace to force memory type > > > for a given slot, if it is mainly used in para-virtualized scenarios (e.g. > > > virtio-gpu) where the guest is enlightened to use a forced type (e.g. WC)? > > KVM forcing the memory type for a given slot should work too. But the > > ignore-guest-pat bit seems to be Intel-specific. We will need to > > define how the second-level page attributes combine with the guest > > page attributes somehow. > > oh, I'm not aware of that difference. without an ipat-equivalent > capability, I'm not sure how to forcing random type here. If you look at > table 11-7 in Intel SDM, none of MTRR (EPT) memory type can lead to > consistent effective type when combining with random PAT value. So > it is definitely a dead end. > > > > > KVM should in theory be able to tell that the userspace region is > > mapped with a certain memory type and can force the same memory type > > onto the guest. The userspace does not need to be involved. But that > > sounds very slow? This may be a dumb question, but would it help to > > add KVM_SET_DMA_BUF and let KVM negotiate the memory type with the > > in-kernel GPU drivers? > > > > > > KVM_SET_DMA_BUF looks more reasonable. But I guess we don't need > KVM to be aware of such negotiation. We can continue your original > proposal to have KVM simply favor guest memory type (maybe still call > KVM_MEM_DMA). On the other hand, Qemu should just mmap on the > fd handle of the dmabuf passed from the virtio-gpu device backend, e.g. > to conduct migration. That way the mmap request is finally served by > DRM and underlying GPU drivers, with proper type enforced automatically. > Thinking more possibly we don't need introduce new interface to KVM. As long as Qemu uses dmabuf interface to mmap the specific region, KVM can simply check memory type in host page table given hva of a memslot. If the type is UC or WC, it implies that userspace wants a non-coherent mapping which should be reflected in the guest side too. In such case, KVM can go to non-cohenrent DMA path and favor guest memory type automatically. Thanks Kevin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH 0/3] KVM: x86: honor guest memory type
> From: Chia-I Wu > Sent: Thursday, February 20, 2020 3:18 AM > > On Wed, Feb 19, 2020 at 2:00 AM Tian, Kevin wrote: > > > > > From: Chia-I Wu > > > Sent: Saturday, February 15, 2020 5:15 AM > > > > > > On Fri, Feb 14, 2020 at 2:26 AM Paolo Bonzini > wrote: > > > > > > > > On 13/02/20 23:18, Chia-I Wu wrote: > > > > > > > > > > The bug you mentioned was probably this one > > > > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=104091 > > > > > > > > Yes, indeed. > > > > > > > > > From what I can tell, the commit allowed the guests to create cached > > > > > mappings to MMIO regions and caused MCEs. That is different than > what > > > > > I need, which is to allow guests to create uncached mappings to > system > > > > > ram (i.e., !kvm_is_mmio_pfn) when the host userspace also has > > > uncached > > > > > mappings. But it is true that this still allows the userspace & guest > > > > > kernel to create conflicting memory types. > > > > > > > > Right, the question is whether the MCEs were tied to MMIO regions > > > > specifically and if so why. > > > > > > > > An interesting remark is in the footnote of table 11-7 in the SDM. > > > > There, for the MTRR (EPT for us) memory type UC you can read: > > > > > > > > The UC attribute comes from the MTRRs and the processors are not > > > > required to snoop their caches since the data could never have > > > > been cached. This attribute is preferred for performance reasons. > > > > > > > > There are two possibilities: > > > > > > > > 1) the footnote doesn't apply to UC mode coming from EPT page tables. > > > > That would make your change safe. > > > > > > > > 2) the footnote also applies when the UC attribute comes from the EPT > > > > page tables rather than the MTRRs. In that case, the host should use > > > > UC as the EPT page attribute if and only if it's consistent with the > > > > host > > > > MTRRs; it would be more or less impossible to honor UC in the guest > > > MTRRs. > > > > In that case, something like the patch below would be needed. > > > > > > > > It is not clear from the manual why the footnote would not apply to WC; > > > that > > > > is, the manual doesn't say explicitly that the processor does not do > > > snooping > > > > for accesses to WC memory. But I guess that must be the case, which is > > > why I > > > > used MTRR_TYPE_WRCOMB in the patch below. > > > > > > > > Either way, we would have an explanation of why creating cached > mapping > > > to > > > > MMIO regions would, and why in practice we're not seeing MCEs for > guest > > > RAM > > > > (the guest would have set WB for that memory in its MTRRs, not UC). > > > > > > > > One thing you didn't say: how would userspace use KVM_MEM_DMA? > On > > > which > > > > regions would it be set? > > > It will be set for shmems that are mapped WC. > > > > > > GPU/DRM drivers allocate shmems as DMA-able gpu buffers and allow > the > > > userspace to map them cached or WC (I915_MMAP_WC or > > > AMDGPU_GEM_CREATE_CPU_GTT_USWC for example). When a shmem > is > > > mapped > > > WC and is made available to the guest, we would like the ability to > > > map the region WC in the guest. > > > > Curious... How is such slot exposed to the guest? A reserved memory > > region? Is it static or might be dynamically added? > The plan is for virtio-gpu device to reserve a huge memory region in > the guest. Memslots may be added dynamically or statically to back > the region. so the region is marked as E820_RESERVED to prevent guest kernel from using it for other purpose and then virtio-gpu device will report virtio-gpu driver of the exact location of the region through its own interface? > > Dynamic: the host adds a 16MB GPU allocation as a memslot at a time. > The guest kernel suballocates from the 16MB pool. > > Static: the host creates a huge PROT_NONE memfd and adds it as a > memslot. GPU allocations are mremap()ed into the memfd region to > provide the real mapping. > > These options are considered because the number of memslots are > limited: 32 on ARM and 509 on x86. If the number of memslots could be > made larger (4096 or more), we would also consider adding each > individual GPU allocation as a memslot. > > These are actually questions we need feedback. Besides, GPU > allocations can be assumed to be kernel dma-bufs in this context. I > wonder if it makes sense to have a variation of > KVM_SET_USER_MEMORY_REGION that takes dma-bufs. I feel it makes more sense. Thanks Kevin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH 0/3] KVM: x86: honor guest memory type
> From: Chia-I Wu > Sent: Thursday, February 20, 2020 3:37 AM > > On Wed, Feb 19, 2020 at 1:52 AM Tian, Kevin wrote: > > > > > From: Paolo Bonzini > > > Sent: Wednesday, February 19, 2020 12:29 AM > > > > > > On 14/02/20 23:03, Sean Christopherson wrote: > > > >> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu wrote: > > > >>> AFAICT, it is currently allowed on ARM (verified) and AMD (not > > > >>> verified, but svm_get_mt_mask returns 0 which supposedly means > the > > > NPT > > > >>> does not restrict what the guest PAT can do). This diff would do the > > > >>> trick for Intel without needing any uapi change: > > > >> I would be concerned about Intel CPU errata such as SKX40 and SKX59. > > > > The part KVM cares about, #MC, is already addressed by forcing UC for > > > MMIO. > > > > The data corruption issue is on the guest kernel to correctly use WC > > > > and/or non-temporal writes. > > > > > > What about coherency across live migration? The userspace process > would > > > use cached accesses, and also a WBINVD could potentially corrupt guest > > > memory. > > > > > > > In such case the userspace process possibly should conservatively use > > UC mapping, as if for MMIO regions on a passthrough device. However > > there remains a problem. the definition of KVM_MEM_DMA implies > > favoring guest setting, which could be whatever type in concept. Then > > assuming UC is also problematic. I'm not sure whether inventing another > > interface to query effective memory type from KVM is a good idea. There > > is no guarantee that the guest will use same type for every page in the > > same slot, then such interface might be messy. Alternatively, maybe > > we could just have an interface for KVM userspace to force memory type > > for a given slot, if it is mainly used in para-virtualized scenarios (e.g. > > virtio-gpu) where the guest is enlightened to use a forced type (e.g. WC)? > KVM forcing the memory type for a given slot should work too. But the > ignore-guest-pat bit seems to be Intel-specific. We will need to > define how the second-level page attributes combine with the guest > page attributes somehow. oh, I'm not aware of that difference. without an ipat-equivalent capability, I'm not sure how to forcing random type here. If you look at table 11-7 in Intel SDM, none of MTRR (EPT) memory type can lead to consistent effective type when combining with random PAT value. So it is definitely a dead end. > > KVM should in theory be able to tell that the userspace region is > mapped with a certain memory type and can force the same memory type > onto the guest. The userspace does not need to be involved. But that > sounds very slow? This may be a dumb question, but would it help to > add KVM_SET_DMA_BUF and let KVM negotiate the memory type with the > in-kernel GPU drivers? > > KVM_SET_DMA_BUF looks more reasonable. But I guess we don't need KVM to be aware of such negotiation. We can continue your original proposal to have KVM simply favor guest memory type (maybe still call KVM_MEM_DMA). On the other hand, Qemu should just mmap on the fd handle of the dmabuf passed from the virtio-gpu device backend, e.g. to conduct migration. That way the mmap request is finally served by DRM and underlying GPU drivers, with proper type enforced automatically. Thanks Kevin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:topic/core-for-CI 18/21] init/Kconfig:77: symbol BROKEN is selected by DRM_I915_DEBUG
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI head: 2a97892fdbae277a104d6ba0b90f8a47cbe53681 commit: 0db409f2a5a4ec41dba541c21d6fa294c8a4dfd4 [18/21] Revert "drm/i915: Don't select BROKEN" config: powerpc-ksi8560_defconfig compiler: powerpc-linux-gcc (GCC) 7.5.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 0db409f2a5a4ec41dba541c21d6fa294c8a4dfd4 GCC_VERSION=7.5.0 make.cross ARCH=powerpc 85xx/ksi8560_defconfig GCC_VERSION=7.5.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> arch/powerpc/platforms/embedded6xx/Kconfig:2:error: recursive dependency >> detected! >> arch/powerpc/platforms/embedded6xx/Kconfig:2: symbol EMBEDDED6xx depends on >> BROKEN_ON_SMP >> init/Kconfig:80: symbol BROKEN_ON_SMP depends on BROKEN >> init/Kconfig:77: symbol BROKEN is selected by DRM_I915_DEBUG >> drivers/gpu/drm/i915/Kconfig.debug:19: symbol DRM_I915_DEBUG depends on >> DRM_I915 >> drivers/gpu/drm/i915/Kconfig:2: symbol DRM_I915 depends on DRM >> drivers/gpu/drm/Kconfig:8: symbol DRM depends on AGP >> drivers/char/agp/Kconfig:2: symbol AGP depends on PCI >> drivers/pci/Kconfig:16: symbol PCI depends on HAVE_PCI >> drivers/pci/Kconfig:7: symbol HAVE_PCI is selected by FORCE_PCI >> drivers/pci/Kconfig:11: symbol FORCE_PCI is selected by MVME5100 >> arch/powerpc/platforms/embedded6xx/Kconfig:51: symbol MVME5100 depends on >> EMBEDDED6xx For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" vim +77 init/Kconfig ^1da177e4c3f41 Linus Torvalds 2005-04-16 76 ^1da177e4c3f41 Linus Torvalds 2005-04-16 @77 config BROKEN ^1da177e4c3f41 Linus Torvalds 2005-04-16 78bool ^1da177e4c3f41 Linus Torvalds 2005-04-16 79 ^1da177e4c3f41 Linus Torvalds 2005-04-16 @80 config BROKEN_ON_SMP ^1da177e4c3f41 Linus Torvalds 2005-04-16 81bool ^1da177e4c3f41 Linus Torvalds 2005-04-16 82depends on BROKEN || !SMP ^1da177e4c3f41 Linus Torvalds 2005-04-16 83default y ^1da177e4c3f41 Linus Torvalds 2005-04-16 84 :: The code at line 77 was first introduced by commit :: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2 :: TO: Linus Torvalds :: CC: Linus Torvalds --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: component type MTK_DISP_OVL_2L is not correctly handled
Hi, Phong: On Wed, 2020-02-19 at 15:13 +0100, Phong LE wrote: > The larb device remains NULL if the type is MTK_DISP_OVL_2L. > A kernel panic is raised when a crtc uses mtk_smi_larb_get or > mtk_smi_larb_put. > Reviewed-by: CK Hu > Signed-off-by: Phong LE > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > index 1f5a112bb034..57c88de9a329 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > @@ -471,6 +471,7 @@ int mtk_ddp_comp_init(struct device *dev, struct > device_node *node, > /* Only DMA capable components need the LARB property */ > comp->larb_dev = NULL; > if (type != MTK_DISP_OVL && > + type != MTK_DISP_OVL_2L && > type != MTK_DISP_RDMA && > type != MTK_DISP_WDMA) > return 0; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] Security mitigation for Intel Gen7/7.5 HWs
Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Summary of Vulnerability Insufficient control flow in certain data structures for some Intel(R) Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via local access Products affected: -- Intel CPU’s with Gen7, Gen7.5 and Gen9 Graphics. Mitigation Summary -- This patch provides mitigation for Gen7 and Gen7.5 hardware only. Patch for Gen9 devices have been provided and merged to Linux mainline, and backported to stable kernels. Note that Gen8 is not impacted due to a previously implemented workaround. The mitigation involves submitting a custom EU kernel prior to every context restore, in order to forcibly clear down residual EU and URB resources. The custom EU kernel are generated/assembled automatically, using Mesa (an open source tool) and IGT GPU tool - assembly sources are provided with IGT source code. This security mitigation change does not trigger any known performance regression. Performance is on par with current mainline/drm-tip. Note on Address Space Isolation (Full PPGTT) Isolation of EU kernel assets should be considered complementary to the existing support for address space isolation (aka Full PPGTT), since without address space isolation there is minimal value in preventing leakage between EU contexts. Full PPGTT has long been supported on Gen Gfx devices since Gen8, and protection against EU residual leakage is a welcome addition for these newer platforms. By contrast, Gen7 and Gen7.5 device introduced Full PPGTT support only as a hardware development feature for anticipated Gen8 productization. Support was never intended for, or provided to the Linux kernels for these platforms. Recent work (still ongoing) to the mainline kernel is retroactively providing this support, but due to the level of complexity it is not practical to attempt to backport this to earlier stable kernels. Since without Full PPGTT, EU residuals protection has questionable benefit, *there are no plans to provide stable kernel backports for this patch series.* Mika Kuoppala (1): drm/i915: Add mechanism to submit a context WA on ring submission Prathap Kumar Valsan (1): drm/i915/gen7: Clear all EU/L3 residual contexts drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h | 69 +++ drivers/gpu/drm/i915/gt/gen7_clearbuffer.h| 69 +++ drivers/gpu/drm/i915/gt/gen7_renderclear.c| 399 ++ drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 135 +- 7 files changed, 698 insertions(+), 7 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h create mode 100644 drivers/gpu/drm/i915/gt/gen7_clearbuffer.h create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.
This security mitigation changes does not triggers any performance
regression. Performance is on par with current drm-tips.
v2: Add igt generated header file for CB kernel assembled with Mesa tool
and addressed use of Kernel macro for ptr_align comment.
v3: Resolve Sparse warnings with newly generated, and imported CB
kernel.
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h | 69 +++
drivers/gpu/drm/i915/gt/gen7_clearbuffer.h| 69 +++
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 399 ++
drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
7 files changed, 569 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
create mode 100644 drivers/gpu/drm/i915/gt/gen7_clearbuffer.h
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b314d44ded5e..ebe3a160f588 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ gt-y += \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
gt/gen6_ppgtt.o \
+ gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
diff --git a/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
b/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
new file mode 100644
index ..a0d5e3b20caa
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/gen7_5_clearbuffer.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ *
+ * Generated by: IGT Gpu Tools on Thu 20 Feb 2020 12:30:21 AM UTC
+ */
+
+#ifndef __GEN7_5_CLEARBUFFER_H__
+#define __GEN7_5_CLEARBUFFER_H__
+
+#include
+
+/* Media CB Kernel for gen7.5 devices */
+static const u32 hsw_eu_kernel[] = {
+ 0x0001, 0x26020128, 0x0024, 0x,
+ 0x0040, 0x20280c21, 0x0028, 0x0001,
+ 0x0110, 0x2c20, 0x002c, 0x,
+ 0x00010220, 0x34001c00, 0x1400, 0x0160,
+ 0x0061, 0x20600061, 0x, 0x,
+ 0x0008, 0x20601c85, 0x0e00, 0x000c,
+ 0x0005, 0x20601ca5, 0x0060, 0x0001,
+ 0x0008, 0x20641c85, 0x0e00, 0x000d,
+ 0x0005, 0x20641ca5, 0x0064, 0x0003,
+ 0x0041, 0x207424a5, 0x0064, 0x0034,
+ 0x0040, 0x206014a5, 0x0060, 0x0074,
+ 0x0008, 0x20681c85, 0x0e00, 0x0008,
+ 0x0005, 0x20681ca5, 0x0068, 0x000f,
+ 0x0041, 0x20701ca5, 0x0060, 0x0010,
+ 0x0040, 0x206814a5, 0x0068, 0x0070,
+ 0x0061, 0x20a00061, 0x, 0x,
+ 0x0005, 0x206c1c85, 0x0e00, 0x0007,
+ 0x0041, 0x206c1ca5, 0x006c, 0x0004,
+ 0x0061, 0x20800021, 0x008d, 0x,
+ 0x0001, 0x20800021, 0x006c, 0x,
+ 0x0001, 0x20840021, 0x0068, 0x,
+ 0x0001, 0x20880061, 0x, 0x0003,
+ 0x0005, 0x208c0d21, 0x0086, 0x,
+ 0x05600032, 0x20a00fa1, 0x008d0080, 0x02190001,
+ 0x0040, 0x20a01ca5, 0x00a0, 0x0001,
+ 0x05600032, 0x20a00fa1, 0x008d0080, 0x040a8001,
+ 0x0240, 0x20281c21, 0x0028, 0x,
+ 0x00010220, 0x34001c00, 0x1400, 0xffe0,
+ 0x0001, 0x26020128, 0x0024, 0x,
+ 0x0001, 0x220010e4, 0x, 0x,
+ 0x0001, 0x220831ec, 0x, 0x007f007f,
+ 0x0061, 0x20400021, 0x008d, 0x,
+ 0x0061, 0x2fe00021, 0x008d, 0x,
+ 0x0021, 0x20400121, 0x00450020, 0x,
+ 0x0001, 0x20480061, 0x, 0x000f000f,
+ 0x0005, 0x204c0d21, 0x0046, 0xffef,
+ 0x0081, 0x20600061, 0x, 0x,
+ 0x0081, 0x20800061, 0x, 0x,
+ 0x0081, 0x20a00061, 0x, 0x,
+ 0x0081, 0x20c00061, 0x, 0x,
+ 0x0081, 0x20e00061, 0x, 0x,
+ 0x0081, 0x2161, 0x, 0x,
+ 0x0081, 0x21200061, 0x, 0x,
+ 0x0081, 0x21400061, 0x, 0x,
+
[PATCH v3 1/2] drm/i915: Add mechanism to submit a context WA on ring submission
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.
However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.
This security mitigation change does not trigger any performance
regression. Performance is on par with current mainline/drm-tip.
v2: Update vm_alias params to point to correct address space "vm" due to
changes made in the patch "f21613797bae98773"
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 134 +-
1 file changed, 130 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index f70b903a98bc..593710558b99 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1360,7 +1360,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
}
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
{
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1435,7 +1437,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
- *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+ *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
* WaMiSetContext_Hang:snb,ivb,vlv
@@ -1550,13 +1552,56 @@ static int switch_mm(struct i915_request *rq, struct
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
}
+static int clear_residuals(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ int ret;
+
+ GEM_BUG_ON(!engine->kernel_context->state);
+
+ ret = switch_mm(rq, vm_alias(engine->kernel_context->vm));
+ if (ret)
+ return ret;
+
+ ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_bb_start(rq,
+ engine->wa_ctx.vma->node.start, 0,
+ 0);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_flush(rq, EMIT_FLUSH);
+ if (ret)
+ return ret;
+
+ /* Always invalidate before the next switch_mm() */
+ return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
static int switch_context(struct i915_request *rq)
{
+ struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
+ void **residuals = NULL;
int ret;
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
+ if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+ if (engine->wa_ctx.vma->private != ce) {
+ ret = clear_residuals(rq);
+ if (ret)
+ return ret;
+
+ residuals = >wa_ctx.vma->private;
+ }
+ }
+
ret = switch_mm(rq, vm_alias(ce->vm));
if (ret)
return ret;
@@ -1564,7 +1609,7 @@ static int switch_context(struct i915_request *rq)
if (ce->state) {
u32 flags;
- GEM_BUG_ON(rq->engine->id != RCS0);
+ GEM_BUG_ON(engine->id != RCS0);
/* For resource streamer on HSW+ and power context elsewhere */
BUILD_BUG_ON(HSW_MI_RS_SAVE_STATE_EN != MI_SAVE_EXT_STATE_EN);
@@ -1576,7 +1621,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
- ret = mi_set_context(rq, flags);
+ ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1585,6 +1630,20 @@ static int
drm_dp_mst_topology.c and old compilers
Hello!
A box with GCC 4.8.3 compiler didn't like drm_dp_mst_topology.c. The
following (lightly tested) patch makes it happy and seems OK for newer
compilers as well.
Is this of interest?
Thanx, Paul
---
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 20cdaf3..232408a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -5396,7 +5396,7 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
drm_dp_mst_port *port)
{
struct drm_dp_mst_port *immediate_upstream_port;
struct drm_dp_mst_port *fec_port;
- struct drm_dp_desc desc = { 0 };
+ struct drm_dp_desc desc = {{{ 0 }}};
u8 endpoint_fec;
u8 endpoint_dsc;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: fix virtio-gpu resource id creation race
On Wed, Feb 19, 2020 at 4:20 PM John Bates wrote:
>
>
>
> On Wed, Feb 19, 2020 at 12:40 PM John Bates wrote:
>>
>> The previous code was not thread safe and caused
>> undefined behavior from spurious duplicate resource IDs.
>> In this patch, an atomic_t is used instead. We no longer
>> see any duplicate IDs in tests with this change.
>>
>> Signed-off-by: John Bates
>> ---
>>
>> drivers/gpu/drm/virtio/virtgpu_object.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
>> b/drivers/gpu/drm/virtio/virtgpu_object.c
>> index 017a9e0fc3bb..b11c1fce1770 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
>> @@ -42,8 +42,8 @@ static int virtio_gpu_resource_id_get(struct
>> virtio_gpu_device *vgdev,
>> * "f91a9dd35715 Fix unlinking resources from hash
>> * table." (Feb 2019) fixes the bug.
>> */
>> - static int handle;
>> - handle++;
>> + static atomic_t seqno;
nit: ATOMIC_INIT(0)?
>> + int handle = atomic_inc_return();
>> *resid = handle + 1;
>> } else {
>> int handle = ida_alloc(>resource_ida, GFP_KERNEL);
>> --
>> 2.25.0.265.gbab2e86ba0-goog
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: add led-backlight driver
Hi! > > > If you guys instead want me to pick these both into my fixes > > > branch, just let me know and I'll do the explaining why these > > > are needed as fixes. Basically we no longer have a way to enable > > > the LCD backlight for droid4 manually starting with v5.6-rc1 > > > unlike earlier. > > > > If you are willing to do that, it looks like good solution from my > > point of view. > > OK. I'll apply them but won't push out yet in case Lee is already > applying the driver change.. > > Pavel, care to ack the dts patch? It looks okay to me (but did not test it yet). Acked-by: Pavel Machek Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: add led-backlight driver
On Wed, Feb 19, 2020 at 11:45:40AM -0800, Tony Lindgren wrote:
> * Pavel Machek [200219 19:15]:
> > From: Tomi Valkeinen
> >
> > This patch adds a led-backlight driver (led_bl), which is similar to
> > pwm_bl except the driver uses a LED class driver to adjust the
> > brightness in the HW. Multiple LEDs can be used for a single backlight.
> >
> > Signed-off-by: Tomi Valkeinen
> > Signed-off-by: Jean-Jacques Hiblot
> > Acked-by: Pavel Machek
> > Reviewed-by: Daniel Thompson
> > Acked-by: Lee Jones
> > Acked-by: Tony Lindgren
> > Tested-by: Tony Lindgren
> > Signed-off-by: Pavel Machek
> > ---
> > drivers/video/backlight/Kconfig | 7 ++
> > drivers/video/backlight/Makefile | 1 +
> > drivers/video/backlight/led_bl.c | 260
> > +++
> > 3 files changed, 268 insertions(+)
> > create mode 100644 drivers/video/backlight/led_bl.c
> >
> > Hi!
> >
> > Here's the version of the driver I have. AFAICT
> > default-brightness-level handling is ok, so does not need to be
> > changed.
> >
> > Lee, it would be easiest for me if you could apply it to your tree and
> > push, but given enough time I can push it to Linus, too.
>
> Oh you're using quoted-printable for patches.. Got it applied now,
> and it still works. Below is also the related dts change that
> I tested with.
>
> Feel free to pick the dts change too, naturally that should
> not be applied before the driver.
>
> If you guys instead want me to pick these both into my fixes
> branch, just let me know and I'll do the explaining why these
> are needed as fixes. Basically we no longer have a way to enable
> the LCD backlight for droid4 manually starting with v5.6-rc1
> unlike earlier.
>
> Regards,
>
> Tony
>
> 8< --
> From tony Mon Sep 17 00:00:00 2001
> From: Tony Lindgren
> Date: Wed, 19 Feb 2020 11:25:27 -0800
> Subject: [PATCH] ARM: dts: droid4: Configure LED backlight for lm3532
>
> With the LED backlight changes merged, we still need the dts configured
> to have backlight working for droid4. Based on an earlier patch from
> Pavel Machek , let's configure the backlight but update
> the value range to be more usable.
>
> We have a range of 256 register values split into 8 steps, so we can
> generate the brightness levels backwards with:
>
> $ for i in 0 1 2 3 4 5 6 7; do echo "255 - ${i} * (256 / 8)" | bc; done
>
> To avoid more confusion why the LCD backlight is still not on, let's
> also enable LED backlight as a loadable module for omap2plus_defconfig.
>
> Cc: Merlijn Wajer
> Cc: Pavel Machek
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/boot/dts/motorola-mapphone-common.dtsi | 13 +++--
> arch/arm/configs/omap2plus_defconfig| 1 +
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/motorola-mapphone-common.dtsi
> b/arch/arm/boot/dts/motorola-mapphone-common.dtsi
> --- a/arch/arm/boot/dts/motorola-mapphone-common.dtsi
> +++ b/arch/arm/boot/dts/motorola-mapphone-common.dtsi
> @@ -182,6 +182,14 @@ vibrator {
> pwm-names = "enable", "direction";
> direction-duty-cycle-ns = <1000>;
> };
> +
> + backlight: backlight {
> + compatible = "led-backlight";
> +
> + leds = <_led>;
> + brightness-levels = <31 63 95 127 159 191 223 255>;
> + default-brightness-level = <6>;
> + };
> };
>
> {
> @@ -205,6 +213,8 @@ lcd0: display {
> vddi-supply = <_regulator>;
> reset-gpios = < 5 GPIO_ACTIVE_HIGH>; /* gpio101 */
>
> + backlight = <>;
> +
> width-mm = <50>;
> height-mm = <89>;
>
> @@ -393,12 +403,11 @@ led-controller@38 {
> ramp-up-us = <1024>;
> ramp-down-us = <8193>;
>
> - led@0 {
> + backlight_led: led@0 {
> reg = <0>;
> led-sources = <2>;
> ti,led-mode = <0>;
> label = ":backlight";
> - linux,default-trigger = "backlight";
> };
>
> led@1 {
> diff --git a/arch/arm/configs/omap2plus_defconfig
> b/arch/arm/configs/omap2plus_defconfig
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -375,6 +375,7 @@ CONFIG_BACKLIGHT_GENERIC=m
> CONFIG_BACKLIGHT_PWM=m
> CONFIG_BACKLIGHT_PANDORA=m
> CONFIG_BACKLIGHT_GPIO=m
> +CONFIG_BACKLIGHT_LED=m
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
> CONFIG_LOGO=y
Finally :)
Reviewed-by: Sebastian Reichel
-- Sebastian
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: panel: lvds: Add properties for clock and data polarities
On Fri, Feb 14, 2020 at 01:24:39PM +0100, Maxime Ripard wrote: > Some LVDS encoders can support multiple polarities on the data and > clock lanes, and similarly some panels require a given polarity on > their inputs. Add a property on the panel to configure the encoder > properly. If the panel requires a specific setting, then that can be implied by the panel's compatible. Does Boris' format constraint solving series help here? Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] GPU: DRM: VC4/V3D Replace wait_for macros in to remove use of msleep
On Mon, Feb 17, 2020 at 7:41 AM James Hughes wrote: > > The wait_for macro's for Broadcom VC4 and V3D drivers used msleep > which is inappropriate due to its inaccuracy at low values (minimum > wait time is about 30ms on the Raspberry Pi). > > This patch replaces the macro with the one from the Intel i915 version > which uses usleep_range to provide more accurate waits. > > Signed-off-by: James Hughes To apply this, we're going to want to split the patch up between v3d (with a fixes tag to the introduction of the driver, since it's a pretty critical fix) and vc4 (where it's used in KMS, and we're pretty sure we want it but changing timing like this in KMS paths is risky so we don't want to backport to stable). And adjust the commit messages to have consistent prefixes to the rest of the commits to those drivers. I've been fighting with the drm maintainer tools today to try to apply the patch, with no luck. I'll keep trying, and if I succeed, I'll push it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4 v6] drm/virtio: track whether or not a context has been initiated
Use an boolean variable to track whether a context has been
initiated.
v5: Fix possible race and sleep via mutex (olv)
Reviewed-by: Chia-I Wu
Reviewed-by: Emil Velikov
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8
drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 72c1d9b59dfe..76b7b7c30e10 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -209,6 +209,8 @@ struct virtio_gpu_device {
struct virtio_gpu_fpriv {
uint32_t ctx_id;
+ bool context_created;
+ struct mutex context_lock;
};
/* virtio_ioctl.c */
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 00ef9fd3fbf6..ec38cf5573aa 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -40,10 +40,18 @@ void virtio_gpu_create_context(struct drm_device *dev,
struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
char dbgname[TASK_COMM_LEN];
+ mutex_lock(>context_lock);
+ if (vfpriv->context_created)
+ goto out_unlock;
+
get_task_comm(dbgname, current);
virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
strlen(dbgname), dbgname);
virtio_gpu_notify(vgdev);
+ vfpriv->context_created = true;
+
+out_unlock:
+ mutex_unlock(>context_lock);
}
static int virtio_gpu_map_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index f7e3712502ca..424729cb81d1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -258,6 +258,8 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
drm_file *file)
if (!vfpriv)
return -ENOMEM;
+ mutex_init(>context_lock);
+
handle = ida_alloc(>ctx_id_ida, GFP_KERNEL);
if (handle < 0) {
kfree(vfpriv);
@@ -281,6 +283,7 @@ void virtio_gpu_driver_postclose(struct drm_device *dev,
struct drm_file *file)
vfpriv = file->driver_priv;
virtio_gpu_context_destroy(vgdev, vfpriv->ctx_id);
+ mutex_destroy(>context_lock);
kfree(vfpriv);
file->driver_priv = NULL;
}
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4 v6] drm/virtio: use consistent names for drm_files
Minor cleanup, change:
- file_priv--> file,
- drm_file --> file.
Reviewed-by: Chia-I Wu
Reviewed-by: Emil Velikov
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index bbc31aef51f1..baad7e1c9505 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -34,12 +34,12 @@
#include "virtgpu_drv.h"
static int virtio_gpu_map_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+ struct drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct drm_virtgpu_map *virtio_gpu_map = data;
- return virtio_gpu_mode_dumb_mmap(file_priv, vgdev->ddev,
+ return virtio_gpu_mode_dumb_mmap(file, vgdev->ddev,
virtio_gpu_map->handle,
_gpu_map->offset);
}
@@ -51,11 +51,11 @@ static int virtio_gpu_map_ioctl(struct drm_device *dev,
void *data,
* VIRTIO_GPUReleaseInfo struct (first XXX bytes)
*/
static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
-struct drm_file *drm_file)
+struct drm_file *file)
{
struct drm_virtgpu_execbuffer *exbuf = data;
struct virtio_gpu_device *vgdev = dev->dev_private;
- struct virtio_gpu_fpriv *vfpriv = drm_file->driver_priv;
+ struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
struct virtio_gpu_fence *out_fence;
int ret;
uint32_t *bo_handles = NULL;
@@ -116,7 +116,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
goto out_unused_fd;
}
- buflist = virtio_gpu_array_from_handles(drm_file, bo_handles,
+ buflist = virtio_gpu_array_from_handles(file, bo_handles,
exbuf->num_bo_handles);
if (!buflist) {
ret = -ENOENT;
@@ -178,7 +178,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
}
static int virtio_gpu_getparam_ioctl(struct drm_device *dev, void *data,
-struct drm_file *file_priv)
+struct drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct drm_virtgpu_getparam *param = data;
@@ -201,7 +201,7 @@ static int virtio_gpu_getparam_ioctl(struct drm_device
*dev, void *data,
}
static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+ struct drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct drm_virtgpu_resource_create *rc = data;
@@ -252,7 +252,7 @@ static int virtio_gpu_resource_create_ioctl(struct
drm_device *dev, void *data,
return ret;
obj = >base.base;
- ret = drm_gem_handle_create(file_priv, obj, );
+ ret = drm_gem_handle_create(file, obj, );
if (ret) {
drm_gem_object_release(obj);
return ret;
@@ -265,13 +265,13 @@ static int virtio_gpu_resource_create_ioctl(struct
drm_device *dev, void *data,
}
static int virtio_gpu_resource_info_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+ struct drm_file *file)
{
struct drm_virtgpu_resource_info *ri = data;
struct drm_gem_object *gobj = NULL;
struct virtio_gpu_object *qobj = NULL;
- gobj = drm_gem_object_lookup(file_priv, ri->bo_handle);
+ gobj = drm_gem_object_lookup(file, ri->bo_handle);
if (gobj == NULL)
return -ENOENT;
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4 v6] drm/virtio: enqueue virtio_gpu_create_context after the first 3D ioctl
For old userspace, initialization will still be implicit.
For backwards compatibility, enqueue virtio_gpu_cmd_context_create after
the first 3D ioctl.
v3: staticify virtio_gpu_create_context
remove notify to batch vm-exit
v6: Remove nested 3D checks (emil.velikov):
- unify 3D check in resource create
- VIRTIO_GPU_CMD_GET_CAPSET is listed as a 2D ioctl, added a
3D check there.
Reviewed-by: Chia-I Wu
Reviewed-by: Emil Velikov
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 --
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 32 +++---
drivers/gpu/drm/virtio/virtgpu_kms.c | 1 -
3 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 76b7b7c30e10..95a7443baaba 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -216,8 +216,6 @@ struct virtio_gpu_fpriv {
/* virtio_ioctl.c */
#define DRM_VIRTIO_NUM_IOCTLS 10
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
-void virtio_gpu_create_context(struct drm_device *dev,
- struct drm_file *file);
/* virtio_kms.c */
int virtio_gpu_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index ec38cf5573aa..c36faa572caa 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -33,8 +33,8 @@
#include "virtgpu_drv.h"
-void virtio_gpu_create_context(struct drm_device *dev,
- struct drm_file *file)
+static void virtio_gpu_create_context(struct drm_device *dev,
+ struct drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
@@ -95,6 +95,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
exbuf->fence_fd = -1;
+ virtio_gpu_create_context(dev, file);
if (exbuf->flags & VIRTGPU_EXECBUF_FENCE_FD_IN) {
struct dma_fence *in_fence;
@@ -233,7 +234,17 @@ static int virtio_gpu_resource_create_ioctl(struct
drm_device *dev, void *data,
uint32_t handle = 0;
struct virtio_gpu_object_params params = { 0 };
- if (vgdev->has_virgl_3d == false) {
+ if (vgdev->has_virgl_3d) {
+ virtio_gpu_create_context(dev, file);
+ params.virgl = true;
+ params.target = rc->target;
+ params.bind = rc->bind;
+ params.depth = rc->depth;
+ params.array_size = rc->array_size;
+ params.last_level = rc->last_level;
+ params.nr_samples = rc->nr_samples;
+ params.flags = rc->flags;
+ } else {
if (rc->depth > 1)
return -EINVAL;
if (rc->nr_samples > 1)
@@ -250,16 +261,6 @@ static int virtio_gpu_resource_create_ioctl(struct
drm_device *dev, void *data,
params.width = rc->width;
params.height = rc->height;
params.size = rc->size;
- if (vgdev->has_virgl_3d) {
- params.virgl = true;
- params.target = rc->target;
- params.bind = rc->bind;
- params.depth = rc->depth;
- params.array_size = rc->array_size;
- params.last_level = rc->last_level;
- params.nr_samples = rc->nr_samples;
- params.flags = rc->flags;
- }
/* allocate a single page size object */
if (params.size == 0)
params.size = PAGE_SIZE;
@@ -319,6 +320,7 @@ static int virtio_gpu_transfer_from_host_ioctl(struct
drm_device *dev,
if (vgdev->has_virgl_3d == false)
return -ENOSYS;
+ virtio_gpu_create_context(dev, file);
objs = virtio_gpu_array_from_handles(file, >bo_handle, 1);
if (objs == NULL)
return -ENOENT;
@@ -367,6 +369,7 @@ static int virtio_gpu_transfer_to_host_ioctl(struct
drm_device *dev, void *data,
args->box.w, args->box.h, args->box.x, args->box.y,
objs, NULL);
} else {
+ virtio_gpu_create_context(dev, file);
ret = virtio_gpu_array_lock_resv(objs);
if (ret != 0)
goto err_put_free;
@@ -466,6 +469,9 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
}
spin_unlock(>display_info_lock);
+ if (vgdev->has_virgl_3d)
+ virtio_gpu_create_context(dev, file);
+
/* not in cache - need to talk to hw */
virtio_gpu_cmd_get_capset(vgdev, found_valid, args->cap_set_ver,
_ent);
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 424729cb81d1..023a030ca7b9
[PATCH 2/4 v6] drm/virtio: factor out context create hypercall
We currently create an OpenGL context when opening the DRM fd
if 3D is available.
We may need other context types (VK,..) in the future, and the plan
is to have explicit initialization for that.
For explicit initialization to work, we need to factor out
virtio_gpu_create_context from driver initialization.
v2: Move context handle initialization too (olv)
v6: Remove redundant 3D check (emil.velikov)
Reviewed-by: Chia-I Wu
Reviewed-by: Emil Velikov
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 13 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 26 ++
3 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 2f6c4ccbfd14..72c1d9b59dfe 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -214,6 +214,8 @@ struct virtio_gpu_fpriv {
/* virtio_ioctl.c */
#define DRM_VIRTIO_NUM_IOCTLS 10
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
+void virtio_gpu_create_context(struct drm_device *dev,
+ struct drm_file *file);
/* virtio_kms.c */
int virtio_gpu_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index baad7e1c9505..00ef9fd3fbf6 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -33,6 +33,19 @@
#include "virtgpu_drv.h"
+void virtio_gpu_create_context(struct drm_device *dev,
+ struct drm_file *file)
+{
+ struct virtio_gpu_device *vgdev = dev->dev_private;
+ struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
+ char dbgname[TASK_COMM_LEN];
+
+ get_task_comm(dbgname, current);
+ virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
+ strlen(dbgname), dbgname);
+ virtio_gpu_notify(vgdev);
+}
+
static int virtio_gpu_map_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index ad3b673f5796..f7e3712502ca 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -52,19 +52,6 @@ static void virtio_gpu_config_changed_work_func(struct
work_struct *work)
events_clear, _clear);
}
-static int virtio_gpu_context_create(struct virtio_gpu_device *vgdev,
- uint32_t nlen, const char *name)
-{
- int handle = ida_alloc(>ctx_id_ida, GFP_KERNEL);
-
- if (handle < 0)
- return handle;
- handle += 1;
- virtio_gpu_cmd_context_create(vgdev, handle, nlen, name);
- virtio_gpu_notify(vgdev);
- return handle;
-}
-
static void virtio_gpu_context_destroy(struct virtio_gpu_device *vgdev,
uint32_t ctx_id)
{
@@ -260,8 +247,7 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv;
- int id;
- char dbgname[TASK_COMM_LEN];
+ int handle;
/* can't create contexts without 3d renderer */
if (!vgdev->has_virgl_3d)
@@ -272,15 +258,15 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
drm_file *file)
if (!vfpriv)
return -ENOMEM;
- get_task_comm(dbgname, current);
- id = virtio_gpu_context_create(vgdev, strlen(dbgname), dbgname);
- if (id < 0) {
+ handle = ida_alloc(>ctx_id_ida, GFP_KERNEL);
+ if (handle < 0) {
kfree(vfpriv);
- return id;
+ return handle;
}
- vfpriv->ctx_id = id;
+ vfpriv->ctx_id = handle + 1;
file->driver_priv = vfpriv;
+ virtio_gpu_create_context(dev, file);
return 0;
}
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 4/4] drm/msm/a6xx: Use the DMA API for GMU memory objects
The GMU has very few memory allocations and uses a flat memory space so
there is no good reason to go out of our way to bypass the DMA APIs which
were basically designed for this exact secnario.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 107 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 5 +-
2 files changed, 7 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 983afea..97c9ddf 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -2,6 +2,7 @@
/* Copyright (c) 2017-2019 The Linux Foundation. All rights reserved. */
#include
+#include
#include
#include
#include
@@ -895,21 +896,10 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
static void a6xx_gmu_memory_free(struct a6xx_gmu *gmu, struct a6xx_gmu_bo *bo)
{
- int count, i;
- u64 iova;
-
if (IS_ERR_OR_NULL(bo))
return;
- count = bo->size >> PAGE_SHIFT;
- iova = bo->iova;
-
- for (i = 0; i < count; i++, iova += PAGE_SIZE) {
- iommu_unmap(gmu->domain, iova, PAGE_SIZE);
- __free_pages(bo->pages[i], 0);
- }
-
- kfree(bo->pages);
+ dma_free_attrs(gmu->dev, bo->size, bo->virt, bo->iova, bo->attrs);
kfree(bo);
}
@@ -917,94 +907,23 @@ static struct a6xx_gmu_bo *a6xx_gmu_memory_alloc(struct
a6xx_gmu *gmu,
size_t size)
{
struct a6xx_gmu_bo *bo;
- int ret, count, i;
bo = kzalloc(sizeof(*bo), GFP_KERNEL);
if (!bo)
return ERR_PTR(-ENOMEM);
bo->size = PAGE_ALIGN(size);
+ bo->attrs = DMA_ATTR_WRITE_COMBINE;
- count = bo->size >> PAGE_SHIFT;
+ bo->virt = dma_alloc_attrs(gmu->dev, bo->size, >iova, GFP_KERNEL,
+ bo->attrs);
- bo->pages = kcalloc(count, sizeof(struct page *), GFP_KERNEL);
- if (!bo->pages) {
+ if (!bo->virt) {
kfree(bo);
return ERR_PTR(-ENOMEM);
}
- for (i = 0; i < count; i++) {
- bo->pages[i] = alloc_page(GFP_KERNEL);
- if (!bo->pages[i])
- goto err;
- }
-
- bo->iova = gmu->uncached_iova_base;
-
- for (i = 0; i < count; i++) {
- ret = iommu_map(gmu->domain,
- bo->iova + (PAGE_SIZE * i),
- page_to_phys(bo->pages[i]), PAGE_SIZE,
- IOMMU_READ | IOMMU_WRITE);
-
- if (ret) {
- DRM_DEV_ERROR(gmu->dev, "Unable to map GMU buffer
object\n");
-
- for (i = i - 1 ; i >= 0; i--)
- iommu_unmap(gmu->domain,
- bo->iova + (PAGE_SIZE * i),
- PAGE_SIZE);
-
- goto err;
- }
- }
-
- bo->virt = vmap(bo->pages, count, VM_IOREMAP,
- pgprot_writecombine(PAGE_KERNEL));
- if (!bo->virt)
- goto err;
-
- /* Align future IOVA addresses on 1MB boundaries */
- gmu->uncached_iova_base += ALIGN(size, SZ_1M);
-
return bo;
-
-err:
- for (i = 0; i < count; i++) {
- if (bo->pages[i])
- __free_pages(bo->pages[i], 0);
- }
-
- kfree(bo->pages);
- kfree(bo);
-
- return ERR_PTR(-ENOMEM);
-}
-
-static int a6xx_gmu_memory_probe(struct a6xx_gmu *gmu)
-{
- int ret;
-
- /*
-* The GMU address space is hardcoded to treat the range
-* 0x6000 - 0x8000 as un-cached memory. All buffers shared
-* between the GMU and the CPU will live in this space
-*/
- gmu->uncached_iova_base = 0x6000;
-
-
- gmu->domain = iommu_domain_alloc(_bus_type);
- if (!gmu->domain)
- return -ENODEV;
-
- ret = iommu_attach_device(gmu->domain, gmu->dev);
-
- if (ret) {
- iommu_domain_free(gmu->domain);
- gmu->domain = NULL;
- }
-
- return ret;
}
/* Return the 'arc-level' for the given frequency */
@@ -1264,10 +1183,6 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
a6xx_gmu_memory_free(gmu, gmu->hfi);
- iommu_detach_device(gmu->domain, gmu->dev);
-
- iommu_domain_free(gmu->domain);
-
free_irq(gmu->gmu_irq, gmu);
free_irq(gmu->hfi_irq, gmu);
@@ -1300,11 +1215,6 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
if (ret)
goto err_put_device;
- /* Set up the IOMMU context bank */
- ret = a6xx_gmu_memory_probe(gmu);
- if (ret)
- goto err_put_device;
-
/* Allocate memory for for the HFI queues */
gmu->hfi = a6xx_gmu_memory_alloc(gmu, SZ_16K);
if (IS_ERR(gmu->hfi))
@@ -1350,11 +1260,6 @@ int
[PATCH v1 1/4] dt-bindings: display: msm: Convert GMU bindings to YAML
Convert display/msm/gmu.txt to display/msm/gmu.yaml and remove the old
text bindings.
Signed-off-by: Jordan Crouse
---
.../devicetree/bindings/display/msm/gmu.txt| 116 --
.../devicetree/bindings/display/msm/gmu.yaml | 130 +
2 files changed, 130 insertions(+), 116 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt
create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.yaml
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
b/Documentation/devicetree/bindings/display/msm/gmu.txt
deleted file mode 100644
index bf9c7a2..000
--- a/Documentation/devicetree/bindings/display/msm/gmu.txt
+++ /dev/null
@@ -1,116 +0,0 @@
-Qualcomm adreno/snapdragon GMU (Graphics management unit)
-
-The GMU is a programmable power controller for the GPU. the CPU controls the
-GMU which in turn handles power controls for the GPU.
-
-Required properties:
-- compatible: "qcom,adreno-gmu-XYZ.W", "qcom,adreno-gmu"
-for example: "qcom,adreno-gmu-630.2", "qcom,adreno-gmu"
- Note that you need to list the less specific "qcom,adreno-gmu"
- for generic matches and the more specific identifier to identify
- the specific device.
-- reg: Physical base address and length of the GMU registers.
-- reg-names: Matching names for the register regions
- * "gmu"
- * "gmu_pdc"
- * "gmu_pdc_seg"
-- interrupts: The interrupt signals from the GMU.
-- interrupt-names: Matching names for the interrupts
- * "hfi"
- * "gmu"
-- clocks: phandles to the device clocks
-- clock-names: Matching names for the clocks
- * "gmu"
- * "cxo"
- * "axi"
- * "mnoc"
-- power-domains: should be:
- <_gpucc GPU_CX_GDSC>
- <_gpucc GPU_GX_GDSC>
-- power-domain-names: Matching names for the power domains
-- iommus: phandle to the adreno iommu
-- operating-points-v2: phandle to the OPP operating points
-
-Optional properties:
-- sram: phandle to the On Chip Memory (OCMEM) that's present on some Snapdragon
-SoCs. See Documentation/devicetree/bindings/sram/qcom,ocmem.yaml.
-
-Example:
-
-/ {
- ...
-
- gmu: gmu@506a000 {
- compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
-
- reg = <0x506a000 0x3>,
- <0xb28 0x1>,
- <0xb48 0x1>;
- reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
-
- interrupts = ,
-;
- interrupt-names = "hfi", "gmu";
-
- clocks = < GPU_CC_CX_GMU_CLK>,
- < GPU_CC_CXO_CLK>,
- < GCC_DDRSS_GPU_AXI_CLK>,
- < GCC_GPU_MEMNOC_GFX_CLK>;
- clock-names = "gmu", "cxo", "axi", "memnoc";
-
- power-domains = < GPU_CX_GDSC>,
- < GPU_GX_GDSC>;
- power-domain-names = "cx", "gx";
-
- iommus = <_smmu 5>;
-
- operating-points-v2 = <_opp_table>;
- };
-};
-
-a3xx example with OCMEM support:
-
-/ {
- ...
-
- gpu: adreno@fdb0 {
- compatible = "qcom,adreno-330.2",
-"qcom,adreno";
- reg = <0xfdb0 0x1>;
- reg-names = "kgsl_3d0_reg_memory";
- interrupts = ;
- interrupt-names = "kgsl_3d0_irq";
- clock-names = "core",
- "iface",
- "mem_iface";
- clocks = < OXILI_GFX3D_CLK>,
-< OXILICX_AHB_CLK>,
-< OXILICX_AXI_CLK>;
- sram = <_sram>;
- power-domains = < OXILICX_GDSC>;
- operating-points-v2 = <_opp_table>;
- iommus = <_iommu 0>;
- };
-
- ocmem@fdd0 {
- compatible = "qcom,msm8974-ocmem";
-
- reg = <0xfdd0 0x2000>,
- <0xfec0 0x18>;
- reg-names = "ctrl",
-"mem";
-
- clocks = < RPM_SMD_OCMEMGX_CLK>,
-< OCMEMCX_OCMEMNOC_CLK>;
- clock-names = "core",
- "iface";
-
- #address-cells = <1>;
- #size-cells = <1>;
-
- gmu_sram: gmu-sram@0 {
- reg = <0x0 0x10>;
- ranges = <0 0 0xfec0 0x10>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml
b/Documentation/devicetree/bindings/display/msm/gmu.yaml
new file mode 100644
index 000..776ff92
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# Copyright 2019-2020, The Linux Foundation, All Rights Reserved
+%YAML 1.2
+---
+
+$id: "http://devicetree.org/schemas/display/msm/gmu.yaml#;
+$schema:
[PATCH v1 2/4] dt-bindings: display: msm: Add required dma-range property
The GMU node now requires a specific dma-range property so that the driver can use the DMA API to do the few memory allocations required by the GMU. This sets the IOMMU iova allocadtor to match the 'uncached' part of the GMU virtual address space. Signed-off-by: Jordan Crouse --- Documentation/devicetree/bindings/display/msm/gmu.yaml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml index 776ff92..6952d5a 100644 --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml @@ -83,6 +83,13 @@ properties: Phandle to the OPP table for the available GMU frequencies. Refer to ../../opp/opp.txt for more information. + dma-ranges: +$ref: /schemas/types.yaml#/definitions/uint32-array +description: + Describe the dma-address range for the device. This should always + describe the range between 0x6000 and 0x8000 which represents + the uncached region of the GMU address space. + required: - compatible - reg @@ -95,6 +102,7 @@ required: - power-domain-names - iommus - operating-points-v2 + - dma-ranges examples: - | @@ -127,4 +135,6 @@ examples: iommus = <_smmu 5>; operating-points-v2 = <_opp_table>; + +dma-ranges = <0 0x6000 0 0x6000 0 0x8000>; }; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/4] msm/gpu/a6xx: use the DMA-API for GMU memory allocations
When CONFIG_INIT_ON_ALLOC_DEFAULT_ON the GMU memory allocator runs afoul of cache coherency issues because it is mapped as write-combine without clearing the cache after it was zeroed. Rather than duplicate the hacky workaround we use in the GEM allocator for the same reason it turns out that we don't need to have a bespoke memory allocator for the GMU anyway. It uses a flat, global address space and there are only two relatively minor allocations anyway. In short, this is essentially what the DMA API was created for so replace a bunch of memory management code with two calls to allocate and free DMA memory and we're fine. The only wrinkle is that the memory allocations need to be in a very specific location in the GMU virtual address space so in order to get the iova allocator to do the right thing we need to specify the dma-ranges property in the device tree for the GMU node. Since we've not yet converted the GMU bindings over to YAML two patches quickly turn into four but at the end of it we have at least one bindings file converted to YAML and 99 less lines of code to worry about. Jordan Crouse (4): dt-bindings: display: msm: Convert GMU bindings to YAML dt-bindings: display: msm: Add required dma-range property arm64: dts: sdm845: Set the virtual address range for GMU allocations drm/msm/a6xx: Use the DMA API for GMU memory objects .../devicetree/bindings/display/msm/gmu.txt| 116 - .../devicetree/bindings/display/msm/gmu.yaml | 140 + arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 + drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 107 +--- drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 5 +- 5 files changed, 149 insertions(+), 221 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.yaml -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/12] drm: Put drm_display_mode on diet
On Wed, Feb 19, 2020 at 10:35:32PM +0200, Ville Syrjala wrote: > - Eliminate the second list head somehow? I think we could just convert that to a boolean, or even just borrow eg. the one totally free mode->type bit for our internal use to tag the exposed modes. That would in fact get us down to 120 bytes on 64bit machines (and 112 bytes on 32bit). The downside would be one extra loop over the modes in the getconnector ioctl to clear the stale tags. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: add led-backlight driver
Hi! > > This patch adds a led-backlight driver (led_bl), which is similar to > > pwm_bl except the driver uses a LED class driver to adjust the > > brightness in the HW. Multiple LEDs can be used for a single backlight. > > > > Signed-off-by: Tomi Valkeinen > > Signed-off-by: Jean-Jacques Hiblot > > Acked-by: Pavel Machek > > Reviewed-by: Daniel Thompson > > Acked-by: Lee Jones > > Acked-by: Tony Lindgren > > Tested-by: Tony Lindgren > > Signed-off-by: Pavel Machek > > --- > > drivers/video/backlight/Kconfig | 7 ++ > > drivers/video/backlight/Makefile | 1 + > > drivers/video/backlight/led_bl.c | 260 > > +++ > > 3 files changed, 268 insertions(+) > > create mode 100644 drivers/video/backlight/led_bl.c > > Here's the version of the driver I have. AFAICT > > default-brightness-level handling is ok, so does not need to be > > changed. > > > > Lee, it would be easiest for me if you could apply it to your tree and > > push, but given enough time I can push it to Linus, too. > > Oh you're using quoted-printable for patches.. Got it applied now, > and it still works. Below is also the related dts change that > I tested with. > > Feel free to pick the dts change too, naturally that should > not be applied before the driver. > > If you guys instead want me to pick these both into my fixes > branch, just let me know and I'll do the explaining why these > are needed as fixes. Basically we no longer have a way to enable > the LCD backlight for droid4 manually starting with v5.6-rc1 > unlike earlier. If you are willing to do that, it looks like good solution from my point of view. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/12] drm: Shrink mode->private_flags
From: Ville Syrjälä
gma500 needs 4 bits (to store a pixel multiplier) in the
mode->private_flags, i915 currently has three bits defined.
No one else uses this. Reduce the size to u8.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index b585074945b5..dadb0f3e5b0b 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -378,7 +378,7 @@ struct drm_display_mode {
* by atomic drivers since they can store any additional data by
* subclassing state structures.
*/
- int private_flags;
+ u8 private_flags;
/**
* @picture_aspect_ratio:
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/12] drm: Flatten drm_mode_vrefresh()
From: Ville Syrjälä
Remove the pointless whole-function indentation. Also don't
need to worry about negative values anymore since we switched
everything to u16.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index cc9fc52f9f7c..d20a273b4b9a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -773,24 +773,22 @@ EXPORT_SYMBOL(drm_mode_hsync);
*/
int drm_mode_vrefresh(const struct drm_display_mode *mode)
{
- int refresh = 0;
+ unsigned int num, den;
- if (mode->htotal > 0 && mode->vtotal > 0) {
- unsigned int num, den;
+ if (mode->htotal == 0 || mode->vtotal == 0)
+ return 0;
- num = mode->clock * 1000;
- den = mode->htotal * mode->vtotal;
+ num = mode->clock * 1000;
+ den = mode->htotal * mode->vtotal;
- if (mode->flags & DRM_MODE_FLAG_INTERLACE)
- num *= 2;
- if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
- den *= 2;
- if (mode->vscan > 1)
- den *= mode->vscan;
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ num *= 2;
+ if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ den *= 2;
+ if (mode->vscan > 1)
+ den *= mode->vscan;
- refresh = DIV_ROUND_CLOSEST(num, den);
- }
- return refresh;
+ return DIV_ROUND_CLOSEST(num, den);
}
EXPORT_SYMBOL(drm_mode_vrefresh);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/12] drm: Shrink {width,height}_mm to u16
From: Ville Syrjälä
Instead of supporting ~2000km wide displayes let's limit ourselves
to ~65m. That seems plenty big enough to me.
Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
10*0xfff which fits into the 16 bits.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 52e8ca613e4b..2bb2b1a8592a 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -330,7 +330,7 @@ struct drm_display_mode {
* Addressable size of the output in mm, projectors should set this to
* 0.
*/
- int width_mm;
+ u16 width_mm;
/**
* @height_mm:
@@ -338,7 +338,7 @@ struct drm_display_mode {
* Addressable size of the output in mm, projectors should set this to
* 0.
*/
- int height_mm;
+ u16 height_mm;
/**
* @crtc_clock:
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/12] drm: Make mode->flags u32
From: Ville Syrjälä
The mode flags are direclty exposed in the uapi as u32. Use the
same size type to store them internally.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 5c20285cc317..b28c0234fcd7 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -322,7 +322,7 @@ struct drm_display_mode {
* - DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF: frame split into left and
*right parts.
*/
- unsigned int flags;
+ u32 flags;
/**
* @width_mm:
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] drm: pahole struct drm_display_mode
From: Ville Syrjälä
Reorganize drm_display_mode to eliminate all the holes.
We'll put all the actual timings to the start of the
struct and all the extra junk to the end.
Gets the size down to 136 bytes on 64bit and 120 bytes on
32bit. With a bit more work we should be able to get this
below the two cacheline mark even on 64bit.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 139
1 file changed, 70 insertions(+), 69 deletions(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index dadb0f3e5b0b..fded81306a47 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -222,56 +222,6 @@ enum drm_mode_status {
* For printing you can use %DRM_MODE_FMT and DRM_MODE_ARG().
*/
struct drm_display_mode {
- /**
-* @head:
-*
-* struct list_head for mode lists.
-*/
- struct list_head head;
-
- /**
-* @name:
-*
-* Human-readable name of the mode, filled out with drm_mode_set_name().
-*/
- char name[DRM_DISPLAY_MODE_LEN];
-
- /**
-* @status:
-*
-* Status of the mode, used to filter out modes not supported by the
-* hardware. See enum _mode_status.
-*/
- enum drm_mode_status status;
-
- /**
-* @type:
-*
-* A bitmask of flags, mostly about the source of a mode. Possible flags
-* are:
-*
-* - DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
-*resolution of an LCD panel. There should only be one preferred
-*mode per connector at any given time.
-* - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
-*them really. Drivers must set this bit for all modes they create
-*and expose to userspace.
-* - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
-*
-* Plus a big list of flags which shouldn't be used at all, but are
-* still around since these flags are also used in the userspace ABI.
-* We no longer accept modes with these types though:
-*
-* - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, unused.
-*Use DRM_MODE_TYPE_DRIVER instead.
-* - DRM_MODE_TYPE_DEFAULT: Again a leftover, use
-*DRM_MODE_TYPE_PREFERRED instead.
-* - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
-*which are stuck around for hysterical raisins only. No one has an
-*idea what they were meant for. Don't use.
-*/
- u8 type;
-
/**
* @clock:
*
@@ -324,22 +274,6 @@ struct drm_display_mode {
*/
u32 flags;
- /**
-* @width_mm:
-*
-* Addressable size of the output in mm, projectors should set this to
-* 0.
-*/
- u16 width_mm;
-
- /**
-* @height_mm:
-*
-* Addressable size of the output in mm, projectors should set this to
-* 0.
-*/
- u16 height_mm;
-
/**
* @crtc_clock:
*
@@ -370,6 +304,50 @@ struct drm_display_mode {
u16 crtc_vsync_end;
u16 crtc_vtotal;
+ /**
+* @width_mm:
+*
+* Addressable size of the output in mm, projectors should set this to
+* 0.
+*/
+ u16 width_mm;
+
+ /**
+* @height_mm:
+*
+* Addressable size of the output in mm, projectors should set this to
+* 0.
+*/
+ u16 height_mm;
+
+ /**
+* @type:
+*
+* A bitmask of flags, mostly about the source of a mode. Possible flags
+* are:
+*
+* - DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
+*resolution of an LCD panel. There should only be one preferred
+*mode per connector at any given time.
+* - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
+*them really. Drivers must set this bit for all modes they create
+*and expose to userspace.
+* - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
+*
+* Plus a big list of flags which shouldn't be used at all, but are
+* still around since these flags are also used in the userspace ABI.
+* We no longer accept modes with these types though:
+*
+* - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, unused.
+*Use DRM_MODE_TYPE_DRIVER instead.
+* - DRM_MODE_TYPE_DEFAULT: Again a leftover, use
+*DRM_MODE_TYPE_PREFERRED instead.
+* - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
+*which are stuck around for hysterical raisins only. No one has an
+*idea what they were meant for. Don't use.
+*/
+ u8 type;
+
/**
* @private_flags:
[PATCH 07/12] drm: Shrink mode->type to u8
From: Ville Syrjälä
We only have 7 bits defined for mode->type. Shrink the storage to u8.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 2bb2b1a8592a..5c20285cc317 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -270,7 +270,7 @@ struct drm_display_mode {
*which are stuck around for hysterical raisins only. No one has an
*idea what they were meant for. Don't use.
*/
- unsigned int type;
+ u8 type;
/**
* @clock:
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Ville Syrjälä
The driver never sets mode->private_flags so copying
it back and forth is entirely pointless. Stop doing it.
Also drop private_flags from the tracepoint.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 +
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +++
2 files changed, 5 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 58d3400668f5..4511e2ba3680 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -500,23 +500,6 @@ void dpu_encoder_helper_split_config(
}
}
-static void _dpu_encoder_adjust_mode(struct drm_connector *connector,
- struct drm_display_mode *adj_mode)
-{
- struct drm_display_mode *cur_mode;
-
- if (!connector || !adj_mode)
- return;
-
- list_for_each_entry(cur_mode, >modes, head) {
- if (cur_mode->vdisplay == adj_mode->vdisplay &&
- cur_mode->hdisplay == adj_mode->hdisplay &&
- drm_mode_vrefresh(cur_mode) == drm_mode_vrefresh(adj_mode))
{
- adj_mode->private_flags |= cur_mode->private_flags;
- }
- }
-}
-
static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
@@ -580,15 +563,6 @@ static int dpu_encoder_virt_atomic_check(
adj_mode = _state->adjusted_mode;
trace_dpu_enc_atomic_check(DRMID(drm_enc));
- /*
-* display drivers may populate private fields of the drm display mode
-* structure while registering possible modes of a connector with DRM.
-* These private fields are not populated back while DRM invokes
-* the mode_set callbacks. This module retrieves and populates the
-* private fields of the given mode.
-*/
- _dpu_encoder_adjust_mode(conn_state->connector, adj_mode);
-
/* perform atomic check on the first physical encoder (master) */
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
@@ -623,8 +597,7 @@ static int dpu_encoder_virt_atomic_check(
}
}
- trace_dpu_enc_atomic_check_flags(DRMID(drm_enc), adj_mode->flags,
- adj_mode->private_flags);
+ trace_dpu_enc_atomic_check_flags(DRMID(drm_enc), adj_mode->flags);
return ret;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
index eecfe9b3199e..6714b088970f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
@@ -327,20 +327,18 @@ DEFINE_EVENT(dpu_enc_keyval_template,
dpu_enc_trigger_start,
);
TRACE_EVENT(dpu_enc_atomic_check_flags,
- TP_PROTO(uint32_t drm_id, unsigned int flags, int private_flags),
- TP_ARGS(drm_id, flags, private_flags),
+ TP_PROTO(uint32_t drm_id, unsigned int flags),
+ TP_ARGS(drm_id, flags),
TP_STRUCT__entry(
__field(uint32_t, drm_id )
__field(unsigned int, flags )
- __field(int,private_flags )
),
TP_fast_assign(
__entry->drm_id = drm_id;
__entry->flags = flags;
- __entry->private_flags = private_flags;
),
- TP_printk("id=%u, flags=%u, private_flags=%d",
- __entry->drm_id, __entry->flags, __entry->private_flags)
+ TP_printk("id=%u, flags=%u",
+ __entry->drm_id, __entry->flags)
);
DECLARE_EVENT_CLASS(dpu_enc_id_enable_template,
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/12] drm: Shrink drm_display_mode timings
From: Ville Syrjälä
Store the timings (apart from the clock) as u16. The uapi mode
struct already uses u16 for everything so using something bigger
internally doesn't really help us.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 7 --
include/drm/drm_modes.h | 46 ++---
2 files changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 0e7c9ba241c4..cc9fc52f9f7c 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1917,13 +1917,6 @@ EXPORT_SYMBOL(drm_mode_create_from_cmdline_mode);
void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,
const struct drm_display_mode *in)
{
- WARN(in->hdisplay > USHRT_MAX || in->hsync_start > USHRT_MAX ||
-in->hsync_end > USHRT_MAX || in->htotal > USHRT_MAX ||
-in->hskew > USHRT_MAX || in->vdisplay > USHRT_MAX ||
-in->vsync_start > USHRT_MAX || in->vsync_end > USHRT_MAX ||
-in->vtotal > USHRT_MAX || in->vscan > USHRT_MAX,
-"timing values too large for mode info\n");
-
out->clock = in->clock;
out->hdisplay = in->hdisplay;
out->hsync_start = in->hsync_start;
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index b28c0234fcd7..b585074945b5 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -278,16 +278,16 @@ struct drm_display_mode {
* Pixel clock in kHz.
*/
int clock; /* in kHz */
- int hdisplay;
- int hsync_start;
- int hsync_end;
- int htotal;
- int hskew;
- int vdisplay;
- int vsync_start;
- int vsync_end;
- int vtotal;
- int vscan;
+ u16 hdisplay;
+ u16 hsync_start;
+ u16 hsync_end;
+ u16 htotal;
+ u16 hskew;
+ u16 vdisplay;
+ u16 vsync_start;
+ u16 vsync_end;
+ u16 vtotal;
+ u16 vscan;
/**
* @flags:
*
@@ -356,19 +356,19 @@ struct drm_display_mode {
* difference is exactly a factor of 10.
*/
int crtc_clock;
- int crtc_hdisplay;
- int crtc_hblank_start;
- int crtc_hblank_end;
- int crtc_hsync_start;
- int crtc_hsync_end;
- int crtc_htotal;
- int crtc_hskew;
- int crtc_vdisplay;
- int crtc_vblank_start;
- int crtc_vblank_end;
- int crtc_vsync_start;
- int crtc_vsync_end;
- int crtc_vtotal;
+ u16 crtc_hdisplay;
+ u16 crtc_hblank_start;
+ u16 crtc_hblank_end;
+ u16 crtc_hsync_start;
+ u16 crtc_hsync_end;
+ u16 crtc_htotal;
+ u16 crtc_hskew;
+ u16 crtc_vdisplay;
+ u16 crtc_vblank_start;
+ u16 crtc_vblank_end;
+ u16 crtc_vsync_start;
+ u16 crtc_vsync_end;
+ u16 crtc_vtotal;
/**
* @private_flags:
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh
From: Ville Syrjälä
htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index ff59c641fa80..e7b58097ccdc 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -139,7 +139,7 @@ static void decon_ctx_remove(struct decon_context *ctx)
static u32 decon_calc_clkdiv(struct decon_context *ctx,
const struct drm_display_mode *mode)
{
- unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
+ unsigned long ideal_clk = mode->clock;
u32 clkdiv;
/* Find the clock divider value that gets us closest to ideal_clk */
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/12] drm: Nuke mode->hsync
From: Ville Syrjälä
Let's just calculate the hsync rate on demand. No point in wasting
space storing it and risking the cached value getting out of sync
with reality.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 14 ++
drivers/gpu/drm/i915/display/intel_display.c | 1 -
include/drm/drm_modes.h | 10 --
3 files changed, 2 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d4d64518e11b..fe7e872a6239 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -752,24 +752,14 @@ EXPORT_SYMBOL(drm_mode_set_name);
* @mode: mode
*
* Returns:
- * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates the
- * value first if it is not yet set.
+ * @modes's hsync rate in kHz, rounded to the nearest integer
*/
int drm_mode_hsync(const struct drm_display_mode *mode)
{
- unsigned int calc_val;
-
- if (mode->hsync)
- return mode->hsync;
-
if (mode->htotal <= 0)
return 0;
- calc_val = (mode->clock * 1000) / mode->htotal; /* hsync in Hz */
- calc_val += 500;/* round to 1000Hz */
- calc_val /= 1000; /* truncate to kHz */
-
- return calc_val;
+ return DIV_ROUND_CLOSEST(mode->clock, mode->htotal);
}
EXPORT_SYMBOL(drm_mode_hsync);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ee7d54ccd3e6..fab914819489 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8867,7 +8867,6 @@ void intel_mode_from_pipe_config(struct drm_display_mode
*mode,
mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
- mode->hsync = drm_mode_hsync(mode);
mode->vrefresh = drm_mode_vrefresh(mode);
drm_mode_set_name(mode);
}
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 99134d4f35eb..7dab7f172431 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -390,16 +390,6 @@ struct drm_display_mode {
*/
int vrefresh;
- /**
-* @hsync:
-*
-* Horizontal refresh rate, for debug output in human readable form. Not
-* used in a functional way.
-*
-* This value is in kHz.
-*/
- int hsync;
-
/**
* @picture_aspect_ratio:
*
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/12] drm/i915: Introduce some local intel_dp variables
From: Ville Syrjälä
The drrs code dereferences mode->vrefresh via some really long chain
of structures/pointers. Couldn't get coccinelle to see through all
that so let's add some local variables to help it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 82baf5aba84b..f9e1361460d8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7196,6 +7196,7 @@ static void intel_edp_drrs_downclock_work(struct
work_struct *work)
void intel_edp_drrs_invalidate(struct drm_i915_private *dev_priv,
unsigned int frontbuffer_bits)
{
+ struct intel_dp *intel_dp;
struct drm_crtc *crtc;
enum pipe pipe;
@@ -7205,12 +7206,14 @@ void intel_edp_drrs_invalidate(struct drm_i915_private
*dev_priv,
cancel_delayed_work(_priv->drrs.work);
mutex_lock(_priv->drrs.mutex);
- if (!dev_priv->drrs.dp) {
+
+ intel_dp = dev_priv->drrs.dp;
+ if (!intel_dp) {
mutex_unlock(_priv->drrs.mutex);
return;
}
- crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+ crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
pipe = to_intel_crtc(crtc)->pipe;
frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
@@ -7219,7 +7222,7 @@ void intel_edp_drrs_invalidate(struct drm_i915_private
*dev_priv,
/* invalidate means busy screen hence upclock */
if (frontbuffer_bits && dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR)
intel_dp_set_drrs_state(dev_priv, to_intel_crtc(crtc)->config,
-
dev_priv->drrs.dp->attached_connector->panel.fixed_mode->vrefresh);
+
intel_dp->attached_connector->panel.fixed_mode->vrefresh);
mutex_unlock(_priv->drrs.mutex);
}
@@ -7239,6 +7242,7 @@ void intel_edp_drrs_invalidate(struct drm_i915_private
*dev_priv,
void intel_edp_drrs_flush(struct drm_i915_private *dev_priv,
unsigned int frontbuffer_bits)
{
+ struct intel_dp *intel_dp;
struct drm_crtc *crtc;
enum pipe pipe;
@@ -7248,12 +7252,14 @@ void intel_edp_drrs_flush(struct drm_i915_private
*dev_priv,
cancel_delayed_work(_priv->drrs.work);
mutex_lock(_priv->drrs.mutex);
- if (!dev_priv->drrs.dp) {
+
+ intel_dp = dev_priv->drrs.dp;
+ if (!intel_dp) {
mutex_unlock(_priv->drrs.mutex);
return;
}
- crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+ crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
pipe = to_intel_crtc(crtc)->pipe;
frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
@@ -7262,7 +7268,7 @@ void intel_edp_drrs_flush(struct drm_i915_private
*dev_priv,
/* flush means busy screen hence upclock */
if (frontbuffer_bits && dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR)
intel_dp_set_drrs_state(dev_priv, to_intel_crtc(crtc)->config,
-
dev_priv->drrs.dp->attached_connector->panel.fixed_mode->vrefresh);
+
intel_dp->attached_connector->panel.fixed_mode->vrefresh);
/*
* flush also means no more activity hence schedule downclock, if all
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä
struct drm_display_mode is extremely fat. Put it on diet.
Some stats for the whole series:
64bit sizeof(struct drm_display_mode):
200 -> 136 bytes (-32%)
64bit bloat-o-meter -c drm.ko:
add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
Function old new delta
...
Total: Before=189430, After=188779, chg -0.34%
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Data old new delta
Total: Before=11667, After=11667, chg +0.00%
add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
RO Data old new delta
edid_4k_modes 1000 680-320
edid_est_modes 34002312 -1088
edid_cea_modes_193 54003672 -1728
drm_dmt_modes 17600 11968 -5632
edid_cea_modes_1 25400 17272 -8128
Total: Before=71239, After=54343, chg -23.72%
64bit bloat-o-meter drm.ko:
add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
...
Total: Before=272336, After=254789, chg -6.44%
32bit sizeof(struct drm_display_mode):
184 -> 120 bytes (-34%)
32bit bloat-o-meter -c drm.ko
add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
Function old new delta
...
Total: Before=172359, After=171734, chg -0.36%
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Data old new delta
Total: Before=4227, After=4227, chg +0.00%
add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
RO Data old new delta
edid_4k_modes920 600-320
edid_est_modes 31282040 -1088
edid_cea_modes_193 49683240 -1728
drm_dmt_modes 16192 10560 -5632
edid_cea_modes_1 23368 15240 -8128
Total: Before=59230, After=42334, chg -28.53%
32bit bloat-o-meter drm.ko:
add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
...
Total: Before=235816, After=218295, chg -7.43%
Some ideas for further reduction:
- Convert mode->name to a pointer (saves 24/28 bytes in the
struct but would often require a heap alloc for the name (though
typical mode name is <10 bytes so still overall win perhaps)
- Get rid of mode->name entirely? I guess setcrtc & co. is the only
place where we have to preserve the user provided name, elsewhere
could pehaps just generate on demand? Not sure how tricky this
would get.
- Eliminate the second list head somehow?
Pie in the sky idea:
- Eliminate the normal vs. crtc_ dual timings where not needed. Ie.
Just use two structs if necessary instead of packing both to the
same struct. Can't imagine this being an easy conversion.
Entire series available here:
git://github.com/vsyrjala/linux.git drm_mode_diet_4
Ville Syrjälä (12):
drm: Nuke mode->hsync
drm/exynos: Use mode->clock instead of reverse calculating it from the
vrefresh
drm/i915: Introduce some local intel_dp variables
drm: Nuke mode->vrefresh
drm/msm/dpu: Stop copying around mode->private_flags
drm: Shrink {width,height}_mm to u16
drm: Shrink mode->type to u8
drm: Make mode->flags u32
drm: Shrink drm_display_mode timings
drm: Flatten drm_mode_vrefresh()
drm: Shrink mode->private_flags
drm: pahole struct drm_display_mode
drivers/gpu/drm/bridge/sii902x.c | 2 +-
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_edid.c| 328 +-
drivers/gpu/drm/drm_modes.c | 54 +--
drivers/gpu/drm/drm_probe_helper.c| 3 -
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 5 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
drivers/gpu/drm/i2c/ch7006_mode.c | 1 -
drivers/gpu/drm/i915/display/intel_display.c | 2 -
.../drm/i915/display/intel_display_debugfs.c | 4 +-
drivers/gpu/drm/i915/display/intel_dp.c | 24 +-
drivers/gpu/drm/i915/display/intel_tv.c | 3 -
drivers/gpu/drm/mcde/mcde_dsi.c | 6 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 5 +-
drivers/gpu/drm/panel/panel-arm-versatile.c | 4 -
drivers/gpu/drm/panel/panel-boe-himax8279d.c | 3 +-
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 6 +-
.../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 3 +-
.../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 +-
Re: [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 7:19 PM Greg Kroah-Hartman wrote: > > On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote: > > Hi Greg, > > > > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > > > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > > > > quality. The biggest wrong pattern is that developers use devm_, > > > > > > > which > > > > > > > ties the release action to the underlying struct device, whereas > > > > > > > all the userspace visible stuff attached to a drm_device can long > > > > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > > > > files and mmap'ed buffers). Give people what they want, but with > > > > > > > more > > > > > > > correctness. > > > > > > > > > > > > > > Mostly copied from devres.c, with types adjusted to fit > > > > > > > drm_device and > > > > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > > > > the types don't match code sharing looked like a hopeless > > > > > > > endeavour. > > > > > > > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > > > > actions (but kfree exists, we'll need that soon). Plus all > > > > > > > specific to > > > > > > > drm_device ofc, including the logging. Which I didn't bother to > > > > > > > make > > > > > > > compile-time optional, since none of the other drm logging is > > > > > > > compile > > > > > > > time optional either. > > > > > > > > > > > > > > One tricky bit here is the chicken between allocating your > > > > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > > > > allocation registered before drm_dev_init registers any of its own > > > > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > > > > drm_device is emebedded into the overall structure, and by the > > > > > > > time it > > > > > > > returns it'll all be too late. And forcing drivers to be able > > > > > > > clean up > > > > > > > everything except the one kzalloc is silly. > > > > > > > > > > > > > > Work around this by having a very special final_kfree pointer. > > > > > > > This > > > > > > > also avoids troubles with the list head possibly disappearing from > > > > > > > underneath us when we release all resources attached to the > > > > > > > drm_device. > > > > > > > > > > > > This is all a very good idea ! Many subsystems are plagged by > > > > > > drivers > > > > > > using devm_k*alloc to allocate data accessible by userspace. Since > > > > > > the > > > > > > introduction of devm_*, we've likely reduced the number of memory > > > > > > leaks, > > > > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > > > > some drivers that used .release() callbacks correctly being naively > > > > > > converted to incorrect devm_* usage :-( > > > > > > > > > > > > This leads me to a question: if other subsystems have the same > > > > > > problem, > > > > > > could we turn this implementation into something more generic ? It > > > > > > doesn't have to be done right away and shouldn't block merging this > > > > > > series, but I think it would be very useful. > > > > > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > > > (driver_memory?) > > > > > > > > > > And yes, I think it's much better than devm_* for the obvious reasons > > > > > of > > > > > this being needed here. > > > > > > > > There's two reasons I went with copypasta instead of trying to share > > > > code: > > > > - Type checking, I definitely don't want people to mix up devm_ with > > > > drmm_. But even if we do a drv_m that subsystems could embed we do > > > > have quite a few different types of component drivers (and with > > > > drm_panel and drm_bridge even standardized), and I don't want people > > > > to be able to pass the wrong kind of struct to e.g. a managed > > > > drmm_connector_init - it really needs to be the drm_device, not a > > > > panel or bridge or something else. > > > > > > Fair enough, that makes sense. > > > > > > > - We could still share the code as a kind of implementation/backend > > > > library. But it's not much, and with embedding I could use the drm > > > > device logging stuff which is kinda nice. But if there's more demand > > > > for this I can definitely see the point in sharing this, as Laurent > > > > pointed out with the tiny optimization with not allocating a NULL void > > > > * that I've done (and screwed up) it's not entirely trivial code. > > > > > > I think moving over time to having this be a backend library is good. > > >
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 --- Comment #10 from Noel Maersk (veox+ker...@veox.pw) --- That came in negative. Looks like it's 1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4 indeed. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/52] mm/sl[uo]b: export __kmalloc_track(_node)_caller
On Wed, 19 Feb 2020 11:20:31 +0100 Daniel Vetter wrote: > tracker in drm for stuff that's tied to the lifetime of a drm_device, > not the underlying struct device. Kinda like devres, but for drm. > > ... > > Ack for merging through drm trees very much appreciated. Acked-by: Andrew Morton ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
On Wed, Feb 19, 2020 at 1:52 AM Tian, Kevin wrote: > > > From: Paolo Bonzini > > Sent: Wednesday, February 19, 2020 12:29 AM > > > > On 14/02/20 23:03, Sean Christopherson wrote: > > >> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu wrote: > > >>> AFAICT, it is currently allowed on ARM (verified) and AMD (not > > >>> verified, but svm_get_mt_mask returns 0 which supposedly means the > > NPT > > >>> does not restrict what the guest PAT can do). This diff would do the > > >>> trick for Intel without needing any uapi change: > > >> I would be concerned about Intel CPU errata such as SKX40 and SKX59. > > > The part KVM cares about, #MC, is already addressed by forcing UC for > > MMIO. > > > The data corruption issue is on the guest kernel to correctly use WC > > > and/or non-temporal writes. > > > > What about coherency across live migration? The userspace process would > > use cached accesses, and also a WBINVD could potentially corrupt guest > > memory. > > > > In such case the userspace process possibly should conservatively use > UC mapping, as if for MMIO regions on a passthrough device. However > there remains a problem. the definition of KVM_MEM_DMA implies > favoring guest setting, which could be whatever type in concept. Then > assuming UC is also problematic. I'm not sure whether inventing another > interface to query effective memory type from KVM is a good idea. There > is no guarantee that the guest will use same type for every page in the > same slot, then such interface might be messy. Alternatively, maybe > we could just have an interface for KVM userspace to force memory type > for a given slot, if it is mainly used in para-virtualized scenarios (e.g. > virtio-gpu) where the guest is enlightened to use a forced type (e.g. WC)? KVM forcing the memory type for a given slot should work too. But the ignore-guest-pat bit seems to be Intel-specific. We will need to define how the second-level page attributes combine with the guest page attributes somehow. KVM should in theory be able to tell that the userspace region is mapped with a certain memory type and can force the same memory type onto the guest. The userspace does not need to be involved. But that sounds very slow? This may be a dumb question, but would it help to add KVM_SET_DMA_BUF and let KVM negotiate the memory type with the in-kernel GPU drivers? > > Thanks > Kevin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/3] KVM: x86: honor guest memory type
On Wed, Feb 19, 2020 at 2:00 AM Tian, Kevin wrote: > > > From: Chia-I Wu > > Sent: Saturday, February 15, 2020 5:15 AM > > > > On Fri, Feb 14, 2020 at 2:26 AM Paolo Bonzini wrote: > > > > > > On 13/02/20 23:18, Chia-I Wu wrote: > > > > > > > > The bug you mentioned was probably this one > > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=104091 > > > > > > Yes, indeed. > > > > > > > From what I can tell, the commit allowed the guests to create cached > > > > mappings to MMIO regions and caused MCEs. That is different than what > > > > I need, which is to allow guests to create uncached mappings to system > > > > ram (i.e., !kvm_is_mmio_pfn) when the host userspace also has > > uncached > > > > mappings. But it is true that this still allows the userspace & guest > > > > kernel to create conflicting memory types. > > > > > > Right, the question is whether the MCEs were tied to MMIO regions > > > specifically and if so why. > > > > > > An interesting remark is in the footnote of table 11-7 in the SDM. > > > There, for the MTRR (EPT for us) memory type UC you can read: > > > > > > The UC attribute comes from the MTRRs and the processors are not > > > required to snoop their caches since the data could never have > > > been cached. This attribute is preferred for performance reasons. > > > > > > There are two possibilities: > > > > > > 1) the footnote doesn't apply to UC mode coming from EPT page tables. > > > That would make your change safe. > > > > > > 2) the footnote also applies when the UC attribute comes from the EPT > > > page tables rather than the MTRRs. In that case, the host should use > > > UC as the EPT page attribute if and only if it's consistent with the host > > > MTRRs; it would be more or less impossible to honor UC in the guest > > MTRRs. > > > In that case, something like the patch below would be needed. > > > > > > It is not clear from the manual why the footnote would not apply to WC; > > that > > > is, the manual doesn't say explicitly that the processor does not do > > snooping > > > for accesses to WC memory. But I guess that must be the case, which is > > why I > > > used MTRR_TYPE_WRCOMB in the patch below. > > > > > > Either way, we would have an explanation of why creating cached mapping > > to > > > MMIO regions would, and why in practice we're not seeing MCEs for guest > > RAM > > > (the guest would have set WB for that memory in its MTRRs, not UC). > > > > > > One thing you didn't say: how would userspace use KVM_MEM_DMA? On > > which > > > regions would it be set? > > It will be set for shmems that are mapped WC. > > > > GPU/DRM drivers allocate shmems as DMA-able gpu buffers and allow the > > userspace to map them cached or WC (I915_MMAP_WC or > > AMDGPU_GEM_CREATE_CPU_GTT_USWC for example). When a shmem is > > mapped > > WC and is made available to the guest, we would like the ability to > > map the region WC in the guest. > > Curious... How is such slot exposed to the guest? A reserved memory > region? Is it static or might be dynamically added? The plan is for virtio-gpu device to reserve a huge memory region in the guest. Memslots may be added dynamically or statically to back the region. Dynamic: the host adds a 16MB GPU allocation as a memslot at a time. The guest kernel suballocates from the 16MB pool. Static: the host creates a huge PROT_NONE memfd and adds it as a memslot. GPU allocations are mremap()ed into the memfd region to provide the real mapping. These options are considered because the number of memslots are limited: 32 on ARM and 509 on x86. If the number of memslots could be made larger (4096 or more), we would also consider adding each individual GPU allocation as a memslot. These are actually questions we need feedback. Besides, GPU allocations can be assumed to be kernel dma-bufs in this context. I wonder if it makes sense to have a variation of KVM_SET_USER_MEMORY_REGION that takes dma-bufs. > > Thanks > Kevin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] backlight: add led-backlight driver
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is similar to
pwm_bl except the driver uses a LED class driver to adjust the
brightness in the HW. Multiple LEDs can be used for a single backlight.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques Hiblot
Acked-by: Pavel Machek
Reviewed-by: Daniel Thompson
Acked-by: Lee Jones
Acked-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Pavel Machek
---
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/led_bl.c | 260 +++
3 files changed, 268 insertions(+)
create mode 100644 drivers/video/backlight/led_bl.c
Hi!
Here's the version of the driver I have. AFAICT
default-brightness-level handling is ok, so does not need to be
changed.
Lee, it would be easiest for me if you could apply it to your tree and
push, but given enough time I can push it to Linus, too.
Thanks,
Pavel
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 403707a3e503..0093bbd0d326 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -456,6 +456,13 @@ config BACKLIGHT_RAVE_SP
help
Support for backlight control on RAVE SP device.
+config BACKLIGHT_LED
+ tristate "Generic LED based Backlight Driver"
+ depends on LEDS_CLASS && OF
+ help
+ If you have a LCD backlight adjustable by LED class driver, say Y
+ to enable this driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endmenu
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 6f8777037c37..0c1a1524627a 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
obj-$(CONFIG_BACKLIGHT_ARCXCNN)+= arcxcnn_bl.o
obj-$(CONFIG_BACKLIGHT_RAVE_SP)+= rave-sp-backlight.o
+obj-$(CONFIG_BACKLIGHT_LED)+= led_bl.o
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
new file mode 100644
index ..3f66549997c8
--- /dev/null
+++ b/drivers/video/backlight/led_bl.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2015-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Tomi Valkeinen
+ *
+ * Based on pwm_bl.c
+ */
+
+#include
+#include
+#include
+#include
+
+struct led_bl_data {
+ struct device *dev;
+ struct backlight_device *bl_dev;
+ struct led_classdev **leds;
+ boolenabled;
+ int nb_leds;
+ unsigned int*levels;
+ unsigned intdefault_brightness;
+ unsigned intmax_brightness;
+};
+
+static void led_bl_set_brightness(struct led_bl_data *priv, int level)
+{
+ int i;
+ int bkl_brightness;
+
+ if (priv->levels)
+ bkl_brightness = priv->levels[level];
+ else
+ bkl_brightness = level;
+
+ for (i = 0; i < priv->nb_leds; i++)
+ led_set_brightness(priv->leds[i], bkl_brightness);
+
+ priv->enabled = true;
+}
+
+static void led_bl_power_off(struct led_bl_data *priv)
+{
+ int i;
+
+ if (!priv->enabled)
+ return;
+
+ for (i = 0; i < priv->nb_leds; i++)
+ led_set_brightness(priv->leds[i], LED_OFF);
+
+ priv->enabled = false;
+}
+
+static int led_bl_update_status(struct backlight_device *bl)
+{
+ struct led_bl_data *priv = bl_get_data(bl);
+ int brightness = bl->props.brightness;
+
+ if (bl->props.power != FB_BLANK_UNBLANK ||
+ bl->props.fb_blank != FB_BLANK_UNBLANK ||
+ bl->props.state & BL_CORE_FBBLANK)
+ brightness = 0;
+
+ if (brightness > 0)
+ led_bl_set_brightness(priv, brightness);
+ else
+ led_bl_power_off(priv);
+
+ return 0;
+}
+
+static const struct backlight_ops led_bl_ops = {
+ .update_status = led_bl_update_status,
+};
+
+static int led_bl_get_leds(struct device *dev,
+ struct led_bl_data *priv)
+{
+ int i, nb_leds, ret;
+ struct device_node *node = dev->of_node;
+ struct led_classdev **leds;
+ unsigned int max_brightness;
+ unsigned int default_brightness;
+
+ ret = of_count_phandle_with_args(node, "leds", NULL);
+ if (ret < 0) {
+ dev_err(dev, "Unable to get led count\n");
+ return -EINVAL;
+ }
+
+ nb_leds = ret;
+ if (nb_leds < 1) {
+ dev_err(dev, "At least one LED must be specified!\n");
+ return -EINVAL;
+ }
+
+ leds = devm_kzalloc(dev, sizeof(struct led_classdev *) * nb_leds,
+
Re: [PATCH v2 0/3] Improve MIPS Magnum support
Hello,
Finn Thain wrote:
> A few minor patches are needed to more easily boot a MIPS Magnum build
> under QEMU. This series fixes a build failure in the g364fb driver and
> modifies jazz_defconfig for use with 'qemu-system-mips64el -M magnum'.
>
> Note that QEMU's dp8393x implementation has bugs, one of which prevents
> the Linux jazzsonic driver from probing the chip. I have fixed the bugs
> that I know of in a series of patches at,
> https://github.com/fthain/qemu/commits/sonic
>
> Changed since v1:
> - Added reviewed-by and tested-by tags from Philippe Mathieu-Daudé.
> - Rebased.
>
>
> Finn Thain (3):
> fbdev/g364fb: Fix build failure
> mips/jazz: Remove redundant settings and shrink jazz_defconfig
> mips/jazz: Update jazz_defconfig for MIPS Magnum
Series applied to mips-next.
> fbdev/g364fb: Fix build failure
> commit c584f9532115
> https://git.kernel.org/mips/c/c584f9532115
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Finn Thain
> Acked-by: Bartlomiej Zolnierkiewicz
> Tested-by: Philippe Mathieu-Daudé
> Signed-off-by: Paul Burton
>
> mips/jazz: Remove redundant settings and shrink jazz_defconfig
> commit a7047b8dd098
> https://git.kernel.org/mips/c/a7047b8dd098
>
> Tested-by: Philippe Mathieu-Daudé
> Signed-off-by: Finn Thain
> Signed-off-by: Paul Burton
>
> mips/jazz: Update jazz_defconfig for MIPS Magnum
> commit 91f40e896444
> https://git.kernel.org/mips/c/91f40e896444
>
> Reviewed-by: Philippe Mathieu-Daudé
> Tested-by: Philippe Mathieu-Daudé
> Signed-off-by: Finn Thain
> Signed-off-by: Paul Burton
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paulbur...@kernel.org to report it. ]
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d: make v3d_debugfs_init return 0
On Tue, Feb 18, 2020 at 9:28 AM Wambui Karuga wrote:
>
> As drm_debugfs_create_files should return void, remove its use as the
> return value of v3d_debugfs_init and have the function return 0
> directly.
If we're going this route, then this function should be returning void, too.
>
> Signed-off-by: Wambui Karuga
> ---
> drivers/gpu/drm/v3d/v3d_debugfs.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
> b/drivers/gpu/drm/v3d/v3d_debugfs.c
> index 9e953ce64ef7..57dded6a3957 100644
> --- a/drivers/gpu/drm/v3d/v3d_debugfs.c
> +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
> @@ -261,7 +261,8 @@ static const struct drm_info_list v3d_debugfs_list[] = {
> int
> v3d_debugfs_init(struct drm_minor *minor)
> {
> - return drm_debugfs_create_files(v3d_debugfs_list,
> - ARRAY_SIZE(v3d_debugfs_list),
> - minor->debugfs_root, minor);
> + drm_debugfs_create_files(v3d_debugfs_list,
> +ARRAY_SIZE(v3d_debugfs_list),
> +minor->debugfs_root, minor);
> + return 0;
> }
> --
> 2.25.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/52] drm/v3d: Use drmm_add_final_kfree
On Wed, Feb 19, 2020 at 2:21 AM Daniel Vetter wrote: > > With this we can drop the final kfree from the release function. > > I also noticed that the unwind code is wrong, after drm_dev_init the > drm_device owns the v3d allocation, so the kfree(v3d) is a double-free. > Reorder the setup to fix this issue. > > After a bit more prep in drivers and drm core v3d should be able to > switch over to devm_drm_dev_init, which should clean this up further. > > Signed-off-by: Daniel Vetter > Cc: Eric Anholt Acked-by: Eric Anholt ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5 v5] drm/virtio: track whether or not a context has been initiated
Patch 1-4 are
Reviewed-by: Chia-I Wu
I think we can drop patch 5 for now.
On Wed, Feb 19, 2020 at 9:56 AM Gurchetan Singh
wrote:
>
> Use an atomic variable to track whether a context has been
> initiated.
>
> v5: Fix possible race and sleep via mutex (@olv)
>
> Signed-off-by: Gurchetan Singh
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8
> drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++
> 3 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 72c1d9b59dfe..0596d9618554 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -209,6 +209,8 @@ struct virtio_gpu_device {
>
> struct virtio_gpu_fpriv {
> uint32_t ctx_id;
> + bool context_initiated;
ctx_id and context_initialized are named hw_res_handle and created
respectively in virtio_gpu_object. I think we should use "hw",
"id"/"handle", "initialized"/"created" more consistently.
This is just a nitpick, and does not need to be a part of this series.
> + struct mutex context_lock;
> };
>
> /* virtio_ioctl.c */
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index de04f80f737d..c1a6cb4ec375 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -44,10 +44,18 @@ void virtio_gpu_create_context(struct drm_device *dev,
> if (!vgdev->has_virgl_3d)
> return;
>
> + mutex_lock(>context_lock);
> + if (vfpriv->context_initiated)
> + goto out_unlock;
> +
> get_task_comm(dbgname, current);
> virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
> strlen(dbgname), dbgname);
> virtio_gpu_notify(vgdev);
> + vfpriv->context_initiated = true;
> +
> +out_unlock:
> + mutex_unlock(>context_lock);
> }
>
> static int virtio_gpu_map_ioctl(struct drm_device *dev, void *data,
> diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
> b/drivers/gpu/drm/virtio/virtgpu_kms.c
> index f7e3712502ca..424729cb81d1 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> @@ -258,6 +258,8 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
> drm_file *file)
> if (!vfpriv)
> return -ENOMEM;
>
> + mutex_init(>context_lock);
> +
> handle = ida_alloc(>ctx_id_ida, GFP_KERNEL);
> if (handle < 0) {
> kfree(vfpriv);
> @@ -281,6 +283,7 @@ void virtio_gpu_driver_postclose(struct drm_device *dev,
> struct drm_file *file)
> vfpriv = file->driver_priv;
>
> virtio_gpu_context_destroy(vgdev, vfpriv->ctx_id);
> + mutex_destroy(>context_lock);
> kfree(vfpriv);
> file->driver_priv = NULL;
> }
> --
> 2.25.0.265.gbab2e86ba0-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5 v5] drm/virtio: add virtio_gpu_context_type
On Wed, 19 Feb 2020 at 17:57, Gurchetan Singh wrote: > > We'll have to do something like this eventually, and this > conveys we want a Virgl context by default. > > Signed-off-by: Gurchetan Singh Reviewed-by: Emil Velikov HTH Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5 v5] drm/virtio: enqueue virtio_gpu_create_context after the first 3D ioctl
On Wed, 19 Feb 2020 at 17:57, Gurchetan Singh
wrote:
>
> For old userspace, initialization will still be implicit.
>
> For backwards compatibility, enqueue virtio_gpu_cmd_context_create after
> the first 3D ioctl.
>
> v3: staticify virtio_gpu_create_context
> remove notify to batch vm-exit
>
Similar to 2/5 I suspect we have nested has_virgl_3d checking.
> Signed-off-by: Gurchetan Singh
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 2 --
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 10 +++---
> drivers/gpu/drm/virtio/virtgpu_kms.c | 1 -
> 3 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 0596d9618554..9fdc3b4cef48 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -216,8 +216,6 @@ struct virtio_gpu_fpriv {
> /* virtio_ioctl.c */
> #define DRM_VIRTIO_NUM_IOCTLS 10
> extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
> -void virtio_gpu_create_context(struct drm_device *dev,
> - struct drm_file *file);
>
> /* virtio_kms.c */
> int virtio_gpu_init(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index c1a6cb4ec375..2c182922ec78 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -33,8 +33,8 @@
>
> #include "virtgpu_drv.h"
>
> -void virtio_gpu_create_context(struct drm_device *dev,
> - struct drm_file *file)
> +static void virtio_gpu_create_context(struct drm_device *dev,
> + struct drm_file *file)
> {
In this function...
> struct virtio_gpu_device *vgdev = dev->dev_private;
> struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
> @@ -51,7 +51,6 @@ void virtio_gpu_create_context(struct drm_device *dev,
> get_task_comm(dbgname, current);
> virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
> strlen(dbgname), dbgname);
> - virtio_gpu_notify(vgdev);
> vfpriv->context_initiated = true;
>
> out_unlock:
> @@ -99,6 +98,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
> *dev, void *data,
>
... and this caller, just a couple of lines above.
> exbuf->fence_fd = -1;
>
> + virtio_gpu_create_context(dev, file);
> if (exbuf->flags & VIRTGPU_EXECBUF_FENCE_FD_IN) {
> struct dma_fence *in_fence;
>
> @@ -250,6 +250,7 @@ static int virtio_gpu_resource_create_ioctl(struct
> drm_device *dev, void *data,
> return -EINVAL;
> }
>
Unrelated: might be a good idea to sort the has_virgl_3d == false
EINVAL handling like the has_virgl_3d == true hunk just below. Bonus
points for a comment explaining we don't check for the bind and flags
arguments.
> + virtio_gpu_create_context(dev, file);
> params.format = rc->format;
> params.width = rc->width;
> params.height = rc->height;
> @@ -323,6 +324,7 @@ static int virtio_gpu_transfer_from_host_ioctl(struct
> drm_device *dev,
> if (vgdev->has_virgl_3d == false)
> return -ENOSYS;
>
... and this caller.
> + virtio_gpu_create_context(dev, file);
> objs = virtio_gpu_array_from_handles(file, >bo_handle, 1);
> if (objs == NULL)
> return -ENOENT;
> @@ -371,6 +373,7 @@ static int virtio_gpu_transfer_to_host_ioctl(struct
> drm_device *dev, void *data,
> args->box.w, args->box.h, args->box.x, args->box.y,
> objs, NULL);
> } else {
... and this caller, just a couple of lines above.
With the trivial comments addressed:
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote: > Hi Greg, > > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote: > > On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > > > quality. The biggest wrong pattern is that developers use devm_, > > > > > > which > > > > > > ties the release action to the underlying struct device, whereas > > > > > > all the userspace visible stuff attached to a drm_device can long > > > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > > > files and mmap'ed buffers). Give people what they want, but with > > > > > > more > > > > > > correctness. > > > > > > > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device > > > > > > and > > > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > > > actions (but kfree exists, we'll need that soon). Plus all specific > > > > > > to > > > > > > drm_device ofc, including the logging. Which I didn't bother to make > > > > > > compile-time optional, since none of the other drm logging is > > > > > > compile > > > > > > time optional either. > > > > > > > > > > > > One tricky bit here is the chicken between allocating your > > > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > > > allocation registered before drm_dev_init registers any of its own > > > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > > > drm_device is emebedded into the overall structure, and by the time > > > > > > it > > > > > > returns it'll all be too late. And forcing drivers to be able clean > > > > > > up > > > > > > everything except the one kzalloc is silly. > > > > > > > > > > > > Work around this by having a very special final_kfree pointer. This > > > > > > also avoids troubles with the list head possibly disappearing from > > > > > > underneath us when we release all resources attached to the > > > > > > drm_device. > > > > > > > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > > > > using devm_k*alloc to allocate data accessible by userspace. Since the > > > > > introduction of devm_*, we've likely reduced the number of memory > > > > > leaks, > > > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > > > some drivers that used .release() callbacks correctly being naively > > > > > converted to incorrect devm_* usage :-( > > > > > > > > > > This leads me to a question: if other subsystems have the same > > > > > problem, > > > > > could we turn this implementation into something more generic ? It > > > > > doesn't have to be done right away and shouldn't block merging this > > > > > series, but I think it would be very useful. > > > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > > (driver_memory?) > > > > > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > > > this being needed here. > > > > > > There's two reasons I went with copypasta instead of trying to share code: > > > - Type checking, I definitely don't want people to mix up devm_ with > > > drmm_. But even if we do a drv_m that subsystems could embed we do > > > have quite a few different types of component drivers (and with > > > drm_panel and drm_bridge even standardized), and I don't want people > > > to be able to pass the wrong kind of struct to e.g. a managed > > > drmm_connector_init - it really needs to be the drm_device, not a > > > panel or bridge or something else. > > > > Fair enough, that makes sense. > > > > > - We could still share the code as a kind of implementation/backend > > > library. But it's not much, and with embedding I could use the drm > > > device logging stuff which is kinda nice. But if there's more demand > > > for this I can definitely see the point in sharing this, as Laurent > > > pointed out with the tiny optimization with not allocating a NULL void > > > * that I've done (and screwed up) it's not entirely trivial code. > > > > I think moving over time to having this be a backend library is good. > > But no rush/issues here with this going in now, it solves a real need > > and we can refactor it later on to try to make it more "bus/class" > > generic as needed. > > >From a type checking point of view, it would then be nice to have a > structure that models a device node, other than just struct device that > is
Re: [PATCH 3/5 v5] drm/virtio: track whether or not a context has been initiated
On Wed, 19 Feb 2020 at 17:56, Gurchetan Singh wrote: > > Use an atomic variable to track whether a context has been > initiated. > > v5: Fix possible race and sleep via mutex (@olv) > > Signed-off-by: Gurchetan Singh Reviewed-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_
On Wed, Feb 19, 2020 at 6:30 PM Noralf Trønnes wrote:
>
>
>
> Den 19.02.2020 17.23, skrev Daniel Vetter:
> > On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart
> > wrote:
> >>
> >> Hi Daniel,
> >>
> >> On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
> >>> On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote:
> On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote:
> > drm_mode_config_cleanup is idempotent, so no harm in calling this
> > twice. This allows us to gradually switch drivers over by removing
> > explicit drm_mode_config_cleanup calls.
> >
> > With this step it's not also possible that (at least for simple
> > drivers) automatic resource cleanup can be done correctly without a
> > drm_driver->release hook. Therefore allow this now in
> > devm_drm_dev_init().
> >
> > Also with drmm_ explicit drm_driver->release hooks are kinda not the
> > best option, so deprecate that hook to discourage future users.
> >
> > v2: Fixup the example in the kerneldoc too.
> >
> > Cc: "Noralf Trønnes"
> > Cc: Sam Ravnborg
> > Cc: Thomas Zimmermann
> > Signed-off-by: Daniel Vetter
> > ---
>
>
>
> > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > b/drivers/gpu/drm/drm_mode_config.c
> > index 08e6eff6a179..957db1edba0c 100644
> > --- a/drivers/gpu/drm/drm_mode_config.c
> > +++ b/drivers/gpu/drm/drm_mode_config.c
> > @@ -25,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -373,6 +374,11 @@ static int
> > drm_mode_create_standard_properties(struct drm_device *dev)
> > return 0;
> > }
> >
> > +static void drm_mode_config_init_release(struct drm_device *dev, void
> > *ptr)
> > +{
> > + drm_mode_config_cleanup(dev);
> > +}
> > +
> > /**
> > * drm_mode_config_init - initialize DRM mode_configuration structure
> > * @dev: DRM device
> > @@ -384,8 +390,10 @@ static int
> > drm_mode_create_standard_properties(struct drm_device *dev)
> > * problem, since this should happen single threaded at init time. It
> > is the
> > * driver's problem to ensure this guarantee.
> > *
> > + * Cleanup is automatically handled through registering
> > drm_mode_config_cleanup
> > + * with drmm_add_action().
> > */
> > -void drm_mode_config_init(struct drm_device *dev)
> > +int drm_mode_config_init(struct drm_device *dev)
> > {
> > mutex_init(>mode_config.mutex);
> > drm_modeset_lock_init(>mode_config.connection_mutex);
> > @@ -443,6 +451,8 @@ void drm_mode_config_init(struct drm_device *dev)
> > drm_modeset_acquire_fini(_ctx);
> > dma_resv_fini();
> > }
> > +
> > + return drmm_add_action(dev, drm_mode_config_init_release, NULL);
>
> If this fails, shouldn't drm_mode_config_cleanup() be called here ?
> >>>
> >>> Maybe for ocd reasons, but not for actually cleaning up anything. It's
> >>> just a bunch of empty lists that drm_mode_config_cleanup will walk and
> >>> do nothing about. Not sure I should add that ...
> >>
> >> How about the ida init, and the mutex_init() that isn't a no-op when
> >> lock debugging is enabled ?
> >
> > Hm right, I'll fix this.
> >
>
> You could make a drmm_ version of devm_add_action_or_reset() for this.
...
How did I not see that in devres.c. In my defense, I've never written
a driver using devm because of all the lifetime bugs that would cause
in drm, but yes this is exactly what we want here.
Thanks a lot for the pointer, I'll go do some typing!
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5 v5] drm/virtio: factor out context create hyercall
Hi Gurchetan,
s/hyercall/hypercall/ in the commit message
On Wed, 19 Feb 2020 at 17:56, Gurchetan Singh
wrote:
> +void virtio_gpu_create_context(struct drm_device *dev,
> + struct drm_file *file)
> +{
> + struct virtio_gpu_device *vgdev = dev->dev_private;
> + struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
> + char dbgname[TASK_COMM_LEN];
> +
> + /* can't create contexts without 3d renderer */
> + if (!vgdev->has_virgl_3d)
> + return;
> +
This cannot trigger, since we have similar check in the caller
virtio_gpu_driver_open().
> @@ -260,8 +247,7 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
> drm_file *file)
> {
> struct virtio_gpu_device *vgdev = dev->dev_private;
> struct virtio_gpu_fpriv *vfpriv;
> - int id;
> - char dbgname[TASK_COMM_LEN];
> + int handle;
>
> /* can't create contexts without 3d renderer */
> if (!vgdev->has_virgl_3d)
... namely this here.
With either of the two dropped:
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5 v5] drm/virtio: use consistent names for drm_files
On Wed, 19 Feb 2020 at 17:56, Gurchetan Singh wrote: > > Minor cleanup, change: > > - file_priv--> file, > - drm_file --> file. > > Signed-off-by: Gurchetan Singh Reviewed-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5 v5] drm/virtio: add virtio_gpu_context_type
We'll have to do something like this eventually, and this
conveys we want a Virgl context by default.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 2c182922ec78..c3358eedd3ab 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -33,8 +33,14 @@
#include "virtgpu_drv.h"
+/* TODO: add more context types */
+enum virtio_gpu_context_type {
+ virtio_gpu_virgl_context,
+};
+
static void virtio_gpu_create_context(struct drm_device *dev,
- struct drm_file *file)
+ struct drm_file *file,
+ enum virtio_gpu_context_type type)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
@@ -44,6 +50,11 @@ static void virtio_gpu_create_context(struct drm_device *dev,
if (!vgdev->has_virgl_3d)
return;
+ if (type != virtio_gpu_virgl_context) {
+ DRM_ERROR("Unsupported context type: %u\n", type);
+ return;
+ }
+
mutex_lock(>context_lock);
if (vfpriv->context_initiated)
goto out_unlock;
@@ -98,7 +109,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
exbuf->fence_fd = -1;
- virtio_gpu_create_context(dev, file);
+ virtio_gpu_create_context(dev, file, virtio_gpu_virgl_context);
if (exbuf->flags & VIRTGPU_EXECBUF_FENCE_FD_IN) {
struct dma_fence *in_fence;
@@ -250,7 +261,7 @@ static int virtio_gpu_resource_create_ioctl(struct
drm_device *dev, void *data,
return -EINVAL;
}
- virtio_gpu_create_context(dev, file);
+ virtio_gpu_create_context(dev, file, virtio_gpu_virgl_context);
params.format = rc->format;
params.width = rc->width;
params.height = rc->height;
@@ -324,7 +335,7 @@ static int virtio_gpu_transfer_from_host_ioctl(struct
drm_device *dev,
if (vgdev->has_virgl_3d == false)
return -ENOSYS;
- virtio_gpu_create_context(dev, file);
+ virtio_gpu_create_context(dev, file, virtio_gpu_virgl_context);
objs = virtio_gpu_array_from_handles(file, >bo_handle, 1);
if (objs == NULL)
return -ENOENT;
@@ -373,7 +384,7 @@ static int virtio_gpu_transfer_to_host_ioctl(struct
drm_device *dev, void *data,
args->box.w, args->box.h, args->box.x, args->box.y,
objs, NULL);
} else {
- virtio_gpu_create_context(dev, file);
+ virtio_gpu_create_context(dev, file, virtio_gpu_virgl_context);
ret = virtio_gpu_array_lock_resv(objs);
if (ret != 0)
goto err_put_free;
@@ -474,7 +485,7 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
spin_unlock(>display_info_lock);
/* not in cache - need to talk to hw */
- virtio_gpu_create_context(dev, file);
+ virtio_gpu_create_context(dev, file, virtio_gpu_virgl_context);
virtio_gpu_cmd_get_capset(vgdev, found_valid, args->cap_set_ver,
_ent);
virtio_gpu_notify(vgdev);
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5 v5] drm/virtio: factor out context create hyercall
We currently create an OpenGL context when opening the DRM fd
if 3D is available.
We may need other context types (VK,..) in the future, and the plan
is to have explicit initialization for that.
For explicit initialization to work, we need to factor out
virtio_gpu_create_context from driver initialization.
v2: Move context handle initialization too (@olv)
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 17 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 26 ++
3 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 2f6c4ccbfd14..72c1d9b59dfe 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -214,6 +214,8 @@ struct virtio_gpu_fpriv {
/* virtio_ioctl.c */
#define DRM_VIRTIO_NUM_IOCTLS 10
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
+void virtio_gpu_create_context(struct drm_device *dev,
+ struct drm_file *file);
/* virtio_kms.c */
int virtio_gpu_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index baad7e1c9505..de04f80f737d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -33,6 +33,23 @@
#include "virtgpu_drv.h"
+void virtio_gpu_create_context(struct drm_device *dev,
+ struct drm_file *file)
+{
+ struct virtio_gpu_device *vgdev = dev->dev_private;
+ struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
+ char dbgname[TASK_COMM_LEN];
+
+ /* can't create contexts without 3d renderer */
+ if (!vgdev->has_virgl_3d)
+ return;
+
+ get_task_comm(dbgname, current);
+ virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
+ strlen(dbgname), dbgname);
+ virtio_gpu_notify(vgdev);
+}
+
static int virtio_gpu_map_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index ad3b673f5796..f7e3712502ca 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -52,19 +52,6 @@ static void virtio_gpu_config_changed_work_func(struct
work_struct *work)
events_clear, _clear);
}
-static int virtio_gpu_context_create(struct virtio_gpu_device *vgdev,
- uint32_t nlen, const char *name)
-{
- int handle = ida_alloc(>ctx_id_ida, GFP_KERNEL);
-
- if (handle < 0)
- return handle;
- handle += 1;
- virtio_gpu_cmd_context_create(vgdev, handle, nlen, name);
- virtio_gpu_notify(vgdev);
- return handle;
-}
-
static void virtio_gpu_context_destroy(struct virtio_gpu_device *vgdev,
uint32_t ctx_id)
{
@@ -260,8 +247,7 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv;
- int id;
- char dbgname[TASK_COMM_LEN];
+ int handle;
/* can't create contexts without 3d renderer */
if (!vgdev->has_virgl_3d)
@@ -272,15 +258,15 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
drm_file *file)
if (!vfpriv)
return -ENOMEM;
- get_task_comm(dbgname, current);
- id = virtio_gpu_context_create(vgdev, strlen(dbgname), dbgname);
- if (id < 0) {
+ handle = ida_alloc(>ctx_id_ida, GFP_KERNEL);
+ if (handle < 0) {
kfree(vfpriv);
- return id;
+ return handle;
}
- vfpriv->ctx_id = id;
+ vfpriv->ctx_id = handle + 1;
file->driver_priv = vfpriv;
+ virtio_gpu_create_context(dev, file);
return 0;
}
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5 v5] drm/virtio: use consistent names for drm_files
Minor cleanup, change:
- file_priv--> file,
- drm_file --> file.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index bbc31aef51f1..baad7e1c9505 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -34,12 +34,12 @@
#include "virtgpu_drv.h"
static int virtio_gpu_map_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+ struct drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct drm_virtgpu_map *virtio_gpu_map = data;
- return virtio_gpu_mode_dumb_mmap(file_priv, vgdev->ddev,
+ return virtio_gpu_mode_dumb_mmap(file, vgdev->ddev,
virtio_gpu_map->handle,
_gpu_map->offset);
}
@@ -51,11 +51,11 @@ static int virtio_gpu_map_ioctl(struct drm_device *dev,
void *data,
* VIRTIO_GPUReleaseInfo struct (first XXX bytes)
*/
static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
-struct drm_file *drm_file)
+struct drm_file *file)
{
struct drm_virtgpu_execbuffer *exbuf = data;
struct virtio_gpu_device *vgdev = dev->dev_private;
- struct virtio_gpu_fpriv *vfpriv = drm_file->driver_priv;
+ struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
struct virtio_gpu_fence *out_fence;
int ret;
uint32_t *bo_handles = NULL;
@@ -116,7 +116,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
goto out_unused_fd;
}
- buflist = virtio_gpu_array_from_handles(drm_file, bo_handles,
+ buflist = virtio_gpu_array_from_handles(file, bo_handles,
exbuf->num_bo_handles);
if (!buflist) {
ret = -ENOENT;
@@ -178,7 +178,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
}
static int virtio_gpu_getparam_ioctl(struct drm_device *dev, void *data,
-struct drm_file *file_priv)
+struct drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct drm_virtgpu_getparam *param = data;
@@ -201,7 +201,7 @@ static int virtio_gpu_getparam_ioctl(struct drm_device
*dev, void *data,
}
static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+ struct drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct drm_virtgpu_resource_create *rc = data;
@@ -252,7 +252,7 @@ static int virtio_gpu_resource_create_ioctl(struct
drm_device *dev, void *data,
return ret;
obj = >base.base;
- ret = drm_gem_handle_create(file_priv, obj, );
+ ret = drm_gem_handle_create(file, obj, );
if (ret) {
drm_gem_object_release(obj);
return ret;
@@ -265,13 +265,13 @@ static int virtio_gpu_resource_create_ioctl(struct
drm_device *dev, void *data,
}
static int virtio_gpu_resource_info_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+ struct drm_file *file)
{
struct drm_virtgpu_resource_info *ri = data;
struct drm_gem_object *gobj = NULL;
struct virtio_gpu_object *qobj = NULL;
- gobj = drm_gem_object_lookup(file_priv, ri->bo_handle);
+ gobj = drm_gem_object_lookup(file, ri->bo_handle);
if (gobj == NULL)
return -ENOENT;
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5 v5] drm/virtio: track whether or not a context has been initiated
Use an atomic variable to track whether a context has been
initiated.
v5: Fix possible race and sleep via mutex (@olv)
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8
drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 72c1d9b59dfe..0596d9618554 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -209,6 +209,8 @@ struct virtio_gpu_device {
struct virtio_gpu_fpriv {
uint32_t ctx_id;
+ bool context_initiated;
+ struct mutex context_lock;
};
/* virtio_ioctl.c */
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index de04f80f737d..c1a6cb4ec375 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -44,10 +44,18 @@ void virtio_gpu_create_context(struct drm_device *dev,
if (!vgdev->has_virgl_3d)
return;
+ mutex_lock(>context_lock);
+ if (vfpriv->context_initiated)
+ goto out_unlock;
+
get_task_comm(dbgname, current);
virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
strlen(dbgname), dbgname);
virtio_gpu_notify(vgdev);
+ vfpriv->context_initiated = true;
+
+out_unlock:
+ mutex_unlock(>context_lock);
}
static int virtio_gpu_map_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index f7e3712502ca..424729cb81d1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -258,6 +258,8 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
drm_file *file)
if (!vfpriv)
return -ENOMEM;
+ mutex_init(>context_lock);
+
handle = ida_alloc(>ctx_id_ida, GFP_KERNEL);
if (handle < 0) {
kfree(vfpriv);
@@ -281,6 +283,7 @@ void virtio_gpu_driver_postclose(struct drm_device *dev,
struct drm_file *file)
vfpriv = file->driver_priv;
virtio_gpu_context_destroy(vgdev, vfpriv->ctx_id);
+ mutex_destroy(>context_lock);
kfree(vfpriv);
file->driver_priv = NULL;
}
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5 v5] drm/virtio: enqueue virtio_gpu_create_context after the first 3D ioctl
For old userspace, initialization will still be implicit.
For backwards compatibility, enqueue virtio_gpu_cmd_context_create after
the first 3D ioctl.
v3: staticify virtio_gpu_create_context
remove notify to batch vm-exit
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 --
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 10 +++---
drivers/gpu/drm/virtio/virtgpu_kms.c | 1 -
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 0596d9618554..9fdc3b4cef48 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -216,8 +216,6 @@ struct virtio_gpu_fpriv {
/* virtio_ioctl.c */
#define DRM_VIRTIO_NUM_IOCTLS 10
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
-void virtio_gpu_create_context(struct drm_device *dev,
- struct drm_file *file);
/* virtio_kms.c */
int virtio_gpu_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index c1a6cb4ec375..2c182922ec78 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -33,8 +33,8 @@
#include "virtgpu_drv.h"
-void virtio_gpu_create_context(struct drm_device *dev,
- struct drm_file *file)
+static void virtio_gpu_create_context(struct drm_device *dev,
+ struct drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
@@ -51,7 +51,6 @@ void virtio_gpu_create_context(struct drm_device *dev,
get_task_comm(dbgname, current);
virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
strlen(dbgname), dbgname);
- virtio_gpu_notify(vgdev);
vfpriv->context_initiated = true;
out_unlock:
@@ -99,6 +98,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
exbuf->fence_fd = -1;
+ virtio_gpu_create_context(dev, file);
if (exbuf->flags & VIRTGPU_EXECBUF_FENCE_FD_IN) {
struct dma_fence *in_fence;
@@ -250,6 +250,7 @@ static int virtio_gpu_resource_create_ioctl(struct
drm_device *dev, void *data,
return -EINVAL;
}
+ virtio_gpu_create_context(dev, file);
params.format = rc->format;
params.width = rc->width;
params.height = rc->height;
@@ -323,6 +324,7 @@ static int virtio_gpu_transfer_from_host_ioctl(struct
drm_device *dev,
if (vgdev->has_virgl_3d == false)
return -ENOSYS;
+ virtio_gpu_create_context(dev, file);
objs = virtio_gpu_array_from_handles(file, >bo_handle, 1);
if (objs == NULL)
return -ENOENT;
@@ -371,6 +373,7 @@ static int virtio_gpu_transfer_to_host_ioctl(struct
drm_device *dev, void *data,
args->box.w, args->box.h, args->box.x, args->box.y,
objs, NULL);
} else {
+ virtio_gpu_create_context(dev, file);
ret = virtio_gpu_array_lock_resv(objs);
if (ret != 0)
goto err_put_free;
@@ -471,6 +474,7 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
spin_unlock(>display_info_lock);
/* not in cache - need to talk to hw */
+ virtio_gpu_create_context(dev, file);
virtio_gpu_cmd_get_capset(vgdev, found_valid, args->cap_set_ver,
_ent);
virtio_gpu_notify(vgdev);
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 424729cb81d1..023a030ca7b9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -268,7 +268,6 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct
drm_file *file)
vfpriv->ctx_id = handle + 1;
file->driver_priv = vfpriv;
- virtio_gpu_create_context(dev, file);
return 0;
}
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 8/9] media: fsl-viu: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski --- drivers/media/platform/fsl-viu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c index 81a8faedbba6..991d9dc82749 100644 --- a/drivers/media/platform/fsl-viu.c +++ b/drivers/media/platform/fsl-viu.c @@ -34,7 +34,7 @@ /* Allow building this driver with COMPILE_TEST */ #if !defined(CONFIG_PPC) && !defined(CONFIG_MICROBLAZE) #define out_be32(v, a) iowrite32be(a, (void __iomem *)v) -#define in_be32(a) ioread32be((void __iomem *)a) +#define in_be32(a) ioread32be((const void __iomem *)a) #endif #define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */ -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Acked-by: Kalle Valo
---
drivers/net/wireless/ath/ath5k/ahb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
b/drivers/net/wireless/ath/ath5k/ahb.c
index 2c9cec8b53d9..8bd01df369fb 100644
--- a/drivers/net/wireless/ath/ath5k/ahb.c
+++ b/drivers/net/wireless/ath/ath5k/ahb.c
@@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device *pdev)
if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
/* Enable WMAC AHB arbitration */
- reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
+ reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
reg |= AR5K_AR2315_AHB_ARB_CTL_WLAN;
iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
/* Enable global WMAC swapping */
- reg = ioread32((void __iomem *) AR5K_AR2315_BYTESWAP);
+ reg = ioread32((const void __iomem *) AR5K_AR2315_BYTESWAP);
reg |= AR5K_AR2315_BYTESWAP_WMAC;
iowrite32(reg, (void __iomem *) AR5K_AR2315_BYTESWAP);
} else {
/* Enable WMAC DMA access (assuming 5312 or 231x*/
/* TODO: check other platforms */
- reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
+ reg = ioread32((const void __iomem *) AR5K_AR5312_ENABLE);
if (to_platform_device(ah->dev)->id == 0)
reg |= AR5K_AR5312_ENABLE_WLAN0;
else
@@ -202,12 +202,12 @@ static int ath_ahb_remove(struct platform_device *pdev)
if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
/* Disable WMAC AHB arbitration */
- reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
+ reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
reg &= ~AR5K_AR2315_AHB_ARB_CTL_WLAN;
iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
} else {
/*Stop DMA access */
- reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
+ reg = ioread32((const void __iomem *) AR5K_AR5312_ENABLE);
if (to_platform_device(ah->dev)->id == 0)
reg &= ~AR5K_AR5312_ENABLE_WLAN0;
else
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 6/9] drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Thomas Zimmermann --- Changes since v1: 1. Add Thomas' review. --- drivers/gpu/drm/mgag200/mgag200_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h index aa32aad222c2..6512b3af4fb7 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.h +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h @@ -34,9 +34,9 @@ #define MGAG200FB_CONN_LIMIT 1 -#define RREG8(reg) ioread8(((void __iomem *)mdev->rmmio) + (reg)) +#define RREG8(reg) ioread8(((const void __iomem *)mdev->rmmio) + (reg)) #define WREG8(reg, v) iowrite8(v, ((void __iomem *)mdev->rmmio) + (reg)) -#define RREG32(reg) ioread32(((void __iomem *)mdev->rmmio) + (reg)) +#define RREG32(reg) ioread32(((const void __iomem *)mdev->rmmio) + (reg)) #define WREG32(reg, v) iowrite32(v, ((void __iomem *)mdev->rmmio) + (reg)) #define ATTR_INDEX 0x1fc0 -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 2/9] rtl818x: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
Acked-by: Kalle Valo
---
Changes since v1:
1. Add Geert's review.
2. Add Kalle's ack. Fix subject prefix.
---
drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
index 7948a2da195a..2ff00800d45b 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
@@ -150,17 +150,17 @@ void rtl8180_write_phy(struct ieee80211_hw *dev, u8 addr,
u32 data);
void rtl8180_set_anaparam(struct rtl8180_priv *priv, u32 anaparam);
void rtl8180_set_anaparam2(struct rtl8180_priv *priv, u32 anaparam2);
-static inline u8 rtl818x_ioread8(struct rtl8180_priv *priv, u8 __iomem *addr)
+static inline u8 rtl818x_ioread8(struct rtl8180_priv *priv, const u8 __iomem
*addr)
{
return ioread8(addr);
}
-static inline u16 rtl818x_ioread16(struct rtl8180_priv *priv, __le16 __iomem
*addr)
+static inline u16 rtl818x_ioread16(struct rtl8180_priv *priv, const __le16
__iomem *addr)
{
return ioread16(addr);
}
-static inline u32 rtl818x_ioread32(struct rtl8180_priv *priv, __le32 __iomem
*addr)
+static inline u32 rtl818x_ioread32(struct rtl8180_priv *priv, const __le32
__iomem *addr)
{
return ioread32(addr);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 7/9] drm/nouveau: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 1b62ccc57aef..d95bdd65dbca 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -613,7 +613,7 @@ nouveau_bo_rd32(struct nouveau_bo *nvbo, unsigned index) mem += index; if (is_iomem) - return ioread32_native((void __force __iomem *)mem); + return ioread32_native((const void __force __iomem *)mem); else return *mem; } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 3/9] ntb: intel: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
Acked-by: Dave Jiang
---
Changes since v1:
1. Add Geert's review.
2. Add Dave's ack.
---
drivers/ntb/hw/intel/ntb_hw_gen1.c | 2 +-
drivers/ntb/hw/intel/ntb_hw_gen3.h | 2 +-
drivers/ntb/hw/intel/ntb_hw_intel.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen1.c
b/drivers/ntb/hw/intel/ntb_hw_gen1.c
index bb57ec239029..9202502a9787 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen1.c
+++ b/drivers/ntb/hw/intel/ntb_hw_gen1.c
@@ -1202,7 +1202,7 @@ int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int
pidx, int sidx,
ndev->peer_reg->spad);
}
-static u64 xeon_db_ioread(void __iomem *mmio)
+static u64 xeon_db_ioread(const void __iomem *mmio)
{
return (u64)ioread16(mmio);
}
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen3.h
b/drivers/ntb/hw/intel/ntb_hw_gen3.h
index 75fb86ca27bb..d1455f24ec99 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen3.h
+++ b/drivers/ntb/hw/intel/ntb_hw_gen3.h
@@ -91,7 +91,7 @@
#define GEN3_DB_TOTAL_SHIFT33
#define GEN3_SPAD_COUNT16
-static inline u64 gen3_db_ioread(void __iomem *mmio)
+static inline u64 gen3_db_ioread(const void __iomem *mmio)
{
return ioread64(mmio);
}
diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.h
b/drivers/ntb/hw/intel/ntb_hw_intel.h
index e071e28bca3f..3c0a5a2da241 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.h
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.h
@@ -102,7 +102,7 @@ struct intel_ntb_dev;
struct intel_ntb_reg {
int (*poll_link)(struct intel_ntb_dev *ndev);
int (*link_is_up)(struct intel_ntb_dev *ndev);
- u64 (*db_ioread)(void __iomem *mmio);
+ u64 (*db_ioread)(const void __iomem *mmio);
void (*db_iowrite)(u64 db_bits, void __iomem *mmio);
unsigned long ntb_ctl;
resource_size_t db_size;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 4/9] virtio: pci: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
1. Add Geert's review.
---
drivers/virtio/virtio_pci_modern.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_pci_modern.c
b/drivers/virtio/virtio_pci_modern.c
index 7abcc50838b8..fc58db4ab6c3 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -26,16 +26,16 @@
* method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses
* for 16-bit fields and 8-bit accesses for 8-bit fields.
*/
-static inline u8 vp_ioread8(u8 __iomem *addr)
+static inline u8 vp_ioread8(const u8 __iomem *addr)
{
return ioread8(addr);
}
-static inline u16 vp_ioread16 (__le16 __iomem *addr)
+static inline u16 vp_ioread16 (const __le16 __iomem *addr)
{
return ioread16(addr);
}
-static inline u32 vp_ioread32(__le32 __iomem *addr)
+static inline u32 vp_ioread32(const __le32 __iomem *addr)
{
return ioread32(addr);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 5/9] arc: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the
address so they can be converted to a "const" version for const-safety
and consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Acked-by: Alexey Brodkin
---
Changes since v1:
1. Add Alexey's ack.
---
arch/arc/plat-axs10x/axs10x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c
index 63ea5a606ecd..180c260a8221 100644
--- a/arch/arc/plat-axs10x/axs10x.c
+++ b/arch/arc/plat-axs10x/axs10x.c
@@ -84,7 +84,7 @@ static void __init axs10x_print_board_ver(unsigned int creg,
const char *str)
unsigned int val;
} board;
- board.val = ioread32((void __iomem *)creg);
+ board.val = ioread32((const void __iomem *)creg);
pr_info("AXS: %s FPGA Date: %u-%u-%u\n", str, board.d, board.m,
board.y);
}
@@ -95,7 +95,7 @@ static void __init axs10x_early_init(void)
char mb[32];
/* Determine motherboard version */
- if (ioread32((void __iomem *) CREG_MB_CONFIG) & (1 << 28))
+ if (ioread32((const void __iomem *) CREG_MB_CONFIG) & (1 << 28))
mb_rev = 3; /* HT-3 (rev3.0) */
else
mb_rev = 2; /* HT-2 (rev2.0) */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 1/9] iomap: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
some architectures void *__iomem address argument is a pointer to const,
on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Suggested-by: Geert Uytterhoeven
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Arnd Bergmann
---
Changes since v1:
1. Constify also ioreadX_rep() and mmio_insX(),
2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability,
3. Add Geert's review.
4. Add Arnd's review.
---
arch/alpha/include/asm/core_apecs.h | 6 +--
arch/alpha/include/asm/core_cia.h | 6 +--
arch/alpha/include/asm/core_lca.h | 6 +--
arch/alpha/include/asm/core_marvel.h | 4 +-
arch/alpha/include/asm/core_mcpcia.h | 6 +--
arch/alpha/include/asm/core_t2.h | 2 +-
arch/alpha/include/asm/io.h | 12 ++---
arch/alpha/include/asm/io_trivial.h | 16 +++---
arch/alpha/include/asm/jensen.h | 2 +-
arch/alpha/include/asm/machvec.h | 6 +--
arch/alpha/kernel/core_marvel.c | 2 +-
arch/alpha/kernel/io.c| 12 ++---
arch/parisc/include/asm/io.h | 4 +-
arch/parisc/lib/iomap.c | 72 +--
arch/powerpc/kernel/iomap.c | 28 +--
arch/sh/kernel/iomap.c| 22
include/asm-generic/iomap.h | 28 +--
include/linux/io-64-nonatomic-hi-lo.h | 4 +-
include/linux/io-64-nonatomic-lo-hi.h | 4 +-
lib/iomap.c | 30 +--
20 files changed, 136 insertions(+), 136 deletions(-)
diff --git a/arch/alpha/include/asm/core_apecs.h
b/arch/alpha/include/asm/core_apecs.h
index 0a07055bc0fe..2d9726fc02ef 100644
--- a/arch/alpha/include/asm/core_apecs.h
+++ b/arch/alpha/include/asm/core_apecs.h
@@ -384,7 +384,7 @@ struct el_apecs_procdata
} \
} while (0)
-__EXTERN_INLINE unsigned int apecs_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread8(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -420,7 +420,7 @@ __EXTERN_INLINE void apecs_iowrite8(u8 b, void __iomem
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int apecs_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread16(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -456,7 +456,7 @@ __EXTERN_INLINE void apecs_iowrite16(u16 b, void __iomem
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int apecs_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread32(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
if (addr < APECS_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_cia.h
b/arch/alpha/include/asm/core_cia.h
index c706a7f2b061..cb22991f6761 100644
--- a/arch/alpha/include/asm/core_cia.h
+++ b/arch/alpha/include/asm/core_cia.h
@@ -342,7 +342,7 @@ struct el_CIA_sysdata_mcheck {
#define vuip volatile unsigned int __force *
#define vulp volatile unsigned long __force *
-__EXTERN_INLINE unsigned int cia_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread8(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -374,7 +374,7 @@ __EXTERN_INLINE void cia_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int cia_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread16(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -404,7 +404,7 @@ __EXTERN_INLINE void cia_iowrite16(u16 b, void __iomem
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int cia_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread32(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
if (addr < CIA_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_lca.h
b/arch/alpha/include/asm/core_lca.h
index 84d5e5b84f4f..ec86314418cb 100644
--- a/arch/alpha/include/asm/core_lca.h
+++ b/arch/alpha/include/asm/core_lca.h
@@ -230,7 +230,7 @@ union el_lca {
} while (0)
-__EXTERN_INLINE unsigned int lca_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread8(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -266,7 +266,7 @@ __EXTERN_INLINE void lca_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type)
[RESEND PATCH v2 0/9] iomap: Constify ioreadX() iomem argument
Hi, Changes since v1 https://lore.kernel.org/lkml/1578415992-24054-1-git-send-email-k...@kernel.org/ 1. Constify also ioreadX_rep() and mmio_insX(), 2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability, 3. Add acks and reviews, 4. Re-order patches so all optional driver changes are at the end. Description === The ioread8/16/32() and others have inconsistent interface among the architectures: some taking address as const, some not. It seems there is nothing really stopping all of them to take pointer to const. Patchset was only compile tested on affected architectures. No real testing. volatile There is still interface inconsistency between architectures around "volatile" qualifier: - include/asm-generic/io.h:static inline u32 ioread32(const volatile void __iomem *addr) - include/asm-generic/iomap.h:extern unsigned int ioread32(const void __iomem *); This is still discussed and out of scope of this patchset. Merging === Multiple architectures are affected in first patch so acks are welcomed. 1. All patches depend on first patch, 2. Patches 2-4 unify the interface also in few drivers, 3. PAtches 5-9 are optional cleanup, without actual impact. Best regards, Krzysztof Krzysztof Kozlowski (9): iomap: Constify ioreadX() iomem argument (as in generic implementation) rtl818x: Constify ioreadX() iomem argument (as in generic implementation) ntb: intel: Constify ioreadX() iomem argument (as in generic implementation) virtio: pci: Constify ioreadX() iomem argument (as in generic implementation) arc: Constify ioreadX() iomem argument (as in generic implementation) drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation) drm/nouveau: Constify ioreadX() iomem argument (as in generic implementation) media: fsl-viu: Constify ioreadX() iomem argument (as in generic implementation) ath5k: Constify ioreadX() iomem argument (as in generic implementation) arch/alpha/include/asm/core_apecs.h | 6 +- arch/alpha/include/asm/core_cia.h | 6 +- arch/alpha/include/asm/core_lca.h | 6 +- arch/alpha/include/asm/core_marvel.h | 4 +- arch/alpha/include/asm/core_mcpcia.h | 6 +- arch/alpha/include/asm/core_t2.h | 2 +- arch/alpha/include/asm/io.h | 12 ++-- arch/alpha/include/asm/io_trivial.h | 16 ++--- arch/alpha/include/asm/jensen.h | 2 +- arch/alpha/include/asm/machvec.h | 6 +- arch/alpha/kernel/core_marvel.c | 2 +- arch/alpha/kernel/io.c| 12 ++-- arch/arc/plat-axs10x/axs10x.c | 4 +- arch/parisc/include/asm/io.h | 4 +- arch/parisc/lib/iomap.c | 72 +-- arch/powerpc/kernel/iomap.c | 28 arch/sh/kernel/iomap.c| 22 +++--- drivers/gpu/drm/mgag200/mgag200_drv.h | 4 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- drivers/media/platform/fsl-viu.c | 2 +- drivers/net/wireless/ath/ath5k/ahb.c | 10 +-- .../realtek/rtl818x/rtl8180/rtl8180.h | 6 +- drivers/ntb/hw/intel/ntb_hw_gen1.c| 2 +- drivers/ntb/hw/intel/ntb_hw_gen3.h| 2 +- drivers/ntb/hw/intel/ntb_hw_intel.h | 2 +- drivers/virtio/virtio_pci_modern.c| 6 +- include/asm-generic/iomap.h | 28 include/linux/io-64-nonatomic-hi-lo.h | 4 +- include/linux/io-64-nonatomic-lo-hi.h | 4 +- lib/iomap.c | 30 30 files changed, 156 insertions(+), 156 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/msm/dpu: Refactor rm iterator
Make iterator implementation private, and add function to
query resources assigned to an encoder.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 59 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 10
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 10
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 31 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 47 ++-
5 files changed, 76 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index f8ac3bf60fd60..6cadeff456f09 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -957,11 +957,11 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
struct drm_connector *conn = NULL, *conn_iter;
struct drm_crtc *drm_crtc;
struct dpu_crtc_state *cstate;
- struct dpu_rm_hw_iter hw_iter;
struct msm_display_topology topology;
- struct dpu_hw_ctl *hw_ctl[MAX_CHANNELS_PER_ENC] = { NULL };
- struct dpu_hw_mixer *hw_lm[MAX_CHANNELS_PER_ENC] = { NULL };
- int num_lm = 0, num_ctl = 0;
+ struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
+ struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
+ struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
+ int num_lm, num_ctl, num_pp;
int i, j, ret;
if (!drm_enc) {
@@ -1005,42 +1005,31 @@ static void dpu_encoder_virt_mode_set(struct
drm_encoder *drm_enc,
return;
}
- dpu_rm_init_hw_iter(_iter, drm_enc->base.id, DPU_HW_BLK_PINGPONG);
- for (i = 0; i < MAX_CHANNELS_PER_ENC; i++) {
- dpu_enc->hw_pp[i] = NULL;
- if (!dpu_rm_get_hw(_kms->rm, _iter))
- break;
- dpu_enc->hw_pp[i] = (struct dpu_hw_pingpong *) hw_iter.hw;
- }
-
- dpu_rm_init_hw_iter(_iter, drm_enc->base.id, DPU_HW_BLK_CTL);
- for (i = 0; i < MAX_CHANNELS_PER_ENC; i++) {
- if (!dpu_rm_get_hw(_kms->rm, _iter))
- break;
- hw_ctl[i] = (struct dpu_hw_ctl *)hw_iter.hw;
- num_ctl++;
- }
+ num_pp = dpu_rm_get_assigned_resources(_kms->rm, drm_enc->base.id,
+ DPU_HW_BLK_PINGPONG, hw_pp, ARRAY_SIZE(hw_pp));
+ num_ctl = dpu_rm_get_assigned_resources(_kms->rm, drm_enc->base.id,
+ DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
+ num_lm = dpu_rm_get_assigned_resources(_kms->rm, drm_enc->base.id,
+ DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
- dpu_rm_init_hw_iter(_iter, drm_enc->base.id, DPU_HW_BLK_LM);
- for (i = 0; i < MAX_CHANNELS_PER_ENC; i++) {
- if (!dpu_rm_get_hw(_kms->rm, _iter))
- break;
- hw_lm[i] = (struct dpu_hw_mixer *)hw_iter.hw;
- num_lm++;
- }
+ for (i = 0; i < MAX_CHANNELS_PER_ENC; i++)
+ dpu_enc->hw_pp[i] = i < num_pp ? to_dpu_hw_pingpong(hw_pp[i])
+ : NULL;
cstate = to_dpu_crtc_state(drm_crtc->state);
for (i = 0; i < num_lm; i++) {
int ctl_idx = (i < num_ctl) ? i : (num_ctl-1);
- cstate->mixers[i].hw_lm = hw_lm[i];
- cstate->mixers[i].lm_ctl = hw_ctl[ctl_idx];
+ cstate->mixers[i].hw_lm = to_dpu_hw_mixer(hw_lm[i]);
+ cstate->mixers[i].lm_ctl = to_dpu_hw_ctl(hw_ctl[ctl_idx]);
}
cstate->num_mixers = num_lm;
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
+ int num_blk;
+ struct dpu_hw_blk *hw_blk[MAX_CHANNELS_PER_ENC];
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
if (!dpu_enc->hw_pp[i]) {
@@ -1056,17 +1045,15 @@ static void dpu_encoder_virt_mode_set(struct
drm_encoder *drm_enc,
}
phys->hw_pp = dpu_enc->hw_pp[i];
- phys->hw_ctl = hw_ctl[i];
+ phys->hw_ctl = to_dpu_hw_ctl(hw_ctl[i]);
- dpu_rm_init_hw_iter(_iter, drm_enc->base.id,
- DPU_HW_BLK_INTF);
- for (j = 0; j < MAX_CHANNELS_PER_ENC; j++) {
+ num_blk = dpu_rm_get_assigned_resources(_kms->rm,
+ drm_enc->base.id, DPU_HW_BLK_INTF, hw_blk,
+ ARRAY_SIZE(hw_blk));
+ for (j = 0; j < num_blk; j++) {
struct dpu_hw_intf *hw_intf;
- if (!dpu_rm_get_hw(_kms->rm, _iter))
- break;
-
- hw_intf = (struct dpu_hw_intf *)hw_iter.hw;
+ hw_intf = to_dpu_hw_intf(hw_blk[i]);
if (hw_intf->idx == phys->intf_idx)
phys->hw_intf = hw_intf;
}
diff --git
[PATCH 3/4] drm/msm/dpu: Refactor resource manager
Track hardware resource objects in arrays rather than
a list and remove the resource manager's iterator idiom. Separate
the mapping of hardware resources to an encoder ID into a different
array.
Use an implicit mapping between the hardware blocks' ids, which
are 1-based, and array indices in these arrays to replace iteration
with index lookups in several places.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 553 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 22 +-
2 files changed, 255 insertions(+), 320 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 779df26dc81ae..f1483b00b7423 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -12,8 +12,12 @@
#include "dpu_encoder.h"
#include "dpu_trace.h"
-#define RESERVED_BY_OTHER(h, r) \
- ((h)->enc_id && (h)->enc_id != r)
+
+static inline bool reserved_by_other(uint32_t *res_map, int idx,
+uint32_t enc_id)
+{
+ return res_map[idx] && res_map[idx] != enc_id;
+}
/**
* struct dpu_rm_requirements - Reservation requirements parameter bundle
@@ -25,126 +29,40 @@ struct dpu_rm_requirements {
struct dpu_encoder_hw_resources hw_res;
};
-
-/**
- * struct dpu_rm_hw_blk - hardware block tracking list member
- * @list: List head for list of all hardware blocks tracking items
- * @id:Hardware ID number, within it's own space, ie. LM_X
- * @enc_id:Encoder id to which this blk is binded
- * @hw:Pointer to the hardware register access object for this
block
- */
-struct dpu_rm_hw_blk {
- struct list_head list;
- uint32_t id;
- uint32_t enc_id;
- struct dpu_hw_blk *hw;
-};
-
-/**
- * struct dpu_rm_hw_iter - iterator for use with dpu_rm
- * @hw: dpu_hw object requested, or NULL on failure
- * @blk: dpu_rm internal block representation. Clients ignore. Used as
iterator.
- * @enc_id: DRM ID of Encoder client wishes to search for, or 0 for Any Encoder
- * @type: Hardware Block Type client wishes to search for.
- */
-struct dpu_rm_hw_iter {
- void *hw;
- struct dpu_rm_hw_blk *blk;
- uint32_t enc_id;
- enum dpu_hw_blk_type type;
-};
-
-static void dpu_rm_init_hw_iter(
- struct dpu_rm_hw_iter *iter,
- uint32_t enc_id,
- enum dpu_hw_blk_type type)
-{
- memset(iter, 0, sizeof(*iter));
- iter->enc_id = enc_id;
- iter->type = type;
-}
-
-static bool _dpu_rm_get_hw_locked(struct dpu_rm *rm, struct dpu_rm_hw_iter *i)
+int dpu_rm_destroy(struct dpu_rm *rm)
{
- struct list_head *blk_list;
+ int i;
- if (!rm || !i || i->type >= DPU_HW_BLK_MAX) {
- DPU_ERROR("invalid rm\n");
- return false;
- }
+ for (i = 0; i < ARRAY_SIZE(rm->pingpong_blks); i++) {
+ struct dpu_hw_pingpong *hw;
- i->hw = NULL;
- blk_list = >hw_blks[i->type];
-
- if (i->blk && (>blk->list == blk_list)) {
- DPU_DEBUG("attempt resume iteration past last\n");
- return false;
+ if (rm->pingpong_blks[i]) {
+ hw = to_dpu_hw_pingpong(rm->pingpong_blks[i]);
+ dpu_hw_pingpong_destroy(hw);
+ }
}
+ for (i = 0; i < ARRAY_SIZE(rm->mixer_blks); i++) {
+ struct dpu_hw_mixer *hw;
- i->blk = list_prepare_entry(i->blk, blk_list, list);
-
- list_for_each_entry_continue(i->blk, blk_list, list) {
- if (i->enc_id == i->blk->enc_id) {
- i->hw = i->blk->hw;
- DPU_DEBUG("found type %d id %d for enc %d\n",
- i->type, i->blk->id, i->enc_id);
- return true;
+ if (rm->mixer_blks[i]) {
+ hw = to_dpu_hw_mixer(rm->mixer_blks[i]);
+ dpu_hw_lm_destroy(hw);
}
}
+ for (i = 0; i < ARRAY_SIZE(rm->ctl_blks); i++) {
+ struct dpu_hw_ctl *hw;
- DPU_DEBUG("no match, type %d for enc %d\n", i->type, i->enc_id);
-
- return false;
-}
-
-static bool dpu_rm_get_hw(struct dpu_rm *rm, struct dpu_rm_hw_iter *i)
-{
- bool ret;
-
- mutex_lock(>rm_lock);
- ret = _dpu_rm_get_hw_locked(rm, i);
- mutex_unlock(>rm_lock);
-
- return ret;
-}
-
-static void _dpu_rm_hw_destroy(enum dpu_hw_blk_type type, void *hw)
-{
- switch (type) {
- case DPU_HW_BLK_LM:
- dpu_hw_lm_destroy(hw);
- break;
- case DPU_HW_BLK_CTL:
- dpu_hw_ctl_destroy(hw);
- break;
- case DPU_HW_BLK_PINGPONG:
- dpu_hw_pingpong_destroy(hw);
- break;
- case DPU_HW_BLK_INTF:
- dpu_hw_intf_destroy(hw);
- break;
-
[PATCH 4/4] drm/msm/dpu: Track resources in global state
Move mapping of resources to encoder ids from the resource manager to a
new dpu_global_state struct. Store this struct in global atomic state.
Before this patch, atomic test would be performed by modifying global
state (resource manager), and backing out any changes if the test fails.
By using drm atomic global state, this is not necessary as any changes
to the global state will be discarded if the test fails.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 65 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 84 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 26 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 121 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 22 ++--
5 files changed, 207 insertions(+), 111 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 6cadeff456f09..5afde2e7fef08 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -164,7 +164,6 @@ enum dpu_enc_rc_states {
* clks and resources after IDLE_TIMEOUT time.
* @vsync_event_work: worker to handle vsync event for autorefresh
* @topology: topology of the display
- * @mode_set_complete: flag to indicate modeset completion
* @idle_timeout: idle timeout duration in milliseconds
*/
struct dpu_encoder_virt {
@@ -202,7 +201,6 @@ struct dpu_encoder_virt {
struct delayed_work delayed_off_work;
struct kthread_work vsync_event_work;
struct msm_display_topology topology;
- bool mode_set_complete;
u32 idle_timeout;
};
@@ -563,6 +561,7 @@ static int dpu_encoder_virt_atomic_check(
const struct drm_display_mode *mode;
struct drm_display_mode *adj_mode;
struct msm_display_topology topology;
+ struct dpu_global_state *global_state;
int i = 0;
int ret = 0;
@@ -579,6 +578,7 @@ static int dpu_encoder_virt_atomic_check(
dpu_kms = to_dpu_kms(priv->kms);
mode = _state->mode;
adj_mode = _state->adjusted_mode;
+ global_state = dpu_kms_get_existing_global_state(dpu_kms);
trace_dpu_enc_atomic_check(DRMID(drm_enc));
/*
@@ -610,17 +610,15 @@ static int dpu_encoder_virt_atomic_check(
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
- /* Reserve dynamic resources now. Indicating AtomicTest phase */
+ /* Reserve dynamic resources now. */
if (!ret) {
/*
* Avoid reserving resources when mode set is pending. Topology
* info may not be available to complete reservation.
*/
- if (drm_atomic_crtc_needs_modeset(crtc_state)
- && dpu_enc->mode_set_complete) {
- ret = dpu_rm_reserve(_kms->rm, drm_enc, crtc_state,
-topology, true);
- dpu_enc->mode_set_complete = false;
+ if (drm_atomic_crtc_needs_modeset(crtc_state)) {
+ ret = dpu_rm_reserve(_kms->rm, global_state,
+ drm_enc, crtc_state, topology);
}
}
@@ -957,12 +955,13 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
struct drm_connector *conn = NULL, *conn_iter;
struct drm_crtc *drm_crtc;
struct dpu_crtc_state *cstate;
+ struct dpu_global_state *global_state;
struct msm_display_topology topology;
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
int num_lm, num_ctl, num_pp;
- int i, j, ret;
+ int i, j;
if (!drm_enc) {
DPU_ERROR("invalid encoder\n");
@@ -976,6 +975,12 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
dpu_kms = to_dpu_kms(priv->kms);
connector_list = _kms->dev->mode_config.connector_list;
+ global_state = dpu_kms_get_existing_global_state(dpu_kms);
+ if (IS_ERR_OR_NULL(global_state)) {
+ DPU_ERROR("Failed to get global state");
+ return;
+ }
+
trace_dpu_enc_mode_set(DRMID(drm_enc));
list_for_each_entry(conn_iter, connector_list, head)
@@ -996,21 +1001,14 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
- /* Reserve dynamic resources now. Indicating non-AtomicTest phase */
- ret = dpu_rm_reserve(_kms->rm, drm_enc, drm_crtc->state,
-topology, false);
- if (ret) {
- DPU_ERROR_ENC(dpu_enc,
- "failed to reserve hw resources, %d\n", ret);
[PATCH 1/4] drm/msm/dpu: Remove unused function arguments
Several functions arguments in the resource manager are unused, so
remove them.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 37 ++
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 23f5b1433b357..dea1dba441fe7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -144,8 +144,7 @@ static int _dpu_rm_hw_blk_create(
const struct dpu_mdss_cfg *cat,
void __iomem *mmio,
enum dpu_hw_blk_type type,
- uint32_t id,
- const void *hw_catalog_info)
+ uint32_t id)
{
struct dpu_rm_hw_blk *blk;
void *hw;
@@ -223,7 +222,7 @@ int dpu_rm_init(struct dpu_rm *rm,
}
rc = _dpu_rm_hw_blk_create(rm, cat, mmio, DPU_HW_BLK_LM,
- cat->mixer[i].id, >mixer[i]);
+ cat->mixer[i].id);
if (rc) {
DPU_ERROR("failed: lm hw not available\n");
goto fail;
@@ -244,7 +243,7 @@ int dpu_rm_init(struct dpu_rm *rm,
for (i = 0; i < cat->pingpong_count; i++) {
rc = _dpu_rm_hw_blk_create(rm, cat, mmio, DPU_HW_BLK_PINGPONG,
- cat->pingpong[i].id, >pingpong[i]);
+ cat->pingpong[i].id);
if (rc) {
DPU_ERROR("failed: pp hw not available\n");
goto fail;
@@ -258,7 +257,7 @@ int dpu_rm_init(struct dpu_rm *rm,
}
rc = _dpu_rm_hw_blk_create(rm, cat, mmio, DPU_HW_BLK_INTF,
- cat->intf[i].id, >intf[i]);
+ cat->intf[i].id);
if (rc) {
DPU_ERROR("failed: intf hw not available\n");
goto fail;
@@ -267,7 +266,7 @@ int dpu_rm_init(struct dpu_rm *rm,
for (i = 0; i < cat->ctl_count; i++) {
rc = _dpu_rm_hw_blk_create(rm, cat, mmio, DPU_HW_BLK_CTL,
- cat->ctl[i].id, >ctl[i]);
+ cat->ctl[i].id);
if (rc) {
DPU_ERROR("failed: ctl hw not available\n");
goto fail;
@@ -293,7 +292,6 @@ static bool _dpu_rm_needs_split_display(const struct
msm_display_topology *top)
* pingpong
* @rm: dpu resource manager handle
* @enc_id: encoder id requesting for allocation
- * @reqs: proposed use case requirements
* @lm: proposed layer mixer, function checks if lm, and all other hardwired
* blocks connected to the lm (pp) is available and appropriate
* @pp: output parameter, pingpong block attached to the layer mixer.
@@ -305,7 +303,6 @@ static bool _dpu_rm_needs_split_display(const struct
msm_display_topology *top)
static bool _dpu_rm_check_lm_and_get_connected_blks(
struct dpu_rm *rm,
uint32_t enc_id,
- struct dpu_rm_requirements *reqs,
struct dpu_rm_hw_blk *lm,
struct dpu_rm_hw_blk **pp,
struct dpu_rm_hw_blk *primary_lm)
@@ -384,7 +381,7 @@ static int _dpu_rm_reserve_lms(struct dpu_rm *rm, uint32_t
enc_id,
lm[lm_count] = iter_i.blk;
if (!_dpu_rm_check_lm_and_get_connected_blks(
- rm, enc_id, reqs, lm[lm_count],
+ rm, enc_id, lm[lm_count],
[lm_count], NULL))
continue;
@@ -399,7 +396,7 @@ static int _dpu_rm_reserve_lms(struct dpu_rm *rm, uint32_t
enc_id,
continue;
if (!_dpu_rm_check_lm_and_get_connected_blks(
- rm, enc_id, reqs, iter_j.blk,
+ rm, enc_id, iter_j.blk,
[lm_count], iter_i.blk))
continue;
@@ -480,20 +477,19 @@ static int _dpu_rm_reserve_ctls(
static int _dpu_rm_reserve_intf(
struct dpu_rm *rm,
uint32_t enc_id,
- uint32_t id,
- enum dpu_hw_blk_type type)
+ uint32_t id)
{
struct dpu_rm_hw_iter iter;
int ret = 0;
/* Find the block entry in the rm, and note the reservation */
- dpu_rm_init_hw_iter(, 0, type);
+ dpu_rm_init_hw_iter(, 0, DPU_HW_BLK_INTF);
while (_dpu_rm_get_hw_locked(rm, )) {
if (iter.blk->id != id)
continue;
if (RESERVED_BY_OTHER(iter.blk, enc_id)) {
- DPU_ERROR("type %d id %d already reserved\n", type, id);
+ DPU_ERROR("intf id %d already reserved\n", id);
[pull] amdgpu 5.6 fixes
Hi Dave, Daniel, Fixes for 5.6. The following changes since commit 6f4134b30b6ee33e2fd4d602099e6c5e60d0351a: Merge tag 'drm-intel-next-fixes-2020-02-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2020-02-14 13:04:46 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.6-2020-02-19 for you to fetch changes up to 6c62ce8073daf27ae3fd03b6929d6cea3887eeb2: drm/amdgpu/display: clean up hdcp workqueue handling (2020-02-19 11:03:24 -0500) amd-drm-fixes-5.6-2020-02-19: amdgpu: - HDCP fixes - xclk fix for raven - GFXOFF fixes Alex Deucher (4): drm/amdgpu/soc15: fix xclk for raven drm/amdgpu/gfx9: disable gfxoff when reading rlc clock drm/amdgpu/gfx10: disable gfxoff when reading rlc clock drm/amdgpu/display: clean up hdcp workqueue handling Bhawanpreet Lakha (2): drm/amd/display: fix backwards byte order in rx_caps. drm/amd/display: fix dtm unloading Evan Quan (1): drm/amd/powerplay: always refetch the enabled features status on dpm enablement changzhu (1): drm/amdgpu: add is_raven_kicker judgement for raven1 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 26 +- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 ++ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 13 +-- drivers/gpu/drm/amd/amdgpu/soc15.c | 7 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 + .../drm/amd/display/modules/hdcp/hdcp2_execution.c | 4 ++-- drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 ++--- 7 files changed, 55 insertions(+), 13 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Greg, On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote: > On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > > quality. The biggest wrong pattern is that developers use devm_, which > > > > > ties the release action to the underlying struct device, whereas > > > > > all the userspace visible stuff attached to a drm_device can long > > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > > files and mmap'ed buffers). Give people what they want, but with more > > > > > correctness. > > > > > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > > actions (but kfree exists, we'll need that soon). Plus all specific to > > > > > drm_device ofc, including the logging. Which I didn't bother to make > > > > > compile-time optional, since none of the other drm logging is compile > > > > > time optional either. > > > > > > > > > > One tricky bit here is the chicken between allocating your > > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > > allocation registered before drm_dev_init registers any of its own > > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > > drm_device is emebedded into the overall structure, and by the time it > > > > > returns it'll all be too late. And forcing drivers to be able clean up > > > > > everything except the one kzalloc is silly. > > > > > > > > > > Work around this by having a very special final_kfree pointer. This > > > > > also avoids troubles with the list head possibly disappearing from > > > > > underneath us when we release all resources attached to the > > > > > drm_device. > > > > > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > > > using devm_k*alloc to allocate data accessible by userspace. Since the > > > > introduction of devm_*, we've likely reduced the number of memory leaks, > > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > > some drivers that used .release() callbacks correctly being naively > > > > converted to incorrect devm_* usage :-( > > > > > > > > This leads me to a question: if other subsystems have the same problem, > > > > could we turn this implementation into something more generic ? It > > > > doesn't have to be done right away and shouldn't block merging this > > > > series, but I think it would be very useful. > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > (driver_memory?) > > > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > > this being needed here. > > > > There's two reasons I went with copypasta instead of trying to share code: > > - Type checking, I definitely don't want people to mix up devm_ with > > drmm_. But even if we do a drv_m that subsystems could embed we do > > have quite a few different types of component drivers (and with > > drm_panel and drm_bridge even standardized), and I don't want people > > to be able to pass the wrong kind of struct to e.g. a managed > > drmm_connector_init - it really needs to be the drm_device, not a > > panel or bridge or something else. > > Fair enough, that makes sense. > > > - We could still share the code as a kind of implementation/backend > > library. But it's not much, and with embedding I could use the drm > > device logging stuff which is kinda nice. But if there's more demand > > for this I can definitely see the point in sharing this, as Laurent > > pointed out with the tiny optimization with not allocating a NULL void > > * that I've done (and screwed up) it's not entirely trivial code. > > I think moving over time to having this be a backend library is good. > But no rush/issues here with this going in now, it solves a real need > and we can refactor it later on to try to make it more "bus/class" > generic as needed. >From a type checking point of view, it would then be nice to have a structure that models a device node, other than just struct device that is shared by all types of devices. As someone who was involve in the creation of the device model we have today, and thus know the history, what's your opinion on that ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org
Re: [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_
Den 19.02.2020 17.23, skrev Daniel Vetter:
> On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart
> wrote:
>>
>> Hi Daniel,
>>
>> On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
>>> On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote:
On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote:
> drm_mode_config_cleanup is idempotent, so no harm in calling this
> twice. This allows us to gradually switch drivers over by removing
> explicit drm_mode_config_cleanup calls.
>
> With this step it's not also possible that (at least for simple
> drivers) automatic resource cleanup can be done correctly without a
> drm_driver->release hook. Therefore allow this now in
> devm_drm_dev_init().
>
> Also with drmm_ explicit drm_driver->release hooks are kinda not the
> best option, so deprecate that hook to discourage future users.
>
> v2: Fixup the example in the kerneldoc too.
>
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Signed-off-by: Daniel Vetter
> ---
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index 08e6eff6a179..957db1edba0c 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -373,6 +374,11 @@ static int
> drm_mode_create_standard_properties(struct drm_device *dev)
> return 0;
> }
>
> +static void drm_mode_config_init_release(struct drm_device *dev, void
> *ptr)
> +{
> + drm_mode_config_cleanup(dev);
> +}
> +
> /**
> * drm_mode_config_init - initialize DRM mode_configuration structure
> * @dev: DRM device
> @@ -384,8 +390,10 @@ static int
> drm_mode_create_standard_properties(struct drm_device *dev)
> * problem, since this should happen single threaded at init time. It is
> the
> * driver's problem to ensure this guarantee.
> *
> + * Cleanup is automatically handled through registering
> drm_mode_config_cleanup
> + * with drmm_add_action().
> */
> -void drm_mode_config_init(struct drm_device *dev)
> +int drm_mode_config_init(struct drm_device *dev)
> {
> mutex_init(>mode_config.mutex);
> drm_modeset_lock_init(>mode_config.connection_mutex);
> @@ -443,6 +451,8 @@ void drm_mode_config_init(struct drm_device *dev)
> drm_modeset_acquire_fini(_ctx);
> dma_resv_fini();
> }
> +
> + return drmm_add_action(dev, drm_mode_config_init_release, NULL);
If this fails, shouldn't drm_mode_config_cleanup() be called here ?
>>>
>>> Maybe for ocd reasons, but not for actually cleaning up anything. It's
>>> just a bunch of empty lists that drm_mode_config_cleanup will walk and
>>> do nothing about. Not sure I should add that ...
>>
>> How about the ida init, and the mutex_init() that isn't a no-op when
>> lock debugging is enabled ?
>
> Hm right, I'll fix this.
>
You could make a drmm_ version of devm_add_action_or_reset() for this.
Noralf.
> Fun thing is that I've found a pile of missing mutex_destroy and
> ida_cleanup() while reviewing all the code I've read. Not sure I've
> fixed them all up ...
> -Daniel
>
>>
> }
> EXPORT_SYMBOL(drm_mode_config_init);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 6:02 PM Laurent Pinchart wrote: > > Hi Daniel, > > On Wed, Feb 19, 2020 at 05:53:59PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart wrote: > > > On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote: > > >> On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > >>> On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > >> On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > >>> We have lots of these. And the cleanup code tends to be of dubious > > >>> quality. The biggest wrong pattern is that developers use devm_, > > >>> which > > >>> ties the release action to the underlying struct device, whereas > > >>> all the userspace visible stuff attached to a drm_device can long > > >>> outlive that one (e.g. after a hotunplug while userspace has open > > >>> files and mmap'ed buffers). Give people what they want, but with > > >>> more > > >>> correctness. > > >>> > > >>> Mostly copied from devres.c, with types adjusted to fit drm_device > > >>> and > > >>> a few simplifications - I didn't (yet) copy over everything. Since > > >>> the types don't match code sharing looked like a hopeless endeavour. > > >>> > > >>> For now it's only super simplified, no groups, you can't remove > > >>> actions (but kfree exists, we'll need that soon). Plus all specific > > >>> to > > >>> drm_device ofc, including the logging. Which I didn't bother to make > > >>> compile-time optional, since none of the other drm logging is > > >>> compile > > >>> time optional either. > > >>> > > >>> One tricky bit here is the chicken between allocating your > > >>> drm_device structure and initiliazing it with drm_dev_init. For > > >>> perfect onion unwinding we'd need to have the action to kfree the > > >>> allocation registered before drm_dev_init registers any of its own > > >>> release handlers. But drm_dev_init doesn't know where exactly the > > >>> drm_device is emebedded into the overall structure, and by the time > > >>> it > > >>> returns it'll all be too late. And forcing drivers to be able clean > > >>> up > > >>> everything except the one kzalloc is silly. > > >>> > > >>> Work around this by having a very special final_kfree pointer. This > > >>> also avoids troubles with the list head possibly disappearing from > > >>> underneath us when we release all resources attached to the > > >>> drm_device. > > >> > > >> This is all a very good idea ! Many subsystems are plagged by drivers > > >> using devm_k*alloc to allocate data accessible by userspace. Since > > >> the > > >> introduction of devm_*, we've likely reduced the number of memory > > >> leaks, > > >> but I'm pretty sure we've increased the risk of crashes as I've seen > > >> some drivers that used .release() callbacks correctly being naively > > >> converted to incorrect devm_* usage :-( > > >> > > >> This leads me to a question: if other subsystems have the same > > >> problem, > > >> could we turn this implementation into something more generic ? It > > >> doesn't have to be done right away and shouldn't block merging this > > >> series, but I think it would be very useful. > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > (driver_memory?) > > > > > > And yes, I think it's much better than devm_* for the obvious reasons > > > of > > > this being needed here. > > > > There's two reasons I went with copypasta instead of trying to share > > code: > > - Type checking, I definitely don't want people to mix up devm_ with > > drmm_. But even if we do a drv_m that subsystems could embed we do > > have quite a few different types of component drivers (and with > > drm_panel and drm_bridge even standardized), and I don't want people > > to be able to pass the wrong kind of struct to e.g. a managed > > drmm_connector_init - it really needs to be the drm_device, not a > > panel or bridge or something else. > > > > - We could still share the code as a kind of implementation/backend > > library. But it's not much, and with embedding I could use the drm > > device logging stuff which is kinda nice. But if there's more demand > > for this I can definitely see the point in sharing this, as Laurent > > pointed out with the tiny optimization with not allocating a NULL void > > * that I've done (and screwed up) it's not entirely trivial code. > > >>> > > >>> My 2c as they say, although closer to a brain dump :-) > > >>> > > >>> On one hand the drm_device has an embedded struct device. On the other > >
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Daniel, On Wed, Feb 19, 2020 at 05:53:59PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote: > >> On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > >>> On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > >> On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > >>> We have lots of these. And the cleanup code tends to be of dubious > >>> quality. The biggest wrong pattern is that developers use devm_, which > >>> ties the release action to the underlying struct device, whereas > >>> all the userspace visible stuff attached to a drm_device can long > >>> outlive that one (e.g. after a hotunplug while userspace has open > >>> files and mmap'ed buffers). Give people what they want, but with more > >>> correctness. > >>> > >>> Mostly copied from devres.c, with types adjusted to fit drm_device and > >>> a few simplifications - I didn't (yet) copy over everything. Since > >>> the types don't match code sharing looked like a hopeless endeavour. > >>> > >>> For now it's only super simplified, no groups, you can't remove > >>> actions (but kfree exists, we'll need that soon). Plus all specific to > >>> drm_device ofc, including the logging. Which I didn't bother to make > >>> compile-time optional, since none of the other drm logging is compile > >>> time optional either. > >>> > >>> One tricky bit here is the chicken between allocating your > >>> drm_device structure and initiliazing it with drm_dev_init. For > >>> perfect onion unwinding we'd need to have the action to kfree the > >>> allocation registered before drm_dev_init registers any of its own > >>> release handlers. But drm_dev_init doesn't know where exactly the > >>> drm_device is emebedded into the overall structure, and by the time it > >>> returns it'll all be too late. And forcing drivers to be able clean up > >>> everything except the one kzalloc is silly. > >>> > >>> Work around this by having a very special final_kfree pointer. This > >>> also avoids troubles with the list head possibly disappearing from > >>> underneath us when we release all resources attached to the > >>> drm_device. > >> > >> This is all a very good idea ! Many subsystems are plagged by drivers > >> using devm_k*alloc to allocate data accessible by userspace. Since the > >> introduction of devm_*, we've likely reduced the number of memory > >> leaks, > >> but I'm pretty sure we've increased the risk of crashes as I've seen > >> some drivers that used .release() callbacks correctly being naively > >> converted to incorrect devm_* usage :-( > >> > >> This leads me to a question: if other subsystems have the same problem, > >> could we turn this implementation into something more generic ? It > >> doesn't have to be done right away and shouldn't block merging this > >> series, but I think it would be very useful. > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > (driver_memory?) > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > this being needed here. > > There's two reasons I went with copypasta instead of trying to share > code: > - Type checking, I definitely don't want people to mix up devm_ with > drmm_. But even if we do a drv_m that subsystems could embed we do > have quite a few different types of component drivers (and with > drm_panel and drm_bridge even standardized), and I don't want people > to be able to pass the wrong kind of struct to e.g. a managed > drmm_connector_init - it really needs to be the drm_device, not a > panel or bridge or something else. > > - We could still share the code as a kind of implementation/backend > library. But it's not much, and with embedding I could use the drm > device logging stuff which is kinda nice. But if there's more demand > for this I can definitely see the point in sharing this, as Laurent > pointed out with the tiny optimization with not allocating a NULL void > * that I've done (and screwed up) it's not entirely trivial code. > >>> > >>> My 2c as they say, although closer to a brain dump :-) > >>> > >>> On one hand the drm_device has an embedded struct device. On the other > >>> drm_device preserves state which outlives the embedded struct device. > >>> > >>> Would it make sense to keep drm_device better related to the > >>> underlying device? Effectively moving the $misc state to drm_driver. > >>> This idea does raise another question - struct drm_driver unlike many > >>> other struct $foo_driver, does not embedded
Re: [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman > wrote: > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > Hi Daniel, > > > > > > Thank you for the patch. > > > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > quality. The biggest wrong pattern is that developers use devm_, which > > > > ties the release action to the underlying struct device, whereas > > > > all the userspace visible stuff attached to a drm_device can long > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > files and mmap'ed buffers). Give people what they want, but with more > > > > correctness. > > > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > actions (but kfree exists, we'll need that soon). Plus all specific to > > > > drm_device ofc, including the logging. Which I didn't bother to make > > > > compile-time optional, since none of the other drm logging is compile > > > > time optional either. > > > > > > > > One tricky bit here is the chicken between allocating your > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > allocation registered before drm_dev_init registers any of its own > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > drm_device is emebedded into the overall structure, and by the time it > > > > returns it'll all be too late. And forcing drivers to be able clean up > > > > everything except the one kzalloc is silly. > > > > > > > > Work around this by having a very special final_kfree pointer. This > > > > also avoids troubles with the list head possibly disappearing from > > > > underneath us when we release all resources attached to the > > > > drm_device. > > > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > > using devm_k*alloc to allocate data accessible by userspace. Since the > > > introduction of devm_*, we've likely reduced the number of memory leaks, > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > some drivers that used .release() callbacks correctly being naively > > > converted to incorrect devm_* usage :-( > > > > > > This leads me to a question: if other subsystems have the same problem, > > > could we turn this implementation into something more generic ? It > > > doesn't have to be done right away and shouldn't block merging this > > > series, but I think it would be very useful. > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > (driver_memory?) > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > this being needed here. > > There's two reasons I went with copypasta instead of trying to share code: > - Type checking, I definitely don't want people to mix up devm_ with > drmm_. But even if we do a drv_m that subsystems could embed we do > have quite a few different types of component drivers (and with > drm_panel and drm_bridge even standardized), and I don't want people > to be able to pass the wrong kind of struct to e.g. a managed > drmm_connector_init - it really needs to be the drm_device, not a > panel or bridge or something else. Fair enough, that makes sense. > - We could still share the code as a kind of implementation/backend > library. But it's not much, and with embedding I could use the drm > device logging stuff which is kinda nice. But if there's more demand > for this I can definitely see the point in sharing this, as Laurent > pointed out with the tiny optimization with not allocating a NULL void > * that I've done (and screwed up) it's not entirely trivial code. I think moving over time to having this be a backend library is good. But no rush/issues here with this going in now, it solves a real need and we can refactor it later on to try to make it more "bus/class" generic as needed. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart wrote: > > Hi Daniel, > > On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > > >> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > >>> On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > We have lots of these. And the cleanup code tends to be of dubious > > > quality. The biggest wrong pattern is that developers use devm_, which > > > ties the release action to the underlying struct device, whereas > > > all the userspace visible stuff attached to a drm_device can long > > > outlive that one (e.g. after a hotunplug while userspace has open > > > files and mmap'ed buffers). Give people what they want, but with more > > > correctness. > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > > a few simplifications - I didn't (yet) copy over everything. Since > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > For now it's only super simplified, no groups, you can't remove > > > actions (but kfree exists, we'll need that soon). Plus all specific to > > > drm_device ofc, including the logging. Which I didn't bother to make > > > compile-time optional, since none of the other drm logging is compile > > > time optional either. > > > > > > One tricky bit here is the chicken between allocating your > > > drm_device structure and initiliazing it with drm_dev_init. For > > > perfect onion unwinding we'd need to have the action to kfree the > > > allocation registered before drm_dev_init registers any of its own > > > release handlers. But drm_dev_init doesn't know where exactly the > > > drm_device is emebedded into the overall structure, and by the time it > > > returns it'll all be too late. And forcing drivers to be able clean up > > > everything except the one kzalloc is silly. > > > > > > Work around this by having a very special final_kfree pointer. This > > > also avoids troubles with the list head possibly disappearing from > > > underneath us when we release all resources attached to the > > > drm_device. > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > using devm_k*alloc to allocate data accessible by userspace. Since the > > introduction of devm_*, we've likely reduced the number of memory > > leaks, > > but I'm pretty sure we've increased the risk of crashes as I've seen > > some drivers that used .release() callbacks correctly being naively > > converted to incorrect devm_* usage :-( > > > > This leads me to a question: if other subsystems have the same problem, > > could we turn this implementation into something more generic ? It > > doesn't have to be done right away and shouldn't block merging this > > series, but I think it would be very useful. > > >>> > > >>> It shouldn't be that hard to tie this into a drv_m() type of a thing > > >>> (driver_memory?) > > >>> > > >>> And yes, I think it's much better than devm_* for the obvious reasons of > > >>> this being needed here. > > >> > > >> There's two reasons I went with copypasta instead of trying to share > > >> code: > > >> - Type checking, I definitely don't want people to mix up devm_ with > > >> drmm_. But even if we do a drv_m that subsystems could embed we do > > >> have quite a few different types of component drivers (and with > > >> drm_panel and drm_bridge even standardized), and I don't want people > > >> to be able to pass the wrong kind of struct to e.g. a managed > > >> drmm_connector_init - it really needs to be the drm_device, not a > > >> panel or bridge or something else. > > >> > > >> - We could still share the code as a kind of implementation/backend > > >> library. But it's not much, and with embedding I could use the drm > > >> device logging stuff which is kinda nice. But if there's more demand > > >> for this I can definitely see the point in sharing this, as Laurent > > >> pointed out with the tiny optimization with not allocating a NULL void > > >> * that I've done (and screwed up) it's not entirely trivial code. > > > > > > My 2c as they say, although closer to a brain dump :-) > > > > > > On one hand the drm_device has an embedded struct device. On the other > > > drm_device preserves state which outlives the embedded struct device. > > > > > > Would it make sense to keep drm_device better related to the > > > underlying device? Effectively moving the $misc state to drm_driver. > > > This idea does raise another question - struct drm_driver unlike many > > > other struct $foo_driver, does not embedded device_driver :-( > > > So if one is to cover the above two,
Re: [PATCH v5] dt-bindings: display: renesas: du: Document optional reset properties
Hi Geert, On Wed, Feb 19, 2020 at 05:36:57PM +0100, Geert Uytterhoeven wrote: > On Wed, Feb 19, 2020 at 5:04 PM Laurent Pinchart wrote: > > On Fri, Feb 14, 2020 at 09:26:23AM +0100, Geert Uytterhoeven wrote: > > > Document the optional properties for describing module resets, to > > > support resetting display channels on R-Car Gen2 and Gen3. > > > > > > Signed-off-by: Geert Uytterhoeven > > > Acked-by: Laurent Pinchart > > > Acked-by: Rob Herring > > > > --- a/Documentation/devicetree/bindings/display/renesas,du.txt > > > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt > > > @@ -50,6 +50,14 @@ Required Properties: > > > VSP instance that serves the DU channel, and the channel index > > > identifies > > > the LIF instance in that VSP. > > > > > > +Optional properties: > > > + - resets: A list of phandle + reset-specifier pairs, one for each > > > entry in > > > +the reset-names property. > > > + - reset-names: Names of the resets. This property is model-dependent. > > > +- All but R8A7779 use one reset for a group of one or more successive > > > + channels. The resets must be named "du.x" with "x" being the > > > numerical > > > + index of the lowest channel in the group. > > > > I've now reviewed the patches that add those properties to our .dtsi > > files, and I wonder how we should handle the two SoCs that have DU0, DU1 > > and DU3, but not DU2. The reset resource is tied to a group of two > > channels, so we would use du.0 and du.2 respectively, but that conflicts > > with the above text. > > > > I'm trying to think about the implementation on the driver side, where > > group resources are associated with a group object, whose index is > > computed by dividing the channel number by 2. We could have a special > > case in group initialization that uses du.3 instead of du.2 for the > > second group. > > > > What do you think ? Probably overkill, and we should go for du.3 ? > > The "division by 2" rule is valid for R-Car Gen3, but not for R-Car > Gen2, where there is only a single reset for all channels. > > Originally we had "du.0-1" and "du.2-3" (hmm, somehow I missed adding > this to the changelog for the bindings, but it is present in the > changelog for the DTS files), but after switching to "du.0" and "du.2", > I always envisioned implementing this by finding a "du.x" reset by > looping from the current channel index to 0. That algorithm works for all > supported SoCs (irrespective of naming the second reset on R-Car H3-N > and M3-N "du.2" or "du.3" ;-) > > As per your comment about single resets, we could drop reset-names on > R-Car Gen2, but doing so would mean another special case in the driver. Probably not worth it indeed. We can handle all this in the driver, let's keep it as-is. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Daniel, On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > >> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > >>> On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > We have lots of these. And the cleanup code tends to be of dubious > > quality. The biggest wrong pattern is that developers use devm_, which > > ties the release action to the underlying struct device, whereas > > all the userspace visible stuff attached to a drm_device can long > > outlive that one (e.g. after a hotunplug while userspace has open > > files and mmap'ed buffers). Give people what they want, but with more > > correctness. > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > a few simplifications - I didn't (yet) copy over everything. Since > > the types don't match code sharing looked like a hopeless endeavour. > > > > For now it's only super simplified, no groups, you can't remove > > actions (but kfree exists, we'll need that soon). Plus all specific to > > drm_device ofc, including the logging. Which I didn't bother to make > > compile-time optional, since none of the other drm logging is compile > > time optional either. > > > > One tricky bit here is the chicken between allocating your > > drm_device structure and initiliazing it with drm_dev_init. For > > perfect onion unwinding we'd need to have the action to kfree the > > allocation registered before drm_dev_init registers any of its own > > release handlers. But drm_dev_init doesn't know where exactly the > > drm_device is emebedded into the overall structure, and by the time it > > returns it'll all be too late. And forcing drivers to be able clean up > > everything except the one kzalloc is silly. > > > > Work around this by having a very special final_kfree pointer. This > > also avoids troubles with the list head possibly disappearing from > > underneath us when we release all resources attached to the > > drm_device. > > This is all a very good idea ! Many subsystems are plagged by drivers > using devm_k*alloc to allocate data accessible by userspace. Since the > introduction of devm_*, we've likely reduced the number of memory leaks, > but I'm pretty sure we've increased the risk of crashes as I've seen > some drivers that used .release() callbacks correctly being naively > converted to incorrect devm_* usage :-( > > This leads me to a question: if other subsystems have the same problem, > could we turn this implementation into something more generic ? It > doesn't have to be done right away and shouldn't block merging this > series, but I think it would be very useful. > >>> > >>> It shouldn't be that hard to tie this into a drv_m() type of a thing > >>> (driver_memory?) > >>> > >>> And yes, I think it's much better than devm_* for the obvious reasons of > >>> this being needed here. > >> > >> There's two reasons I went with copypasta instead of trying to share code: > >> - Type checking, I definitely don't want people to mix up devm_ with > >> drmm_. But even if we do a drv_m that subsystems could embed we do > >> have quite a few different types of component drivers (and with > >> drm_panel and drm_bridge even standardized), and I don't want people > >> to be able to pass the wrong kind of struct to e.g. a managed > >> drmm_connector_init - it really needs to be the drm_device, not a > >> panel or bridge or something else. > >> > >> - We could still share the code as a kind of implementation/backend > >> library. But it's not much, and with embedding I could use the drm > >> device logging stuff which is kinda nice. But if there's more demand > >> for this I can definitely see the point in sharing this, as Laurent > >> pointed out with the tiny optimization with not allocating a NULL void > >> * that I've done (and screwed up) it's not entirely trivial code. > > > > My 2c as they say, although closer to a brain dump :-) > > > > On one hand the drm_device has an embedded struct device. On the other > > drm_device preserves state which outlives the embedded struct device. > > > > Would it make sense to keep drm_device better related to the > > underlying device? Effectively moving the $misc state to drm_driver. > > This idea does raise another question - struct drm_driver unlike many > > other struct $foo_driver, does not embedded device_driver :-( > > So if one is to cover the above two, then the embedding concerns will > > be elevated. > > drm_driver isn't a bus device driver in the linux driver model sense, > but an uapi thing that sits on top of some underlying device. So maybe > better to rename drm_driver to
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, 19 Feb 2020 at 16:22, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > > > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > > > > > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman > > > wrote: > > > > > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > > Hi Daniel, > > > > > > > > > > Thank you for the patch. > > > > > > > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > > > quality. The biggest wrong pattern is that developers use devm_, > > > > > > which > > > > > > ties the release action to the underlying struct device, whereas > > > > > > all the userspace visible stuff attached to a drm_device can long > > > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > > > files and mmap'ed buffers). Give people what they want, but with > > > > > > more > > > > > > correctness. > > > > > > > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device > > > > > > and > > > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > > > actions (but kfree exists, we'll need that soon). Plus all specific > > > > > > to > > > > > > drm_device ofc, including the logging. Which I didn't bother to make > > > > > > compile-time optional, since none of the other drm logging is > > > > > > compile > > > > > > time optional either. > > > > > > > > > > > > One tricky bit here is the chicken between allocating your > > > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > > > allocation registered before drm_dev_init registers any of its own > > > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > > > drm_device is emebedded into the overall structure, and by the time > > > > > > it > > > > > > returns it'll all be too late. And forcing drivers to be able clean > > > > > > up > > > > > > everything except the one kzalloc is silly. > > > > > > > > > > > > Work around this by having a very special final_kfree pointer. This > > > > > > also avoids troubles with the list head possibly disappearing from > > > > > > underneath us when we release all resources attached to the > > > > > > drm_device. > > > > > > > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > > > > using devm_k*alloc to allocate data accessible by userspace. Since the > > > > > introduction of devm_*, we've likely reduced the number of memory > > > > > leaks, > > > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > > > some drivers that used .release() callbacks correctly being naively > > > > > converted to incorrect devm_* usage :-( > > > > > > > > > > This leads me to a question: if other subsystems have the same > > > > > problem, > > > > > could we turn this implementation into something more generic ? It > > > > > doesn't have to be done right away and shouldn't block merging this > > > > > series, but I think it would be very useful. > > > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > > (driver_memory?) > > > > > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > > > this being needed here. > > > > > > There's two reasons I went with copypasta instead of trying to share code: > > > - Type checking, I definitely don't want people to mix up devm_ with > > > drmm_. But even if we do a drv_m that subsystems could embed we do > > > have quite a few different types of component drivers (and with > > > drm_panel and drm_bridge even standardized), and I don't want people > > > to be able to pass the wrong kind of struct to e.g. a managed > > > drmm_connector_init - it really needs to be the drm_device, not a > > > panel or bridge or something else. > > > > > > - We could still share the code as a kind of implementation/backend > > > library. But it's not much, and with embedding I could use the drm > > > device logging stuff which is kinda nice. But if there's more demand > > > for this I can definitely see the point in sharing this, as Laurent > > > pointed out with the tiny optimization with not allocating a NULL void > > > * that I've done (and screwed up) it's not entirely trivial code. > > > > > > > My 2c as they say, although closer to a brain dump :-) > > > > On one hand the drm_device has an embedded struct device. On the other > > drm_device preserves state which outlives the embedded struct device. > > > > Would it make sense to keep drm_device better related to the > > underlying device? Effectively moving the $misc state to drm_driver. > > This idea does raise
Re: [PATCH v5] dt-bindings: display: renesas: du: Document optional reset properties
Hi Laurent,
On Wed, Feb 19, 2020 at 5:04 PM Laurent Pinchart
wrote:
> On Fri, Feb 14, 2020 at 09:26:23AM +0100, Geert Uytterhoeven wrote:
> > Document the optional properties for describing module resets, to
> > support resetting display channels on R-Car Gen2 and Gen3.
> >
> > Signed-off-by: Geert Uytterhoeven
> > Acked-by: Laurent Pinchart
> > Acked-by: Rob Herring
> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> > @@ -50,6 +50,14 @@ Required Properties:
> > VSP instance that serves the DU channel, and the channel index
> > identifies
> > the LIF instance in that VSP.
> >
> > +Optional properties:
> > + - resets: A list of phandle + reset-specifier pairs, one for each entry
> > in
> > +the reset-names property.
> > + - reset-names: Names of the resets. This property is model-dependent.
> > +- All but R8A7779 use one reset for a group of one or more successive
> > + channels. The resets must be named "du.x" with "x" being the
> > numerical
> > + index of the lowest channel in the group.
>
> I've now reviewed the patches that add those properties to our .dtsi
> files, and I wonder how we should handle the two SoCs that have DU0, DU1
> and DU3, but not DU2. The reset resource is tied to a group of two
> channels, so we would use du.0 and du.2 respectively, but that conflicts
> with the above text.
>
> I'm trying to think about the implementation on the driver side, where
> group resources are associated with a group object, whose index is
> computed by dividing the channel number by 2. We could have a special
> case in group initialization that uses du.3 instead of du.2 for the
> second group.
>
> What do you think ? Probably overkill, and we should go for du.3 ?
The "division by 2" rule is valid for R-Car Gen3, but not for R-Car
Gen2, where there is only a single reset for all channels.
Originally we had "du.0-1" and "du.2-3" (hmm, somehow I missed adding
this to the changelog for the bindings, but it is present in the
changelog for the DTS files), but after switching to "du.0" and "du.2",
I always envisioned implementing this by finding a "du.x" reset by
looping from the current channel index to 0. That algorithm works for all
supported SoCs (irrespective of naming the second reset on R-Car H3-N
and M3-N "du.2" or "du.3" ;-)
As per your comment about single resets, we could drop reset-names on
R-Car Gen2, but doing so would mean another special case in the driver.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/52] drm: Set final_kfree in drm_dev_alloc
On 2/19/20 12:20 PM, Daniel Vetter wrote: > I also did a full review of all callers, and only the xen driver > forgot to call drm_dev_put in the failure path. Fix that up too. > > v2: I noticed that xen has a drm_driver.release hook, and uses > drm_dev_alloc(). We need to remove the kfree from > xen_drm_drv_release(). > > bochs also has a release hook, but leaked the drm_device ever since > > commit 0a6659bdc5e8221da99eebb176fd9591435e38de > Author: Gerd Hoffmann > Date: Tue Dec 17 18:04:46 2013 +0100 > > drm/bochs: new driver > > This patch here fixes that leak. > > Same for virtio, started leaking with > > commit b1df3a2b24a917f8853d43fe9683c0e360d2c33a > Author: Gerd Hoffmann > Date: Tue Feb 11 14:58:04 2020 +0100 > > drm/virtio: add drm_driver.release callback. > > Cc: Gerd Hoffmann > Cc: Oleksandr Andrushchenko > Cc: xen-de...@lists.xenproject.org > > Signed-off-by: Daniel Vetter Thank you, Reviewed-by: Oleksandr Andrushchenko > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Oleksandr Andrushchenko > Cc: xen-de...@lists.xenproject.org > --- > drivers/gpu/drm/drm_drv.c | 3 +++ > drivers/gpu/drm/xen/xen_drm_front.c | 2 +- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index 3e5627d6eba6..9e62e28bbc62 100644 > --- a/drivers/gpu/drm/drm_drv.c > +++ b/drivers/gpu/drm/drm_drv.c > @@ -39,6 +39,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -819,6 +820,8 @@ struct drm_device *drm_dev_alloc(struct drm_driver > *driver, > return ERR_PTR(ret); > } > > + drmm_add_final_kfree(dev, dev); > + > return dev; > } > EXPORT_SYMBOL(drm_dev_alloc); > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c > b/drivers/gpu/drm/xen/xen_drm_front.c > index 4be49c1aef51..d22b5da38935 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -461,7 +461,6 @@ static void xen_drm_drv_release(struct drm_device *dev) > drm_mode_config_cleanup(dev); > > drm_dev_fini(dev); > - kfree(dev); > > if (front_info->cfg.be_alloc) > xenbus_switch_state(front_info->xb_dev, > @@ -561,6 +560,7 @@ static int xen_drm_drv_init(struct xen_drm_front_info > *front_info) > fail_modeset: > drm_kms_helper_poll_fini(drm_dev); > drm_mode_config_cleanup(drm_dev); > + drm_dev_put(drm_dev); > fail: > kfree(drm_info); > return ret; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Wed, Feb 19, 2020 at 11:18 AM Johannes Weiner wrote: > > Yes, I'd go with absolute units when it comes to memory, because it's > not a renewable resource like CPU and IO, and so we do have cliff > behavior around the edge where you transition from ok to not-enough. > > memory.low is a bit in flux right now, so if anything is unclear > around its semantics, please feel free to reach out. I am not familiar with the discussion, would you point me to a relevant thread please? In addition, is there some kind of order of preference for implementing low vs high vs max? Regards, Kenny ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_
On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
> > On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote:
> > > On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote:
> > > > drm_mode_config_cleanup is idempotent, so no harm in calling this
> > > > twice. This allows us to gradually switch drivers over by removing
> > > > explicit drm_mode_config_cleanup calls.
> > > >
> > > > With this step it's not also possible that (at least for simple
> > > > drivers) automatic resource cleanup can be done correctly without a
> > > > drm_driver->release hook. Therefore allow this now in
> > > > devm_drm_dev_init().
> > > >
> > > > Also with drmm_ explicit drm_driver->release hooks are kinda not the
> > > > best option, so deprecate that hook to discourage future users.
> > > >
> > > > v2: Fixup the example in the kerneldoc too.
> > > >
> > > > Cc: "Noralf Trønnes"
> > > > Cc: Sam Ravnborg
> > > > Cc: Thomas Zimmermann
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/drm_drv.c | 21 +
> > > > drivers/gpu/drm/drm_mode_config.c | 12 +++-
> > > > include/drm/drm_mode_config.h | 2 +-
> > > > 3 files changed, 17 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > > index 3cf40864d4a6..428c569aaaf1 100644
> > > > --- a/drivers/gpu/drm/drm_drv.c
> > > > +++ b/drivers/gpu/drm/drm_drv.c
> > > > @@ -267,8 +267,7 @@ void drm_minor_release(struct drm_minor *minor)
> > > > *
> > > > * The following example shows a typical structure of a DRM display
> > > > driver.
> > > > * The example focus on the probe() function and the other functions
> > > > that is
> > > > - * almost always present and serves as a demonstration of
> > > > devm_drm_dev_init()
> > > > - * usage with its accompanying drm_driver->release callback.
> > > > + * almost always present and serves as a demonstration of
> > > > devm_drm_dev_init().
> > > > *
> > > > * .. code-block:: c
> > > > *
> > > > @@ -278,16 +277,8 @@ void drm_minor_release(struct drm_minor *minor)
> > > > * struct clk *pclk;
> > > > * };
> > > > *
> > > > - * static void driver_drm_release(struct drm_device *drm)
> > > > - * {
> > > > - * struct driver_device *priv = container_of(...);
> > > > - *
> > > > - * drm_mode_config_cleanup(drm);
> > > > - * }
> > > > - *
> > > > * static struct drm_driver driver_drm_driver = {
> > > > * [...]
> > > > - * .release = driver_drm_release,
> > > > * };
> > > > *
> > > > * static int driver_probe(struct platform_device *pdev)
> > > > @@ -312,7 +303,9 @@ void drm_minor_release(struct drm_minor *minor)
> > > > * }
> > > > * drmm_add_final_kfree(drm, priv);
> > > > *
> > > > - * drm_mode_config_init(drm);
> > > > + * ret = drm_mode_config_init(drm);
> > > > + * if (ret)
> > > > + * return ret;
> > > > *
> > > > * priv->userspace_facing = drmm_kzalloc(..., GFP_KERNEL);
> > > > * if (!priv->userspace_facing)
> > > > @@ -710,8 +703,7 @@ static void devm_drm_dev_init_release(void *data)
> > > > * @driver: DRM driver
> > > > *
> > > > * Managed drm_dev_init(). The DRM device initialized with this
> > > > function is
> > > > - * automatically put on driver detach using drm_dev_put(). You must
> > > > supply a
> > > > - * _driver.release callback to control the finalization explicitly.
> > > > + * automatically put on driver detach using drm_dev_put().
> > > > *
> > > > * RETURNS:
> > > > * 0 on success, or error code on failure.
> > > > @@ -722,9 +714,6 @@ int devm_drm_dev_init(struct device *parent,
> > > > {
> > > > int ret;
> > > >
> > > > - if (WARN_ON(!driver->release))
> > > > - return -EINVAL;
> > > > -
> > > > ret = drm_dev_init(dev, driver, parent);
> > > > if (ret)
> > > > return ret;
> > > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > > b/drivers/gpu/drm/drm_mode_config.c
> > > > index 08e6eff6a179..957db1edba0c 100644
> > > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > > @@ -25,6 +25,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -373,6 +374,11 @@ static int
> > > > drm_mode_create_standard_properties(struct drm_device *dev)
> > > > return 0;
> > > > }
> > > >
> > > > +static void drm_mode_config_init_release(struct drm_device *dev, void
> > > > *ptr)
> > > > +{
> > > > + drm_mode_config_cleanup(dev);
> > > > +}
> > > > +
> > > > /**
> > > > * drm_mode_config_init - initialize DRM mode_configuration structure
> > > > * @dev: DRM device
> > > > @@ -384,8 +390,10 @@ static int
> > > >
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > > > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman > > wrote: > > > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > Hi Daniel, > > > > > > > > Thank you for the patch. > > > > > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > > > We have lots of these. And the cleanup code tends to be of dubious > > > > > quality. The biggest wrong pattern is that developers use devm_, which > > > > > ties the release action to the underlying struct device, whereas > > > > > all the userspace visible stuff attached to a drm_device can long > > > > > outlive that one (e.g. after a hotunplug while userspace has open > > > > > files and mmap'ed buffers). Give people what they want, but with more > > > > > correctness. > > > > > > > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > > > > a few simplifications - I didn't (yet) copy over everything. Since > > > > > the types don't match code sharing looked like a hopeless endeavour. > > > > > > > > > > For now it's only super simplified, no groups, you can't remove > > > > > actions (but kfree exists, we'll need that soon). Plus all specific to > > > > > drm_device ofc, including the logging. Which I didn't bother to make > > > > > compile-time optional, since none of the other drm logging is compile > > > > > time optional either. > > > > > > > > > > One tricky bit here is the chicken between allocating your > > > > > drm_device structure and initiliazing it with drm_dev_init. For > > > > > perfect onion unwinding we'd need to have the action to kfree the > > > > > allocation registered before drm_dev_init registers any of its own > > > > > release handlers. But drm_dev_init doesn't know where exactly the > > > > > drm_device is emebedded into the overall structure, and by the time it > > > > > returns it'll all be too late. And forcing drivers to be able clean up > > > > > everything except the one kzalloc is silly. > > > > > > > > > > Work around this by having a very special final_kfree pointer. This > > > > > also avoids troubles with the list head possibly disappearing from > > > > > underneath us when we release all resources attached to the > > > > > drm_device. > > > > > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > > > using devm_k*alloc to allocate data accessible by userspace. Since the > > > > introduction of devm_*, we've likely reduced the number of memory leaks, > > > > but I'm pretty sure we've increased the risk of crashes as I've seen > > > > some drivers that used .release() callbacks correctly being naively > > > > converted to incorrect devm_* usage :-( > > > > > > > > This leads me to a question: if other subsystems have the same problem, > > > > could we turn this implementation into something more generic ? It > > > > doesn't have to be done right away and shouldn't block merging this > > > > series, but I think it would be very useful. > > > > > > It shouldn't be that hard to tie this into a drv_m() type of a thing > > > (driver_memory?) > > > > > > And yes, I think it's much better than devm_* for the obvious reasons of > > > this being needed here. > > > > There's two reasons I went with copypasta instead of trying to share code: > > - Type checking, I definitely don't want people to mix up devm_ with > > drmm_. But even if we do a drv_m that subsystems could embed we do > > have quite a few different types of component drivers (and with > > drm_panel and drm_bridge even standardized), and I don't want people > > to be able to pass the wrong kind of struct to e.g. a managed > > drmm_connector_init - it really needs to be the drm_device, not a > > panel or bridge or something else. > > > > - We could still share the code as a kind of implementation/backend > > library. But it's not much, and with embedding I could use the drm > > device logging stuff which is kinda nice. But if there's more demand > > for this I can definitely see the point in sharing this, as Laurent > > pointed out with the tiny optimization with not allocating a NULL void > > * that I've done (and screwed up) it's not entirely trivial code. > > > > My 2c as they say, although closer to a brain dump :-) > > On one hand the drm_device has an embedded struct device. On the other > drm_device preserves state which outlives the embedded struct device. > > Would it make sense to keep drm_device better related to the > underlying device? Effectively moving the $misc state to drm_driver. > This idea does raise another question - struct drm_driver unlike many > other struct $foo_driver, does not embedded device_driver :-( > So if one is to cover the above two, then the embedding concerns will > be elevated. drm_driver isn't a bus device driver in the linux driver model sense, but an uapi thing that sits on top of some underlying device. So maybe better
[PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v2
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/drm_gem_vram_helper.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 92a11bb42365..3edf5f241c15 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -198,6 +198,21 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object
*gbo)
}
EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
+/**
+ * drm_gem_vram_pg_offset() - Returns a GEM VRAM object's page offset
+ * @gbo: the GEM VRAM object
+ *
+ * Returns:
+ * The buffer object's page offset, or
+ * 0 with a warning when memory manager node of the buffer object is NULL
+ * */
+static s64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
+{
+ if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
+ return 0;
+ return gbo->bo.mem.start;
+}
+
/**
* drm_gem_vram_offset() - \
Returns a GEM VRAM object's offset in video memory
@@ -214,7 +229,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
{
if (WARN_ON_ONCE(!gbo->pin_count))
return (s64)-ENODEV;
- return gbo->bo.offset;
+ return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
}
EXPORT_SYMBOL(drm_gem_vram_offset);
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/vmwgfx: don't use ttm bo->offset
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 8b71bf6b58ef..1e59c019affa 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -258,7 +258,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
ret = ttm_bo_validate(bo, , );
/* For some reason we didn't end up at the start of vram */
- WARN_ON(ret == 0 && bo->offset != 0);
+ WARN_ON(ret == 0 && bo->mem.start != 0);
if (!ret)
vmw_bo_pin_reserved(buf, true);
@@ -317,7 +317,7 @@ void vmw_bo_get_guest_ptr(const struct ttm_buffer_object
*bo,
{
if (bo->mem.mem_type == TTM_PL_VRAM) {
ptr->gmrId = SVGA_GMR_FRAMEBUFFER;
- ptr->offset = bo->offset;
+ ptr->offset = bo->mem.start << PAGE_SHIFT;
} else {
ptr->gmrId = bo->mem.start;
ptr->offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 73489a45decb..72c2cf4053df 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3313,7 +3313,7 @@ static void vmw_apply_relocations(struct vmw_sw_context
*sw_context)
bo = >vbo->base;
switch (bo->mem.mem_type) {
case TTM_PL_VRAM:
- reloc->location->offset += bo->offset;
+ reloc->location->offset += bo->mem.start << PAGE_SHIFT;
reloc->location->gmrId = SVGA_GMR_FRAMEBUFFER;
break;
case VMW_PL_GMR:
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index e5252ef3812f..1cdc445b24c3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -612,7 +612,7 @@ static int vmw_fifo_emit_dummy_legacy_query(struct
vmw_private *dev_priv,
if (bo->mem.mem_type == TTM_PL_VRAM) {
cmd->body.guestResult.gmrId = SVGA_GMR_FRAMEBUFFER;
- cmd->body.guestResult.offset = bo->offset;
+ cmd->body.guestResult.offset = bo->mem.start << PAGE_SHIFT;
} else {
cmd->body.guestResult.gmrId = bo->mem.start;
cmd->body.guestResult.offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 3f3b2c7a208a..e7134aebeb81 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -750,7 +750,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _bo_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
@@ -763,7 +762,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
* slots as well as the bo size.
*/
man->func = _gmrid_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_CMA | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/qxl: don't use ttm bo->offset
This patch removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar
This patch also removes unused qxl_bo_gpu_offset()
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 6 ++
drivers/gpu/drm/qxl/qxl_kms.c| 5 ++---
drivers/gpu/drm/qxl/qxl_object.h | 5 -
drivers/gpu/drm/qxl/qxl_ttm.c| 9 -
4 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 27e45a2d6b52..df581f0e6699 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -134,7 +134,6 @@ struct qxl_memslot {
uint64_tstart_phys_addr;
uint64_tsize;
uint64_thigh_bits;
- uint64_tgpu_offset;
};
enum {
@@ -311,10 +310,9 @@ qxl_bo_physical_address(struct qxl_device *qdev, struct
qxl_bo *bo,
(bo->tbo.mem.mem_type == TTM_PL_VRAM)
? >main_slot : >surfaces_slot;
- WARN_ON_ONCE((bo->tbo.offset & slot->gpu_offset) != slot->gpu_offset);
+ /* TODO - need to hold one of the locks to read bo->tbo.mem.start */
- /* TODO - need to hold one of the locks to read tbo.offset */
- return slot->high_bits | (bo->tbo.offset - slot->gpu_offset + offset);
+ return slot->high_bits | ((bo->tbo.mem.start << PAGE_SHIFT) + offset);
}
/* qxl_display.c */
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 70b20ee4741a..7a5bf544f34d 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -86,11 +86,10 @@ static void setup_slot(struct qxl_device *qdev,
high_bits <<= (64 - (qdev->rom->slot_gen_bits +
qdev->rom->slot_id_bits));
slot->high_bits = high_bits;
- DRM_INFO("slot %d (%s): base 0x%08lx, size 0x%08lx, gpu_offset 0x%lx\n",
+ DRM_INFO("slot %d (%s): base 0x%08lx, size 0x%08lx\n",
slot->index, slot->name,
(unsigned long)slot->start_phys_addr,
-(unsigned long)slot->size,
-(unsigned long)slot->gpu_offset);
+(unsigned long)slot->size);
}
void qxl_reinit_memslots(struct qxl_device *qdev)
diff --git a/drivers/gpu/drm/qxl/qxl_object.h b/drivers/gpu/drm/qxl/qxl_object.h
index 8ae54ba7857c..21fa81048f4f 100644
--- a/drivers/gpu/drm/qxl/qxl_object.h
+++ b/drivers/gpu/drm/qxl/qxl_object.h
@@ -48,11 +48,6 @@ static inline void qxl_bo_unreserve(struct qxl_bo *bo)
ttm_bo_unreserve(>tbo);
}
-static inline u64 qxl_bo_gpu_offset(struct qxl_bo *bo)
-{
- return bo->tbo.offset;
-}
-
static inline unsigned long qxl_bo_size(struct qxl_bo *bo)
{
return bo->tbo.num_pages << PAGE_SHIFT;
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 62a5e424971b..635d000e7934 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -51,11 +51,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- struct qxl_device *qdev = qxl_get_qdev(bdev);
- unsigned int gpu_offset_shift =
- 64 - (qdev->rom->slot_gen_bits + qdev->rom->slot_id_bits + 8);
- struct qxl_memslot *slot;
-
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
@@ -66,11 +61,7 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
case TTM_PL_PRIV:
/* "On-card" video ram */
- slot = (type == TTM_PL_VRAM) ?
- >main_slot : >surfaces_slot;
- slot->gpu_offset = (uint64_t)type << gpu_offset_shift;
man->func = _bo_manager_func;
- man->gpu_offset = slot->gpu_offset;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_MASK_CACHING;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] drm/radeon: don't use ttm bo->offset
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset
Signed-off-by: Nirmoy Das
Reviewed-and-tested-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 +---
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 30e32adc1fc6..b7c3fb2bfb54 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2828,6 +2828,7 @@ extern void radeon_ttm_set_active_vram_size(struct
radeon_device *rdev, u64 size
extern void radeon_program_register_sequence(struct radeon_device *rdev,
const u32 *registers,
const u32 array_size);
+struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev);
/*
* vm
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index d23f2ed4126e..4d37571c7ff5 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -90,7 +90,21 @@ static inline void radeon_bo_unreserve(struct radeon_bo *bo)
*/
static inline u64 radeon_bo_gpu_offset(struct radeon_bo *bo)
{
- return bo->tbo.offset;
+ struct radeon_device *rdev;
+ u64 start = 0;
+
+ rdev = radeon_get_rdev(bo->tbo.bdev);
+
+ switch(bo->tbo.mem.mem_type) {
+ case TTM_PL_TT:
+ start = rdev->mc.gtt_start;
+ break;
+ case TTM_PL_VRAM:
+ start = rdev->mc.vram_start;
+ break;
+ }
+
+ return (bo->tbo.mem.start << PAGE_SHIFT) + start;
}
static inline unsigned long radeon_bo_size(struct radeon_bo *bo)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index badf1b6d1549..1c8303468e8f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -56,7 +56,7 @@
static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
static void radeon_ttm_debugfs_fini(struct radeon_device *rdev);
-static struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
+struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
{
struct radeon_mman *mman;
struct radeon_device *rdev;
@@ -82,7 +82,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
break;
case TTM_PL_TT:
man->func = _bo_manager_func;
- man->gpu_offset = rdev->mc.gtt_start;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
@@ -104,7 +103,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _bo_manager_func;
- man->gpu_offset = rdev->mc.vram_start;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/nouveau: don't use ttm bo->offset v3
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 8
drivers/gpu/drm/nouveau/nouveau_bo.c| 8
drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-
15 files changed, 35 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 1f08de4241e0..d06a93f2b38a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
fb = nouveau_framebuffer(crtc->primary->fb);
}
- nv_crtc->fb.offset = fb->nvbo->bo.offset;
+ nv_crtc->fb.offset = fb->nvbo->offset;
if (nv_crtc->lut.depth != drm_fb->format->depth) {
nv_crtc->lut.depth = drm_fb->format->depth;
@@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
nouveau_bo_unmap(cursor);
- nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
+ nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
nv_crtc->cursor.show(nv_crtc, true);
out:
@@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
/* Initialize a page flip struct */
*s = (struct nv04_page_flip_state)
{ { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
- new_bo->bo.offset };
+ new_bo->offset };
/* Keep vblanks on during flip, for the target crtc of this flip */
drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 44ee82d0c9b6..89a4ddfcc55f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume, bool
runtime)
continue;
if (nv_crtc->cursor.set_offset)
- nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->bo.offset);
+ nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->offset);
nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
nv_crtc->cursor_saved_y);
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index a3a0a73ae8ab..9529bd9053e7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
- nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
+ nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
@@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (format & NV_PVIDEO_FORMAT_PLANAR) {
nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
- nv_fb->nvbo->bo.offset + fb->offsets[1]);
+ nv_fb->nvbo->offset + fb->offsets[1]);
}
nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_STOP, 0);
@@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
for (i = 0; i < 2; i++) {
nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADDRESS + 4 * i,
- nv_fb->nvbo->bo.offset);
+ nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_BUFF0_PITCH_LENGTH + 4 * i,
fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_BUFF0_OFFSET + 4 * i,
[PATCH 7/8] drm/bochs: use drm_gem_vram_offset to get bo offset v2
Switch over to GEM VRAM's implementation to retrieve bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/bochs/bochs_kms.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 8066d7d370d5..18d2ec34534d 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -29,16 +29,21 @@ static void bochs_plane_update(struct bochs_device *bochs,
struct drm_plane_state *state)
{
struct drm_gem_vram_object *gbo;
+ s64 gpu_addr;
if (!state->fb || !bochs->stride)
return;
gbo = drm_gem_vram_of_gem(state->fb->obj[0]);
+ gpu_addr = drm_gem_vram_offset(gbo);
+ if (WARN_ON_ONCE(gpu_addr < 0))
+ return; /* Bug: we didn't pin the BO to VRAM in prepare_fb. */
+
bochs_hw_setbase(bochs,
state->crtc_x,
state->crtc_y,
state->fb->pitches[0],
-state->fb->offsets[0] + gbo->bo.offset);
+state->fb->offsets[0] + gpu_addr);
bochs_hw_setformat(bochs, state->fb->format);
}
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mediatek: component type MTK_DISP_OVL_2L is not correctly handled
The larb device remains NULL if the type is MTK_DISP_OVL_2L. A kernel panic is raised when a crtc uses mtk_smi_larb_get or mtk_smi_larb_put. Signed-off-by: Phong LE --- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c index 1f5a112bb034..57c88de9a329 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c @@ -471,6 +471,7 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node, /* Only DMA capable components need the LARB property */ comp->larb_dev = NULL; if (type != MTK_DISP_OVL && + type != MTK_DISP_OVL_2L && type != MTK_DISP_RDMA && type != MTK_DISP_WDMA) return 0; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] ARM: sun7i: dts: Add LVDS panel support on A20
On Tue, Feb 18, 2020 at 07:50:33PM +0200, Andrey Lebedev wrote:
> On Mon, Feb 17, 2020 at 06:51:35PM +0100, Maxime Ripard wrote:
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> > > b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> > > index cfbf4e6c1679..bc87d28ee341 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> > > @@ -235,6 +235,8 @@ struct sun4i_tcon_quirks {
> > > boolneeds_de_be_mux; /* sun6i needs mux to select backend */
> > > boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
> > > boolsupports_lvds; /* Does the TCON support an LVDS output? */
> > > + /* "compatible" string of TCON that exclusively supports LVDS */
> > > + const char *lvds_compatible_tcon;
> >
> > However this is far more complicated than needed, you can simply add a
> > new quirks structure associated to the tcon0 compatible in
> > sun4i_tcon_of_table, and that will do
>
> Aha! Does this look good to you?
>
> From 4ad2978e404c63d4cca1b7890bc5bdd4d1e8965d Mon Sep 17 00:00:00 2001
> From: Andrey Lebedev
> Date: Tue, 18 Feb 2020 19:47:33 +0200
> Subject: [PATCH] Mark tcon0 to be the only tcon capable of LVDS on sun7i-a20
>
> This allows to avoid warnings about reset line not provided for tcon1.
>
> Signed-off-by: Andrey Lebedev
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 6 --
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 14 --
> 2 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index dc4f3f249aee..d50263c1ca9a 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -405,7 +405,8 @@
> };
>
> tcon0: lcd-controller@1c0c000 {
> - compatible = "allwinner,sun7i-a20-tcon";
> + compatible = "allwinner,sun7i-a20-tcon0",
> + "allwinner,sun7i-a20-tcon";
> reg = <0x01c0c000 0x1000>;
> interrupts = ;
> resets = < RST_TCON0>, < RST_LVDS>;
> @@ -460,7 +461,8 @@
> };
>
> tcon1: lcd-controller@1c0d000 {
> - compatible = "allwinner,sun7i-a20-tcon";
> + compatible = "allwinner,sun7i-a20-tcon1",
> + "allwinner,sun7i-a20-tcon";
> reg = <0x01c0d000 0x1000>;
> interrupts = ;
> resets = < RST_TCON1>;
This needs to be in a separate patch
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 800a9bd86112..d9605d331010 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1479,7 +1479,7 @@ static const struct sun4i_tcon_quirks sun6i_a31s_quirks
> = {
> .dclk_min_div = 1,
> };
>
> -static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
> +static const struct sun4i_tcon_quirks sun7i_a20_tcon0_quirks = {
> .supports_lvds = true,
> .has_channel_0 = true,
> .has_channel_1 = true,
> @@ -1489,6 +1489,15 @@ static const struct sun4i_tcon_quirks sun7i_a20_quirks
> = {
> .setup_lvds_phy = sun4i_tcon_setup_lvds_phy,
> };
>
> +static const struct sun4i_tcon_quirks sun7i_a20_tcon1_quirks = {
> + .supports_lvds = false,
> + .has_channel_0 = true,
> + .has_channel_1 = true,
> + .dclk_min_div = 4,
> + /* Same display pipeline structure as A10 */
> + .set_mux= sun4i_a10_tcon_set_mux,
> +};
> +
> static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
> .has_channel_0 = true,
> .has_lvds_alt = true,
> @@ -1534,7 +1543,8 @@ const struct of_device_id sun4i_tcon_of_table[] = {
> { .compatible = "allwinner,sun5i-a13-tcon", .data = _a13_quirks },
> { .compatible = "allwinner,sun6i-a31-tcon", .data = _a31_quirks },
> { .compatible = "allwinner,sun6i-a31s-tcon", .data = _a31s_quirks
> },
> - { .compatible = "allwinner,sun7i-a20-tcon", .data = _a20_quirks },
> + { .compatible = "allwinner,sun7i-a20-tcon0", .data =
> _a20_tcon0_quirks },
> + { .compatible = "allwinner,sun7i-a20-tcon1", .data =
> _a20_tcon1_quirks },
> { .compatible = "allwinner,sun8i-a23-tcon", .data = _a33_quirks },
> { .compatible = "allwinner,sun8i-a33-tcon", .data = _a33_quirks },
> { .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data =
> _a83t_lcd_quirks },
And we need to support older DT as well, so you shouldn't remove the
older TCON compatible and its structure. Make sure to document the new
compatibles too.
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] drm/amdgpu: move ttm bo->offset to amdgpu_bo
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 29 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 1 +
4 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e3f16b49e970..04e78f783638 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -917,7 +917,7 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
bo->pin_count++;
if (max_offset != 0) {
- u64 domain_start =
bo->tbo.bdev->man[mem_type].gpu_offset;
+ u64 domain_start = amdgpu_ttm_domain_start(adev,
mem_type);
WARN_ON_ONCE(max_offset <
(amdgpu_bo_gpu_offset(bo) - domain_start));
}
@@ -1445,7 +1445,25 @@ u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo)
WARN_ON_ONCE(bo->tbo.mem.mem_type == TTM_PL_VRAM &&
!(bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS));
- return amdgpu_gmc_sign_extend(bo->tbo.offset);
+ return amdgpu_bo_gpu_offset_no_check(bo);
+}
+
+/**
+ * amdgpu_bo_gpu_offset_no_check - return GPU offset of bo
+ * @bo:amdgpu object for which we query the offset
+ *
+ * Returns:
+ * current GPU offset of the object without raising warnings.
+ */
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo)
+{
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ uint64_t offset;
+
+offset = (bo->tbo.mem.start << PAGE_SHIFT) +
+amdgpu_ttm_domain_start(adev, bo->tbo.mem.mem_type);
+
+ return amdgpu_gmc_sign_extend(offset);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 36dec51d1ef1..1d86b4c7a1f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -279,6 +279,7 @@ void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence
*fence,
bool shared);
int amdgpu_bo_sync_wait(struct amdgpu_bo *bo, void *owner, bool intr);
u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo);
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo);
int amdgpu_bo_validate(struct amdgpu_bo *bo);
int amdgpu_bo_restore_shadow(struct amdgpu_bo *shadow,
struct dma_fence **fence);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 3ab46d4647e4..e329a108e760 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -97,7 +97,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_TT:
/* GTT memory */
man->func = _gtt_mgr_func;
- man->gpu_offset = adev->gmc.gart_start;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
@@ -105,7 +104,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _vram_mgr_func;
- man->gpu_offset = adev->gmc.vram_start;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
@@ -116,7 +114,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = _bo_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
@@ -264,7 +261,7 @@ static uint64_t amdgpu_mm_node_addr(struct
ttm_buffer_object *bo,
if (mm_node->start != AMDGPU_BO_INVALID_OFFSET) {
addr = mm_node->start << PAGE_SHIFT;
- addr += bo->bdev->man[mem->mem_type].gpu_offset;
+ addr += amdgpu_ttm_domain_start(amdgpu_ttm_adev(bo->bdev),
mem->mem_type);
}
return addr;
}
@@ -751,6 +748,27 @@ static unsigned long amdgpu_ttm_io_mem_pfn(struct
ttm_buffer_object *bo,
(offset >> PAGE_SHIFT);
}
+/**
+ * amdgpu_ttm_domain_start - Returns GPU start address
+ * @adev: amdgpu device object
+
