[git pull] drm fixes for rc4 or 5
On 29 August 2016 at 07:35, Linus Torvalds wrote: > On Sun, Aug 28, 2016 at 2:31 PM, Linus Torvalds > wrote: >> >> Anyway, the real problem was that this was in my spam-box. Which I've >> learnt to check religiously, so I noticed almost immediately. > > Btw, on a totally unrelated issue: you make thes pull points tags > (good), but they are just plain simple tags with no message and in > particular no pgp signature. > > I guess freedesktop.org is fairly well managed, but still - would you > mind using signed tags? It's not *that* much extra work: use "git tag > -s". You can write the description into the tag message, or you can > just make the message be something useless and continue to write the > description in the email itself, but now it would have that nice > cryptographic signature showing it's really you.. See when I failed to use capital letters, you knew it was definitely me, no need for crypto. The main reason I've avoided signed tags is I currently don't have my pgp key sitting on the machine where I build and generate, because I'm lazy, and I don't usually propogate my pgp key to other machines like my other laptops when I have to do a pull request from the shower or wherever. I'll try and integrate signed tags a bit better. I think it's probably spam because of sending @linux.ie from a server that isn't definitely a linux.ie email server, I'll probably just move to using gmail for sending pull requests, though the UI kinda sucks for pasting in things. Dave.
[PATCH] drm/amdgpu: Add amdkfd softdep
On 26/08/16 06:16 PM, Michal Marek wrote:
> On 2016-08-26 04:20, Michel Dänzer wrote:
>> On 26/08/16 02:10 AM, Michal Marek wrote:
>>> amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that
>>> userspace knows that amdgpu needs amdkfd in the initrd.
>>>
>>> Reported-and-tested-by: Martin Jambor
>>> Signed-off-by: Michal Marek
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> index 9aa533cf4ad1..9c469cd311ca 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> @@ -633,3 +633,4 @@ module_exit(amdgpu_exit);
>>> MODULE_AUTHOR(DRIVER_AUTHOR);
>>> MODULE_DESCRIPTION(DRIVER_DESC);
>>> MODULE_LICENSE("GPL and additional rights");
>>> +MODULE_SOFTDEP("pre: amdkfd");
>>
>> Will this work if amdkfd isn't built (CONFIG_HSA_AMD=n)?
>
> It's a soft dependency, so it will be silently ignored. /sbin/modprobe
> --show-depends amdgpu will only list amdgpu.ko and its hard depedencies.
Thanks for the clarification.
The radeon driver probably needs this as well?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
[PATCH] modetest: Adding amdgpu to module list
On 26/08/16 11:52 PM, Alex Deucher wrote:
> From: satsahu
>
> Signed-off-by: Alex Deucher
> ---
> tests/util/kms.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/util/kms.c b/tests/util/kms.c
> index 650b23b..c20134e 100644
> --- a/tests/util/kms.c
> +++ b/tests/util/kms.c
> @@ -127,6 +127,7 @@ const char *util_lookup_connector_type_name(unsigned int
> type)
>
> static const char * const modules[] = {
> "i915",
> + "amdgpu",
> "radeon",
> "nouveau",
> "vmwgfx",
>
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
"Fixes" for page flipping under PRIME on AMD & nouveau
On 27/08/16 05:07 AM, Mario Kleiner wrote: > On 08/18/2016 04:32 AM, Michel Dänzer wrote: >> On 18/08/16 08:51 AM, Mario Kleiner wrote: >>> >>> and the offload gpu imports those and renders into them. That saves >>> one extra copy, so should be somewhat more efficient. >> >> Using two shared buffers actually isn't as efficient as possible wrt >> inter-GPU bandwidth. > > Out of interest, why? You'd have only one detiling copy VRAM -> RAM? Yeah, that's basically it. With a single shared buffer, only the parts which have changed since last time need to be copied between the GPUs; the slave GPU can copy the other changed parts from its other local scanout pixmap (with TearFree enabled; note that this isn't quite implemented yet in our drivers for slave output, but I'm planning to do it soon). With two shared pixmaps, some changed parts have to be copied between GPUs several times. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
"Fixes" for page flipping under PRIME on AMD & nouveau
On 27/08/16 04:57 AM, Mario Kleiner wrote: > On 08/18/2016 04:23 AM, Michel Dänzer wrote: >> On 18/08/16 01:12 AM, Mario Kleiner wrote: > > One thing that confuses me so far is that visual results and measurment > suggest it works nicely, properly serializing the rendering/detiling > blit and the pageflip. But when i ftrace the Intel drivers > reservation_object_wait_timeout_rcu() call where it normally waits for > the dmabuf fence to complete then i never see it blocking for more than > a few dozen microseconds, and i couldn't find any other place where it > blocks on detiling blit completion yet. Iow. it seems to work correctly > in practice, but i don't know where it actually blocks. It actually doesn't work correctly in all cases yet: https://bugs.freedesktop.org/show_bug.cgi?id=95472 >>> Turns out that prime + page flipping currently doesn't work >>> on nouveau and amd. The first offload rendered images from >>> the imported dmabufs show up properly, but then the display >>> is stuck alternating between the first two or three rendered >>> frames. >>> >>> The problem is that during the pageflip ioctl we pin the >>> dmabuf into VRAM in preparation for scanout, then unpin it >>> when we are done with it at next flip, but the buffer stays >>> in the VRAM memory domain. >> >> Sounds like you found a bug here: BOs which are being shared between >> different GPUs should always be pinned to GTT, moving them to VRAM (and >> consequently the page flip) should fail. > > Seems so, although i hoped i was fixing a bug, not exploiting a > loophole. In practice i haven't observed trouble with the hack so far. I > havent't looked deeply enough into how the dma api below dmabuf > operates, so this is just guesswork, but i suspect the reason that this > doesn't blow up in an obvious way is that if the render offload gpu > exports the dmabuf then the pages get pinned/locked into system RAM, so > the pages can't move around or get paged out to swap, as long as the > dmabuf stays exported. When the dmabuf importing AMD or nouveau display > gpu then moves the bo from GTT to VRAM (or pseudo-moves it back with my > hack) all that changes is some pin refcount for the RAM pages, but the > refcount always stays non-zero and system RAM isn't freed or moved > around during the session. I just wonder if this bug couldn't somehow be > turned into a proper feature? I'm afraid not; BOs which are being shared between devices are supposed to be pinned to GTT, and pinned BOs aren't supposed to move. However, something similar to your patches could be done in the DDX drivers, using the dedicated scanout pixmap mechanism. >> The latest versions of DCE support scanning out from GTT, so that might >> be a good solution at least for Carrizo and newer APUs, not sure it >> makes sense for dGPUs though. > > That would be good to have. But that means DCE-11 or later only? What is > the constraint on older parts, does it need contiguous memory? Presumably. Anyway, from Christian's description it sounds like it'll be tricky to get this working even with current APUs. :( -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH v3 1/3] drm/bridge: introduce bridge detaching mechanism
On 08/25/2016 05:46 PM, Daniel Vetter wrote:
> On Thu, Aug 25, 2016 at 11:04:32AM +0200, Andrea Merello wrote:
>> Up to now, once a bridge has been attached to a DRM device, it cannot
>> be undone.
>>
>> In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
>> because the bridge would remain bound to the first (dead) driver instance.
>>
>> This patch fixes this by introducing drm_encoder_detach() and a ->detach
>> callback in drm_bridge_funcs for the bridge to be notified about detaches.
>>
>> It's DRM/KMS driver responsibility to call drm_encoder_detach().
>>
>> While adding the bridge detach callback, with its kerneldoc, I also added
>> kerneldoc for attach callback.
>>
>> Few other kerneldocs fixes around there are included.
>>
>> Suggested-by: Daniel Vetter
>> Suggested-by: Lucas Stach
>> Signed-off-by: Andrea Merello
>> Cc: Archit Taneja
>> Cc: David Airlie
>> Cc: Daniel Vetter
>> Cc: Lucas Stach
>
> Reviewed-by: Daniel Vetter
>
> As discussed on the last round, I'll let Archit apply all 3 to drm-misc,
> so he can check them out too.
Pushed to drm-misc.
Thanks,
Archit
> -Daniel
>> ---
>> drivers/gpu/drm/drm_bridge.c | 29 +++--
>> include/drm/drm_crtc.h | 26 +-
>> 2 files changed, 52 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 2555430..4840466 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -98,11 +98,11 @@ EXPORT_SYMBOL(drm_bridge_remove);
>>* @dev: DRM device
>>* @bridge: bridge control structure
>>*
>> - * called by a kms driver to link one of our encoder/bridge to the given
>> + * Called by a kms driver to link one of our encoder/bridge to the given
>>* bridge.
>>*
>>* Note that setting up links between the bridge and our encoder/bridge
>> - * objects needs to be handled by the kms driver itself
>> + * objects needs to be handled by the kms driver itself.
>>*
>>* RETURNS:
>>* Zero on success, error code on failure
>> @@ -125,6 +125,31 @@ int drm_bridge_attach(struct drm_device *dev, struct
>> drm_bridge *bridge)
>> EXPORT_SYMBOL(drm_bridge_attach);
>>
>> /**
>> + * drm_bridge_detach - deassociate given bridge from its DRM device
>> + *
>> + * @bridge: bridge control structure
>> + *
>> + * Called by a kms driver to unlink the given bridge from its DRM device.
>> + *
>> + * Note that tearing down links between the bridge and our encoder/bridge
>> + * objects needs to be handled by the kms driver itself.
>> + */
>> +void drm_bridge_detach(struct drm_bridge *bridge)
>> +{
>> +if (WARN_ON(!bridge))
>> +return;
>> +
>> +if (WARN_ON(!bridge->dev))
>> +return;
>> +
>> +if (bridge->funcs->detach)
>> +bridge->funcs->detach(bridge);
>> +
>> +bridge->dev = NULL;
>> +}
>> +EXPORT_SYMBOL(drm_bridge_detach);
>> +
>> +/**
>>* DOC: bridge callbacks
>>*
>>* The &drm_bridge_funcs ops are populated by the bridge driver. The DRM
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 3fa0275..bb214a1 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -1118,12 +1118,33 @@ struct drm_plane {
>>
>> /**
>>* struct drm_bridge_funcs - drm_bridge control functions
>> - * @attach: Called during drm_bridge_attach
>>*/
>> struct drm_bridge_funcs {
>> +/**
>> + * @attach:
>> + *
>> + * This callback is invoked whenever our bridge is being attached to a
>> + * &drm_encoder.
>> + *
>> + * The attach callback is optional.
>> + *
>> + * RETURNS:
>> + *
>> + * Zero on success, error code on failure.
>> + */
>> int (*attach)(struct drm_bridge *bridge);
>>
>> /**
>> + * @detach:
>> + *
>> + * This callback is invoked whenever our bridge is being detached from a
>> + * &drm_encoder.
>> + *
>> + * The detach callback is optional.
>> + */
>> +void (*detach)(struct drm_bridge *bridge);
>> +
>> +/**
>> * @mode_fixup:
>> *
>> * This callback is used to validate and adjust a mode. The paramater
>> @@ -1137,6 +1158,8 @@ struct drm_bridge_funcs {
>> * this function passes all other callbacks must succeed for this
>> * configuration.
>> *
>> + * The mode_fixup callback is optional.
>> + *
>> * NOTE:
>> *
>> * This function is called in the check phase of atomic modesets, which
>> @@ -2426,6 +2449,7 @@ extern int drm_bridge_add(struct drm_bridge *bridge);
>> extern void drm_bridge_remove(struct drm_bridge *bridge);
>> extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
>> extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge
>> *bridge);
>> +extern void drm_bridge_detach(struct drm_bridge *bridge);
>>
>> bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
>> const str
[PATCH v3 2/3] drm: simple_kms_helper: make connector optional at init time
On 08/25/2016 02:34 PM, Andrea Merello wrote:
> drm_simple_display_pipe_init() pretends to attach a connector
> to the display pipe.
>
> In case a drm bridge has to be used, then it's the bridge that
> takes care of connectors.
>
> This patch makes the connector parameter optional for
> drm_simple_display_pipe_init(), so that a drm bridge could
> handle connector by itself later.
>
Pushed to drm-misc.
Thanks,
Archit
> Signed-off-by: Andrea Merello
> Reviewed-by: Daniel Vetter
> Cc: David Airlie
> Cc: Noralf Trønnes
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_simple_kms_helper.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 4476310..3301e4a 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -146,10 +146,15 @@ static const struct drm_plane_funcs
> drm_simple_kms_plane_funcs = {
>* @funcs: callbacks for the display pipe (optional)
>* @formats: array of supported formats (DRM_FORMAT\_\*)
>* @format_count: number of elements in @formats
> - * @connector: connector to attach and register
> + * @connector: connector to attach and register (optional)
>*
>* Sets up a display pipeline which consist of a really simple
> - * plane-crtc-encoder pipe coupled with the provided connector.
> + * plane-crtc-encoder pipe.
> + *
> + * If a connector is supplied, the pipe will be coupled with the provided
> + * connector. You may supply a NULL connector when using drm bridges, that
> + * handle connectors themselves (see
> drm_simple_display_pipe_attach_bridge()).
> + *
>* Teardown of a simple display pipe is all handled automatically by the drm
>* core through calling drm_mode_config_cleanup(). Drivers afterwards need
> to
>* release the memory for the structure themselves.
> @@ -188,7 +193,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
> encoder->possible_crtcs = 1 << drm_crtc_index(crtc);
> ret = drm_encoder_init(dev, encoder, &drm_simple_kms_encoder_funcs,
> DRM_MODE_ENCODER_NONE, NULL);
> - if (ret)
> + if (ret || !connector)
> return ret;
>
> return drm_mode_connector_attach_encoder(connector, encoder);
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3 3/3] drm: simple_kms_helper: add support for bridges
On 08/25/2016 02:34 PM, Andrea Merello wrote:
> Introduce drm_simple_display_pipe_attach_bridge() and
> drm_simple_display_pipe_detach_bridge() in order to make it possible to use
> drm encoders with the simple display pipes managed by simple_kms_helpers
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Andrea Merello
> Reviewed-by: Daniel Vetter
Pushed to drm-misc.
Thanks,
Archit
> Cc: Noralf Trønnes
> Cc: Daniel Vetter
> Cc: David Airlie
> ---
> drivers/gpu/drm/drm_simple_kms_helper.c | 40
> +
> include/drm/drm_simple_kms_helper.h | 5 +
> 2 files changed, 45 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 3301e4a..8e9858b 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -140,6 +140,46 @@ static const struct drm_plane_funcs
> drm_simple_kms_plane_funcs = {
> };
>
> /**
> + * drm_simple_display_pipe_attach_bridge - Attach a bridge to the display
> pipe
> + * @pipe: simple display pipe object
> + * @bridge: bridge to attach
> + *
> + * Makes it possible to still use the drm_simple_display_pipe helpers when
> + * a DRM bridge has to be used.
> + *
> + * Note that you probably want to initialize the pipe by passing a NULL
> + * connector to drm_simple_display_pipe_init().
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe
> *pipe,
> + struct drm_bridge *bridge)
> +{
> + bridge->encoder = &pipe->encoder;
> + pipe->encoder.bridge = bridge;
> + return drm_bridge_attach(pipe->encoder.dev, bridge);
> +}
> +EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge);
> +
> +/**
> + * drm_simple_display_pipe_detach_bridge - Detach the bridge from the
> display pipe
> + * @pipe: simple display pipe object
> + *
> + * Detaches the drm bridge previously attached with
> + * drm_simple_display_pipe_attach_bridge()
> + */
> +void drm_simple_display_pipe_detach_bridge(struct drm_simple_display_pipe
> *pipe)
> +{
> + if (WARN_ON(!pipe->encoder.bridge))
> + return;
> +
> + drm_bridge_detach(pipe->encoder.bridge);
> + pipe->encoder.bridge = NULL;
> +}
> +EXPORT_SYMBOL(drm_simple_display_pipe_detach_bridge);
> +
> +/**
>* drm_simple_display_pipe_init - Initialize a simple display pipeline
>* @dev: DRM device
>* @pipe: simple display pipe object to initialize
> diff --git a/include/drm/drm_simple_kms_helper.h
> b/include/drm/drm_simple_kms_helper.h
> index 2690397..5245d1f 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -85,6 +85,11 @@ struct drm_simple_display_pipe {
> const struct drm_simple_display_pipe_funcs *funcs;
> };
>
> +int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe
> *pipe,
> + struct drm_bridge *bridge);
> +
> +void drm_simple_display_pipe_detach_bridge(struct drm_simple_display_pipe
> *pipe);
> +
> int drm_simple_display_pipe_init(struct drm_device *dev,
> struct drm_simple_display_pipe *pipe,
> const struct drm_simple_display_pipe_funcs *funcs,
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[Bug 97524] Invalid sampler settings cause full GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=97524 Bug ID: 97524 Summary: Invalid sampler settings cause full GPU reset Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: dark_sylinc at yahoo.com.ar QA Contact: dri-devel at lists.freedesktop.org Created attachment 126091 --> https://bugs.freedesktop.org/attachment.cgi?id=126091&action=edit Bug repro Running invalid the following GL settings hangs Mesa pretty badly. Sometimes it says stuck on ring(0)/(3), other times it just hangs; GPU tries to reset but does a really poor job (at least I can blindly go to tty1 via Ctrl+Alt+F1 then reboot via Ctrl+Alt+Supr). Attachment provided to repro the bug. What is causing it: Vertex Shader must use samplerBuffer on binding point 0. Pixel Shader must use samplerCube on binding point 0. Bind a TBO to binding point 0. What happens: Near full system hang, it becomes really unstable. System can be soft-rebooted but that's it. What should happen: All other GPU drivers I tested with handle this gracefully by raising a GL_INVALID_OPERATION error and continuing rendering the rest normally. Version tested: Latest git 22cec6dc5e5a3060bc87f4a92871b4f6eef04632 I'm assigning a low priority since this GL setting combination is invalid to begin with and I want to believe software isn't shipped like this (though considering other GPU drivers allow to ignore the problem, I wouldn't be fully surprised if there is faulty software out there...); though I believe the system shouldn't hang because of this. GL_VERSION = 4.3.0.0 GL_VENDOR = X.Org GL_RENDERER = Gallium 0.4 on AMD CAPE VERDE (DRM 2.45.0 / 4.7.0-040700-generic, LLVM 3.9.0) uname -r 4.7.0-040700-generic Cheers -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/123304cd/attachment.html>
imx-drm: Possible regression after update to atomic
Hi Thorsten,
On Sun, Aug 28, 2016 at 6:17 PM, Thorsten Leemhuis
wrote:
> Lo! Dave, below report made it to the list of regression for 4.8, but
> afaics nothing happened after the initial report. Was it discussed (and
> maybe even fixed?) elsewhere? Or is there some reason why it shouldn't
> be on the list of regressions at all?
We've got a patch set[1] to fix this.
[1] http://www.spinics.net/lists/dri-devel/msg116491.html
Regards,
Liu Ying
>
> Ciao, Thorsten
>
> On 13.08.2016 14:37, Peter Senna Tschudin wrote:
>>
>> d7868cb7ac58640e9c0383205ba31bd6a985cc6f is the last commit that works for
>> me. I'm experiencing black screen after Weston starts in two different i.MX
>> based devices:
>>
>> - i.MX6 -> arch/arm/boot/dts/imx6q-b850v3.dts
>> - i.MX53 based device
>>
>> Weston starts, but nothing is shown on screen. fb works fine. Disabling fb
>> on Kconfig or simply commenting out drm_fbdev_cma_init() solves the black
>> screen issue.
>>
>> The tests that are causing the black screen:
>>
>> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
>> b/drivers/gpu/drm/imx/ipuv3-plane.c
>> index 4ad67d0..52dc1b7 100644
>> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
>> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
>> @@ -325,7 +325,7 @@ static int ipu_plane_atomic_check(struct drm_plane
>> *plane,
>> if (old_fb && (state->src_w != old_state->src_w ||
>> state->src_h != old_state->src_h ||
>> fb->pixel_format != old_fb->pixel_format))
>> - return -EINVAL;
>>
>> eba = drm_plane_state_to_eba(state);
>>
>> @@ -336,7 +336,7 @@ static int ipu_plane_atomic_check(struct drm_plane
>> *plane,
>> return -EINVAL;
>>
>> if (old_fb && fb->pitches[0] != old_fb->pitches[0])
>> - return -EINVAL;
>>
>> switch (fb->pixel_format) {
>> case DRM_FORMAT_YUV420:
>> @@ -372,7 +372,7 @@ static int ipu_plane_atomic_check(struct drm_plane
>> *plane,
>> return -EINVAL;
>>
>> if (old_fb && old_fb->pitches[1] != fb->pitches[1])
>> - return -EINVAL;
>> }
>>
>> I tried to replace the return -EINVAL by crtc_state->mode_changed = true
>> with no positive results.
>>
>> I'm trying to understand what is the difference with and without fb, but I
>> have no conclusions yet.
>>
>> Hints on what could be the cause here?
>>
>> Thank you,
>>
>> Peter
>>
>> P.S. This is what I get after replacing the return -EINVAL(the mode is
>> correct): https://goo.gl/photos/1eRdcco9GpszgvzM8
drm: WARNING in drm_irq_by_busid
On Sun, Aug 28, 2016 at 01:30:04PM +0200, Dmitry Vyukov wrote: > Hello, > > I've got the following WARNING while running syzkaller fuzzer: This should be fixed in linux-next, can you pls confirm? Also I'm somewhat suprised that syzkaller can't reproduce this reliably, at least in the latest code the WARNING happens before anything complicated (which would be hard to guess correctly for syzkaller) is checked. -Daniel > > [ cut here ] > WARNING: CPU: 1 PID: 16092 at drivers/gpu/drm/drm_pci.c:182 > drm_irq_by_busid+0x3c0/0x4a0 > Kernel panic - not syncing: panic_on_warn set ... > CPU: 1 PID: 16092 Comm: syz-executor Not tainted 4.8.0-rc3+ #33 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > 884b8280 880032c07b00 82d1b239 0178 > fbfff1097050 86e8eec0 880032c07bd8 873a2c00 > dc00 0009 880032c07bc8 816ab4e3 > Call Trace: > [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:552 > [] drm_irq_by_busid+0x3c0/0x4a0 > drivers/gpu/drm/drm_pci.c:182 > [] drm_ioctl+0x7bc/0xc60 drivers/gpu/drm/drm_ioctl.c:724 > [< inline >] vfs_ioctl fs/ioctl.c:43 > [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675 > [< inline >] SYSC_ioctl fs/ioctl.c:690 > [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681 > [] entry_SYSCALL_64_fastpath+0x23/0xc1 > arch/x86/entry/entry_64.S:207 > > Unfortunately it's not reproducible. Probably fuzzer can't guess the > right bus id (there is no simple way to extract correct bus id). But > it happens regularly. > > On commit 61c04572de404e52a655a36752e696bbcb483cf5 (Auh 25). > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
dri: WARNING in idr_remove
On Sun, Aug 28, 2016 at 04:32:55PM +0200, Dmitry Vyukov wrote:
> Hello,
>
> The following program causes a WARNING in idr_remove:
Again under the assumption that you're running this with the vgem driver:
linux-next has it fixed.
-Daniel
>
> [ cut here ]
> WARNING: CPU: 3 PID: 26766 at lib/idr.c:505
> idr_remove called for id=1 which is not allocated.
> CPU: 3 PID: 26766 Comm: syz-executor Not tainted 4.8.0-rc3+ #33
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> 884b8280 8800634878d8 82d1b239 01fc
> fbfff1097050 86e8eec0 8800634879b0 8723b400
> dc00 0009 8800634879a0 816ab4e3
> Call Trace:
> [] warn_slowpath_fmt+0xac/0xd0 kernel/panic.c:532
> [< inline >] idr_remove_warning lib/idr.c:505
> [] idr_remove+0x617/0x830 lib/idr.c:559
> [] drm_legacy_ctxbitmap_free+0x9d/0xd0
> drivers/gpu/drm/drm_context.c:61
> [] drm_legacy_rmctx+0x30e/0x410
> drivers/gpu/drm/drm_context.c:496
> [] drm_ioctl+0x7bc/0xc60 drivers/gpu/drm/drm_ioctl.c:724
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
> [] do_syscall_64+0x1df/0x640 arch/x86/entry/common.c:288
> [] entry_SYSCALL64_slow_path+0x25/0x25
> arch/x86/entry/entry_64.S:248
>
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include
> #include
> #include
> #include
>
> int main()
> {
> syscall(__NR_mmap, 0x2000ul, 0xc000ul, 0x3ul,
> 0x32ul, -1, 0x0ul, 0, 0, 0);
> int fd = open("/dev/dri/card0", 0x101102ul, 0);
> *(uint32_t*)0x2000b000 = (uint32_t)0x2;
> *(uint64_t*)0x2000b008 = (uint64_t)0x2000b000;
> syscall(__NR_ioctl, fd, 0xc0106426ul, 0x2000b000ul);
> int res = *(uint32_t*)0x2000b000;
> *(uint32_t*)0x2000bff8 = res;
> *(uint32_t*)0x2000bffc = (uint32_t)0x2;
> syscall(__NR_ioctl, fd, 0xc0086421ul, 0x2000bff8ul);
> return 0;
> }
>
> On commit 61c04572de404e52a655a36752e696bbcb483cf5 (Aug 25).
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drm: WARNING in ioremap_wc
On Sun, Aug 28, 2016 at 07:36:59PM +0200, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers WARNING in ioremap_wc:
Yup, that should also be fixed in linux-next. Probably better to not
report more for 4.8-rc kernels for now ;-)
If you have some time to test, you need to cherry pick the following two
patches I think:
fa5386459f06 ("drm: Used DRM_LEGACY for all legacy functions")
3cbf6a5deb2f ("drm: Mark up legacy/dri1 drivers with DRM_LEGACY")
If that's confirmed we can cherry-pick them over to -fixes.
-Daniel
>
> [ cut here ]
> LoadPin: kernel-module denied obj="/memfd: (deleted)" pid=12061
> cmdline="/tmp/syz-executor"
> WARNING: CPU: 1 PID: 12056 at arch/x86/mm/ioremap.c:121[< none
> >] __ioremap_caller+0x348/0x6b0 arch/x86/mm/ioremap.c:120
> LoadPin: kernel-module denied obj="/memfd: (deleted)" pid=12063
> cmdline="/tmp/syz-executor"
> ioremap on RAM at 0x20068000 - 0x20068fff
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 12056 Comm: syz-executor Not tainted 4.8.0-rc3+ #32
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> 884b8280 8800295777f0 82d1b239 00bd6000
> fbfff1097050 86e8eec0 8800295778c8 86e7ad00
> dc00 0009 8800295778b8 816ab4e3
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [] dump_stack+0x12e/0x185 lib/dump_stack.c:51
> [] panic+0x1e4/0x3ef kernel/panic.c:153
> [] __warn+0x1c4/0x1e0 kernel/panic.c:509
> [] warn_slowpath_fmt+0xac/0xd0 kernel/panic.c:532
> [] __ioremap_caller+0x348/0x6b0 arch/x86/mm/ioremap.c:120
> [] ioremap_wc+0x26/0x30 arch/x86/mm/ioremap.c:290
> [] drm_addmap_core+0xf1e/0x16c0
> drivers/gpu/drm/drm_bufs.c:213
> [] drm_legacy_addmap_ioctl+0x1ca/0x340
> drivers/gpu/drm/drm_bufs.c:403
> [] drm_ioctl+0x7bc/0xc60 drivers/gpu/drm/drm_ioctl.c:724
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
> [] do_syscall_64+0x1df/0x640 arch/x86/entry/common.c:288
> [] entry_SYSCALL64_slow_path+0x25/0x25
> arch/x86/entry/entry_64.S:248
>
> On commit 61c04572de404e52a655a36752e696bbcb483cf5 (Aug 25).
>
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #ifndef __NR_syz_open_pts
> #define __NR_syz_open_pts 102
> #endif
> #ifndef __NR_mmap
> #define __NR_mmap 9
> #endif
> #ifndef __NR_syz_open_dev
> #define __NR_syz_open_dev 101
> #endif
> #ifndef __NR_ioctl
> #define __NR_ioctl 16
> #endif
> #ifndef __NR_syz_fuse_mount
> #define __NR_syz_fuse_mount 103
> #endif
> #ifndef __NR_syz_fuseblk_mount
> #define __NR_syz_fuseblk_mount 104
> #endif
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> __thread int skip_segv;
> __thread jmp_buf segv_env;
>
> static void segv_handler(int sig, siginfo_t* info, void* uctx)
> {
> if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
> _longjmp(segv_env, 1);
> exit(sig);
> }
>
> static void install_segv_handler()
> {
> struct sigaction sa;
> memset(&sa, 0, sizeof(sa));
> sa.sa_sigaction = segv_handler;
> sa.sa_flags = SA_NODEFER | SA_SIGINFO;
> sigaction(SIGSEGV, &sa, NULL);
> sigaction(SIGBUS, &sa, NULL);
> }
>
> #define NONFAILING(...)\
> {\
> __atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
> if (_setjmp(segv_env) == 0) { \
> __VA_ARGS__; \
> } \
> __atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
> }
>
> static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
> {
> if (a0 == 0xc || a0 == 0xb) {
> char buf[128];
> sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block",
> (uint8_t)a1, (uint8_t)a2);
> return open(buf, O_RDWR, 0);
> } else {
> char buf[1024];
> char* hash;
> strncpy(buf, (char*)a0, sizeof(buf));
> buf[sizeof(buf) - 1] = 0;
> while ((hash = strchr(buf, '#'))) {
> *hash = '0' + (char)(a1 % 10);
> a1 /= 10;
> }
> return open(buf, a2, 0);
> }
> }
>
> static uintptr_t syz_open_pts(uintptr_t a0, uintptr_t a1)
> {
> int ptyno = 0;
> if (ioctl(a0, TIOCGPTN, &ptyno))
> return -1;
> char buf[128];
> sprintf(buf, "/dev/pts/%d", ptyno);
> return open(buf, a1, 0);
> }
>
> static uintptr_t syz_fuse_mount(uintptr_t a0, uintptr_t a1,
> uintptr_t a2, uintptr_t a3,
> uintptr_t a4, uintptr_t a5)
> {
> u
[PATCH 01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy check and potentially blocking wait. Signed-off-by: Chris Wilson Cc: Alex Deucher Cc: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c index 88fbed2389c0..a3e6f883ac2c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -407,10 +407,8 @@ int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data, return -ENOENT; } robj = gem_to_amdgpu_bo(gobj); - if (timeout == 0) - ret = reservation_object_test_signaled_rcu(robj->tbo.resv, true); - else - ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, timeout); + ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, + timeout); /* ret == 0 means not signaled, * ret > 0 means signaled -- 2.9.3
[PATCH 02/11] drm/etnaviv: Remove manual call to reservation_object_test_signaled_rcu before wait
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 5ce3603e6eac..9ffca2478e02 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -409,20 +409,16 @@ int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32
op,
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
struct drm_device *dev = obj->dev;
bool write = !!(op & ETNA_PREP_WRITE);
- int ret;
-
- if (op & ETNA_PREP_NOSYNC) {
- if (!reservation_object_test_signaled_rcu(etnaviv_obj->resv,
- write))
- return -EBUSY;
- } else {
- unsigned long remain = etnaviv_timeout_to_jiffies(timeout);
-
- ret = reservation_object_wait_timeout_rcu(etnaviv_obj->resv,
- write, true, remain);
- if (ret <= 0)
- return ret == 0 ? -ETIMEDOUT : ret;
- }
+ unsigned long remain =
+ op & ETNA_PREP_NOSYNC ? 0 : etnaviv_timeout_to_jiffies(timeout);
+ long lret;
+
+ lret = reservation_object_wait_timeout_rcu(etnaviv_obj->resv,
+ write, true, remain);
+ if (lret < 0)
+ return lret;
+ else if (lret == 0)
+ return remain == 0 ? -EBUSY : -ETIMEDOUT;
if (etnaviv_obj->flags & ETNA_BO_CACHED) {
if (!etnaviv_obj->sgt) {
--
2.9.3
[PATCH 03/11] drm/msm: Remove call to reservation_object_test_signaled_rcu before wait
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.
v2: 9 is only 0 in German.
Signed-off-by: Chris Wilson
Cc: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 6cd4af443139..45796a88d353 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -584,18 +584,16 @@ int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t
op, ktime_t *timeout)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
bool write = !!(op & MSM_PREP_WRITE);
-
- if (op & MSM_PREP_NOSYNC) {
- if (!reservation_object_test_signaled_rcu(msm_obj->resv, write))
- return -EBUSY;
- } else {
- int ret;
-
- ret = reservation_object_wait_timeout_rcu(msm_obj->resv, write,
- true, timeout_to_jiffies(timeout));
- if (ret <= 0)
- return ret == 0 ? -ETIMEDOUT : ret;
- }
+ unsigned long remain =
+ op & MSG_PREP_NOSYNC ? 0 : timeout_to_jiffies(timeout);
+ long ret;
+
+ ret = reservation_object_wait_timeout_rcu(msm_obj->resv, write,
+ true, remain);
+ if (ret == 0)
+ return remain == 0 ? -EBUSY : -ETIMEDOUT;
+ else if (ret < 0)
+ return ret;
/* TODO cache maintenance */
--
2.9.3
[PATCH 04/11] drm/nouveau: Remove call to reservation_object_test_signaled_rcu before wait
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 72e2399bce39..b90e21ff1ed8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -861,6 +861,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void
*data,
struct nouveau_bo *nvbo;
bool no_wait = !!(req->flags & NOUVEAU_GEM_CPU_PREP_NOWAIT);
bool write = !!(req->flags & NOUVEAU_GEM_CPU_PREP_WRITE);
+ long lret;
int ret;
gem = drm_gem_object_lookup(file_priv, req->handle);
@@ -868,19 +869,15 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void
*data,
return -ENOENT;
nvbo = nouveau_gem_object(gem);
- if (no_wait)
- ret = reservation_object_test_signaled_rcu(nvbo->bo.resv,
write) ? 0 : -EBUSY;
- else {
- long lret;
+ lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, write, true,
+ no_wait ? 0 :30 * HZ);
+ if (!lret)
+ ret = -EBUSY;
+ else if (lret > 0)
+ ret = 0;
+ else
+ ret = lret;
- lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv,
write, true, 30 * HZ);
- if (!lret)
- ret = -EBUSY;
- else if (lret > 0)
- ret = 0;
- else
- ret = lret;
- }
nouveau_bo_sync_for_cpu(nvbo);
drm_gem_object_unreference_unlocked(gem);
--
2.9.3
[PATCH 05/11] drm/vmwgfx: Remove call to reservation_object_test_signaled_rcu before wait
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy check and potentially blocking wait. Signed-off-by: Chris Wilson Cc: Sinclair Yeh Cc: Thomas Hellstrom Reviewed-by: Sinclair Yeh --- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c index 6a328d507a28..1a85fb2d4dc6 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c @@ -574,10 +574,8 @@ static int vmw_user_dmabuf_synccpu_grab(struct vmw_user_dma_buffer *user_bo, bool nonblock = !!(flags & drm_vmw_synccpu_dontblock); long lret; - if (nonblock) - return reservation_object_test_signaled_rcu(bo->resv, true) ? 0 : -EBUSY; - - lret = reservation_object_wait_timeout_rcu(bo->resv, true, true, MAX_SCHEDULE_TIMEOUT); + lret = reservation_object_wait_timeout_rcu(bo->resv, true, true, + nonblock ? 0 : MAX_SCHEDULE_TIMEOUT); if (!lret) return -EBUSY; else if (lret < 0) -- 2.9.3
[PATCH 06/11] dma-buf: Introduce fence_get_rcu_safe()
This variant of fence_get_rcu() takes an RCU protected pointer to a
fence and carefully returns a reference to the fence ensuring that it is
not reallocated as it does. This is required when mixing fences and
SLAB_DESTROY_BY_RCU - although it serves a more pedagogical function atm
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
include/linux/fence.h | 56 ++-
1 file changed, 51 insertions(+), 5 deletions(-)
diff --git a/include/linux/fence.h b/include/linux/fence.h
index 0d763053f97a..c9c5ba98c302 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -183,6 +183,16 @@ void fence_release(struct kref *kref);
void fence_free(struct fence *fence);
/**
+ * fence_put - decreases refcount of the fence
+ * @fence: [in]fence to reduce refcount of
+ */
+static inline void fence_put(struct fence *fence)
+{
+ if (fence)
+ kref_put(&fence->refcount, fence_release);
+}
+
+/**
* fence_get - increases refcount of the fence
* @fence: [in]fence to increase refcount of
*
@@ -210,13 +220,49 @@ static inline struct fence *fence_get_rcu(struct fence
*fence)
}
/**
- * fence_put - decreases refcount of the fence
- * @fence: [in]fence to reduce refcount of
+ * fence_get_rcu_safe - acquire a reference to an RCU tracked fence
+ * @fence: [in]pointer to fence to increase refcount of
+ *
+ * Function returns NULL if no refcount could be obtained, or the fence.
+ * This function handles acquiring a reference to a fence that may be
+ * reallocated within the RCU grace period (such as with SLAB_DESTROY_BY_RCU),
+ * so long as the caller is using RCU on the pointer to the fence.
+ *
+ * An alternative mechanism is to employ a seqlock to protect a bunch of
+ * fences, such as used by struct reservation_object. When using a seqlock,
+ * the seqlock must be taken before and checked after a reference to the
+ * fence is acquired (as shown here).
+ *
+ * The caller is required to hold the RCU read lock.
*/
-static inline void fence_put(struct fence *fence)
+static inline struct fence *fence_get_rcu_safe(struct fence * __rcu *fencep)
{
- if (fence)
- kref_put(&fence->refcount, fence_release);
+ do {
+ struct fence *fence;
+
+ fence = rcu_dereference(*fencep);
+ if (!fence || !fence_get_rcu(fence))
+ return NULL;
+
+ /* The atomic_inc_not_zero() inside fence_get_rcu()
+* provides a full memory barrier upon success (such as now).
+* This is paired with the write barrier from assigning
+* to the __rcu protected fence pointer so that if that
+* pointer still matches the current fence, we know we
+* have successfully acquire a reference to it. If it no
+* longer matches, we are holding a reference to some other
+* reallocated pointer. This is possible if the allocator
+* is using a freelist like SLAB_DESTROY_BY_RCU where the
+* fence remains valid for the RCU grace period, but it
+* may be reallocated. When using such allocators, we are
+* responsible for ensuring the reference we get is to
+* the right fence, as below.
+*/
+ if (fence == rcu_access_pointer(*fencep))
+ return rcu_pointer_handoff(fence);
+
+ fence_put(fence);
+ } while (1);
}
int fence_signal(struct fence *fence);
--
2.9.3
[PATCH 07/11] dma-buf: Restart reservation_object_get_fences_rcu() after writes
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical section does not prevent this reallocation, instead
we have to inspect the reservation's seqlock to double check if the
fences have been reassigned as we were acquiring our reference.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Christian König
Cc: Alex Deucher
Cc: Sumit Semwal
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
drivers/dma-buf/reservation.c | 71 +++
1 file changed, 31 insertions(+), 40 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 723d8af988e5..10fd441dd4ed 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -280,18 +280,24 @@ int reservation_object_get_fences_rcu(struct
reservation_object *obj,
unsigned *pshared_count,
struct fence ***pshared)
{
- unsigned shared_count = 0;
- unsigned retry = 1;
- struct fence **shared = NULL, *fence_excl = NULL;
- int ret = 0;
+ struct fence **shared = NULL;
+ struct fence *fence_excl;
+ unsigned shared_count;
+ int ret = 1;
- while (retry) {
+ do {
struct reservation_object_list *fobj;
unsigned seq;
+ unsigned i;
- seq = read_seqcount_begin(&obj->seq);
+ shared_count = i = 0;
rcu_read_lock();
+ seq = read_seqcount_begin(&obj->seq);
+
+ fence_excl = rcu_dereference(obj->fence_excl);
+ if (fence_excl && !fence_get_rcu(fence_excl))
+ goto unlock;
fobj = rcu_dereference(obj->fence);
if (fobj) {
@@ -309,52 +315,37 @@ int reservation_object_get_fences_rcu(struct
reservation_object *obj,
}
ret = -ENOMEM;
- shared_count = 0;
break;
}
shared = nshared;
- memcpy(shared, fobj->shared, sz);
shared_count = fobj->shared_count;
- } else
- shared_count = 0;
- fence_excl = rcu_dereference(obj->fence_excl);
-
- retry = read_seqcount_retry(&obj->seq, seq);
- if (retry)
- goto unlock;
-
- if (!fence_excl || fence_get_rcu(fence_excl)) {
- unsigned i;
for (i = 0; i < shared_count; ++i) {
- if (fence_get_rcu(shared[i]))
- continue;
-
- /* uh oh, refcount failed, abort and retry */
- while (i--)
- fence_put(shared[i]);
-
- if (fence_excl) {
- fence_put(fence_excl);
- fence_excl = NULL;
- }
-
- retry = 1;
- break;
+ shared[i] = rcu_dereference(fobj->shared[i]);
+ if (!fence_get_rcu(shared[i]))
+ break;
}
- } else
- retry = 1;
+ }
+
+ if (i != shared_count || read_seqcount_retry(&obj->seq, seq)) {
+ while (i--)
+ fence_put(shared[i]);
+ fence_put(fence_excl);
+ goto unlock;
+ }
+ ret = 0;
unlock:
rcu_read_unlock();
- }
- *pshared_count = shared_count;
- if (shared_count)
- *pshared = shared;
- else {
- *pshared = NULL;
+ } while (ret);
+
+ if (!shared_count) {
kfree(shared);
+ shared = NULL;
}
+
+ *pshared_count = shared_count;
+ *pshared = shared;
*pfence_excl = fence_excl;
return ret;
--
2.9.3
[PATCH 08/11] dma-buf: Restart reservation_object_wait_timeout_rcu() after writes
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical section does not prevent this reallocation, instead
we have to inspect the reservation's seqlock to double check if the
fences have been reassigned as we were acquiring our reference.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Christian König
Cc: Alex Deucher
Cc: Sumit Semwal
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
drivers/dma-buf/reservation.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 10fd441dd4ed..3369e4668e96 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -388,9 +388,6 @@ retry:
if (fobj)
shared_count = fobj->shared_count;
- if (read_seqcount_retry(&obj->seq, seq))
- goto unlock_retry;
-
for (i = 0; i < shared_count; ++i) {
struct fence *lfence = rcu_dereference(fobj->shared[i]);
@@ -413,9 +410,6 @@ retry:
if (!shared_count) {
struct fence *fence_excl = rcu_dereference(obj->fence_excl);
- if (read_seqcount_retry(&obj->seq, seq))
- goto unlock_retry;
-
if (fence_excl &&
!test_bit(FENCE_FLAG_SIGNALED_BIT, &fence_excl->flags)) {
if (!fence_get_rcu(fence_excl))
@@ -430,6 +424,11 @@ retry:
rcu_read_unlock();
if (fence) {
+ if (read_seqcount_retry(&obj->seq, seq)) {
+ fence_put(fence);
+ goto retry;
+ }
+
ret = fence_wait_timeout(fence, intr, ret);
fence_put(fence);
if (ret > 0 && wait_all && (i + 1 < shared_count))
--
2.9.3
[PATCH 09/11] dma-buf: Restart reservation_object_test_signaled_rcu() after writes
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical section does not prevent this reallocation, instead
we have to inspect the reservation's seqlock to double check if the
fences have been reassigned as we were acquiring our reference.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Christian König
Cc: Alex Deucher
Cc: Sumit Semwal
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
drivers/dma-buf/reservation.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 3369e4668e96..e74493e7332b 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -474,12 +474,13 @@ bool reservation_object_test_signaled_rcu(struct
reservation_object *obj,
bool test_all)
{
unsigned seq, shared_count;
- int ret = true;
+ int ret;
+ rcu_read_lock();
retry:
+ ret = true;
shared_count = 0;
seq = read_seqcount_begin(&obj->seq);
- rcu_read_lock();
if (test_all) {
unsigned i;
@@ -490,46 +491,35 @@ retry:
if (fobj)
shared_count = fobj->shared_count;
- if (read_seqcount_retry(&obj->seq, seq))
- goto unlock_retry;
-
for (i = 0; i < shared_count; ++i) {
struct fence *fence = rcu_dereference(fobj->shared[i]);
ret = reservation_object_test_signaled_single(fence);
if (ret < 0)
- goto unlock_retry;
+ goto retry;
else if (!ret)
break;
}
- /*
-* There could be a read_seqcount_retry here, but nothing cares
-* about whether it's the old or newer fence pointers that are
-* signaled. That race could still have happened after checking
-* read_seqcount_retry. If you care, use ww_mutex_lock.
-*/
+ if (read_seqcount_retry(&obj->seq, seq))
+ goto retry;
}
if (!shared_count) {
struct fence *fence_excl = rcu_dereference(obj->fence_excl);
- if (read_seqcount_retry(&obj->seq, seq))
- goto unlock_retry;
-
if (fence_excl) {
ret = reservation_object_test_signaled_single(
fence_excl);
if (ret < 0)
- goto unlock_retry;
+ goto retry;
+
+ if (read_seqcount_retry(&obj->seq, seq))
+ goto retry;
}
}
rcu_read_unlock();
return ret;
-
-unlock_retry:
- rcu_read_unlock();
- goto retry;
}
EXPORT_SYMBOL_GPL(reservation_object_test_signaled_rcu);
--
2.9.3
[PATCH 10/11] dma-buf: Use seqlock to close RCU race in test_signaled_single
With the seqlock now extended to cover the lookup of the fence and its
testing, we can perform that testing solely under the seqlock guard and
avoid the effective locking and serialisation of acquiring a reference to
the request. As the fence is RCU protected we know it cannot disappear
as we test it, the same guarantee that made it safe to acquire the
reference previously. The seqlock tests whether the fence was replaced
as we are testing it telling us whether or not we can trust the result
(if not, we just repeat the test until stable).
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
drivers/dma-buf/reservation.c | 32
1 file changed, 4 insertions(+), 28 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index e74493e7332b..1ddffa5adb5a 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -442,24 +442,6 @@ unlock_retry:
}
EXPORT_SYMBOL_GPL(reservation_object_wait_timeout_rcu);
-
-static inline int
-reservation_object_test_signaled_single(struct fence *passed_fence)
-{
- struct fence *fence, *lfence = passed_fence;
- int ret = 1;
-
- if (!test_bit(FENCE_FLAG_SIGNALED_BIT, &lfence->flags)) {
- fence = fence_get_rcu(lfence);
- if (!fence)
- return -1;
-
- ret = !!fence_is_signaled(fence);
- fence_put(fence);
- }
- return ret;
-}
-
/**
* reservation_object_test_signaled_rcu - Test if a reservation object's
* fences have been signaled.
@@ -474,7 +456,7 @@ bool reservation_object_test_signaled_rcu(struct
reservation_object *obj,
bool test_all)
{
unsigned seq, shared_count;
- int ret;
+ bool ret;
rcu_read_lock();
retry:
@@ -494,10 +476,8 @@ retry:
for (i = 0; i < shared_count; ++i) {
struct fence *fence = rcu_dereference(fobj->shared[i]);
- ret = reservation_object_test_signaled_single(fence);
- if (ret < 0)
- goto retry;
- else if (!ret)
+ ret = fence_is_signaled(fence);
+ if (!ret)
break;
}
@@ -509,11 +489,7 @@ retry:
struct fence *fence_excl = rcu_dereference(obj->fence_excl);
if (fence_excl) {
- ret = reservation_object_test_signaled_single(
- fence_excl);
- if (ret < 0)
- goto retry;
-
+ ret = fence_is_signaled(fence_excl);
if (read_seqcount_retry(&obj->seq, seq))
goto retry;
}
--
2.9.3
[PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0
Currently we install a callback for performing poll on a dma-buf,
irrespective of the timeout. This involves taking a spinlock, as well as
unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
multiple threads.
We can query whether the poll will block prior to installing the
callback to make the busy-query fast.
Single thread: 60% faster
8 threads on 4 (+4 HT) cores: 600% faster
Still not quite the perfect scaling we get with a native busy ioctl, but
poll(dmabuf) is faster due to the quicker lookup of the object and
avoiding drm_ioctl().
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Reviewed-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index cf04d249a6a4..c7a7bc579941 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -156,6 +156,18 @@ static unsigned int dma_buf_poll(struct file *file,
poll_table *poll)
if (!events)
return 0;
+ if (poll_does_not_wait(poll)) {
+ if (events & POLLOUT &&
+ !reservation_object_test_signaled_rcu(resv, true))
+ events &= ~(POLLOUT | POLLIN);
+
+ if (events & POLLIN &&
+ !reservation_object_test_signaled_rcu(resv, false))
+ events &= ~POLLIN;
+
+ return events;
+ }
+
retry:
seq = read_seqcount_begin(&resv->seq);
rcu_read_lock();
--
2.9.3
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On Sun, 28 Aug 2016, Andrea Arcangeli wrote:
> Skylake was already singled out, but it doesn't cover the XPS 13 L332X
> model which is based on IvyBridge.
>
> The commit that introduced the regression is
> 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
That's a merge commit, the real one is
commit a05628195a0d9f3173dd9aa76f482aef692e46ee
Author: Ville Syrjälä
Date: Mon Apr 11 10:23:51 2016 +0300
drm/i915: Get panel_type from OpRegion panel details
> The Skylake workaround for the regression was introduced in commit
> aeddda06c1a704bb97c8a7bfe7a472120193bd56
>
> Signed-off-by: Andrea Arcangeli
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index adca262..ca17ab6 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1073,12 +1073,14 @@ intel_opregion_get_panel_type(struct drm_i915_private
> *dev_priv)
> }
>
> /*
> - * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
> - * low vswing for eDP, whereas the VBT panel type (2) gives us normal
> - * vswing instead. Low vswing results in some display flickers, so
> - * let's simply ignore the OpRegion panel type on SKL for now.
> + * FIXME On Dell XPS 13 9350 and Dell XPS 13 L322X the
> + * OpRegion panel type (0) gives us low vswing for eDP,
> + * whereas the VBT panel type (2) gives us normal vswing
> + * instead. Low vswing results in some display flickers, so
> + * let's simply ignore the OpRegion panel type on SKL and
> + * IVYBRIDGE for now.
>*/
If it's an Iybridge, there's no low vswing, and that explanation is
false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
on an unpatched kernel.
Doesn't mean there can't be something else wrong with the mode you get
using a different panel_type. And this makes me wonder what the point is
in trying to patch up the commit instead of reverting.
BR,
Jani.
> - if (IS_SKYLAKE(dev_priv)) {
> + if (IS_SKYLAKE(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
> DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
> return -ENODEV;
> }
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH RFC] drm/tilcdc: Write DMA base and ceiling address with single instruction
Write DMA base and ceiling address with a single instruction, if
available. This should make it more unlikely that LCDC would fetch the
DMA addresses in the middle of an update. Having bad combination of
addresses in dma base and ceiling (e.g base > ceiling) can cause
unpredictaple behavior in LCDC.
Signed-off-by: Jyri Sarha
---
I am not sure what would be the least ugly way of utilizing ARM7 strd
instruction. Using inline assebler would be the most straight forward
way, but this looks less ugly to me.
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 9 +++--
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 13 +
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 6350f2a..41ec5b3 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -70,6 +70,7 @@ static void set_scanout(struct drm_crtc *crtc, struct
drm_framebuffer *fb)
struct drm_gem_cma_object *gem;
unsigned int depth, bpp;
dma_addr_t start, end;
+ u64 dma_base_and_ceiling;
drm_fb_get_bpp_depth(fb->pixel_format, &depth, &bpp);
gem = drm_fb_cma_get_gem_obj(fb, 0);
@@ -80,8 +81,12 @@ static void set_scanout(struct drm_crtc *crtc, struct
drm_framebuffer *fb)
end = start + (crtc->mode.vdisplay * fb->pitches[0]);
- tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, start);
- tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, end - 1);
+ /* Write DMA base and ceiling address with a single insruction,
+* if available. This should make it more unlikely that LCDC would
+* fetch the DMA addresses in the middle of an update.
+*/
+ dma_base_and_ceiling = (u64)(end - 1) << 32 | start;
+ tilcdc_write64(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_base_and_ceiling);
if (tilcdc_crtc->curr_fb)
drm_flip_work_queue(&tilcdc_crtc->unref_work,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
index 1bf5e25..ea934c9 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
@@ -119,6 +119,19 @@ static inline void tilcdc_write(struct drm_device *dev,
u32 reg, u32 data)
iowrite32(data, priv->mmio + reg);
}
+static inline void tilcdc_write64(struct drm_device *dev, u32 reg, u64 data)
+{
+ struct tilcdc_drm_private *priv = dev->dev_private;
+ volatile void __iomem *addr = priv->mmio + reg;
+
+#ifdef iowrite64
+ iowrite64(data, addr);
+#else
+ /* This compiles to strd (=64-bit write) on ARM7 */
+ *(volatile u64 __force *)addr = data;
+#endif
+}
+
static inline u32 tilcdc_read(struct drm_device *dev, u32 reg)
{
struct tilcdc_drm_private *priv = dev->dev_private;
--
1.9.1
[PATCH] drm/hisilicon: Don't set drm_device->platformdev
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
This required a bit more fudging, but I guess kirin_dc_ops really
wants to operate on the platform_device, not something else. Also
bonus points for implementing abstraction, and then storing the vfunc
in a global variable.
v2: Don't break the build s badly :(
Note that the cleanup function is a bit confused: ade_data was never
set as drvdata, and calling drm_crtc_cleanup directly is a bug - this
is called indirectly through drm_mode_config_cleanup, which calls into
crtc->destroy, which already has the call to drm_crtc_cleanup. Which
means we can just nuke it.
Note this is the 2nd attempt after the first one failed and had to be
reverted again in
commit 9cd2e854d61ccfa51686f3ed7b0c917708fc641f
Author: Daniel Vetter
Date: Wed Aug 17 13:59:40 2016 +0200
Revert "drm/hisilicon: Don't set drm_device->platformdev"
Cc: Xinliang Liu
Cc: Xinwei Kong
Cc: Archit Taneja
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 11 +++
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 8 +++-
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 4 ++--
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 7e7a4d43d6b6..26022122bcd1 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -974,9 +974,9 @@ static int ade_dts_parse(struct platform_device *pdev,
struct ade_hw_ctx *ctx)
return 0;
}
-static int ade_drm_init(struct drm_device *dev)
+static int ade_drm_init(struct platform_device *pdev)
{
- struct platform_device *pdev = dev->platformdev;
+ struct drm_device *dev = platform_get_drvdata(pdev);
struct ade_data *ade;
struct ade_hw_ctx *ctx;
struct ade_crtc *acrtc;
@@ -1035,13 +1035,8 @@ static int ade_drm_init(struct drm_device *dev)
return 0;
}
-static void ade_drm_cleanup(struct drm_device *dev)
+static void ade_drm_cleanup(struct platform_device *pdev)
{
- struct platform_device *pdev = dev->platformdev;
- struct ade_data *ade = platform_get_drvdata(pdev);
- struct drm_crtc *crtc = &ade->acrtc.base;
-
- drm_crtc_cleanup(crtc);
}
const struct kirin_dc_ops ade_dc_ops = {
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 1fc2f502d20d..b9b8c25da5e3 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -41,7 +41,7 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
#endif
drm_kms_helper_poll_fini(dev);
drm_vblank_cleanup(dev);
- dc_ops->cleanup(dev);
+ dc_ops->cleanup(to_platform_device(dev->dev));
drm_mode_config_cleanup(dev);
devm_kfree(dev->dev, priv);
dev->dev_private = NULL;
@@ -103,7 +103,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
kirin_drm_mode_config_init(dev);
/* display controller init */
- ret = dc_ops->init(dev);
+ ret = dc_ops->init(to_platform_device(dev->dev));
if (ret)
goto err_mode_config_cleanup;
@@ -137,7 +137,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
err_unbind_all:
component_unbind_all(dev->dev, dev);
err_dc_cleanup:
- dc_ops->cleanup(dev);
+ dc_ops->cleanup(to_platform_device(dev->dev));
err_mode_config_cleanup:
drm_mode_config_cleanup(dev);
devm_kfree(dev->dev, priv);
@@ -210,8 +210,6 @@ static int kirin_drm_bind(struct device *dev)
if (!drm_dev)
return -ENOMEM;
- drm_dev->platformdev = to_platform_device(dev);
-
ret = kirin_drm_kms_init(drm_dev);
if (ret)
goto err_drm_dev_unref;
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 1a07caf8e7f4..a0bb217c4c64 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -15,8 +15,8 @@
/* display controller init/cleanup ops */
struct kirin_dc_ops {
- int (*init)(struct drm_device *dev);
- void (*cleanup)(struct drm_device *dev);
+ int (*init)(struct platform_device *pdev);
+ void (*cleanup)(struct platform_device *pdev);
};
struct kirin_drm_private {
--
2.9.3
[PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()
>Sent: Saturday, August 27, 2016 8:07 PM >To: Tomi Valkeinen ; Tony Lindgren atomide.com>; >Sean Paul ; Peter Chen ; >Andrey Utkin >Cc: David Airlie ; Peter Ujfalusi ti.com>; Dave >Airlie ; Rob Clark ; Dr. H. >Nikolaus >Schaller ; Andrew Bradford ; >kernel at pyra-handheld.com; Discussions about the Letux Kernel kernel at openphoenux.org>; dri-devel at lists.freedesktop.org; lkml kernel at vger.kernel.org>; linux-omap at vger.kernel.org >Subject: Re: [PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to >of_get_next_parent() > >> [8.842806] OF: ERROR: Bad of_node_put() on /encoder/ports/port at >> 1/endpoint >> [8.843014] [] (omapdss_of_find_source_for_first_ep [omapdss]) > >I can confirm that reverting 2ab9f5879162 fixes this regression, tested on >omap5- >uevm. > It was my careless for introducing regression. The revert patch has already been at linux-next. Sorry for inconvenience. https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=5a78ff7bf7e25191144b550961001bbf6c734da4 Peter
i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status
Tried 4.8-rc4 on my i5-2400 PC, got this warning: [ 14.579557] i915 :00:02.0: fb0: inteldrmfb frame buffer device [ 15.847321] [ cut here ] [ 15.847346] WARNING: CPU: 0 PID: 208 at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write+0x109/0x1f0 [i915] [ 15.847348] Missing switch case (16) in gen6_check_mailbox_status [ 15.847349] Modules linked in: cpufreq_powersave cpufreq_userspace cpufreq_conservative joydev hid_generic usbhid hid x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel aesni_intel snd_hda_codec_realtek snd_hda_codec_generic iTCO_wdt i915 aes_x86_64 iTCO_vendor_support glue_helper lrw ablk_helper cryptd video i2c_algo_bit drm_kms_helper psmouse pcspkr syscopyarea sysfillrect sysimgblt fb_sys_fops ehci_pci ehci_hcd snd_hda_intel xhci_pci xhci_hcd e1000e snd_hda_codec snd_hwdep usbcore drm snd_hda_core usb_common i2c_i801 ptp pps_core i2c_smbus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer evdev snd tpm_tis lpc_ich parport_pc tpm_tis_core mfd_core parport nuvoton_cir rc_core tpm soundcore floppy w83627ehf hwmon_vid coretemp hwmon eeprom i2c_core loop ip_tables x_tables autofs4 [ 15.847395] CPU: 0 PID: 208 Comm: kworker/0:2 Not tainted 4.8.0-rc4 #213 [ 15.847396] Hardware name: /DQ67OW, BIOS SWQ6710H.86A.0066.2012.1105.1504 11/05/2012 [ 15.847412] Workqueue: events intel_gen6_powersave_work [i915] [ 15.847414] 812d8198 88023191fd70 [ 15.847417] 81056d1e 88022ea4 88023191fdc0 [ 15.847419] 88022ea4a3c8 88022ea487c0 088023e21ba0 81056d8f [ 15.847422] Call Trace: [ 15.847427] [] ? dump_stack+0x46/0x5e [ 15.847429] [] ? __warn+0xbe/0xe0 [ 15.847431] [] ? warn_slowpath_fmt+0x4f/0x60 [ 15.847446] [] ? sandybridge_pcode_write+0x109/0x1f0 [i915] [ 15.847459] [] ? intel_gen6_powersave_work+0x2a8/0x1400 [i915] [ 15.847462] [] ? process_one_work+0x1eb/0x480 [ 15.847465] [] ? worker_thread+0x47/0x4c0 [ 15.847467] [] ? __schedule+0x1d7/0x660 [ 15.847469] [] ? process_one_work+0x480/0x480 [ 15.847472] [] ? kthread+0xbd/0xe0 [ 15.847475] [] ? ret_from_fork+0x1f/0x40 [ 15.847478] [] ? kthread_worker_fn+0x160/0x160 [ 15.847487] ---[ end trace ad9e991297d99be1 ]--- -- Meelis Roos (mroos at linux.ee)
[PATCH v4 3/7] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit
On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote: > Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter > of the helper drm_atomic_helper_commit_planes() if the relevant display > controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes > when the CRTC is disabled. The helper would skip the ->atomic_disable > call for a plane if the CRTC of the old plane state needs a modesetting > operation. Of course, the drivers need to disable the planes in their CRTC > disable callbacks since no one else would do that. > > Suggested-by: Daniel Vetter > Cc: Philipp Zabel > Cc: David Airlie > Cc: Russell King > Cc: Peter Senna Tschudin > Cc: Lucas Stach > Signed-off-by: Liu Ying A few small nits below, otherwise looks good. I merged patches 1&2 into drm-misc already. Thanks, Daniel > --- > v4: > * Newly introduced in v4. > > drivers/gpu/drm/arm/malidp_drv.c | 3 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- > drivers/gpu/drm/drm_atomic_helper.c | 46 > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > drivers/gpu/drm/imx/imx-drm-core.c | 3 +- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++-- > drivers/gpu/drm/msm/msm_atomic.c | 2 +- > drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c| 3 +- > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +- > drivers/gpu/drm/sti/sti_drv.c| 2 +- > drivers/gpu/drm/tegra/drm.c | 3 +- > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +- > drivers/gpu/drm/vc4/vc4_kms.c| 2 +- > drivers/gpu/drm/virtio/virtgpu_display.c | 3 +- > include/drm/drm_atomic_helper.h | 6 +++- > 16 files changed, 61 insertions(+), 29 deletions(-) > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c > b/drivers/gpu/drm/arm/malidp_drv.c > index 82171d2..c383d72 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -91,7 +91,8 @@ static void malidp_atomic_commit_tail(struct > drm_atomic_state *state) > > drm_atomic_helper_commit_modeset_disables(drm, state); > drm_atomic_helper_commit_modeset_enables(drm, state); > - drm_atomic_helper_commit_planes(drm, state, true); > + drm_atomic_helper_commit_planes(drm, state, > + DRM_PLANE_COMMIT_ACTIVE_ONLY); > > malidp_atomic_commit_hw_done(state); > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > index d4a3d61..8e7483d 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > @@ -457,7 +457,7 @@ atmel_hlcdc_dc_atomic_complete(struct > atmel_hlcdc_dc_commit *commit) > > /* Apply the atomic update. */ > drm_atomic_helper_commit_modeset_disables(dev, old_state); > - drm_atomic_helper_commit_planes(dev, old_state, false); > + drm_atomic_helper_commit_planes(dev, old_state, 0); > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > drm_atomic_helper_wait_for_vblanks(dev, old_state); > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 30c52a8..cf19b6e 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1148,7 +1148,8 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks); > * > * drm_atomic_helper_commit_modeset_enables(dev, state); > * > - * drm_atomic_helper_commit_planes(dev, state, true); > + * drm_atomic_helper_commit_planes(dev, state, > + * DRM_PLANE_COMMIT_ACTIVE_ONLY); > * > * for committing the atomic update to hardware. See the kerneldoc entries > for > * these three functions for more details. > @@ -1159,7 +1160,7 @@ void drm_atomic_helper_commit_tail(struct > drm_atomic_state *state) > > drm_atomic_helper_commit_modeset_disables(dev, state); > > - drm_atomic_helper_commit_planes(dev, state, false); > + drm_atomic_helper_commit_planes(dev, state, 0); > > drm_atomic_helper_commit_modeset_enables(dev, state); > > @@ -1678,7 +1679,7 @@ bool plane_crtc_active(struct drm_plane_state *state) > * drm_atomic_helper_commit_planes - commit plane state > * @dev: DRM device > * @old_state: atomic state object with old state structures > - * @active_only: Only commit on active CRTC if set > + * @flags: flags for committing plane state > * > * This function commits the new plane state using the plane and atomic > helper > * functions for planes and crtcs. It assumes that the atomic state has > already > @@ -1698,25 +1699,33 @@ bool plane_crtc_active(struct drm_plane_state *state) > * most drivers don't need to be immediately notified of plane updates for a > * disabled CRTC. > * > - * Unless otherwise needed, drivers ar
[PATCH 1/9] drm: Extract drm_encoder.[hc]
Same treatment as before. Only hiccup is drm_crtc_mask, which
unfortunately can't be resolved until drm_crtc.h is less of a monster.
Untangle the header loop with a forward declaration for that static
inline.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 9 ++
drivers/gpu/drm/Makefile| 3 +-
drivers/gpu/drm/drm_crtc.c | 193 ---
drivers/gpu/drm/drm_crtc_internal.h | 10 +-
drivers/gpu/drm/drm_encoder.c | 220
include/drm/drm_crtc.h | 134 +-
include/drm/drm_encoder.h | 167 +++
7 files changed, 407 insertions(+), 329 deletions(-)
create mode 100644 drivers/gpu/drm/drm_encoder.c
create mode 100644 include/drm/drm_encoder.h
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index fa948b4e029b..7f788caebea3 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -125,6 +125,15 @@ Connector Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_connector.c
:export:
+Encoder Abstraction
+===
+
+.. kernel-doc:: include/drm/drm_encoder.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
+ :export:
+
KMS Initialization and Cleanup
==
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4054c94a2301..8aa3a7800560 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -13,7 +13,8 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
- drm_framebuffer.o drm_connector.o drm_blend.o
+ drm_framebuffer.o drm_connector.o drm_blend.o \
+ drm_encoder.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7ebe549051a6..389d013dcb36 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -54,18 +54,6 @@ static const struct drm_prop_enum_list
drm_plane_type_enum_list[] = {
{ DRM_PLANE_TYPE_CURSOR, "Cursor" },
};
-static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
- { DRM_MODE_ENCODER_NONE, "None" },
- { DRM_MODE_ENCODER_DAC, "DAC" },
- { DRM_MODE_ENCODER_TMDS, "TMDS" },
- { DRM_MODE_ENCODER_LVDS, "LVDS" },
- { DRM_MODE_ENCODER_TVDAC, "TV" },
- { DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
- { DRM_MODE_ENCODER_DSI, "DSI" },
- { DRM_MODE_ENCODER_DPMST, "DP MST" },
- { DRM_MODE_ENCODER_DPI, "DPI" },
-};
-
/*
* Optional properties
*/
@@ -419,117 +407,6 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
}
EXPORT_SYMBOL(drm_crtc_cleanup);
-static int drm_encoder_register_all(struct drm_device *dev)
-{
- struct drm_encoder *encoder;
- int ret = 0;
-
- drm_for_each_encoder(encoder, dev) {
- if (encoder->funcs->late_register)
- ret = encoder->funcs->late_register(encoder);
- if (ret)
- return ret;
- }
-
- return 0;
-}
-
-static void drm_encoder_unregister_all(struct drm_device *dev)
-{
- struct drm_encoder *encoder;
-
- drm_for_each_encoder(encoder, dev) {
- if (encoder->funcs->early_unregister)
- encoder->funcs->early_unregister(encoder);
- }
-}
-
-/**
- * drm_encoder_init - Init a preallocated encoder
- * @dev: drm device
- * @encoder: the encoder to init
- * @funcs: callbacks for this encoder
- * @encoder_type: user visible type of the encoder
- * @name: printf style format string for the encoder name, or NULL for default
name
- *
- * Initialises a preallocated encoder. Encoder should be
- * subclassed as part of driver encoder objects.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_encoder_init(struct drm_device *dev,
- struct drm_encoder *encoder,
- const struct drm_encoder_funcs *funcs,
- int encoder_type, const char *name, ...)
-{
- int ret;
-
- drm_modeset_lock_all(dev);
-
- ret = drm_mode_object_get(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
- if (ret)
- goto out_unlock;
-
- encoder->dev = dev;
- encoder->encoder_type = encoder_type;
- encoder->funcs = funcs;
- if (name) {
- va_list ap;
-
- va_start(ap, name);
- encoder->name = kvasprintf(GFP_KERNEL, name, ap);
- va_end(ap);
- } else {
- encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
-
drm_encoder_enum_list[encoder_type].name,
-
[PATCH 2/9] drm/doc: Polish kerneldoc for encoders
- Move missing bits into struct drm_encoder docs.
- Explain that encoders are 95% internal and only 5% uapi, and that in
general the uapi part is broken.
- Remove verbose comments for functions not exposed to drivers.
v2: Review from Archit:
- Appease checkpatch in the moved code.
- Make it clearer that bridges are not exposed to userspace.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 46
drivers/gpu/drm/drm_encoder.c | 48 ++---
include/drm/drm_encoder.h | 70 +++
3 files changed, 101 insertions(+), 63 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 7f788caebea3..47c2835b7c2d 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -128,6 +128,12 @@ Connector Functions Reference
Encoder Abstraction
===
+.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
+ :doc: overview
+
+Encoder Functions Reference
+---
+
.. kernel-doc:: include/drm/drm_encoder.h
:internal:
@@ -207,46 +213,6 @@ future); drivers that do not wish to provide special
handling for
primary planes may make use of the helper functions described in ? to
create and register a primary plane with standard capabilities.
-Encoders (:c:type:`struct drm_encoder `)
--
-
-An encoder takes pixel data from a CRTC and converts it to a format
-suitable for any attached connectors. On some devices, it may be
-possible to have a CRTC send data to more than one encoder. In that
-case, both encoders would receive data from the same scanout buffer,
-resulting in a "cloned" display configuration across the connectors
-attached to each encoder.
-
-Encoder Initialization
-~~
-
-As for CRTCs, a KMS driver must create, initialize and register at least
-one :c:type:`struct drm_encoder ` instance. The
-instance is allocated and zeroed by the driver, possibly as part of a
-larger structure.
-
-Drivers must initialize the :c:type:`struct drm_encoder
-` possible_crtcs and possible_clones fields before
-registering the encoder. Both fields are bitmasks of respectively the
-CRTCs that the encoder can be connected to, and sibling encoders
-candidate for cloning.
-
-After being initialized, the encoder must be registered with a call to
-:c:func:`drm_encoder_init()`. The function takes a pointer to the
-encoder functions and an encoder type. Supported types are
-
-- DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A
-- DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort
-- DRM_MODE_ENCODER_LVDS for display panels
-- DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video,
- Component, SCART)
-- DRM_MODE_ENCODER_VIRTUAL for virtual machine displays
-
-Encoders must be attached to a CRTC to be used. DRM drivers leave
-encoders unattached at initialization time. Applications (or the fbdev
-compatibility layer when implemented) are responsible for attaching the
-encoders they want to use to a CRTC.
-
Cleanup
---
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index bce781b7bb5f..998a6743a586 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -26,6 +26,30 @@
#include "drm_crtc_internal.h"
+/**
+ * DOC: overview
+ *
+ * Encoders represent the connecting element between the CRTC (as the overall
+ * pixel pipeline, represented by struct &drm_crtc) and the connectors (as the
+ * generic sink entity, represented by struct &drm_connector). Encoders are
+ * objects exposed to userspace, originally to allow userspace to infer cloning
+ * and connector/CRTC restrictions. Unfortunately almost all drivers get this
+ * wrong, making the uabi pretty much useless. On top of that the exposed
+ * restrictions are too simple for todays hardware, and the recommend way to
+ * infer restrictions is by using the DRM_MODE_ATOMIC_TEST_ONLY flag for the
+ * atomic IOCTL.
+ *
+ * Otherwise encoders aren't used in the uapi at all (any modeset request from
+ * userspace directly connects a connector with a CRTC), drivers are therefore
+ * free to use them however they wish. Modeset helper libraries make strong use
+ * of encoders to facilitate code sharing. But for more complex settings it is
+ * usually better to move shared code into a separate &drm_bridge. Compared to
+ * encoders bridges also have the benefit of not being purely an internal
+ * abstraction since they are not exposed to userspace at all.
+ *
+ * Encoders are initialized with drm_encoder_init() and cleaned up using
+ * drm_encoder_cleanup().
+ */
static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
{ DRM_MODE_ENCODER_NONE, "None" },
{ DRM_MODE_ENCODER_DAC, "DAC" },
@@ -71,16 +95,17 @@ void drm_encoder_unregister_all(struct drm_device *dev)
* @encoder_type: user visible type of the
[PATCH 3/9] drm: Extract drm_mode_object.[hc]
Just for the struct drm_mode_object base class. The header file was
already partially extracted to help untangle the include loops.
v2:
- Also move the generic get/set property ioctls. At first this seemed
like a bad idea since it requires making drm_mode_crtc_set_obj_prop
non-static. But eventually that will get split away too (like
the connector version already is) for both crtc and planes. Hence I
reconsidered.
- drm_mode_object.[hc] instead of drm_modeset.[hc], which requires
renaming the drm_modeset.h header I already started building up.
This is more consistent (matches the name of the main structure),
and I want to be able to use drm_modeset.[hc] for the basic modeset
init/cleanup functionality like drm_mode_config_init.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst| 9 +
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_crtc.c | 413 +
drivers/gpu/drm/drm_crtc_internal.h | 52 +--
drivers/gpu/drm/drm_mode_object.c| 435 +++
include/drm/drm_connector.h | 2 +-
include/drm/drm_crtc.h | 12 +-
include/drm/drm_encoder.h| 2 +-
include/drm/drm_framebuffer.h| 2 +-
include/drm/{drm_modeset.h => drm_mode_object.h} | 10 +
include/drm/drm_modes.h | 2 +-
11 files changed, 492 insertions(+), 449 deletions(-)
create mode 100644 drivers/gpu/drm/drm_mode_object.c
rename include/drm/{drm_modeset.h => drm_mode_object.h} (87%)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 47c2835b7c2d..b164472f2157 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -15,6 +15,15 @@ be setup by initializing the following fields.
- struct drm_mode_config_funcs \*funcs;
Mode setting functions.
+Modeset Base Object Abstraction
+===
+
+.. kernel-doc:: include/drm/drm_mode_object.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
+ :export:
+
KMS Data Structures
===
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8aa3a7800560..8d379565ac8e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
- drm_encoder.o
+ drm_encoder.o drm_mode_object.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 389d013dcb36..7ec9f7e7a077 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -57,162 +57,6 @@ static const struct drm_prop_enum_list
drm_plane_type_enum_list[] = {
/*
* Optional properties
*/
-/*
- * Internal function to assign a slot in the object idr and optionally
- * register the object into the idr.
- */
-int drm_mode_object_get_reg(struct drm_device *dev,
- struct drm_mode_object *obj,
- uint32_t obj_type,
- bool register_obj,
- void (*obj_free_cb)(struct kref *kref))
-{
- int ret;
-
- mutex_lock(&dev->mode_config.idr_mutex);
- ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj : NULL,
1, 0, GFP_KERNEL);
- if (ret >= 0) {
- /*
-* Set up the object linking under the protection of the idr
-* lock so that other users can't see inconsistent state.
-*/
- obj->id = ret;
- obj->type = obj_type;
- if (obj_free_cb) {
- obj->free_cb = obj_free_cb;
- kref_init(&obj->refcount);
- }
- }
- mutex_unlock(&dev->mode_config.idr_mutex);
-
- return ret < 0 ? ret : 0;
-}
-
-/**
- * drm_mode_object_get - allocate a new modeset identifier
- * @dev: DRM device
- * @obj: object pointer, used to generate unique ID
- * @obj_type: object type
- *
- * Create a unique identifier based on @ptr in @dev's identifier space. Used
- * for tracking modes, CRTCs and connectors. Note that despite the _get postfix
- * modeset identifiers are _not_ reference counted. Hence don't use this for
- * reference counted modeset objects like framebuffers.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_mode_object_get(struct drm_device *dev,
- struct drm_mode_object *obj, uint32_t obj_type)
-{
- return drm_mode_object_get_reg(dev, obj, obj_type, true, NULL);
-}
-
-void drm_mode
[PATCH 4/9] drm: Remove drm_mode_object->atomic_count
It's only used in drm_mode_object_get_properties, and we can compute
it there directly with a bit of code shuffling.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_object.c | 31 ---
include/drm/drm_mode_object.h | 2 +-
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm/drm_mode_object.c
index cef9104e8285..a92aeed51156 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -209,8 +209,6 @@ void drm_object_attach_property(struct drm_mode_object *obj,
obj->properties->properties[count] = property;
obj->properties->values[count] = init_val;
obj->properties->count++;
- if (property->flags & DRM_MODE_PROP_ATOMIC)
- obj->properties->atomic_count++;
}
EXPORT_SYMBOL(drm_object_attach_property);
@@ -288,35 +286,30 @@ int drm_mode_object_get_properties(struct drm_mode_object
*obj, bool atomic,
uint64_t __user *prop_values,
uint32_t *arg_count_props)
{
- int props_count;
- int i, ret, copied;
+ int i, ret, count;
- props_count = obj->properties->count;
- if (!atomic)
- props_count -= obj->properties->atomic_count;
+ for (i = 0, count = 0; i < obj->properties->count; i++) {
+ struct drm_property *prop = obj->properties->properties[i];
+ uint64_t val;
- if ((*arg_count_props >= props_count) && props_count) {
- for (i = 0, copied = 0; copied < props_count; i++) {
- struct drm_property *prop =
obj->properties->properties[i];
- uint64_t val;
-
- if ((prop->flags & DRM_MODE_PROP_ATOMIC) && !atomic)
- continue;
+ if ((prop->flags & DRM_MODE_PROP_ATOMIC) && !atomic)
+ continue;
+ if (*arg_count_props > count) {
ret = drm_object_property_get_value(obj, prop, &val);
if (ret)
return ret;
- if (put_user(prop->base.id, prop_ptr + copied))
+ if (put_user(prop->base.id, prop_ptr + count))
return -EFAULT;
- if (put_user(val, prop_values + copied))
+ if (put_user(val, prop_values + count))
return -EFAULT;
-
- copied++;
}
+
+ count++;
}
- *arg_count_props = props_count;
+ *arg_count_props = count;
return 0;
}
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index c0e4414299f7..b8adb6425f2a 100644
--- a/include/drm/drm_mode_object.h
+++ b/include/drm/drm_mode_object.h
@@ -37,7 +37,7 @@ struct drm_mode_object {
#define DRM_OBJECT_MAX_PROPERTY 24
struct drm_object_properties {
- int count, atomic_count;
+ int count;
/* NOTE: if we ever start dynamically destroying properties (ie.
* not at drm_mode_config_cleanup() time), then we'd have to do
* a better job of detaching property from mode objects to avoid
--
2.9.3
[PATCH 6/9] drm: move drm_mode_legacy_fb_format to drm_fourcc.c
It's part of the drm fourcc handling code, mapping the old depth/bpp
values to new fourcc codes.
Cc: Laurent Pinchart
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 43 ---
drivers/gpu/drm/drm_fourcc.c | 43 +++
include/drm/drm_crtc.h | 2 --
include/drm/drm_fourcc.h | 1 +
4 files changed, 44 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7ec9f7e7a077..59491fc843b6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1666,49 +1666,6 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
return drm_mode_cursor_common(dev, req, file_priv);
}
-/**
- * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
- * @bpp: bits per pixels
- * @depth: bit depth per pixel
- *
- * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
- * Useful in fbdev emulation code, since that deals in those values.
- */
-uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
-{
- uint32_t fmt;
-
- switch (bpp) {
- case 8:
- fmt = DRM_FORMAT_C8;
- break;
- case 16:
- if (depth == 15)
- fmt = DRM_FORMAT_XRGB1555;
- else
- fmt = DRM_FORMAT_RGB565;
- break;
- case 24:
- fmt = DRM_FORMAT_RGB888;
- break;
- case 32:
- if (depth == 24)
- fmt = DRM_FORMAT_XRGB;
- else if (depth == 30)
- fmt = DRM_FORMAT_XRGB2101010;
- else
- fmt = DRM_FORMAT_ARGB;
- break;
- default:
- DRM_ERROR("bad bpp, assuming x8r8g8b8 pixel format\n");
- fmt = DRM_FORMAT_XRGB;
- break;
- }
-
- return fmt;
-}
-EXPORT_SYMBOL(drm_mode_legacy_fb_format);
-
static bool drm_property_type_valid(struct drm_property *property)
{
if (property->flags & DRM_MODE_PROP_EXTENDED_TYPE)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index c81546c15c93..29c56b4331e0 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -36,6 +36,49 @@ static char printable_char(int c)
}
/**
+ * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
+ * @bpp: bits per pixels
+ * @depth: bit depth per pixel
+ *
+ * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
+ * Useful in fbdev emulation code, since that deals in those values.
+ */
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
+{
+ uint32_t fmt;
+
+ switch (bpp) {
+ case 8:
+ fmt = DRM_FORMAT_C8;
+ break;
+ case 16:
+ if (depth == 15)
+ fmt = DRM_FORMAT_XRGB1555;
+ else
+ fmt = DRM_FORMAT_RGB565;
+ break;
+ case 24:
+ fmt = DRM_FORMAT_RGB888;
+ break;
+ case 32:
+ if (depth == 24)
+ fmt = DRM_FORMAT_XRGB;
+ else if (depth == 30)
+ fmt = DRM_FORMAT_XRGB2101010;
+ else
+ fmt = DRM_FORMAT_ARGB;
+ break;
+ default:
+ DRM_ERROR("bad bpp, assuming x8r8g8b8 pixel format\n");
+ fmt = DRM_FORMAT_XRGB;
+ break;
+ }
+
+ return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format);
+
+/**
* drm_get_format_name - return a string for drm fourcc format
* @format: format to compute name of
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b3c3f0c7b449..0c3fa89afd11 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2164,8 +2164,6 @@ extern int drm_mode_crtc_set_gamma_size(struct drm_crtc
*crtc,
extern int drm_mode_set_config_internal(struct drm_mode_set *set);
-extern uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
-
extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device
*dev,
char topology[8]);
extern struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index b106337de1bf..30c30fa87ee8 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -25,6 +25,7 @@
#include
#include
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth, int *bpp);
int drm_format_num_planes(uint32_t format);
int drm_format_plane_cpp(uint32_t format, int plane);
--
2.9.3
[PATCH 8/9] drm: Unify handling of blob and object properties
They work exactly the same now, after the refcounting unification a bit
ago. The only reason they're distinct is backwards compat with existing
userspace.
Cc: Daniel Stone
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_property.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 162cc9032ae5..b5521f705b1c 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -911,20 +911,8 @@ bool drm_property_change_valid_get(struct drm_property
*property,
for (i = 0; i < property->num_values; i++)
valid_mask |= (1ULL << property->values[i]);
return !(value & ~valid_mask);
- } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
- struct drm_property_blob *blob;
-
- if (value == 0)
- return true;
-
- blob = drm_property_lookup_blob(property->dev, value);
- if (blob) {
- *ref = &blob->base;
- return true;
- } else {
- return false;
- }
- } else if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
+ } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB) ||
+ drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
/* a zero value for an object property translates to null: */
if (value == 0)
return true;
@@ -941,13 +929,12 @@ bool drm_property_change_valid_get(struct drm_property
*property,
}
void drm_property_change_valid_put(struct drm_property *property,
- struct drm_mode_object *ref)
+ struct drm_mode_object *ref)
{
if (!ref)
return;
- if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
+ if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT) ||
+ drm_property_type_is(property, DRM_MODE_PROP_BLOB))
drm_mode_object_unreference(ref);
- } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB))
- drm_property_unreference_blob(obj_to_blob(ref));
}
--
2.9.3
dri-devel@lists.freedesktop.org
- remove kerneldoc for drm-internal functions - drm_property_replace_global_blob isn't actually atomic, and doesn't need to be. Update docs&comments to match - document all the types and try to link things a bit better - nits all over v2: Appease checkpatch in the moved code (Archit) Reviewed-by: Archit Taneja Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 88 +- drivers/gpu/drm/drm_property.c | 153 include/drm/drm_property.h | 196 ++--- 3 files changed, 244 insertions(+), 193 deletions(-) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index e07a2667ab61..f9a991bb87d4 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -304,94 +304,12 @@ KMS Locking KMS Properties == -Drivers may need to expose additional parameters to applications than -those described in the previous sections. KMS supports attaching -properties to CRTCs, connectors and planes and offers a userspace API to -list, get and set the property values. - -Properties are identified by a name that uniquely defines the property -purpose, and store an associated value. For all property types except -blob properties the value is a 64-bit unsigned integer. - -KMS differentiates between properties and property instances. Drivers -first create properties and then create and associate individual -instances of those properties to objects. A property can be instantiated -multiple times and associated with different objects. Values are stored -in property instances, and all other property information are stored in -the property and shared between all instances of the property. - -Every property is created with a type that influences how the KMS core -handles the property. Supported property types are - -DRM_MODE_PROP_RANGE -Range properties report their minimum and maximum admissible values. -The KMS core verifies that values set by application fit in that -range. - -DRM_MODE_PROP_ENUM -Enumerated properties take a numerical value that ranges from 0 to -the number of enumerated values defined by the property minus one, -and associate a free-formed string name to each value. Applications -can retrieve the list of defined value-name pairs and use the -numerical value to get and set property instance values. - -DRM_MODE_PROP_BITMASK -Bitmask properties are enumeration properties that additionally -restrict all enumerated values to the 0..63 range. Bitmask property -instance values combine one or more of the enumerated bits defined -by the property. - -DRM_MODE_PROP_BLOB -Blob properties store a binary blob without any format restriction. -The binary blobs are created as KMS standalone objects, and blob -property instance values store the ID of their associated blob -object. - -Blob properties are only used for the connector EDID property and -cannot be created by drivers. - -To create a property drivers call one of the following functions -depending on the property type. All property creation functions take -property flags and name, as well as type-specific arguments. - -- struct drm_property \*drm_property_create_range(struct - drm_device \*dev, int flags, const char \*name, uint64_t min, - uint64_t max); - Create a range property with the given minimum and maximum values. - -- struct drm_property \*drm_property_create_enum(struct drm_device - \*dev, int flags, const char \*name, const struct - drm_prop_enum_list \*props, int num_values); - Create an enumerated property. The ``props`` argument points to an - array of ``num_values`` value-name pairs. - -- struct drm_property \*drm_property_create_bitmask(struct - drm_device \*dev, int flags, const char \*name, const struct - drm_prop_enum_list \*props, int num_values); - Create a bitmask property. The ``props`` argument points to an array - of ``num_values`` value-name pairs. - -Properties can additionally be created as immutable, in which case they -will be read-only for applications but can be modified by the driver. To -create an immutable property drivers must set the -DRM_MODE_PROP_IMMUTABLE flag at property creation time. - -When no array of value-name pairs is readily available at property -creation time for enumerated or range properties, drivers can create the -property using the :c:func:`drm_property_create()` function and -manually add enumeration value-name pairs by calling the -:c:func:`drm_property_add_enum()` function. Care must be taken to -properly specify the property type through the ``flags`` argument. - -After creating properties drivers can attach property instances to CRTC, -connector and plane objects by calling the -:c:func:`drm_object_attach_property()`. The function takes a -pointer to the target object, a pointer to the previously created -property and an initial instance value. - Property Types an
[PATCH 5/9] drm/doc: Polish docs for drm_mode_object
I figured an overview section here is overkill, and better
to just document the 2 structures themselves well enough.
v2: Review from Archit:
- Appease checkpatch in moved code.
- Spelling fixes in the kerneldoc.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_object.c | 17 +
include/drm/drm_mode_object.h | 50 ---
2 files changed, 60 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm/drm_mode_object.c
index a92aeed51156..6edda8382a4c 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -97,7 +97,7 @@ void drm_mode_object_register(struct drm_device *dev,
* for reference counted modeset objects like framebuffers.
*/
void drm_mode_object_unregister(struct drm_device *dev,
-struct drm_mode_object *object)
+ struct drm_mode_object *object)
{
mutex_lock(&dev->mode_config.idr_mutex);
if (object->id) {
@@ -152,7 +152,7 @@ EXPORT_SYMBOL(drm_mode_object_find);
* drm_mode_object_unreference - decr the object refcnt
* @obj: mode_object
*
- * This functions decrements the object's refcount if it is a refcounted
modeset
+ * This function decrements the object's refcount if it is a refcounted modeset
* object. It is a no-op on any other object. This is used to drop references
* acquired with drm_mode_object_reference().
*/
@@ -169,7 +169,7 @@ EXPORT_SYMBOL(drm_mode_object_unreference);
* drm_mode_object_reference - incr the object refcnt
* @obj: mode_object
*
- * This functions increments the object's refcount if it is a refcounted
modeset
+ * This function increments the object's refcount if it is a refcounted modeset
* object. It is a no-op on any other object. References should be dropped
again
* by calling drm_mode_object_unreference().
*/
@@ -218,10 +218,16 @@ EXPORT_SYMBOL(drm_object_attach_property);
* @property: property to set
* @val: value the property should be set to
*
- * This functions sets a given property on a given object. This function only
+ * This function sets a given property on a given object. This function only
* changes the software state of the property, it does not call into the
* driver's ->set_property callback.
*
+ * Note that atomic drivers should not have any need to call this, the core
will
+ * ensure consistency of values reported back to userspace through the
+ * appropriate ->atomic_get_property callback. Only legacy drivers should call
+ * this function to update the tracked value (after clamping and other
+ * restrictions have been applied).
+ *
* Returns:
* Zero on success, error code on failure.
*/
@@ -252,6 +258,9 @@ EXPORT_SYMBOL(drm_object_property_set_value);
* value this might be out of sync with the hardware, depending upon the driver
* and property.
*
+ * Atomic drivers should never call this function directly, the core will read
+ * out property values through the various ->atomic_get_property callbacks.
+ *
* Returns:
* Zero on success, error code on failure.
*/
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index b8adb6425f2a..be3d93839ae2 100644
--- a/include/drm/drm_mode_object.h
+++ b/include/drm/drm_mode_object.h
@@ -27,6 +27,28 @@
struct drm_object_properties;
struct drm_property;
+/**
+ * struct drm_mode_object - base structure for modeset objects
+ * @id: userspace visible identifier
+ * @type: type of the object, one of DRM_MODE_OBJECT\_\*
+ * @properties: properties attached to this object, including values
+ * @refcount: reference count for objects which with dynamic lifetime
+ * @free_cb: free function callback, only set for objects with dynamic lifetime
+ *
+ * Base structure for modeset objects visible to userspace. Objects can be
+ * looked up using drm_mode_object_find(). Besides basic uapi interface
+ * properties like @id and @type it provides two services:
+ *
+ * - It tracks attached properties and their values. This is used by &drm_crtc,
+ * &drm_plane and &drm_connector. Properties are attached by calling
+ * drm_object_attach_property() before the object is visible to userspace.
+ *
+ * - For objects with dynamic lifetimes (as indicated by a non-NULL @free_cb)
it
+ * provides reference counting through drm_mode_object_reference() and
+ * drm_mode_object_unreference(). This is used by &drm_framebuffer,
+ * &drm_connector and &drm_property_blob. These objects provide specialized
+ * reference counting wrappers.
+ */
struct drm_mode_object {
uint32_t id;
uint32_t type;
@@ -36,16 +58,38 @@ struct drm_mode_object {
};
#define DRM_OBJECT_MAX_PROPERTY 24
+/**
+ * struct drm_object_properties - property tracking for &drm_mode_object
+ */
struct drm_object_properties {
+ /**
+* @count: number of valid properties, must be less than or equal to
+* DRM_OBJECT_MAX_PROPERT
[PATCH 7/9] drm: Extract drm_property.[hc]
This just contains the base property classes and all the code to
handle blobs. I think for any kind of standardized/shared properties
it's better to have separate files - this is fairly big already as-is.
v2: resurrect misplaced hunk (Daniel Stone)
Cc: Daniel Stone
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 9 +
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_crtc.c | 926 ---
drivers/gpu/drm/drm_crtc_internal.h | 32 +-
drivers/gpu/drm/drm_property.c | 953
include/drm/drm_crtc.h | 88 +---
include/drm/drm_property.h | 120 +
7 files changed, 1102 insertions(+), 1028 deletions(-)
create mode 100644 drivers/gpu/drm/drm_property.c
create mode 100644 include/drm/drm_property.h
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index b164472f2157..e07a2667ab61 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -389,6 +389,15 @@ connector and plane objects by calling the
pointer to the target object, a pointer to the previously created
property and an initial instance value.
+Property Types and Blob Property Support
+
+
+.. kernel-doc:: include/drm/drm_property.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_property.c
+ :export:
+
Blending and Z-Position properties
--
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8d379565ac8e..439d89b25ae0 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
- drm_encoder.o drm_mode_object.o
+ drm_encoder.o drm_mode_object.o drm_property.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 59491fc843b6..0fad433f4d2d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1666,932 +1666,6 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
return drm_mode_cursor_common(dev, req, file_priv);
}
-static bool drm_property_type_valid(struct drm_property *property)
-{
- if (property->flags & DRM_MODE_PROP_EXTENDED_TYPE)
- return !(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
- return !!(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
-}
-
-/**
- * drm_property_create - create a new property type
- * @dev: drm device
- * @flags: flags specifying the property type
- * @name: name of the property
- * @num_values: number of pre-defined values
- *
- * This creates a new generic drm property which can then be attached to a drm
- * object with drm_object_attach_property. The returned property object must be
- * freed with drm_property_destroy.
- *
- * Note that the DRM core keeps a per-device list of properties and that, if
- * drm_mode_config_cleanup() is called, it will destroy all properties created
- * by the driver.
- *
- * Returns:
- * A pointer to the newly created property on success, NULL on failure.
- */
-struct drm_property *drm_property_create(struct drm_device *dev, int flags,
-const char *name, int num_values)
-{
- struct drm_property *property = NULL;
- int ret;
-
- property = kzalloc(sizeof(struct drm_property), GFP_KERNEL);
- if (!property)
- return NULL;
-
- property->dev = dev;
-
- if (num_values) {
- property->values = kcalloc(num_values, sizeof(uint64_t),
- GFP_KERNEL);
- if (!property->values)
- goto fail;
- }
-
- ret = drm_mode_object_get(dev, &property->base,
DRM_MODE_OBJECT_PROPERTY);
- if (ret)
- goto fail;
-
- property->flags = flags;
- property->num_values = num_values;
- INIT_LIST_HEAD(&property->enum_list);
-
- if (name) {
- strncpy(property->name, name, DRM_PROP_NAME_LEN);
- property->name[DRM_PROP_NAME_LEN-1] = '\0';
- }
-
- list_add_tail(&property->head, &dev->mode_config.property_list);
-
- WARN_ON(!drm_property_type_valid(property));
-
- return property;
-fail:
- kfree(property->values);
- kfree(property);
- return NULL;
-}
-EXPORT_SYMBOL(drm_property_create);
-
-/**
- * drm_property_create_enum - create a new enumeration property type
- * @dev: drm device
- * @flags: flags specifying the property type
- * @name: name of the property
- * @props: enumeration lists with property values
- * @num_values: number of pre-defi
[PATCH 01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait
Am 29.08.2016 um 09:08 schrieb Chris Wilson: > Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a > timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not > need to handle such conversion in the caller. The only challenge are > those callers that wish to differentiate the error code between the > nonblocking busy check and potentially blocking wait. > > Signed-off-by: Chris Wilson > Cc: Alex Deucher > Cc: Christian König Mhm, actually it was one of our developers who added the shortcut into reservation_object_wait_timeout_rcu(). But it looks like we forgot to clean this up in the amdgpu driver after doing this. So thanks for taking care of this. Patch #1 as well as patch #6 are Reviewed-by: Christian König . For patch #6 there is also an use case for this in TTM ttm_bo_add_move_fence(). We could change the lock into an RCU if we can make sure that we get an up to date RCU protected fence and not NULL if the fence becomes freed right at the wrong time. Regards, Christian. > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c > index 88fbed2389c0..a3e6f883ac2c 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c > @@ -407,10 +407,8 @@ int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, > void *data, > return -ENOENT; > } > robj = gem_to_amdgpu_bo(gobj); > - if (timeout == 0) > - ret = reservation_object_test_signaled_rcu(robj->tbo.resv, > true); > - else > - ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, > true, timeout); > + ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, > + timeout); > > /* ret == 0 means not signaled, >* ret > 0 means signaled
[Bug 97530] [HD5650][REDWOOD] kernel commit 8c70e1cda04b966b50ddfefafbd0ea376ed8edd5 causing multiple delays during X server start
https://bugs.freedesktop.org/show_bug.cgi?id=97530 Bug ID: 97530 Summary: [HD5650][REDWOOD] kernel commit 8c70e1cda04b966b50ddfefafbd0ea376ed8edd5 causing multiple delays during X server start Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: Heiko.Lechner at ruhr-uni-bochum.de Created attachment 126096 --> https://bugs.freedesktop.org/attachment.cgi?id=126096&action=edit log before reverting the patch Hi! https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8c70e1cda04b966b50ddfefafbd0ea376ed8edd5 is causing a very long boot delay for me. I attached a Xorg log before and after reverting the patch in the current linux kernel. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/71f5e05a/attachment.html>
[Bug 97530] [HD5650][REDWOOD] kernel commit 8c70e1cda04b966b50ddfefafbd0ea376ed8edd5 causing multiple delays during X server start
https://bugs.freedesktop.org/show_bug.cgi?id=97530 --- Comment #1 from Heiko Lechner --- Created attachment 126097 --> https://bugs.freedesktop.org/attachment.cgi?id=126097&action=edit log after reverting the patch -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/569aafd9/attachment.html>
[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel
Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: > According to basic tests, it looks there is no issue if we don't wait for > DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that, > either. This patch is needed to avoid the annoying warning caused by a > timeout on waiting for the FIFO to clear after we add the new > DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver > which changes the procedure to disable display channel slightly. I suppose the reason this happens is that now DC/DI are disabled first, so the DC can't drain the FIFO anymore. If the FIFO is properly reset when reenabling the DMFC, this shouldn't have any ill effects. regards Philipp
[PATCH v4 3/7] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit
On Mon, Aug 29, 2016 at 4:25 PM, Daniel Vetter wrote: > On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote: >> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter >> of the helper drm_atomic_helper_commit_planes() if the relevant display >> controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes >> when the CRTC is disabled. The helper would skip the ->atomic_disable >> call for a plane if the CRTC of the old plane state needs a modesetting >> operation. Of course, the drivers need to disable the planes in their CRTC >> disable callbacks since no one else would do that. >> >> Suggested-by: Daniel Vetter >> Cc: Philipp Zabel >> Cc: David Airlie >> Cc: Russell King >> Cc: Peter Senna Tschudin >> Cc: Lucas Stach >> Signed-off-by: Liu Ying > > A few small nits below, otherwise looks good. I merged patches 1&2 into > drm-misc already. I'll address all your below comments and send v2 for this one separately. Thanks. Regards, Liu Ying > > Thanks, Daniel > >> --- >> v4: >> * Newly introduced in v4. >> >> drivers/gpu/drm/arm/malidp_drv.c | 3 +- >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- >> drivers/gpu/drm/drm_atomic_helper.c | 46 >> >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- >> drivers/gpu/drm/imx/imx-drm-core.c | 3 +- >> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++-- >> drivers/gpu/drm/msm/msm_atomic.c | 2 +- >> drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- >> drivers/gpu/drm/rcar-du/rcar_du_kms.c| 3 +- >> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +- >> drivers/gpu/drm/sti/sti_drv.c| 2 +- >> drivers/gpu/drm/tegra/drm.c | 3 +- >> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +- >> drivers/gpu/drm/vc4/vc4_kms.c| 2 +- >> drivers/gpu/drm/virtio/virtgpu_display.c | 3 +- >> include/drm/drm_atomic_helper.h | 6 +++- >> 16 files changed, 61 insertions(+), 29 deletions(-) >> >> diff --git a/drivers/gpu/drm/arm/malidp_drv.c >> b/drivers/gpu/drm/arm/malidp_drv.c >> index 82171d2..c383d72 100644 >> --- a/drivers/gpu/drm/arm/malidp_drv.c >> +++ b/drivers/gpu/drm/arm/malidp_drv.c >> @@ -91,7 +91,8 @@ static void malidp_atomic_commit_tail(struct >> drm_atomic_state *state) >> >> drm_atomic_helper_commit_modeset_disables(drm, state); >> drm_atomic_helper_commit_modeset_enables(drm, state); >> - drm_atomic_helper_commit_planes(drm, state, true); >> + drm_atomic_helper_commit_planes(drm, state, >> + DRM_PLANE_COMMIT_ACTIVE_ONLY); >> >> malidp_atomic_commit_hw_done(state); >> >> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c >> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c >> index d4a3d61..8e7483d 100644 >> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c >> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c >> @@ -457,7 +457,7 @@ atmel_hlcdc_dc_atomic_complete(struct >> atmel_hlcdc_dc_commit *commit) >> >> /* Apply the atomic update. */ >> drm_atomic_helper_commit_modeset_disables(dev, old_state); >> - drm_atomic_helper_commit_planes(dev, old_state, false); >> + drm_atomic_helper_commit_planes(dev, old_state, 0); >> drm_atomic_helper_commit_modeset_enables(dev, old_state); >> >> drm_atomic_helper_wait_for_vblanks(dev, old_state); >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c >> b/drivers/gpu/drm/drm_atomic_helper.c >> index 30c52a8..cf19b6e 100644 >> --- a/drivers/gpu/drm/drm_atomic_helper.c >> +++ b/drivers/gpu/drm/drm_atomic_helper.c >> @@ -1148,7 +1148,8 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks); >> * >> * drm_atomic_helper_commit_modeset_enables(dev, state); >> * >> - * drm_atomic_helper_commit_planes(dev, state, true); >> + * drm_atomic_helper_commit_planes(dev, state, >> + * DRM_PLANE_COMMIT_ACTIVE_ONLY); >> * >> * for committing the atomic update to hardware. See the kerneldoc entries >> for >> * these three functions for more details. >> @@ -1159,7 +1160,7 @@ void drm_atomic_helper_commit_tail(struct >> drm_atomic_state *state) >> >> drm_atomic_helper_commit_modeset_disables(dev, state); >> >> - drm_atomic_helper_commit_planes(dev, state, false); >> + drm_atomic_helper_commit_planes(dev, state, 0); >> >> drm_atomic_helper_commit_modeset_enables(dev, state); >> >> @@ -1678,7 +1679,7 @@ bool plane_crtc_active(struct drm_plane_state *state) >> * drm_atomic_helper_commit_planes - commit plane state >> * @dev: DRM device >> * @old_state: atomic state object with old state structures >> - * @active_only: Only commit on active CRTC if set >> + * @flags: flags for committing plane state >> * >> * This function commits the new plane state using the plane and atomic >> helper >> * functions for planes and crtcs. It assumes that the at
Skylake underruns on 4.8-rc4
My Dell XPS 13 9350 laptop just got a buffer underrun: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun I'm seeing this very occasionally, and they don't come in groups -- I seem to get one underrun with a black flash and that's it. This is with just the laptop screen -- nothing at all is plugged in to the USB-C port. 4.8-rc4 has the latest round of fixes applied, so i915/skl_dmc_ver1_26.bin loaded successfully and the SAGV fix is there. I had the same problem on 4.8-rc3. 4.7 seemed okay. I have: 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07) --Andy
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 Kontantin Ivanov changed: What|Removed |Added Severity|low |normal -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit
Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
of the helper drm_atomic_helper_commit_planes() if the relevant display
controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
when the CRTC is disabled. The helper would skip the ->atomic_disable
call for a plane if the CRTC of the old plane state needs a modesetting
operation. Of course, the drivers need to disable the planes in their CRTC
disable callbacks since no one else would do that.
Suggested-by: Daniel Vetter
Cc: Philipp Zabel
Cc: David Airlie
Cc: Russell King
Cc: Peter Senna Tschudin
Cc: Lucas Stach
Signed-off-by: Liu Ying
---
I choose to pick this patch from the patch set[1] so that I may address
Daniel Vetter's comments conveniently by sending v2 for it alone.
[1] http://www.spinics.net/lists/dri-devel/msg116491.html
v1->v2:
* Add a newline in the kernel-doc for drm_atomic_helper_commit_planes()
to improve readability.
* Remove unecessary check/warn on crtc_state before passing it over to
drm_atomic_crtc_needs_modeset().
* Wrap plane_funcs->atomic_update with {} to make checkpatch happy.
drivers/gpu/drm/arm/malidp_drv.c | 3 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
drivers/gpu/drm/drm_atomic_helper.c | 43
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
drivers/gpu/drm/imx/imx-drm-core.c | 3 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++--
drivers/gpu/drm/msm/msm_atomic.c | 2 +-
drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c| 3 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +-
drivers/gpu/drm/sti/sti_drv.c| 2 +-
drivers/gpu/drm/tegra/drm.c | 3 +-
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
drivers/gpu/drm/vc4/vc4_kms.c| 2 +-
drivers/gpu/drm/virtio/virtgpu_display.c | 3 +-
include/drm/drm_atomic_helper.h | 6 +++-
16 files changed, 59 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 82171d2..c383d72 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -91,7 +91,8 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state
*state)
drm_atomic_helper_commit_modeset_disables(drm, state);
drm_atomic_helper_commit_modeset_enables(drm, state);
- drm_atomic_helper_commit_planes(drm, state, true);
+ drm_atomic_helper_commit_planes(drm, state,
+ DRM_PLANE_COMMIT_ACTIVE_ONLY);
malidp_atomic_commit_hw_done(state);
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index d4a3d61..8e7483d 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -457,7 +457,7 @@ atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit
*commit)
/* Apply the atomic update. */
drm_atomic_helper_commit_modeset_disables(dev, old_state);
- drm_atomic_helper_commit_planes(dev, old_state, false);
+ drm_atomic_helper_commit_planes(dev, old_state, 0);
drm_atomic_helper_commit_modeset_enables(dev, old_state);
drm_atomic_helper_wait_for_vblanks(dev, old_state);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 5f82290..6fdd7ba 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1148,7 +1148,8 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
*
* drm_atomic_helper_commit_modeset_enables(dev, state);
*
- * drm_atomic_helper_commit_planes(dev, state, true);
+ * drm_atomic_helper_commit_planes(dev, state,
+ * DRM_PLANE_COMMIT_ACTIVE_ONLY);
*
* for committing the atomic update to hardware. See the kerneldoc entries for
* these three functions for more details.
@@ -1159,7 +1160,7 @@ void drm_atomic_helper_commit_tail(struct
drm_atomic_state *state)
drm_atomic_helper_commit_modeset_disables(dev, state);
- drm_atomic_helper_commit_planes(dev, state, false);
+ drm_atomic_helper_commit_planes(dev, state, 0);
drm_atomic_helper_commit_modeset_enables(dev, state);
@@ -1678,7 +1679,7 @@ bool plane_crtc_active(struct drm_plane_state *state)
* drm_atomic_helper_commit_planes - commit plane state
* @dev: DRM device
* @old_state: atomic state object with old state structures
- * @active_only: Only commit on active CRTC if set
+ * @flags: flags for committing plane state
*
* This function commits the new plane state using the plane and atomic helper
* functions for planes and crtcs. It assumes that the atomic state has already
@@ -1698,25 +1699,34 @@ bool plane_crtc_active(struct drm_plane_state *state)
* most drivers don't need to be immediately notified of plan
[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel
On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel wrote: > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: >> According to basic tests, it looks there is no issue if we don't wait for >> DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that, >> either. This patch is needed to avoid the annoying warning caused by a >> timeout on waiting for the FIFO to clear after we add the new >> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver >> which changes the procedure to disable display channel slightly. > > I suppose the reason this happens is that now DC/DI are disabled first, > so the DC can't drain the FIFO anymore. If the FIFO is properly reset > when reenabling the DMFC, this shouldn't have any ill effects. I found the timeout warning issue by blanking the framebuffer. Ofc, the framebuffer is supported by the fbdev emulation. Before applying this patch set, the planes are not even disabled when the framebuffer is blanked, that is to say, plane_funcs-> atomic_disable is not called - the CRTC is disabled alone. After applying this patch set, the planes are always disabled together with the CRTC. And, yes, DC/DI are disabled first, then the timeout warning happens. Please note the warning happens when the planes are disabled instead of reenabled. So, I don't get your point by resetting FIFO when _reenabling_ DMFC. And, I don't see the way to reset FIFO. Regards, Liu Ying > > regards > Philipp >
[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel
Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu: > On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel > wrote: > > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: > >> According to basic tests, it looks there is no issue if we don't wait for > >> DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that, > >> either. This patch is needed to avoid the annoying warning caused by a > >> timeout on waiting for the FIFO to clear after we add the new > >> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver > >> which changes the procedure to disable display channel slightly. > > > > I suppose the reason this happens is that now DC/DI are disabled first, > > so the DC can't drain the FIFO anymore. If the FIFO is properly reset > > when reenabling the DMFC, this shouldn't have any ill effects. > > I found the timeout warning issue by blanking the framebuffer. > Ofc, the framebuffer is supported by the fbdev emulation. > Before applying this patch set, the planes are not even disabled > when the framebuffer is blanked, that is to say, plane_funcs-> > atomic_disable is not called - the CRTC is disabled alone. > After applying this patch set, the planes are always disabled > together with the CRTC. And, yes, DC/DI are disabled first, > then the timeout warning happens. > > Please note the warning happens when the planes are disabled > instead of reenabled. So, I don't get your point by resetting > FIFO when _reenabling_ DMFC. If we disable the DMFC with data still in the FIFO and then reenable it and the DC first reads the stale data from the FIFO, that should cause a visible artifact in the first frame after reenabling the plane. If that doesn't happen, I trust that the hardware resets the FIFO state somewhere along the way. > And, I don't see the way to reset FIFO. We could reset the DMFC_WR memory after disabling the DMFC, but I'm not sure this is necessary at all. regards Philipp
[PATCH 1/2] drm/imx: imx-ldb: detach bridge on unbind
Don't leave the bridge attached to a stale driver instance when
unbinding, to allow reattachment on a rebind.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-ldb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 33a7613..b300998 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -745,6 +745,8 @@ static void imx_ldb_unbind(struct device *dev, struct
device *master,
for (i = 0; i < 2; i++) {
struct imx_ldb_channel *channel = &imx_ldb->channel[i];
+ if (channel->bridge)
+ drm_bridge_detach(channel->bridge);
if (channel->panel)
drm_panel_detach(channel->panel);
--
2.8.1
[PATCH 2/2] drm/imx: parallel-display: detach bridge or panel on unbind
Don't leave any bridge or panel attached to a stale driver instance
when unbinding, to allow reattachment on a rebind.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/parallel-display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/drivers/gpu/drm/imx/parallel-display.c
index f203337..d796ada 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -293,6 +293,11 @@ static void imx_pd_unbind(struct device *dev, struct
device *master,
{
struct imx_parallel_display *imxpd = dev_get_drvdata(dev);
+ if (imxpd->bridge)
+ drm_bridge_detach(imxpd->bridge);
+ if (imxpd->panel)
+ drm_panel_detach(imxpd->panel);
+
kfree(imxpd->edid);
}
--
2.8.1
[Bug 97119] screen flickerin under KDE when compositor was dis- and reenabled
https://bugs.freedesktop.org/show_bug.cgi?id=97119
--- Comment #14 from Michel Dänzer ---
Which 'Tearing prevention ("vsync")' mode are you using in the kwin compositor
settings? Maybe attach a screenshot of that settings page.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/25d8573f/attachment.html>
[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel
On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel wrote: > Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu: >> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel >> wrote: >> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: >> >> According to basic tests, it looks there is no issue if we don't wait for >> >> DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that, >> >> either. This patch is needed to avoid the annoying warning caused by a >> >> timeout on waiting for the FIFO to clear after we add the new >> >> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver >> >> which changes the procedure to disable display channel slightly. >> > >> > I suppose the reason this happens is that now DC/DI are disabled first, >> > so the DC can't drain the FIFO anymore. If the FIFO is properly reset >> > when reenabling the DMFC, this shouldn't have any ill effects. >> >> I found the timeout warning issue by blanking the framebuffer. >> Ofc, the framebuffer is supported by the fbdev emulation. >> Before applying this patch set, the planes are not even disabled >> when the framebuffer is blanked, that is to say, plane_funcs-> >> atomic_disable is not called - the CRTC is disabled alone. >> After applying this patch set, the planes are always disabled >> together with the CRTC. And, yes, DC/DI are disabled first, >> then the timeout warning happens. >> >> Please note the warning happens when the planes are disabled >> instead of reenabled. So, I don't get your point by resetting >> FIFO when _reenabling_ DMFC. > > If we disable the DMFC with data still in the FIFO and then reenable it > and the DC first reads the stale data from the FIFO, that should cause a > visible artifact in the first frame after reenabling the plane. If that > doesn't happen, I trust that the hardware resets the FIFO state > somewhere along the way. Not sure if the hardware resets the FIFO automatically... The NXP driver waits for some hardware status/irqs when disabling the channels, but it doesn't wait for DMFC status. > >> And, I don't see the way to reset FIFO. > > We could reset the DMFC_WR memory after disabling the DMFC, but I'm not > sure this is necessary at all. You mean the register DMFC_WR_CHAN, for instance? I still don't see how we could reset the FIFO. Regards, Liu Ying > > regards > Philipp >
[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel
Am Montag, den 29.08.2016, 17:57 +0800 schrieb Ying Liu: > On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel > wrote: > > Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu: > >> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel > >> wrote: > >> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: > >> >> According to basic tests, it looks there is no issue if we don't wait > >> >> for > >> >> DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do > >> >> that, > >> >> either. This patch is needed to avoid the annoying warning caused by a > >> >> timeout on waiting for the FIFO to clear after we add the new > >> >> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver > >> >> which changes the procedure to disable display channel slightly. > >> > > >> > I suppose the reason this happens is that now DC/DI are disabled first, > >> > so the DC can't drain the FIFO anymore. If the FIFO is properly reset > >> > when reenabling the DMFC, this shouldn't have any ill effects. > >> > >> I found the timeout warning issue by blanking the framebuffer. > >> Ofc, the framebuffer is supported by the fbdev emulation. > >> Before applying this patch set, the planes are not even disabled > >> when the framebuffer is blanked, that is to say, plane_funcs-> > >> atomic_disable is not called - the CRTC is disabled alone. > >> After applying this patch set, the planes are always disabled > >> together with the CRTC. And, yes, DC/DI are disabled first, > >> then the timeout warning happens. > >> > >> Please note the warning happens when the planes are disabled > >> instead of reenabled. So, I don't get your point by resetting > >> FIFO when _reenabling_ DMFC. > > > > If we disable the DMFC with data still in the FIFO and then reenable it > > and the DC first reads the stale data from the FIFO, that should cause a > > visible artifact in the first frame after reenabling the plane. If that > > doesn't happen, I trust that the hardware resets the FIFO state > > somewhere along the way. > > Not sure if the hardware resets the FIFO automatically... > The NXP driver waits for some hardware status/irqs when disabling > the channels, but it doesn't wait for DMFC status. > > > > >> And, I don't see the way to reset FIFO. > > > > We could reset the DMFC_WR memory after disabling the DMFC, but I'm not > > sure this is necessary at all. > > You mean the register DMFC_WR_CHAN, for instance? > I still don't see how we could reset the FIFO. I mean via IPU_MEM_RST. I'll send a patch to illustrate, but as I said, I don't know if this is really useful. regards Philipp
[RFC 1/2] gpu: ipu-v3: export memory reset function
Add defines for the memory reset bits and export the memory reset
function to IPU modules.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 17 +
drivers/gpu/ipu-v3/ipu-prv.h| 24
2 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 5e7af61..1ad33df 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -706,14 +706,14 @@ void ipu_idmac_enable_watermark(struct ipuv3_channel
*channel, bool enable)
}
EXPORT_SYMBOL_GPL(ipu_idmac_enable_watermark);
-static int ipu_memory_reset(struct ipu_soc *ipu)
+int ipu_memory_reset(struct ipu_soc *ipu, u32 rst_mem)
{
unsigned long timeout;
- ipu_cm_write(ipu, 0x807F, IPU_MEM_RST);
+ ipu_cm_write(ipu, rst_mem | IPU_RST_MEM_START, IPU_MEM_RST);
timeout = jiffies + msecs_to_jiffies(1000);
- while (ipu_cm_read(ipu, IPU_MEM_RST) & 0x8000) {
+ while (ipu_cm_read(ipu, IPU_MEM_RST) & IPU_RST_MEM_START) {
if (time_after(jiffies, timeout))
return -ETIME;
cpu_relax();
@@ -1363,7 +1363,16 @@ static int ipu_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failed to reset: %d\n", ret);
goto out_failed_reset;
}
- ret = ipu_memory_reset(ipu);
+ ret = ipu_memory_reset(ipu, IPU_RST_MEM_SRM | IPU_RST_MEM_ALPHA |
+ IPU_RST_MEM_CPMEM | IPU_RST_MEM_TPM |
+ IPU_RST_MEM_MPM | IPU_RST_MEM_BM |
+ IPU_RST_MEM_RM | IPU_RST_MEM_DSTM |
+ IPU_RST_MEM_DSOM | IPU_RST_MEM_LUT0 |
+ IPU_RST_MEM_LUT1 | IPU_RST_MEM_RAM_SMFC |
+ IPU_RST_MEM_VDI_FIFO2 | IPU_RST_MEM_VDI_FIFO3 |
+ IPU_RST_MEM_ICB | IPU_RST_MEM_VDI_FIFO1 |
+ IPU_RST_MEM_DC_TEMPLATE | IPU_RST_MEM_DMFC_RD |
+ IPU_RST_MEM_DMFC_WR);
if (ret)
goto out_failed_reset;
#endif
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index 6803cc7..8e9ef56 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -75,6 +75,28 @@ struct ipu_soc;
#define IPU_INT_CTRL(n)IPU_CM_REG(0x003C + 4 * (n))
#define IPU_INT_STAT(n)IPU_CM_REG(0x0200 + 4 * (n))
+#define IPU_RST_MEM_SRMBIT(0)
+#define IPU_RST_MEM_ALPHA BIT(1)
+#define IPU_RST_MEM_CPMEM BIT(2)
+#define IPU_RST_MEM_TPMBIT(3)
+#define IPU_RST_MEM_MPMBIT(4)
+#define IPU_RST_MEM_BM BIT(5)
+#define IPU_RST_MEM_RM BIT(6)
+#define IPU_RST_MEM_DSTM BIT(7)
+#define IPU_RST_MEM_DSOM BIT(8)
+#define IPU_RST_MEM_LUT0 BIT(9)
+#define IPU_RST_MEM_LUT1 BIT(10)
+#define IPU_RST_MEM_RAM_SMFC BIT(11)
+#define IPU_RST_MEM_VDI_FIFO2 BIT(12)
+#define IPU_RST_MEM_VDI_FIFO3 BIT(13)
+#define IPU_RST_MEM_ICBBIT(14)
+#define IPU_RST_MEM_VDI_FIFO1 BIT(15)
+#define IPU_RST_MEM_DC_TEMPLATEBIT(20)
+#define IPU_RST_MEM_DMFC_RDBIT(21)
+#define IPU_RST_MEM_DMFC_WRBIT(22)
+
+#define IPU_RST_MEM_START BIT(31)
+
#define IPU_DI0_COUNTER_RELEASE(1 << 24)
#define IPU_DI1_COUNTER_RELEASE(1 << 25)
@@ -401,6 +423,8 @@ static inline void ipu_idmac_write(struct ipu_soc *ipu, u32
value,
void ipu_srm_dp_sync_update(struct ipu_soc *ipu);
+int ipu_memory_reset(struct ipu_soc *ipu, u32 rst_mem);
+
int ipu_module_enable(struct ipu_soc *ipu, u32 mask);
int ipu_module_disable(struct ipu_soc *ipu, u32 mask);
--
2.8.1
[RFC 2/2] gpu: ipu-v3: reset DMFC memory when disabling
Reset the write FIFO memories after disabling the DMFC
to make sure no stale data is kept around.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-dmfc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c
index a40f211..e1e5506 100644
--- a/drivers/gpu/ipu-v3/ipu-dmfc.c
+++ b/drivers/gpu/ipu-v3/ipu-dmfc.c
@@ -131,8 +131,10 @@ void ipu_dmfc_disable_channel(struct dmfc_channel *dmfc)
priv->use_count--;
- if (!priv->use_count)
+ if (!priv->use_count) {
ipu_module_disable(priv->ipu, IPU_CONF_DMFC_EN);
+ ipu_memory_reset(priv->ipu, IPU_RST_MEM_DMFC_WR);
+ }
if (priv->use_count < 0)
priv->use_count = 0;
--
2.8.1
[PATCH 1/2] drm/etnaviv: fail probe if core or bus clock are absent
Am Freitag, den 26.08.2016, 17:10 +0100 schrieb Russell King - ARM Linux: > On Fri, Aug 26, 2016 at 05:49:54PM +0200, Lucas Stach wrote: > > The devicetree documentation states that those are required properties, > > so the driver should refuse to probe if those are absent to be > > consistent. This will also allow to drop some error checking from the > > clock enable/disable paths. > > NAK. > > Thanks for reviewing the existing DT files before proposing this change > and noticing that you're going to wilfully end up breaking existing users. > A simple grep would have sufficed. > Gah, thanks for pointing this out. > The DT binding doc is wrong: there is only one documented clock on Dove > and that's for the GPU core. (The Dove documentation as far as clocks > go is very poor.) So, what's Dove supposed to do - make up some > ficticious clock? > Core, bus and shader are all module input clocks. If the SoC integration provides the same clock for all inputs, the DT should reflect this by supplying the same clock for all 3 inputs. I'm going to change this patch to keep things working for the Dove DTs, but I think they really should be changed to supply all 3 input clocks. I'm sorry for not noticing this when you proposed the Dove GPU DT support. Regards, Lucas
[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support
Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: > This patch adds active plane reconfiguration support for imx-drm. > This may fixes some mode setting failure issues which were introduced > by imx-drm atomic conversion patch set. The main idea is to disable the > plane in question in CRTC's atomic_disable operation and then the drm > atomic core will enable it again automatically. I have rebased onto drm-misc and picked up the remaining patches (4-7) regards Philipp > v3->v4: > * Change the bool active_only parameter of commit_planes() to an uint32_t > parameter named 'flags' and add two flags - DRM_PLANE_COMMIT_ACTIVE_ONLY > and DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET. This way, the drm atomic > core is able to skip the atomic_disable call for the planes which are > committed with the NO_DISABLE_AFTER_MODESET flag set. > * Fix the helper disable_planes_on_crtc(), which is needed for CRTC's > atomic_disable callback to disable planes. > * Improve kernel-doc of CRTC's atomic_disable callback to address Daniel > Vetter's comment. > * Do not wait for DMFC FIFO to clear to avoid timeout warning, as the > precedure to disable display channel is changed slightly after the > NO_DISABLE_AFTER_MODESET flag is used. > > v2->v3: > * Disable all appropriate affected planes(when necessary) in CRTC's > ->atomic_disable callback, but not in each plane's ->atomic_update callback, > as suggested by Daniel Vetter. > * +Cc Lucas Stach, as he tested the patch v2. > > v1->v2: > * Do not reject reconfiguring an active overlay plane. > > Liu Ying (7): > drm/atomic-helper: Add atomic_disable CRTC helper callback > drm/atomic-helper: Disable appropriate planes in > disable_planes_on_crtc() > drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane > commit > gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC > channel > drm/imx: ipuv3-crtc: Use the callback ->atomic_disable instead of > ->disable > drm/imx: Use DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag > drm/imx: Add active plane reconfiguration support > > drivers/gpu/drm/arm/malidp_drv.c | 3 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- > drivers/gpu/drm/drm_atomic_helper.c | 64 > +++- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > drivers/gpu/drm/imx/imx-drm-core.c | 30 - > drivers/gpu/drm/imx/ipuv3-crtc.c | 8 +++- > drivers/gpu/drm/imx/ipuv3-plane.c| 21 ++--- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++- > drivers/gpu/drm/msm/msm_atomic.c | 2 +- > drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c| 3 +- > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +- > drivers/gpu/drm/sti/sti_drv.c| 2 +- > drivers/gpu/drm/tegra/drm.c | 3 +- > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +- > drivers/gpu/drm/vc4/vc4_kms.c| 2 +- > drivers/gpu/drm/virtio/virtgpu_display.c | 3 +- > drivers/gpu/ipu-v3/ipu-dmfc.c| 18 +--- > include/drm/drm_atomic_helper.h | 11 +++-- > include/drm/drm_modeset_helper_vtables.h | 24 +++ > 20 files changed, 146 insertions(+), 65 deletions(-) >
[PATCH 1/5] drm/imx: don't call disable_plane in plane destroy path
Am Donnerstag, den 11.08.2016, 11:18 +0200 schrieb Lucas Stach:
> When the destroy path is called the plane should already be
> disabled. If not, this is a core bug and should not be worked
> around in the driver.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/imx/ipuv3-plane.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 4ad67d015ec7..6cc809e1ca55 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -242,7 +242,6 @@ static void ipu_plane_destroy(struct drm_plane *plane)
>
> DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>
> - ipu_disable_plane(plane);
> drm_plane_cleanup(plane);
> kfree(ipu_plane);
> }
Applied all 5.
regards
Philipp
[PATCH] drm/fb-helper: don't call remove_conflicting_framebuffers for FB=m && DRM=y
When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration
in which some DRM drivers are built-in, but the framebuffer core is a
loadable module. This results in a link error, such as:
drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe':
radeon_kfd.c:(.text.radeon_pci_probe+0xbc): undefined reference to
`remove_conflicting_framebuffers'
drivers/gpu/drm/amd/amdgpu/amdgpu.o: In function `amdgpu_pci_probe':
amdgpu_mn.c:(.text.amdgpu_pci_probe+0xa8): undefined reference to
`remove_conflicting_framebuffers'
drivers/gpu/drm/mgag200/mgag200.o: In function `mga_vram_init':
mgag200_ttm.c:(.text.mga_vram_init+0xa8): undefined reference to
`remove_conflicting_framebuffers'
drivers/gpu/drm/mgag200/mgag200.o: In function `mga_pci_probe':
mgag200_ttm.c:(.text.mga_pci_probe+0x88): undefined reference to
`remove_conflicting_framebuffers'
Makefile:969: recipe for target 'vmlinux' failed
This changes the compile-time check to IS_REACHABLE, which means we end up
not calling remove_conflicting_framebuffers() in the configuration, which
seems good enough, as we know that no framebuffer driver is loaded by the
time that the built-in DRM driver calls remove_conflicting_framebuffers.
We could alternatively avoid the link error by forcing CONFIG_FB to not
be a module in this case, but that wouldn't change anything at runtime,
and just make the already convoluted set of dependencies worse here.
I could not find out what happens if the fbdev driver gets loaded as
a module after the DRM driver is already initialized, but that is a case
that can happen with or without this patch.
Signed-off-by: Arnd Bergmann
Fixes: 0a3bfe29f816 ("drm/fb-helper: Fix the dummy
remove_conflicting_framebuffers")
---
include/drm/drm_fb_helper.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index edc6cfd3aa34..797fb5f80c45 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -491,7 +491,7 @@ static inline int
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
const char *name, bool primary)
{
-#if IS_ENABLED(CONFIG_FB)
+#if IS_REACHABLE(CONFIG_FB)
return remove_conflicting_framebuffers(a, name, primary);
#else
return 0;
--
2.9.0
[Bug 97249] R290x combined with Mg279q, Dp link fail in ubuntu-multihead setup.
https://bugs.freedesktop.org/show_bug.cgi?id=97249 Vedran MiletiÄ changed: What|Removed |Added CC||vedran at miletic.net --- Comment #6 from Vedran MiletiÄ --- Can you try a newer kernel? 4.7 at least. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/6415174a/attachment.html>
[PATCH] drm/fb-helper: don't call remove_conflicting_framebuffers for FB=m && DRM=y
On Mon, Aug 29, 2016 at 02:34:07PM +0200, Arnd Bergmann wrote:
> When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration
> in which some DRM drivers are built-in, but the framebuffer core is a
> loadable module. This results in a link error, such as:
>
> drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe':
> radeon_kfd.c:(.text.radeon_pci_probe+0xbc): undefined reference to
> `remove_conflicting_framebuffers'
> drivers/gpu/drm/amd/amdgpu/amdgpu.o: In function `amdgpu_pci_probe':
> amdgpu_mn.c:(.text.amdgpu_pci_probe+0xa8): undefined reference to
> `remove_conflicting_framebuffers'
> drivers/gpu/drm/mgag200/mgag200.o: In function `mga_vram_init':
> mgag200_ttm.c:(.text.mga_vram_init+0xa8): undefined reference to
> `remove_conflicting_framebuffers'
> drivers/gpu/drm/mgag200/mgag200.o: In function `mga_pci_probe':
> mgag200_ttm.c:(.text.mga_pci_probe+0x88): undefined reference to
> `remove_conflicting_framebuffers'
> Makefile:969: recipe for target 'vmlinux' failed
>
> This changes the compile-time check to IS_REACHABLE, which means we end up
> not calling remove_conflicting_framebuffers() in the configuration, which
> seems good enough, as we know that no framebuffer driver is loaded by the
> time that the built-in DRM driver calls remove_conflicting_framebuffers.
>
> We could alternatively avoid the link error by forcing CONFIG_FB to not
> be a module in this case, but that wouldn't change anything at runtime,
> and just make the already convoluted set of dependencies worse here.
>
> I could not find out what happens if the fbdev driver gets loaded as
> a module after the DRM driver is already initialized, but that is a case
> that can happen with or without this patch.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 0a3bfe29f816 ("drm/fb-helper: Fix the dummy
> remove_conflicting_framebuffers")
Applied to drm-misc, thanks.
-Daniel
> ---
> include/drm/drm_fb_helper.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index edc6cfd3aa34..797fb5f80c45 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -491,7 +491,7 @@ static inline int
> drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primary)
> {
> -#if IS_ENABLED(CONFIG_FB)
> +#if IS_REACHABLE(CONFIG_FB)
> return remove_conflicting_framebuffers(a, name, primary);
> #else
> return 0;
> --
> 2.9.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit
On Mon, Aug 29, 2016 at 05:12:03PM +0800, Liu Ying wrote:
> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
> of the helper drm_atomic_helper_commit_planes() if the relevant display
> controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
> when the CRTC is disabled. The helper would skip the ->atomic_disable
> call for a plane if the CRTC of the old plane state needs a modesetting
> operation. Of course, the drivers need to disable the planes in their CRTC
> disable callbacks since no one else would do that.
>
> Suggested-by: Daniel Vetter
> Cc: Philipp Zabel
> Cc: David Airlie
> Cc: Russell King
> Cc: Peter Senna Tschudin
> Cc: Lucas Stach
> Signed-off-by: Liu Ying
Applied to drm-misc, thanks. I'll send a pull request with it to Dave
later this week to avoid blocking any driver pulls from you side.
-Daniel
> ---
> I choose to pick this patch from the patch set[1] so that I may address
> Daniel Vetter's comments conveniently by sending v2 for it alone.
>
> [1] http://www.spinics.net/lists/dri-devel/msg116491.html
>
> v1->v2:
> * Add a newline in the kernel-doc for drm_atomic_helper_commit_planes()
> to improve readability.
> * Remove unecessary check/warn on crtc_state before passing it over to
> drm_atomic_crtc_needs_modeset().
> * Wrap plane_funcs->atomic_update with {} to make checkpatch happy.
>
> drivers/gpu/drm/arm/malidp_drv.c | 3 +-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
> drivers/gpu/drm/drm_atomic_helper.c | 43
>
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
> drivers/gpu/drm/imx/imx-drm-core.c | 3 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++--
> drivers/gpu/drm/msm/msm_atomic.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_du_kms.c| 3 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +-
> drivers/gpu/drm/sti/sti_drv.c| 2 +-
> drivers/gpu/drm/tegra/drm.c | 3 +-
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
> drivers/gpu/drm/vc4/vc4_kms.c| 2 +-
> drivers/gpu/drm/virtio/virtgpu_display.c | 3 +-
> include/drm/drm_atomic_helper.h | 6 +++-
> 16 files changed, 59 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 82171d2..c383d72 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -91,7 +91,8 @@ static void malidp_atomic_commit_tail(struct
> drm_atomic_state *state)
>
> drm_atomic_helper_commit_modeset_disables(drm, state);
> drm_atomic_helper_commit_modeset_enables(drm, state);
> - drm_atomic_helper_commit_planes(drm, state, true);
> + drm_atomic_helper_commit_planes(drm, state,
> + DRM_PLANE_COMMIT_ACTIVE_ONLY);
>
> malidp_atomic_commit_hw_done(state);
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index d4a3d61..8e7483d 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -457,7 +457,7 @@ atmel_hlcdc_dc_atomic_complete(struct
> atmel_hlcdc_dc_commit *commit)
>
> /* Apply the atomic update. */
> drm_atomic_helper_commit_modeset_disables(dev, old_state);
> - drm_atomic_helper_commit_planes(dev, old_state, false);
> + drm_atomic_helper_commit_planes(dev, old_state, 0);
> drm_atomic_helper_commit_modeset_enables(dev, old_state);
>
> drm_atomic_helper_wait_for_vblanks(dev, old_state);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5f82290..6fdd7ba 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1148,7 +1148,8 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
> *
> * drm_atomic_helper_commit_modeset_enables(dev, state);
> *
> - * drm_atomic_helper_commit_planes(dev, state, true);
> + * drm_atomic_helper_commit_planes(dev, state,
> + * DRM_PLANE_COMMIT_ACTIVE_ONLY);
> *
> * for committing the atomic update to hardware. See the kerneldoc entries
> for
> * these three functions for more details.
> @@ -1159,7 +1160,7 @@ void drm_atomic_helper_commit_tail(struct
> drm_atomic_state *state)
>
> drm_atomic_helper_commit_modeset_disables(dev, state);
>
> - drm_atomic_helper_commit_planes(dev, state, false);
> + drm_atomic_helper_commit_planes(dev, state, 0);
>
> drm_atomic_helper_commit_modeset_enables(dev, state);
>
> @@ -1678,7 +1679,7 @@ bool plane_crtc_active(struct drm_plane_state *state)
> * drm_atomic_helper_commit_planes - commit plane state
> * @dev: DRM device
> * @old_state: atomic state object with old state structures
>
[PATCH v2] amdgpu, radeon: Add amdkfd softdep
Both amdgpu and radeon load amdkfd via symbol_request(). Add a softdep
hint so that userspace knows that each of them needs amdkfd in the
initrd.
Reported-and-tested-by: Martin Jambor [amdgpu]
Reported-by: Michel Dänzer [radeon]
Signed-off-by: Michal Marek
---
v2: Also patch radeon
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
drivers/gpu/drm/radeon/radeon_drv.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 9aa533cf4ad1..9c469cd311ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -633,3 +633,4 @@ module_exit(amdgpu_exit);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL and additional rights");
+MODULE_SOFTDEP("pre: amdkfd");
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index c01a7c6abb49..0a60125c0138 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -617,3 +617,4 @@ module_exit(radeon_exit);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL and additional rights");
+MODULE_SOFTDEP("pre: amdkfd");
--
2.6.6
[PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling
On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote:
> drm_kms_helper_poll_enable_locked() should check if we have delayed event
> pending and if we have, schedule the work to run without delay.
>
> Currently the output_poll_work is only scheduled if any of the connectors
> have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
> DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
> already registered to be handled. The detection will be delayd by
> DRM_OUTPUT_POLL_PERIOD in any case.
> Furthermore if none of the connectors are marked as POLL_CONNECT or
> POLL_DISCONNECT because all connectors are either POLL_HPD or they are
> always connected: the output_poll_work will not run at all even if we
> have delayed event marked.
>
> When none of the connectors require polling, their initial status change
> from unknown to connected/disconnected is not going to be handled until
> the first kms application starts or if we have fb console enabled.
>
> With this change we can react more quickly to output status changes after
> enabling the poll but most importantly it will correct the behavior when
> none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they
> are either POLL_HPD or the .polled is 0. The initial status change is going
> to be handled correctly as well.
Don't we need to set delayed_event somewhere too first? At least I don't
really understand how this speeds things up ... The patch itself looks
like a valid bugfix, but the description confuses me a bit. I think if you
delete the above paragraph (starting with "With this change we can react
...") then it's all good.
-Daniel
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/gpu/drm/drm_probe_helper.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index a0df377d7d1c..f6b64d7d3528 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device
> *dev)
> {
> bool poll = false;
> struct drm_connector *connector;
> + unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
>
> WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>
> @@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device
> *dev)
> poll = true;
> }
>
> + if (dev->mode_config.delayed_event) {
> + poll = true;
> + delay = 0;
> + }
> +
> if (poll)
> - schedule_delayed_work(&dev->mode_config.output_poll_work,
> DRM_OUTPUT_POLL_PERIOD);
> + schedule_delayed_work(&dev->mode_config.output_poll_work,
> delay);
> }
> EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>
> --
> 2.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/amdgpu: Add amdkfd softdep
On 2016-08-29 03:37, Michel Dänzer wrote: > On 26/08/16 06:16 PM, Michal Marek wrote: >> It's a soft dependency, so it will be silently ignored. /sbin/modprobe >> --show-depends amdgpu will only list amdgpu.ko and its hard depedencies. > > Thanks for the clarification. > > The radeon driver probably needs this as well? You are right. I sent a v2 covering radeon as well. Thanks, Michal
dri-devel@lists.freedesktop.org
On 08/29/2016 01:57 PM, Daniel Vetter wrote: > - remove kerneldoc for drm-internal functions > - drm_property_replace_global_blob isn't actually atomic, and doesn't >need to be. Update docs&comments to match > - document all the types and try to link things a bit better > - nits all over > Reviewed-by: Archit Taneja > v2: Appease checkpatch in the moved code (Archit) > > Reviewed-by: Archit Taneja > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-kms.rst | 88 +- > drivers/gpu/drm/drm_property.c | 153 > include/drm/drm_property.h | 196 > ++--- > 3 files changed, 244 insertions(+), 193 deletions(-) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index e07a2667ab61..f9a991bb87d4 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -304,94 +304,12 @@ KMS Locking > KMS Properties > == > > -Drivers may need to expose additional parameters to applications than > -those described in the previous sections. KMS supports attaching > -properties to CRTCs, connectors and planes and offers a userspace API to > -list, get and set the property values. > - > -Properties are identified by a name that uniquely defines the property > -purpose, and store an associated value. For all property types except > -blob properties the value is a 64-bit unsigned integer. > - > -KMS differentiates between properties and property instances. Drivers > -first create properties and then create and associate individual > -instances of those properties to objects. A property can be instantiated > -multiple times and associated with different objects. Values are stored > -in property instances, and all other property information are stored in > -the property and shared between all instances of the property. > - > -Every property is created with a type that influences how the KMS core > -handles the property. Supported property types are > - > -DRM_MODE_PROP_RANGE > -Range properties report their minimum and maximum admissible values. > -The KMS core verifies that values set by application fit in that > -range. > - > -DRM_MODE_PROP_ENUM > -Enumerated properties take a numerical value that ranges from 0 to > -the number of enumerated values defined by the property minus one, > -and associate a free-formed string name to each value. Applications > -can retrieve the list of defined value-name pairs and use the > -numerical value to get and set property instance values. > - > -DRM_MODE_PROP_BITMASK > -Bitmask properties are enumeration properties that additionally > -restrict all enumerated values to the 0..63 range. Bitmask property > -instance values combine one or more of the enumerated bits defined > -by the property. > - > -DRM_MODE_PROP_BLOB > -Blob properties store a binary blob without any format restriction. > -The binary blobs are created as KMS standalone objects, and blob > -property instance values store the ID of their associated blob > -object. > - > -Blob properties are only used for the connector EDID property and > -cannot be created by drivers. > - > -To create a property drivers call one of the following functions > -depending on the property type. All property creation functions take > -property flags and name, as well as type-specific arguments. > - > -- struct drm_property \*drm_property_create_range(struct > - drm_device \*dev, int flags, const char \*name, uint64_t min, > - uint64_t max); > - Create a range property with the given minimum and maximum values. > - > -- struct drm_property \*drm_property_create_enum(struct drm_device > - \*dev, int flags, const char \*name, const struct > - drm_prop_enum_list \*props, int num_values); > - Create an enumerated property. The ``props`` argument points to an > - array of ``num_values`` value-name pairs. > - > -- struct drm_property \*drm_property_create_bitmask(struct > - drm_device \*dev, int flags, const char \*name, const struct > - drm_prop_enum_list \*props, int num_values); > - Create a bitmask property. The ``props`` argument points to an array > - of ``num_values`` value-name pairs. > - > -Properties can additionally be created as immutable, in which case they > -will be read-only for applications but can be modified by the driver. To > -create an immutable property drivers must set the > -DRM_MODE_PROP_IMMUTABLE flag at property creation time. > - > -When no array of value-name pairs is readily available at property > -creation time for enumerated or range properties, drivers can create the > -property using the :c:func:`drm_property_create()` function and > -manually add enumeration value-name pairs by calling the > -:c:func:`drm_property_add_enum()` function. Care must be taken to > -properly specify the property type through the ``flags`` argument. > - > -After creating p
"Fixes" for page flipping under PRIME on AMD & nouveau
> -Original Message- > From: Michel Dänzer [mailto:michel at daenzer.net] > Sent: Sunday, August 28, 2016 11:17 PM > To: Mario Kleiner > Cc: dri-devel at lists.freedesktop.org; jglisse at redhat.com; > bskeggs at redhat.com; Deucher, Alexander; airlied at redhat.com > Subject: Re: "Fixes" for page flipping under PRIME on AMD & nouveau > > On 27/08/16 04:57 AM, Mario Kleiner wrote: > > On 08/18/2016 04:23 AM, Michel Dänzer wrote: > >> On 18/08/16 01:12 AM, Mario Kleiner wrote: > > > > One thing that confuses me so far is that visual results and measurment > > suggest it works nicely, properly serializing the rendering/detiling > > blit and the pageflip. But when i ftrace the Intel drivers > > reservation_object_wait_timeout_rcu() call where it normally waits for > > the dmabuf fence to complete then i never see it blocking for more than > > a few dozen microseconds, and i couldn't find any other place where it > > blocks on detiling blit completion yet. Iow. it seems to work correctly > > in practice, but i don't know where it actually blocks. > > It actually doesn't work correctly in all cases yet: > https://bugs.freedesktop.org/show_bug.cgi?id=95472 > > > >>> Turns out that prime + page flipping currently doesn't work > >>> on nouveau and amd. The first offload rendered images from > >>> the imported dmabufs show up properly, but then the display > >>> is stuck alternating between the first two or three rendered > >>> frames. > >>> > >>> The problem is that during the pageflip ioctl we pin the > >>> dmabuf into VRAM in preparation for scanout, then unpin it > >>> when we are done with it at next flip, but the buffer stays > >>> in the VRAM memory domain. > >> > >> Sounds like you found a bug here: BOs which are being shared between > >> different GPUs should always be pinned to GTT, moving them to VRAM > (and > >> consequently the page flip) should fail. > > > > Seems so, although i hoped i was fixing a bug, not exploiting a > > loophole. In practice i haven't observed trouble with the hack so far. I > > havent't looked deeply enough into how the dma api below dmabuf > > operates, so this is just guesswork, but i suspect the reason that this > > doesn't blow up in an obvious way is that if the render offload gpu > > exports the dmabuf then the pages get pinned/locked into system RAM, > so > > the pages can't move around or get paged out to swap, as long as the > > dmabuf stays exported. When the dmabuf importing AMD or nouveau > display > > gpu then moves the bo from GTT to VRAM (or pseudo-moves it back with > my > > hack) all that changes is some pin refcount for the RAM pages, but the > > refcount always stays non-zero and system RAM isn't freed or moved > > around during the session. I just wonder if this bug couldn't somehow be > > turned into a proper feature? > > I'm afraid not; BOs which are being shared between devices are supposed > to be pinned to GTT, and pinned BOs aren't supposed to move. > > However, something similar to your patches could be done in the DDX > drivers, using the dedicated scanout pixmap mechanism. > > > >> The latest versions of DCE support scanning out from GTT, so that might > >> be a good solution at least for Carrizo and newer APUs, not sure it > >> makes sense for dGPUs though. > > > > That would be good to have. But that means DCE-11 or later only? What is > > the constraint on older parts, does it need contiguous memory? > > Presumably. Anyway, from Christian's description it sounds like it'll be > tricky to get this working even with current APUs. :( It only works for DCE11 APUs (not dGPUs) using single level page tables for gart and has fairly strict alignment requirements. The watermark setup and bandwidth management also have much stricter requirements. I think DAL has most of what is needed in place on the display side assuming the rest of the stack provides a buffer with the right alignment. Alex
[Bug 97504] Enabling SDMA on CIK (0241d8300f66ee2c6c2c55fe64ac88d76440c591) causes corruption on a mobile Bonaire with AMDGPU DDX / video desktop recording
https://bugs.freedesktop.org/show_bug.cgi?id=97504 --- Comment #1 from Vedran MiletiÄ --- It's a long shot, but does https://lists.freedesktop.org/archives/mesa-dev/2016-August/127318.html fix it? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/2216ebd8/attachment.html>
dri-devel@lists.freedesktop.org
On Mon, Aug 29, 2016 at 06:44:46PM +0530, Archit Taneja wrote: > > > On 08/29/2016 01:57 PM, Daniel Vetter wrote: > > - remove kerneldoc for drm-internal functions > > - drm_property_replace_global_blob isn't actually atomic, and doesn't > >need to be. Update docs&comments to match > > - document all the types and try to link things a bit better > > - nits all over > > > > Reviewed-by: Archit Taneja All applied to drm-misc, thanks for your review. -Daniel > > > v2: Appease checkpatch in the moved code (Archit) > > > > Reviewed-by: Archit Taneja > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/drm-kms.rst | 88 +- > > drivers/gpu/drm/drm_property.c | 153 > > include/drm/drm_property.h | 196 > > ++--- > > 3 files changed, 244 insertions(+), 193 deletions(-) > > > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > > index e07a2667ab61..f9a991bb87d4 100644 > > --- a/Documentation/gpu/drm-kms.rst > > +++ b/Documentation/gpu/drm-kms.rst > > @@ -304,94 +304,12 @@ KMS Locking > > KMS Properties > > == > > > > -Drivers may need to expose additional parameters to applications than > > -those described in the previous sections. KMS supports attaching > > -properties to CRTCs, connectors and planes and offers a userspace API to > > -list, get and set the property values. > > - > > -Properties are identified by a name that uniquely defines the property > > -purpose, and store an associated value. For all property types except > > -blob properties the value is a 64-bit unsigned integer. > > - > > -KMS differentiates between properties and property instances. Drivers > > -first create properties and then create and associate individual > > -instances of those properties to objects. A property can be instantiated > > -multiple times and associated with different objects. Values are stored > > -in property instances, and all other property information are stored in > > -the property and shared between all instances of the property. > > - > > -Every property is created with a type that influences how the KMS core > > -handles the property. Supported property types are > > - > > -DRM_MODE_PROP_RANGE > > -Range properties report their minimum and maximum admissible values. > > -The KMS core verifies that values set by application fit in that > > -range. > > - > > -DRM_MODE_PROP_ENUM > > -Enumerated properties take a numerical value that ranges from 0 to > > -the number of enumerated values defined by the property minus one, > > -and associate a free-formed string name to each value. Applications > > -can retrieve the list of defined value-name pairs and use the > > -numerical value to get and set property instance values. > > - > > -DRM_MODE_PROP_BITMASK > > -Bitmask properties are enumeration properties that additionally > > -restrict all enumerated values to the 0..63 range. Bitmask property > > -instance values combine one or more of the enumerated bits defined > > -by the property. > > - > > -DRM_MODE_PROP_BLOB > > -Blob properties store a binary blob without any format restriction. > > -The binary blobs are created as KMS standalone objects, and blob > > -property instance values store the ID of their associated blob > > -object. > > - > > -Blob properties are only used for the connector EDID property and > > -cannot be created by drivers. > > - > > -To create a property drivers call one of the following functions > > -depending on the property type. All property creation functions take > > -property flags and name, as well as type-specific arguments. > > - > > -- struct drm_property \*drm_property_create_range(struct > > - drm_device \*dev, int flags, const char \*name, uint64_t min, > > - uint64_t max); > > - Create a range property with the given minimum and maximum values. > > - > > -- struct drm_property \*drm_property_create_enum(struct drm_device > > - \*dev, int flags, const char \*name, const struct > > - drm_prop_enum_list \*props, int num_values); > > - Create an enumerated property. The ``props`` argument points to an > > - array of ``num_values`` value-name pairs. > > - > > -- struct drm_property \*drm_property_create_bitmask(struct > > - drm_device \*dev, int flags, const char \*name, const struct > > - drm_prop_enum_list \*props, int num_values); > > - Create a bitmask property. The ``props`` argument points to an array > > - of ``num_values`` value-name pairs. > > - > > -Properties can additionally be created as immutable, in which case they > > -will be read-only for applications but can be modified by the driver. To > > -create an immutable property drivers must set the > > -DRM_MODE_PROP_IMMUTABLE flag at property creation time. > > - > > -When no array of value-name pairs is readily available at property > > -creation time for enumerat
[PATCH] drm/i915/skl: Don't try to update plane watermarks if they haven't changed
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks. And if the watermarks hasn't changed then we
haven't populated skl_results with anything, which means we'll end up
zeroing out a plane's watermarks in the middle of the atomic commit
without restoring them later.
Changes since v1:
- Fix incorrect use of "it's"
Signed-off-by: Lyude
Cc: Maarten Lankhorst
Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically
during plane updates")
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_display.c | 7 ++-
drivers/gpu/drm/i915/intel_sprite.c | 9 +++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e4e6141..13e47a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3448,7 +3448,12 @@ static void skylake_disable_primary_plane(struct
drm_plane *primary,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
- skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
+ /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+ if (!crtc->primary->state->visible)
+ skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0df783a..73a521f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -292,8 +292,13 @@ skl_disable_plane(struct drm_plane *dplane, struct
drm_crtc *crtc)
const int pipe = intel_plane->pipe;
const int plane = intel_plane->plane + 1;
- skl_write_plane_wm(to_intel_crtc(crtc), &dev_priv->wm.skl_results,
- plane);
+ /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+ if (!dplane->state->visible)
+ skl_write_plane_wm(to_intel_crtc(crtc),
+ &dev_priv->wm.skl_results, plane);
I915_WRITE(PLANE_CTL(pipe, plane), 0);
--
2.7.4
[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support
Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel: > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: > > This patch adds active plane reconfiguration support for imx-drm. > > This may fixes some mode setting failure issues which were introduced > > by imx-drm atomic conversion patch set. The main idea is to disable the > > plane in question in CRTC's atomic_disable operation and then the drm > > atomic core will enable it again automatically. > > I have rebased onto drm-misc and picked up the remaining patches (4-7) Actually, since this is a regression and the new drm-misc patches won't make it into 4.8, I'd be inclined to take the v2 patch as a fix for 4.8 and then apply the remaining patches as relative changes to that on top of drm-misc instead. regards Philipp
[Bug 97305] Gallium: TBOs and images set the offset in elements, not bytes
https://bugs.freedesktop.org/show_bug.cgi?id=97305 Vedran MiletiÄ changed: What|Removed |Added CC||vedran at miletic.net --- Comment #16 from Vedran MiletiÄ --- (In reply to Marek Olšák from comment #15) > I'm working on it. Any news? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/ff05218c/attachment.html>
[Bug 97340] [radeonsi] POSTAL 2 freezes during shader compilation
https://bugs.freedesktop.org/show_bug.cgi?id=97340 Vedran MiletiÄ changed: What|Removed |Added Summary|POSTAL 2 poor performance |[radeonsi] POSTAL 2 freezes |at certain times, RadeonSI |during shader compilation |driver | -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/4fec402d/attachment.html>
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On Mon, 29 Aug 2016, Andrea Arcangeli wrote: > On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote: >> If it's an Iybridge, there's no low vswing, and that explanation is >> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2 >> on an unpatched kernel. > > What I should look for when trying those two settings? Will they > successfully fix my problem with intel_backlight with upstream 4.8-rc? > > I thought it had to be the same issue as on skylake as I get the > backlight flikering at low frequency but getting brighter and darker > in a cycle lasting a few seconds and I thought there couldn't be too > many other random bugs that ends up with the same side effect. Your Ivybridge does not have low voltage swing *and* low voltage swing has nothing to do with the backlight. The regressing commit may be the same for you, but the failure mode appears to be completely different. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[Bug 95308] [radeonsi] Hangs after some minutes on Team Fortress 2
https://bugs.freedesktop.org/show_bug.cgi?id=95308 Vedran MiletiÄ changed: What|Removed |Added Blocks||77449 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=77449 [Bug 77449] Tracker bug for all bugs related to Steam titles -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/5e8abd78/attachment.html>
[Bug 97340] [radeonsi] POSTAL 2 freezes during shader compilation
https://bugs.freedesktop.org/show_bug.cgi?id=97340 Vedran MiletiÄ changed: What|Removed |Added Blocks||77449 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=77449 [Bug 77449] Tracker bug for all bugs related to Steam titles -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/8138f61a/attachment.html>
[PATCH] drm/i915/skl: Don't try to update plane watermarks if they haven't changed
On Mon, 29 Aug 2016, Lyude wrote:
> i915 sometimes needs to disable planes in the middle of an atomic
> commit, and then reenable them later in the same commit. Because of
> this, we can't make the assumption that the state of the plane actually
> changed. Since the state of the plane hasn't actually changed, neither
> have it's watermarks. And if the watermarks hasn't changed then we
> haven't populated skl_results with anything, which means we'll end up
> zeroing out a plane's watermarks in the middle of the atomic commit
> without restoring them later.
I would appreciate a (brief) description of what the failure mode is in
this case.
BR,
Jani.
>
> Changes since v1:
> - Fix incorrect use of "it's"
>
> Signed-off-by: Lyude
> Cc: Maarten Lankhorst
> Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically
> during plane updates")
>
> Signed-off-by: Lyude
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 ++-
> drivers/gpu/drm/i915/intel_sprite.c | 9 +++--
> 2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e4e6141..13e47a7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3448,7 +3448,12 @@ static void skylake_disable_primary_plane(struct
> drm_plane *primary,
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> int pipe = intel_crtc->pipe;
>
> - skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
> + /*
> + * We only populate skl_results on watermark updates, and if the
> + * plane's visiblity isn't actually changing neither is its watermarks.
> + */
> + if (!crtc->primary->state->visible)
> + skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
>
> I915_WRITE(PLANE_CTL(pipe, 0), 0);
> I915_WRITE(PLANE_SURF(pipe, 0), 0);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 0df783a..73a521f 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -292,8 +292,13 @@ skl_disable_plane(struct drm_plane *dplane, struct
> drm_crtc *crtc)
> const int pipe = intel_plane->pipe;
> const int plane = intel_plane->plane + 1;
>
> - skl_write_plane_wm(to_intel_crtc(crtc), &dev_priv->wm.skl_results,
> -plane);
> + /*
> + * We only populate skl_results on watermark updates, and if the
> + * plane's visiblity isn't actually changing neither is its watermarks.
> + */
> + if (!dplane->state->visible)
> + skl_write_plane_wm(to_intel_crtc(crtc),
> +&dev_priv->wm.skl_results, plane);
>
> I915_WRITE(PLANE_CTL(pipe, plane), 0);
--
Jani Nikula, Intel Open Source Technology Center
[Bug 91969] [radeonsi][bonaire] Stalls with Borderlands 2
https://bugs.freedesktop.org/show_bug.cgi?id=91969 Vedran MiletiÄ changed: What|Removed |Added Blocks||77449 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=77449 [Bug 77449] Tracker bug for all bugs related to Steam titles -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/14bd2532/attachment.html>
[Bug 97305] Gallium: TBOs and images set the offset in elements, not bytes
https://bugs.freedesktop.org/show_bug.cgi?id=97305 --- Comment #17 from Marek Olšák --- It should be fixed in master already. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/aab84dbb/attachment.html>
[Bug 97513] clover reports wrong device pointer size
https://bugs.freedesktop.org/show_bug.cgi?id=97513 Vedran MiletiÄ changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |vedran at miletic.net |.org| QA Contact|dri-devel at lists.freedesktop |vedran at miletic.net |.org| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/78c15ac6/attachment.html>
[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support
On Mon, Aug 29, 2016 at 4:59 PM, Philipp Zabel wrote: > Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel: >> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying: >> > This patch adds active plane reconfiguration support for imx-drm. >> > This may fixes some mode setting failure issues which were introduced >> > by imx-drm atomic conversion patch set. The main idea is to disable the >> > plane in question in CRTC's atomic_disable operation and then the drm >> > atomic core will enable it again automatically. >> >> I have rebased onto drm-misc and picked up the remaining patches (4-7) > > Actually, since this is a regression and the new drm-misc patches won't > make it into 4.8, I'd be inclined to take the v2 patch as a fix for 4.8 > and then apply the remaining patches as relative changes to that on top > of drm-misc instead. Just apply the 4.8 to 4.8 and then once that's in an -rc do a backmerge with -X ours and explain in the commit what you're doing. No need to rework the patches once more to be incremental on top of the 4.8 fix. At least that's what we're doing all the time in i915. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
On Wed, Aug 24, 2016 at 08:46:37AM +0300, Vladimir Zapolskiy wrote: > The change adds support of internal HDMI I2C master controller, this > subdevice is used by default, if "ddc-i2c-bus" DT property is omitted. > > The main purpose of this functionality is to support reading EDID from > an HDMI monitor on boards, which don't have an I2C bus connected to > DDC pins. > > The current implementation does not support "I2C Master Interface > Extended Read Mode" to read data addressed by non-zero segment > pointer, this means that if EDID has more than 1 extension blocks, > EDID reading operation won't succeed, in my practice all tested HDMI > monitors have at maximum one extension block. > > Signed-off-by: Vladimir Zapolskiy > --- > The change is based on top of v4.8.0-rc1 and a fix in DW HDMI driver > https://patchwork.kernel.org/patch/9284717/ > > Changes from v5 to v6: > * rebased on top of v4.8.0-rc1 > * fixed one improper resource deallocation on error path of dw_hdmi_bind() > * added a comment describing a mutex asked by checkpatch.pl --strict > > Link to version v5: https://patchwork.kernel.org/patch/7279831/ > > Changes from v4 to v5: > * do I2C bus controller initialization only once in bind() as it was done > in v1-v3 of the change. > > Changes from v3 to v4, thanks to Doug and Philipp for review: > * set speed mode after software reset in dw_hdmi_i2c_init() > * by default set standard speed mode instead of fast speed mode, on iMX6Q > this configures SCL to 100 KHz, which is compliant with HDMI 1.3a spec > * do I2C bus controller reinitialization on every data transfer, > this change hopefully solves some observed problems on RK3288 platform > * added short functional change description to dw_hdmi.txt > > v3 of the change was > > Tested-by: Philipp Zabel > > Changes from v2 to v3, thanks to Russell: > * moved register field value definitions to dw_hdmi.h > * made completions uninterruptible to avoid transfer retries if interrupted > * use one completion for both read and write transfers as in v1, > operation_reg is removed > * redundant i2c->stat = 0 is removed from dw_hdmi_i2c_read/write() > * struct i2c_algorithm dw_hdmi_algorithm is qualified as const > * dw_hdmi_i2c_adapter() does not modify struct dw_hdmi on error path > * dw_hdmi_i2c_irq() does not modify hdmi->i2c->stat, if interrupt is > not for I2CM > * spin lock is removed from dw_hdmi_i2c_irq() > * removed spin lock from dw_hdmi_i2c_xfer() around write to > HDMI_IH_MUTE_I2CM_STAT0 register > * split loop over message array in dw_hdmi_i2c_xfer() to validation > and transfer parts > * added a mutex to serialize I2C transfer requests, i2c->lock is > completely removed > * removed if(len) check from dw_hdmi_i2c_write(), hardware supports > only len>0 transfers > * described extension blocks <= 1 limitation in the commit message > * a number of minor clean ups > > Changes from v1 to v2: > * fixed a devm_kfree() signature > * split completions for read and write operations > > .../devicetree/bindings/display/bridge/dw_hdmi.txt | 4 +- Acked-by: Rob Herring > drivers/gpu/drm/bridge/dw-hdmi.c | 265 > - > drivers/gpu/drm/bridge/dw-hdmi.h | 19 ++ > 3 files changed, 281 insertions(+), 7 deletions(-)
[PATCH] drm/imx: fix crtc vblank state regression
The atomic conversion lost the notification to let the DRM core
know about the current state of the CRTC vblank interrupts. This
regressed the ability of the core to reject page flip attempts
on currently disabled CRTCs. Add back the notifications.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 08e188bc10fc..462056e4b9e4 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -76,6 +76,8 @@ static void ipu_crtc_disable(struct drm_crtc *crtc)
crtc->state->event = NULL;
}
spin_unlock_irq(&crtc->dev->event_lock);
+
+ drm_crtc_vblank_off(crtc);
}
static void imx_drm_crtc_reset(struct drm_crtc *crtc)
@@ -175,6 +177,8 @@ static int ipu_crtc_atomic_check(struct drm_crtc *crtc,
static void ipu_crtc_atomic_begin(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
{
+ drm_crtc_vblank_on(crtc);
+
spin_lock_irq(&crtc->dev->event_lock);
if (crtc->state->event) {
WARN_ON(drm_crtc_vblank_get(crtc));
--
2.8.1
[PATCH v3] drm/i915/skl: Don't try to update plane watermarks if they haven't changed
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks. And if the watermarks hasn't changed then we
haven't populated skl_results with anything, which means we'll end up
zeroing out a plane's watermarks in the middle of the atomic commit
without restoring them later.
Simple reproduction recipe:
- Get a SKL laptop, launch any kind of X session
- Get two extra monitors
- Keep hotplugging both displays (so that the display configuration
jumps from 1 active pipe to 3 active pipes and back)
- Eventually underrun
Changes since v1:
- Fix incorrect use of "it's"
Changes since v2:
- Add reproduction recipe
Signed-off-by: Lyude
Cc: Maarten Lankhorst
Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically
during plane updates")
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_display.c | 7 ++-
drivers/gpu/drm/i915/intel_sprite.c | 9 +++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e4e6141..13e47a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3448,7 +3448,12 @@ static void skylake_disable_primary_plane(struct
drm_plane *primary,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
- skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
+ /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+ if (!crtc->primary->state->visible)
+ skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0);
I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0df783a..73a521f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -292,8 +292,13 @@ skl_disable_plane(struct drm_plane *dplane, struct
drm_crtc *crtc)
const int pipe = intel_plane->pipe;
const int plane = intel_plane->plane + 1;
- skl_write_plane_wm(to_intel_crtc(crtc), &dev_priv->wm.skl_results,
- plane);
+ /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is its watermarks.
+*/
+ if (!dplane->state->visible)
+ skl_write_plane_wm(to_intel_crtc(crtc),
+ &dev_priv->wm.skl_results, plane);
I915_WRITE(PLANE_CTL(pipe, plane), 0);
--
2.7.4
[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Hi all,
On 24 August 2016 at 06:46, Vladimir Zapolskiy
wrote:
> MODULE_AUTHOR("Sascha Hauer ");
> MODULE_AUTHOR("Andy Yan ");
> MODULE_AUTHOR("Yakir Yang ");
> +MODULE_AUTHOR("Vladimir Zapolskiy ");
Don't meant to start a flame-war or alike but to educate myself:
Where does one draw the line about adding new author(s) of said
module/subsystem ?
Afaict this is the most common (?) driver in DRM where the list has
grown over time. Should we do the same with others ?
Thanks
Emil
[PATCH] drm/ttm: Use RCU for ttm_mem_type_manager.move fence
The ttm_mem_type_manager.move tracks the fence for the last migration on
the memory manager. Currently it is accessed under its own spinlock to
ensure that the fence doesn't disappear from underneath it. We can
translate the reader to acquire a reference to the fence using
fence_get_rcu_safe() which ensures that the fence cannot be reallocated
as the reference is acquired.
Suggested-by: Christian König
Signed-off-by: Chris Wilson
Cc: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 24
drivers/gpu/drm/ttm/ttm_bo_util.c | 12
include/drm/ttm/ttm_bo_driver.h | 2 +-
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 42c074a9c955..422d9b39d8ae 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -797,9 +797,9 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object
*bo,
struct fence *fence;
int ret;
- spin_lock(&man->move_lock);
- fence = fence_get(man->move);
- spin_unlock(&man->move_lock);
+ rcu_read_lock();
+ fence = fence_get_rcu_safe(&man->move);
+ rcu_read_unlock();
if (fence) {
reservation_object_add_shared_fence(bo->resv, fence);
@@ -1310,9 +1310,9 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
*bdev,
}
spin_unlock(&glob->lru_lock);
- spin_lock(&man->move_lock);
- fence = fence_get(man->move);
- spin_unlock(&man->move_lock);
+ rcu_read_lock();
+ fence = fence_get_rcu_safe(&man->move);
+ rcu_read_unlock();
if (fence) {
ret = fence_wait(fence, false);
@@ -1332,6 +1332,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
*bdev,
int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned mem_type)
{
struct ttm_mem_type_manager *man;
+ struct fence *last_move;
int ret = -EINVAL;
if (mem_type >= TTM_NUM_MEM_TYPES) {
@@ -1345,7 +1346,14 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned
mem_type)
mem_type);
return ret;
}
- fence_put(man->move);
+
+ /* The locking here is overkill; but harmless and documentary */
+ spin_lock(&man->move_lock);
+ last_move = rcu_dereference_protected(man->move,
+ spin_is_locked(&man->move_lock));
+ rcu_assign_pointer(man->move, NULL);
+ spin_unlock(&man->move_lock);
+ fence_put(last_move);
man->use_type = false;
man->has_type = false;
@@ -1410,7 +1418,7 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned
type,
man->size = p_size;
INIT_LIST_HEAD(&man->lru);
- man->move = NULL;
+ RCU_INIT_POINTER(man->move, NULL);
return 0;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f157a9efd220..cd675d503ee4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -755,6 +755,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
ttm_bo_unref(&ghost_obj);
} else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
+ struct fence *last_move;
/**
* BO doesn't have a TTM we need to bind/unbind. Just remember
@@ -762,11 +763,14 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
*/
spin_lock(&from->move_lock);
- if (!from->move || fence_is_later(fence, from->move)) {
- fence_put(from->move);
- from->move = fence_get(fence);
- }
+ last_move = rcu_dereference_protected(from->move,
+
spin_is_locked(&from->move_lock));
+ if (!last_move || fence_is_later(fence, last_move))
+ rcu_assign_pointer(from->move, fence_get(fence));
+ else
+ last_move = NULL;
spin_unlock(&from->move_lock);
+ fence_put(last_move);
ttm_bo_free_old_node(bo);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 99c6d01d24f2..508d2f428d25 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -305,7 +305,7 @@ struct ttm_mem_type_manager {
/*
* Protected by @move_lock.
*/
- struct fence *move;
+ struct fence __rcu *move;
};
/**
--
2.9.3
[PATCH] drm/ttm: Use RCU for ttm_mem_type_manager.move fence
Am 29.08.2016 um 18:57 schrieb Chris Wilson:
> The ttm_mem_type_manager.move tracks the fence for the last migration on
> the memory manager. Currently it is accessed under its own spinlock to
> ensure that the fence doesn't disappear from underneath it. We can
> translate the reader to acquire a reference to the fence using
> fence_get_rcu_safe() which ensures that the fence cannot be reallocated
> as the reference is acquired.
>
> Suggested-by: Christian König
> Signed-off-by: Chris Wilson
> Cc: Christian König
Reviewed-by: Christian König .
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 24
> drivers/gpu/drm/ttm/ttm_bo_util.c | 12
> include/drm/ttm/ttm_bo_driver.h | 2 +-
> 3 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 42c074a9c955..422d9b39d8ae 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -797,9 +797,9 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object
> *bo,
> struct fence *fence;
> int ret;
>
> - spin_lock(&man->move_lock);
> - fence = fence_get(man->move);
> - spin_unlock(&man->move_lock);
> + rcu_read_lock();
> + fence = fence_get_rcu_safe(&man->move);
> + rcu_read_unlock();
>
> if (fence) {
> reservation_object_add_shared_fence(bo->resv, fence);
> @@ -1310,9 +1310,9 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
> *bdev,
> }
> spin_unlock(&glob->lru_lock);
>
> - spin_lock(&man->move_lock);
> - fence = fence_get(man->move);
> - spin_unlock(&man->move_lock);
> + rcu_read_lock();
> + fence = fence_get_rcu_safe(&man->move);
> + rcu_read_unlock();
>
> if (fence) {
> ret = fence_wait(fence, false);
> @@ -1332,6 +1332,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
> *bdev,
> int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned mem_type)
> {
> struct ttm_mem_type_manager *man;
> + struct fence *last_move;
> int ret = -EINVAL;
>
> if (mem_type >= TTM_NUM_MEM_TYPES) {
> @@ -1345,7 +1346,14 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev,
> unsigned mem_type)
> mem_type);
> return ret;
> }
> - fence_put(man->move);
> +
> + /* The locking here is overkill; but harmless and documentary */
> + spin_lock(&man->move_lock);
> + last_move = rcu_dereference_protected(man->move,
> + spin_is_locked(&man->move_lock));
> + rcu_assign_pointer(man->move, NULL);
> + spin_unlock(&man->move_lock);
> + fence_put(last_move);
>
> man->use_type = false;
> man->has_type = false;
> @@ -1410,7 +1418,7 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned
> type,
> man->size = p_size;
>
> INIT_LIST_HEAD(&man->lru);
> - man->move = NULL;
> + RCU_INIT_POINTER(man->move, NULL);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index f157a9efd220..cd675d503ee4 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -755,6 +755,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
> ttm_bo_unref(&ghost_obj);
>
> } else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
> + struct fence *last_move;
>
> /**
>* BO doesn't have a TTM we need to bind/unbind. Just remember
> @@ -762,11 +763,14 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
>*/
>
> spin_lock(&from->move_lock);
> - if (!from->move || fence_is_later(fence, from->move)) {
> - fence_put(from->move);
> - from->move = fence_get(fence);
> - }
> + last_move = rcu_dereference_protected(from->move,
> +
> spin_is_locked(&from->move_lock));
> + if (!last_move || fence_is_later(fence, last_move))
> + rcu_assign_pointer(from->move, fence_get(fence));
> + else
> + last_move = NULL;
> spin_unlock(&from->move_lock);
> + fence_put(last_move);
>
> ttm_bo_free_old_node(bo);
>
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 99c6d01d24f2..508d2f428d25 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -305,7 +305,7 @@ struct ttm_mem_type_manager {
> /*
>* Protected by @move_lock.
>*/
> - struct fence *move;
> + struct fence __rcu *move;
> };
>
> /**
[Bug 97305] Gallium: TBOs and images set the offset in elements, not bytes
https://bugs.freedesktop.org/show_bug.cgi?id=97305 Matias N. Goldberg changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #18 from Matias N. Goldberg --- You're awesome! I can confirm it works on both the sample repro I provided and my actual real case. Small note: We discovered there was a potential for a crash because at certain points we assume SIMD alignment; so we're now enforcing 16-byte alignment as minimum in our code. I'm doing this remark because Mesa is the only (or among the very few) implementations that return alignments <16; which can reveal hidden bugs in program code that runs fine everywhere else. If you ever see a bug report of these sorts (e.g. crashing in movaps, movntdqa), this is something to keep in mind. I appreciate the 4 byte alignment as 256 reported by others is excessively wasteful. Thanks. For the record it was fixed in https://cgit.freedesktop.org/mesa/mesa/commit/?id=7cd256ce7e4bad680bb77d033cf5dd662abab2dd and https://cgit.freedesktop.org/mesa/mesa/commit/?id=325379096f54dde39171d1b8804e29a8003bb3c7 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/11ad4aef/attachment-0001.html>
[PATCH] dma-buf/sync-file: Avoid enable fence signaling if poll(.timeout=0)
If we being polled with a timeout of zero, a nonblocking busy query,
we don't need to install any fence callbacks as we will not be waiting.
As we only install the callback once, the overhead comes from the atomic
bit test that also causes serialisation between threads.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
drivers/dma-buf/sync_file.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 486d29c1a830..abb5fdab75fd 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -306,7 +306,8 @@ static unsigned int sync_file_poll(struct file *file,
poll_table *wait)
poll_wait(file, &sync_file->wq, wait);
- if (!test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
+ if (!poll_does_not_wait(wait) &&
+ !test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
if (fence_add_callback(sync_file->fence, &sync_file->cb,
fence_check_cb_func) < 0)
wake_up_all(&sync_file->wq);
--
2.9.3
[PATCH] dma-buf/sync-file: Avoid enable fence signaling if poll(.timeout=0)
Hi Chris, 2016-08-29 Chris Wilson : > If we being polled with a timeout of zero, a nonblocking busy query, > we don't need to install any fence callbacks as we will not be waiting. > As we only install the callback once, the overhead comes from the atomic > bit test that also causes serialisation between threads. > > Signed-off-by: Chris Wilson > Cc: Sumit Semwal > Cc: Gustavo Padovan > Cc: linux-media at vger.kernel.org > Cc: dri-devel at lists.freedesktop.org > Cc: linaro-mm-sig at lists.linaro.org > --- > drivers/dma-buf/sync_file.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Indeed, we can shortcut this. Reviewed-by: Gustavo Padovan Gustavo
[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Hi Emil,
On 08/29/2016 07:41 PM, Emil Velikov wrote:
> Hi all,
>
> On 24 August 2016 at 06:46, Vladimir Zapolskiy
> wrote:
>
>> MODULE_AUTHOR("Sascha Hauer ");
>> MODULE_AUTHOR("Andy Yan ");
>> MODULE_AUTHOR("Yakir Yang ");
>> +MODULE_AUTHOR("Vladimir Zapolskiy ");
> Don't meant to start a flame-war or alike but to educate myself:
> Where does one draw the line about adding new author(s) of said
> module/subsystem ?
I support you, let's don't sink. Since it evokes questions I'm
ready to provide you with more background information.
> Afaict this is the most common (?) driver in DRM where the list has
> grown over time. Should we do the same with others ?
If you look into the essense of this change it adds support to
an I2C master controller, which is a part of DW HDMI controller.
Originally this particular change was done as a separate driver
in I2C subsystem about 3 years ago and delivered to the customers,
about 2 years ago I published its RFC version:
RFC: https://patchwork.ozlabs.org/patch/405100/
v1 discussion: http://www.mailbrowse.com/linux-i2c/20949.html
As you may see this was a stand-alone driver, which served as
the fourth I2C master controller on iMX6Q, however I believe
it is better to merge two drivers into one. Does it sound like
a good enough reason to merge lists of authors as well?
Hope it clarifies the situation a bit.
--
With best wishes,
Vladimir
[Bug 117581] Celsius H265: suspend does not bring up console unless no_console_suspend is given
https://bugzilla.kernel.org/show_bug.cgi?id=117581 --- Comment #7 from Elmar Stellnberger --- I guess it would already be resolved but Bug 155511 inhibits me from testing that out correctly. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 92912] Full GPU lockups in TF2 - R600
https://bugs.freedesktop.org/show_bug.cgi?id=92912 --- Comment #7 from Chris Rankin --- FWIW, my nephew has played TF2 (Steam's "Team Fortress 2", presumably) for HOURS recently with HD 6450 and recent Mesa 12.1.0-devel. If it had locked up even once then I would have known about it... ;-). The base OS was Fedora 24/x86_64 with LLVM 3.8.0. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/1e187f11/attachment.html>
[PATCH 0/4] Backported vlv fixes for 4.7.y
drm/i915/vlv: Make intel_crt_reset() per-encoder: 4570d833390b10043d082fe535375d4a0e071d9c drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init(): 4c732e6ee9e71903934d75b12a021eb3520b6197 drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug(): 21842ea84f161ae37ba25f0250c377fd19c5b307 drm/i915: Enable polling when we don't have hpd: 84c8e0963da434d37355079b568465cd121af295 On Mon, 2016-08-22 at 16:33 -0400, Greg KH wrote: > On Mon, Aug 22, 2016 at 11:31:31AM -0400, Lyude wrote: > > > > Hope this didn't take too long! Here's the backported versions of the > > patches > > you had trouble applying to stable. The patch for FBC won't be necessary as > > that is already present in 4.7.y. > > > > Cheers, > > Lyude > > Thanks, but what are the git commit ids of these patches in Linus's > tree?  I need those to add to the commits... > > thanks, > > greg k-h
[GIT PULL] drm-vc4-fixes-2016-08-29
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: https://github.com/anholt/linux drm-vc4-fixes-2016-08-29 for you to fetch changes up to 552416c146fadc67cd9b53ef7adf88d3381c43a6: drm/vc4: Fix oops when userspace hands in a bad BO. (2016-08-19 19:17:39 -0700) This pull request brings in fixes for VC4 3D in 4.8, most of which are covered by testcases. Eric Anholt (6): drm/vc4: Use drm_free_large() on handles to match its allocation. drm/vc4: Use drm_malloc_ab to fix large rendering jobs. drm/vc4: Fix handling of a pm_runtime_get_sync() success case. drm/vc4: Free hang state before destroying BO cache. drm/vc4: Fix overflow mem unreferencing when the binner runs dry. drm/vc4: Fix oops when userspace hands in a bad BO. drivers/gpu/drm/vc4/vc4_drv.c | 6 +++--- drivers/gpu/drm/vc4/vc4_drv.h | 9 + drivers/gpu/drm/vc4/vc4_gem.c | 18 +- drivers/gpu/drm/vc4/vc4_irq.c | 4 +++- 4 files changed, 24 insertions(+), 13 deletions(-)
[GIT PULL] drm-vc4-next-2016-08-29
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: https://github.com/anholt/linux tags/drm-vc4-next-2016-08-29 for you to fetch changes up to 67f13690f447841fb3d2f952a6e49b2b28ae379b: drm/vc4: Don't force new binner overflow allocation per draw. (2016-08-19 19:36:22 -0700) This pull request brings in interlaced vblank timing and a 3D rendering memory/CPU overhead reduction. Eric Anholt (1): drm/vc4: Don't force new binner overflow allocation per draw. Mario Kleiner (5): drm/vc4: Disallow interlaced modes on DPI. drm/vc4: Fix handling of interlaced video modes. drm/vc4: Reject doublescan modes. drm/vc4: Enable precise vblank timestamping for interlaced modes. drm/vc4: Enable/Disable vblanks properly in crtc en/disable. drivers/gpu/drm/vc4/vc4_crtc.c | 52 +++--- drivers/gpu/drm/vc4/vc4_dpi.c | 11 + drivers/gpu/drm/vc4/vc4_gem.c | 4 drivers/gpu/drm/vc4/vc4_hdmi.c | 29 +-- 4 files changed, 77 insertions(+), 19 deletions(-)
[Bug 92912] Full GPU lockups in TF2 - R600
https://bugs.freedesktop.org/show_bug.cgi?id=92912 --- Comment #8 from hofmann.zachary at gmail.com --- It's definitely fixed now, just disappointed that in this whole time the bug never got recognized. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/22518200/attachment-0001.html>
[PATCH 0/4 v2] Audio support for adv7511 hdmi bridge
This is another swing at getting the adv7511 hdmi bridge audio support reviewed. I've taken the core audio work done by Lars-Peter Clausen, and adapted by Srinivas Kandagatla and Archit Taneja, and tried to rework it to use the hdmi-codec sound driver. This patchset, along with the i2s driver and dts changes allows HDMI audio to work on the HiKey board. I'd really appreciate any thoughts or feedback. New in v2: * Integrated Srinivas' review feedback thanks -john Cc: David Airlie Cc: Archit Taneja Cc: Laurent Pinchart Cc: Wolfram Sang Cc: Srinivas Kandagatla Cc: "Ville Syrjälä" Cc: Boris Brezillon Cc: Andy Green Cc: Dave Long Cc: Guodong Xu Cc: Zhangfei Gao Cc: Mark Brown Cc: Lars-Peter Clausen Cc: Jose Abreu Cc: dri-devel at lists.freedesktop.org Andy Green (1): drm/bridge: adv7511: Initialize audio packet on adv7533 Archit Taneja (1): drm/bridge: adv7511: Move the common data structures to header file John Stultz (1): drm/bridge: adv7511: Add Audio support. Srinivas Kandagatla (1): drm/bridge: adv7511: Enable the audio data and clock pads on adv7533 drivers/gpu/drm/bridge/adv7511/Kconfig | 1 + drivers/gpu/drm/bridge/adv7511/Makefile| 2 +- drivers/gpu/drm/bridge/adv7511/adv7511.h | 13 ++ drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 199 + drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 9 +- drivers/gpu/drm/bridge/adv7511/adv7533.c | 23 +++ 6 files changed, 244 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c -- 1.9.1
[PATCH 1/4 v2] drm/bridge: adv7511: Move the common data structures to header file
From: Archit Taneja
This patch moves the adv7511 data structure to header file so that the
audio driver file could use it.
Cc: David Airlie
Cc: Archit Taneja
Cc: Laurent Pinchart
Cc: Wolfram Sang
Cc: Srinivas Kandagatla
Cc: "Ville Syrjälä"
Cc: Boris Brezillon
Cc: Andy Green
Cc: Dave Long
Cc: Guodong Xu
Cc: Zhangfei Gao
Cc: Mark Brown
Cc: Lars-Peter Clausen
Cc: Jose Abreu
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Srinivas Kandagatla
Signed-off-by: John Stultz
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 8
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 161c923..c7002a0 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -16,6 +16,14 @@
#include
#include
+#include
+
+struct regmap;
+struct adv7511;
+
+int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
+int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
+
#define ADV7511_REG_CHIP_REVISION 0x00
#define ADV7511_REG_N0 0x01
#define ADV7511_REG_N1 0x02
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index ec8fb2e..f8eb7f8 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -160,7 +160,7 @@ static void adv7511_set_colormap(struct adv7511 *adv7511,
bool enable,
ADV7511_CSC_UPDATE_MODE, 0);
}
-static int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet)
+int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet)
{
if (packet & 0xff)
regmap_update_bits(adv7511->regmap, ADV7511_REG_PACKET_ENABLE0,
@@ -175,7 +175,7 @@ static int adv7511_packet_enable(struct adv7511 *adv7511,
unsigned int packet)
return 0;
}
-static int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet)
+int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet)
{
if (packet & 0xff)
regmap_update_bits(adv7511->regmap, ADV7511_REG_PACKET_ENABLE0,
--
1.9.1
