[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&action=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 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 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 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&action=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>
[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&action=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 --- Comment #2 from Dennis Schridde --- Created attachment 117052 --> https://bugs.freedesktop.org/attachment.cgi?id=117052&action=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 #3 from Dennis Schridde --- Created attachment 117053 --> https://bugs.freedesktop.org/attachment.cgi?id=117053&action=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 #4 from Dennis Schridde --- Created attachment 117054 --> https://bugs.freedesktop.org/attachment.cgi?id=117054&action=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 #5 from Dennis Schridde --- Created attachment 117055 --> https://bugs.freedesktop.org/attachment.cgi?id=117055&action=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 #6 from Dennis Schridde --- Created attachment 117056 --> https://bugs.freedesktop.org/attachment.cgi?id=117056&action=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 #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 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 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>
[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 = &dev->mode_config;
>> +
>> +if (property == config->prop_palette_after_ctm)
>> +return intel_color_manager_set_gamma(dev, &crtc->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 = &dev->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
[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
[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
[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>
[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&action=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>
[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(&dev->event_lock, flags);
- file_priv->event_space += sizeof e->event;
spin_unlock_irqrestore(&dev->event_lock, flags);
goto out;
}
--
1.8.1.2
[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(&dev->event_lock, flags);
> - file_priv->event_space += sizeof e->event;
> spin_unlock_irqrestore(&dev->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
[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 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>
[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
[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(&dep->dependency);
> >> + dep->fwnode = fwnode;
> >> +
> >> + list_add_tail(&dep->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);
> >> + parser->func = func;
> >> +
> >> + list_add_tail(&parser->parser, &dependency_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, &dependency_parsers, parser) {
> >> + if (parser->func == func) {
> >> + list_del(&parser->parser);
> >> + kfree(parser);
> >> + return;
> >> + }
> >> + }
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_remove_dependency_parser);
> >> +
> >> +/**
> >> + * fwnode_get_dependencies - find out what dependencies a
