dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

Re: [PATCH 08/15] mm: remove the mask variable in hmm_vma_walk_hugetlb_entry
by Jason Gunthorpe 06 Aug '19

06 Aug '19

On Tue, Aug 06, 2019 at 07:05:46PM +0300, Christoph Hellwig wrote: > The pagewalk code already passes the value as the hmask parameter. > > Signed-off-by: Christoph Hellwig <hch(a)lst.de> > mm/hmm.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) Reviewed-by: Jason Gunthorpe <jgg(a)mellanox.com> Jason

1 0

Re: [PATCH 11/15] mm: cleanup the hmm_vma_handle_pmd stub
by Jason Gunthorpe 06 Aug '19

06 Aug '19

On Tue, Aug 06, 2019 at 07:05:49PM +0300, Christoph Hellwig wrote: > Stub out the whole function when CONFIG_TRANSPARENT_HUGEPAGE is not set > to make the function easier to read. > > Signed-off-by: Christoph Hellwig <hch(a)lst.de> > --- > mm/hmm.c | 18 ++++++++---------- > 1 file changed, 8 insertions(+), 10 deletions(-) Reviewed-by: Jason Gunthorpe <jgg(a)mellanox.com> Jason

1 0

Re: [PATCH 14/15] mm: make HMM_MIRROR an implicit option
by Jason Gunthorpe 06 Aug '19

06 Aug '19

On Tue, Aug 06, 2019 at 07:05:52PM +0300, Christoph Hellwig wrote: > Make HMM_MIRROR an option that is selected by drivers wanting to use it > instead of a user visible option as it is just a low-level > implementation detail. > > Signed-off-by: Christoph Hellwig <hch(a)lst.de> > --- > drivers/gpu/drm/amd/amdgpu/Kconfig | 4 +++- > drivers/gpu/drm/nouveau/Kconfig | 4 +++- > mm/Kconfig | 14 ++++++-------- > 3 files changed, 12 insertions(+), 10 deletions(-) Reviewed-by: Jason Gunthorpe <jgg(a)mellanox.com> Jason

1 0

Re: [PATCH 1/2] drm: add cache support for arm64
by Rob Clark 06 Aug '19

06 Aug '19

On Tue, Aug 6, 2019 at 8:50 AM Christoph Hellwig <hch(a)lst.de> wrote: > > On Tue, Aug 06, 2019 at 07:11:41AM -0700, Rob Clark wrote: > > Agreed that drm_cflush_* isn't a great API. In this particular case > > (IIUC), I need wb+inv so that there aren't dirty cache lines that drop > > out to memory later, and so that I don't get a cache hit on > > uncached/wc mmap'ing. > > So what is the use case here? Allocate pages using the page allocator > (or CMA for that matter), and then mmaping them to userspace and never > touching them again from the kernel? Currently, it is pages coming from tmpfs. Ideally we want pages that are swappable when unpinned. CPU mappings are *mostly* just mapping to userspace. There are a few exceptions that are vmap'd (fbcon, and ringbuffer). (Eventually I'd like to support pages passed in from userspace.. but that is down the road.) > > Tying it in w/ iommu seems a bit weird to me.. but maybe that is just > > me, I'm certainly willing to consider proposals or to try things and > > see how they work out. > > This was just my through as the fit seems easy. But maybe you'll > need to explain your use case(s) a bit more so that we can figure out > what a good high level API is. Tying it to iommu_map/unmap would be awkward, as we could need to setup cpu mmap before it ends up mapped to iommu. And the plan to support per-process pagetables involved creating an iommu_domain per userspace gl context.. some buffers would end up mapped into multiple contexts/iommu_domains. If the cache operation was detached from iommu_map/unmap, then it would seem weird to be part of the iommu API. I guess I'm not entirely sure what you had in mind, but this is why iommu seemed to me like a bad fit. > > Exposing the arch_sync_* API and using that directly (bypassing > > drm_cflush_*) actually seems pretty reasonable and pragmatic. I did > > have one doubt, as phys_to_virt() is only valid for kernel direct > > mapped memory (AFAIU), what happens for pages that are not in kernel > > linear map? Maybe it is ok to ignore those pages, since they won't > > have an aliased mapping? > > They could have an aliased mapping in vmalloc/vmap space for example, > if you created one. We have the flush_kernel_vmap_range / > invalidate_kernel_vmap_range APIs for those, that are implement > on architectures with VIVT caches. If I only have to worry about aliased mappings that I create myself, that doesn't seem too bad.. I could track that myself easily enough. BR, -R

1 1

[PATCH v2 0/3] drm/meson: convert bindings to YAML schemas
by Neil Armstrong 06 Aug '19

06 Aug '19

This patchset converts the existing text bindings to YAML schemas. Those bindings have a lot of texts, thus is interesting to convert. All have been tested using : $ make ARCH=arm64 dtbs_check Issues with the amlogic arm64 DTs has already been identified thanks to the validation scripts. The DT fixes will be pushed once these yaml bindings are acked. Neil Armstrong (3): dt-bindings: display: amlogic,meson-dw-hdmi: convert to yaml dt-bindings: display: amlogic,meson-vpu: convert to yaml MAINTAINERS: Update with Amlogic DRM bindings converted as YAML .../display/amlogic,meson-dw-hdmi.txt | 119 -------------- .../display/amlogic,meson-dw-hdmi.yaml | 150 ++++++++++++++++++ .../bindings/display/amlogic,meson-vpu.txt | 121 -------------- .../bindings/display/amlogic,meson-vpu.yaml | 138 ++++++++++++++++ MAINTAINERS | 4 +- 5 files changed, 290 insertions(+), 242 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml delete mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml -- 2.22.0

2 5

[Bug 111307] critical fhghg
by bugzilla-daemon＠freedesktop.org 06 Aug '19

06 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=111307 Bug ID: 111307 Summary: critical fhghg Product: Mesa Version: 19.0 Hardware: Alpha OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Drivers/DRI/R100 Assignee: dri-devel(a)lists.freedesktop.org Reporter: sowjanyagowda1809(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org hgfhgfhgdgff -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH 2/4 v3] drm/panel: simple: Add TI nspire panel bindings
by Linus Walleij 06 Aug '19

06 Aug '19

Add bindings for the TI NSPIRE simple display panels. Cc: devicetree(a)vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- ChanegLog v2->v3: - Switch to GPL-2.0-only OR BSD-2-Clause license - Use a simple enum for the compatible - Use the new nifty panel-common.yaml, tested on linux-next ChangeLog v1->v2: - New patch as bindings are required - Let's use YAML --- .../bindings/display/panel/ti,nspire.yaml | 36 +++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/ti,nspire.yaml diff --git a/Documentation/devicetree/bindings/display/panel/ti,nspire.yaml b/Documentation/devicetree/bindings/display/panel/ti,nspire.yaml new file mode 100644 index 000000000000..5c5a3b519e31 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ti,nspire.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/ti,nspire.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments NSPIRE Display Panels + +maintainers: + - Linus Walleij <linus.walleij(a)linaro.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + enum: + - ti,nspire-cx-lcd-panel + - ti,nspire-classic-lcd-panel + port: true + +required: + - compatible + +additionalProperties: false + +examples: + - | + panel { + compatible = "ti,nspire-cx-lcd-panel"; + port { + panel_in: endpoint { + remote-endpoint = <&pads>; + }; + }; + }; -- 2.21.0

2 1

[PATCH] drm/amd/powerplay: Zero initialize some variables
by Nathan Chancellor 06 Aug '19

06 Aug '19

Clang warns (only Navi warning shown but Arcturus warns as well): drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1534:4: warning: variable 'asic_default_power_limit' is used uninitialized whenever '?:' condition is false [-Wsometimes-uninitialized] smu_read_smc_arg(smu, &asic_default_power_limit); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:588:3: note: expanded from macro 'smu_read_smc_arg' ((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg)) : 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1550:30: note: uninitialized use occurs here smu->default_power_limit = asic_default_power_limit; ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1534:4: note: remove the '?:' if its condition is always true smu_read_smc_arg(smu, &asic_default_power_limit); ^ drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:588:3: note: expanded from macro 'smu_read_smc_arg' ((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg)) : 0) ^ drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1517:35: note: initialize the variable 'asic_default_power_limit' to silence this warning uint32_t asic_default_power_limit; ^ = 0 1 warning generated. As the code is currently written, if read_smc_arg were ever NULL, arg would fail to be initialized but the code would continue executing as normal because the return value would just be zero. There are a few different possible solutions to resolve this class of warnings which have appeared in these drivers before: 1. Assume the function pointer will never be NULL and eliminate the wrapper macros. 2. Have the wrapper macros initialize arg when the function pointer is NULL. 3. Have the wrapper macros return an error code instead of 0 when the function pointer is NULL so that the callsites can properly bail out before arg can be used. 4. Initialize arg at the top of its function. Number four is the path of least resistance right now as every other change will be driver wide so do that here. I only make the comment now as food for thought. Fixes: b4af964e75c4 ("drm/amd/powerplay: make power limit retrieval as asic specific") Link: https://github.com/ClangBuiltLinux/linux/issues/627 Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> --- drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 2 +- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c index 215f7173fca8..b92eded7374f 100644 --- a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c +++ b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c @@ -1326,7 +1326,7 @@ static int arcturus_get_power_limit(struct smu_context *smu, bool asic_default) { PPTable_t *pptable = smu->smu_table.driver_pptable; - uint32_t asic_default_power_limit; + uint32_t asic_default_power_limit = 0; int ret = 0; int power_src; diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c index 106352a4fb82..d844bc8411aa 100644 --- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c +++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c @@ -1514,7 +1514,7 @@ static int navi10_get_power_limit(struct smu_context *smu, bool asic_default) { PPTable_t *pptable = smu->smu_table.driver_pptable; - uint32_t asic_default_power_limit; + uint32_t asic_default_power_limit = 0; int ret = 0; int power_src; -- 2.23.0.rc1

3 2

[PATCH v2] MAINTAINERS: update amdkfd maintainer
by Oded Gabbay 06 Aug '19

06 Aug '19

I'm leaving the role of amdkfd maintainer. Therefore, update the relevant entry in the MAINTAINERS file with the name of the new maintainer. Good Luck! Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 01a52fc964da..9a6c15fa5fd5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -821,9 +821,9 @@ F: drivers/iommu/amd_iommu*.[ch] F: include/linux/amd-iommu.h AMD KFD -M: Oded Gabbay <oded.gabbay(a)gmail.com> +M: Felix Kuehling <Felix.Kuehling(a)amd.com> L: dri-devel(a)lists.freedesktop.org -T: git git://people.freedesktop.org/~gabbayo/linux.git +T: git git://people.freedesktop.org/~agd5f/linux S: Supported F: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c F: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h -- 2.17.1

3 2

[PATCH] gpu: drm: amd: powerplay: Remove logically dead code
by Hariprasad Kelam 06 Aug '19

06 Aug '19

Result of pointer airthmentic is never null fix coverity defect:1451876 Signed-off-by: Hariprasad Kelam <hariprasad.kelam(a)gmail.com> --- drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c index ee739c0..a3acd77 100644 --- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c +++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c @@ -736,8 +736,6 @@ static int smu_v11_0_write_watermarks_table(struct smu_context *smu) struct smu_table *table = NULL; table = &smu_table->tables[SMU_TABLE_WATERMARKS]; - if (!table) - return -EINVAL; if (!table->cpu_addr) return -EINVAL; -- 2.7.4

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019