Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions
On October 13, 2018 19:50:00 "Keith Packard" wrote: Jason Ekstrand writes: Actually, I think anv is doing the right thing too. Now I have no idea why Keith was having problems. anv is happily returning a valid pointer and radv is not? In any case, I've switched to using vkGetInstanceProcAddr for the VkPhysicalDevice function and it works fine with both drivers. Using vkGetInstanceProcAddr is the right thing to do. The fact that anv allows you to is a bug which should be investigated and fixed. I looked at it a bit today and I'm still not sure how it's happening. --Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions
Jason Ekstrand writes: > Actually, I think anv is doing the right thing too. Now I have no idea why > Keith was having problems. anv is happily returning a valid pointer and radv is not? In any case, I've switched to using vkGetInstanceProcAddr for the VkPhysicalDevice function and it works fine with both drivers. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108355] Civilization VI - Artifacts in mouse cursor
https://bugs.freedesktop.org/show_bug.cgi?id=108355 Bug ID: 108355 Summary: Civilization VI - Artifacts in mouse cursor Product: Mesa Version: 18.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: freedesk...@psydk.org QA Contact: dri-devel@lists.freedesktop.org Created attachment 142017 --> https://bugs.freedesktop.org/attachment.cgi?id=142017=edit expected and actual cursor texture I'm on Ubuntu 18.04.1 with a RX 480 and Mesa 18.2.2 The mouse cursor texture is not correctly displayed. There are several artifacts, like a left vertical missing line, bright magenta, green and cyan pixels (see the attached image). uname -a: Linux c18 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux glxinfo -B: name of display: :0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.23.0, 4.15.0-36-generic, LLVM 7.0.0) (0x67df) Version: 18.2.2 Accelerated: yes Video memory: 8192MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 4.4 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 Memory info (GL_ATI_meminfo): VBO free memory - total: 7781 MB, largest block: 7781 MB VBO free aux. memory - total: 8176 MB, largest block: 8176 MB Texture free memory - total: 7781 MB, largest block: 7781 MB Texture free aux. memory - total: 8176 MB, largest block: 8176 MB Renderbuffer free memory - total: 7781 MB, largest block: 7781 MB Renderbuffer free aux. memory - total: 8176 MB, largest block: 8176 MB Memory info (GL_NVX_gpu_memory_info): Dedicated video memory: 8192 MB Total available memory: 16384 MB Currently available dedicated video memory: 7781 MB OpenGL vendor string: X.Org OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.23.0, 4.15.0-36-generic, LLVM 7.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.2 - padoka PPA OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.4 (Compatibility Profile) Mesa 18.2.2 - padoka PPA OpenGL shading language version string: 4.40 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.2.2 - padoka PPA OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108194] Civilization VI - Animated leader characters small black squares artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=108194 --- Comment #1 from Hadrien Nilsson --- This is actually another issue than bug 108111: I upgraded from Mesa 18.2.1 to 18.2.2. bug 108111 is fixed, but the characters are still displayed with these small black squares. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108111] Civilization VI Artifacts RX480
https://bugs.freedesktop.org/show_bug.cgi?id=108111 --- Comment #6 from Hadrien Nilsson --- It happens Mesa 18.2.2 from padoka are available :) I did the upgrade, and the bug is gone. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108111] Civilization VI Artifacts RX480
https://bugs.freedesktop.org/show_bug.cgi?id=108111 --- Comment #5 from Hadrien Nilsson --- (In reply to Gregor Münch from comment #4) > Fixed by > https://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=0e6cdfd561c63d23e8ff32df4cab2370dc2a53d2 ? Maybe. I saw this commit is included in Mesa 18.2.2 (I still have 18.2.1 from padoka ppa). Hopefully we'll get an update soon. Meanwhile I tried to build my own Mesa version (usin meson) but I'm stuck with big "so" files like "libmesa_dri_drivers.so" "libgallium_dri.so"; I expected to get something like "radeonsi_dri.so" ready to be copied on my system and I can't find a lot of documentation on the topic. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible lock inversion in ttm_bo_vm_access
Hi, Christian, On 10/13/2018 07:36 PM, Christian König wrote: Hi Thomas, bo_reserve() copy_to_user() / copy_from_user() bo_unreserve() That pattern is illegal for a number of reasons and the mmap_sem is only one of it. So the locking order must always be mmap_sem->bo_reservation. See the userptr implementation in amdgpu as well. Christian. I'm not arguing against that, and since vmwgfx doesn't use that pattern, the locking order doesn't really matter to me since it's even possible to make the TTM fault() handler more well-behaved if we were to fix the locking order to mmap_sem->bo_reserve. My concern is, since the _opposite_ locking order is (admittedly vaguely) documented in the fault handler, that the access() handler took a shortcut when the new locking order was established possibly without auditing of the other TTM drivers for locking inversion: For example it looks from a quick glance like nouveau_gem_pushbuf_reloc_apply() calls copy_from_user() with bo's reserved (which IIRC was the typical use-case at the time this was last lifted). And lockdep won't trip unless the access() callback is actually called. My point is if AMD wants to enforce this locking order, then IMHO the other drivers need to be audited and corrected if they are assuming the locking order documented in fault(). A good way to catch such drivers would be to add that might_lock(). Thanks, Thomas Am 12.10.2018 um 16:52 schrieb Thomas Hellstrom: Hi, Felix, It looks like there is a locking inversion in ttm_bo_vm_access() where we take a sleeping bo_reserve() while holding mmap_sem(). Previously we've been assuming the other way around or at least undefined allowing for drivers to do bo_reserve() copy_to_user() / copy_from_user() bo_unreserve() I'm not sure the latter pattern is used in any drivers, though, and I guess there are ways around it. So it might make sense to fix the locking order at this point. In that case, perhaps one should add a might_lock(>resv->lock.base); at the start of the TTM fault handler to trip lockdep on locking order violations in situations where the access() callback isn't commonly used... /Thomas ___ 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: [alsa-devel] [PATCH 4/8] sound: hpios: don't pass GFP_DMA32 to dma_alloc_coherent
On Sat, 13 Oct 2018 18:35:40 +0200, Christoph Hellwig wrote: > > On Sat, Oct 13, 2018 at 06:18:28PM +0200, Takashi Iwai wrote: > > On Sat, 13 Oct 2018 17:17:03 +0200, > > Christoph Hellwig wrote: > > > > > > The DMA API does its own zone decisions based on the coherent_dma_mask. > > > > > > Signed-off-by: Christoph Hellwig > > > > Reviewed-by: Takashi Iwai > > > > > > Would you like to take this as a series, or shall I take individually > > through sound tree? > > There is nothing that depends on this, so feel free to apply the > two sound patches to your tree. OK, thanks. Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/4] drm: Add vrr_enabled property to drm CRTC
Am 12.10.2018 um 18:44 schrieb Nicholas Kazlauskas:
This patch introduces the 'vrr_enabled' CRTC property to allow
dynamic control over variable refresh rate support for a CRTC.
This property should be treated like a content hint to the driver -
if the hardware or driver is not capable of driving variable refresh
timings then this is not considered an error.
Capability for variable refresh rate support should be determined
by querying the vrr_capable drm connector property.
It is worth noting that while the property is intended for atomic use
it isn't filtered from legacy userspace queries. This allows for Xorg
userspace drivers to implement support.
I'm honestly still not convinced that a per CRTC property is actually
the right approach.
What we should rather do instead is to implement a target timestamp for
the page flip.
Regards,
Christian.
Signed-off-by: Nicholas Kazlauskas
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_crtc.c| 2 ++
drivers/gpu/drm/drm_mode_config.c | 6 ++
include/drm/drm_crtc.h| 9 +
include/drm/drm_mode_config.h | 5 +
5 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..eec396a57b88 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -433,6 +433,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
drm_property_blob_put(mode);
return ret;
+ } else if (property == config->prop_vrr_enabled) {
+ state->vrr_enabled = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -491,6 +493,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = state->active;
else if (property == config->prop_mode_id)
*val = (state->mode_blob) ? state->mode_blob->base.id : 0;
+ else if (property == config->prop_vrr_enabled)
+ *val = state->vrr_enabled;
else if (property == config->degamma_lut_property)
*val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
else if (property == config->ctm_property)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5f488aa80bcd..e4eb2c897ff4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -340,6 +340,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
drm_object_attach_property(>base, config->prop_mode_id,
0);
drm_object_attach_property(>base,
config->prop_out_fence_ptr, 0);
+ drm_object_attach_property(>base,
+ config->prop_vrr_enabled, 0);
}
return 0;
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index ee80788f2c40..5670c67f28d4 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -310,6 +310,12 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;
+ prop = drm_property_create_bool(dev, 0,
+ "VRR_ENABLED");
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.prop_vrr_enabled = prop;
+
prop = drm_property_create(dev,
DRM_MODE_PROP_BLOB,
"DEGAMMA_LUT", 0);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b21437bc95bf..39c3900aab3c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -290,6 +290,15 @@ struct drm_crtc_state {
*/
u32 pageflip_flags;
+ /**
+* @vrr_enabled:
+*
+* Indicates if variable refresh rate should be enabled for the CRTC.
+* Support for the requested vrr state will depend on driver and
+* hardware capabiltiy - lacking support is not treated as failure.
+*/
+ bool vrr_enabled;
+
/**
* @event:
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 928e4172a0bb..49f2fcfdb5fc 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -639,6 +639,11 @@ struct drm_mode_config {
* connectors must be of and active must be set to disabled, too.
*/
struct drm_property *prop_mode_id;
+ /**
+* @prop_vrr_enabled: Default atomic CRTC property to indicate
+* whether variable refresh rate should be enabled on the CRTC.
+*/
+ struct drm_property *prop_vrr_enabled;
/**
* @dvi_i_subconnector_property: Optional DVI-I property to
Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions
On Sat, Oct 13, 2018 at 11:27 AM Jason Ekstrand
wrote:
> On Sat, Oct 13, 2018 at 11:24 AM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
>
>> On Sat, Oct 13, 2018 at 6:12 PM Jason Ekstrand
>> wrote:
>> >
>> > On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen <
>> b...@basnieuwenhuizen.nl> wrote:
>> >>
>> >> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard
>> wrote:
>> >> >
>> >> > According to the Vulkan spec:
>> >> >
>> >> > "Vulkan 1.0 initially required all new physical-device-level
>> extension
>> >> > functionality to be structured within an instance extension. In
>> order
>> >> > to avoid using an instance extension, which often requires loader
>> >> > support, physical-device-level extension functionality may be
>> >> > implemented within device extensions"
>> >> >
>> >> > The code that checks for enabled extension APIs currently only passes
>> >> > functions with VkDevice or VkCommandBuffer as their first
>> >> > argument. This patch extends that to also allow functions with
>> >> > VkPhysicalDevice parameters, in support of the above quote from the
>> >> > Vulkan spec.
>> >> >
>> >>
>> >> Also "To obtain a function pointer for a physical-device-level command
>> >> from a device extension, an application can use vkGetInstanceProcAddr.
>> >> "
>> >>
>> >> As far as I can tell the device_command member is only to make sure we
>> >> return NULL from vkGetDeviceProcAddr, and per the spec (3.1 table 2)
>> >> we still have to return NULL there for functions which take
>> >> VkPhysicalDevice? So the old behavior seems correct to me.
>> >
>> >
>> > I think anv is ignoring that line in the table which is why it works
>> for us. If only someone wrote tests for these things...
>> >
>> > I think the correct interpretation would be that any physical device
>> functions that are part of a core version or instance extension should
>> yield NULL but any physical device functions from a device extension should
>> return a valid function pointer. Sadly, that behavior is kind-of a pain to
>> implement. :-(
>>
>> How would you read that into the spec? As quoted above it explicitly
>> tells you to use vkGetInstanceProcAddr for VkPhysicalDevice functions,
>> even if they are based on a device extension. (And you cannot really
>> use vkGetDeviceProcAddr anyway as the typical usecase is before you've
>> created a device).
>>
>
> Because I was reading the wrong chunk of spec. :-( You are correct and
> radv is like doing the right thing and anv is doing the wrong thing.
>
Actually, I think anv is doing the right thing too. Now I have no idea why
Keith was having problems.
--Jason
>
>
>> >
>> >>
>> >> > Signed-off-by: Keith Packard
>> >> > ---
>> >> > src/amd/vulkan/radv_entrypoints_gen.py | 2 +-
>> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/src/amd/vulkan/radv_entrypoints_gen.py
>> b/src/amd/vulkan/radv_entrypoints_gen.py
>> >> > index 377b544c2aa..69e6fc3e0eb 100644
>> >> > --- a/src/amd/vulkan/radv_entrypoints_gen.py
>> >> > +++ b/src/amd/vulkan/radv_entrypoints_gen.py
>> >> > @@ -352,7 +352,7 @@ class Entrypoint(EntrypointBase):
>> >> > self.return_type = return_type
>> >> > self.params = params
>> >> > self.guard = guard
>> >> > -self.device_command = len(params) > 0 and (params[0].type
>> == 'VkDevice' or params[0].type == 'VkQueue' or params[0].type ==
>> 'VkCommandBuffer')
>> >> > +self.device_command = len(params) > 0 and (params[0].type
>> == 'VkPhysicalDevice' or params[0].type == 'VkDevice' or params[0].type ==
>> 'VkQueue' or params[0].type == 'VkCommandBuffer')
>> >> >
>> >> > def prefixed_name(self, prefix):
>> >> > assert self.name.startswith('vk')
>> >> > --
>> >> > 2.19.1
>> >> >
>> >> > ___
>> >> > mesa-dev mailing list
>> >> > mesa-...@lists.freedesktop.org
>> >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> >> ___
>> >> mesa-dev mailing list
>> >> mesa-...@lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible lock inversion in ttm_bo_vm_access
Hi Thomas, bo_reserve() copy_to_user() / copy_from_user() bo_unreserve() That pattern is illegal for a number of reasons and the mmap_sem is only one of it. So the locking order must always be mmap_sem->bo_reservation. See the userptr implementation in amdgpu as well. Christian. Am 12.10.2018 um 16:52 schrieb Thomas Hellstrom: Hi, Felix, It looks like there is a locking inversion in ttm_bo_vm_access() where we take a sleeping bo_reserve() while holding mmap_sem(). Previously we've been assuming the other way around or at least undefined allowing for drivers to do bo_reserve() copy_to_user() / copy_from_user() bo_unreserve() I'm not sure the latter pattern is used in any drivers, though, and I guess there are ways around it. So it might make sense to fix the locking order at this point. In that case, perhaps one should add a might_lock(>resv->lock.base); at the start of the TTM fault handler to trip lockdep on locking order violations in situations where the access() callback isn't commonly used... /Thomas ___ 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
[Bug 108347] [regression, bisected] Performance drop in Tesseract
https://bugs.freedesktop.org/show_bug.cgi?id=108347 Gregor Münch changed: What|Removed |Added Summary|[regression, bisected] |[regression, bisected] |Performance drop in various |Performance drop in |games |Tesseract --- Comment #1 from Gregor Münch --- Here is a complete test result from comparing todays master with the commit right before the bisected commit. https://openbenchmarking.org/result/1810130-RA-MESAPERFO80 We see that without nir, the impact in Tesseract isnt that much. However with nir we see a regression from 412 to 397 fps, Dirt Rally drops from 108 to 107fps. Other games see mostly a small improvement, except Civ VI 36 to 37fps. I will change the title as it mostly impacts Tesseract. Havent tested other games. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH 4/8] sound: hpios: don't pass GFP_DMA32 to dma_alloc_coherent
On Sat, Oct 13, 2018 at 06:18:28PM +0200, Takashi Iwai wrote: > On Sat, 13 Oct 2018 17:17:03 +0200, > Christoph Hellwig wrote: > > > > The DMA API does its own zone decisions based on the coherent_dma_mask. > > > > Signed-off-by: Christoph Hellwig > > Reviewed-by: Takashi Iwai > > > Would you like to take this as a series, or shall I take individually > through sound tree? There is nothing that depends on this, so feel free to apply the two sound patches to your tree. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions
On Sat, Oct 13, 2018 at 11:24 AM Bas Nieuwenhuizen
wrote:
> On Sat, Oct 13, 2018 at 6:12 PM Jason Ekstrand
> wrote:
> >
> > On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard
> wrote:
> >> >
> >> > According to the Vulkan spec:
> >> >
> >> > "Vulkan 1.0 initially required all new physical-device-level extension
> >> > functionality to be structured within an instance extension. In order
> >> > to avoid using an instance extension, which often requires loader
> >> > support, physical-device-level extension functionality may be
> >> > implemented within device extensions"
> >> >
> >> > The code that checks for enabled extension APIs currently only passes
> >> > functions with VkDevice or VkCommandBuffer as their first
> >> > argument. This patch extends that to also allow functions with
> >> > VkPhysicalDevice parameters, in support of the above quote from the
> >> > Vulkan spec.
> >> >
> >>
> >> Also "To obtain a function pointer for a physical-device-level command
> >> from a device extension, an application can use vkGetInstanceProcAddr.
> >> "
> >>
> >> As far as I can tell the device_command member is only to make sure we
> >> return NULL from vkGetDeviceProcAddr, and per the spec (3.1 table 2)
> >> we still have to return NULL there for functions which take
> >> VkPhysicalDevice? So the old behavior seems correct to me.
> >
> >
> > I think anv is ignoring that line in the table which is why it works for
> us. If only someone wrote tests for these things...
> >
> > I think the correct interpretation would be that any physical device
> functions that are part of a core version or instance extension should
> yield NULL but any physical device functions from a device extension should
> return a valid function pointer. Sadly, that behavior is kind-of a pain to
> implement. :-(
>
> How would you read that into the spec? As quoted above it explicitly
> tells you to use vkGetInstanceProcAddr for VkPhysicalDevice functions,
> even if they are based on a device extension. (And you cannot really
> use vkGetDeviceProcAddr anyway as the typical usecase is before you've
> created a device).
>
Because I was reading the wrong chunk of spec. :-( You are correct and
radv is like doing the right thing and anv is doing the wrong thing.
--Jason
> >
> >>
> >> > Signed-off-by: Keith Packard
> >> > ---
> >> > src/amd/vulkan/radv_entrypoints_gen.py | 2 +-
> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/src/amd/vulkan/radv_entrypoints_gen.py
> b/src/amd/vulkan/radv_entrypoints_gen.py
> >> > index 377b544c2aa..69e6fc3e0eb 100644
> >> > --- a/src/amd/vulkan/radv_entrypoints_gen.py
> >> > +++ b/src/amd/vulkan/radv_entrypoints_gen.py
> >> > @@ -352,7 +352,7 @@ class Entrypoint(EntrypointBase):
> >> > self.return_type = return_type
> >> > self.params = params
> >> > self.guard = guard
> >> > -self.device_command = len(params) > 0 and (params[0].type ==
> 'VkDevice' or params[0].type == 'VkQueue' or params[0].type ==
> 'VkCommandBuffer')
> >> > +self.device_command = len(params) > 0 and (params[0].type ==
> 'VkPhysicalDevice' or params[0].type == 'VkDevice' or params[0].type ==
> 'VkQueue' or params[0].type == 'VkCommandBuffer')
> >> >
> >> > def prefixed_name(self, prefix):
> >> > assert self.name.startswith('vk')
> >> > --
> >> > 2.19.1
> >> >
> >> > ___
> >> > mesa-dev mailing list
> >> > mesa-...@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> ___
> >> mesa-dev mailing list
> >> mesa-...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions
On Sat, Oct 13, 2018 at 6:12 PM Jason Ekstrand wrote:
>
> On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen
> wrote:
>>
>> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard wrote:
>> >
>> > According to the Vulkan spec:
>> >
>> > "Vulkan 1.0 initially required all new physical-device-level extension
>> > functionality to be structured within an instance extension. In order
>> > to avoid using an instance extension, which often requires loader
>> > support, physical-device-level extension functionality may be
>> > implemented within device extensions"
>> >
>> > The code that checks for enabled extension APIs currently only passes
>> > functions with VkDevice or VkCommandBuffer as their first
>> > argument. This patch extends that to also allow functions with
>> > VkPhysicalDevice parameters, in support of the above quote from the
>> > Vulkan spec.
>> >
>>
>> Also "To obtain a function pointer for a physical-device-level command
>> from a device extension, an application can use vkGetInstanceProcAddr.
>> "
>>
>> As far as I can tell the device_command member is only to make sure we
>> return NULL from vkGetDeviceProcAddr, and per the spec (3.1 table 2)
>> we still have to return NULL there for functions which take
>> VkPhysicalDevice? So the old behavior seems correct to me.
>
>
> I think anv is ignoring that line in the table which is why it works for us.
> If only someone wrote tests for these things...
>
> I think the correct interpretation would be that any physical device
> functions that are part of a core version or instance extension should yield
> NULL but any physical device functions from a device extension should return
> a valid function pointer. Sadly, that behavior is kind-of a pain to
> implement. :-(
How would you read that into the spec? As quoted above it explicitly
tells you to use vkGetInstanceProcAddr for VkPhysicalDevice functions,
even if they are based on a device extension. (And you cannot really
use vkGetDeviceProcAddr anyway as the typical usecase is before you've
created a device).
>
>>
>> > Signed-off-by: Keith Packard
>> > ---
>> > src/amd/vulkan/radv_entrypoints_gen.py | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/src/amd/vulkan/radv_entrypoints_gen.py
>> > b/src/amd/vulkan/radv_entrypoints_gen.py
>> > index 377b544c2aa..69e6fc3e0eb 100644
>> > --- a/src/amd/vulkan/radv_entrypoints_gen.py
>> > +++ b/src/amd/vulkan/radv_entrypoints_gen.py
>> > @@ -352,7 +352,7 @@ class Entrypoint(EntrypointBase):
>> > self.return_type = return_type
>> > self.params = params
>> > self.guard = guard
>> > -self.device_command = len(params) > 0 and (params[0].type ==
>> > 'VkDevice' or params[0].type == 'VkQueue' or params[0].type ==
>> > 'VkCommandBuffer')
>> > +self.device_command = len(params) > 0 and (params[0].type ==
>> > 'VkPhysicalDevice' or params[0].type == 'VkDevice' or params[0].type ==
>> > 'VkQueue' or params[0].type == 'VkCommandBuffer')
>> >
>> > def prefixed_name(self, prefix):
>> > assert self.name.startswith('vk')
>> > --
>> > 2.19.1
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-...@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> ___
>> mesa-dev mailing list
>> mesa-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH 5/8] sound: intel/sst: don't pass GFP_DMA32 to dma_alloc_coherent
On Sat, 13 Oct 2018 17:17:04 +0200,
Christoph Hellwig wrote:
>
> The DMA API does its own zone decisions based on the coherent_dma_mask.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Takashi Iwai
thanks,
Takashi
> ---
> sound/soc/intel/common/sst-firmware.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/intel/common/sst-firmware.c
> b/sound/soc/intel/common/sst-firmware.c
> index 11041aedea31..1e067504b604 100644
> --- a/sound/soc/intel/common/sst-firmware.c
> +++ b/sound/soc/intel/common/sst-firmware.c
> @@ -355,7 +355,7 @@ struct sst_fw *sst_fw_new(struct sst_dsp *dsp,
>
> /* allocate DMA buffer to store FW data */
> sst_fw->dma_buf = dma_alloc_coherent(dsp->dma_dev, sst_fw->size,
> - _fw->dmable_fw_paddr, GFP_DMA | GFP_KERNEL);
> + _fw->dmable_fw_paddr, GFP_KERNEL);
> if (!sst_fw->dma_buf) {
> dev_err(dsp->dev, "error: DMA alloc failed\n");
> kfree(sst_fw);
> --
> 2.19.1
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH 4/8] sound: hpios: don't pass GFP_DMA32 to dma_alloc_coherent
On Sat, 13 Oct 2018 17:17:03 +0200,
Christoph Hellwig wrote:
>
> The DMA API does its own zone decisions based on the coherent_dma_mask.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Takashi Iwai
Would you like to take this as a series, or shall I take individually
through sound tree?
thanks,
Takashi
> ---
> sound/pci/asihpi/hpios.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/pci/asihpi/hpios.c b/sound/pci/asihpi/hpios.c
> index 5ef4fe964366..7c91330af719 100644
> --- a/sound/pci/asihpi/hpios.c
> +++ b/sound/pci/asihpi/hpios.c
> @@ -49,7 +49,7 @@ u16 hpios_locked_mem_alloc(struct consistent_dma_area
> *p_mem_area, u32 size,
> /*?? any benefit in using managed dmam_alloc_coherent? */
> p_mem_area->vaddr =
> dma_alloc_coherent(>dev, size, _mem_area->dma_handle,
> - GFP_DMA32 | GFP_KERNEL);
> + GFP_KERNEL);
>
> if (p_mem_area->vaddr) {
> HPI_DEBUG_LOG(DEBUG, "allocated %d bytes, dma 0x%x vma %p\n",
> --
> 2.19.1
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions
On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen
wrote:
> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard wrote:
> >
> > According to the Vulkan spec:
> >
> > "Vulkan 1.0 initially required all new physical-device-level extension
> > functionality to be structured within an instance extension. In order
> > to avoid using an instance extension, which often requires loader
> > support, physical-device-level extension functionality may be
> > implemented within device extensions"
> >
> > The code that checks for enabled extension APIs currently only passes
> > functions with VkDevice or VkCommandBuffer as their first
> > argument. This patch extends that to also allow functions with
> > VkPhysicalDevice parameters, in support of the above quote from the
> > Vulkan spec.
> >
>
> Also "To obtain a function pointer for a physical-device-level command
> from a device extension, an application can use vkGetInstanceProcAddr.
> "
>
> As far as I can tell the device_command member is only to make sure we
> return NULL from vkGetDeviceProcAddr, and per the spec (3.1 table 2)
> we still have to return NULL there for functions which take
> VkPhysicalDevice? So the old behavior seems correct to me.
>
I think anv is ignoring that line in the table which is why it works for
us. If only someone wrote tests for these things...
I think the correct interpretation would be that any physical device
functions that are part of a core version or instance extension should
yield NULL but any physical device functions from a device extension should
return a valid function pointer. Sadly, that behavior is kind-of a pain to
implement. :-(
> > Signed-off-by: Keith Packard
> > ---
> > src/amd/vulkan/radv_entrypoints_gen.py | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/amd/vulkan/radv_entrypoints_gen.py
> b/src/amd/vulkan/radv_entrypoints_gen.py
> > index 377b544c2aa..69e6fc3e0eb 100644
> > --- a/src/amd/vulkan/radv_entrypoints_gen.py
> > +++ b/src/amd/vulkan/radv_entrypoints_gen.py
> > @@ -352,7 +352,7 @@ class Entrypoint(EntrypointBase):
> > self.return_type = return_type
> > self.params = params
> > self.guard = guard
> > -self.device_command = len(params) > 0 and (params[0].type ==
> 'VkDevice' or params[0].type == 'VkQueue' or params[0].type ==
> 'VkCommandBuffer')
> > +self.device_command = len(params) > 0 and (params[0].type ==
> 'VkPhysicalDevice' or params[0].type == 'VkDevice' or params[0].type ==
> 'VkQueue' or params[0].type == 'VkCommandBuffer')
> >
> > def prefixed_name(self, prefix):
> > assert self.name.startswith('vk')
> > --
> > 2.19.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions
On Fri, Oct 12, 2018 at 10:38 PM Keith Packard wrote:
>
> According to the Vulkan spec:
>
> "Vulkan 1.0 initially required all new physical-device-level extension
> functionality to be structured within an instance extension. In order
> to avoid using an instance extension, which often requires loader
> support, physical-device-level extension functionality may be
> implemented within device extensions"
>
> The code that checks for enabled extension APIs currently only passes
> functions with VkDevice or VkCommandBuffer as their first
> argument. This patch extends that to also allow functions with
> VkPhysicalDevice parameters, in support of the above quote from the
> Vulkan spec.
>
Also "To obtain a function pointer for a physical-device-level command
from a device extension, an application can use vkGetInstanceProcAddr.
"
As far as I can tell the device_command member is only to make sure we
return NULL from vkGetDeviceProcAddr, and per the spec (3.1 table 2)
we still have to return NULL there for functions which take
VkPhysicalDevice? So the old behavior seems correct to me.
> Signed-off-by: Keith Packard
> ---
> src/amd/vulkan/radv_entrypoints_gen.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_entrypoints_gen.py
> b/src/amd/vulkan/radv_entrypoints_gen.py
> index 377b544c2aa..69e6fc3e0eb 100644
> --- a/src/amd/vulkan/radv_entrypoints_gen.py
> +++ b/src/amd/vulkan/radv_entrypoints_gen.py
> @@ -352,7 +352,7 @@ class Entrypoint(EntrypointBase):
> self.return_type = return_type
> self.params = params
> self.guard = guard
> -self.device_command = len(params) > 0 and (params[0].type ==
> 'VkDevice' or params[0].type == 'VkQueue' or params[0].type ==
> 'VkCommandBuffer')
> +self.device_command = len(params) > 0 and (params[0].type ==
> 'VkPhysicalDevice' or params[0].type == 'VkDevice' or params[0].type ==
> 'VkQueue' or params[0].type == 'VkCommandBuffer')
>
> def prefixed_name(self, prefix):
> assert self.name.startswith('vk')
> --
> 2.19.1
>
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] fsl-diu-fb: don't pass GFP_DMA32 to dmam_alloc_coherent
The DMA API does its own zone decisions based on the coherent_dma_mask. Signed-off-by: Christoph Hellwig --- drivers/video/fbdev/fsl-diu-fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c index bc9eb8afc313..6a49fe917bdb 100644 --- a/drivers/video/fbdev/fsl-diu-fb.c +++ b/drivers/video/fbdev/fsl-diu-fb.c @@ -1697,7 +1697,7 @@ static int fsl_diu_probe(struct platform_device *pdev) int ret; data = dmam_alloc_coherent(>dev, sizeof(struct fsl_diu_data), - _addr, GFP_DMA | __GFP_ZERO); + _addr, GFP_KERNEL | __GFP_ZERO); if (!data) return -ENOMEM; data->dma_addr = dma_addr; -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] cpufreq: tegra186: don't pass GFP_DMA32 to dma_alloc_coherent
The DMA API does its own zone decisions based on the coherent_dma_mask. Signed-off-by: Christoph Hellwig --- drivers/cpufreq/tegra186-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/tegra186-cpufreq.c b/drivers/cpufreq/tegra186-cpufreq.c index 1f59966573aa..f1e09022b819 100644 --- a/drivers/cpufreq/tegra186-cpufreq.c +++ b/drivers/cpufreq/tegra186-cpufreq.c @@ -121,7 +121,7 @@ static struct cpufreq_frequency_table *init_vhint_table( void *virt; virt = dma_alloc_coherent(bpmp->dev, sizeof(*data), , - GFP_KERNEL | GFP_DMA32); + GFP_KERNEL); if (!virt) return ERR_PTR(-ENOMEM); -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] sound: intel/sst: don't pass GFP_DMA32 to dma_alloc_coherent
The DMA API does its own zone decisions based on the coherent_dma_mask.
Signed-off-by: Christoph Hellwig
---
sound/soc/intel/common/sst-firmware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/common/sst-firmware.c
b/sound/soc/intel/common/sst-firmware.c
index 11041aedea31..1e067504b604 100644
--- a/sound/soc/intel/common/sst-firmware.c
+++ b/sound/soc/intel/common/sst-firmware.c
@@ -355,7 +355,7 @@ struct sst_fw *sst_fw_new(struct sst_dsp *dsp,
/* allocate DMA buffer to store FW data */
sst_fw->dma_buf = dma_alloc_coherent(dsp->dma_dev, sst_fw->size,
- _fw->dmable_fw_paddr, GFP_DMA | GFP_KERNEL);
+ _fw->dmable_fw_paddr, GFP_KERNEL);
if (!sst_fw->dma_buf) {
dev_err(dsp->dev, "error: DMA alloc failed\n");
kfree(sst_fw);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm: sti: don't pass GFP_DMA32 to dma_alloc_wc
The DMA API does its own zone decisions based on the coherent_dma_mask.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/sti/sti_gdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index c32de6cbf061..cdf0a1396e00 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -517,7 +517,7 @@ static void sti_gdp_init(struct sti_gdp *gdp)
/* Allocate all the nodes within a single memory page */
size = sizeof(struct sti_gdp_node) *
GDP_NODE_PER_FIELD * GDP_NODE_NB_BANK;
- base = dma_alloc_wc(gdp->dev, size, _addr, GFP_KERNEL | GFP_DMA);
+ base = dma_alloc_wc(gdp->dev, size, _addr, GFP_KERNEL);
if (!base) {
DRM_ERROR("Failed to allocate memory for GDP node\n");
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] spi: pic32-sqi: don't pass GFP_DMA32 to dma_alloc_coherent
The DMA API does its own zone decisions based on the coherent_dma_mask.
Signed-off-by: Christoph Hellwig
---
drivers/spi/spi-pic32-sqi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-pic32-sqi.c b/drivers/spi/spi-pic32-sqi.c
index bd1c6b53283f..ab53e461d80f 100644
--- a/drivers/spi/spi-pic32-sqi.c
+++ b/drivers/spi/spi-pic32-sqi.c
@@ -468,7 +468,7 @@ static int ring_desc_ring_alloc(struct pic32_sqi *sqi)
/* allocate coherent DMAable memory for hardware buffer descriptors. */
sqi->bd = dma_zalloc_coherent(>master->dev,
sizeof(*bd) * PESQI_BD_COUNT,
- >bd_dma, GFP_DMA32);
+ >bd_dma, GFP_KERNEL);
if (!sqi->bd) {
dev_err(>master->dev, "failed allocating dma buffer\n");
return -ENOMEM;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] media: sti/bdisp: don't pass GFP_DMA32 to dma_alloc_attrs
The DMA API does its own zone decisions based on the coherent_dma_mask. Signed-off-by: Christoph Hellwig --- drivers/media/platform/sti/bdisp/bdisp-hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c b/drivers/media/platform/sti/bdisp/bdisp-hw.c index 26d9fa7aeb5f..4372abbb5950 100644 --- a/drivers/media/platform/sti/bdisp/bdisp-hw.c +++ b/drivers/media/platform/sti/bdisp/bdisp-hw.c @@ -510,7 +510,7 @@ int bdisp_hw_alloc_filters(struct device *dev) /* Allocate all the filters within a single memory page */ size = (BDISP_HF_NB * NB_H_FILTER) + (BDISP_VF_NB * NB_V_FILTER); - base = dma_alloc_attrs(dev, size, , GFP_KERNEL | GFP_DMA, + base = dma_alloc_attrs(dev, size, , GFP_KERNEL, DMA_ATTR_WRITE_COMBINE); if (!base) return -ENOMEM; -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] sound: hpios: don't pass GFP_DMA32 to dma_alloc_coherent
The DMA API does its own zone decisions based on the coherent_dma_mask.
Signed-off-by: Christoph Hellwig
---
sound/pci/asihpi/hpios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/asihpi/hpios.c b/sound/pci/asihpi/hpios.c
index 5ef4fe964366..7c91330af719 100644
--- a/sound/pci/asihpi/hpios.c
+++ b/sound/pci/asihpi/hpios.c
@@ -49,7 +49,7 @@ u16 hpios_locked_mem_alloc(struct consistent_dma_area
*p_mem_area, u32 size,
/*?? any benefit in using managed dmam_alloc_coherent? */
p_mem_area->vaddr =
dma_alloc_coherent(>dev, size, _mem_area->dma_handle,
- GFP_DMA32 | GFP_KERNEL);
+ GFP_KERNEL);
if (p_mem_area->vaddr) {
HPI_DEBUG_LOG(DEBUG, "allocated %d bytes, dma 0x%x vma %p\n",
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] firmware: tegra: don't pass GFP_DMA32 to dma_alloc_coherent
The DMA API does its own zone decisions based on the coherent_dma_mask.
Signed-off-by: Christoph Hellwig
---
drivers/firmware/tegra/bpmp-debugfs.c | 11 +--
drivers/firmware/tegra/bpmp.c | 2 +-
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/tegra/bpmp-debugfs.c
b/drivers/firmware/tegra/bpmp-debugfs.c
index f7f6a0a5cb07..567160897bac 100644
--- a/drivers/firmware/tegra/bpmp-debugfs.c
+++ b/drivers/firmware/tegra/bpmp-debugfs.c
@@ -218,12 +218,12 @@ static int debugfs_show(struct seq_file *m, void *p)
return -ENOENT;
namevirt = dma_alloc_coherent(bpmp->dev, namesize, ,
- GFP_KERNEL | GFP_DMA32);
+ GFP_KERNEL);
if (!namevirt)
return -ENOMEM;
datavirt = dma_alloc_coherent(bpmp->dev, datasize, ,
- GFP_KERNEL | GFP_DMA32);
+ GFP_KERNEL);
if (!datavirt) {
ret = -ENOMEM;
goto free_namebuf;
@@ -269,12 +269,12 @@ static ssize_t debugfs_store(struct file *file, const
char __user *buf,
return -ENOENT;
namevirt = dma_alloc_coherent(bpmp->dev, namesize, ,
- GFP_KERNEL | GFP_DMA32);
+ GFP_KERNEL);
if (!namevirt)
return -ENOMEM;
datavirt = dma_alloc_coherent(bpmp->dev, datasize, ,
- GFP_KERNEL | GFP_DMA32);
+ GFP_KERNEL);
if (!datavirt) {
ret = -ENOMEM;
goto free_namebuf;
@@ -422,8 +422,7 @@ int tegra_bpmp_init_debugfs(struct tegra_bpmp *bpmp)
if (!root)
return -ENOMEM;
- virt = dma_alloc_coherent(bpmp->dev, sz, ,
- GFP_KERNEL | GFP_DMA32);
+ virt = dma_alloc_coherent(bpmp->dev, sz, , GFP_KERNEL);
if (!virt) {
ret = -ENOMEM;
goto out;
diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 14a456afa379..e6d2356ccec3 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -531,7 +531,7 @@ static int tegra_bpmp_get_firmware_tag(struct tegra_bpmp
*bpmp, char *tag,
int err;
virt = dma_alloc_coherent(bpmp->dev, MSG_DATA_MIN_SZ, ,
- GFP_KERNEL | GFP_DMA32);
+ GFP_KERNEL);
if (!virt)
return -ENOMEM;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
remove bogus GFP_DMA32 flags for dma allocations
dma_alloc_* internally selects the zone to allocate from based on the DMA mask. Remove all explicit uses of GFP_DMA32 with dma_alloc_*. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108352] On GIGABYTE Radeon RX Vega 64 Gaming OC 8G applications `sensor` and `xsensor` showed last rpm before fan off when really fan is off
https://bugs.freedesktop.org/show_bug.cgi?id=108352 --- Comment #1 from mikhail.v.gavri...@gmail.com --- $ uname -r 4.19.0-0.rc7.git0.1.fc30.x86_64 $ inxi -bM System:Host: localhost.localdomain Kernel: 4.19.0-0.rc7.git0.1.fc30.x86_64 x86_64 bits: 64 Desktop: Gnome 3.30.1 Distro: Fedora release 30 (Rawhide) Machine: Type: Desktop Mobo: ASUSTeK model: ROG STRIX X470-I GAMING v: Rev 1.xx serial: UEFI: American Megatrends v: 0901 date: 07/23/2018 CPU: 8-Core: AMD Ryzen 7 2700X type: MT MCP speed: 1684 MHz min/max: 2200/4000 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] driver: amdgpu v: kernel Display: wayland server: Fedora Project X.org 1.20.1 driver: amdgpu resolution: 1920x1080~60Hz OpenGL: renderer: Radeon RX Vega (VEGA10 DRM 3.27.0 4.19.0-0.rc7.git0.1.fc30.x86_64 LLVM 7.0.0) v: 4.5 Mesa 18.2.2 Network: Device-1: Intel I211 Gigabit Network driver: igb Device-2: Realtek RTL8822BE 802.11a/b/g/n/ac WiFi adapter driver: r8822be Drives:Local Storage: total: 11.35 TiB used: 800.88 GiB (6.9%) Info: Processes: 514 Uptime: 20h 31m Memory: 31.41 GiB used: 9.09 GiB (28.9%) Shell: bash inxi: 3.0.26 $ lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Root Complex 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) I/O Memory Management Unit 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 59) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 5 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 6 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 7 01:00.0 Non-Volatile memory controller: Intel Corporation Optane SSD 900P Series 02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43d0 (rev 01) 02:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] Device 43c8 (rev 01) 02:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43c6 (rev 01) 03:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43c7 (rev 01) 03:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43c7 (rev 01) 03:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43c7 (rev 01) 03:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43c7 (rev 01) 03:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43c7 (rev 01) 04:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) 05:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter 09:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1470 (rev c1) 0a:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1471 0b:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] (rev c1) 0b:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device
[Bug 108352] On GIGABYTE Radeon RX Vega 64 Gaming OC 8G applications `sensor` and `xsensor` showed last rpm before fan off when really fan is off
https://bugs.freedesktop.org/show_bug.cgi?id=108352 Bug ID: 108352 Summary: On GIGABYTE Radeon RX Vega 64 Gaming OC 8G applications `sensor` and `xsensor` showed last rpm before fan off when really fan is off Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com Created attachment 142016 --> https://bugs.freedesktop.org/attachment.cgi?id=142016=edit screenshot I am bought second RX Vega series video card. This is GIGABYTE Radeon RX Vega 64 Gaming OC 8G. https://www.gigabyte.com/Graphics-Card/GV-RXVEGA64GAMING-OC-8GD#kf And I observe follow bug: On GIGABYTE Radeon RX Vega 64 Gaming OC 8G applications `sensor` and `xsensor` showed last rpm before fan off when really fan is off. Expected behavior: When fan is really off `sensor` and `xsensor` must show 0 RPM. $ sensors amdgpu-pci-0b00 Adapter: PCI adapter vddgfx: +0.75 V fan1: 789 RPM temp1:+49.0°C (crit = +89.0°C, hyst = -273.1°C) power1:6.00 W (cap = 247.00 W) k10temp-pci-00c3 Adapter: PCI adapter Tdie: +41.0°C (high = +70.0°C) Tctl: +51.0°C asus-isa- Adapter: ISA adapter cpu_fan:0 RPM -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108322] RX580 Display flickering after waking from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=108322 --- Comment #12 from bmil...@gmail.com --- Created custom modes and forced it into xrandr. 75hz flickers, but 73hz is working fine it seems. This is on last amd-drm-next-staging ~ >>> gtf 1920 1080 73 # 1920x1080 @ 73.00 Hz (GTF) hsync: 82.20 kHz; pclk: 214.37 MHz Modeline "1920x1080_73.00" 214.37 1920 2056 2264 2608 1080 1081 1084 1126 -HSync +Vsync ~ >>> xrandr --newmode "1920x1080_73.00" 214.37 1920 2056 2264 2608 1080 1081 1084 1126 -HSync +Vsync [130] ~ >>> xrandr --addmode DisplayPort-0 "1920x1080_73.00" ~ >>> xrandr --output DisplayPort-0 --mode "1920x1080_73.00" Will keep it like this for now and test it in games, but in kde plasma/chromium 73hz is smooth as silk it seems. Another thing I noticed is gtf generates higher pixel clocks than the ones from my monitor (edid?). You can compare above result with the attached xorg log. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108309] Raven Ridge 2700U system lock-up on multiple games
https://bugs.freedesktop.org/show_bug.cgi?id=108309 --- Comment #8 from Samantha McVey --- Also to clarify: The first dmesg I uploaded had `rcu: INFO: rcu_sched detected stalls on CPUs/tasks:` in the log. Adding `idle=nomwait` to kernel cmdline has so far fully resolved this and other messages which sometimes would appear which not always referenced rcu_sched but seemed to imply a cpu or thread had stalled. There seem to be several Ryzen errata related to mwait (https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf) so I think that issue is fixed though the amdgpu/drm issues seem to have remained. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108309] Raven Ridge 2700U system lock-up on multiple games
https://bugs.freedesktop.org/show_bug.cgi?id=108309 --- Comment #7 from Samantha McVey --- Created attachment 142015 --> https://bugs.freedesktop.org/attachment.cgi?id=142015=edit dmesg from 4.19.0-rc7+ (commit bab5c80b2110 I believe) Here is a log with git from a day ago (commit bab5c80b2110). This log and the previous I posted both seem to show some aspect of the system is still responding, as you can tell it logged my sysrq attempts. Though trying to hard shutdown/restart with sysrq doesn't result in the system restarting, and it still shows the same image on the screen from the time of the freeze. DRM messages at the end of the log: Oct 12 21:19:22 kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:41:crtc-0] flip_done timed out Oct 12 21:19:32 kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:41:crtc-0] flip_done timed out Oct 12 21:19:42 kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:40:plane-4] flip_done timed out -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/gpu: Fix a couple memory leaks in debugfs
The msm_gpu_open() function should free "show_priv" on error or it
causes static checker warnings.
Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU
state")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/msm/msm_debugfs.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
b/drivers/gpu/drm/msm/msm_debugfs.c
index f0da0d3c8a80..d756436c1fcd 100644
--- a/drivers/gpu/drm/msm/msm_debugfs.c
+++ b/drivers/gpu/drm/msm/msm_debugfs.c
@@ -84,7 +84,7 @@ static int msm_gpu_open(struct inode *inode, struct file
*file)
ret = mutex_lock_interruptible(>struct_mutex);
if (ret)
- return ret;
+ goto free_priv;
pm_runtime_get_sync(>pdev->dev);
show_priv->state = gpu->funcs->gpu_state_get(gpu);
@@ -94,13 +94,20 @@ static int msm_gpu_open(struct inode *inode, struct file
*file)
if (IS_ERR(show_priv->state)) {
ret = PTR_ERR(show_priv->state);
- kfree(show_priv);
- return ret;
+ goto free_priv;
}
show_priv->dev = dev;
- return single_open(file, msm_gpu_show, show_priv);
+ ret = single_open(file, msm_gpu_show, show_priv);
+ if (ret)
+ goto free_priv;
+
+ return 0;
+
+free_priv:
+ kfree(show_priv);
+ return ret;
}
static const struct file_operations msm_gpu_fops = {
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: checking for NULL instead of IS_ERR()
The of_drm_find_panel() function returns error pointers and never NULL
but we the driver assumes that ->panel is NULL when it's not present.
Fixes: 6afb7721e2a0 ("drm/exynos: move connector creation to attach callback")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 07af7758066d..32f256749789 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1527,7 +1527,9 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
}
dsi->panel = of_drm_find_panel(device->dev.of_node);
- if (dsi->panel) {
+ if (IS_ERR(dsi->panel)) {
+ dsi->panel = NULL;
+ } else {
drm_panel_attach(dsi->panel, >connector);
dsi->connector.status = connector_status_connected;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108309] Raven Ridge 2700U system lock-up on multiple games
https://bugs.freedesktop.org/show_bug.cgi?id=108309 Samantha McVey changed: What|Removed |Added Attachment #142001|0 |1 is obsolete|| --- Comment #6 from Samantha McVey --- Created attachment 142014 --> https://bugs.freedesktop.org/attachment.cgi?id=142014=edit 4.18.12 Xorg log, was using vulkan at the time -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108309] Raven Ridge 2700U system lock-up on multiple games
https://bugs.freedesktop.org/show_bug.cgi?id=108309 Samantha McVey changed: What|Removed |Added Attachment #142000|0 |1 is obsolete|| --- Comment #5 from Samantha McVey --- Created attachment 142013 --> https://bugs.freedesktop.org/attachment.cgi?id=142013=edit 4.18.12 dmesg log, was using vulkan at the time Seems I spoke too soon. I am uploading some logs taken with 4.18.12 while using vulkan. Screen was fully frozen, and for example trying to mute audio would not change the status indicator on my keyboard. Some extracts related to amdgpu below, but the full dmesg is attached. Oct 13 01:08:12 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=1055330, last emitted seq=1055332 ... Oct 13 01:09:24 kernel: kworker/0:2: page allocation failure: order:10, mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null) Oct 13 01:09:24 kernel: kworker/0:2 cpuset=/ mems_allowed=0 Oct 13 01:09:24 kernel: CPU: 0 PID: 192238 Comm: kworker/0:2 Tainted: G C4.18.12 #1 Oct 13 01:09:24 kernel: Hardware name: LENOVO 20MUCTO1WW/20MUCTO1WW, BIOS R0WET34W (1.02 ) 07/05/2018 Oct 13 01:09:24 kernel: Workqueue: events do_poweroff Oct 13 01:09:24 kernel: Call Trace: Oct 13 01:09:24 kernel: dump_stack+0x5c/0x7b Oct 13 01:09:24 kernel: warn_alloc+0xf7/0x180 Oct 13 01:09:24 kernel: ? _cond_resched+0x11/0x40 Oct 13 01:09:24 kernel: __alloc_pages_nodemask+0xee3/0x1030 Oct 13 01:09:24 kernel: ? __radix_tree_delete+0x7e/0xa0 Oct 13 01:09:24 kernel: cache_grow_begin+0x77/0x510 Oct 13 01:09:24 kernel: fallback_alloc+0x15c/0x1f0 Oct 13 01:09:24 kernel: ? amdgpu_vcn_suspend+0x47/0x80 [amdgpu] Oct 13 01:09:24 kernel: __kmalloc+0x1bf/0x240 Oct 13 01:09:24 kernel: amdgpu_vcn_suspend+0x47/0x80 [amdgpu] Oct 13 01:09:24 kernel: amdgpu_device_ip_suspend+0xbd/0x160 [amdgpu] Oct 13 01:09:24 kernel: device_shutdown+0x13f/0x1e0 Oct 13 01:09:24 kernel: kernel_power_off+0x2c/0x60 Oct 13 01:09:24 kernel: process_one_work+0x1e0/0x3c0 Oct 13 01:09:24 kernel: worker_thread+0x44/0x3f0 Oct 13 01:09:24 kernel: kthread+0xf0/0x130 Oct 13 01:09:24 kernel: ? process_one_work+0x3c0/0x3c0 Oct 13 01:09:24 kernel: ? kthread_flush_work_fn+0x10/0x10 Oct 13 01:09:24 kernel: ret_from_fork+0x22/0x40 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107612] [Vega10] Hard Lock [gfxhub] VMC page fault when opening Mario Kart 8 in Cemu under wine
https://bugs.freedesktop.org/show_bug.cgi?id=107612 --- Comment #2 from Xalphenos --- I too have this issue on vega 8(2200g). It may be slightly interesting that a very similar problem happens on windows. The emulator behaves the same way freezing at the same moment while sound continues playing. The only difference is that windows itself remains operable. On windows all Fiji, polaris, and vega cards have had this problem at one time or another. It was fixed for polaris cards on 18.4.1. If I recall correctly It was fixed for fiji on 18.9.1. I don't believe it was ever fixed for vega. For polaris and fiji it has never been an issue on linux. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108317] [Polaris] Black Textures only on Polaris in Cemu Zelda Breath of the Wild
https://bugs.freedesktop.org/show_bug.cgi?id=108317 --- Comment #7 from Xalphenos --- I don't know if or in what way I could help but I wanted to add my experiences with this. I've been using testing this for about the last year with various cards and here are my findings. The issue seems to be that most textures are rendered black. Light sources are fine and anything transparent is fine. https://i.imgur.com/J2HCAkb.png The following are all cards that I have personally tested. rx 470 4gb Has this issue. r9 280 3gb Does not r9 Fury Has this issue rx 460 2gb has this issue vega 8(2200g) Does not Since I've been at this for so long I've ran in to dozens of others trying to run this emulator as well. Though not tested by me it seems we can add rx 480 and 580 as having the issue and vega 56 and vega 64 as not having the issue. I've been running this on mesa-git from lcarlier for nearly the last year and the results have always been the same. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
