[PATCH] drm/atomic: fix null dereference
We are checking the size of e->event but we were doing it when e is
known to be NULL.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu/drm/drm_atomic.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index acebd16..51d3a85 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1311,7 +1311,6 @@ static struct drm_pending_vblank_event
*create_vblank_event(
e = kzalloc(sizeof *e, GFP_KERNEL);
if (e == NULL) {
spin_lock_irqsave(>event_lock, flags);
- file_priv->event_space += sizeof e->event;
spin_unlock_irqrestore(>event_lock, flags);
goto out;
}
--
1.8.1.2
[PATCH 01/18] drm/gem: rip out drm vma accounting for gem mmaps
On Thu, Jul 09, 2015 at 11:32:33PM +0200, Daniel Vetter wrote: > Doesn't really add anything which can't be figured out through > proc files. And more clearly separates the new gem mmap handling > code from the old drm maps mmap handling code, which is surely a > good thing. > > Cc: Martin Peres > Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson Long have I wanted vmalist dead. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 91302] radeon.audio=1 causes weird issues with 7950
https://bugs.freedesktop.org/show_bug.cgi?id=91302 --- Comment #1 from Max Qia --- Seems like the bug has been there awhile https://bbs.archlinux.org/viewtopic.php?id=160515 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/20a6f882/attachment.html>
[Bug 91268] R6xx freezes with kernel 3.17 and up
https://bugs.freedesktop.org/show_bug.cgi?id=91268 --- Comment #1 from Kajzer --- Quote from another thread where this bug initially started : (In reply to Michel Dänzer from comment #273) > Please run a kernel built from commit > 77497f2735ad6e29c55475e15e9790dbfa2c2ef8 (the commit before > 02376d8282b88f07d0716da6155094c8760b1a13) for at least a few days to make > sure it doesn't happen with that. After few days I can safely say that this kernel runs great, I had no hangs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/64173e66/attachment.html>
[Bug 91308] Tonga UVD not working with GL_NV_vdpau_interop
https://bugs.freedesktop.org/show_bug.cgi?id=91308 --- Comment #1 from Andy Furniss --- Created attachment 117060 --> https://bugs.freedesktop.org/attachment.cgi?id=117060=edit my diff against agd5f/mesa -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/b3957419/attachment.html>
[Bug 91308] Tonga UVD not working with GL_NV_vdpau_interop
https://bugs.freedesktop.org/show_bug.cgi?id=91308 Bug ID: 91308 Summary: Tonga UVD not working with GL_NV_vdpau_interop Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: adf.lists at gmail.com UVD seems OK generally on Tonga (barring apparently being in low power) but not with GL_NV_vdpau_interop. Tested with kodi and mpv. kodi says - ERROR: VDPAU::COutput error mapping surface DEBUG: CLinuxRendererGL::GetPlaneTextureSize - invalid size 0x0 - 0 mpv - [vo/opengl] after rendering: OpenGL error INVALID_OPERATION. glxinfo shows GL_NV_vdpau_interop present. mesa is of course agd5f, with some llvm build fixes plus a minor modification I made to advertise level 52 (as ffmpeg cli at least does check). I'll attach my diff against agd5f mesa just in case I obviously messed up! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/4d4360cc/attachment.html>
[PATCH 09/12] drm/i915: Add pipe level Gamma correction for CHV/BSW
On Wednesday 08 July 2015 04:53 AM, Matt Roper wrote:
> On Fri, Jul 03, 2015 at 09:01:44AM +0530, Kausal Malladi wrote:
>> CHV/BSW platform supports various Gamma correction modes, which are:
>> 1. Legacy 8-bit mode
>> 2. 10-bit CGM (Color Gamut Mapping) mode
>>
>> This patch does the following:
>> 1. Adds the core function to program Gamma correction values for CHV/BSW
>> platform
>> 2. Adds Gamma correction macros/defines
>>
>> Signed-off-by: Shashank Sharma
>> Signed-off-by: Kausal Malladi
>> ---
>> drivers/gpu/drm/i915/i915_reg.h| 10 ++
>> drivers/gpu/drm/i915/intel_atomic.c| 6 ++
>> drivers/gpu/drm/i915/intel_color_manager.c | 154
>> +
>> drivers/gpu/drm/i915/intel_color_manager.h | 12 +++
>> drivers/gpu/drm/i915/intel_drv.h | 2 +
>> 5 files changed, 184 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 313b1f9..36672e7 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7900,4 +7900,14 @@ enum skl_disp_power_wells {
>> #define _PALETTE_A (dev_priv->info.display_mmio_offset + 0xa000)
>> #define _PALETTE_B (dev_priv->info.display_mmio_offset + 0xa800)
>>
>> +/* Color Management */
>> +#define PIPEA_CGM_CONTROL (VLV_DISPLAY_BASE + 0x67A00)
>> +#define PIPEA_CGM_GAMMA_MIN (VLV_DISPLAY_BASE + 0x67000)
>> +#define CGM_OFFSET 0x2000
>> +#define GAMMA_OFFSET0x2000
>> +#define _PIPE_CGM_CONTROL(pipe) \
>> +(PIPEA_CGM_CONTROL + (pipe * CGM_OFFSET))
>> +#define _PIPE_GAMMA_BASE(pipe) \
>> +(PIPEA_CGM_GAMMA_MIN + (pipe * GAMMA_OFFSET))
>> +
>> #endif /* _I915_REG_H_ */
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index d2674a6..21f0ac2 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -473,6 +473,12 @@ int intel_crtc_atomic_set_property(struct drm_crtc
>> *crtc,
>> struct drm_property *property,
>> uint64_t val)
>> {
>> +struct drm_device *dev = crtc->dev;
>> +struct drm_mode_config *config = >mode_config;
>> +
>> +if (property == config->prop_palette_after_ctm)
>> +return intel_color_manager_set_gamma(dev, >base, val);
>> +
> I think we discussed this on a previous iteration of the patch series,
> but .atomic_set_property() isn't supposed to actually update the
> hardware at all itself (as you're doing here); it's only supposed to
> update the 'state' parameter that was passed here. Further down the
> atomic pipeline the driver will decide whether it really wants to
> program any of the state or not and then the CRTC's atomic commit
> function should program the registers according to whatever value is set
> in the state object.
Thanks Matt for your suggestions offline. We will implement it this way
in our next set of patches.
>
>> DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
>> return -EINVAL;
>> }
>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>> b/drivers/gpu/drm/i915/intel_color_manager.c
>> index 71b4c05..84cc3e47 100644
>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>> @@ -27,6 +27,160 @@
>>
>> #include "intel_color_manager.h"
>>
>> +int chv_set_gamma(struct drm_device *dev, uint32_t blob_id,
>> + struct drm_crtc *crtc)
>> +{
>> +struct drm_palette *gamma_data;
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +struct drm_property_blob *blob;
>> +struct drm_mode_config *config = >mode_config;
>> +u32 cgm_control_reg = 0;
>> +u32 cgm_gamma_reg = 0;
>> +u32 reg, val;
>> +enum pipe pipe;
>> +u16 red, green, blue;
>> +u32 count = 0;
>> +struct drm_r32g32b32 *correction_values = NULL;
>> +u32 num_samples;
>> +u32 word;
>> +u32 palette;
>> +int ret = 0, length;
>> +
>> +blob = drm_property_lookup_blob(dev, blob_id);
>> +if (!blob) {
>> +DRM_ERROR("Invalid Blob ID\n");
>> +return -EINVAL;
>> +}
>> +
>> +gamma_data = (struct drm_palette *)blob->data;
> Do we need to validate that the blob we receive is of the expected size
> or does something in the DRM core's blob handling take care of that for
> us? We don't want userspace to be able to trigger a panic by passing a
> smaller than expected blob here.
Yes, it was an oversight.
>
>
>> +
>> +if (gamma_data->version != CHV_GAMMA_DATA_STRUCT_VERSION) {
>> +DRM_ERROR("Invalid Gamma Data struct version\n");
>> +return -EINVAL;
>> +}
>> +
>> +pipe = to_intel_crtc(crtc)->pipe;
>> +num_samples = gamma_data->palette_num_samples;
>> +length = num_samples * sizeof(struct drm_r32g32b32);
>> +
>> +if (num_samples
[PATCH v7 1/4] drm/layerscape: Add Freescale DCU DRM driver
A question and a nit follow.
On vr, 2015-07-10 at 19:17 +0800, Jianwei Wang wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +MODULE_ALIAS("platform:fsl-dcu-drm");
Question: this appears to be only useful if there's a corresponding
struct platform_device. That is, a platform_device with a "fsl-dcu-drm"
.name. It will fire off a "MODALIAS=platform:fsl-dcu-drm" uevent when
it's created.
I couldn't find this corresponding platform_device. Does it exist? Or is
this alias needed for some other reason?
> --- /dev/null
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> +#define DRIVER_NAME "fsl-dcu-drm"
Nit: I don't think DRIVER_NAME is actually used anywhere.
Thanks,
Paul Bolle
[PATCH] drm/atomic: fix null dereference
On Sat, Jul 11, 2015 at 1:24 PM, Sudip Mukherjee
wrote:
> We are checking the size of e->event but we were doing it when e is
> known to be NULL.
nak, this will leak event_space.. since it is a sizeof, it isn't
actually deref'ing e, but rather just using the static type info, so
it's ok (although perhaps funny looking)
BR,
-R
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/gpu/drm/drm_atomic.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index acebd16..51d3a85 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1311,7 +1311,6 @@ static struct drm_pending_vblank_event
> *create_vblank_event(
> e = kzalloc(sizeof *e, GFP_KERNEL);
> if (e == NULL) {
> spin_lock_irqsave(>event_lock, flags);
> - file_priv->event_space += sizeof e->event;
> spin_unlock_irqrestore(>event_lock, flags);
> goto out;
> }
> --
> 1.8.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] nul-terminate readlink result
readlink by itself does not guarantee that its result is properly nul-terminated. Setting the last byte of the buffer to '\0' fixes this issue. --- libkms/linux.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libkms/linux.c b/libkms/linux.c index 4d47148..667d37c 100644 --- a/libkms/linux.c +++ b/libkms/linux.c @@ -82,6 +82,7 @@ linux_name_from_sysfs(int fd, char **out) if (readlink(path, link, PATH_SIZE) < 0) return -EINVAL; + link[PATH_SIZE] = '\0'; /* link looks something like this: ../../../bus/pci/drivers/intel */ slash_name = strrchr(link, '/'); -- 2.4.5
[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 Dennis Schridde changed: What|Removed |Added Attachment #117050|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/c0d58897/attachment.html>
[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 Dennis Schridde changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=81896 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/255c900e/attachment.html>
[Bug 81896] GPU reset when running some "John the Ripper" (+ jumbo patch, from Git) OpenCL tests
https://bugs.freedesktop.org/show_bug.cgi?id=81896 Dennis Schridde changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=91305 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/f1b4dacc/attachment.html>
[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 --- Comment #7 from Dennis Schridde --- Please note that I have 2 GPUs (Redwood and Kaveri) and Mesa at version 10.6.1. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/f9857ebb/attachment.html>
[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 --- Comment #6 from Dennis Schridde --- Created attachment 117056 --> https://bugs.freedesktop.org/attachment.cgi?id=117056=edit emerge --info media-libs/mesa -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/5ce3cecf/attachment-0001.html>
[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 --- Comment #5 from Dennis Schridde --- Created attachment 117055 --> https://bugs.freedesktop.org/attachment.cgi?id=117055=edit lspci -v -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/8cb781ba/attachment.html>
[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 --- Comment #4 from Dennis Schridde --- Created attachment 117054 --> https://bugs.freedesktop.org/attachment.cgi?id=117054=edit Linux kernel config -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/6d5e0f1b/attachment.html>
[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 --- Comment #3 from Dennis Schridde --- Created attachment 117053 --> https://bugs.freedesktop.org/attachment.cgi?id=117053=edit Last lines of output from: john --test=0 --verbosity=5 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/3ab1dfc8/attachment.html>
[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 --- Comment #2 from Dennis Schridde --- Created attachment 117052 --> https://bugs.freedesktop.org/attachment.cgi?id=117052=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/fcc01e49/attachment.html>
[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 --- Comment #1 from Dennis Schridde --- Created attachment 117051 --> https://bugs.freedesktop.org/attachment.cgi?id=117051=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/2bfe2cc9/attachment.html>
[Bug 91305] When running JTR OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305
Bug ID: 91305
Summary: When running JTR OpenCL tests: radeon :01:00.0:
ring 0 stalled for more than ...msec
Product: Mesa
Version: 10.6
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel at lists.freedesktop.org
Reporter: devurandom at gmx.net
QA Contact: dri-devel at lists.freedesktop.org
Created attachment 117050
--> https://bugs.freedesktop.org/attachment.cgi?id=117050=edit
screenshot
I ran `john --test=0 --verbosity=5` from
JohnTheRipper at d8cb9ce98acd26bd917dff4cbb54bdc14b7133f9, which made X crash.
I was dropped to VT1, where the messages "radeon :01:00.0: ring 0 stalled
for more than ...msec" and "radeon :00:01.0: ring 3 stalled for more than
...msec" where flashing by. Afterwards messages of failed tests were logged
(typewrote from attached screenshot):
```
AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x
address=0x00041145c040 flags=0x0050]
[drm:cik_ring_test [radeon]] *ERROR* radeon: ring 1 test failed
(scratch(0x3010C)=0xCAFEDEAD)
[drm:cik_ring_test [radeon]] *ERROR* radeon: ring 2 test failed
(scratch(0x3010C)=0xCAFEDEAD)
[drm:cik_sdma_ring_test [radeon]] *ERROR* radeon: ring 4 test failed
(0xCAFEDEAD)
[drm:cik_resume [radeon]] *ERROR* cik startup failed on resume
radeon :00:01.0: ring 0 stalled for more than 10281msec
[drm:cik_ib_test [radeon]] *ERROR* radeon: fence wait failed (-35).
[drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX
ring (-35).
```
Since dmesg did not log these errors and journald is not accessible via
journalctl ATM ("Error was encountered while opening journal files: Invalid
argument"), I sadly cannot give you more accurate logs than the typewrote
screenshot.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/373d1a26/attachment.html>
[alsa-devel] [PATCH v2 02/12] device: property: find dependencies of a firmware node
On Friday, July 10, 2015 03:14:38 PM Tomeu Vizoso wrote:
> On 2 July 2015 at 02:02, Rafael J. Wysocki wrote:
> > On Wednesday, July 01, 2015 11:40:57 AM Tomeu Vizoso wrote:
> >> Adds API that allows callers to find out what other firmware nodes a
> >> node depends on.
> >>
> >> Implementors of bindings documentation can register callbacks that
> >> return the dependencies of a node.
> >>
> >> Dependency information can be used to change the order in which devices
> >> are probed, or to print a warning when a device node is going to be
> >> probed without all its dependencies fulfilled.
> >>
> >> Signed-off-by: Tomeu Vizoso
> >
> > I'd like to see a description of the new API in English in the changelog.
>
> Agreed.
>
> >> ---
> >>
> >> Changes in v2:
> >> - Allow bindings implementations register a function instead of using
> >> class callbacks, as not only subsystems implement firmware bindings.
> >>
> >> drivers/base/property.c | 91
> >>
> >> include/linux/fwnode.h | 5 +++
> >> include/linux/property.h | 12 +++
> >> 3 files changed, 108 insertions(+)
> >>
> >> diff --git a/drivers/base/property.c b/drivers/base/property.c
> >> index 8ead1ba..9d38ede 100644
> >> --- a/drivers/base/property.c
> >> +++ b/drivers/base/property.c
> >> @@ -19,7 +19,13 @@
> >> #include
> >> #include
> >>
> >
> > Please add a comment describing this structure. In particular, what it is
> > supposed to be used for and how it is supposed to be used.
>
> Ok.
>
> >> +struct dependency_parser {
> >> + struct list_head parser;
> >
> > I'd rather call this "list_node" or something like that.
>
> Ok.
>
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps);
> >> +};
> >> +
> >> static bool fwnode_match_enable = false;
> >> +static LIST_HEAD(dependency_parsers);
> >>
> >> /**
> >> * device_add_property_set - Add a collection of properties to a device
> >> object.
> >> @@ -553,6 +559,27 @@ bool device_dma_is_coherent(struct device *dev)
> >> EXPORT_SYMBOL_GPL(device_dma_is_coherent);
> >>
> >> /**
> >> + * fwnode_add_dependency - add firmware node to the passed dependency list
> >> + * @fwnode: Firmware node to add to dependency list
> >> + * @list: Dependency list to add the fwnode to
> >> + */
> >> +void fwnode_add_dependency(struct fwnode_handle *fwnode,
> >> +struct list_head *list)
> >> +{
> >> + struct fwnode_dependency *dep;
> >> +
> >> + dep = kzalloc(sizeof(*dep), GFP_KERNEL);
> >> + if (!dep)
> >> + return;
> >> +
> >> + INIT_LIST_HEAD(>dependency);
> >> + dep->fwnode = fwnode;
> >> +
> >> + list_add_tail(>dependency, list);
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_add_dependency);
> >> +
> >> +/**
> >> * fwnode_get_parent - return the parent node of a device node
> >> * @fwnode: Device node to find the parent node of
> >> */
> >> @@ -600,6 +627,70 @@ bool fwnode_is_compatible(struct fwnode_handle
> >> *fwnode, const char *compatible)
> >> EXPORT_SYMBOL_GPL(fwnode_is_compatible);
> >>
> >> /**
> >> + * fwnode_add_dependency_parser - register dependency parser
> >> + * @func: Function that will be called to find out dependencies of a node
> >> + *
> >> + * Registers a callback that will be called when collecting the
> >> dependencies
> >> + * of a firmware node. The callback should inspect the properties of the
> >> node
> >> + * and call fwnode_add_dependency() for each dependency it recognizes,
> >> from
> >> + * the bindings documentation.
> >> + */
> >> +void fwnode_add_dependency_parser(
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps))
> >> +{
> >> + struct dependency_parser *parser;
> >> +
> >> + parser = kzalloc(sizeof(*parser), GFP_KERNEL);
> >> + if (!parser)
> >> + return;
> >> +
> >> + INIT_LIST_HEAD(>parser);
> >> + parser->func = func;
> >> +
> >> + list_add_tail(>parser, _parsers);
> >
> > We're modifying a global list here. Any locking needed? RCU? Whatever?
>
> Oops.
>
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_add_dependency_parser);
> >> +
> >> +/**
> >> + * fwnode_remove_dependency_parser - unregister dependency parser
> >> + * @func: Function that was to be called to find out dependencies of a
> >> node
> >> + */
> >> +void fwnode_remove_dependency_parser(
> >> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps))
> >> +{
> >> + struct dependency_parser *parser, *tmp;
> >> +
> >> + list_for_each_entry_safe(parser, tmp, _parsers, parser) {
> >> + if (parser->func == func) {
> >> + list_del(>parser);
> >> + kfree(parser);
> >> + return;
> >> + }
> >> + }
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_remove_dependency_parser);
> >> +
> >> +/**
> >> + * fwnode_get_dependencies - find out what dependencies a firmware node
> >> has
> >> + * @fwnode: firmware node
[Bug 91302] radeon.audio=1 causes weird issues with 7950
https://bugs.freedesktop.org/show_bug.cgi?id=91302 Bug ID: 91302 Summary: radeon.audio=1 causes weird issues with 7950 Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: contrib at kliznoe.com When I have radeon.audio set to 1, My displayport audio output is deeper then normal and my hdmi screen becomes blurry and has a pink line to the left of it. This doesn't happen when radeon.audio is set to 0 or in Windows. OS : Arch Linux with Gnome3 and xf86-video-ati-git from the AUR -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/0005189c/attachment-0001.html>
[Bug 91294] [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=91294 Tobias Droste changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=76490 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/91694c0e/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 Tobias Droste changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=91294 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/b3a214c5/attachment.html>
[Bug 91294] [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=91294 --- Comment #5 from Elia Argentieri --- Created attachment 117048 --> https://bugs.freedesktop.org/attachment.cgi?id=117048=edit Fix by adding a line to si_dpm_quirk_list Adding this line made my card work with DPM enabled, but I'm not sure about mclk value. This card is supposed to have a 5600 MHz video memory according to MSI's site. However Catalyst reports a frequency of 1400 MHz. Tomorrow, I'll play with this values. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150711/44a599ee/attachment.html>
[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)
https://bugzilla.kernel.org/show_bug.cgi?id=78221 Linux Tester changed: What|Removed |Added CC||linux.tester at sharklasers.co ||m --- Comment #24 from Linux Tester --- After some updates to MESA and kernel this bug no longer happens at all - 2D now rock solid for me on R9 270 and I can run even most troublesome workloads for weeks without any issues. While I failed to pinpoint what exactly has fixed bug, thanks anyway. I think it is now safe to close this bug as fixed. I bet you've got dozens of other GPU lockups to chew on, so I'm glad to inform you at least one nasty thing has been nailed down. (it's me, original bug reporter who has forgot password on both original mailbox and bugzilla account, dammit) -- You are receiving this mail because: You are watching the assignee of the bug.
