[GIT PULL FOR v3.19] R-Car DU changes
On 25 November 2014 at 00:18, Lars-Peter Clausen wrote: > On 11/24/2014 03:00 PM, Laurent Pinchart wrote: >> >> Hi Daniel, >> >> (CC'ing Rob Clark and Lars-Peter. As a reminder we're discussing the "drm: >> Decouple EDID parsing from I2C adapter" patch available at >> git://linuxtv.org/pinchartl/fbdev.git drm/next/du) >> >> On Monday 24 November 2014 14:09:39 Daniel Vetter wrote: >>> >>> On Mon, Nov 24, 2014 at 11:46:18AM +0200, Laurent Pinchart wrote: > > - the interface looks rather backwards: Either this still does i2c >reads, and then you'd just need a i2c-over-whatever adapter to make > it >work. Or you have other magic means to optain an edid block, in > which >case just do that and then feed the edid drm_add_edid_modes. I have a magic way to get EDID over I2C :-) Basically the ADV7511 controls the DDC bus, and exposes EDID data over I2C using vendor commands. To read an EDID block I have to write an ADV7511 register over I2C with the block number, wait for an interrupt, read a status register to check whether EDID data is available or whether an error occurred, and then read EDID data from the ADV7511 over I2C in 64-bytes chunks. This needs to be repeated for every block. I thus can't use drm_get_edid() directly. >>> >>> >>> Sounds familiar. See the special ddc-over-sdvo i2c bus we register in >>> intel_sdvo.c, specifically look at intel_sdvo_init_ddc_proxy. It is a bit >>> of boilerplate, but in the end just amounts to 3 small functions and one >>> tiny vtable to wire it all up cleanly. >> >> >> That's what I would have done as well if I had a device-specific I2C >> adapter >> connected to the DDC bus, but in this case the interface exposed by the >> ADV7511 to the SoC over I2C consists of higher level device-specific I2C >> commands to read EDID data. There is no low-level I2C read/write >> primitives >> available. I would thus need to expose a fake adapter that would receive >> I2C >> commands, parse them to detect an EDID block read, retrieve the EDID data >> and >> return them from the fake read. That doesn't make much sense to me. > > > The intel sdvo looks just like a simple I2C mux which will just pass-through > messages from the master to the EDID EEPROM. The ADV7511 is unfortunately a > bit different. You tell it to fetch the EDID information, then it will do > some magic and then you can read the EDID back. Abstracting this as a this > as a I2C controller will, while possible, result in a fair amount of boiler > plate code that will not look particularly pretty. It sounds also a bit like DP auxch also, or even how on UDL we get the edid over USB. I'd rather see not pretty code that only one person had to look at though :-) with lots of comments on the hw design that demands ugly. Dave.
[PATCH] drm/vgem: implement virtual GEM
After looking into removing platform_device, I found that using dma_buf_attach with a NULL device always returns an error, thereby preventing me from using VGEM for import and mmap. The solution seems to be to skip using dma_buf_attach, and instead use dma_buf_mmap when user-space tries to mmap a gem object that was imported into VGEM. The drawback to this approach is that most drivers stub their dma_buf_ops->mmap implementation. Presumably mmap could be implemented for the drivers that this would make sense for. Are there any comments, questions, or concerns for this proposed solution? On Fri Nov 21 2014 at 10:45:08 AM Zachary Reizner wrote: > ajax: The consumer of this will be software renderers. We're working on > one right now that will be using dma-bufs from userspace. > Daniel: Thanks for your suggestions. I'll work on it and submit a v2. > On Fri Nov 21 2014 at 6:02:45 AM Adam Jackson wrote: > >> On Thu, 2014-11-20 at 16:26 -0800, Zach Reizner wrote: >> > This patch implements the virtual GEM driver with PRIME sharing which >> > allows vgem to import a gem object from other drivers for the purpose >> > of mmap-ing them to userspace. >> >> The reason I initially wanted this was to get zero-copy llvmpipe, since >> (besides making GLX conformance impossible) the image transfer parts of >> drisw are easily the biggest part of the runtime overhead. Is there a >> userspace consumer of this anywhere? >> >> - ajax >> >> -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/b72310a0/attachment.html>
[GIT PULL FOR v3.19] R-Car DU changes
Hi Laurent, On Mon, Nov 24, 2014 at 11:46:18AM +0200, Laurent Pinchart wrote: > Hi Daniel, > > Thank you for the review. > > On Friday 07 November 2014 10:19:14 Daniel Vetter wrote: > > On Fri, Nov 07, 2014 at 08:25:32AM +0200, Laurent Pinchart wrote: > > > Hi Dave, > > > > > > Here's a pull request that adds HDMI support to the R-Car DU driver, > > > including a new slave encoder driver for the adv7511. > > > > > > The branch is based on a merge of drm-next and Simon's > > > tags/renesas-dt-du-for- v3.19 available at > > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git, for which > > > a pull request has been submitted for v3.19 to the ARM SoC maintainers. > > > > > > I'm leaving now for two weeks of holidays and would like to avoid missing > > > the merge window. Simon, could you please confirm that > > > tags/renesas-dt-du-for- v3.19 is stable and ack this pull request (and > > > possibly ping Dave on my behalf ;-)) ? Welcome back from vacation :) FYI renesas-dt-du-for was accepted by Arnd last week so it is rather unlikely it will change now: it should be a stable base. > > > > > > The following changes since commit > 19de43d4dea8712b3574d72d3d8aa16cd17e7fed: > > > Merge tag 'tags/renesas-dt-du-for-v3.19' into drm/next/adv7511-base > > > > > > (2014-11-07 08:06:16 +0200) > > > > > > are available in the git repository at: > > > git://linuxtv.org/pinchartl/fbdev.git > > > > > > for you to fetch changes up to cc47927ca851110d2c387a7d9fd7086112abb92e: > > > drm: Add adv7511 encoder driver (2014-11-07 08:19:06 +0200) > > > > > > > > > > > > Lars-Peter Clausen (2): > > > drm: Decouple EDID parsing from I2C adapter > > > > So somehow the pull request seems to lack the branch so I can't actually > > take a lookc. > > git request-pull is playing trick with me :-/ I'll try to fix that. > > The branch is available at > > git://linuxtv.org/pinchartl/fbdev.git drm/next/du > > (http://git.linuxtv.org/cgit.cgi/pinchartl/fbdev.git/commit/?h=drm/next/du) > > > But this patch here seems to lack review: > > - kerneldoc for the newly exported function is missing > > I'll fix that. > > > - the interface looks rather backwards: Either this still does i2c reads, > > and then you'd just need a i2c-over-whatever adapter to make it work. Or > > you have other magic means to optain an edid block, in which case just > > do that and then feed the edid drm_add_edid_modes. > > I have a magic way to get EDID over I2C :-) Basically the ADV7511 controls > the > DDC bus, and exposes EDID data over I2C using vendor commands. To read an > EDID > block I have to write an ADV7511 register over I2C with the block number, > wait > for an interrupt, read a status register to check whether EDID data is > available or whether an error occurred, and then read EDID data from the > ADV7511 over I2C in 64-bytes chunks. This needs to be repeated for every > block. I thus can't use drm_get_edid() directly. > > > Nack from me in this form. And can we try not to be quite this sneaky with > > drm core patches going in through driver trees, please? > > > > Thanks, Daniel > > > > > drm: Add adv7511 encoder driver > > > > > > Laurent Pinchart (6): > > > drm: rcar-du: Remove platform data support > > > drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init() > > > drm: rcar-du: Replace direct DRM encoder access with cast macro > > > drm: rcar-du: Replace drm_encoder with drm_slave_encoder > > > drm: rcar-du: Add HDMI encoder and connector support > > > video: Add ADV751[13] DT bindings documentation > > > > > > Documentation/devicetree/bindings/video/adi,adv7511.txt | 88 ++ > > > drivers/gpu/drm/drm_edid.c | 27 +- > > > drivers/gpu/drm/i2c/Kconfig |6 + > > > drivers/gpu/drm/i2c/Makefile|2 + > > > drivers/gpu/drm/i2c/adv7511.c | 1010 ++ > > > drivers/gpu/drm/i2c/adv7511.h | 289 +++ > > > drivers/gpu/drm/rcar-du/Kconfig | 11 +- > > > drivers/gpu/drm/rcar-du/Makefile|2 + > > > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 10 +- > > > drivers/gpu/drm/rcar-du/rcar_du_drv.c |4 +- > > > drivers/gpu/drm/rcar-du/rcar_du_drv.h |2 - > > > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 45 +- > > > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 23 +- > > > drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 118 +++ > > > drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h | 31 + > > > drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 151 > > > drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h | 35 + > > > drivers/gpu/drm/rcar-du/
[Bug 72785] bfgminer --scrypt on 7xxx+
https://bugs.freedesktop.org/show_bug.cgi?id=72785 --- Comment #39 from Michel Dänzer --- (In reply to Linux User from comment #36) > P.P.S. and what about better fan/intensity control? See bug 73338. (In reply to Linux User from comment #38) > P.S. also there is another silly issue. If I just install Ubuntu and run > bfgminer on multi-GPU setup within X session, it would only see 1st GPU > (where X server running). Remaining GPUs are not detected. Fix is to either > run bfgminer as root (extremely unsafe!!!) or create new user and make > "video" it's primary group. The user who installs Ubuntu is a member of > "video" group, but "video" is his secondary group, which is very common. > Somehow, kernel seems to disregard permissions in such case and would issue > -EPERM on certain syscall, making bfgminer unable to find GPUs except one > used by X. Generally it means that user can't use more than 1 GPU unless he > is either root (very dangerous!) or video is his primary group (inconvenient > and uncommon). I believe it is a bug and I should file it? Since I fail to > understand how average Joe would be able to use some OpenCL program in > multi-GPU setup and get it working "by default" on all available GPUs. I > guess I should file it as new bug? Is it kernel issue or MESA, etc? You should report this to Ubuntu. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/7b3aa2ff/attachment.html>
[Bug 88781] black screen when starting X with radeon
https://bugzilla.kernel.org/show_bug.cgi?id=88781 --- Comment #2 from Michel Dänzer --- Duplicate of bug 88481. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 86591] Clicking popping sound while playing DTS-HD MA / TrueHD video
https://bugs.freedesktop.org/show_bug.cgi?id=86591 Michel Dänzer changed: What|Removed |Added Component|Driver/radeonhd |DRM/Radeon Assignee|eich at pdx.freedesktop.org|dri-devel at lists.freedesktop ||.org Product|xorg|DRI QA Contact|xorg-team at lists.x.org | -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/d87736e9/attachment.html>
[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Andreas,
On Mon, Nov 24, 2014 at 8:35 PM, Andreas Färber wrote:
> Hi,
>
> Am 24.11.2014 um 11:05 schrieb Javier Martinez Canillas:
>> On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote:
>>> On 11/21/2014 06:32 PM, Ajay kumar wrote:
I have rebased my bridge series on top of linux-next.
This is my git log:
4b38a6f Revert "Revert "ARM: exynos_defconfig: Enable options for
display panel support""
6fb39a7 ARM: dts: peach-pit: represent the connection between bridge
and panel using videoport and endpoints
aee649c ARM: dts: snow: represent the connection between bridge and
panel using videoport and endpoints
5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
581257f Documentation: bridge: Add documentation for ps8622 DT properties
178e8b9 Documentation: devicetree: Add vendor prefix for parade
0ceea75 Documentation: drm: bridge: move to video/bridge
f143e2e drm/bridge: ptn3460: use gpiod interface
2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach
32ac563 drm/bridge: ptn3460: support drm_panel
91c6c30 drm/exynos: dp: support drm_bridge
7eea7eb drm/bridge: ptn3460: Convert to i2c driver model
602f343 drm/bridge: make bridge registration independent of drm flow
14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
2c01ac4 drm/bridge: ptn3460: Few trivial cleanups
7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
28655d1 drm/exynos: Move platform drivers registration to module init
ed6778a Add linux-next specific files for 20141121
I have attached the rebased patches as well.
I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*.
Display is totally fine with exynos_defconfig (booting is fine even
with CONFIG_SND_SOC_SNOW=y)
>>>
>>> Thanks for forward porting your patches to linux-next. Unfortunately I
>>> won't have time to test them until Monday but I wonder why you didn't
>>> have the boot issues that we have with next-20141121.
>>
>> I tested your ToT patches on top of next-20141121, this is my git log:
>>
>> 93fe3d7 Revert "Revert "ARM: exynos_defconfig: Enable options for display
>> panel support""
>> 552f74e ARM: dts: peach-pit: represent the connection between bridge and
>> panel using videoport and endpoints
>> dbbc293 ARM: dts: snow: represent the connection between bridge and panel
>> using videoport and endpoints
>> d8687f8 drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
>> f29a649 Documentation: bridge: Add documentation for ps8622 DT properties
>> 6ade887 Documentation: devicetree: Add vendor prefix for parade
>> d81c42d Documentation: drm: bridge: move to video/bridge
>> 50b9828 drm/bridge: ptn3460: use gpiod interface
>> 1274c56 drm/bridge: ptn3460: probe connector at the end of bridge attach
>> f3cf063 drm/bridge: ptn3460: support drm_panel
>> cab682b drm/exynos: dp: support drm_bridge
>> 6e78916 drm/bridge: ptn3460: Convert to i2c driver model
>> 93f4b5f drm/bridge: make bridge registration independent of drm flow
>> 81a038f drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
>> eb6996e drm/bridge: ptn3460: Few trivial cleanups
>> c41fa5d arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>> 51b2c75 drm/exynos: Move platform drivers registration to module init
>> ed6778a Add linux-next specific files for 20141121
>>
>>> I found that the commit ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add
>>> runtime Power Management support v12") had to be reverted in order to
>>> boot linux-next.
>>>
>>
>> Display works but I needed to revert the mentioned commit, otherwise
>> the boot hangs as reported before. I'm using exynos_defconfig and this
>> kernel command line:
>>
>> console=ttySAC3,115200N8 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw
>
> I tested Spring with next-20141124, and finally got it to work! :)
That's great to hear!
> Thanks a lot, Ajay and Javier!
>
> To be on the safe side, I reverted the patch pointed out by Javier and
> was still using clk_ignore_unused.
>
> Ajay, note that your rebased Snow patch has the last hunk indented one
> level too deep.
Ahh, right. I just saw that. I am not sure if these patches go in just
like this,
or I need to rebase on top of kukjin's for-next or some other branch/tree!
Will take care of this, then.
>
> I'll post a cleaned-up bridge patch for Spring later.
Ok, AFAIK, peach_pit DT properties can be reused.
Ajay
[PATCH] drm/vmwgfx: Fix error printout on signals pending
The function vmw_master_check() might return -ERESTARTSYS if there is a
signal pending, indicating that the IOCTL should be rerun, potentially from
user-space. At that point we shouldn't print out an error message since that
is not an error condition. In short, avoid bloating the kernel log when a
process refuses to die on SIGTERM.
Cc:
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 25f3c25..daeca57 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1063,8 +1063,12 @@ static long vmw_generic_ioctl(struct file *filp,
unsigned int cmd,
vmaster = vmw_master_check(dev, file_priv, flags);
if (unlikely(IS_ERR(vmaster))) {
- DRM_INFO("IOCTL ERROR %d\n", nr);
- return PTR_ERR(vmaster);
+ ret = PTR_ERR(vmaster);
+
+ if (ret != -ERESTARTSYS)
+ DRM_INFO("IOCTL ERROR Command %d, Error %ld.\n",
+nr, ret);
+ return ret;
}
ret = ioctl_func(filp, cmd, arg);
--
1.8.3.2
[Bug 86490] Some Unreal Engine 4.5 Demos render only black on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=86490 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Michel Dänzer --- (In reply to Andy Furniss from comment #1) > If your llvm is new enough could be - > > https://bugs.freedesktop.org/show_bug.cgi?id=86432 Light Room Interior Day Demo works for me now, so assuming that was it. *** This bug has been marked as a duplicate of bug 86432 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/c4a0f062/attachment.html>
[Bug 86432] llvm Unreal Elemental rendering regression
https://bugs.freedesktop.org/show_bug.cgi?id=86432 Michel Dänzer changed: What|Removed |Added CC||haagch at frickel.club --- Comment #16 from Michel Dänzer --- *** Bug 86490 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/33ea60f7/attachment.html>
[Bug 84627] (bisected) 32bit corruption with PIPE_USAGE_STREAM reverted
https://bugs.freedesktop.org/show_bug.cgi?id=84627 --- Comment #29 from Michel Dänzer --- (In reply to Nils Holland from comment #28) > any more help needed in diagnosing this, and if so, anything I can do to help? See comment 22. From comment 23, it sounds like it might actually be a 32-bit toolchain issue, which somehow leaks into 64-bit kernel builds as well. If there's any way you can run a 'real' 64-bit kernel on your distro, that's probably the best way to avoid the problem for now. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/8672c8a3/attachment-0001.html>
3.18-rc regression: drm/nouveau: use shared fences for readable objects
Hey, Op 22-11-14 om 21:16 schreef Michael Marineau: > On Nov 22, 2014 11:45 AM, "Michael Marineau" wrote: >> >> On Nov 22, 2014 8:56 AM, "Maarten Lankhorst" < > maarten.lankhorst at canonical.com> wrote: >>> Hey, >>> >>> Op 22-11-14 om 01:19 schreef Michael Marineau: On Thu, Nov 20, 2014 at 12:53 AM, Maarten Lankhorst wrote: > Op 20-11-14 om 05:06 schreef Michael Marineau: >> On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst >> wrote: >>> Hey, >>> >>> On 19-11-14 07:43, Michael Marineau wrote: On 3.18-rc kernel's I have been intermittently experiencing GPU lockups shortly after startup, accompanied with one or both of the following errors: nouveau E[ PFIFO][:01:00.0] read fault at 0x000734a000 [PTE] from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown] nouveau E[ DRM] GPU lockup - switching to software fbcon I was able to trace the issue with bisect to commit 809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared fences for readable objects". The lockups appear to have cleared > up since reverting that and a few related followup commits: 809e9447: "drm/nouveau: use shared fences for readable objects" 055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1" e3be4c23: "drm/nouveau: specify if interruptible wait is desired > in nouveau_fence_sync" 15a996bb: "drm/nouveau: assign fence_chan->name correctly" >>> Weird. I'm not sure yet what causes it. >>> >>> > http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect&id=86be4f216bbb9ea3339843a5658d4c21162c7ee2 >> Building a kernel from that commit gives me an entirely new > behavior: >> X hangs for at least 10-20 seconds at a time with brief moments of >> responsiveness before hanging again while gitk on the kernel repo >> loads. Otherwise the system is responsive. The head of that >> fixed-fences-for-bisect branch (1c6aafb5) which is the "use shared >> fences for readable objects" commit I originally bisected to does >> feature the complete lockups I was seeing before. > Ok for the sake of argument lets just assume they're separate bugs, > and we should look at xorg > hanging first. > > Is there anything in the dmesg when the hanging happens? > > And it's probably 15 seconds, if it's called through > nouveau_fence_wait. > Try changing else if (!ret) to else if (WARN_ON(!ret)) in that > function, and see if you get some dmesg spam. :) Adding the WARN_ON to 86be4f21 repots the following: [ 1188.676073] [ cut here ] [ 1188.676161] WARNING: CPU: 1 PID: 474 at drivers/gpu/drm/nouveau/nouveau_fence.c:359 nouveau_fence_wait.part.9+0x33/0x40 [nouveau]() [ 1188.676166] Modules linked in: rndis_host cdc_ether usbnet mii bnep ecb btusb bluetooth rfkill bridge stp llc hid_generic usb_storage joydev mousedev hid_apple usbhid bcm5974 nls_iso8859_1 nls_cp437 vfat fat nouveau snd_hda_codec_hdmi coretemp x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm iTCO_wdt crct10dif_pclmul iTCO_vendor_support crc32c_intel evdev aesni_intel mac_hid aes_x86_64 lrw glue_helper ablk_helper applesmc snd_hda_codec_cirrus cryptd input_polldev snd_hda_codec_generic mxm_wmi led_class wmi microcode hwmon snd_hda_intel ttm snd_hda_controller lpc_ich i2c_i801 mfd_core snd_hda_codec i2c_algo_bit snd_hwdep drm_kms_helper snd_pcm sbs drm apple_gmux i2ccore snd_timer snd agpgart mei_me soundcore sbshc mei video xhci_hcd usbcore usb_common apple_bl button battery ac efivars autofs4 [ 1188.676300] efivarfs [ 1188.676308] CPU: 1 PID: 474 Comm: Xorg Tainted: GW 3.17.0-rc2-nvtest+ #147 [ 1188.676313] Hardware name: Apple Inc. MacBookPro11,3/Mac-2BD1B31983FE1663, BIOS MBP112.88Z.0138.B11.1408291503 08/29/2014 [ 1188.676316] 0009 88045daebce8 814f0c09 [ 1188.676325] 88045daebd20 8104ea5d 88006a6c1468 fff0 [ 1188.676333] 88006a6c1000 88045daebd30 [ 1188.676341] Call Trace: [ 1188.676356] [] dump_stack+0x4d/0x66 [ 1188.676369] [] warn_slowpath_common+0x7d/0xa0 [ 1188.676377] [] warn_slowpath_null+0x1a/0x20 [ 1188.676439] [] nouveau_fence_wait.part.9+0x33/0x40 [nouveau] [ 1188.676496] [] nouveau_fence_wait+0x16/0x30 > [nouveau] [ 1188.676552] [] nouveau_gem_ioctl_cpu_prep+0xef/0x1f0 [nouveau] [ 1188.676578] [] drm_ioctl+0x1ec/0x660 [drm] [ 1188.676590] [] ? > _raw_spin_unlock_irqrestore+0x36/0x70 [ 1188.676600] [] ? trace_hardirqs_on+0xd/0x10 [ 1188.676655] [] nouveau_drm_ioctl+0x54/0xc0 > [nouveau] [ 1188.676663] [] do_vfs_ioc
[Bug 83510] Graphical glitches in Unreal Engine 4
https://bugs.freedesktop.org/show_bug.cgi?id=83510 --- Comment #7 from Christoph Haag --- I think in the new "Lightroom Interior" the blackness glitch is visible in a more interesting way: https://www.youtube.com/watch?v=R9N-srsF_Fg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/a727496b/attachment.html>
[Bug 86490] Some Unreal Engine 4.5 Demos render only black on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=86490 --- Comment #3 from Christoph Haag --- I can confirm, it renders now. Thanks for the info. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/73f47082/attachment.html>
[Bug 82667] "Distance" game closed alpha: Changing shadow settings segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=82667 Christoph Haag changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Christoph Haag --- Both games had multiple updates by now. Whether the games got fixed, or the driver, I don't know. But it doesn't happen anymore. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/a407dd83/attachment.html>
[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init
https://bugzilla.kernel.org/show_bug.cgi?id=85491 --- Comment #15 from Marek --- Hi, I tried also Kubuntu with new kernel (newer than 3.15) and it was not working (previous versions of kernel were working also with Kubuntu) so it is not Fedora specific problem. The result of bisection is that the first bad commit is: e5558d1a516fa6924fa8d53152b665d4c26f142e Merge branches 'dma-api', 'pci/virtualization', 'pci/msi', 'pci/misc' and 'pci/resource' into next I took a look at code that was changed, but it is (yet) far beyond my abylities to come to some conclusion/quess. I am java developer and in the past I have written also few small C programs - so if needed I could help with some testing/debugging. -- You are receiving this mail because: You are watching the assignee of the bug.
[patch] amdkfd: fix some error handling in ioctl
There is a typo here so the errors from kfd_bind_process_to_device()
are not detected.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 64c73ba..c5dd0ae 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -236,7 +236,7 @@ static long kfd_ioctl_create_queue(struct file *filep,
struct kfd_process *p,
mutex_lock(&p->mutex);
pdd = kfd_bind_process_to_device(dev, p);
- if (IS_ERR(pdd) < 0) {
+ if (IS_ERR(pdd)) {
err = PTR_ERR(pdd);
goto err_bind_process;
}
@@ -381,7 +381,7 @@ static long kfd_ioctl_set_memory_policy(struct file *filep,
mutex_lock(&p->mutex);
pdd = kfd_bind_process_to_device(dev, p);
- if (IS_ERR(pdd) < 0) {
+ if (IS_ERR(pdd)) {
err = PTR_ERR(pdd);
goto out;
}
[patch] amdkfd: fix an error handling bug in pqm_create_queue()
The call to kernel_queue_uninit(NULL) will trigger a BUG(), and also the
error code is incorrect.
Fixes: 45102048f77e ('amdkfd: Add process queue manager module')
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
index c7859fc..7ce7a25 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
@@ -208,7 +208,7 @@ int pqm_create_queue(struct process_queue_manager *pqm,
case KFD_QUEUE_TYPE_DIQ:
kq = kernel_queue_init(dev, KFD_QUEUE_TYPE_DIQ);
if (kq == NULL) {
- kernel_queue_uninit(kq);
+ retval = -ENOMEM;
goto err_create_queue;
}
kq->queue->properties.queue_id = *qid;
[PATCH v2 1/6] drm/plane: Pass old state to ->atomic_update()
From: Thierry Reding
In most situations it will be useful to have the old state passed to the
->atomic_update() callback. For example if a plane is being disabled the
new state's .crtc field will be NULL, but some drivers may rely on this
field to program the CRTCs registers.
v2: rename variable to old_plane_state and remove redundant comment as
suggested by Daniel Vetter, remove an Exynos hunk that doesn't apply to
drm-next and add a hunk for pending MSM mdp5 changes
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic_helper.c | 5 -
drivers/gpu/drm/drm_plane_helper.c| 2 +-
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 3 ++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 3 ++-
include/drm/drm_plane_helper.h| 3 ++-
5 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 25d8263f9869..7f020403ffe0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1014,6 +1014,7 @@ void drm_atomic_helper_commit_planes(struct drm_device
*dev,
for (i = 0; i < nplanes; i++) {
struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = old_state->planes[i];
+ struct drm_plane_state *old_plane_state;
if (!plane)
continue;
@@ -1023,7 +1024,9 @@ void drm_atomic_helper_commit_planes(struct drm_device
*dev,
if (!funcs || !funcs->atomic_update)
continue;
- funcs->atomic_update(plane);
+ old_plane_state = old_state->plane_states[i];
+
+ funcs->atomic_update(plane, old_plane_state);
}
for (i = 0; i < ncrtcs; i++) {
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index 2dd30518f9a2..aa399db5d36d 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -443,7 +443,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
crtc_funcs[i]->atomic_begin(crtc[i]);
}
- plane_funcs->atomic_update(plane);
+ plane_funcs->atomic_update(plane, plane_state);
for (i = 0; i < 2; i++) {
if (crtc_funcs[i] && crtc_funcs[i]->atomic_flush)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index 76d0a40c7138..1e5ebe83647d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -107,7 +107,8 @@ static int mdp4_plane_atomic_check(struct drm_plane *plane,
return 0;
}
-static void mdp4_plane_atomic_update(struct drm_plane *plane)
+static void mdp4_plane_atomic_update(struct drm_plane *plane,
+struct drm_plane_state *old_state)
{
struct drm_plane_state *state = plane->state;
int ret;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 533df7caa310..26e5fdea6594 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -213,7 +213,8 @@ static int mdp5_plane_atomic_check(struct drm_plane *plane,
return 0;
}
-static void mdp5_plane_atomic_update(struct drm_plane *plane)
+static void mdp5_plane_atomic_update(struct drm_plane *plane,
+struct drm_plane_state *old_state)
{
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
struct drm_plane_state *state = plane->state;
diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
index 00ad3b3c5324..d3122cd0609b 100644
--- a/include/drm/drm_plane_helper.h
+++ b/include/drm/drm_plane_helper.h
@@ -59,7 +59,8 @@ struct drm_plane_helper_funcs {
int (*atomic_check)(struct drm_plane *plane,
struct drm_plane_state *state);
- void (*atomic_update)(struct drm_plane *plane);
+ void (*atomic_update)(struct drm_plane *plane,
+ struct drm_plane_state *old_state);
};
static inline void drm_plane_helper_add(struct drm_plane *plane,
--
2.1.3
[PATCH v2 3/6] drm/plane: Add optional ->atomic_disable() callback
From: Thierry Reding
In order to prevent drivers from having to perform the same checks over
and over again, add an optional ->atomic_disable callback which the core
calls under the right circumstances.
v2: pass old state and detect edges to avoid calling ->atomic_disable on
already disabled planes, remove redundant comment (Daniel Vetter)
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic_helper.c | 15 +--
drivers/gpu/drm/drm_plane_helper.c | 10 +-
include/drm/drm_crtc.h | 26 ++
include/drm/drm_plane_helper.h | 3 +++
4 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 7f020403ffe0..a1c7d1b73f86 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1020,12 +1020,23 @@ void drm_atomic_helper_commit_planes(struct drm_device
*dev,
continue;
funcs = plane->helper_private;
-
- if (!funcs || !funcs->atomic_update)
+ if (!funcs)
continue;
old_plane_state = old_state->plane_states[i];
+ /*
+* Special-case disabling the plane if drivers support it.
+*/
+ if (drm_plane_disabled(plane, old_plane_state) &&
+ funcs->atomic_disable) {
+ funcs->atomic_disable(plane, old_plane_state);
+ continue;
+ }
+
+ if (!funcs->atomic_update)
+ continue;
+
funcs->atomic_update(plane, old_plane_state);
}
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index aa399db5d36d..8c81d3a9e625 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -443,7 +443,15 @@ int drm_plane_helper_commit(struct drm_plane *plane,
crtc_funcs[i]->atomic_begin(crtc[i]);
}
- plane_funcs->atomic_update(plane, plane_state);
+ /*
+* Drivers may optionally implement the ->atomic_disable callback, so
+* special-case that here.
+*/
+ if (drm_plane_disabled(plane, plane_state) &&
+ plane_funcs->atomic_disable)
+ plane_funcs->atomic_disable(plane, plane_state);
+ else
+ plane_funcs->atomic_update(plane, plane_state);
for (i = 0; i < 2; i++) {
if (crtc_funcs[i] && crtc_funcs[i]->atomic_flush)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6da67dfcb6fc..80d0f1c2b265 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -795,6 +795,32 @@ struct drm_plane {
struct drm_plane_state *state;
};
+/*
+ * drm_plane_disabled - check whether a plane is being disabled
+ * @plane: plane object
+ * @old_state: previous atomic state
+ *
+ * Checks the atomic state of a plane to determine whether it's being disabled
+ * or not. This also WARNs if it detects an invalid state (both CRTC and FB
+ * need to either both be NULL or both be non-NULL).
+ *
+ * RETURNS:
+ * True if the plane is being disabled, false otherwise.
+ */
+static inline bool drm_plane_disabled(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ /*
+* When disabling a plane, CRTC and FB should always be NULL together.
+* Anything else should be considered a bug in the atomic core, so we
+* gently warn about it.
+*/
+ WARN_ON((plane->state->crtc == NULL && plane->state->fb != NULL) ||
+ (plane->state->crtc != NULL && plane->state->fb == NULL));
+
+ return (!old_state || old_state->crtc) && !plane->state->crtc;
+}
+
/**
* struct drm_bridge_funcs - drm_bridge control functions
* @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
index 0f2230311aa8..680be61ef20a 100644
--- a/include/drm/drm_plane_helper.h
+++ b/include/drm/drm_plane_helper.h
@@ -52,6 +52,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc,
* @cleanup_fb: cleanup a framebuffer when it's no longer used by the plane
* @atomic_check: check that a given atomic state is valid and can be applied
* @atomic_update: apply an atomic state to the plane
+ * @atomic_disable: disable the plane
*
* The helper operations are called by the mid-layer CRTC helper.
*/
@@ -65,6 +66,8 @@ struct drm_plane_helper_funcs {
struct drm_plane_state *state);
void (*atomic_update)(struct drm_plane *plane,
struct drm_plane_state *old_state);
+ void (*atomic_disable)(struct drm_plane *plane,
+ struct drm_plane_state *old_state);
};
static inline void drm_plane_helpe
[PATCH v2 2/6] drm/plane: Add missing kerneldoc
From: Thierry Reding The plane helpers aren't pulled into the DocBook yet, so these weren't noticed. Reviewed-by: Daniel Vetter Signed-off-by: Thierry Reding --- include/drm/drm_plane_helper.h | 4 1 file changed, 4 insertions(+) diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h index d3122cd0609b..0f2230311aa8 100644 --- a/include/drm/drm_plane_helper.h +++ b/include/drm/drm_plane_helper.h @@ -48,6 +48,10 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, /** * drm_plane_helper_funcs - helper operations for CRTCs + * @prepare_fb: prepare a framebuffer for use by the plane + * @cleanup_fb: cleanup a framebuffer when it's no longer used by the plane + * @atomic_check: check that a given atomic state is valid and can be applied + * @atomic_update: apply an atomic state to the plane * * The helper operations are called by the mid-layer CRTC helper. */ -- 2.1.3
[PATCH v2 4/6] drm: Make drm_atomic_helper.h standalone includible
From: Thierry Reding This header uses a bunch of declarations from the drm/drm_crtc.h header, so make sure to include that as well so that drm_atomic_helper.h can be included standalone. Reviewed-by: Daniel Vetter Signed-off-by: Thierry Reding --- include/drm/drm_atomic_helper.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h index 64b4e91b93bc..70a83197ef66 100644 --- a/include/drm/drm_atomic_helper.h +++ b/include/drm/drm_atomic_helper.h @@ -28,6 +28,8 @@ #ifndef DRM_ATOMIC_HELPER_H_ #define DRM_ATOMIC_HELPER_H_ +#include + int drm_atomic_helper_check(struct drm_device *dev, struct drm_atomic_state *state); int drm_atomic_helper_commit(struct drm_device *dev, -- 2.1.3
[PATCH v2 6/6] drm: Free atomic state during cleanup
From: Thierry Reding The current state of CRTCs, planes and connectors currently leaks during DRM driver ->unload() unless drivers explicitly clean it up. Since there is nothing driver-specific about it, that cleanup can be done within the DRM core. Reviewed-by: Daniel Vetter Signed-off-by: Thierry Reding --- drivers/gpu/drm/drm_crtc.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index de09c1ff0714..9f736417a95d 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -721,6 +721,10 @@ void drm_crtc_cleanup(struct drm_crtc *crtc) drm_mode_object_put(dev, &crtc->base); list_del(&crtc->head); dev->mode_config.num_crtc--; + + WARN_ON(crtc->state && !crtc->funcs->atomic_destroy_state); + if (crtc->state && crtc->funcs->atomic_destroy_state) + crtc->funcs->atomic_destroy_state(crtc, crtc->state); } EXPORT_SYMBOL(drm_crtc_cleanup); @@ -918,6 +922,11 @@ void drm_connector_cleanup(struct drm_connector *connector) connector->name = NULL; list_del(&connector->head); dev->mode_config.num_connector--; + + WARN_ON(connector->state && !connector->funcs->atomic_destroy_state); + if (connector->state && connector->funcs->atomic_destroy_state) + connector->funcs->atomic_destroy_state(connector, + connector->state); } EXPORT_SYMBOL(drm_connector_cleanup); @@ -1244,6 +1253,10 @@ void drm_plane_cleanup(struct drm_plane *plane) if (plane->type == DRM_PLANE_TYPE_OVERLAY) dev->mode_config.num_overlay_plane--; drm_modeset_unlock_all(dev); + + WARN_ON(plane->state && !plane->funcs->atomic_destroy_state); + if (plane->state && plane->funcs->atomic_destroy_state) + plane->funcs->atomic_destroy_state(plane, plane->state); } EXPORT_SYMBOL(drm_plane_cleanup); -- 2.1.3
[PATCH v2 5/6] drm: Make drm_atomic.h standalone includible
From: Thierry Reding This header file makes use of a bunch of structures declared in the drm_crtc.h header file. Include that to make sure the drm_atomic.h header can be included standalone. Signed-off-by: Thierry Reding --- include/drm/drm_atomic.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 9d919168bc11..e224ccfa11ca 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -28,6 +28,8 @@ #ifndef DRM_ATOMIC_H_ #define DRM_ATOMIC_H_ +#include + struct drm_atomic_state * __must_check drm_atomic_state_alloc(struct drm_device *dev); void drm_atomic_state_clear(struct drm_atomic_state *state); -- 2.1.3
[PATCH v2 3/6] drm/plane: Add optional ->atomic_disable() callback
On Tue, Nov 25, 2014 at 12:09:46PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> In order to prevent drivers from having to perform the same checks over
> and over again, add an optional ->atomic_disable callback which the core
> calls under the right circumstances.
>
> v2: pass old state and detect edges to avoid calling ->atomic_disable on
> already disabled planes, remove redundant comment (Daniel Vetter)
>
> Signed-off-by: Thierry Reding
Some minor bikesheds about consistency and clarity below.
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 15 +--
> drivers/gpu/drm/drm_plane_helper.c | 10 +-
> include/drm/drm_crtc.h | 26 ++
> include/drm/drm_plane_helper.h | 3 +++
> 4 files changed, 51 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 7f020403ffe0..a1c7d1b73f86 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1020,12 +1020,23 @@ void drm_atomic_helper_commit_planes(struct
> drm_device *dev,
> continue;
>
> funcs = plane->helper_private;
> -
> - if (!funcs || !funcs->atomic_update)
> + if (!funcs)
> continue;
>
> old_plane_state = old_state->plane_states[i];
>
> + /*
> + * Special-case disabling the plane if drivers support it.
> + */
> + if (drm_plane_disabled(plane, old_plane_state) &&
> + funcs->atomic_disable) {
> + funcs->atomic_disable(plane, old_plane_state);
> + continue;
> + }
> +
> + if (!funcs->atomic_update)
> + continue;
This looks dangerous - we really should either have the atomic_disable or
at least atomic_update. And plane transitional helpers exactly require
that. On the bikeshed front I also like the plane helper structure more
with the if () atomic_disalbel else atomic_update instead of the continue.
> +
> funcs->atomic_update(plane, old_plane_state);
> }
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index aa399db5d36d..8c81d3a9e625 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -443,7 +443,15 @@ int drm_plane_helper_commit(struct drm_plane *plane,
> crtc_funcs[i]->atomic_begin(crtc[i]);
> }
>
> - plane_funcs->atomic_update(plane, plane_state);
> + /*
> + * Drivers may optionally implement the ->atomic_disable callback, so
> + * special-case that here.
> + */
> + if (drm_plane_disabled(plane, plane_state) &&
> + plane_funcs->atomic_disable)
> + plane_funcs->atomic_disable(plane, plane_state);
> + else
> + plane_funcs->atomic_update(plane, plane_state);
>
> for (i = 0; i < 2; i++) {
> if (crtc_funcs[i] && crtc_funcs[i]->atomic_flush)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 6da67dfcb6fc..80d0f1c2b265 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -795,6 +795,32 @@ struct drm_plane {
> struct drm_plane_state *state;
> };
>
> +/*
> + * drm_plane_disabled - check whether a plane is being disabled
> + * @plane: plane object
> + * @old_state: previous atomic state
> + *
> + * Checks the atomic state of a plane to determine whether it's being
> disabled
> + * or not. This also WARNs if it detects an invalid state (both CRTC and FB
> + * need to either both be NULL or both be non-NULL).
> + *
> + * RETURNS:
> + * True if the plane is being disabled, false otherwise.
> + */
> +static inline bool drm_plane_disabled(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + /*
> + * When disabling a plane, CRTC and FB should always be NULL together.
> + * Anything else should be considered a bug in the atomic core, so we
> + * gently warn about it.
> + */
> + WARN_ON((plane->state->crtc == NULL && plane->state->fb != NULL) ||
> + (plane->state->crtc != NULL && plane->state->fb == NULL));
> +
> + return (!old_state || old_state->crtc) && !plane->state->crtc;
The !old_state check here confused me a bit, until I've realized that you
use this for transitional helpers too. What about adding
/* Cope with NULL old_state for transitional helpers. */
right above?
> +}
Hm, given that this is used by helpers maybe place it into
drm_atomic_helper.h? I'm also not too happy about the name, disabled
doesn't clearly only mean the enable->disable transition. What about
drm_atomic_plane_disabling instead, to make it clear we only care about
the transition? After all your kerneldoc also uses continuous ("being
disabled").
> +
> /**
> * struct d
[PATCH v2 3/6] drm/plane: Add optional ->atomic_disable() callback
+ * Checks the atomic state of a plane to determine whether it's being
> > disabled
> > + * or not. This also WARNs if it detects an invalid state (both CRTC and FB
> > + * need to either both be NULL or both be non-NULL).
> > + *
> > + * RETURNS:
> > + * True if the plane is being disabled, false otherwise.
> > + */
> > +static inline bool drm_plane_disabled(struct drm_plane *plane,
> > + struct drm_plane_state *old_state)
> > +{
> > + /*
> > +* When disabling a plane, CRTC and FB should always be NULL together.
> > +* Anything else should be considered a bug in the atomic core, so we
> > +* gently warn about it.
> > +*/
> > + WARN_ON((plane->state->crtc == NULL && plane->state->fb != NULL) ||
> > + (plane->state->crtc != NULL && plane->state->fb == NULL));
> > +
> > + return (!old_state || old_state->crtc) && !plane->state->crtc;
>
> The !old_state check here confused me a bit, until I've realized that you
> use this for transitional helpers too. What about adding
>
> /* Cope with NULL old_state for transitional helpers. */
>
> right above?
Sounds good.
>
> > +}
>
> Hm, given that this is used by helpers maybe place it into
> drm_atomic_helper.h?
It technically operates only on the drm_plane and drm_plane_state so
could be useful outside of helpers, but I have no objections to moving
it to the helpers.
> I'm also not too happy about the name, disabled
> doesn't clearly only mean the enable->disable transition. What about
> drm_atomic_plane_disabling instead, to make it clear we only care about
> the transition? After all your kerneldoc also uses continuous ("being
> disabled").
Okay, I can't think of anything better, so drm_atomic_plane_disabling()
it is.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/9fad09a8/attachment.sig>
[PATCH v2 3/6] drm/plane: Add optional ->atomic_disable() callback
On Tue, Nov 25, 2014 at 12:45:46PM +0100, Thierry Reding wrote:
> On Tue, Nov 25, 2014 at 12:22:34PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 25, 2014 at 12:09:46PM +0100, Thierry Reding wrote:
[...]
> > > +/*
> > > + * drm_plane_disabled - check whether a plane is being disabled
> > > + * @plane: plane object
> > > + * @old_state: previous atomic state
> > > + *
> > > + * Checks the atomic state of a plane to determine whether it's being
> > > disabled
> > > + * or not. This also WARNs if it detects an invalid state (both CRTC and
> > > FB
> > > + * need to either both be NULL or both be non-NULL).
> > > + *
> > > + * RETURNS:
> > > + * True if the plane is being disabled, false otherwise.
> > > + */
> > > +static inline bool drm_plane_disabled(struct drm_plane *plane,
> > > + struct drm_plane_state *old_state)
> > > +{
[...]
> > > + return (!old_state || old_state->crtc) && !plane->state->crtc;
> >
> > The !old_state check here confused me a bit, until I've realized that you
> > use this for transitional helpers too. What about adding
> >
> > /* Cope with NULL old_state for transitional helpers. */
> >
> > right above?
>
> Sounds good.
When I now thought about the reason again it took me a while to
reconstruct, so I figured I'd be extra verbose and used this:
/*
* When using the transitional helpers, old_state may be NULL. If so,
* we know nothing about the current state and have to assume that it
* might be enabled.
*/
Does that sound accurate and sufficient to you?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/bbd487ee/attachment.sig>
[RFC PATCH] drm/exynos: Add DECON driver
ping. On Tue, Nov 11, 2014 at 10:08 PM, Ajay kumar wrote: > Hi Inki, > > On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae wrote: >> >> Hi, >> >> Fortunately, I could get the user manual for Exynos7420. Below are my >> comments. >> >> Thanks, >> Inki Dae >> >> On 2014ë 10ì 23ì¼ 01:34, Ajay kumar wrote: >>> On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae wrote: Thanks for contribution. It seems reasonable that you separate device drivers into FIMD and DECON because many registers of them have many different offsets and fields. However, there may be a good solution that we can combine common sets of these drivers later. >>> Yes, this is the main reason behind sending this as RFC patch. >>> I want to know what's the best way to do this. >>> FIMD, 5433 DECON and Exynos7 DECON - all are different. >>> Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). >>> So, even I am not sure how the driver layouts should be! >> >> Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my >> understanding, Exynos7 doesn't mean one real SoC. > We shall use Exynos7 as per the discussion. > >>> Below are my comments. Thanks, Inki Dae On 2014ë 10ì 10ì¼ 21:48, Ajay Kumar wrote: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > DECON(Display and Enhancement Controller) is the new IP > in exynos7 SOC for generating video signals using pixel data. DECON was used since Exynos5430. And is Exynos5433 different from Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? >>> Yes, Exynos5433 DECON is very much different than Exynos7 DECON. >> >> Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead. > Again, we shall use Exynos7. > >>> I will see how manual can be arranged. >>> > > DECON driver can be used to drive 2 different interfaces on Exynos7: > DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) > > The existing FIMD driver code was used as a template to create > DECON driver. Only DECON-INT is supported as of now, and > DECON-EXT support will be added later. > > Signed-off-by: Akshu Agrawal > Signed-off-by: Ajay Kumar > --- > .../devicetree/bindings/video/exynos-decon.txt | 68 ++ > drivers/gpu/drm/exynos/Kconfig | 11 +- > drivers/gpu/drm/exynos/Makefile|1 + > drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 > drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- > drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + > include/video/samsung_decon.h | 346 +++ > 7 files changed, 1537 insertions(+), 3 deletions(-) > create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt > create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c > create mode 100644 include/video/samsung_decon.h > > diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt b/Documentation/devicetree/bindings/video/exynos-decon.txt > new file mode 100644 > index 000..e865650 > --- /dev/null > +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt > @@ -0,0 +1,68 @@ > +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) > + > +DECON (Display and Enhancement Controller) is the Display Controller for the > +Exynos7 series of SoCs which transfers the image data from a video memory > +buffer to an external LCD interface. > + > +Required properties: > +- compatible: value should be "samsung,exynos7-decon"; If exynos5433 was just renamed to exynos7 then, it should be one of the following: (a) "samsung,exynos5430-decon" for Display and enhancement controller IP for Exynos5430 (b) "samsung,exynos7" for Display and enhancement controller IP for Exynos7 Or, (a) "samsung,exynos5430-decon" for Display and enhancement controller IP for Exynos5430 (b) "samsung,exynos5433-decon" for Display and enhancement controller IP for Exynos5433 (c) "samsung,exynos7" for Display and enhancement controller IP for Exynos7 >>> Eventually, we will end up here. >>> > + > +- reg: physical base address and length of the DECON registers set. > + > +- interrupt-parent: should be the phandle of the decon controller's > + parent interrupt controller. > + > +- interrupts: should contain a list of all DECON IP block interrupts in the > + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt > specifier > + format depends on the interrupt controller used. > + > +- interrupt-name
[PATCH v2 3/6] drm/plane: Add optional ->atomic_disable() callback
On Tue, Nov 25, 2014 at 12:57:04PM +0100, Thierry Reding wrote:
> On Tue, Nov 25, 2014 at 12:45:46PM +0100, Thierry Reding wrote:
> > On Tue, Nov 25, 2014 at 12:22:34PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 25, 2014 at 12:09:46PM +0100, Thierry Reding wrote:
> [...]
> > > > +/*
> > > > + * drm_plane_disabled - check whether a plane is being disabled
> > > > + * @plane: plane object
> > > > + * @old_state: previous atomic state
> > > > + *
> > > > + * Checks the atomic state of a plane to determine whether it's being
> > > > disabled
> > > > + * or not. This also WARNs if it detects an invalid state (both CRTC
> > > > and FB
> > > > + * need to either both be NULL or both be non-NULL).
> > > > + *
> > > > + * RETURNS:
> > > > + * True if the plane is being disabled, false otherwise.
> > > > + */
> > > > +static inline bool drm_plane_disabled(struct drm_plane *plane,
> > > > + struct drm_plane_state *old_state)
> > > > +{
> [...]
> > > > + return (!old_state || old_state->crtc) && !plane->state->crtc;
> > >
> > > The !old_state check here confused me a bit, until I've realized that you
> > > use this for transitional helpers too. What about adding
> > >
> > > /* Cope with NULL old_state for transitional helpers. */
> > >
> > > right above?
> >
> > Sounds good.
>
> When I now thought about the reason again it took me a while to
> reconstruct, so I figured I'd be extra verbose and used this:
>
> /*
>* When using the transitional helpers, old_state may be NULL. If so,
>* we know nothing about the current state and have to assume that it
>* might be enabled.
>*/
>
> Does that sound accurate and sufficient to you?
Hm, thinking about this some more this will result in a slight difference
in behaviour, at least when drivers just use the helper ->reset functions
but don't disable everything:
- With transitional helpers we assume we know nothing and call
->atomic_disable.
- With atomic old_state->crtc == NULL in the same situation right after
boot-up, but we asssume the plane is really off and _dont_ call
->atomic_disable.
Should we instead check for (old_state && old_state->crtc) and state that
drivers need to make sure they don't have stuff hanging around?
Or maybe just a note that there's a difference in behaviour here?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 3/6] drm/plane: Add optional ->atomic_disable() callback
On Tue, Nov 25, 2014 at 12:45:46PM +0100, Thierry Reding wrote:
> On Tue, Nov 25, 2014 at 12:22:34PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 25, 2014 at 12:09:46PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > In order to prevent drivers from having to perform the same checks over
> > > and over again, add an optional ->atomic_disable callback which the core
> > > calls under the right circumstances.
> > >
> > > v2: pass old state and detect edges to avoid calling ->atomic_disable on
> > > already disabled planes, remove redundant comment (Daniel Vetter)
> > >
> > > Signed-off-by: Thierry Reding
> >
> > Some minor bikesheds about consistency and clarity below.
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 15 +--
> > > drivers/gpu/drm/drm_plane_helper.c | 10 +-
> > > include/drm/drm_crtc.h | 26 ++
> > > include/drm/drm_plane_helper.h | 3 +++
> > > 4 files changed, 51 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 7f020403ffe0..a1c7d1b73f86 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -1020,12 +1020,23 @@ void drm_atomic_helper_commit_planes(struct
> > > drm_device *dev,
> > > continue;
> > >
> > > funcs = plane->helper_private;
> > > -
> > > - if (!funcs || !funcs->atomic_update)
> > > + if (!funcs)
> > > continue;
> > >
> > > old_plane_state = old_state->plane_states[i];
> > >
> > > + /*
> > > + * Special-case disabling the plane if drivers support it.
> > > + */
> > > + if (drm_plane_disabled(plane, old_plane_state) &&
> > > + funcs->atomic_disable) {
> > > + funcs->atomic_disable(plane, old_plane_state);
> > > + continue;
> > > + }
> > > +
> > > + if (!funcs->atomic_update)
> > > + continue;
> >
> > This looks dangerous - we really should either have the atomic_disable or
> > at least atomic_update. And plane transitional helpers exactly require
> > that.
>
> Note that this isn't anything that this patch introduces. This function
> has been optional since the drm_atomic_helper_commit_planes() was first
> introduced. That said, I agree that ->atomic_update() should not be
> optional, but I'd propose making that change in a precursory patch. That
> is, remove the check for !funcs->atomic_update and let the kernel crash
> if the driver doesn't provide it (drm_plane_helper_commit() will already
> oops in that case anyway).
>
> > On the bikeshed front I also like the plane helper structure more
> > with the if () atomic_disalbel else atomic_update instead of the continue.
>
> The existing code was using this structure, but I think with the above
> change to make ->atomic_update() mandatory it would make more sense to
> turn this into a more idiomatic if/else.
Oh right I've missed that there's you just moved the check around in your
patch. Still transitional helpers requires this, and I can't think of a
case where we don't need this really. So if you feel like a quick
follow-up patch that would be great.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[patch] amdkfd: fix some error handling in ioctl
On 11/25/2014 12:21 PM, Dan Carpenter wrote:
> There is a typo here so the errors from kfd_bind_process_to_device()
> are not detected.
>
> Signed-off-by: Dan Carpenter
>
Patch is:
Reviewed-by: Oded Gabbay
And applied to my 3.19-next-wip tree
Oded
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index 64c73ba..c5dd0ae 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -236,7 +236,7 @@ static long kfd_ioctl_create_queue(struct file *filep,
> struct kfd_process *p,
> mutex_lock(&p->mutex);
>
> pdd = kfd_bind_process_to_device(dev, p);
> - if (IS_ERR(pdd) < 0) {
> + if (IS_ERR(pdd)) {
> err = PTR_ERR(pdd);
> goto err_bind_process;
> }
> @@ -381,7 +381,7 @@ static long kfd_ioctl_set_memory_policy(struct file
> *filep,
> mutex_lock(&p->mutex);
>
> pdd = kfd_bind_process_to_device(dev, p);
> - if (IS_ERR(pdd) < 0) {
> + if (IS_ERR(pdd)) {
> err = PTR_ERR(pdd);
> goto out;
> }
>
[PATCH 2/2] drm/atomic: add plane iterator macros
On Fri, Nov 21, 2014 at 09:42:25PM +0100, Thierry Reding wrote: > On Fri, Nov 21, 2014 at 09:38:40PM +0100, Daniel Vetter wrote: > > On Fri, Nov 21, 2014 at 03:28:32PM -0500, Rob Clark wrote: > > > +#define drm_crtc_for_each_plane(plane, crtc) \ > > > + list_for_each_entry((plane), &(crtc)->dev->mode_config.plane_list, > > > head) \ > > > + if ((crtc)->state->plane_mask & (1 << drm_plane_index(plane))) > > > > Implement this as drm_crtc_for_each_pending_plane(plane, (crtc)->state)? > > Which means _pending is a strange name ... > > Yeah, I think the drm_crtc_for_each_pending_plane() could be > drm_crtc_state_for_each_plane(), then your suggestion makes perfect > sense. I like Thierry's naming here. Rob can you apply that please? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[GIT PULL] exynos-drm-next
Hi Dave, Add Exynos4415 SoC support, some fixups and cleanups. Summary: - Resolve kernel lockup issue incurred by probe request in probe context. . For this, it moves all register codes of sub drivers into init function and adds component binding support for vidi driver. - Add Exynos4415 SoC support. - Make each manager and display object to be embedded in each driver context. - Fix and clean up FIMD and MIPI-DSI drivers. - Clean up unnecesary or wrong descriptions. - And trivial cleanups. Please kindly let me know if there is my missing point. Thanks, Inki Dae The following changes since commit ed1e8777a56f3523712506d608a29f57ed37b613: Merge branch 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux into drm-next (2014-11-21 12:17:43 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-next for you to fetch changes up to 5baf5d44fbcde002d7f3f8148e69305f520770dd: drm/exynos: avoid leak if exynos_dpi_probe() fails (2014-11-25 11:58:43 +0900) Andrzej Hajda (19): drm/exynos: remove ifdeferry from initialization code drm/exynos: dsi: remove global variable exynos_dsi_display drm/exynos: dsi: simplify device pointer evaluation drm/exynos: dsi: remove redundant encoder field drm/exynos: dsi: stop using display->ctx pointer drm/exynos/mixer: embed manager into private context drm/exynos/mixer: stop using manager->ctx pointer drm/exynos/vidi: embed manager into private context drm/exynos/vidi: stop using manager->ctx pointer drm/exynos/fimd: embed manager into private context drm/exynos/fimd: stop using manager->ctx pointer drm/exynos/hdmi: embed display into private context drm/exynos/hdmi: stop using display->ctx pointer drm/exynos/vidi: embed display into private context drm/exynos/vidi: stop using display->ctx pointer drm/exynos/dp: embed display into private context drm/exynos/dp: stop using display->ctx pointer drm/exynos/dpi: embed display into private context drm/exynos/dpi: stop using display->ctx pointer Gustavo Padovan (13): drm/exynos: remove uneeded declaration of struct dma_iommu_mapping drm/exynos: remove extra declaration of struct exynos_drm_manager drm/exynos: remove extra declaration of struct exynos_overlay drm/exynos: Replace repeated declaration by include drm/exynos: Replace repeated declarations by #include "exynos_drm_drv.h" drm/exynos: remove unused wait_for macro drm/exynos: Save up space using bool var as bitfields drm/exynos: update documentation to reflect code changes drm/exynos: remove leftover hdmi function declarations Revert "drm/exynos: fix null pointer dereference issue" drm/exynos: move Exynos platform drivers registration to init drm/exynos: Fix exynos_dpi_remove() parameter drm/exynos: avoid leak if exynos_dpi_probe() fails Inki Dae (8): drm/exynos: resolve infinite loop issue on multi-platform drm/exynos: resolve infinite loop issue on non multi-platform drm/exynos: g2d: fix null pointer dereference drm/exynos: fix possible infinite loop issue drm/exynos: fix null pointer dereference issue drm/exynos: clean up machine compatible string check drm/exynos: fix exynos_drm_component_del drm/exynos: vidi: add component support Joonyoung Shim (3): drm/exynos: add has_vtsel flag drm/exynos: move triggering checking drm/exynos: use irq_flags instead of triggering Julia Lawall (1): drm/exynos/ipp: fix error return code Krzysztof Kozlowski (1): drm/exynos: Fix DSI resuming fail because power domain being off Vivek Gautam (1): drm/exynos: dp: Remove support for unused dptx-phy YoungJun Cho (12): drm/exynos: dsi: support Exynos4415 SoC drm/exynos: fimd: support Exynos4415 SoC drm/exynos: fimd: remove unnecessary waiting vblank routine drm/exynos: fimd: move handle vblank position in TE handler drm/exynos: dsi: move DSIM_STATE_ENABLED set position drm/exynos: fimd: move shadow unprotection position drm/exynos: fimd: add fimd_enable_video_output() to cleanup drm/exynos: fimd: add fimd_enable_shadow_channel_path() to cleanup drm/exynos: fimd: modify I80 i/f irq relevant routine drm/exynos: fimd: add triggering unset routine in fimd_trigger() drm/exynos: dsi: move TE irq handler registration position drm/exynos: dsi: set TE GPIO IRQ status as IRQ_NOAUTOEN .../devicetree/bindings/video/exynos_dsim.txt |1 + .../devicetree/bindings/video/samsung-fimd.txt |1 + drivers/gpu/drm/exynos/exynos_dp_core.c| 132 -- drivers/gpu/drm/exynos/exynos_dp_core.h|5 +- drivers/gpu/drm/exynos/exynos_
[RFC PATCH] drm/exynos: Add DECON driver
On 2014ë 11ì 25ì¼ 21:17, Ajay kumar wrote: > ping. > You'd need to clean up clocks and fix up binding file. And then let's have review in more details. I wish that other people also give you their reviews. Anyway, below is my answer. Thanks, Inki Dae > On Tue, Nov 11, 2014 at 10:08 PM, Ajay kumar wrote: >> Hi Inki, >> >> On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae wrote: >>> >>> Hi, >>> >>> Fortunately, I could get the user manual for Exynos7420. Below are my >>> comments. >>> >>> Thanks, >>> Inki Dae >>> >>> On 2014ë 10ì 23ì¼ 01:34, Ajay kumar wrote: On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae wrote: > > Thanks for contribution. > > It seems reasonable that you separate device drivers into FIMD and DECON > because many registers of them have many different offsets and fields. > However, there may be a good solution that we can combine common sets of > these drivers later. Yes, this is the main reason behind sending this as RFC patch. I want to know what's the best way to do this. FIMD, 5433 DECON and Exynos7 DECON - all are different. Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). So, even I am not sure how the driver layouts should be! >>> >>> Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my >>> understanding, Exynos7 doesn't mean one real SoC. >> We shall use Exynos7 as per the discussion. Just for the time being. >> > Below are my comments. > > Thanks, > Inki Dae > > On 2014ë 10ì 10ì¼ 21:48, Ajay Kumar wrote: >> This series is based on exynos-drm-next branch of Inki Dae's tree at: >> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >> >> DECON(Display and Enhancement Controller) is the new IP >> in exynos7 SOC for generating video signals using pixel data. > > DECON was used since Exynos5430. And is Exynos5433 different from > Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? Yes, Exynos5433 DECON is very much different than Exynos7 DECON. >>> >>> Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead. >> Again, we shall use Exynos7. >> I will see how manual can be arranged. >> >> DECON driver can be used to drive 2 different interfaces on Exynos7: >> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) >> >> The existing FIMD driver code was used as a template to create >> DECON driver. Only DECON-INT is supported as of now, and >> DECON-EXT support will be added later. >> >> Signed-off-by: Akshu Agrawal >> Signed-off-by: Ajay Kumar >> --- >> .../devicetree/bindings/video/exynos-decon.txt | 68 ++ >> drivers/gpu/drm/exynos/Kconfig | 11 +- >> drivers/gpu/drm/exynos/Makefile|1 + >> drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 > >> drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- >> drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + >> include/video/samsung_decon.h | 346 +++ >> 7 files changed, 1537 insertions(+), 3 deletions(-) >> create mode 100644 > Documentation/devicetree/bindings/video/exynos-decon.txt >> create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c >> create mode 100644 include/video/samsung_decon.h >> >> diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt > b/Documentation/devicetree/bindings/video/exynos-decon.txt >> new file mode 100644 >> index 000..e865650 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt >> @@ -0,0 +1,68 @@ >> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) >> + >> +DECON (Display and Enhancement Controller) is the Display Controller > for the >> +Exynos7 series of SoCs which transfers the image data from a video >> memory >> +buffer to an external LCD interface. >> + >> +Required properties: >> +- compatible: value should be "samsung,exynos7-decon"; > > If exynos5433 was just renamed to exynos7 then, it should be one of the > following: > (a) "samsung,exynos5430-decon" for Display and enhancement > controller > IP for Exynos5430 > (b) "samsung,exynos7" for Display and enhancement controller IP > for Exynos7 > > Or, > (a) "samsung,exynos5430-decon" for Display and enhancement > controller > IP for Exynos5430 > > (b) "samsung,exynos5433-decon" for Display and enhancement > controller > IP for Exynos5433 > (c) "samsung,exynos7" for Display and enhancement controller IP > for Exynos7 Eventually, we will end up here. > >> + >> +- reg: physical base address and length of the DECON registers set. >> +
[RFC PATCH] drm/exynos: Add DECON driver
Hi Inki, On Tue, Nov 25, 2014 at 6:30 PM, Inki Dae wrote: > On 2014ë 11ì 25ì¼ 21:17, Ajay kumar wrote: >> ping. >> > > You'd need to clean up clocks and fix up binding file. And then let's > have review in more details. I wish that other people also give you > their reviews. Nice to hear. Earlier, you mentioned that its good if FIMD driver itself is modified to support Exynos7 DECON. So, what is your take now? 1) Should I add it in FIMD driver itself? We may need to add lot of driver_data for that, since offsets are much different. 2) Or, create two seperate register level files for Exynos5 and Exynos7? 3) Or the current way - Entirely different driver > Anyway, below is my answer. > > Thanks, > Inki Dae > > >> On Tue, Nov 11, 2014 at 10:08 PM, Ajay kumar wrote: >>> Hi Inki, >>> >>> On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae wrote: Hi, Fortunately, I could get the user manual for Exynos7420. Below are my comments. Thanks, Inki Dae On 2014ë 10ì 23ì¼ 01:34, Ajay kumar wrote: > On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae wrote: >> >> Thanks for contribution. >> >> It seems reasonable that you separate device drivers into FIMD and DECON >> because many registers of them have many different offsets and fields. >> However, there may be a good solution that we can combine common sets of >> these drivers later. > Yes, this is the main reason behind sending this as RFC patch. > I want to know what's the best way to do this. > FIMD, 5433 DECON and Exynos7 DECON - all are different. > Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). > So, even I am not sure how the driver layouts should be! Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my understanding, Exynos7 doesn't mean one real SoC. >>> We shall use Exynos7 as per the discussion. > > Just for the time being. Ok. >>> > >> Below are my comments. >> >> Thanks, >> Inki Dae >> >> On 2014ë 10ì 10ì¼ 21:48, Ajay Kumar wrote: >>> This series is based on exynos-drm-next branch of Inki Dae's tree at: >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >>> >>> DECON(Display and Enhancement Controller) is the new IP >>> in exynos7 SOC for generating video signals using pixel data. >> >> DECON was used since Exynos5430. And is Exynos5433 different from >> Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? > Yes, Exynos5433 DECON is very much different than Exynos7 DECON. Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead. >>> Again, we shall use Exynos7. >>> > I will see how manual can be arranged. > >>> >>> DECON driver can be used to drive 2 different interfaces on Exynos7: >>> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) >>> >>> The existing FIMD driver code was used as a template to create >>> DECON driver. Only DECON-INT is supported as of now, and >>> DECON-EXT support will be added later. >>> >>> Signed-off-by: Akshu Agrawal >>> Signed-off-by: Ajay Kumar >>> --- >>> .../devicetree/bindings/video/exynos-decon.txt | 68 ++ >>> drivers/gpu/drm/exynos/Kconfig | 11 +- >>> drivers/gpu/drm/exynos/Makefile|1 + >>> drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 >> >>> drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- >>> drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + >>> include/video/samsung_decon.h | 346 +++ >>> 7 files changed, 1537 insertions(+), 3 deletions(-) >>> create mode 100644 >> Documentation/devicetree/bindings/video/exynos-decon.txt >>> create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c >>> create mode 100644 include/video/samsung_decon.h >>> >>> diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt >> b/Documentation/devicetree/bindings/video/exynos-decon.txt >>> new file mode 100644 >>> index 000..e865650 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt >>> @@ -0,0 +1,68 @@ >>> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) >>> + >>> +DECON (Display and Enhancement Controller) is the Display Controller >> for the >>> +Exynos7 series of SoCs which transfers the image data from a video >>> memory >>> +buffer to an external LCD interface. >>> + >>> +Required properties: >>> +- compatible: value should be "samsung,exynos7-decon"; >> >> If exynos5433 was just renamed to exynos7 then, it should be one of the >> following: >> (a) "samsung,exynos5430-decon" for Display and enhancement >> controller >> IP for Exynos5430 >>
[patch] amdkfd: fix an error handling bug in pqm_create_queue()
On 11/25/2014 12:24 PM, Dan Carpenter wrote:
> The call to kernel_queue_uninit(NULL) will trigger a BUG(), and also the
> error code is incorrect.
>
> Fixes: 45102048f77e ('amdkfd: Add process queue manager module')
> Signed-off-by: Dan Carpenter
>
Patch is:
Reviewed-by: Oded Gabbay
And applied to my 3.19-next-wip tree.
Thanks!
Oded
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
> index c7859fc..7ce7a25 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
> @@ -208,7 +208,7 @@ int pqm_create_queue(struct process_queue_manager *pqm,
> case KFD_QUEUE_TYPE_DIQ:
> kq = kernel_queue_init(dev, KFD_QUEUE_TYPE_DIQ);
> if (kq == NULL) {
> - kernel_queue_uninit(kq);
> + retval = -ENOMEM;
> goto err_create_queue;
> }
> kq->queue->properties.queue_id = *qid;
>
[PATCH] amdkfd: Fix memory leak of mqds on dqm fini
The mqds array members are not freed when dqm is uninitialized.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 904eb38..924e90c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -575,11 +575,15 @@ static int initialize_nocpsch(struct device_queue_manager
*dqm)
static void uninitialize_nocpsch(struct device_queue_manager *dqm)
{
+ int i;
+
BUG_ON(!dqm);
BUG_ON(dqm->queue_count > 0 || dqm->processes_count > 0);
kfree(dqm->allocated_queues);
+ for (i = 0 ; i < KFD_MQD_TYPE_MAX ; i++)
+ kfree(dqm->mqds[i]);
mutex_destroy(&dqm->lock);
kfd2kgd->free_mem(dqm->dev->kgd,
(struct kgd_mem *) dqm->pipeline_mem);
--
1.9.1
[RFC PATCH] drm/exynos: Add DECON driver
On 2014ë 11ì 25ì¼ 22:08, Ajay kumar wrote: > Hi Inki, > > On Tue, Nov 25, 2014 at 6:30 PM, Inki Dae wrote: >> On 2014ë 11ì 25ì¼ 21:17, Ajay kumar wrote: >>> ping. >>> >> >> You'd need to clean up clocks and fix up binding file. And then let's >> have review in more details. I wish that other people also give you >> their reviews. > Nice to hear. Earlier, you mentioned that its good if FIMD driver itself > is modified to support Exynos7 DECON. So, what is your take now? > 1) Should I add it in FIMD driver itself? > We may need to add lot of driver_data > for that, since offsets are much different. > 2) Or, create two seperate register level files for Exynos5 and Exynos7? > 3) Or the current way - Entirely different driver This one, 3), for now because they, Exynos4, Exynos543x and Exynos7, are much different each other. So for next version of your patch, you'd need to change the driver name to exynos7-decon or what you want so that each driver can be entirely separated in SoC name somehow. i.e., - exynos_drm_fimd covers Exynos64xx, Exynos3250, all Exynos4 series and Exynos5250 ~ 5422 SoC. - exynos5-decon covers Exynos5430 and Exynos5433 SoC. - exynos7-decon covers Exynos7 and maybe later SoC. After that, let's consider how we can integrate these drivers later. Thanks, Inki Dae > >> Anyway, below is my answer. >> >> Thanks, >> Inki Dae >> >> >>> On Tue, Nov 11, 2014 at 10:08 PM, Ajay kumar wrote: Hi Inki, On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae wrote: > > Hi, > > Fortunately, I could get the user manual for Exynos7420. Below are my > comments. > > Thanks, > Inki Dae > > On 2014ë 10ì 23ì¼ 01:34, Ajay kumar wrote: >> On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae >> wrote: >>> >>> Thanks for contribution. >>> >>> It seems reasonable that you separate device drivers into FIMD and DECON >>> because many registers of them have many different offsets and fields. >>> However, there may be a good solution that we can combine common sets of >>> these drivers later. >> Yes, this is the main reason behind sending this as RFC patch. >> I want to know what's the best way to do this. >> FIMD, 5433 DECON and Exynos7 DECON - all are different. >> Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). >> So, even I am not sure how the driver layouts should be! > > Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my > understanding, Exynos7 doesn't mean one real SoC. We shall use Exynos7 as per the discussion. >> >> Just for the time being. > Ok. > >> >>> Below are my comments. >>> >>> Thanks, >>> Inki Dae >>> >>> On 2014ë 10ì 10ì¼ 21:48, Ajay Kumar wrote: This series is based on exynos-drm-next branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git DECON(Display and Enhancement Controller) is the new IP in exynos7 SOC for generating video signals using pixel data. >>> >>> DECON was used since Exynos5430. And is Exynos5433 different from >>> Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? >> Yes, Exynos5433 DECON is very much different than Exynos7 DECON. > > Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead. Again, we shall use Exynos7. >> I will see how manual can be arranged. >> DECON driver can be used to drive 2 different interfaces on Exynos7: DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) The existing FIMD driver code was used as a template to create DECON driver. Only DECON-INT is supported as of now, and DECON-EXT support will be added later. Signed-off-by: Akshu Agrawal Signed-off-by: Ajay Kumar --- .../devicetree/bindings/video/exynos-decon.txt | 68 ++ drivers/gpu/drm/exynos/Kconfig | 11 +- drivers/gpu/drm/exynos/Makefile|1 + drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 >>> drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + include/video/samsung_decon.h | 346 +++ 7 files changed, 1537 insertions(+), 3 deletions(-) create mode 100644 >>> Documentation/devicetree/bindings/video/exynos-decon.txt create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c create mode 100644 include/video/samsung_decon.h diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt >>> b/Documentation/devicetree/bindings/video/exynos-decon.txt new file mode 100644 index 000..e865650 --- /dev/null
[RFC PATCH] drm/exynos: Add DECON driver
On Tue, Nov 25, 2014 at 6:59 PM, Inki Dae wrote: > On 2014ë 11ì 25ì¼ 22:08, Ajay kumar wrote: >> Hi Inki, >> >> On Tue, Nov 25, 2014 at 6:30 PM, Inki Dae wrote: >>> On 2014ë 11ì 25ì¼ 21:17, Ajay kumar wrote: ping. >>> >>> You'd need to clean up clocks and fix up binding file. And then let's >>> have review in more details. I wish that other people also give you >>> their reviews. >> Nice to hear. Earlier, you mentioned that its good if FIMD driver itself >> is modified to support Exynos7 DECON. So, what is your take now? >> 1) Should I add it in FIMD driver itself? >> We may need to add lot of driver_data >> for that, since offsets are much different. >> 2) Or, create two seperate register level files for Exynos5 and Exynos7? >> 3) Or the current way - Entirely different driver > > This one, 3), for now because they, Exynos4, Exynos543x and Exynos7, > are much different each other. So for next version of your patch, you'd > need to change the driver name to exynos7-decon or what you want so that > each driver can be entirely separated in SoC name somehow. > > i.e., > - exynos_drm_fimd covers Exynos64xx, Exynos3250, all Exynos4 series and > Exynos5250 ~ 5422 SoC. > - exynos5-decon covers Exynos5430 and Exynos5433 SoC. Use exynos543x-decon here. > - exynos7-decon covers Exynos7 and maybe later SoC. Ok. I will use exynos7-decon. By the way, On which branch of exynos-drm tree should I create this patch? Ajay > After that, let's consider how we can integrate these drivers later. > > Thanks, > Inki Dae > >> >>> Anyway, below is my answer. >>> >>> Thanks, >>> Inki Dae >>> >>> On Tue, Nov 11, 2014 at 10:08 PM, Ajay kumar wrote: > Hi Inki, > > On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae wrote: >> >> Hi, >> >> Fortunately, I could get the user manual for Exynos7420. Below are my >> comments. >> >> Thanks, >> Inki Dae >> >> On 2014ë 10ì 23ì¼ 01:34, Ajay kumar wrote: >>> On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae >>> wrote: Thanks for contribution. It seems reasonable that you separate device drivers into FIMD and DECON because many registers of them have many different offsets and fields. However, there may be a good solution that we can combine common sets of these drivers later. >>> Yes, this is the main reason behind sending this as RFC patch. >>> I want to know what's the best way to do this. >>> FIMD, 5433 DECON and Exynos7 DECON - all are different. >>> Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). >>> So, even I am not sure how the driver layouts should be! >> >> Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my >> understanding, Exynos7 doesn't mean one real SoC. > We shall use Exynos7 as per the discussion. >>> >>> Just for the time being. >> Ok. >> > >>> Below are my comments. Thanks, Inki Dae On 2014ë 10ì 10ì¼ 21:48, Ajay Kumar wrote: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > DECON(Display and Enhancement Controller) is the new IP > in exynos7 SOC for generating video signals using pixel data. DECON was used since Exynos5430. And is Exynos5433 different from Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? >>> Yes, Exynos5433 DECON is very much different than Exynos7 DECON. >> >> Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead. > Again, we shall use Exynos7. > >>> I will see how manual can be arranged. >>> > > DECON driver can be used to drive 2 different interfaces on Exynos7: > DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) > > The existing FIMD driver code was used as a template to create > DECON driver. Only DECON-INT is supported as of now, and > DECON-EXT support will be added later. > > Signed-off-by: Akshu Agrawal > Signed-off-by: Ajay Kumar > --- > .../devicetree/bindings/video/exynos-decon.txt | 68 ++ > drivers/gpu/drm/exynos/Kconfig | 11 +- > drivers/gpu/drm/exynos/Makefile|1 + > drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 > drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- > drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + > include/video/samsung_decon.h | 346 +++ > 7 files changed, 1537 insertions(+), 3 deletions(-) > create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt > create mode 100644
[PATCH 1/2] drm/atomic: track bitmask of planes attached to crtc
On Fri, Nov 21, 2014 at 03:28:31PM -0500, Rob Clark wrote:
> Chasing plane->state->crtc of planes that are *not* part of the same
> atomic update is racy, making it incredibly awkward (or impossible) to
> do something simple like iterate over all planes and figure out which
> ones are attached to a crtc.
>
> Solve this by adding a bitmask of currently attached planes in the
> crtc-state.
>
> Note that the transitional helpers do not maintain the plane_mask. But
> they only support the legacy ioctls, which have sufficient brute-force
> locking around plane updates that they can continue to loop over all
> planes to see what is attached to a crtc the old way.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_atomic.c| 25 -
> drivers/gpu/drm/drm_atomic_helper.c | 8
> include/drm/drm_atomic.h| 4 ++--
> include/drm/drm_crtc.h | 14 +++---
> 4 files changed, 37 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d3b4674..8effbba 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -350,7 +350,8 @@ EXPORT_SYMBOL(drm_atomic_get_connector_state);
>
> /**
> * drm_atomic_set_crtc_for_plane - set crtc for plane
> - * @plane_state: atomic state object for the plane
> + * @state: the incoming atomic state
> + * @plane: the plane whose incoming state to update
> * @crtc: crtc to use for the plane
> *
> * Changing the assigned crtc for a plane requires us to grab the lock and
> state
> @@ -363,20 +364,34 @@ EXPORT_SYMBOL(drm_atomic_get_connector_state);
> * sequence must be restarted. All other errors are fatal.
> */
> int
> -drm_atomic_set_crtc_for_plane(struct drm_plane_state *plane_state,
> - struct drm_crtc *crtc)
> +drm_atomic_set_crtc_for_plane(struct drm_atomic_state *state,
> + struct drm_plane *plane, struct drm_crtc *crtc)
> {
> + struct drm_plane_state *plane_state =
> + drm_atomic_get_plane_state(state, plane);
> struct drm_crtc_state *crtc_state;
>
> - if (crtc) {
> + /* acquire outgoing crtc lock, and clear bit in outgoing crtc mask: */
Ok still don't like these comments since at least for the old crtc it's
wrong: We already must both hold the lock and copied the state. So I've
dropped them (kerneldoc already mentions this too).
> + if (plane_state->crtc) {
> crtc_state = drm_atomic_get_crtc_state(plane_state->state,
> -crtc);
> +plane_state->crtc);
> if (IS_ERR(crtc_state))
And changed this to WARN_ON too to make sure this never fails. The pulled
it into my atomic-fixes branch.
-Daniel
> return PTR_ERR(crtc_state);
> +
> + crtc_state->plane_mask &= ~(1 << drm_plane_index(plane));
> }
>
> plane_state->crtc = crtc;
>
> + /* acquire incoming crtc lock, and set bit in incoming crtc mask: */
> + if (crtc) {
> + crtc_state = drm_atomic_get_crtc_state(plane_state->state,
> +crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> + crtc_state->plane_mask |= (1 << drm_plane_index(plane));
> + }
> +
> if (crtc)
> DRM_DEBUG_KMS("Link plane state %p to [CRTC:%d]\n",
> plane_state, crtc->base.id);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a17b8e9..d765d37 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1187,7 +1187,7 @@ retry:
> goto fail;
> }
>
> - ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> + ret = drm_atomic_set_crtc_for_plane(state, plane, crtc);
> if (ret != 0)
> goto fail;
> drm_atomic_set_fb_for_plane(plane_state, fb);
> @@ -1255,7 +1255,7 @@ retry:
> goto fail;
> }
>
> - ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> + ret = drm_atomic_set_crtc_for_plane(state, plane, NULL);
> if (ret != 0)
> goto fail;
> drm_atomic_set_fb_for_plane(plane_state, NULL);
> @@ -1426,7 +1426,7 @@ retry:
> goto fail;
> }
>
> - ret = drm_atomic_set_crtc_for_plane(primary_state, crtc);
> + ret = drm_atomic_set_crtc_for_plane(state, crtc->primary, crtc);
> if (ret != 0)
> goto fail;
> drm_atomic_set_fb_for_plane(primary_state, set->fb);
> @@ -1698,7 +1698,7 @@ retry:
> goto fail;
> }
>
> - ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> + ret = drm_atomic_set_crtc_for_plane(state, plane, crtc);
> if (ret != 0)
> goto fail;
[PATCH] amdkfd: Fix memory leak of mqds on dqm fini
Reviewed-by: Ben Goz
-Original Message-
From: Gabbay, Oded
Sent: Tuesday, November 25, 2014 3:22 PM
To: dri-devel at lists.freedesktop.org
Cc: Goz, Ben
Subject: [PATCH] amdkfd: Fix memory leak of mqds on dqm fini
The mqds array members are not freed when dqm is uninitialized.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 904eb38..924e90c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -575,11 +575,15 @@ static int initialize_nocpsch(struct device_queue_manager
*dqm)
static void uninitialize_nocpsch(struct device_queue_manager *dqm) {
+ int i;
+
BUG_ON(!dqm);
BUG_ON(dqm->queue_count > 0 || dqm->processes_count > 0);
kfree(dqm->allocated_queues);
+ for (i = 0 ; i < KFD_MQD_TYPE_MAX ; i++)
+ kfree(dqm->mqds[i]);
mutex_destroy(&dqm->lock);
kfd2kgd->free_mem(dqm->dev->kgd,
(struct kgd_mem *) dqm->pipeline_mem);
--
1.9.1
[Bug 86591] Clicking popping sound while playing DTS-HD MA / TrueHD video
https://bugs.freedesktop.org/show_bug.cgi?id=86591 --- Comment #2 from Alex Deucher --- Please Attach your xorg log and dmesg output. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/46301a02/attachment.html>
[patch] amdkfd: delete some dead code
This is dead code. We don't need to unbind here, we can just return
directly.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index a17e2dd..b4f49ac 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -348,11 +348,6 @@ struct kfd_process_device
*kfd_bind_process_to_device(struct kfd_dev *dev,
if (err < 0)
return ERR_PTR(err);
- if (err < 0) {
- amd_iommu_unbind_pasid(dev->pdev, p->pasid);
- return ERR_PTR(err);
- }
-
pdd->bound = true;
return pdd;
[PATCH] radeon: acquire BIOS via firmware subsystem if everything else failed
On Sat, Nov 22, 2014 at 2:30 PM, Wilfried Klaebe
wrote:
> At least Apple's MacBook Pro 8,2 booting EFI -> GRUB2 -> Linux (without
> BIOS emulation) seems to have no Radeon BIOS accessible via conventional
> means. Loading one via firmware system previously dumped (with
> "dd if=/dev/mem of=/lib/firmware/radeon/vbios.bin bs=65536 skip=12 count=1")
> when booted with BIOS emulation works. I carry this patch around since
> about 3.8 and never had any problems, not even with several dozen cycles
> of suspend2ram and resume. Also, I tested every new release if this patch
> was still necessary, and it always was.
>
> Thanks to Stefan Dösinger and others at
> https://www.libreoffice.org/bugzilla/show_bug.cgi?id=26891
>
> Signed-off-by: Wilfried Klaebe
NACK. This mac specific and is not something I want to support in radeon.
The vbios image is available via ACPI prior to the OS taking over.
IIRC, Matthew Garret fixed up the bootloader to fetch the vbios image
prior to loading Linux so that it could be accessed after the OS
loaded.
Alex
>
> ---
>
> Note: I'm not subscribed to dri-devel at lists.freedesktop.org, please cc:
> me if replying there.
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 63ccb8f..cf55e0e 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -29,6 +29,7 @@
> #include "radeon_reg.h"
> #include "radeon.h"
> #include "atom.h"
> +#include
>
> #include
> #include
> @@ -74,6 +75,44 @@ static bool igp_read_bios_from_vram(struct radeon_device
> *rdev)
> return true;
> }
>
> +static bool radeon_read_bios_from_firmware(struct radeon_device *rdev)
> +{
> + const uint8_t __iomem *bios;
> + resource_size_t size;
> + const struct firmware *fw = NULL;
> + char *err = NULL;
> +
> + request_firmware(&fw, "radeon/vbios.bin", rdev->dev);
> + if (!fw) {
> + err = "firmware request returned NULL\n";
> + goto out;
> + }
> + size = fw->size;
> + bios = fw->data;
> +
> + if (size == 0 || !bios) {
> + err = "firmware request returned zero sized or NULL data\n";
> + goto out;
> + }
> +
> + if (bios[0] != 0x55 || bios[1] != 0xaa) {
> + err = "wrong signature on firmware\n";
> + goto out;
> + }
> + rdev->bios = kmalloc(size, GFP_KERNEL);
> + if (rdev->bios == NULL) {
> + err = "failed to kmalloc() memory for firmware\n";
> + goto out;
> + }
> + memcpy(rdev->bios, bios, size);
> +out:
> + if (err)
> + DRM_ERROR(err);
> + if (fw)
> + release_firmware(fw);
> + return !err;
> +}
> +
> static bool radeon_read_bios(struct radeon_device *rdev)
> {
> uint8_t __iomem *bios;
> @@ -662,6 +701,8 @@ bool radeon_get_bios(struct radeon_device *rdev)
> r = radeon_read_disabled_bios(rdev);
> if (r == false)
> r = radeon_read_platform_bios(rdev);
> + if (r == false)
> + r = radeon_read_bios_from_firmware(rdev);
> if (r == false || rdev->bios == NULL) {
> DRM_ERROR("Unable to locate a BIOS ROM\n");
> rdev->bios = NULL;
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: acquire BIOS via firmware subsystem if everything else failed
On Tue, Nov 25, 2014 at 12:14:21PM -0500, Alex Deucher wrote: > The vbios image is available via ACPI prior to the OS taking over. > IIRC, Matthew Garret fixed up the bootloader to fetch the vbios image > prior to loading Linux so that it could be accessed after the OS > loaded. EFI rather than ACPI, but yeah. In theory this should work fine if you're using the EFI entry point. I don't know whether the patches for linuxefi were ever accepted by grub upstream - if not, pushing those would make more sense. -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH] drm/exynos/fimd: only finish pageflip if START == START_S
From: Daniel Kurtz
A framebuffer gets committed to FIMD's default window like this:
exynos_drm_crtc_update()
exynos_plane_commit()
fimd_win_commit()
fimd_win_commit() programs BUF_START[0]. At each vblank, FIMD hardware
copies the value from BUF_START to BUF_START_S (BUF_START's shadow
register), starts scanning out from BUF_START_S, and asserts its irq.
This irq is handled by fimd_irq_handler(), which calls
exynos_drm_crtc_finish_pageflip() to free the old buffer that FIMD just
finished scanning out, and potentially commit the next pending flip.
There is a race, however, if fimd_win_commit() programs BUF_START(0)
between the actual vblank irq, and its corresponding fimd_irq_handler().
=> FIMD vblank: BUF_START_S[0] := BUF_START[0], and irq asserted
| => fimd_win_commit(0) writes new BUF_START[0]
|exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
=> fimd_irq_handler()
exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
and unmaps "old" fb
==> but, since BUF_START_S[0] still points to that "old" fb...
==> FIMD iommu fault
This patch ensures that fimd_irq_handler() only calls
exynos_drm_crtc_finish_pageflip() if any previously scheduled flip
has really completed.
This works because exynos_drm_crtc's flip fifo ensures that
fimd_win_commit() is never called more than once per
exynos_drm_crtc_finish_pageflip().
Signed-off-by: Daniel Kurtz
Reviewed-by: Sean Paul
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 26 ++
include/video/samsung_fimd.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e5810d1..afb0586 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -55,6 +55,7 @@
#define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
#define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) * 8)
+#define VIDWx_BUF_START_S(win, buf) (VIDW_BUF_START_S(buf) + (win) * 8)
#define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) + (win) * 8)
#define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
@@ -1039,6 +1040,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
{
struct fimd_context *ctx = (struct fimd_context *)dev_id;
u32 val, clear_bit;
+ u32 start, start_s;
val = readl(ctx->regs + VIDINTCON1);
@@ -1066,6 +1068,30 @@ static irqreturn_t fimd_irq_handler(int irq, void
*dev_id)
}
}
+ /*
+* Ensure finish_pageflip is called iff a pending flip has completed.
+* This works around a race between a page_flip request and the latency
+* between vblank interrupt and this irq_handler:
+* => FIMD vblank: BUF_START_S[0] := BUF_START[0], and asserts irq
+* | => fimd_win_commit(0) writes new BUF_START[0]
+* |exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
+* => fimd_irq_handler()
+* exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
+* and unmaps "old" fb
+* ==> but, since BUF_START_S[0] still points to that "old" fb...
+* ==> FIMD iommu fault
+*/
+ start = readl(ctx->regs + VIDWx_BUF_START(0, 0));
+ start_s = readl(ctx->regs + VIDWx_BUF_START_S(0, 0));
+ if (start == start_s)
+ exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+
+ /* set wait vsync event to zero and wake up queue. */
+ if (atomic_read(&ctx->wait_vsync_event)) {
+ atomic_set(&ctx->wait_vsync_event, 0);
+ wake_up(&ctx->wait_vsync_queue);
+ }
+
out:
return IRQ_HANDLED;
}
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index a20e4a3..f81d081 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -291,6 +291,7 @@
/* Video buffer addresses */
#define VIDW_BUF_START(_buff) (0xA0 + ((_buff) * 8))
+#define VIDW_BUF_START_S(_buff) (0x40A0 + ((_buff) * 8))
#define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
#define VIDW_BUF_END(_buff)(0xD0 + ((_buff) * 8))
#define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
--
1.9.3
[Bug 88911] New: Radeon: Patch "drm/radeon: fix speaker allocation setup" causes kernel lockup
https://bugzilla.kernel.org/show_bug.cgi?id=88911 Bug ID: 88911 Summary: Radeon: Patch "drm/radeon: fix speaker allocation setup" causes kernel lockup Product: Drivers Version: 2.5 Kernel Version: 3.17.3 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: klaus.kusche at computerix.info Regression: No Since 3.17.3, my system (Dell precision M 6700 notebook with AMD Cap Verde graphics) locks up hard as soon as I connect a beamer via HDMI (both when connected to the HDMI output and when connected to the DP output via a DP/HDMI adapter) while X is running or before starting X (console mode only is fine). 3.17.2 worked. With good luck, the system is still alive, but keyboard, display and mouse are locked up, because X hangs. The system shuts down on soft power off, but with 10 seconds delay and the filesystems still mounted: X seems to be unkillable. With bad luck, the fan goes to 100 % and the kernel seems to be dead: Zero disk activity, hard power off is the only way out. The faulty patch is "drm/radeon: fix speaker allocation setup": Applying or reverting this patch only makes the difference. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/2] drm/udl: handle page mapping in dmabuf export.
Fixes dmabuf export failure with -E_NOMEM when the page is not mapped.
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
---
drivers/gpu/drm/udl/udl_dmabuf.c | 7 +--
drivers/gpu/drm/udl/udl_drv.h| 2 ++
drivers/gpu/drm/udl/udl_gem.c| 4 ++--
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_dmabuf.c b/drivers/gpu/drm/udl/udl_dmabuf.c
index 1d85c3a..2425b76 100644
--- a/drivers/gpu/drm/udl/udl_dmabuf.c
+++ b/drivers/gpu/drm/udl/udl_dmabuf.c
@@ -90,8 +90,11 @@ static struct sg_table *udl_map_dma_buf(struct
dma_buf_attachment *attach,
return &udl_attach->sgt;
if (!obj->pages) {
- DRM_ERROR("pages is null.\n");
- return ERR_PTR(-ENOMEM);
+ ret = udl_gem_get_pages(obj);
+ if (ret) {
+ DRM_ERROR("failed to map pages.\n");
+ return ERR_PTR(ret);
+ }
}
page_count = obj->base.size / PAGE_SIZE;
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 1b132d7..80adbac 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -129,6 +129,8 @@ struct dma_buf *udl_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *udl_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
+int udl_gem_get_pages(struct udl_gem_object *obj);
+void udl_gem_put_pages(struct udl_gem_object *obj);
int udl_gem_vmap(struct udl_gem_object *obj);
void udl_gem_vunmap(struct udl_gem_object *obj);
int udl_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index cd3482d..2a0a784 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -127,7 +127,7 @@ int udl_gem_fault(struct vm_area_struct *vma, struct
vm_fault *vmf)
}
}
-static int udl_gem_get_pages(struct udl_gem_object *obj)
+int udl_gem_get_pages(struct udl_gem_object *obj)
{
struct page **pages;
@@ -143,7 +143,7 @@ static int udl_gem_get_pages(struct udl_gem_object *obj)
return 0;
}
-static void udl_gem_put_pages(struct udl_gem_object *obj)
+void udl_gem_put_pages(struct udl_gem_object *obj)
{
if (obj->base.import_attach) {
drm_free_large(obj->pages);
--
2.2.0.rc0.207.ga3a616c
[PATCH 2/2] drm/udl: properly check for error pointers
The drm_prime_pages_to_sg() function never returns NULL pointers, only
error pointers and valid pointers.
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
---
drivers/gpu/drm/udl/udl_dmabuf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_dmabuf.c b/drivers/gpu/drm/udl/udl_dmabuf.c
index 2425b76..ac8a66b 100644
--- a/drivers/gpu/drm/udl/udl_dmabuf.c
+++ b/drivers/gpu/drm/udl/udl_dmabuf.c
@@ -99,9 +99,9 @@ static struct sg_table *udl_map_dma_buf(struct
dma_buf_attachment *attach,
page_count = obj->base.size / PAGE_SIZE;
obj->sg = drm_prime_pages_to_sg(obj->pages, page_count);
- if (!obj->sg) {
- DRM_ERROR("sg is null.\n");
- return ERR_PTR(-ENOMEM);
+ if (IS_ERR(obj->sg)) {
+ DRM_ERROR("failed to allocate sgt.\n");
+ return ERR_CAST(obj->sg);
}
sgt = &udl_attach->sgt;
--
2.2.0.rc0.207.ga3a616c
Switchable graphics and radeon PX runtime
At Fri, 14 Nov 2014 20:39:15 +0100, Takashi Iwai wrote: > > At Fri, 14 Nov 2014 12:29:17 -0500, > Alex Deucher wrote: > > > > On Fri, Nov 14, 2014 at 11:14 AM, Takashi Iwai wrote: > > > At Fri, 14 Nov 2014 10:40:08 -0500, > > > Alex Deucher wrote: > > >> > > >> On Fri, Nov 14, 2014 at 5:09 AM, Takashi Iwai wrote: > > >> > At Fri, 14 Nov 2014 19:33:00 +1000, > > >> > Dave Airlie wrote: > > >> >> > > >> >> On 14 November 2014 18:12, Takashi Iwai wrote: > > >> >> > Hi Alex, > > >> >> > > > >> >> > we've got a few bug reports about the behavior of radeon driver on > > >> >> > machines with Intel+AMD "switchable graphics" (no Muxless). So far, > > >> >> > it seems that the sane only way to make the machine working is to > > >> >> > get > > >> >> > back to the old vgaswitcheroo behavior via radeon.runpm=0. Without > > >> >> > it, radeon GPU gives a spurious output as connected, eventually > > >> >> > crashes GNOME. (Also, from the nature of the switchable graphics, > > >> >> > vgaswitcheroo looks more intuitive to me.) > > >> >> > > >> >> vgaswitcheroo only matters if there is a MUX, the point of it is to > > >> >> drive > > >> >> the MUX. > > >> >> > > >> >> dynamic poweroff makes more sense, switcheroo on/off switch was > > >> >> just a hack. > > >> > > > >> > Well, I find the current form fairly unintuitive, at least, for the > > >> > switchable (not optimus) graphics. > > >> > With dynamic PM, the card is activated on demand. So you may enable > > >> > outputs of both cards at any time, right? > > >> > > > >> > Currently, all outputs from both cards are exposed in Xrandr, > > >> > e.g. LVDS1 DP1, HDMI1, VGA1, LVDS-1-1, HDMI-1-2, DisplayPort-1-2, and > > >> > VGA-1-1. How can user-space know which one should be activated and > > >> > which not, when you can use effectively only a single card? > > >> > > > >> >> > How are such machines supposed to work with the recent system? Is > > >> >> > PX > > >> >> > wrongly detected on them, or something else missing? > > >> >> > > >> >> It sounds like the connector is wrongly detected and that should be > > >> >> what > > >> >> is fixed. > > >> > > > >> > Yeah, that's a problem indeed. In the bug report, both LVDS1 and > > >> > LVDS-1-1 are reported to be connected at the same time while the > > >> > latter doesn't get any real size and position. We didn't trace > > >> > whether this is the culprit of crash of GNOME, but at least, it looks > > >> > fairly weird. > > >> > > > >> > I forgot to give the original bug report: > > >> > http://bugzilla.opensuse.org/show_bug.cgi?id=904417 > > >> > > > >> > and the xrandr output is found at > > >> > http://bugzilla.opensuse.org/show_bug.cgi?id=904417#c18 > > >> > > >> It's not clear to me from the bug report what that problem is. What > > >> exactly is gnome complaining about? > > > > > > It simply crashes by some reason, showing a sad face and complaining > > > something is wrong. (And it's GNOME, not easy to get a proper log > > > like kernel :) > > > Some users complained about blank output, but I'm not sure whether > > > this is the same cause. > > > > > >> The X logs look fine. > > > > > > I couldn't see any errors there, too. So it's just a wild guess, so > > > far... > > > > > >> From the > > >> xrandr output, LVDS1 (connected to the intel) is connected and active. > > >> LVDS-1-1 (connected to the radeon) is connected but not active. That > > >> should be a perfectly reasonable configuration. If LVDS-1-1 is not > > >> active, the radeon kernel driver will power down the GPU until the > > >> user either activates the panel or uses the dGPU as an offscreen > > >> renderer. > > > > > > Note that the xrandr output was taken on icewm or else. So, right, > > > this might be non-issue. But, I guess now that the issue will happen > > > when LVDS-1-1 is activated at the same time with LVDS. GNOME tries to > > > activate all connected outputs at the same time as default. > > > > > >> There are plenty of cases when you may have a secondary GPU with > > >> attached displays that are not active. If gnome barfs on this it > > >> should be fixed in gnome. > > > > > > Yeah, GNOME has definitely a problem about it. At least, it shouldn't > > > crash badly. > > > > > > But, it's still not clear to me how the activation of the radeon GPU > > > is supposed to work in switchable graphics case. For PX or Otpimus, > > > it's clear. But for switchable case, there is no offload rendering. > > > If you enable the output on radeon GPU while Intel output is being > > > used, what's going on? Shouldn't they be handled exclusively, as user > > > expected? > > > > You can still do offload rendering with a switchable system, it just > > happens to also have a mux which you can use or not use. That's how > > it works today. > > > > If you enable the outputs on both gpus, they will both power up the > > display hw on the GPU, but only the signals from the gpu selected by > > the mux will actually make it to the display
[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop
https://bugs.freedesktop.org/show_bug.cgi?id=82055 Kai changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Kai --- Ok, since my bisecting adventures took too long I just built xorg/xserver:master, commit c52a2b1eba. That version doesn't exhibit this problem. I consider this fixed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/da09d31b/attachment.html>
[PATCH] drm: Handle atomic state properly in kms getfoo ioctl
So the problem with async commit (especially async modeset commit) is
that the legacy pointers only get updated after the point of no
return, in the async part of the modeset sequence. At least as
implemented by the current helper functions. This is done in the
set_routing_links function in drm_atomic_helper.c.
Which also means that access isn't protected by locks but only
coordinated by synchronizing with async workers. No problem thus far,
until we lock at the getconnector/encoder ioctls.
So fix this up by adding special cases for atomic drivers: For those
we need to look at state objects. Unfortunately digging out the
correct encoder->crtc link is a bit of work, so wrap this up in a
helper function.
Moving the assignments of connector->encoder and encoder->crtc earlier
isn't a good idea because the point of the atomic helpers is that we
stage the state updates. That way the disable functions can still
inspect the links and rely upon them.
v2: Extract full encoder->crtc lookup into helper (Rob).
v3: Extract drm_connector_get_encoder too since - we need to always
return state->best_encoder when there is a state otherwise we might
return stale data if there's a pending async disable (and chase
unlocked pointers, too). Same issue with encoder_get_crtc but there
it's a bit more tricky to handle.
Cc: Rob Clark
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 49 +++---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 589a921d4313..d51b1c1f6726 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1955,6 +1955,15 @@ static bool drm_mode_expose_to_userspace(const struct
drm_display_mode *mode,
return true;
}
+static struct drm_encoder *drm_connector_get_encoder(struct drm_connector
*connector)
+{
+ /* For atomic drivers only state objects are synchronously updated and
+* protected by modeset locks, so check those first. */
+ if (connector->state)
+ return connector->state->best_encoder;
+ return connector->encoder;
+}
+
/**
* drm_mode_getconnector - get connector configuration
* @dev: drm device for the ioctl
@@ -1973,6 +1982,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
{
struct drm_mode_get_connector *out_resp = data;
struct drm_connector *connector;
+ struct drm_encoder *encoder;
struct drm_display_mode *mode;
int mode_count = 0;
int props_count = 0;
@@ -2028,8 +2038,10 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
out_resp->subpixel = connector->display_info.subpixel_order;
out_resp->connection = connector->status;
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
- if (connector->encoder)
- out_resp->encoder_id = connector->encoder->base.id;
+
+ encoder = drm_connector_get_encoder(connector);
+ if (encoder)
+ out_resp->encoder_id = encoder->base.id;
else
out_resp->encoder_id = 0;
drm_modeset_unlock(&dev->mode_config.connection_mutex);
@@ -2099,6 +2111,33 @@ out:
return ret;
}
+static struct drm_crtc *drm_encoder_get_crtc(struct drm_encoder *encoder)
+{
+ struct drm_connector *connector;
+ struct drm_device *dev = encoder->dev;
+ bool uses_atomic = false;
+
+ /* For atomic drivers only state objects are synchronously updated and
+* protected by modeset locks, so check those first. */
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ if (!connector->state)
+ continue;
+
+ uses_atomic = true;
+
+ if (connector->state->best_encoder != encoder)
+ continue;
+
+ return connector->state->crtc;
+ }
+
+ /* Don't return stale data (e.g. pending async disable). */
+ if (uses_atomic)
+ return NULL;
+
+ return encoder->crtc;
+}
+
/**
* drm_mode_getencoder - get encoder configuration
* @dev: drm device for the ioctl
@@ -2117,6 +2156,7 @@ int drm_mode_getencoder(struct drm_device *dev, void
*data,
{
struct drm_mode_get_encoder *enc_resp = data;
struct drm_encoder *encoder;
+ struct drm_crtc *crtc;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -2126,7 +2166,10 @@ int drm_mode_getencoder(struct drm_device *dev, void
*data,
return -ENOENT;
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
- if (encoder->crtc)
+ crtc = drm_encoder_get_crtc(encoder);
+ if (crtc)
+ enc_resp->crtc_id = crtc->base.id;
+ else if (encoder->crtc)
enc_resp->crtc_id = encoder->crtc->base.id;
else
enc_resp->crtc_id = 0;
--
2.1.1
[PATCH v4 6/9] drm: Decouple EDID parsing from I2C adapter
On Tue, Nov 25, 2014 at 6:47 PM, Laurent Pinchart
wrote:
> From: Lars-Peter Clausen
>
> The drm_get_edid() function performs direct I2C accesses to read EDID
> blocks, assuming that the monitor DDC interface is directly connected to
> the I2C bus. It can't thus be used with HDMI encoders that control the
> DDC bus and expose EDID blocks through a different interface.
>
> Refactor drm_do_get_edid() to take a block read callback function
> instead of an I2C adapter, and export it for direct use by drivers.
>
> As in the general case the DDC bus is accessible by the kernel at the
> I2C level, drivers must make all reasonable efforts to expose it as an
> I2C adapter and use drm_get_edid() instead of abusing this function.
>
> Signed-off-by: Lars-Peter Clausen
> Signed-off-by: Laurent Pinchart
I suppose if tda998x were converted over to use it, it would be a nice
negative diffstat ;-)
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_edid.c | 43 ++-
> include/drm/drm_edid.h | 5 +
> 2 files changed, 35 insertions(+), 13 deletions(-)
>
> Daniel, could you please review and hopefully ack this ? If this new version
> is
> acceptable I'd like to send an updated pull request for R-Car DU HDMI support
> for v3.19, so time is running short.
>
> Changes since v3:
>
> - Add kerneldoc for the new exported drm_do_get_edid function
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3bf999134bcc..1a77a49d2695 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1125,9 +1125,9 @@ EXPORT_SYMBOL(drm_edid_is_valid);
> * Return: 0 on success or -1 on failure.
> */
> static int
> -drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf,
> - int block, int len)
> +drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int block, size_t len)
> {
> + struct i2c_adapter *adapter = data;
> unsigned char start = block * EDID_LENGTH;
> unsigned char segment = block >> 1;
> unsigned char xfers = segment ? 3 : 2;
> @@ -1184,8 +1184,26 @@ static bool drm_edid_is_zero(u8 *in_edid, int length)
> return true;
> }
>
> -static u8 *
> -drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
> +/**
> + * drm_do_get_edid - get EDID data using a custom EDID block read function
> + * @connector: connector we're probing
> + * @get_edid_block: EDID block read function
> + * @data: private data passed to the block read function
> + *
> + * When the I2C adapter connected to the DDC bus is hidden behind a device
> that
> + * exposes a different interface to read EDID blocks this function can be
> used
> + * to get EDID data using a custom block read function.
> + *
> + * As in the general case the DDC bus is accessible by the kernel at the I2C
> + * level, drivers must make all reasonable efforts to expose it as an I2C
> + * adapter and use drm_get_edid() instead of abusing this function.
> + *
> + * Return: Pointer to valid EDID or NULL if we couldn't find any.
> + */
> +struct edid *drm_do_get_edid(struct drm_connector *connector,
> + int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
> + size_t len),
> + void *data)
> {
> int i, j = 0, valid_extensions = 0;
> u8 *block, *new;
> @@ -1196,7 +1214,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
> i2c_adapter *adapter)
>
> /* base block fetch */
> for (i = 0; i < 4; i++) {
> - if (drm_do_probe_ddc_edid(adapter, block, 0, EDID_LENGTH))
> + if (get_edid_block(data, block, 0, EDID_LENGTH))
> goto out;
> if (drm_edid_block_valid(block, 0, print_bad_edid))
> break;
> @@ -1210,7 +1228,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
> i2c_adapter *adapter)
>
> /* if there's no extensions, we're done */
> if (block[0x7e] == 0)
> - return block;
> + return (struct edid *)block;
>
> new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
> if (!new)
> @@ -1219,7 +1237,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
> i2c_adapter *adapter)
>
> for (j = 1; j <= block[0x7e]; j++) {
> for (i = 0; i < 4; i++) {
> - if (drm_do_probe_ddc_edid(adapter,
> + if (get_edid_block(data,
> block + (valid_extensions + 1) *
> EDID_LENGTH,
> j, EDID_LENGTH))
> goto out;
> @@ -1247,7 +1265,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
> i2c_adapter *adapter)
> block = new;
> }
>
> - return block;
> + return (struct edid *)block;
>
> carp:
> if (print_bad_edid) {
> @@ -1260,6 +1278,7 @@ out:
> kfr
[PATCH 0/3] atomic plane iterators
Resend the series.. I think danvet has first one queued up on topic/core-stuff, second one updated from bikeshedding, adding the third which converts over msm to use the new iterator macros (now that mdp5 atomic stuff is on drm-next) Rob Clark (3): drm/atomic: track bitmask of planes attached to crtc drm/atomic: add plane iterator macros drm/msm: switch to atomic-helpers iterator macros Documentation/DocBook/drm.tmpl | 1 + drivers/gpu/drm/drm_atomic.c | 23 ++- drivers/gpu/drm/drm_atomic_helper.c | 8 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 +++--- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 9 + drivers/gpu/drm/msm/msm_kms.h| 23 --- include/drm/drm_atomic.h | 4 ++-- include/drm/drm_atomic_helper.h | 28 include/drm/drm_crtc.h | 14 +++--- 9 files changed, 72 insertions(+), 44 deletions(-) -- 1.9.3
[PATCH 1/3] drm/atomic: track bitmask of planes attached to crtc
Chasing plane->state->crtc of planes that are *not* part of the same
atomic update is racy, making it incredibly awkward (or impossible) to
do something simple like iterate over all planes and figure out which
ones are attached to a crtc.
Solve this by adding a bitmask of currently attached planes in the
crtc-state.
Note that the transitional helpers do not maintain the plane_mask. But
they only support the legacy ioctls, which have sufficient brute-force
locking around plane updates that they can continue to loop over all
planes to see what is attached to a crtc the old way.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic.c| 23 ++-
drivers/gpu/drm/drm_atomic_helper.c | 8
include/drm/drm_atomic.h| 4 ++--
include/drm/drm_crtc.h | 14 +++---
4 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d3b4674..cfc2500 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -350,7 +350,8 @@ EXPORT_SYMBOL(drm_atomic_get_connector_state);
/**
* drm_atomic_set_crtc_for_plane - set crtc for plane
- * @plane_state: atomic state object for the plane
+ * @state: the incoming atomic state
+ * @plane: the plane whose incoming state to update
* @crtc: crtc to use for the plane
*
* Changing the assigned crtc for a plane requires us to grab the lock and
state
@@ -363,20 +364,32 @@ EXPORT_SYMBOL(drm_atomic_get_connector_state);
* sequence must be restarted. All other errors are fatal.
*/
int
-drm_atomic_set_crtc_for_plane(struct drm_plane_state *plane_state,
- struct drm_crtc *crtc)
+drm_atomic_set_crtc_for_plane(struct drm_atomic_state *state,
+ struct drm_plane *plane, struct drm_crtc *crtc)
{
+ struct drm_plane_state *plane_state =
+ drm_atomic_get_plane_state(state, plane);
struct drm_crtc_state *crtc_state;
+ if (plane_state->crtc) {
+ crtc_state = drm_atomic_get_crtc_state(plane_state->state,
+ plane_state->crtc);
+ if (WARN_ON(IS_ERR(crtc_state)))
+ return PTR_ERR(crtc_state);
+
+ crtc_state->plane_mask &= ~(1 << drm_plane_index(plane));
+ }
+
+ plane_state->crtc = crtc;
+
if (crtc) {
crtc_state = drm_atomic_get_crtc_state(plane_state->state,
crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
+ crtc_state->plane_mask |= (1 << drm_plane_index(plane));
}
- plane_state->crtc = crtc;
-
if (crtc)
DRM_DEBUG_KMS("Link plane state %p to [CRTC:%d]\n",
plane_state, crtc->base.id);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a17b8e9..d765d37 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1187,7 +1187,7 @@ retry:
goto fail;
}
- ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
+ ret = drm_atomic_set_crtc_for_plane(state, plane, crtc);
if (ret != 0)
goto fail;
drm_atomic_set_fb_for_plane(plane_state, fb);
@@ -1255,7 +1255,7 @@ retry:
goto fail;
}
- ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+ ret = drm_atomic_set_crtc_for_plane(state, plane, NULL);
if (ret != 0)
goto fail;
drm_atomic_set_fb_for_plane(plane_state, NULL);
@@ -1426,7 +1426,7 @@ retry:
goto fail;
}
- ret = drm_atomic_set_crtc_for_plane(primary_state, crtc);
+ ret = drm_atomic_set_crtc_for_plane(state, crtc->primary, crtc);
if (ret != 0)
goto fail;
drm_atomic_set_fb_for_plane(primary_state, set->fb);
@@ -1698,7 +1698,7 @@ retry:
goto fail;
}
- ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
+ ret = drm_atomic_set_crtc_for_plane(state, plane, crtc);
if (ret != 0)
goto fail;
drm_atomic_set_fb_for_plane(plane_state, fb);
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 9d91916..6ff8775 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -44,8 +44,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state *state,
struct drm_connector *connector);
int __must_check
-drm_atomic_set_crtc_for_plane(struct drm_plane_state *plane_state,
- struct drm_crtc *crtc);
+drm_atomic_set_crtc_for_plane(struct drm_atomic_state *state,
+ struct drm_plane *plane, struct drm_crtc *crtc);
void drm_atomic_set_fb_for_plane(struct drm_plane_stat
[PATCH 2/3] drm/atomic: add plane iterator macros
Add helper macros to iterate the current, or incoming set of planes attached to a crtc. These helpers are only available for drivers converted to use atomic-helpers. Signed-off-by: Rob Clark --- Documentation/DocBook/drm.tmpl | 1 + include/drm/drm_atomic_helper.h | 28 2 files changed, 29 insertions(+) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 8c54f9a..3789f2d 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2343,6 +2343,7 @@ void intel_crt_init(struct drm_device *dev) Atomic State Reset and Initialization !Pdrivers/gpu/drm/drm_atomic_helper.c atomic state reset and initialization +!Iinclude/drm/drm_atomic_helper.h !Edrivers/gpu/drm/drm_atomic_helper.c diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h index 64b4e91..c8aa6b4 100644 --- a/include/drm/drm_atomic_helper.h +++ b/include/drm/drm_atomic_helper.h @@ -96,5 +96,33 @@ drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector); void drm_atomic_helper_connector_destroy_state(struct drm_connector *connector, struct drm_connector_state *state); +#define __drm_for_each_plane_mask(plane, dev, plane_mask) \ + list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \ + if ((plane_mask) & (1 << drm_plane_index(plane))) + +/** + * drm_atomic_crtc_for_each_plane - iterate over planes currently attached to CRTC + * @plane: the loop cursor + * @crtc: the crtc whose planes are iterated + * + * This iterates over the current state, useful (for example) when applying + * atomic state after it has been checked and swapped. To iterate over the + * planes which *will* be attached (for ->atomic_check()) see + * drm_crtc_for_each_pending_plane() + */ +#define drm_atomic_crtc_for_each_plane(plane, crtc) \ + __drm_for_each_plane_mask(plane, (crtc)->dev, (crtc)->state->plane_mask) + +/** + * drm_crtc_atomic_state_for_each_plane - iterate over attached planes in new state + * @plane: the loop cursor + * @crtc_state: the incoming crtc-state + * + * Similar to drm_crtc_for_each_plane(), but iterates the planes that will be + * attached if the specified state is applied. Useful during (for example) + * ->atomic_check() operations, to validate the incoming state + */ +#define drm_atomic_crtc_state_for_each_plane(plane, crtc_state) \ + __drm_for_each_plane_mask(plane, (crtc_state)->state->dev, (crtc_state)->plane_mask) #endif /* DRM_ATOMIC_HELPER_H_ */ -- 1.9.3
[PATCH 3/3] drm/msm: switch to atomic-helpers iterator macros
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 +++---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 9 +
drivers/gpu/drm/msm/msm_kms.h| 23 ---
3 files changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
index 6781aa9..a7672e1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
@@ -84,7 +84,7 @@ static void crtc_flush(struct drm_crtc *crtc)
struct drm_plane *plane;
uint32_t flush = 0;
- for_each_plane_on_crtc(crtc, plane) {
+ drm_atomic_crtc_for_each_plane(plane, crtc) {
enum mdp4_pipe pipe_id = mdp4_plane_pipe(plane);
flush |= pipe2flush(pipe_id);
}
@@ -197,7 +197,7 @@ static void setup_mixer(struct mdp4_kms *mdp4_kms)
struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
struct drm_plane *plane;
- for_each_plane_on_crtc(crtc, plane) {
+ drm_atomic_crtc_for_each_plane(plane, crtc) {
enum mdp4_pipe pipe_id = mdp4_plane_pipe(plane);
int idx = idxs[pipe_id];
mixer_cfg = mixercfg(mixer_cfg, mdp4_crtc->mixer,
@@ -221,7 +221,7 @@ static void blend_setup(struct drm_crtc *crtc)
mdp4_write(mdp4_kms, REG_MDP4_OVLP_TRANSP_HIGH0(ovlp), 0);
mdp4_write(mdp4_kms, REG_MDP4_OVLP_TRANSP_HIGH1(ovlp), 0);
- for_each_plane_on_crtc(crtc, plane) {
+ drm_atomic_crtc_for_each_plane(plane, crtc) {
enum mdp4_pipe pipe_id = mdp4_plane_pipe(plane);
int idx = idxs[pipe_id];
if (idx > 0) {
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 0598bde..0e9a2e3 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -91,7 +91,7 @@ static void crtc_flush_all(struct drm_crtc *crtc)
if (!mdp5_crtc->ctl)
return;
- for_each_plane_on_crtc(crtc, plane) {
+ drm_atomic_crtc_for_each_plane(plane, crtc) {
flush_mask |= mdp5_plane_get_flush(plane);
}
flush_mask |= mdp5_ctl_get_flush(mdp5_crtc->ctl);
@@ -124,8 +124,9 @@ static void complete_flip(struct drm_crtc *crtc, struct
drm_file *file)
}
spin_unlock_irqrestore(&dev->event_lock, flags);
- for_each_plane_on_crtc(crtc, plane)
+ drm_atomic_crtc_for_each_plane(plane, crtc) {
mdp5_plane_complete_flip(plane);
+ }
}
static void mdp5_crtc_destroy(struct drm_crtc *crtc)
@@ -195,7 +196,7 @@ static void blend_setup(struct drm_crtc *crtc)
if (!mdp5_crtc->ctl)
goto out;
- for_each_plane_on_crtc(crtc, plane) {
+ drm_atomic_crtc_for_each_plane(plane, crtc) {
enum mdp_mixer_stage_id stage =
to_mdp5_plane_state(plane->state)->stage;
@@ -317,7 +318,7 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
/* verify that there are not too many planes attached to crtc
* and that we don't have conflicting mixer stages:
*/
- for_each_pending_plane_on_crtc(state->state, crtc, plane) {
+ drm_atomic_crtc_state_for_each_plane(plane, state) {
struct drm_plane_state *pstate;
if (cnt >= ARRAY_SIZE(pstates)) {
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 7fb4876..0643774 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -65,27 +65,4 @@ static inline void msm_kms_init(struct msm_kms *kms,
struct msm_kms *mdp4_kms_init(struct drm_device *dev);
struct msm_kms *mdp5_kms_init(struct drm_device *dev);
-/* TODO move these helper iterator macro somewhere common: */
-#define for_each_plane_on_crtc(_crtc, _plane) \
- list_for_each_entry((_plane), &(_crtc)->dev->mode_config.plane_list,
head) \
- if ((_plane)->state->crtc == (_crtc))
-
-static inline bool
-__plane_will_be_attached_to_crtc(struct drm_atomic_state *state,
- struct drm_plane *plane, struct drm_crtc *crtc)
-{
- int idx = drm_plane_index(plane);
-
- /* if plane is modified in incoming state, use the new state: */
- if (state->plane_states[idx])
- return state->plane_states[idx]->crtc == crtc;
-
- /* otherwise, current state: */
- return plane->state->crtc == crtc;
-}
-
-#define for_each_pending_plane_on_crtc(_state, _crtc, _plane) \
- list_for_each_entry((_plane), &(_crtc)->dev->mode_config.plane_list,
head) \
- if (__plane_will_be_attached_to_crtc((_state), (_plane),
(_crtc)))
-
#endif /* __MSM_KMS_H__ */
--
1.9.3
[PATCH 0/2] small OCD cleanups
A couple small OCD cleanups I noticed, which my other work-in-progress propertification/atomic-ioctl patches are on top of. No dependency on any atomic stuff, so might as well hit 'send'. Rob Clark (2): drm: fix indentation drm: use mode_object_find helpers drivers/gpu/drm/drm_crtc.c | 13 - include/drm/drmP.h | 2 +- 2 files changed, 5 insertions(+), 10 deletions(-) -- 1.9.3
[PATCH 1/2] drm: fix indentation
Signed-off-by: Rob Clark
---
include/drm/drmP.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index be776fb..8ba35c6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -809,7 +809,7 @@ struct drm_device {
struct drm_local_map *agp_buffer_map;
unsigned int agp_buffer_token;
-struct drm_mode_config mode_config;/**< Current mode config */
+ struct drm_mode_config mode_config; /**< Current mode config */
/** \name GEM information */
/*@{ */
--
1.9.3
[PATCH 2/2] drm: use mode_object_find helpers
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 589a921..9972cc8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2392,7 +2392,6 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_mode_set_plane *plane_req = data;
- struct drm_mode_object *obj;
struct drm_plane *plane;
struct drm_crtc *crtc = NULL;
struct drm_framebuffer *fb = NULL;
@@ -2415,14 +2414,12 @@ int drm_mode_setplane(struct drm_device *dev, void
*data,
* First, find the plane, crtc, and fb objects. If not available,
* we don't bother to call the driver.
*/
- obj = drm_mode_object_find(dev, plane_req->plane_id,
- DRM_MODE_OBJECT_PLANE);
- if (!obj) {
+ plane = drm_plane_find(dev, plane_req->plane_id);
+ if (!plane) {
DRM_DEBUG_KMS("Unknown plane ID %d\n",
plane_req->plane_id);
return -ENOENT;
}
- plane = obj_to_plane(obj);
if (plane_req->fb_id) {
fb = drm_framebuffer_lookup(dev, plane_req->fb_id);
@@ -2432,14 +2429,12 @@ int drm_mode_setplane(struct drm_device *dev, void
*data,
return -ENOENT;
}
- obj = drm_mode_object_find(dev, plane_req->crtc_id,
- DRM_MODE_OBJECT_CRTC);
- if (!obj) {
+ crtc = drm_crtc_find(dev, plane_req->crtc_id);
+ if (!crtc) {
DRM_DEBUG_KMS("Unknown crtc ID %d\n",
plane_req->crtc_id);
return -ENOENT;
}
- crtc = obj_to_crtc(obj);
}
/*
--
1.9.3
[PATCH 1/1] GPU-DRM-MSM: Deletion of unnecessary checks before two function calls
From: Markus Elfring
Date: Tue, 25 Nov 2014 14:30:28 +0100
The functions framebuffer_release() and vunmap() perform also input
parameter validation. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/msm/msm_fbdev.c | 3 +--
drivers/gpu/drm/msm/msm_gem.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index ab5bfd2..fd5a6f3 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -193,8 +193,7 @@ fail_unlock:
fail:
if (ret) {
- if (fbi)
- framebuffer_release(fbi);
+ framebuffer_release(fbi);
if (fb) {
drm_framebuffer_unregister_private(fb);
drm_framebuffer_remove(fb);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 4b1b82a..157cf21 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -543,8 +543,7 @@ void msm_gem_free_object(struct drm_gem_object *obj)
drm_free_large(msm_obj->pages);
} else {
- if (msm_obj->vaddr)
- vunmap(msm_obj->vaddr);
+ vunmap(msm_obj->vaddr);
put_pages(obj);
}
--
2.1.3
[PATCH 1/1] GPU-DRM-MSM-Adreno: Deletion of unnecessary checks before the function call "release_firmware"
From: Markus Elfring Date: Tue, 25 Nov 2014 13:44:20 +0100 The release_firmware() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c index 655ce5b..757052c 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c @@ -404,9 +404,7 @@ void adreno_gpu_cleanup(struct adreno_gpu *gpu) msm_gem_put_iova(gpu->memptrs_bo, gpu->base.id); drm_gem_object_unreference(gpu->memptrs_bo); } - if (gpu->pm4) - release_firmware(gpu->pm4); - if (gpu->pfp) - release_firmware(gpu->pfp); + release_firmware(gpu->pm4); + release_firmware(gpu->pfp); msm_gpu_cleanup(&gpu->base); } -- 2.1.3
[PATCH v14 0/3] Add drm driver for Rockchip Socs
Mark, Am Donnerstag, 20. November 2014, 09:46:34 schrieb Mark Yao: > This a series of patches is a DRM Driver for Rockchip Socs, add support > for vop devices. Future patches will add additional encoders/connectors, > such as eDP, HDMI. > > The basic "crtc" for rockchip is a "VOP" - Video Output Processor. > the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar > Vop devices. Vop devices support iommu mapping, we use dma-mapping API with > ARM_DMA_USE_IOMMU. it looks like everybody is more or less happy with this version - in past versions responses voicing concerns where quite swift. As David requested a pull request the last time, it might be time to do so, so that we maybe still reach 3.19. Heiko
[PATCH 1/2] drm/dp: retry AUX transactions 32 times
On Wed, Nov 26, 2014 at 01:17:22PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> At least on two MST devices I've tested with, when
> they are link training downstream, they are totally
> unable to handle aux ch msgs, so they defer like nuts.
> I tried 16, it wasn't enough, 32 seems better.
>
> This fixes one Dell 4k monitor and one of the
> MST hubs.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 959e207..db0993f 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -189,7 +189,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
>* retry native transactions, so retry 7 times like for I2C-over-AUX
Should this comment be updated too?
-Tom
>* transactions.
>*/
> - for (retry = 0; retry < 7; retry++) {
> + for (retry = 0; retry < 32; retry++) {
>
> mutex_lock(&aux->hw_mutex);
> err = aux->transfer(aux, &msg);
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
