[Bug 93879] kernel 4.4.0 causes application lockup and unusable interfaces with radeon hardware
https://bugs.freedesktop.org/show_bug.cgi?id=93879 Bug ID: 93879 Summary: kernel 4.4.0 causes application lockup and unusable interfaces with radeon hardware Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: jimmy at boombatower.com Created attachment 121320 --> https://bugs.freedesktop.org/attachment.cgi?id=121320&action=edit sh -c "cat /proc/version; ./scripts/ver_linux; cat /proc/cpuinfo; cat /proc/modules; cat /proc/ioports; cat /proc/iomem; lspci -vvv; cat /proc/scsi/scsi" > env_info While running Plasma 5 on 4.4.0 the following occurs periodically: - chromium locks up - plasma desktop locks up - unable to enter password on plasma lock screen A trigger for locking chromium up seems to be to resize the window by dragging to screen edges (top to fullscreen, left to tack up left half of screen, etc). Otherwise, it also seems to somewhat randomly freeze over time. Reverting to 4.3.x resolves the issues. Environment --- Distro: openSUSE Tumbleweed (20160121) (x86_64) Kernel version: 4.4.0-1.2 (works on <= 4.3.3-6) OpenGL renderer string: Gallium 0.4 on AMD TAHITI (DRM 2.43.0, LLVM 3.7.0) OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.1.0 Xorg version: 7.6_1.18.0-5.2 xf86-video-ati version: 7.6.1-1.2 DRI3 enabled Hardware: Radeon HD 7970 ghz output from kernel bug reporting guide attached -- 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/20160127/57dd02f4/attachment.html>
[Bug 93879] kernel 4.4.0 causes application lockup and unusable interfaces with radeon hardware
https://bugs.freedesktop.org/show_bug.cgi?id=93879 --- Comment #1 from Michel D�nzer --- Sounds like it could be the problem discussed in http://lists.freedesktop.org/archives/dri-devel/2016-January/098821.html . -- 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/20160127/71ecf89f/attachment.html>
[Bug 93879] kernel 4.4.0 causes application lockup and unusable interfaces with radeon hardware
https://bugs.freedesktop.org/show_bug.cgi?id=93879 --- Comment #2 from boombatower --- Come to think of it, I did experience that one day but never again. -- 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/20160127/086ad861/attachment.html>
[Bug 93879] kernel 4.4.0 causes application lockup and unusable interfaces with radeon hardware
https://bugs.freedesktop.org/show_bug.cgi?id=93879 --- Comment #3 from Franklin Titus --- I am having similar issue on AMD HD 7870 GPU, openSUSE Tumbleweed, and Kernel 4.4.0-1.2. I cannot say for sure the trigger, however, once the screen locks requiring a password, the password field becomes disabled although mouse and keyboard remain fully functional. In fact, it would seem the entire lock screen becomes unresponsive to both mouse and keyboard, and CTRL+ALT+Backspace needs to be employed in order to restart the session. -- 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/20160127/627cc414/attachment-0001.html>
[PATCH v4 4/6] drm/dsi: Check for used channels
On 01/21/2016 09:41 PM, Thierry Reding wrote: > On Thu, Dec 10, 2015 at 06:11:38PM +0530, Archit Taneja wrote: >> We don't check whether a previously registered mipi_dsi_device under the >> same host shares the same virtual channel. >> >> Before registering, check if any of the registered devices doesn't >> already have the same virtual channel. >> >> This wasn't crucial when all the devices under a host were populated via >> DT. Now that we also support creating devices manually, we could end up >> in a situation where a driver tries to create a device with a virtual >> channel already taken by a device populated in DT. >> >> Reviewed-by: Andrzej Hajda >> Signed-off-by: Archit Taneja >> --- >> drivers/gpu/drm/drm_mipi_dsi.c | 26 -- >> 1 file changed, 24 insertions(+), 2 deletions(-) > > I don't think this is necessary. The device name will be composed of the > host's name, a '.' and the virtual channel ID, and the device core will > refuse to create two devices with the same name. That's a good point. I'll drop this patch. Archit > > Thierry > -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v4 5/6] drm/dsi: Add routine to unregister dsi device
On 01/21/2016 09:42 PM, Thierry Reding wrote:
> On Thu, Dec 10, 2015 at 06:11:39PM +0530, Archit Taneja wrote:
>> A driver calling mipi_dsi_device_new might want to unregister the device
>> once it's done. It might also require it in an error handling path in
>> case something didn't go right.
>>
>> Reviewed-by: Andrzej Hajda
>> Signed-off-by: Archit Taneja
>> ---
>> include/drm/drm_mipi_dsi.h | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
>> index cb084af..410d8b5 100644
>> --- a/include/drm/drm_mipi_dsi.h
>> +++ b/include/drm/drm_mipi_dsi.h
>> @@ -195,6 +195,11 @@ ssize_t mipi_dsi_generic_read(struct mipi_dsi_device
>> *dsi, const void *params,
>>
>> struct mipi_dsi_device *mipi_dsi_device_new(struct mipi_dsi_host *host,
>> struct mipi_dsi_device_info *info);
>> +static inline void mipi_dsi_device_unregister(struct mipi_dsi_device *dsi)
>> +{
>> +device_unregister(&dsi->dev);
>> +}
>
> This is the same, essentially, as mipi_dsi_remove_device_fn(). I think
> this should move into drm_mipi_dsi.c and mipi_dsi_remove_device_fn()
> should call this new function so that both OF and !OF share the same
> code for this.
I can do this.
Thanks,
Archit
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
[PATCH v4 6/6] drm/dsi: Get DSI host by DT device node
On 01/21/2016 09:46 PM, Thierry Reding wrote: > On Thu, Dec 10, 2015 at 06:11:40PM +0530, Archit Taneja wrote: >> mipi_dsi_devices are inherently aware of their host because they >> share a parent-child hierarchy in the device tree. >> >> non-dsi drivers that create dsi device don't have this data. In order to >> get this information, they require to a phandle to the dsi host in the >> device tree. >> >> Maintain a list of all the hosts DSI that are currently registered. >> >> This list will be used to find the mipi_dsi_host corresponding to the >> device_node passed in of_find_mipi_dsi_host_by_node. >> >> Reviewed-by: Andrzej Hajda >> Signed-off-by: Archit Taneja >> --- >> drivers/gpu/drm/drm_mipi_dsi.c | 38 ++ >> include/drm/drm_mipi_dsi.h | 3 +++ >> 2 files changed, 41 insertions(+) > > Please be more consistent with the spelling. Abbreviations should be all > capitals. Also s/mipi_dsi_devices/MIPI DSI devices/, and so on. I'll ensure the abbreviations are consistent in the next revision. > > Otherwise I guess this makes sense. Thanks for the review. Thanks, Archit -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[Bug 93879] kernel 4.4.0 causes application lockup and unusable interfaces with radeon hardware
https://bugs.freedesktop.org/show_bug.cgi?id=93879 --- Comment #4 from Michel D�nzer --- Can you guys try reverting the commits referenced in http://lists.freedesktop.org/archives/dri-devel/2016-January/098823.html ? Alternatively, can you bisect? -- 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/20160127/b8f2d0b3/attachment.html>
[PATCH] mm: fix pfn_t to page conversion in vm_insert_mixed
On 26/01/16 20:37, Dan Williams wrote:
> pfn_t_to_page() honors the flags in the pfn_t value to determine if a
> pfn is backed by a page. However, vm_insert_mixed() was originally
> written to use pfn_valid() to make this determination. To restore the
> old/correct behavior, ignore the pfn_t flags in the !pfn_t_devmap() case
> and fallback to trusting pfn_valid().
>
> Fixes: 01c8f1c44b83 ("mm, dax, gpu: convert vm_insert_mixed to pfn_t")
Thanks, this fixes the crash with omapdrm.
Tested-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160127/55261e50/attachment.sig>
[Bug 93801] GRID Autosport hang on logo (startup)
https://bugs.freedesktop.org/show_bug.cgi?id=93801 --- Comment #7 from Michel D�nzer --- (In reply to Maxim Sheviakov from comment #5) > Umm, the game doesn't hang the system. It's about the game's process not to > respond at all - I can simply go to desktop and kill the process. I don't > think that gdb attachment would help either, [...] Of course it would; it would show us whether it's hanging in game code or driver code. From Jos�'s comments it sounds like it's likely the former though. -- 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/20160127/52841591/attachment.html>
[Bug 93801] GRID Autosport hang on logo (startup)
https://bugs.freedesktop.org/show_bug.cgi?id=93801 --- Comment #8 from Maxim Sheviakov --- Okay. I will test it with a debugger + beta (if I'm lucky) one I complete my Gentoo setup. -- 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/20160127/55e23d95/attachment.html>
[Bug 108221] amdgpu: mouse cursor flickers + black boxes
https://bugzilla.kernel.org/show_bug.cgi?id=108221 --- Comment #15 from Michel Dänzer --- (In reply to Fred Santos from comment #14) > 2. We found (Comment #10) that amdgpu was not found/activated during boot: > when 'forcing' its use by creating this /etc/X11/xorg.conf file, everything > is OK, with all kernels I have tested (4.4, 4.3, 4.2). To put it in a > nutshell, no matter the kernel we use, we have the same behavior: it works > if and only if we add this /etc/X11/xorg.conf file. If /etc/X11/xorg.conf.d/10-amdgpu.conf / /usr/share/X11/xorg.conf.d/10-amdgpu.conf isn't enough, then it sounds like maybe the amdgpu kernel driver isn't loaded yet the first time Xorg starts up during boot. Also, it sounds like there's a bug in the Xorg modesetting driver causing the artifacts you described. Probably no kernel bug here though. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 93800] xfwm4 with compositing hangs indefinitely after after coming back from dpms off
https://bugs.freedesktop.org/show_bug.cgi?id=93800 --- Comment #7 from Michel D�nzer --- It might be the kernel regression discussed in http://lists.freedesktop.org/archives/dri-devel/2016-January/098823.html and followups. -- 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/20160127/6a0a5030/attachment.html>
[PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: > On 11 January 2016 at 19:32, Emmanuel Gil Peyrot > wrote: > > This adds R8, RG88 and GR88, as well as the non-subsampled NV24/NV42 > > formats. > > > Err... please don't copy/paste 'random' hunks here. These headers > should be imported from the kernel with the commit message mentioning > the sha of their origin. > > I've been procrastinating^Wwaiting on some upstream changes to land > and with those in place I'll update the Makefile to import things > properly. Yeah, we should have some scripts in libdrm that runs make headers_install, copies over the latest generated uapi headers for drm and then creates a commit with the sha1 it was generated from. Maybe even a rule that the sha1 has to be from Dave's drm-next. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Problem with component helpers and probe deferral in 4.5-rc1
On Tue, 2016-01-26 at 22:35 +, Russell King - ARM Linux wrote: > On Tue, Jan 26, 2016 at 05:59:13PM +, Jon Medhurst (Tixy) wrote: > > I believe I've found a problem with the component helpers and/or how > > drivers use them. I discovered this whilst trying to get ARM's HDLCD > > driver [1] working on 4.5-rc1, however I believe that code is following > > a pattern used by drivers already in 4.5 and the problem isn't specific > > to it. This is what I have observed... > > Hmm, it all looks plausible, and I'm again left wondering how the code > passed testing over the last year (I've been running this code for > ages both on iMX6 and Dove, where deferred probing does happen.) It depends on the order of things. To go wrong, components must already be there before the master is added, then the master needs to defer probing from it's bind callback. So, components deferring won't trigger the issue, neither will master deferring before any components have been added. > Your patch looks like the right thing to do, so I'll add it to the > component tree shortly - it should end up in linux-next in a few days > time. Thanks. I wasn't sure if that patch was correct as I hadn't looked at any of this code before this week. -- Tixy
Problem with component helpers and probe deferral in 4.5-rc1
On Wed, 2016-01-27 at 09:18 +, Jon Medhurst (Tixy) wrote: > On Tue, 2016-01-26 at 22:35 +, Russell King - ARM Linux wrote: > > On Tue, Jan 26, 2016 at 05:59:13PM +, Jon Medhurst (Tixy) wrote: > > > I believe I've found a problem with the component helpers and/or how > > > drivers use them. I discovered this whilst trying to get ARM's HDLCD > > > driver [1] working on 4.5-rc1, however I believe that code is following > > > a pattern used by drivers already in 4.5 and the problem isn't specific > > > to it. This is what I have observed... > > > > Hmm, it all looks plausible, and I'm again left wondering how the code > > passed testing over the last year (I've been running this code for > > ages both on iMX6 and Dove, where deferred probing does happen.) > > It depends on the order of things. To go wrong, components must already > be there before the master is added, then the master needs to defer > probing from it's bind callback. So, components deferring won't trigger > the issue, Actually, looks like drm drivers for armada and imx will end up calling component_bind_all from their bind callpath, so if components return -EPROBE_DEFER from their bind function, then the master will bail out with that, triggering my failure scenario. Hmmm... -- Tixy
[BUG/REGRESSION] Kernel 4.5-rc1 on Acube Sam460ex AMCC 460ex Power PC motherboards
sert_pfn: entry: 0x80eda46b pfn: 0x80eda [ 47.288113] insert_pfn: entry: 0x80edb46b pfn: 0x80edb [ 47.293660] insert_pfn: entry: 0x80edc46b pfn: 0x80edc [ 47.299834] insert_pfn: entry: 0x80edd46b pfn: 0x80edd [ 47.305223] insert_pfn: entry: 0x80ede46b pfn: 0x80ede [ 47.314891] insert_pfn: entry: 0x80edf46b pfn: 0x80edf [ 47.329777] insert_pfn: entry: 0x80ee046b pfn: 0x80ee0 [ 47.339769] insert_pfn: entry: 0x80ee146b pfn: 0x80ee1 [ 47.349777] Machine check in kernel mode. [ 47.353814] Data Write PLB Error [ 47.357049] Vector: 214 at [efff3f10] [ 47.360799] pc: ccec: DataTLBError44x+0x6c/0x90 [ 47.366085] lr: 2008f404 [ 47.369002] sp: bfe76110 [ 47.371885]msr: 21000 [ 47.374506] current = 0xeced85c0 [ 47.377910] pid = 668, comm = Xorg [ 47.381835] Linux version 4.5.0-rc1-Sam460ex (root at julian-VirtualBox) (gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #2 PREEMPT Wed Jan 27 06:07:01 AST 2016 [ 47.395758] enter ? for help [ 47.398638] mon> [ 49.401927] Oops: Machine check, sig: 7 [#2] [ 49.406450] PREEMPT Canyonlands [ 49.409783] Modules linked in: [ 49.413026] CPU: 0 PID: 668 Comm: Xorg Tainted: G D W 4.5.0-rc1-Sam460ex #2 [ 49.421383] task: eced85c0 ti: efff2000 task.ti: ecf8c000 [ 49.427075] NIP: ccec LR: 2008f404 CTR: 2008f4d0 [ 49.432311] REGS: efff3f10 TRAP: 0214 Tainted: G D W (4.5.0-rc1-Sam460ex) [ 49.440755] MSR: 00021000 CR: 88004262 XER: [ 49.447013] GPR00: 1f553134 bfe76110 b7d6d6f0 b752fffc b6d46008 0780 0004 GPR08: b752fffc b6d46010 ecef9000 ecef9000 0009 0780 GPR16: 0020 1e00 20eb5650 0438 b6d46008 GPR24: 0780 bfe76168 20e9f728 b753 b753 b6d46008 20197ff4 1e00 [ 49.478867] NIP [ccec] DataTLBError44x+0x6c/0x90 [ 49.484108] LR [2008f404] 0x2008f404 [ 49.487881] Call Trace: [ 49.490460] Instruction dump: [ 49.493603] 7d7342a6 816b0040 7d92eaa6 7db00aa6 51ac063e 7d92eba6 7d9e0aa6 39a9 [ 49.501909] 518d57bc 554c6cfa 7d6c582e 556c0029 <4182003c> 514cbd38 816c 818c0004 [ 49.510404] ---[ end trace 439fa29153308786 ]--- [ 49.515026] -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160127/237fc007/attachment-0001.html>
Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
Hey, On 27 January 2016 at 09:38, Daniel Vetter wrote: > On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: >> On 11 January 2016 at 19:32, Emmanuel Gil Peyrot >> wrote: >> > This adds R8, RG88 and GR88, as well as the non-subsampled NV24/NV42 >> > formats. >> > >> Err... please don't copy/paste 'random' hunks here. These headers >> should be imported from the kernel with the commit message mentioning >> the sha of their origin. >> >> I've been procrastinating^Wwaiting on some upstream changes to land >> and with those in place I'll update the Makefile to import things >> properly. > > Yeah, we should have some scripts in libdrm that runs make > headers_install, copies over the latest generated uapi headers for drm and > then creates a commit with the sha1 it was generated from. Maybe even a > rule that the sha1 has to be from Dave's drm-next. Yeah, it's certainly doable, once some kernel-internal details are shuffled out of uapi/drm/drm_mode.h. Would be pretty nice to have too. Cheers, Daniel
[PATCH 3/3] vc4: Add headers and .pc files for VC4 userspace development.
Hi,
On 26 January 2016 at 20:10, Eric Anholt wrote:
> Ilia Mirkin writes:
>> On Mon, Jan 25, 2016 at 2:27 PM, Eric Anholt wrote:
>>> The headers were originally written in Mesa, imported to the kernel,
>>> and improved upon in vc4-gpu-tools. These come from the v-g-t copies
>>> and will replace the Mesa and v-g-t copies, and hopefully be used from
>>> new tests in igt, as well.
>>>
>>> Signed-off-by: Eric Anholt
>>> ---
>>> --- /dev/null
>>> +++ b/vc4/libdrm_vc4.pc.in
>>> @@ -0,0 +1,11 @@
>>> +prefix=@prefix@
>>> +exec_prefix=@exec_prefix@
>>> +libdir=@libdir@
>>> +includedir=@includedir@
>>> +
>>> +Name: libdrm_vc4
>>> +Description: Userspace interface to vc4 kernel DRM services
>>> +Version: @PACKAGE_VERSION@
>>> +Requires: libdrm
>>> +Libs: -L${libdir} -ldrm_intel
>>
>> This probably wants to be -ldrm_vc4? Or nothing if there's no such lib yet?
>
> Fixed to be -ldrm until we start building a libdrm_vc4.so.
The Requires will take care of that, so you can just bin the entire
'Libs:' field until you need one:
[line breaks inserted for clarity]
strictly:~/tmp/pc% cat foo.pc bar.pc && PKG_CONFIG_PATH=. pkg-config --libs foo
Name: foo
Version: 1
Description: Nothing, but includes bar
Requires: bar
Name: bar
Description: An actual thing
Version: 1
Libs: -L/bar -lbar
-L/bar -lbar
Cheers,
Daniel
Trying nouveau reclocking
Hi, I was trying to use re-clocking with nouveau in 4.5.0-rc1 with: # echo "0f" >/sys/kernel/debug/dri/0/pstate while Chromium with a WebGL app already running. (www.playmapscube.com) The video chip in question is: 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2) or in numbers: 03:00.0 0300: 10de:0a64 (rev a2) It is an integrated chip on the mainboard. The result was: [ 77.531009] [ cut here ] [ 77.531009] WARNING: CPU: 3 PID: 405 at drivers/gpu/drm/nouveau/nvkm/subdev/mc/base.c:51 nvkm_mc_intr+0x102/0x110 [nouveau]() [ 77.531009] Modules linked in: tun ums_realtek uas usb_storage joydev input_leds hid_generic usbhid hid cdc_acm snd_hda_codec_hdmi nouveau arc4 mxm_wmi wmi ath9k i2c_algo_bit iTCO_wdt drm_kms_helper iTCO_vendor_support gpio_ich ath9k_common snd_hda_codec_realtek ttm snd_hda_codec_generic ath9k_hw drm snd_hda_intel ath snd_hda_codec mac80211 snd_hwdep syscopyarea lpc_ich snd_hda_core sysfillrect mfd_core sysimgblt fb_sys_fops coretemp snd_pcm serio_raw i2c_i801 xhci_pci pcspkr xhci_hcd cfg80211 r8169 snd_timer i2c_core snd mii ehci_pci uhci_hcd rfkill ehci_hcd soundcore acpi_cpufreq xt_limit xt_multiport xt_recent ip6table_filter xt_conntrack ip6table_nat iptable_nat nf_conntrack_ipv6 nf_nat_ipv4 nf_defrag_ipv6 nf_conntrack_ipv4 nf_nat_ipv6 nf_defrag_ipv4 nf_nat xt_connmark nf_conntrack ip6_tables [ 77.531009] iptable_mangle [ 77.531009] CPU: 3 PID: 405 Comm: Xorg.bin Not tainted 4.5.0-rc1 #1 [ 77.531009] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To Be Filled By O.E.M., BIOS 080016 05/05/2011 [ 77.531009] a053b6f0 88007fd83cd8 80761604 [ 77.531009] 88007fd83d10 8048e7a2 88007c0ef480 880037838840 [ 77.531009] 88007a4b3800 a04fa9a0 88007fd83d20 [ 77.531009] Call Trace: [ 77.531009][] dump_stack+0x44/0x60 [ 77.531009] [] warn_slowpath_common+0x82/0xc0 [ 77.531009] [] warn_slowpath_null+0x1a/0x20 [ 77.531009] [] nvkm_mc_intr+0x102/0x110 [nouveau] [ 77.531009] [] nvkm_pci_intr+0x44/0x70 [nouveau] [ 77.531009] [] handle_irq_event_percpu+0x75/0x180 [ 77.531009] [] handle_irq_event+0x3b/0x60 [ 77.531009] [] handle_edge_irq+0x74/0x130 [ 77.531009] [] handle_irq+0x1a/0x30 [ 77.531009] [] do_IRQ+0x4b/0xd0 [ 77.531009] [] common_interrupt+0x82/0x82 [ 77.531009] [] ? __do_softirq+0x7b/0x260 [ 77.531009] [] irq_exit+0xb1/0xc0 [ 77.531009] [] smp_apic_timer_interrupt+0x42/0x50 [ 77.531009] [] apic_timer_interrupt+0x82/0x90 [ 77.531009][] ? nouveau_fence_emit+0xf1/0x1a0 [nouveau] [ 77.531009] [] ? nouveau_fence_emit+0x13f/0x1a0 [nouveau] [ 77.531009] [] nouveau_fence_new+0x59/0xa0 [nouveau] [ 77.531009] [] nouveau_gem_ioctl_pushbuf+0xeb5/0x1730 [nouveau] [ 77.531009] [] drm_ioctl+0x152/0x540 [drm] [ 77.531009] [] ? nouveau_gem_ioctl_new+0x1c0/0x1c0 [nouveau] [ 77.531009] [] ? fpu__activate_curr+0x15/0x20 [ 77.531009] [] nouveau_drm_ioctl+0x68/0xc0 [nouveau] [ 77.531009] [] do_vfs_ioctl+0x92/0x580 [ 77.531009] [] ? security_file_ioctl+0x43/0x60 [ 77.531009] [] SyS_ioctl+0x79/0x90 [ 77.531009] [] entry_SYSCALL_64_fastpath+0x16/0x75 [ 77.531009] ---[ end trace 4a0b55289f0a358e ]--- [ 78.561529] nouveau :03:00.0: timeout at drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:332/gt215_clk_pre()! [ 90.693743] nouveau :03:00.0: gr: PGRAPH TLB flush idle timeout fail [ 90.693743] nouveau :03:00.0: gr: PGRAPH_STATUS 01dffe03 [BUSY DISPATCH VFETCH CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL ENG2D RMASK TPC_RAST TPC_PROP ] [ 90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS0: 00145b49 [VFETCH CCACHE] [ 90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS1: 1a2d [TPC_MP] [ 90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS2: 0034db43 [ENG2D ROP] [ 93.001694] nouveau :03:00.0: gr: PGRAPH TLB flush idle timeout fail [ 93.001694] nouveau :03:00.0: gr: PGRAPH_STATUS 01dffe03 [BUSY DISPATCH VFETCH CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL ENG2D RMASK TPC_RAST TPC_PROP ] [ 93.001694] nouveau :03:00.0: gr: PGRAPH_VSTATUS0: 00145b49 [VFETCH CCACHE] [ 93.001694] nouveau :03:00.0: gr: PGRAPH_VSTATUS1: 1a2d [TPC_MP] [ 93.001694] nouveau :03:00.0: gr: PGRAPH_VSTATUS2: 0034db43 [ENG2D ROP] [ 95.137647] nouveau :03:00.0: gr: PGRAPH TLB flush idle timeout fail [ 95.137647] nouveau :03:00.0: gr: PGRAPH_STATUS 01dffe03 [BUSY DISPATCH VFETCH CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL ENG2D RMASK TPC_RAST TPC_PROP ] [ 95.137647] nouveau :03:00.0: gr: PGRAPH_VSTATUS0: 00145b49 [VFETCH CCACHE] [ 95.137647] nouveau :03:00.0: gr: PGRAPH_VSTATUS1: 1a2d [TPC_MP] [ 95.137647] nouveau :03:00.0: gr: PGRAPH_VSTATUS2: 0034db43 [ENG2D ROP] [ 98.022424] nouve
[PATCH libdrm] Update/fix the {copy,commit}-headers targets
As some headers do not reside in include/drm we need to tweak our rules, and exclude headers that shouldn't be distributed [XXX: clarify why ?]. To avoid the extra magic of diving into the kernel tree running `make headers_install', just sed out the only reason why we need it - __user. Cc: Alex Deucher Cc: Michel Dänzer Cc: Ben Skeggs Cc: Dave Airlie Cc: Daniel Stone Cc: Daniel Vetter Cc: Inki Dae Cc: Rob Clark Cc: Tomi Valkeinen Cc: Daniel Kurtz Signed-off-by: Emil Velikov --- Gents, As one runs `make copy-headers' we get a massive diff stat (+1500/-800) and a handful of issues gets pointed out. Please let me know of your prefered solution (regardless if one will get to it soon) and if we should consider it a blocker (B) or not (N). Thanks Emil - (N) Header license miss-match - omap, msm, exynos. Update the kernel ones ? - (N) Broken compat ioctls - exynos (and the UMS drivers) - using unsigned int as opposed to _u32/64. Considering they're 32bit only, we can get away with 'breaking' the ABI and using the proper ones ? - (N, keep local for now) C++ compat - libdrm has a hack/workaround (virtual is a keyword in C++), which I'd like us to upstream plus some extern C wrappers. - (?) Missing UMS symbols - see _DRM_GEM - (?) Non C89 compliant (see DRM_DRAWABLE_CLIPRECTS) - do we still want/need that ? - (B) Using include as opposed to include "..." - drm.h, nouveau_drm.h. Should be fixed in kernel. - (N) ABI 'break' + drm - struct drm_mode_get_connector extra pad + tegra - struct drm_tegra_gem_mmap extra pad - (B) API break + drm - missing DRM_MODE_OBJECT_* + nouveau - missing (gs)etparam - both structs and macros. everything else is fine/unused. + radeon - RADEON_TILING_R600_NO_SCANOUT, CIK_TILE_MODE_COLOR_2D* and CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_* - quick grep shows no users + omap - struct drm_omap_get_base, DRM_OMAP_GET_BASE + IOCTL - (N) (unneeded?) API additions - nouveau's DRM_IOCTL_NOUVEAU_GEM_* - (N) __KERNEL__ condiditionals. Is it really an issue - sure if looks a bit spurious but that's about it. Makefile.am | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index ca41508..6c71d3a 100644 --- a/Makefile.am +++ b/Makefile.am @@ -126,7 +126,14 @@ endif copy-headers : cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/ + sed -i "s/__user //g" $(top_srcdir)/include/drm/*.h + mv $(top_srcdir)/include/drm/exynos_drm.h $(top_srcdir)/exynos/ + mv $(top_srcdir)/include/drm/msm_drm.h $(top_srcdir)/freedreno/msm/ + mv $(top_srcdir)/include/drm/omap_drm.h $(top_srcdir)/omap/ + rm $(top_srcdir)/include/drm/armada_drm.h + rm $(top_srcdir)/include/drm/etnaviv_drm.h + rm $(top_srcdir)/include/drm/i810_drm.h + rm $(top_srcdir)/include/drm/vc4_drm.h commit-headers : copy-headers - git add include/drm/*.h git commit -am "Copy headers from kernel $$(GIT_DIR=$(kernel_source)/.git git describe)" -- 2.6.2
Trying nouveau reclocking
The warn in question is
static u32
nvkm_mc_intr_mask(struct nvkm_mc *mc)
{
u32 intr = mc->func->intr_mask(mc);
if (WARN_ON_ONCE(intr == 0x))
intr = 0; /* likely fallen off the bus */
return intr;
}
Which is basically a sign of total death. Is this new with 4.5-rc1, or
is this the first time you've tried reclocking this chip?
-ilia
On Wed, Jan 27, 2016 at 6:59 AM, Boszormenyi Zoltan wrote:
> Hi,
>
> I was trying to use re-clocking with nouveau in 4.5.0-rc1 with:
>
> # echo "0f" >/sys/kernel/debug/dri/0/pstate
>
> while Chromium with a WebGL app already running. (www.playmapscube.com)
>
> The video chip in question is:
>
> 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2)
>
> or in numbers:
>
> 03:00.0 0300: 10de:0a64 (rev a2)
>
> It is an integrated chip on the mainboard.
>
> The result was:
>
> [ 77.531009] [ cut here ]
> [ 77.531009] WARNING: CPU: 3 PID: 405 at
> drivers/gpu/drm/nouveau/nvkm/subdev/mc/base.c:51 nvkm_mc_intr+0x102/0x110
> [nouveau]()
> [ 77.531009] Modules linked in: tun ums_realtek uas usb_storage joydev
> input_leds
> hid_generic usbhid hid cdc_acm snd_hda_codec_hdmi nouveau arc4 mxm_wmi wmi
> ath9k
> i2c_algo_bit iTCO_wdt drm_kms_helper iTCO_vendor_support gpio_ich ath9k_common
> snd_hda_codec_realtek ttm snd_hda_codec_generic ath9k_hw drm snd_hda_intel ath
> snd_hda_codec mac80211 snd_hwdep syscopyarea lpc_ich snd_hda_core sysfillrect
> mfd_core
> sysimgblt fb_sys_fops coretemp snd_pcm serio_raw i2c_i801 xhci_pci pcspkr
> xhci_hcd
> cfg80211 r8169 snd_timer i2c_core snd mii ehci_pci uhci_hcd rfkill ehci_hcd
> soundcore
> acpi_cpufreq xt_limit xt_multiport xt_recent ip6table_filter xt_conntrack
> ip6table_nat
> iptable_nat nf_conntrack_ipv6 nf_nat_ipv4 nf_defrag_ipv6 nf_conntrack_ipv4
> nf_nat_ipv6
> nf_defrag_ipv4 nf_nat xt_connmark nf_conntrack ip6_tables
> [ 77.531009] iptable_mangle
> [ 77.531009] CPU: 3 PID: 405 Comm: Xorg.bin Not tainted 4.5.0-rc1 #1
> [ 77.531009] Hardware name: To Be Filled By O.E.M. To Be Filled By
> O.E.M./To Be Filled
> By O.E.M., BIOS 080016 05/05/2011
> [ 77.531009] a053b6f0 88007fd83cd8 80761604
>
> [ 77.531009] 88007fd83d10 8048e7a2 88007c0ef480
> 880037838840
> [ 77.531009] 88007a4b3800 a04fa9a0
> 88007fd83d20
> [ 77.531009] Call Trace:
> [ 77.531009][] dump_stack+0x44/0x60
> [ 77.531009] [] warn_slowpath_common+0x82/0xc0
> [ 77.531009] [] warn_slowpath_null+0x1a/0x20
> [ 77.531009] [] nvkm_mc_intr+0x102/0x110 [nouveau]
> [ 77.531009] [] nvkm_pci_intr+0x44/0x70 [nouveau]
> [ 77.531009] [] handle_irq_event_percpu+0x75/0x180
> [ 77.531009] [] handle_irq_event+0x3b/0x60
> [ 77.531009] [] handle_edge_irq+0x74/0x130
> [ 77.531009] [] handle_irq+0x1a/0x30
> [ 77.531009] [] do_IRQ+0x4b/0xd0
> [ 77.531009] [] common_interrupt+0x82/0x82
> [ 77.531009] [] ? __do_softirq+0x7b/0x260
> [ 77.531009] [] irq_exit+0xb1/0xc0
> [ 77.531009] [] smp_apic_timer_interrupt+0x42/0x50
> [ 77.531009] [] apic_timer_interrupt+0x82/0x90
> [ 77.531009][] ? nouveau_fence_emit+0xf1/0x1a0
> [nouveau]
> [ 77.531009] [] ? nouveau_fence_emit+0x13f/0x1a0
> [nouveau]
> [ 77.531009] [] nouveau_fence_new+0x59/0xa0 [nouveau]
> [ 77.531009] [] nouveau_gem_ioctl_pushbuf+0xeb5/0x1730
> [nouveau]
> [ 77.531009] [] drm_ioctl+0x152/0x540 [drm]
> [ 77.531009] [] ? nouveau_gem_ioctl_new+0x1c0/0x1c0
> [nouveau]
> [ 77.531009] [] ? fpu__activate_curr+0x15/0x20
> [ 77.531009] [] nouveau_drm_ioctl+0x68/0xc0 [nouveau]
> [ 77.531009] [] do_vfs_ioctl+0x92/0x580
> [ 77.531009] [] ? security_file_ioctl+0x43/0x60
> [ 77.531009] [] SyS_ioctl+0x79/0x90
> [ 77.531009] [] entry_SYSCALL_64_fastpath+0x16/0x75
> [ 77.531009] ---[ end trace 4a0b55289f0a358e ]---
> [ 78.561529] nouveau :03:00.0: timeout at
> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:332/gt215_clk_pre()!
> [ 90.693743] nouveau :03:00.0: gr: PGRAPH TLB flush idle timeout fail
> [ 90.693743] nouveau :03:00.0: gr: PGRAPH_STATUS 01dffe03 [BUSY
> DISPATCH VFETCH
> CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL
> ENG2D RMASK
> TPC_RAST TPC_PROP
> ]
> [ 90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS0: 00145b49 [VFETCH
> CCACHE]
> [ 90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS1: 1a2d [TPC_MP]
> [ 90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS2: 0034db43 [ENG2D ROP]
> [ 93.001694] nouveau :03:00.0: gr: PGRAPH TLB flush idle timeout fail
> [ 93.001694] nouveau :03:00.0: gr: PGRAPH_STATUS 01dffe03 [BUSY
> DISPATCH VFETCH
> CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL
> ENG2D RMASK
> TPC_RAST TPC_PROP
> ]
> [ 93.001694] nouveau :03:00.0: gr: PGRAPH_VSTATUS0: 00145b49 [VFETCH
> CCACHE]
> [ 93.001694] nouveau :03
Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
On 27 January 2016 at 11:42, Daniel Stone wrote: > Hey, > > On 27 January 2016 at 09:38, Daniel Vetter wrote: >> On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: >>> On 11 January 2016 at 19:32, Emmanuel Gil Peyrot >>> wrote: >>> > This adds R8, RG88 and GR88, as well as the non-subsampled NV24/NV42 >>> > formats. >>> > >>> Err... please don't copy/paste 'random' hunks here. These headers >>> should be imported from the kernel with the commit message mentioning >>> the sha of their origin. >>> >>> I've been procrastinating^Wwaiting on some upstream changes to land >>> and with those in place I'll update the Makefile to import things >>> properly. >> >> Yeah, we should have some scripts in libdrm that runs make >> headers_install, copies over the latest generated uapi headers for drm and >> then creates a commit with the sha1 it was generated from. Maybe even a >> rule that the sha1 has to be from Dave's drm-next. > > Yeah, it's certainly doable, once some kernel-internal details are > shuffled out of uapi/drm/drm_mode.h. What do you have in mind - DRM_MODE_PICTURE_ASPECT_* ? I'm thinking more that we should bring back DRM_MODE_OBJECT_* as it breaks libdrm and maybe other userspace. Feel free to let me know here or in the patch I just sent (didn't realise and I Cc'd your collabora email). Thanks Emil
[PATCH v2 00/11] sync framework de-staging: part 2 - de-stage
From: Gustavo Padovan
This patch series de-stage the sync framework and it a follow up on the
clean up series I've sent last week:
http://thread.gmane.org/gmane.comp.video.dri.devel/145509
Now in part 2 we finish the de-stage of the sync framework. It start with the
move of sync_file from staging to drivers/dma-buf, followed by a bunch of clean
ups on sync_timeline and sw_sync. Finally we de-stage the later two plus the
debug routines.
v2: use git format-patch -M
Gustavo Padovan (11):
dma-buf/sync_file: de-stage sync_file
staging/android: store last signaled value on sync timeline
staging/android: remove .fill_driver_data() timeline ops
staging/android: remove .{fence,timeline}_value_str() from
timeline_ops
staging/android: remove struct sync_timeline_ops
staging/android: remove sw_sync_timeline and sw_sync_pt
staging/android: remove sw_sync.[ch] files
staging/android: rename android_fence to timeline_fence
dma-buf/sync_timeline: de-stage sync_timeline
dma-buf/sync_file: bring debug back to sync file
dma-buf/sync_file: bring sync_dump() back
drivers/Kconfig| 2 +
drivers/dma-buf/Kconfig| 21 ++
drivers/dma-buf/Makefile | 2 +
.../{staging/android/uapi => dma-buf}/sw_sync.h| 0
drivers/{staging/android => dma-buf}/sync_debug.c | 40 ++--
drivers/dma-buf/sync_debug.h | 35 +++
.../android/sync.c => dma-buf/sync_file.c} | 245 ++-
drivers/dma-buf/sync_timeline.c| 222 ++
drivers/staging/android/Kconfig| 19 --
drivers/staging/android/Makefile | 1 -
drivers/staging/android/sw_sync.c | 103
drivers/staging/android/sw_sync.h | 59 -
drivers/staging/android/sync.h | 261 -
include/linux/sync_file.h | 123 ++
include/linux/sync_timeline.h | 114 +
.../sync.h => include/trace/events/sync_file.h | 35 +--
include/trace/events/sync_timeline.h | 31 +++
.../android/uapi => include/uapi/linux}/sync.h | 12 +-
18 files changed, 604 insertions(+), 721 deletions(-)
create mode 100644 drivers/dma-buf/Kconfig
rename drivers/{staging/android/uapi => dma-buf}/sw_sync.h (100%)
rename drivers/{staging/android => dma-buf}/sync_debug.c (91%)
create mode 100644 drivers/dma-buf/sync_debug.h
rename drivers/{staging/android/sync.c => dma-buf/sync_file.c} (62%)
create mode 100644 drivers/dma-buf/sync_timeline.c
delete mode 100644 drivers/staging/android/sw_sync.c
delete mode 100644 drivers/staging/android/sw_sync.h
delete mode 100644 drivers/staging/android/sync.h
create mode 100644 include/linux/sync_file.h
create mode 100644 include/linux/sync_timeline.h
rename drivers/staging/android/trace/sync.h =>
include/trace/events/sync_file.h (58%)
create mode 100644 include/trace/events/sync_timeline.h
rename {drivers/staging/android/uapi => include/uapi/linux}/sync.h (90%)
--
2.5.0
[PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file
From: Gustavo Padovan
sync_file is useful to connect one or more fences to the file. The file is
used by userspace to track fences.
Signed-off-by: Gustavo Padovan
---
drivers/Kconfig| 2 +
drivers/dma-buf/Kconfig| 11 +
drivers/dma-buf/Makefile | 1 +
drivers/dma-buf/sync_file.c| 440 +
drivers/staging/android/Kconfig| 1 +
drivers/staging/android/sync.c | 419
drivers/staging/android/sync.h | 105 +
drivers/staging/android/sync_debug.c | 1 +
drivers/staging/android/trace/sync.h | 44 ---
include/linux/sync_file.h | 123 ++
include/trace/events/sync_file.h | 57 +++
.../android/uapi => include/uapi/linux}/sync.h | 12 +-
12 files changed, 644 insertions(+), 572 deletions(-)
create mode 100644 drivers/dma-buf/Kconfig
create mode 100644 drivers/dma-buf/sync_file.c
create mode 100644 include/linux/sync_file.h
create mode 100644 include/trace/events/sync_file.h
rename {drivers/staging/android/uapi => include/uapi/linux}/sync.h (90%)
diff --git a/drivers/Kconfig b/drivers/Kconfig
index d2ac339..430f761 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -114,6 +114,8 @@ source "drivers/rtc/Kconfig"
source "drivers/dma/Kconfig"
+source "drivers/dma-buf/Kconfig"
+
source "drivers/dca/Kconfig"
source "drivers/auxdisplay/Kconfig"
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
new file mode 100644
index 000..9824bc4
--- /dev/null
+++ b/drivers/dma-buf/Kconfig
@@ -0,0 +1,11 @@
+menu "DMABUF options"
+
+config SYNC_FILE
+ bool "sync_file support for fences"
+ default n
+ select ANON_INODES
+ select DMA_SHARED_BUFFER
+ ---help---
+ This option enables the fence framework synchronization to export
+ sync_files to userspace that can represent one or more fences.
+endmenu
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 57a675f..4a424ec 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1 +1,2 @@
obj-y := dma-buf.o fence.o reservation.o seqno-fence.o
+obj-$(CONFIG_SYNC_FILE)+= sync_file.o
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
new file mode 100644
index 000..92474dd
--- /dev/null
+++ b/drivers/dma-buf/sync_file.c
@@ -0,0 +1,440 @@
+/*
+ * drivers/dma-buf/sync_file.c
+ *
+ * Copyright (C) 2012 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CREATE_TRACE_POINTS
+#include
+
+static const struct file_operations sync_file_fops;
+
+static struct sync_file *sync_file_alloc(int size, const char *name)
+{
+ struct sync_file *sync_file;
+
+ sync_file = kzalloc(size, GFP_KERNEL);
+ if (!sync_file)
+ return NULL;
+
+ sync_file->file = anon_inode_getfile("sync_file", &sync_file_fops,
+sync_file, 0);
+ if (IS_ERR(sync_file->file))
+ goto err;
+
+ kref_init(&sync_file->kref);
+ strlcpy(sync_file->name, name, sizeof(sync_file->name));
+
+ init_waitqueue_head(&sync_file->wq);
+
+ return sync_file;
+
+err:
+ kfree(sync_file);
+ return NULL;
+}
+
+static void fence_check_cb_func(struct fence *f, struct fence_cb *cb)
+{
+ struct sync_file_cb *check;
+ struct sync_file *sync_file;
+
+ check = container_of(cb, struct sync_file_cb, cb);
+ sync_file = check->sync_file;
+
+ if (atomic_dec_and_test(&sync_file->status))
+ wake_up_all(&sync_file->wq);
+}
+
+/* TODO: implement a create which takes more that one fence */
+struct sync_file *sync_file_create(const char *name, struct fence *fence)
+{
+ struct sync_file *sync_file;
+
+ sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]),
+ name);
+ if (!sync_file)
+ return NULL;
+
+ sync_file->num_fences = 1;
+ atomic_set(&sync_file->status, 1);
+
+ sync_file->cbs[0].fence = fence;
+ sync_file->cbs[0].sync_file = sync_file;
+ if (fence_add_callback(fence, &sync_file->cbs[0].cb,
+ fence_check_cb_func))
+ atomic_dec(&sync_file->statu
[PATCH v2 02/11] staging/android: store last signaled value on sync timeline
From: Gustavo Padovan
Now fence timeline is aware of the last signaled fence, as it
receives the increment to the current value in sync_timeline_signal().
That allow us to remove .has_signaled() from timeline_ops as we can
directly compare using timeline->value and fence->seqno in sync.c
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c | 16 ++--
drivers/staging/android/sync.c| 15 +++
drivers/staging/android/sync.h| 14 +-
3 files changed, 14 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
index 3bee959..b9d53d3 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -30,7 +30,7 @@ struct fence *sw_sync_pt_create(struct sw_sync_timeline *obj,
u32 value)
struct sw_sync_pt *pt;
pt = (struct sw_sync_pt *)
- sync_pt_create(&obj->obj, sizeof(struct sw_sync_pt));
+ sync_pt_create(&obj->obj, sizeof(struct sw_sync_pt), value);
pt->value = value;
@@ -38,15 +38,6 @@ struct fence *sw_sync_pt_create(struct sw_sync_timeline
*obj, u32 value)
}
EXPORT_SYMBOL(sw_sync_pt_create);
-static int sw_sync_fence_has_signaled(struct fence *fence)
-{
- struct sw_sync_pt *pt = (struct sw_sync_pt *)fence;
- struct sw_sync_timeline *obj =
- (struct sw_sync_timeline *)fence_parent(fence);
-
- return (pt->value > obj->value) ? 0 : 1;
-}
-
static int sw_sync_fill_driver_data(struct fence *fence,
void *data, int size)
{
@@ -77,7 +68,6 @@ static void sw_sync_fence_value_str(struct fence *fence, char
*str, int size)
static struct sync_timeline_ops sw_sync_timeline_ops = {
.driver_name = "sw_sync",
- .has_signaled = sw_sync_fence_has_signaled,
.fill_driver_data = sw_sync_fill_driver_data,
.timeline_value_str = sw_sync_timeline_value_str,
.fence_value_str = sw_sync_fence_value_str,
@@ -96,8 +86,6 @@ EXPORT_SYMBOL(sw_sync_timeline_create);
void sw_sync_timeline_inc(struct sw_sync_timeline *obj, u32 inc)
{
- obj->value += inc;
-
- sync_timeline_signal(&obj->obj);
+ sync_timeline_signal(&obj->obj, inc);
}
EXPORT_SYMBOL(sw_sync_timeline_inc);
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 1e1c009..4eea5c3 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -90,7 +90,7 @@ void sync_timeline_destroy(struct sync_timeline *obj)
}
EXPORT_SYMBOL(sync_timeline_destroy);
-void sync_timeline_signal(struct sync_timeline *obj)
+void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc)
{
unsigned long flags;
struct fence *fence, *next;
@@ -99,6 +99,8 @@ void sync_timeline_signal(struct sync_timeline *obj)
spin_lock_irqsave(&obj->child_list_lock, flags);
+ obj->value += inc;
+
list_for_each_entry_safe(fence, next, &obj->active_list_head,
active_list) {
if (fence_is_signaled_locked(fence))
@@ -109,7 +111,8 @@ void sync_timeline_signal(struct sync_timeline *obj)
}
EXPORT_SYMBOL(sync_timeline_signal);
-struct fence *sync_pt_create(struct sync_timeline *obj, int size)
+struct fence *sync_pt_create(struct sync_timeline *obj, int size,
+unsigned int value)
{
unsigned long flags;
struct fence *fence;
@@ -124,7 +127,7 @@ struct fence *sync_pt_create(struct sync_timeline *obj, int
size)
spin_lock_irqsave(&obj->child_list_lock, flags);
sync_timeline_get(obj);
fence_init(fence, &android_fence_ops, &obj->child_list_lock,
- obj->context, ++obj->value);
+ obj->context, value);
list_add_tail(&fence->child_list, &obj->child_list_head);
INIT_LIST_HEAD(&fence->active_list);
spin_unlock_irqrestore(&obj->child_list_lock, flags);
@@ -164,12 +167,8 @@ static void android_fence_release(struct fence *fence)
static bool android_fence_signaled(struct fence *fence)
{
struct sync_timeline *parent = fence_parent(fence);
- int ret;
- ret = parent->ops->has_signaled(fence);
- if (ret < 0)
- fence->status = ret;
- return ret;
+ return (fence->seqno > parent->value) ? false : true;
}
static bool android_fence_enable_signaling(struct fence *fence)
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index fb209fc..4d3dfbf 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -27,10 +27,6 @@ struct sync_timeline;
/**
* struct sync_timeline_ops - sync object implementation ops
* @driver_name: name of the implementation
- * @has_signaled: returns:
- * 1 if pt has signaled
- * 0 if pt has not signaled
- * <0 on error
* @fill_driver_data: write i
[PATCH v2 03/11] staging/android: remove .fill_driver_data() timeline ops
From: Gustavo Padovan
The .fill_driver_data() ops was just a useless abstraction for
fence_ops op of the same name.
Now that we use fence->seqno to store the value it is cleaner to
remove the abstraction and fill the data directly.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c | 14 --
drivers/staging/android/sync.c| 9 +
drivers/staging/android/sync.h| 7 ---
3 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
index b9d53d3..428e22c 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -38,19 +38,6 @@ struct fence *sw_sync_pt_create(struct sw_sync_timeline
*obj, u32 value)
}
EXPORT_SYMBOL(sw_sync_pt_create);
-static int sw_sync_fill_driver_data(struct fence *fence,
- void *data, int size)
-{
- struct sw_sync_pt *pt = (struct sw_sync_pt *)fence;
-
- if (size < sizeof(pt->value))
- return -ENOMEM;
-
- memcpy(data, &pt->value, sizeof(pt->value));
-
- return sizeof(pt->value);
-}
-
static void sw_sync_timeline_value_str(struct sync_timeline *sync_timeline,
char *str, int size)
{
@@ -68,7 +55,6 @@ static void sw_sync_fence_value_str(struct fence *fence, char
*str, int size)
static struct sync_timeline_ops sw_sync_timeline_ops = {
.driver_name = "sw_sync",
- .fill_driver_data = sw_sync_fill_driver_data,
.timeline_value_str = sw_sync_timeline_value_str,
.fence_value_str = sw_sync_fence_value_str,
};
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 4eea5c3..39af5fb 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -185,11 +185,12 @@ static bool android_fence_enable_signaling(struct fence
*fence)
static int android_fence_fill_driver_data(struct fence *fence,
void *data, int size)
{
- struct sync_timeline *parent = fence_parent(fence);
+ if (size < sizeof(fence->seqno))
+ return -ENOMEM;
+
+ memcpy(data, &fence->seqno, sizeof(fence->seqno));
- if (!parent->ops->fill_driver_data)
- return 0;
- return parent->ops->fill_driver_data(fence, data, size);
+ return sizeof(fence->seqno);
}
static void android_fence_value_str(struct fence *fence,
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 4d3dfbf..500838b 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -27,10 +27,6 @@ struct sync_timeline;
/**
* struct sync_timeline_ops - sync object implementation ops
* @driver_name: name of the implementation
- * @fill_driver_data: write implementation specific driver data to data.
- * should return an error if there is not enough room
- * as specified by size. This information is returned
- * to userspace by SYNC_IOC_FENCE_INFO.
* @timeline_value_str: fill str with the value of the sync_timeline's counter
* @fence_value_str: fill str with the value of the fence
*/
@@ -38,9 +34,6 @@ struct sync_timeline_ops {
const char *driver_name;
/* optional */
- int (*fill_driver_data)(struct fence *fence, void *data, int size);
-
- /* optional */
void (*timeline_value_str)(struct sync_timeline *timeline, char *str,
int size);
--
2.5.0
[PATCH v2 04/11] staging/android: remove .{fence, timeline}_value_str() from timeline_ops
From: Gustavo Padovan
Now that the value of fence and the timeline are not stored by sw_sync
anymore we can remove this extra abstraction to retrieve this data.
This patch changes both fence_ops (.fence_value_str and
.timeline_value_str) to return the str directly.
It also clean up struct sync_timeline_ops by removing both ops from there.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c| 17 -
drivers/staging/android/sync.c | 16 ++--
drivers/staging/android/sync.h | 9 -
drivers/staging/android/sync_debug.c | 12 ++--
drivers/staging/android/trace/sync.h | 12 +++-
5 files changed, 7 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
index 428e22c..4200b12 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -38,25 +38,8 @@ struct fence *sw_sync_pt_create(struct sw_sync_timeline
*obj, u32 value)
}
EXPORT_SYMBOL(sw_sync_pt_create);
-static void sw_sync_timeline_value_str(struct sync_timeline *sync_timeline,
- char *str, int size)
-{
- struct sw_sync_timeline *timeline =
- (struct sw_sync_timeline *)sync_timeline;
- snprintf(str, size, "%d", timeline->value);
-}
-
-static void sw_sync_fence_value_str(struct fence *fence, char *str, int size)
-{
- struct sw_sync_pt *pt = (struct sw_sync_pt *)fence;
-
- snprintf(str, size, "%d", pt->value);
-}
-
static struct sync_timeline_ops sw_sync_timeline_ops = {
.driver_name = "sw_sync",
- .timeline_value_str = sw_sync_timeline_value_str,
- .fence_value_str = sw_sync_fence_value_str,
};
struct sw_sync_timeline *sw_sync_timeline_create(const char *name)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 39af5fb..f2d298c 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -196,14 +196,7 @@ static int android_fence_fill_driver_data(struct fence
*fence,
static void android_fence_value_str(struct fence *fence,
char *str, int size)
{
- struct sync_timeline *parent = fence_parent(fence);
-
- if (!parent->ops->fence_value_str) {
- if (size)
- *str = 0;
- return;
- }
- parent->ops->fence_value_str(fence, str, size);
+ snprintf(str, size, "%d", fence->seqno);
}
static void android_fence_timeline_value_str(struct fence *fence,
@@ -211,12 +204,7 @@ static void android_fence_timeline_value_str(struct fence
*fence,
{
struct sync_timeline *parent = fence_parent(fence);
- if (!parent->ops->timeline_value_str) {
- if (size)
- *str = 0;
- return;
- }
- parent->ops->timeline_value_str(parent, str, size);
+ snprintf(str, size, "%d", parent->value);
}
static const struct fence_ops android_fence_ops = {
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 500838b..b1a4b06 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -27,18 +27,9 @@ struct sync_timeline;
/**
* struct sync_timeline_ops - sync object implementation ops
* @driver_name: name of the implementation
- * @timeline_value_str: fill str with the value of the sync_timeline's counter
- * @fence_value_str: fill str with the value of the fence
*/
struct sync_timeline_ops {
const char *driver_name;
-
- /* optional */
- void (*timeline_value_str)(struct sync_timeline *timeline, char *str,
- int size);
-
- /* optional */
- void (*fence_value_str)(struct fence *fence, char *str, int size);
};
/**
diff --git a/drivers/staging/android/sync_debug.c
b/drivers/staging/android/sync_debug.c
index b37412d..7517fb3 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -134,16 +134,8 @@ static void sync_print_obj(struct seq_file *s, struct
sync_timeline *obj)
struct list_head *pos;
unsigned long flags;
- seq_printf(s, "%s %s", obj->name, obj->ops->driver_name);
-
- if (obj->ops->timeline_value_str) {
- char value[64];
-
- obj->ops->timeline_value_str(obj, value, sizeof(value));
- seq_printf(s, ": %s", value);
- }
-
- seq_puts(s, "\n");
+ seq_printf(s, "%s %s: %d\n", obj->name, obj->ops->driver_name,
+ obj->value);
spin_lock_irqsave(&obj->child_list_lock, flags);
list_for_each(pos, &obj->child_list_head) {
diff --git a/drivers/staging/android/trace/sync.h
b/drivers/staging/android/trace/sync.h
index a0f80f4..d7f6457f 100644
--- a/drivers/staging/android/trace/sync.h
+++ b/drivers/staging/android/trace/sync.h
@@ -15,21 +15,15 @@ TRACE_EVENT(sync_timeline,
TP_STRUCT__en
[PATCH v2 05/11] staging/android: remove struct sync_timeline_ops
From: Gustavo Padovan
Move drv_name, the last field of sync_timeline_ops, to sync_timeline
and remove sync_timeline_ops.
struct sync_timeline_ops was just an extra abstraction on top of
fence_ops, and in the last few commits we removed all it ops in favor
of cleaner fence_ops.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c| 9 ++---
drivers/staging/android/sync.c | 8
drivers/staging/android/sync.h | 28 +---
drivers/staging/android/sync_debug.c | 3 +--
4 files changed, 16 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
index 4200b12..c5e92c6 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -38,16 +38,11 @@ struct fence *sw_sync_pt_create(struct sw_sync_timeline
*obj, u32 value)
}
EXPORT_SYMBOL(sw_sync_pt_create);
-static struct sync_timeline_ops sw_sync_timeline_ops = {
- .driver_name = "sw_sync",
-};
-
struct sw_sync_timeline *sw_sync_timeline_create(const char *name)
{
struct sw_sync_timeline *obj = (struct sw_sync_timeline *)
- sync_timeline_create(&sw_sync_timeline_ops,
-sizeof(struct sw_sync_timeline),
-name);
+ sync_timeline_create(sizeof(struct sw_sync_timeline),
+"sw_sync", name);
return obj;
}
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index f2d298c..07fe995 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -30,8 +30,8 @@
static const struct fence_ops android_fence_ops;
-struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops,
- int size, const char *name)
+struct sync_timeline *sync_timeline_create(int size, const char *drv_name,
+ const char *name)
{
struct sync_timeline *obj;
@@ -43,9 +43,9 @@ struct sync_timeline *sync_timeline_create(const struct
sync_timeline_ops *ops,
return NULL;
kref_init(&obj->kref);
- obj->ops = ops;
obj->context = fence_context_alloc(1);
strlcpy(obj->name, name, sizeof(obj->name));
+ strlcpy(obj->drv_name, drv_name, sizeof(obj->drv_name));
INIT_LIST_HEAD(&obj->child_list_head);
INIT_LIST_HEAD(&obj->active_list_head);
@@ -139,7 +139,7 @@ static const char *android_fence_get_driver_name(struct
fence *fence)
{
struct sync_timeline *parent = fence_parent(fence);
- return parent->ops->driver_name;
+ return parent->drv_name;
}
static const char *android_fence_get_timeline_name(struct fence *fence)
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index b1a4b06..be94a80 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -22,20 +22,10 @@
#include
#include
-struct sync_timeline;
-
-/**
- * struct sync_timeline_ops - sync object implementation ops
- * @driver_name: name of the implementation
- */
-struct sync_timeline_ops {
- const char *driver_name;
-};
-
/**
* struct sync_timeline - sync object
* @kref: reference count on fence.
- * @ops: ops that define the implementation of the sync_timeline
+ * @drv_name: drv_name of the driver using the sync_timeline
* @name: name of the sync_timeline. Useful for debugging
* @destroyed: set when sync_timeline is destroyed
* @child_list_head: list of children sync_pts for this sync_timeline
@@ -46,7 +36,7 @@ struct sync_timeline_ops {
*/
struct sync_timeline {
struct kref kref;
- const struct sync_timeline_ops *ops;
+ chardrv_name[32];
charname[32];
/* protected by child_list_lock */
@@ -75,17 +65,17 @@ static inline struct sync_timeline *fence_parent(struct
fence *fence)
/**
* sync_timeline_create() - creates a sync object
- * @ops: specifies the implementation ops for the object
* @size: size to allocate for this obj
+ * @drv_name: sync_timeline driver name
* @name: sync_timeline name
*
- * Creates a new sync_timeline which will use the implementation specified by
- * @ops. @size bytes will be allocated allowing for implementation specific
- * data to be kept after the generic sync_timeline struct. Returns the
- * sync_timeline object or NULL in case of error.
+ * Creates a new sync_timeline. @size bytes will be allocated allowing
+ * for implementation specific data to be kept after the generic
+ * sync_timeline struct. Returns the sync_timeline object or NULL in
+ * case of error.
*/
-struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops,
- int size, const char *name);
+stru
[PATCH v2 06/11] staging/android: remove sw_sync_timeline and sw_sync_pt
From: Gustavo Padovan
As we moved value storage to sync_timeline and fence those two structs
became useless and can be removed now.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c| 24 +++-
drivers/staging/android/sw_sync.h| 24 ++--
drivers/staging/android/sync_debug.c | 12 ++--
3 files changed, 19 insertions(+), 41 deletions(-)
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
index c5e92c6..461dbd9 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -25,31 +25,21 @@
#include "sw_sync.h"
-struct fence *sw_sync_pt_create(struct sw_sync_timeline *obj, u32 value)
+struct fence *sw_sync_pt_create(struct sync_timeline *obj, u32 value)
{
- struct sw_sync_pt *pt;
-
- pt = (struct sw_sync_pt *)
- sync_pt_create(&obj->obj, sizeof(struct sw_sync_pt), value);
-
- pt->value = value;
-
- return (struct fence *)pt;
+ return sync_pt_create(obj, sizeof(struct fence), value);
}
EXPORT_SYMBOL(sw_sync_pt_create);
-struct sw_sync_timeline *sw_sync_timeline_create(const char *name)
+struct sync_timeline *sw_sync_timeline_create(const char *name)
{
- struct sw_sync_timeline *obj = (struct sw_sync_timeline *)
- sync_timeline_create(sizeof(struct sw_sync_timeline),
-"sw_sync", name);
-
- return obj;
+ return sync_timeline_create(sizeof(struct sync_timeline),
+ "sw_sync", name);
}
EXPORT_SYMBOL(sw_sync_timeline_create);
-void sw_sync_timeline_inc(struct sw_sync_timeline *obj, u32 inc)
+void sw_sync_timeline_inc(struct sync_timeline *obj, u32 inc)
{
- sync_timeline_signal(&obj->obj, inc);
+ sync_timeline_signal(obj, inc);
}
EXPORT_SYMBOL(sw_sync_timeline_inc);
diff --git a/drivers/staging/android/sw_sync.h
b/drivers/staging/android/sw_sync.h
index e18667b..9f26c62 100644
--- a/drivers/staging/android/sw_sync.h
+++ b/drivers/staging/android/sw_sync.h
@@ -22,34 +22,22 @@
#include "sync.h"
#include "uapi/sw_sync.h"
-struct sw_sync_timeline {
- struct sync_timeline obj;
-
- u32 value;
-};
-
-struct sw_sync_pt {
- struct fencept;
-
- u32 value;
-};
-
#if IS_ENABLED(CONFIG_SW_SYNC)
-struct sw_sync_timeline *sw_sync_timeline_create(const char *name);
-void sw_sync_timeline_inc(struct sw_sync_timeline *obj, u32 inc);
+struct sync_timeline *sw_sync_timeline_create(const char *name);
+void sw_sync_timeline_inc(struct sync_timeline *obj, u32 inc);
-struct fence *sw_sync_pt_create(struct sw_sync_timeline *obj, u32 value);
+struct fence *sw_sync_pt_create(struct sync_timeline *obj, u32 value);
#else
-static inline struct sw_sync_timeline *sw_sync_timeline_create(const char
*name)
+static inline struct sync_timeline *sw_sync_timeline_create(const char *name)
{
return NULL;
}
-static inline void sw_sync_timeline_inc(struct sw_sync_timeline *obj, u32 inc)
+static inline void sw_sync_timeline_inc(struct sync_timeline *obj, u32 inc)
{
}
-static inline struct fence *sw_sync_pt_create(struct sw_sync_timeline *obj,
+static inline struct fence *sw_sync_pt_create(struct sync_timeline *obj,
u32 value)
{
return NULL;
diff --git a/drivers/staging/android/sync_debug.c
b/drivers/staging/android/sync_debug.c
index 26ba9e86..e984955 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -211,7 +211,7 @@ static const struct file_operations sync_info_debugfs_fops
= {
/* opening sw_sync create a new sync obj */
static int sw_sync_debugfs_open(struct inode *inode, struct file *file)
{
- struct sw_sync_timeline *obj;
+ struct sync_timeline *obj;
char task_comm[TASK_COMM_LEN];
get_task_comm(task_comm, current);
@@ -227,13 +227,13 @@ static int sw_sync_debugfs_open(struct inode *inode,
struct file *file)
static int sw_sync_debugfs_release(struct inode *inode, struct file *file)
{
- struct sw_sync_timeline *obj = file->private_data;
+ struct sync_timeline *obj = file->private_data;
- sync_timeline_destroy(&obj->obj);
+ sync_timeline_destroy(obj);
return 0;
}
-static long sw_sync_ioctl_create_fence(struct sw_sync_timeline *obj,
+static long sw_sync_ioctl_create_fence(struct sync_timeline *obj,
unsigned long arg)
{
int fd = get_unused_fd_flags(O_CLOEXEC);
@@ -280,7 +280,7 @@ err:
return err;
}
-static long sw_sync_ioctl_inc(struct sw_sync_timeline *obj, unsigned long arg)
+static long sw_sync_ioctl_inc(struct sync_timeline *obj, unsigned long arg)
{
u32 value;
@@ -295,7 +295,7 @@ static long sw_sync_ioctl_inc(struct sw_sync_timeline *obj,
unsigned long arg)
static long sw_sync_ioctl(struct file *file, unsigned int
[PATCH v2 07/11] staging/android: remove sw_sync.[ch] files
From: Gustavo Padovan
We can glue the sw_sync file operations directly on the sync framework
without the need to pass through sw_sync wrappers.
It only builds sw_sync debugfs file support if CONFIG_SW_SYNC is enabled.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/Makefile | 1 -
drivers/staging/android/sw_sync.c| 45 --
drivers/staging/android/sw_sync.h| 47
drivers/staging/android/sync_debug.c | 17 ++---
4 files changed, 13 insertions(+), 97 deletions(-)
delete mode 100644 drivers/staging/android/sw_sync.c
delete mode 100644 drivers/staging/android/sw_sync.h
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index c7b6c99..2c1d97f 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -7,4 +7,3 @@ obj-$(CONFIG_ANDROID_TIMED_OUTPUT) += timed_output.o
obj-$(CONFIG_ANDROID_TIMED_GPIO) += timed_gpio.o
obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
obj-$(CONFIG_SYNC) += sync.o sync_debug.o
-obj-$(CONFIG_SW_SYNC) += sw_sync.o
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
deleted file mode 100644
index 461dbd9..000
--- a/drivers/staging/android/sw_sync.c
+++ /dev/null
@@ -1,45 +0,0 @@
-/*
- * drivers/base/sw_sync.c
- *
- * Copyright (C) 2012 Google, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "sw_sync.h"
-
-struct fence *sw_sync_pt_create(struct sync_timeline *obj, u32 value)
-{
- return sync_pt_create(obj, sizeof(struct fence), value);
-}
-EXPORT_SYMBOL(sw_sync_pt_create);
-
-struct sync_timeline *sw_sync_timeline_create(const char *name)
-{
- return sync_timeline_create(sizeof(struct sync_timeline),
- "sw_sync", name);
-}
-EXPORT_SYMBOL(sw_sync_timeline_create);
-
-void sw_sync_timeline_inc(struct sync_timeline *obj, u32 inc)
-{
- sync_timeline_signal(obj, inc);
-}
-EXPORT_SYMBOL(sw_sync_timeline_inc);
diff --git a/drivers/staging/android/sw_sync.h
b/drivers/staging/android/sw_sync.h
deleted file mode 100644
index 9f26c62..000
--- a/drivers/staging/android/sw_sync.h
+++ /dev/null
@@ -1,47 +0,0 @@
-/*
- * include/linux/sw_sync.h
- *
- * Copyright (C) 2012 Google, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#ifndef _LINUX_SW_SYNC_H
-#define _LINUX_SW_SYNC_H
-
-#include
-#include
-#include "sync.h"
-#include "uapi/sw_sync.h"
-
-#if IS_ENABLED(CONFIG_SW_SYNC)
-struct sync_timeline *sw_sync_timeline_create(const char *name);
-void sw_sync_timeline_inc(struct sync_timeline *obj, u32 inc);
-
-struct fence *sw_sync_pt_create(struct sync_timeline *obj, u32 value);
-#else
-static inline struct sync_timeline *sw_sync_timeline_create(const char *name)
-{
- return NULL;
-}
-
-static inline void sw_sync_timeline_inc(struct sync_timeline *obj, u32 inc)
-{
-}
-
-static inline struct fence *sw_sync_pt_create(struct sync_timeline *obj,
- u32 value)
-{
- return NULL;
-}
-#endif /* IS_ENABLED(CONFIG_SW_SYNC) */
-
-#endif /* _LINUX_SW_SYNC_H */
diff --git a/drivers/staging/android/sync_debug.c
b/drivers/staging/android/sync_debug.c
index e984955..9312e6f 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -28,7 +28,11 @@
#include
#include
#include
-#include "sw_sync.h"
+#include
+#include
+
+#include "uapi/sw_sync.h"
+#include "sync.h"
#ifdef CONFIG_DEBUG_FS
@@ -202,6 +206,7 @@ static const struct file_operations sync_info_debugfs_fops
= {
.release= single_release,
};
+#if IS_ENABLED(CONFIG_SW_SYNC)
/*
* *WARNING*
*
@@ -216,7 +221,7 @@ static int sw_sync_debugfs_open(struct inode *inode, struct
file *file)
get_task_comm(task_comm, current);
- obj = sw_sync_timeline_create(task_comm);
+ obj = sync_timeline_create(sizeof(*obj), "sw_sync", task_comm);
if (!obj)
[PATCH v2 08/11] staging/android: rename android_fence to timeline_fence
From: Gustavo Padovan
We are moving out of staging/adroid so rename it to a name that is not
related to android anymore.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 07fe995..ea816dd 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -28,7 +28,7 @@
#define CREATE_TRACE_POINTS
#include "trace/sync.h"
-static const struct fence_ops android_fence_ops;
+static const struct fence_ops timeline_fence_ops;
struct sync_timeline *sync_timeline_create(int size, const char *drv_name,
const char *name)
@@ -126,7 +126,7 @@ struct fence *sync_pt_create(struct sync_timeline *obj, int
size,
spin_lock_irqsave(&obj->child_list_lock, flags);
sync_timeline_get(obj);
- fence_init(fence, &android_fence_ops, &obj->child_list_lock,
+ fence_init(fence, &timeline_fence_ops, &obj->child_list_lock,
obj->context, value);
list_add_tail(&fence->child_list, &obj->child_list_head);
INIT_LIST_HEAD(&fence->active_list);
@@ -135,21 +135,21 @@ struct fence *sync_pt_create(struct sync_timeline *obj,
int size,
}
EXPORT_SYMBOL(sync_pt_create);
-static const char *android_fence_get_driver_name(struct fence *fence)
+static const char *timeline_fence_get_driver_name(struct fence *fence)
{
struct sync_timeline *parent = fence_parent(fence);
return parent->drv_name;
}
-static const char *android_fence_get_timeline_name(struct fence *fence)
+static const char *timeline_fence_get_timeline_name(struct fence *fence)
{
struct sync_timeline *parent = fence_parent(fence);
return parent->name;
}
-static void android_fence_release(struct fence *fence)
+static void timeline_fence_release(struct fence *fence)
{
struct sync_timeline *parent = fence_parent(fence);
unsigned long flags;
@@ -164,25 +164,25 @@ static void android_fence_release(struct fence *fence)
fence_free(fence);
}
-static bool android_fence_signaled(struct fence *fence)
+static bool timeline_fence_signaled(struct fence *fence)
{
struct sync_timeline *parent = fence_parent(fence);
return (fence->seqno > parent->value) ? false : true;
}
-static bool android_fence_enable_signaling(struct fence *fence)
+static bool timeline_fence_enable_signaling(struct fence *fence)
{
struct sync_timeline *parent = fence_parent(fence);
- if (android_fence_signaled(fence))
+ if (timeline_fence_signaled(fence))
return false;
list_add_tail(&fence->active_list, &parent->active_list_head);
return true;
}
-static int android_fence_fill_driver_data(struct fence *fence,
+static int timeline_fence_fill_driver_data(struct fence *fence,
void *data, int size)
{
if (size < sizeof(fence->seqno))
@@ -193,13 +193,13 @@ static int android_fence_fill_driver_data(struct fence
*fence,
return sizeof(fence->seqno);
}
-static void android_fence_value_str(struct fence *fence,
+static void timeline_fence_value_str(struct fence *fence,
char *str, int size)
{
snprintf(str, size, "%d", fence->seqno);
}
-static void android_fence_timeline_value_str(struct fence *fence,
+static void timeline_fence_timeline_value_str(struct fence *fence,
char *str, int size)
{
struct sync_timeline *parent = fence_parent(fence);
@@ -207,15 +207,15 @@ static void android_fence_timeline_value_str(struct fence
*fence,
snprintf(str, size, "%d", parent->value);
}
-static const struct fence_ops android_fence_ops = {
- .get_driver_name = android_fence_get_driver_name,
- .get_timeline_name = android_fence_get_timeline_name,
- .enable_signaling = android_fence_enable_signaling,
- .signaled = android_fence_signaled,
+static const struct fence_ops timeline_fence_ops = {
+ .get_driver_name = timeline_fence_get_driver_name,
+ .get_timeline_name = timeline_fence_get_timeline_name,
+ .enable_signaling = timeline_fence_enable_signaling,
+ .signaled = timeline_fence_signaled,
.wait = fence_default_wait,
- .release = android_fence_release,
- .fill_driver_data = android_fence_fill_driver_data,
- .fence_value_str = android_fence_value_str,
- .timeline_value_str = android_fence_timeline_value_str,
+ .release = timeline_fence_release,
+ .fill_driver_data = timeline_fence_fill_driver_data,
+ .fence_value_str = timeline_fence_value_str,
+ .timeline_value_str = timeline_fence_timeline_value_str,
};
--
2.5.0
[PATCH v2 09/11] dma-buf/sync_timeline: de-stage sync_timeline
From: Gustavo Padovan
De-stage the remaining bit of sync framework: sync_timeline and sw_sync
plus some debugging routines.
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/Kconfig| 10 +++
drivers/dma-buf/Makefile | 3 +-
.../{staging/android/uapi => dma-buf}/sw_sync.h| 0
drivers/{staging/android => dma-buf}/sync_debug.c | 5 ++--
drivers/dma-buf/sync_debug.h | 35 ++
.../android/sync.c => dma-buf/sync_timeline.c} | 7 +++--
drivers/staging/android/Kconfig| 20 -
.../sync.h => include/linux/sync_timeline.h| 24 +++
.../sync.h => include/trace/events/sync_timeline.h | 9 +++---
9 files changed, 62 insertions(+), 51 deletions(-)
rename drivers/{staging/android/uapi => dma-buf}/sw_sync.h (100%)
rename drivers/{staging/android => dma-buf}/sync_debug.c (99%)
create mode 100644 drivers/dma-buf/sync_debug.h
rename drivers/{staging/android/sync.c => dma-buf/sync_timeline.c} (98%)
rename drivers/staging/android/sync.h => include/linux/sync_timeline.h (85%)
rename drivers/staging/android/trace/sync.h =>
include/trace/events/sync_timeline.h (73%)
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 9824bc4..73df024 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -8,4 +8,14 @@ config SYNC_FILE
---help---
This option enables the fence framework synchronization to export
sync_files to userspace that can represent one or more fences.
+
+config SW_SYNC
+ bool "Software synchronization objects"
+ default n
+ depends on SYNC_FILE
+ ---help---
+ A sync object driver that uses a 32bit counter to coordinate
+ synchronization. Useful when there is no hardware primitive backing
+ the synchronization.
+
endmenu
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 4a424ec..78d8ec4 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,2 +1,3 @@
obj-y := dma-buf.o fence.o reservation.o seqno-fence.o
-obj-$(CONFIG_SYNC_FILE)+= sync_file.o
+obj-$(CONFIG_SYNC_FILE)+= sync_file.o sync_debug.o
+obj-$(CONFIG_SW_SYNC) += sync_timeline.o
diff --git a/drivers/staging/android/uapi/sw_sync.h b/drivers/dma-buf/sw_sync.h
similarity index 100%
rename from drivers/staging/android/uapi/sw_sync.h
rename to drivers/dma-buf/sw_sync.h
diff --git a/drivers/staging/android/sync_debug.c b/drivers/dma-buf/sync_debug.c
similarity index 99%
rename from drivers/staging/android/sync_debug.c
rename to drivers/dma-buf/sync_debug.c
index 9312e6f..7da9ff5 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -30,9 +30,10 @@
#include
#include
#include
+#include
-#include "uapi/sw_sync.h"
-#include "sync.h"
+#include "sync_debug.h"
+#include "sw_sync.h"
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
new file mode 100644
index 000..5b71685
--- /dev/null
+++ b/drivers/dma-buf/sync_debug.h
@@ -0,0 +1,35 @@
+/*
+ * drivers/dma-buf/sync_debug.h
+ *
+ * Copyright (C) 2012 Google, Inc.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _LINUX_SYNC_DEBUG_H
+#define _LINUX_SYNC_DEBUG_H
+
+#include
+#include
+#include
+
+#ifdef CONFIG_DEBUG_FS
+void sync_timeline_debug_add(struct sync_timeline *obj);
+void sync_timeline_debug_remove(struct sync_timeline *obj);
+void sync_file_debug_add(struct sync_file *sync_file);
+void sync_file_debug_remove(struct sync_file *sync_file);
+void sync_dump(void);
+
+#else
+#define sync_timeline_debug_add(obj)
+#define sync_timeline_debug_remove(obj)
+#define sync_file_debug_add(fence)
+#define sync_file_debug_remove(fence)
+#define sync_dump()
+#endif
+
+#endif /* _LINUX_SYNC_DEBUG_H */
diff --git a/drivers/staging/android/sync.c b/drivers/dma-buf/sync_timeline.c
similarity index 98%
rename from drivers/staging/android/sync.c
rename to drivers/dma-buf/sync_timeline.c
index ea816dd..b354b0c 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/dma-buf/sync_timeline.c
@@ -22,11 +22,12 @@
#include
#include
#include
-
-#include "sync.h"
+#include
#define CREATE_TRACE_POINTS
-#include "trace/sync.h"
+#include
+
+#include "sync_debug.h"
static const struct fence_ops timeline_fence_ops;
diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 2756988..4b18fee 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -38,26 +38,6 @@ config ANDROID_LOW_MEMORY_KILLER
scripts (/init.rc), and it defines priority values with minimum free
memory size
for each priority.
-conf
[PATCH v2 10/11] dma-buf/sync_file: bring debug back to sync file
From: Gustavo Padovan
Enable reports of sync_files through /sync/info
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/sync_file.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 92474dd..aa1215d 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -29,6 +29,8 @@
#define CREATE_TRACE_POINTS
#include
+#include "sync_debug.h"
+
static const struct file_operations sync_file_fops;
static struct sync_file *sync_file_alloc(int size, const char *name)
@@ -87,6 +89,8 @@ struct sync_file *sync_file_create(const char *name, struct
fence *fence)
fence_check_cb_func))
atomic_dec(&sync_file->status);
+ sync_file_debug_add(sync_file);
+
return sync_file;
}
EXPORT_SYMBOL(sync_file_create);
@@ -188,6 +192,7 @@ struct sync_file *sync_file_merge(const char *name,
atomic_sub(num_fences - i, &sync_file->status);
sync_file->num_fences = i;
+ sync_file_debug_add(sync_file);
return sync_file;
}
EXPORT_SYMBOL(sync_file_merge);
@@ -246,6 +251,8 @@ static int sync_file_release(struct inode *inode, struct
file *file)
{
struct sync_file *sync_file = file->private_data;
+ sync_file_debug_remove(sync_file);
+
kref_put(&sync_file->kref, sync_file_free);
return 0;
}
--
2.5.0
[PATCH v2 11/11] dma-buf/sync_file: bring sync_dump() back
From: Gustavo Padovan
During the de-stage of sync framework it was easy to keep sync_dump() out
to avoid an early de-stage of all debug code, but now that sync_debug.c
was de-staged bring sync_dump() back.
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/sync_file.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index aa1215d..fd7e3b9 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -218,15 +218,19 @@ int sync_file_wait(struct sync_file *sync_file, long
timeout)
if (ret < 0) {
return ret;
} else if (ret == 0) {
- if (timeout)
+ if (timeout) {
pr_info("sync_file timeout on [%p] after %dms\n",
sync_file, jiffies_to_msecs(timeout));
+ sync_dump();
+ }
return -ETIME;
}
ret = atomic_read(&sync_file->status);
- if (ret)
+ if (ret) {
pr_info("sync_file error %ld on [%p]\n", ret, sync_file);
+ sync_dump();
+ }
return ret;
}
--
2.5.0
Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
Hi, On 27 January 2016 at 13:28, Emil Velikov wrote: > On 27 January 2016 at 11:42, Daniel Stone wrote: >> On 27 January 2016 at 09:38, Daniel Vetter wrote: >>> On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: I've been procrastinating^Wwaiting on some upstream changes to land and with those in place I'll update the Makefile to import things properly. >>> >>> Yeah, we should have some scripts in libdrm that runs make >>> headers_install, copies over the latest generated uapi headers for drm and >>> then creates a commit with the sha1 it was generated from. Maybe even a >>> rule that the sha1 has to be from Dave's drm-next. >> >> Yeah, it's certainly doable, once some kernel-internal details are >> shuffled out of uapi/drm/drm_mode.h. > What do you have in mind - DRM_MODE_PICTURE_ASPECT_* ? I'm thinking > more that we should bring back DRM_MODE_OBJECT_* as it breaks libdrm > and maybe other userspace. > > Feel free to let me know here or in the patch I just sent (didn't > realise and I Cc'd your collabora email). More the *_FLAGS enums: 12:26 PM daniels, what kind of kernel internals in include/uapi/drm/drm_mode.h? 12:26 PM danvet: DRM_MODE_FB_DIRTY_FLAGS, DRM_MODE_CURSOR_FLAGS, DRM_MODE_PAGE_FLIP_FLAGS, DRM_MODE_ATOMIC_FLAGS 12:27 PM danvet: not strictly kernel-internal per se, but does encourage userspace to do stupid validation on a potentially outdated (or too-new; either way the result is incorrect) set of flags 12:27 PM hm well, don't mind those too much really 12:27 PM better than keeping them separate at least 12:28 PM why not just move them into the kernel and leave userspace to work it out for itself? 12:29 PM i can't see the space for userspace using them at all; if you're needing to test for specific flags, then do that, but the only case for exposing the _FLAGS mask is to validate that you're not passing 'unsupported' flags (not 'flags i don't know about', since just use individual flags yourself for that, but 'flags the kernel doesn't know about'), which is a) pointless, and b) likely to be incorrect Cheers, Daniel
Trying nouveau reclocking
Hi,
2016-01-27 14:26 keltezéssel, Ilia Mirkin Ãrta:
> The warn in question is
>
> static u32
> nvkm_mc_intr_mask(struct nvkm_mc *mc)
> {
> u32 intr = mc->func->intr_mask(mc);
> if (WARN_ON_ONCE(intr == 0x))
> intr = 0; /* likely fallen off the bus */
> return intr;
> }
>
> Which is basically a sign of total death. Is this new with 4.5-rc1, or
> is this the first time you've tried reclocking this chip?
this was the first time I tried reclocking. When the GPU is idle,
reclocking is successful and the same WebGL app runs a lot smoother.
BTW, the machine I tried was a Zotac ZBOX MiniPC ID41 series.
I also have a question related to reclocking on other chips.
Zotac ZBOX ID84 series:
# lspci -s 02:00.0
02:00.0 VGA compatible controller: NVIDIA Corporation GF119M [GeForce GT 520M]
(rev a1)
# lspci -s 02:00.0 -n
02:00.0 0300: 10de:1050 (rev a1)
Zotac ZBOX ID86 series:
# lspci -s 02:00.0
02:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610]
(rev a1)
# lspci -s 02:00.0 -n
02:00.0 0300: 10de:104a (rev a1)
All three boxes are out of production now, but we're using about
20,000 (really, about twenty thousand) in total of them at my company.
Nouveau supports them just fine, the main application is video decoding/playing
and it works very well for the supported codecs reported via vdpauinfo.
Is there a known roadmap to support reclocking on these latter two?
Thanks,
Zoltán Böszörményi
>
> -ilia
>
>
> On Wed, Jan 27, 2016 at 6:59 AM, Boszormenyi Zoltan wrote:
>> Hi,
>>
>> I was trying to use re-clocking with nouveau in 4.5.0-rc1 with:
>>
>> # echo "0f" >/sys/kernel/debug/dri/0/pstate
>>
>> while Chromium with a WebGL app already running. (www.playmapscube.com)
>>
>> The video chip in question is:
>>
>> 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2)
>>
>> or in numbers:
>>
>> 03:00.0 0300: 10de:0a64 (rev a2)
>>
>> It is an integrated chip on the mainboard.
>>
>> The result was:
>>
>> [ 77.531009] [ cut here ]
>> [ 77.531009] WARNING: CPU: 3 PID: 405 at
>> drivers/gpu/drm/nouveau/nvkm/subdev/mc/base.c:51 nvkm_mc_intr+0x102/0x110
>> [nouveau]()
>> [ 77.531009] Modules linked in: tun ums_realtek uas usb_storage joydev
>> input_leds
>> hid_generic usbhid hid cdc_acm snd_hda_codec_hdmi nouveau arc4 mxm_wmi wmi
>> ath9k
>> i2c_algo_bit iTCO_wdt drm_kms_helper iTCO_vendor_support gpio_ich
>> ath9k_common
>> snd_hda_codec_realtek ttm snd_hda_codec_generic ath9k_hw drm snd_hda_intel
>> ath
>> snd_hda_codec mac80211 snd_hwdep syscopyarea lpc_ich snd_hda_core
>> sysfillrect mfd_core
>> sysimgblt fb_sys_fops coretemp snd_pcm serio_raw i2c_i801 xhci_pci pcspkr
>> xhci_hcd
>> cfg80211 r8169 snd_timer i2c_core snd mii ehci_pci uhci_hcd rfkill ehci_hcd
>> soundcore
>> acpi_cpufreq xt_limit xt_multiport xt_recent ip6table_filter xt_conntrack
>> ip6table_nat
>> iptable_nat nf_conntrack_ipv6 nf_nat_ipv4 nf_defrag_ipv6 nf_conntrack_ipv4
>> nf_nat_ipv6
>> nf_defrag_ipv4 nf_nat xt_connmark nf_conntrack ip6_tables
>> [ 77.531009] iptable_mangle
>> [ 77.531009] CPU: 3 PID: 405 Comm: Xorg.bin Not tainted 4.5.0-rc1 #1
>> [ 77.531009] Hardware name: To Be Filled By O.E.M. To Be Filled By
>> O.E.M./To Be Filled
>> By O.E.M., BIOS 080016 05/05/2011
>> [ 77.531009] a053b6f0 88007fd83cd8 80761604
>>
>> [ 77.531009] 88007fd83d10 8048e7a2 88007c0ef480
>> 880037838840
>> [ 77.531009] 88007a4b3800 a04fa9a0
>> 88007fd83d20
>> [ 77.531009] Call Trace:
>> [ 77.531009][] dump_stack+0x44/0x60
>> [ 77.531009] [] warn_slowpath_common+0x82/0xc0
>> [ 77.531009] [] warn_slowpath_null+0x1a/0x20
>> [ 77.531009] [] nvkm_mc_intr+0x102/0x110 [nouveau]
>> [ 77.531009] [] nvkm_pci_intr+0x44/0x70 [nouveau]
>> [ 77.531009] [] handle_irq_event_percpu+0x75/0x180
>> [ 77.531009] [] handle_irq_event+0x3b/0x60
>> [ 77.531009] [] handle_edge_irq+0x74/0x130
>> [ 77.531009] [] handle_irq+0x1a/0x30
>> [ 77.531009] [] do_IRQ+0x4b/0xd0
>> [ 77.531009] [] common_interrupt+0x82/0x82
>> [ 77.531009] [] ? __do_softirq+0x7b/0x260
>> [ 77.531009] [] irq_exit+0xb1/0xc0
>> [ 77.531009] [] smp_apic_timer_interrupt+0x42/0x50
>> [ 77.531009] [] apic_timer_interrupt+0x82/0x90
>> [ 77.531009][] ? nouveau_fence_emit+0xf1/0x1a0
>> [nouveau]
>> [ 77.531009] [] ? nouveau_fence_emit+0x13f/0x1a0
>> [nouveau]
>> [ 77.531009] [] nouveau_fence_new+0x59/0xa0 [nouveau]
>> [ 77.531009] [] nouveau_gem_ioctl_pushbuf+0xeb5/0x1730
>> [nouveau]
>> [ 77.531009] [] drm_ioctl+0x152/0x540 [drm]
>> [ 77.531009] [] ? nouveau_gem_ioctl_new+0x1c0/0x1c0
>> [nouveau]
>> [ 77.531009] [] ? fpu__activate_curr+0x15/0x20
>> [ 77.531009] [] nouveau_drm_ioctl+0x68/0xc0 [nouveau]
>> [ 77.531009] [] do_vfs_ioctl+0x92/0x580
>> [ 77.531009] [] ? security_file_ioctl+0x43/0x60
>> [ 77.
[PATCH libdrm] Update/fix the {copy,commit}-headers targets
On Wed, Jan 27, 2016 at 01:23:11PM +, Emil Velikov wrote: > As some headers do not reside in include/drm we need to tweak our rules, > and exclude headers that shouldn't be distributed [XXX: clarify why ?]. > > To avoid the extra magic of diving into the kernel tree running `make > headers_install', just sed out the only reason why we need it - __user. > > Cc: Alex Deucher > Cc: Michel Dänzer > Cc: Ben Skeggs > Cc: Dave Airlie > Cc: Daniel Stone > Cc: Daniel Vetter > Cc: Inki Dae > Cc: Rob Clark > Cc: Tomi Valkeinen > Cc: Daniel Kurtz > Signed-off-by: Emil Velikov > --- > > Gents, > As one runs `make copy-headers' we get a massive diff stat (+1500/-800) > and a handful of issues gets pointed out. > Please let me know of your prefered solution (regardless if one will get > to it soon) and if we should consider it a blocker (B) or not (N). > > Thanks > Emil > > - (N) Header license miss-match - omap, msm, exynos. Update the kernel > ones ? > > - (N) Broken compat ioctls - exynos (and the UMS drivers) - using > unsigned int as opposed to _u32/64. Considering they're 32bit only, we > can get away with 'breaking' the ABI and using the proper ones ? > > - (N, keep local for now) C++ compat - libdrm has a hack/workaround > (virtual is a keyword in C++), which I'd like us to upstream plus some > extern C wrappers. > > - (?) Missing UMS symbols - see _DRM_GEM > > - (?) Non C89 compliant (see DRM_DRAWABLE_CLIPRECTS) - do we still > want/need that ? > > - (B) Using include as opposed to include "..." - drm.h, > nouveau_drm.h. Should be fixed in kernel. > > - (N) ABI 'break' > + drm - struct drm_mode_get_connector extra pad > + tegra - struct drm_tegra_gem_mmap extra pad > > - (B) API break > + drm - missing DRM_MODE_OBJECT_* > + nouveau - missing (gs)etparam - both structs and macros. everything > else is fine/unused. > + radeon - RADEON_TILING_R600_NO_SCANOUT, CIK_TILE_MODE_COLOR_2D* and > CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_* - quick grep shows no users > + omap - struct drm_omap_get_base, DRM_OMAP_GET_BASE + IOCTL > > - (N) (unneeded?) API additions - nouveau's DRM_IOCTL_NOUVEAU_GEM_* > > - (N) __KERNEL__ condiditionals. Is it really an issue - sure if looks > a bit spurious but that's about it. > > > Makefile.am | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/Makefile.am b/Makefile.am > index ca41508..6c71d3a 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -126,7 +126,14 @@ endif > > copy-headers : > cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/ > + sed -i "s/__user //g" $(top_srcdir)/include/drm/*.h > + mv $(top_srcdir)/include/drm/exynos_drm.h $(top_srcdir)/exynos/ > + mv $(top_srcdir)/include/drm/msm_drm.h $(top_srcdir)/freedreno/msm/ > + mv $(top_srcdir)/include/drm/omap_drm.h $(top_srcdir)/omap/ > + rm $(top_srcdir)/include/drm/armada_drm.h > + rm $(top_srcdir)/include/drm/etnaviv_drm.h > + rm $(top_srcdir)/include/drm/i810_drm.h > + rm $(top_srcdir)/include/drm/vc4_drm.h You can't copy headers directly. First you need to generate them in the kernel sources: $ make headers_install Then you can copy them from usr/include/* That should at least get rid of the __KERNEL__ stuff. Then any serious issues should be fixed in the upstream kernel first. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH libdrm] Update/fix the {copy,commit}-headers targets
On 27 January 2016 at 13:50, Daniel Vetter wrote: > On Wed, Jan 27, 2016 at 01:23:11PM +, Emil Velikov wrote: >> As some headers do not reside in include/drm we need to tweak our rules, >> and exclude headers that shouldn't be distributed [XXX: clarify why ?]. >> >> To avoid the extra magic of diving into the kernel tree running `make >> headers_install', just sed out the only reason why we need it - __user. >> >> Cc: Alex Deucher >> Cc: Michel Dänzer >> Cc: Ben Skeggs >> Cc: Dave Airlie >> Cc: Daniel Stone >> Cc: Daniel Vetter >> Cc: Inki Dae >> Cc: Rob Clark >> Cc: Tomi Valkeinen >> Cc: Daniel Kurtz >> Signed-off-by: Emil Velikov >> --- >> >> Gents, >> As one runs `make copy-headers' we get a massive diff stat (+1500/-800) >> and a handful of issues gets pointed out. >> Please let me know of your prefered solution (regardless if one will get >> to it soon) and if we should consider it a blocker (B) or not (N). >> >> Thanks >> Emil >> >> - (N) Header license miss-match - omap, msm, exynos. Update the kernel >> ones ? >> >> - (N) Broken compat ioctls - exynos (and the UMS drivers) - using >> unsigned int as opposed to _u32/64. Considering they're 32bit only, we >> can get away with 'breaking' the ABI and using the proper ones ? >> >> - (N, keep local for now) C++ compat - libdrm has a hack/workaround >> (virtual is a keyword in C++), which I'd like us to upstream plus some >> extern C wrappers. >> >> - (?) Missing UMS symbols - see _DRM_GEM >> >> - (?) Non C89 compliant (see DRM_DRAWABLE_CLIPRECTS) - do we still >> want/need that ? >> >> - (B) Using include as opposed to include "..." - drm.h, >> nouveau_drm.h. Should be fixed in kernel. >> >> - (N) ABI 'break' >> + drm - struct drm_mode_get_connector extra pad >> + tegra - struct drm_tegra_gem_mmap extra pad >> >> - (B) API break >> + drm - missing DRM_MODE_OBJECT_* >> + nouveau - missing (gs)etparam - both structs and macros. everything >> else is fine/unused. >> + radeon - RADEON_TILING_R600_NO_SCANOUT, CIK_TILE_MODE_COLOR_2D* and >> CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_* - quick grep shows no users >> + omap - struct drm_omap_get_base, DRM_OMAP_GET_BASE + IOCTL >> >> - (N) (unneeded?) API additions - nouveau's DRM_IOCTL_NOUVEAU_GEM_* >> >> - (N) __KERNEL__ condiditionals. Is it really an issue - sure if looks >> a bit spurious but that's about it. >> >> >> Makefile.am | 9 - >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/Makefile.am b/Makefile.am >> index ca41508..6c71d3a 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -126,7 +126,14 @@ endif >> >> copy-headers : >> cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/ >> + sed -i "s/__user //g" $(top_srcdir)/include/drm/*.h >> + mv $(top_srcdir)/include/drm/exynos_drm.h $(top_srcdir)/exynos/ >> + mv $(top_srcdir)/include/drm/msm_drm.h $(top_srcdir)/freedreno/msm/ >> + mv $(top_srcdir)/include/drm/omap_drm.h $(top_srcdir)/omap/ >> + rm $(top_srcdir)/include/drm/armada_drm.h >> + rm $(top_srcdir)/include/drm/etnaviv_drm.h >> + rm $(top_srcdir)/include/drm/i810_drm.h >> + rm $(top_srcdir)/include/drm/vc4_drm.h > > You can't copy headers directly. First you need to generate them in the > kernel sources: > > $ make headers_install > > Then you can copy them from usr/include/* > > That should at least get rid of the __KERNEL__ stuff. Then any serious > issues should be fixed in the upstream kernel first. I agree that copying the headers isn't that good of an idea. Then again as that causes zero problems - it brings in __KERNEL__ and __user, latter of which sed out. So wouldn't it be better to focus on the serious issues first ? Of course, that doesn't mean we have to forget about this one :-P -Emil P.S. Diving into other projects and executing make foo/bar is frowned upon, normally.
[PATCH 3/3] vc4: Add headers and .pc files for VC4 userspace development.
On 27 January 2016 at 11:45, Daniel Stone wrote:
> Hi,
>
> On 26 January 2016 at 20:10, Eric Anholt wrote:
>> Ilia Mirkin writes:
>>> On Mon, Jan 25, 2016 at 2:27 PM, Eric Anholt wrote:
The headers were originally written in Mesa, imported to the kernel,
and improved upon in vc4-gpu-tools. These come from the v-g-t copies
and will replace the Mesa and v-g-t copies, and hopefully be used from
new tests in igt, as well.
Signed-off-by: Eric Anholt
---
--- /dev/null
+++ b/vc4/libdrm_vc4.pc.in
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libdrm_vc4
+Description: Userspace interface to vc4 kernel DRM services
+Version: @PACKAGE_VERSION@
+Requires: libdrm
+Libs: -L${libdir} -ldrm_intel
>>>
>>> This probably wants to be -ldrm_vc4? Or nothing if there's no such lib yet?
>>
>> Fixed to be -ldrm until we start building a libdrm_vc4.so.
>
> The Requires will take care of that, so you can just bin the entire
> 'Libs:' field until you need one:
>
In theory this will be sufficient, but Eric wasn't buying it [1] :'-(.
He's main consern (if I understood him correctly) is to stay
consistent with the existing libdrm_* providers, regardless if things
look a bit quirky.
-Emil
[1]
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2016-01-26
@13:22 onwards
Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
On 27 January 2016 at 13:31, Daniel Stone wrote: > Hi, > > On 27 January 2016 at 13:28, Emil Velikov wrote: >> On 27 January 2016 at 11:42, Daniel Stone wrote: >>> On 27 January 2016 at 09:38, Daniel Vetter wrote: On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: > I've been procrastinating^Wwaiting on some upstream changes to land > and with those in place I'll update the Makefile to import things > properly. Yeah, we should have some scripts in libdrm that runs make headers_install, copies over the latest generated uapi headers for drm and then creates a commit with the sha1 it was generated from. Maybe even a rule that the sha1 has to be from Dave's drm-next. >>> >>> Yeah, it's certainly doable, once some kernel-internal details are >>> shuffled out of uapi/drm/drm_mode.h. >> What do you have in mind - DRM_MODE_PICTURE_ASPECT_* ? I'm thinking >> more that we should bring back DRM_MODE_OBJECT_* as it breaks libdrm >> and maybe other userspace. >> >> Feel free to let me know here or in the patch I just sent (didn't >> realise and I Cc'd your collabora email). > > More the *_FLAGS enums: > 12:26 PM daniels, what kind of kernel internals in > include/uapi/drm/drm_mode.h? > 12:26 PM danvet: DRM_MODE_FB_DIRTY_FLAGS, > DRM_MODE_CURSOR_FLAGS, DRM_MODE_PAGE_FLIP_FLAGS, DRM_MODE_ATOMIC_FLAGS > 12:27 PM danvet: not strictly kernel-internal per se, but > does encourage userspace to do stupid validation on a potentially > outdated (or too-new; either way the result is incorrect) set of flags > 12:27 PM hm well, don't mind those too much really > 12:27 PM better than keeping them separate at least > 12:28 PM why not just move them into the kernel and leave > userspace to work it out for itself? > 12:29 PM i can't see the space for userspace using them at > all; if you're needing to test for specific flags, then do that, but > the only case for exposing the _FLAGS mask is to validate that you're > not passing 'unsupported' flags (not 'flags i don't know about', since > just use individual flags yourself for that, but 'flags the kernel > doesn't know about'), which is a) pointless, and b) likely to be > incorrect > Silly me should have checked the logs first. While I agree with your points I'm slightly worried that some of these are already part of the API. So as long as a volunteer goes through the history and checks that we don't break existing apps (libdrm, mesa, ddxen, xserver, wayland and other compositors, dvdhrm's kmscon and others?) I would love to see them do ;-) Thanks Emil
[PATCH 3/3] vc4: Add headers and .pc files for VC4 userspace development.
Hi, On 27 January 2016 at 14:16, Emil Velikov wrote: > On 27 January 2016 at 11:45, Daniel Stone wrote: >> The Requires will take care of that, so you can just bin the entire >> 'Libs:' field until you need one: >> > In theory this will be sufficient, but Eric wasn't buying it [1] :'-(. > He's main consern (if I understood him correctly) is to stay > consistent with the existing libdrm_* providers, regardless if things > look a bit quirky. I suspect he was missing that 'Requires' also pulls in the relevant flags from those libraries, so PKG_CHECK_MODULES(DRM_VC4, [libdrm-vc4]) is equivalent to PKG_CHECK_MODULES(DRM_VC4, [libdrm libdrm-vc4]), if libdrm-vc4.pc has 'Requires: libdrm'. Cheers, Daniel
Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
Hey, On 27 January 2016 at 14:23, Emil Velikov wrote: > On 27 January 2016 at 13:31, Daniel Stone wrote: >> On 27 January 2016 at 13:28, Emil Velikov >> wrote: >>> On 27 January 2016 at 11:42, Daniel Stone wrote: On 27 January 2016 at 09:38, Daniel Vetter wrote: > On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: >> I've been procrastinating^Wwaiting on some upstream changes to land >> and with those in place I'll update the Makefile to import things >> properly. > > Yeah, we should have some scripts in libdrm that runs make > headers_install, copies over the latest generated uapi headers for drm and > then creates a commit with the sha1 it was generated from. Maybe even a > rule that the sha1 has to be from Dave's drm-next. Yeah, it's certainly doable, once some kernel-internal details are shuffled out of uapi/drm/drm_mode.h. >>> What do you have in mind - DRM_MODE_PICTURE_ASPECT_* ? I'm thinking >>> more that we should bring back DRM_MODE_OBJECT_* as it breaks libdrm >>> and maybe other userspace. >>> >>> Feel free to let me know here or in the patch I just sent (didn't >>> realise and I Cc'd your collabora email). >> >> More the *_FLAGS enums: >> 12:26 PM daniels, what kind of kernel internals in >> include/uapi/drm/drm_mode.h? >> 12:26 PM danvet: DRM_MODE_FB_DIRTY_FLAGS, >> DRM_MODE_CURSOR_FLAGS, DRM_MODE_PAGE_FLIP_FLAGS, DRM_MODE_ATOMIC_FLAGS >> 12:27 PM danvet: not strictly kernel-internal per se, but >> does encourage userspace to do stupid validation on a potentially >> outdated (or too-new; either way the result is incorrect) set of flags >> 12:27 PM hm well, don't mind those too much really >> 12:27 PM better than keeping them separate at least >> 12:28 PM why not just move them into the kernel and leave >> userspace to work it out for itself? >> 12:29 PM i can't see the space for userspace using them at >> all; if you're needing to test for specific flags, then do that, but >> the only case for exposing the _FLAGS mask is to validate that you're >> not passing 'unsupported' flags (not 'flags i don't know about', since >> just use individual flags yourself for that, but 'flags the kernel >> doesn't know about'), which is a) pointless, and b) likely to be >> incorrect >> > Silly me should have checked the logs first. > > While I agree with your points I'm slightly worried that some of these > are already part of the API. So as long as a volunteer goes through > the history and checks that we don't break existing apps (libdrm, > mesa, ddxen, xserver, wayland and other compositors, dvdhrm's kmscon > and others?) I would love to see them do ;-) Well, not in libdrm Mesa, the X server or Intel driver, Weston, Mutter, or Chromium ... haven't checked kmscon, Enlightenment or other DDXes, but I'd be shocked if they did use it; if you're generating the pageflip flags in the first place yourself, why would you then need to filter them against a bitmask .,.. ? Cheers, Daniel
[PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file
Hey, Op 27-01-16 om 14:30 schreef Gustavo Padovan: > From: Gustavo Padovan > > sync_file is useful to connect one or more fences to the file. The file is > used by userspace to track fences. > > Signed-off-by: Gustavo Padovan > Is there a value in keeping the abi unchanged? If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read. Looking at the patch, it seems you kept SYNC_IOC_WAIT, won't it be better to remove it, and only support waiting with polling? The code for polling should already work. It's very unclear what format @driver_data has. I kept it for compatibility with android, but it's not clear to me how a userspace consumer would print it. Is there a usecase for this, or could it be removed from fence and sync_file? ~Maarten
[PATCH] drm/dp/mst: deallocate payload on port destruction
From: Mykola Lysenko
This is needed to properly deallocate port payload
after downstream branch get unplugged.
In order to do this unplugged MST topology should
be preserved, to find first alive port on path to
unplugged MST topology, and send payload deallocation
request to branch device of found port.
For this mstb and port kref's are used in reversed
order to track when port and branch memory could be
freed.
Added additional functions to find appropriate mstb
as described above.
Signed-off-by: Mykola Lysenko
Reviewed-by: Harry Wentland
---
drivers/gpu/drm/drm_dp_mst_topology.c | 91 ---
1 file changed, 83 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index fc589265068b..5662e68ecccd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -803,6 +803,18 @@ static struct drm_dp_mst_branch
*drm_dp_add_mst_branch_device(u8 lct, u8 *rad)
return mstb;
}
+static void drm_dp_free_mst_port(struct kref *kref);
+
+static void drm_dp_free_mst_branch_device(struct kref *kref)
+{
+ struct drm_dp_mst_branch *mstb = container_of(kref, struct
drm_dp_mst_branch, kref);
+ if (mstb->port_parent) {
+ if (list_empty(&mstb->port_parent->next))
+ kref_put(&mstb->port_parent->kref,
drm_dp_free_mst_port);
+ }
+ kfree(mstb);
+}
+
static void drm_dp_destroy_mst_branch_device(struct kref *kref)
{
struct drm_dp_mst_branch *mstb = container_of(kref, struct
drm_dp_mst_branch, kref);
@@ -810,6 +822,15 @@ static void drm_dp_destroy_mst_branch_device(struct kref
*kref)
bool wake_tx = false;
/*
+* init kref again to be used by ports to remove mst branch when it is
+* not needed anymore
+*/
+ kref_init(kref);
+
+ if (mstb->port_parent && list_empty(&mstb->port_parent->next))
+ kref_get(&mstb->port_parent->kref);
+
+ /*
* destroy all ports - don't need lock
* as there are no more references to the mst branch
* device at this point.
@@ -835,7 +856,8 @@ static void drm_dp_destroy_mst_branch_device(struct kref
*kref)
if (wake_tx)
wake_up(&mstb->mgr->tx_waitq);
- kfree(mstb);
+
+ kref_put(kref, drm_dp_free_mst_branch_device);
}
static void drm_dp_put_mst_branch_device(struct drm_dp_mst_branch *mstb)
@@ -883,6 +905,7 @@ static void drm_dp_destroy_port(struct kref *kref)
* from an EDID retrieval */
mutex_lock(&mgr->destroy_connector_lock);
+ kref_get(&port->parent->kref);
list_add(&port->next, &mgr->destroy_connector_list);
mutex_unlock(&mgr->destroy_connector_lock);
schedule_work(&mgr->destroy_connector_work);
@@ -1617,6 +1640,37 @@ static int drm_dp_send_enum_path_resources(struct
drm_dp_mst_topology_mgr *mgr,
return 0;
}
+static struct drm_dp_mst_port *drm_dp_get_last_connected_port_to_mstb(struct
drm_dp_mst_branch *mstb)
+{
+ if (!mstb->port_parent)
+ return NULL;
+
+ if (mstb->port_parent->mstb != mstb)
+ return mstb->port_parent;
+
+ return
drm_dp_get_last_connected_port_to_mstb(mstb->port_parent->parent);
+}
+
+static struct drm_dp_mst_branch
*drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
+struct
drm_dp_mst_branch *mstb,
+int
*port_num)
+{
+ struct drm_dp_mst_branch *rmstb = NULL;
+ struct drm_dp_mst_port *found_port;
+ mutex_lock(&mgr->lock);
+ if (mgr->mst_primary) {
+ found_port = drm_dp_get_last_connected_port_to_mstb(mstb);
+
+ if (found_port) {
+ rmstb = found_port->parent;
+ kref_get(&rmstb->kref);
+ *port_num = found_port->port_num;
+ }
+ }
+ mutex_unlock(&mgr->lock);
+ return rmstb;
+}
+
static int drm_dp_payload_send_msg(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port,
int id,
@@ -1624,13 +1678,18 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
{
struct drm_dp_sideband_msg_tx *txmsg;
struct drm_dp_mst_branch *mstb;
- int len, ret;
+ int len, ret, port_num;
u8 sinks[DRM_DP_MAX_SDP_STREAMS];
int i;
+ port_num = port->port_num;
mstb = drm_dp_get_validated_mstb_ref(mgr, port->parent);
- if (!mstb)
- return -EINVAL;
+ if (!mstb) {
+ mstb = drm_dp_get_last_connected_port_and_mstb(mgr,
port->parent, &port_num);
+
+
[PATCH v5 0/5] drm/exynos: introduce generic zpos and blending properties
Hello all, This patch series is a continuation of rework of blending support in Exynos DRM driver. Some background can be found here: http://www.spinics.net/lists/dri-devel/msg96969.html Daniel Vetter suggested that zpos property should be made generic, with well-defined semantics. This patchset is my proposal for such generic zpos property: - added zpos properties to drm core and plane state structures, - added helpers for normalizing zpos properties of given set of planes, - well defined semantics: planes are sorted by zpos values and then plane id value if zpos equals. The next part is a result of my survey on introducing generic plane blending related properties: http://www.spinics.net/lists/dri-devel/msg98106.html Ville Syrjälä suggested that blending mode should be defined by a pair of 2 factors, which define generic blending equation. I've implemented this approach. I hope that this code can be a base for further discussion on generic blending support. For more information, see patch 4/5. Patches are based on top of v4.5-rc1 release. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v5: - added patch with new generic blending and alpha properties - changed patchseries topic to "drm/exynos: introduce generic zpos and blending properties" - moved all generic code to separate drm_blend.c file v4: http://www.spinics.net/lists/dri-devel/msg98654.html - made min/max values of zpos property driver dependent (request of Ville Syrjälä) - adjusted some comments v3: http://www.spinics.net/lists/dri-devel/msg98207.html - on request of Daniel Vetter, moved all normalization process to DRM core, drivers can simply use plane_state->normalized_zpos in their atomic_check/update callbacks with no additional changes needed - updated documentation v2: http://www.spinics.net/lists/dri-devel/msg98093.html - dropped 2 fixes for Exynos DRM, which got merged in meantime - added more comments and kernel docs for core functions as suggested by Daniel Vetter - reworked initialization of zpos properties (moved assiging property class to common code), now the code in the driver is even simpler - while reworking of intialization of zpos property code, did the same change to generic rotation property v1: http://www.spinics.net/lists/dri-devel/msg97709.html - initial version Patch summary: Marek Szyprowski (5): drm: add generic zpos property drm/exynos: use generic code for managing zpos plane property drm: simplify initialization of rotation property drm: add generic blending related properties drm/exynos: add support for blending properties Documentation/DocBook/gpu.tmpl | 57 +++- drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 10 +- drivers/gpu/drm/drm_atomic.c| 16 ++ drivers/gpu/drm/drm_atomic_helper.c | 6 + drivers/gpu/drm/drm_blend.c | 337 drivers/gpu/drm/drm_crtc.c | 29 +- drivers/gpu/drm/drm_crtc_internal.h | 3 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 128 + drivers/gpu/drm/exynos/exynos_mixer.c | 6 +- drivers/gpu/drm/i915/intel_display.c| 6 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 3 +- drivers/gpu/drm/omapdrm/omap_drv.c | 3 +- include/drm/drm_crtc.h | 36 ++- include/uapi/drm/drm_mode.h | 101 +++ 16 files changed, 669 insertions(+), 81 deletions(-) create mode 100644 drivers/gpu/drm/drm_blend.c -- 1.9.2
[PATCH v5 2/5] drm/exynos: use generic code for managing zpos plane property
This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 -
drivers/gpu/drm/exynos/exynos_drm_plane.c | 68 ---
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++-
3 files changed, 20 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 17b5ded72ff1..816537886e4e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
struct exynos_drm_rect src;
unsigned int h_ratio;
unsigned int v_ratio;
- unsigned int zpos;
};
static inline struct exynos_drm_plane_state *
@@ -217,7 +216,6 @@ struct exynos_drm_private {
* this array is used to be aware of which crtc did it request vblank.
*/
struct drm_crtc *crtc[MAX_CRTC];
- struct drm_property *plane_zpos_property;
unsigned long da_start;
unsigned long da_space_size;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index d86227236f55..3a486939168e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -137,9 +137,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)
exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
if (exynos_state) {
- exynos_state->zpos = exynos_plane->config->zpos;
plane->state = &exynos_state->base;
plane->state->plane = plane;
+ plane->state->zpos = exynos_plane->config->zpos;
}
}
@@ -155,7 +155,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
return NULL;
__drm_atomic_helper_plane_duplicate_state(plane, ©->base);
- copy->zpos = exynos_state->zpos;
return ©->base;
}
@@ -168,43 +167,6 @@ static void exynos_drm_plane_destroy_state(struct
drm_plane *plane,
kfree(old_exynos_state);
}
-static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
- struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t val)
-{
- struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
- struct exynos_drm_plane_state *exynos_state =
- to_exynos_plane_state(state);
- struct exynos_drm_private *dev_priv = plane->dev->dev_private;
- const struct exynos_drm_plane_config *config = exynos_plane->config;
-
- if (property == dev_priv->plane_zpos_property &&
- (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
- exynos_state->zpos = val;
- else
- return -EINVAL;
-
- return 0;
-}
-
-static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
- const struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
- const struct exynos_drm_plane_state *exynos_state =
- container_of(state, const struct exynos_drm_plane_state, base);
- struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-
- if (property == dev_priv->plane_zpos_property)
- *val = exynos_state->zpos;
- else
- return -EINVAL;
-
- return 0;
-}
-
static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -213,8 +175,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.reset = exynos_drm_plane_reset,
.atomic_duplicate_state = exynos_drm_plane_duplicate_state,
.atomic_destroy_state = exynos_drm_plane_destroy_state,
- .atomic_set_property = exynos_drm_plane_atomic_set_property,
- .atomic_get_property = exynos_drm_plane_atomic_get_property,
};
static int
@@ -302,20 +262,23 @@ static const struct drm_plane_helper_funcs
plane_helper_funcs = {
};
static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
- unsigned int zpos)
+ unsigned int zpos, bool immutable)
{
struct drm_device *dev = plane->dev;
- struct exynos_drm_private *dev_priv = dev->dev_private;
struct drm_property *prop;
- prop = dev_priv->plane_zpos_property;
- if (!prop) {
- prop = drm_property_create_range(dev, 0, "zpos",
-0, MAX_PLANE - 1);
- if (!prop)
- return
[PATCH v5 1/5] drm: add generic zpos property
This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to drm core and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
id value if zpos equals
Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.
Signed-off-by: Marek Szyprowski
Tested-by: Benjamin Gaignard
---
Documentation/DocBook/gpu.tmpl | 14 ++-
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_atomic.c| 4 +
drivers/gpu/drm/drm_atomic_helper.c | 6 +
drivers/gpu/drm/drm_blend.c | 227
drivers/gpu/drm/drm_crtc_internal.h | 3 +
include/drm/drm_crtc.h | 17 +++
7 files changed, 270 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/drm_blend.c
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index a8669330b456..ae7d913adf60 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions
- DRM
+ DRM
Generic
ârotationâ
BITMASK
@@ -2068,7 +2068,7 @@ void intel_crt_init(struct drm_device *dev)
property to suggest an Y offset for a connector
- Optional
+ Optional
âscaling modeâ
ENUM
{ "None", "Full", "Center", "Full aspect" }
@@ -2092,6 +2092,16 @@ void intel_crt_init(struct drm_device *dev)
TBD
+"zpos"
+ RANGE
+ Min=0, Max= driver dependent
+ Plane
+ Plane's 'z' position during blending operation (0 for
background, highest for frontmost).
+ If two planes assigned to same CRTC have equal zpos values, the
plane with higher plane
+ id is treated as closer to front. Can be IMMUTABLE if driver
doesn't support changing
+ planes' order. Exact value range is driver dependent.
+
+
i915
Generic
"Broadcast RGB"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766dec6a8d..eeefaba1c092 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -2,7 +2,7 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-drm-y := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y := drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3f74193885f1..a19201efb7d1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -630,6 +630,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
+ } else if (property == config->zpos_property) {
+ state->zpos = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -686,6 +688,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_h;
} else if (property == config->rotation_property) {
*val = state->rotation;
+ } else if (property == config->zpos_property) {
+ *val = state->zpos;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 53db2d9120be..9fbfb672b317 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -32,6 +32,8 @@
#include
#include
+#include "drm_crtc_internal.h"
+
/**
* DOC: overview
*
@@ -530,6 +532,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
struct drm_plane_state *plane_state;
int i, ret = 0;
+ ret = drm_atomic_helper_normalize_zpos(dev, state);
+ if (ret)
+ return ret;
+
for_each_plane_in_state(state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
new file mode 100644
index ..cdcb647c8ed9
--- /dev/null
+++ b/drivers/gpu/drm/drm_blend.c
@@ -
[PATCH v5 3/5] drm: simplify initialization of rotation property
This patch simplifies initialization of generic rotation property and
aligns the code to match recently introduced function for intializing
generic zpos property. It also adds missing documentation.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 10 -
drivers/gpu/drm/drm_crtc.c | 29 -
drivers/gpu/drm/i915/intel_display.c| 6 ++---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 3 +--
drivers/gpu/drm/omapdrm/omap_drv.c | 3 +--
include/drm/drm_crtc.h | 4 ++--
6 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 1ffe9c329c46..4f9606cdf0f2 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -967,12 +967,10 @@ atmel_hlcdc_plane_create_properties(struct drm_device
*dev)
if (!props->alpha)
return ERR_PTR(-ENOMEM);
- dev->mode_config.rotation_property =
- drm_mode_create_rotation_property(dev,
- BIT(DRM_ROTATE_0) |
- BIT(DRM_ROTATE_90) |
- BIT(DRM_ROTATE_180) |
- BIT(DRM_ROTATE_270));
+ drm_mode_create_rotation_property(dev, BIT(DRM_ROTATE_0) |
+ BIT(DRM_ROTATE_90) |
+ BIT(DRM_ROTATE_180) |
+ BIT(DRM_ROTATE_270));
if (!dev->mode_config.rotation_property)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d40bab29747e..822ad6928144 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5875,10 +5875,23 @@ void drm_mode_config_cleanup(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_mode_config_cleanup);
-struct drm_property *drm_mode_create_rotation_property(struct drm_device *dev,
- unsigned int
supported_rotations)
+/**
+ * drm_mode_create_rotation_property - create generic rotation property
+ * @dev: DRM device
+ * @supported_rotations: bitmask of supported rotation modes
+ *
+ * This function initializes generic rotation property and enables support
+ * for it in drm core. Drivers can then attach this property to planes to
enable
+ * support for different rotation modes.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_create_rotation_property(struct drm_device *dev,
+ unsigned int supported_rotations)
{
- static const struct drm_prop_enum_list props[] = {
+ struct drm_property *prop;
+ static const struct drm_prop_enum_list values[] = {
{ DRM_ROTATE_0, "rotate-0" },
{ DRM_ROTATE_90, "rotate-90" },
{ DRM_ROTATE_180, "rotate-180" },
@@ -5887,9 +5900,13 @@ struct drm_property
*drm_mode_create_rotation_property(struct drm_device *dev,
{ DRM_REFLECT_Y, "reflect-y" },
};
- return drm_property_create_bitmask(dev, 0, "rotation",
- props, ARRAY_SIZE(props),
- supported_rotations);
+ prop = drm_property_create_bitmask(dev, 0, "rotation", values,
+ ARRAY_SIZE(values), supported_rotations);
+ if (!prop)
+ return -ENOMEM;
+
+ dev->mode_config.rotation_property = prop;
+ return 0;
}
EXPORT_SYMBOL(drm_mode_create_rotation_property);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2f00828ccc6e..1bce8750c308 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14046,8 +14046,7 @@ void intel_create_rotation_property(struct drm_device
*dev, struct intel_plane *
if (INTEL_INFO(dev)->gen >= 9)
flags |= BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270);
- dev->mode_config.rotation_property =
- drm_mode_create_rotation_property(dev, flags);
+ drm_mode_create_rotation_property(dev, flags);
}
if (dev->mode_config.rotation_property)
drm_object_attach_property(&plane->base.base,
@@ -14183,8 +14182,7 @@ static struct drm_plane
*intel_cursor_plane_create(struct drm_device *dev,
if (INTEL_INFO(dev)->gen >= 4) {
if (!dev->mode_config.rotation_property)
- dev->mode_config.rotation_property =
- drm_mode_create_rotation_property(dev,
+
[PATCH v5 4/5] drm: add generic blending related properties
This patch adds code and documentation for the following blending
related properties: 'alpha', 'blending' and 'alpha_premult'.
'alpha' property defines plane's transparency used for some blending
modes.
'alpha_premult' property defines if RGB pixel data in the framebuffer
contains values pre-multiplied by its alpha value or full range RGB
values (0-255), which needs to be multiplied by pixel alpha value for
blending operation.
'blending' property selects blending mode - by selecting one of the
predefined values, user can select a pair of factors, which will be
used in the generic blending equation. For more information, see
the kerneldoc for the added code.
Signed-off-by: Marek Szyprowski
---
Documentation/DocBook/gpu.tmpl | 47 +-
drivers/gpu/drm/drm_atomic.c | 12 +
drivers/gpu/drm/drm_blend.c| 110 +
include/drm/drm_crtc.h | 15 ++
include/uapi/drm/drm_mode.h| 101 +
5 files changed, 283 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index ae7d913adf60..e5197368e68f 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1110,6 +1110,22 @@ int max_width, max_height;
+
+
+
+Plane blending
+
+
+ Plane Blending Overview
+!Pinclude/uapi/drm/drm_mode.h Generic plane blending operation
+
+
+ Blending Function Reference
+!Iinclude/uapi/drm/drm_mode.h
+!Edrivers/gpu/drm/drm_blend.c
+
+
+
@@ -1816,7 +1832,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions
- DRM
+ DRM
Generic
ârotationâ
BITMASK
@@ -2068,7 +2084,7 @@ void intel_crt_init(struct drm_device *dev)
property to suggest an Y offset for a connector
- Optional
+ Optional
âscaling modeâ
ENUM
{ "None", "Full", "Center", "Full aspect" }
@@ -2102,6 +2118,33 @@ void intel_crt_init(struct drm_device *dev)
planes' order. Exact value range is driver dependent.
+"alpha"
+ RANGE
+ Min=0, Max= driver dependent
+ Plane
+ Plane's alpha value (transparency) for blending
operation. Used in some blending modes.
+
+
+"alpha_premult"
+ BOOL
+ Min=0, Max=1
+ Plane
+ Indicates the range of the RGB data of the
framebuffer attached to the given plane.
+ When enabled, RGB values fits the range from 0 to pixel's alpha
value. When disabled, RGB
+ values are from 0 to 255 range and during blending operations
they will be multiplied by
+ the pixel's alpha value first before computing result of
blending equations. Value of this
+ property is used in some blending modes and only when user
attaches framebuffer with pixel
+ format, which contains non-binary alpha channel.
+
+
+"blending"
+ ENUM
+ { "disabled", "pixel-alpha", "const-alpha"
"pixel-const-alpha" }
+ Plane
+ Selects algorithm used in plane blending operation.
For more information, see
+ DRM_BLEND_* symbolic constant documentation.
+
+
i915
Generic
"Broadcast RGB"
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a19201efb7d1..a85da144fd95 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -632,6 +632,12 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->rotation = val;
} else if (property == config->zpos_property) {
state->zpos = val;
+ } else if (property == config->alpha_property) {
+ state->alpha = val;
+ } else if (property == config->alpha_premult_property) {
+ state->alpha_premult = val;
+ } else if (property == config->blending_property) {
+ state->blending = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -690,6 +696,12 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == config->zpos_property) {
*val = state->zpos;
+ } else if (property == config->alpha_property) {
+ *val = state->alpha;
+ } else if (property == config->alpha_premult_property) {
+ *val = state->alpha_premult;
+ } else if (property == config->blending_property) {
+ *val = state->blending;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_blend.c b/
[PATCH v5 5/5] drm/exynos: add support for blending properties
This patch adds support for blending related properties to Exynos DRM
core and Exynos Mixer CRTC device.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +++
drivers/gpu/drm/exynos/exynos_drm_plane.c | 60 +++
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 816537886e4e..b33d69b8bb38 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -92,6 +92,9 @@ struct exynos_drm_plane {
#define EXYNOS_DRM_PLANE_CAP_DOUBLE(1 << 0)
#define EXYNOS_DRM_PLANE_CAP_SCALE (1 << 1)
#define EXYNOS_DRM_PLANE_CAP_ZPOS (1 << 2)
+#define EXYNOS_DRM_PLANE_CAP_PLANE_ALPHA (1 << 3)
+#define EXYNOS_DRM_PLANE_CAP_PREMULT_ALPHA (1 << 4)
+#define EXYNOS_DRM_PLANE_CAP_BLENDING (1 << 5)
/*
* Exynos DRM plane configuration structure.
@@ -100,6 +103,7 @@ struct exynos_drm_plane {
* @type: type of the plane (primary, cursor or overlay).
* @pixel_formats: supported pixel formats.
* @num_pixel_formats: number of elements in 'pixel_formats'.
+ * @blending_mode: default blending mode.
* @capabilities: supported features (see EXYNOS_DRM_PLANE_CAP_*)
*/
@@ -108,6 +112,7 @@ struct exynos_drm_plane_config {
enum drm_plane_type type;
const uint32_t *pixel_formats;
unsigned int num_pixel_formats;
+ unsigned int blending_mode;
unsigned int capabilities;
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 3a486939168e..28502aac135f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -140,6 +140,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)
plane->state = &exynos_state->base;
plane->state->plane = plane;
plane->state->zpos = exynos_plane->config->zpos;
+ plane->state->alpha = 255;
+ plane->state->alpha_premult = 1;
+ plane->state->blending = exynos_plane->config->blending_mode;
}
}
@@ -284,6 +287,53 @@ static void exynos_plane_attach_zpos_property(struct
drm_plane *plane,
drm_object_attach_property(&plane->base, prop, zpos);
}
+static void exynos_plane_attach_alpha_property(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane->dev;
+
+ if (!dev->mode_config.alpha_property)
+ if (drm_mode_create_alpha_property(dev, 255))
+ return;
+
+ drm_object_attach_property(&plane->base,
+ dev->mode_config.alpha_property, 255);
+}
+
+static void exynos_plane_attach_alpha_premult_property(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane->dev;
+
+ if (!dev->mode_config.alpha_premult_property)
+ if (drm_mode_create_alpha_premult_property(dev)) {
+ printk("failed to create alpha premult property\n");
+ return;
+ }
+
+ drm_object_attach_property(&plane->base,
+ dev->mode_config.alpha_premult_property, 1);
+}
+
+static void exynos_plane_attach_blending_property(struct drm_plane *plane,
+ unsigned int blending_mode)
+{
+ struct drm_device *dev = plane->dev;
+ static unsigned int blending_modes[] = {
+ DRM_BLEND_DISABLED,
+ DRM_BLEND_PIXEL_ALPHA,
+ DRM_BLEND_CONST_ALPHA,
+ DRM_BLEND_PIXEL_CONST_ALPHA,
+ };
+
+ if (!dev->mode_config.blending_property)
+ if (drm_mode_create_blending_property(dev, blending_modes,
+ ARRAY_SIZE(blending_modes)))
+ return;
+
+ drm_object_attach_property(&plane->base,
+ dev->mode_config.blending_property,
+ blending_mode);
+}
+
int exynos_plane_init(struct drm_device *dev,
struct exynos_drm_plane *exynos_plane,
unsigned int index, unsigned long possible_crtcs,
@@ -310,5 +360,15 @@ int exynos_plane_init(struct drm_device *dev,
exynos_plane_attach_zpos_property(&exynos_plane->base, config->zpos,
!(config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS));
+ if (config->capabilities & EXYNOS_DRM_PLANE_CAP_PLANE_ALPHA)
+ exynos_plane_attach_alpha_property(&exynos_plane->base);
+
+ if (config->capabilities & EXYNOS_DRM_PLANE_CAP_PREMULT_ALPHA)
+ exynos_plane_attach_alpha_premult_property(&exynos_plane->base);
+
+ if (config->capabilities & EXYNOS_DRM_PLANE_CAP_BLENDING)
+ exynos_plane_attach_blending_property(&exynos_plane->base,
+ config->blending_mode)
[PATCH libdrm] Update/fix the {copy,commit}-headers targets
On Wed, Jan 27, 2016 at 02:08:21PM +, Emil Velikov wrote: > On 27 January 2016 at 13:50, Daniel Vetter wrote: > > On Wed, Jan 27, 2016 at 01:23:11PM +, Emil Velikov wrote: > >> As some headers do not reside in include/drm we need to tweak our rules, > >> and exclude headers that shouldn't be distributed [XXX: clarify why ?]. > >> > >> To avoid the extra magic of diving into the kernel tree running `make > >> headers_install', just sed out the only reason why we need it - __user. > >> > >> Cc: Alex Deucher > >> Cc: Michel Dänzer > >> Cc: Ben Skeggs > >> Cc: Dave Airlie > >> Cc: Daniel Stone > >> Cc: Daniel Vetter > >> Cc: Inki Dae > >> Cc: Rob Clark > >> Cc: Tomi Valkeinen > >> Cc: Daniel Kurtz > >> Signed-off-by: Emil Velikov > >> --- > >> > >> Gents, > >> As one runs `make copy-headers' we get a massive diff stat (+1500/-800) > >> and a handful of issues gets pointed out. > >> Please let me know of your prefered solution (regardless if one will get > >> to it soon) and if we should consider it a blocker (B) or not (N). > >> > >> Thanks > >> Emil > >> > >> - (N) Header license miss-match - omap, msm, exynos. Update the kernel > >> ones ? > >> > >> - (N) Broken compat ioctls - exynos (and the UMS drivers) - using > >> unsigned int as opposed to _u32/64. Considering they're 32bit only, we > >> can get away with 'breaking' the ABI and using the proper ones ? > >> > >> - (N, keep local for now) C++ compat - libdrm has a hack/workaround > >> (virtual is a keyword in C++), which I'd like us to upstream plus some > >> extern C wrappers. > >> > >> - (?) Missing UMS symbols - see _DRM_GEM > >> > >> - (?) Non C89 compliant (see DRM_DRAWABLE_CLIPRECTS) - do we still > >> want/need that ? > >> > >> - (B) Using include as opposed to include "..." - drm.h, > >> nouveau_drm.h. Should be fixed in kernel. > >> > >> - (N) ABI 'break' > >> + drm - struct drm_mode_get_connector extra pad > >> + tegra - struct drm_tegra_gem_mmap extra pad > >> > >> - (B) API break > >> + drm - missing DRM_MODE_OBJECT_* > >> + nouveau - missing (gs)etparam - both structs and macros. everything > >> else is fine/unused. > >> + radeon - RADEON_TILING_R600_NO_SCANOUT, CIK_TILE_MODE_COLOR_2D* and > >> CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_* - quick grep shows no users > >> + omap - struct drm_omap_get_base, DRM_OMAP_GET_BASE + IOCTL > >> > >> - (N) (unneeded?) API additions - nouveau's DRM_IOCTL_NOUVEAU_GEM_* > >> > >> - (N) __KERNEL__ condiditionals. Is it really an issue - sure if looks > >> a bit spurious but that's about it. > >> > >> > >> Makefile.am | 9 - > >> 1 file changed, 8 insertions(+), 1 deletion(-) > >> > >> diff --git a/Makefile.am b/Makefile.am > >> index ca41508..6c71d3a 100644 > >> --- a/Makefile.am > >> +++ b/Makefile.am > >> @@ -126,7 +126,14 @@ endif > >> > >> copy-headers : > >> cp -r $(kernel_source)/include/uapi/drm/*.h > >> $(top_srcdir)/include/drm/ > >> + sed -i "s/__user //g" $(top_srcdir)/include/drm/*.h > >> + mv $(top_srcdir)/include/drm/exynos_drm.h $(top_srcdir)/exynos/ > >> + mv $(top_srcdir)/include/drm/msm_drm.h $(top_srcdir)/freedreno/msm/ > >> + mv $(top_srcdir)/include/drm/omap_drm.h $(top_srcdir)/omap/ > >> + rm $(top_srcdir)/include/drm/armada_drm.h > >> + rm $(top_srcdir)/include/drm/etnaviv_drm.h > >> + rm $(top_srcdir)/include/drm/i810_drm.h > >> + rm $(top_srcdir)/include/drm/vc4_drm.h > > > > You can't copy headers directly. First you need to generate them in the > > kernel sources: > > > > $ make headers_install > > > > Then you can copy them from usr/include/* > > > > That should at least get rid of the __KERNEL__ stuff. Then any serious > > issues should be fixed in the upstream kernel first. > I agree that copying the headers isn't that good of an idea. Then > again as that causes zero problems - it brings in __KERNEL__ and > __user, latter of which sed out. So wouldn't it be better to focus on > the serious issues first ? Of course, that doesn't mean we have to > forget about this one :-P > > -Emil > P.S. Diving into other projects and executing make foo/bar is frowned > upon, normally. I doubt anyone was suggesting that you would do that. I would probably just nuke the copy-headers rule. But if people want to keep it, I'd make it look at the INSTALL_HDR_PATH variable (which is how the kernel decides where to install the headers), bail if it's not set (or maybe default to /usr, like the kernel), and copy the headers from there. Then the user can go and do the 'make INSTALL_HDR_PATH=... headers_install' himself in the kernel tree, and then do the 'make INSTALL_HDR_PATH=... copy-headers' in libdrm. Or you could use some other variable name for that in libdrm, but reusing the kernel one would seem like the easiest solution. -- Ville Syrjälä Intel OTC
[Bug 108561] nouveau: external monitor can not be enabled with hindsight
https://bugzilla.kernel.org/show_bug.cgi?id=108561 Elmar Stellnberger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #11 from Elmar Stellnberger --- bug has now been moved to freedesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=93887 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file
Hi Maarten, 2016-01-27 Maarten Lankhorst : > Hey, > > Op 27-01-16 om 14:30 schreef Gustavo Padovan: > > From: Gustavo Padovan > > > > sync_file is useful to connect one or more fences to the file. The file is > > used by userspace to track fences. > > > > Signed-off-by: Gustavo Padovan > > > Is there a value in keeping the abi unchanged? > If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read. None from me. I'll look where we can improve the ABI. > > Looking at the patch, it seems you kept SYNC_IOC_WAIT, won't it be better to > remove it, and only support waiting with polling? > The code for polling should already work. Sure, that makes sense for me. > > It's very unclear what format @driver_data has. I kept it for compatibility > with android, but it's not clear to me how a userspace consumer would print > it. > Is there a usecase for this, or could it be removed from fence and sync_file? I don't have any usecase for this. I'd say we remove it for now and if someone needs this in the future we can talk about this again. Gustavo
[PATCH libdrm] Update/fix the {copy,commit}-headers targets
On 27 January 2016 at 14:47, Ville Syrjälä wrote: > On Wed, Jan 27, 2016 at 02:08:21PM +, Emil Velikov wrote: >> On 27 January 2016 at 13:50, Daniel Vetter wrote: >> > On Wed, Jan 27, 2016 at 01:23:11PM +, Emil Velikov wrote: >> >> As some headers do not reside in include/drm we need to tweak our rules, >> >> and exclude headers that shouldn't be distributed [XXX: clarify why ?]. >> >> >> >> To avoid the extra magic of diving into the kernel tree running `make >> >> headers_install', just sed out the only reason why we need it - __user. >> >> >> >> Cc: Alex Deucher >> >> Cc: Michel Dänzer >> >> Cc: Ben Skeggs >> >> Cc: Dave Airlie >> >> Cc: Daniel Stone >> >> Cc: Daniel Vetter >> >> Cc: Inki Dae >> >> Cc: Rob Clark >> >> Cc: Tomi Valkeinen >> >> Cc: Daniel Kurtz >> >> Signed-off-by: Emil Velikov >> >> --- >> >> >> >> Gents, >> >> As one runs `make copy-headers' we get a massive diff stat (+1500/-800) >> >> and a handful of issues gets pointed out. >> >> Please let me know of your prefered solution (regardless if one will get >> >> to it soon) and if we should consider it a blocker (B) or not (N). >> >> >> >> Thanks >> >> Emil >> >> >> >> - (N) Header license miss-match - omap, msm, exynos. Update the kernel >> >> ones ? >> >> >> >> - (N) Broken compat ioctls - exynos (and the UMS drivers) - using >> >> unsigned int as opposed to _u32/64. Considering they're 32bit only, we >> >> can get away with 'breaking' the ABI and using the proper ones ? >> >> >> >> - (N, keep local for now) C++ compat - libdrm has a hack/workaround >> >> (virtual is a keyword in C++), which I'd like us to upstream plus some >> >> extern C wrappers. >> >> >> >> - (?) Missing UMS symbols - see _DRM_GEM >> >> >> >> - (?) Non C89 compliant (see DRM_DRAWABLE_CLIPRECTS) - do we still >> >> want/need that ? >> >> >> >> - (B) Using include as opposed to include "..." - drm.h, >> >> nouveau_drm.h. Should be fixed in kernel. >> >> >> >> - (N) ABI 'break' >> >> + drm - struct drm_mode_get_connector extra pad >> >> + tegra - struct drm_tegra_gem_mmap extra pad >> >> >> >> - (B) API break >> >> + drm - missing DRM_MODE_OBJECT_* >> >> + nouveau - missing (gs)etparam - both structs and macros. everything >> >> else is fine/unused. >> >> + radeon - RADEON_TILING_R600_NO_SCANOUT, CIK_TILE_MODE_COLOR_2D* and >> >> CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_* - quick grep shows no users >> >> + omap - struct drm_omap_get_base, DRM_OMAP_GET_BASE + IOCTL >> >> >> >> - (N) (unneeded?) API additions - nouveau's DRM_IOCTL_NOUVEAU_GEM_* >> >> >> >> - (N) __KERNEL__ condiditionals. Is it really an issue - sure if looks >> >> a bit spurious but that's about it. >> >> >> >> >> >> Makefile.am | 9 - >> >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/Makefile.am b/Makefile.am >> >> index ca41508..6c71d3a 100644 >> >> --- a/Makefile.am >> >> +++ b/Makefile.am >> >> @@ -126,7 +126,14 @@ endif >> >> >> >> copy-headers : >> >> cp -r $(kernel_source)/include/uapi/drm/*.h >> >> $(top_srcdir)/include/drm/ >> >> + sed -i "s/__user //g" $(top_srcdir)/include/drm/*.h >> >> + mv $(top_srcdir)/include/drm/exynos_drm.h $(top_srcdir)/exynos/ >> >> + mv $(top_srcdir)/include/drm/msm_drm.h $(top_srcdir)/freedreno/msm/ >> >> + mv $(top_srcdir)/include/drm/omap_drm.h $(top_srcdir)/omap/ >> >> + rm $(top_srcdir)/include/drm/armada_drm.h >> >> + rm $(top_srcdir)/include/drm/etnaviv_drm.h >> >> + rm $(top_srcdir)/include/drm/i810_drm.h >> >> + rm $(top_srcdir)/include/drm/vc4_drm.h >> > >> > You can't copy headers directly. First you need to generate them in the >> > kernel sources: >> > >> > $ make headers_install >> > >> > Then you can copy them from usr/include/* >> > >> > That should at least get rid of the __KERNEL__ stuff. Then any serious >> > issues should be fixed in the upstream kernel first. >> I agree that copying the headers isn't that good of an idea. Then >> again as that causes zero problems - it brings in __KERNEL__ and >> __user, latter of which sed out. So wouldn't it be better to focus on >> the serious issues first ? Of course, that doesn't mean we have to >> forget about this one :-P >> >> -Emil >> P.S. Diving into other projects and executing make foo/bar is frowned >> upon, normally. > > I doubt anyone was suggesting that you would do that. > > I would probably just nuke the copy-headers rule. But if people want > to keep it, I'd make it look at the INSTALL_HDR_PATH variable (which > is how the kernel decides where to install the headers), bail if it's > not set (or maybe default to /usr, like the kernel), and copy the > headers from there. Then the user can go and do the > 'make INSTALL_HDR_PATH=... headers_install' himself in the kernel > tree, and then do the 'make INSTALL_HDR_PATH=... copy-headers' in > libdrm. Or you could use some other variable name for that in libdrm, > but reusing the kernel one would seem like the easiest solution.
[PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file
Hi Gustavo, On 27 January 2016 at 17:03, Gustavo Padovan wrote: > Hi Maarten, > > 2016-01-27 Maarten Lankhorst : > >> Hey, >> >> Op 27-01-16 om 14:30 schreef Gustavo Padovan: >> > From: Gustavo Padovan >> > >> > sync_file is useful to connect one or more fences to the file. The file is >> > used by userspace to track fences. >> > >> > Signed-off-by: Gustavo Padovan >> > >> Is there a value in keeping the abi unchanged? >> If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read. > > None from me. I'll look where we can improve the ABI. > Speaking of ABI... there are a couple of things that rang bells here: - In most/all of the kernel a len/size named member variable indicates the length of the extra data (zero sized array). While here it includes the size of the struct as well. - struct sync_file_info_data::fence_info is of type __u8 yet it is "a fence_info struct for every fence in the sync_file". Thus shouldn't one use "struct fence_info" as the type ? -Emil
[Bug 93879] kernel 4.4.0 causes application lockup and unusable interfaces with radeon hardware
https://bugs.freedesktop.org/show_bug.cgi?id=93879 --- Comment #5 from boombatower --- I had planned to test reverting those commits, but after reading through the thread it seems those commits simply further exposed symptoms of a larger issue that I believe was fixed in http://lists.freedesktop.org/archives/dri-devel/2016-January/097880.html. I am running a 4.4.0 kernel with that patch applied and so far have not seen the issues I described. Although, ironically, on my first boot I had the stuck login screen as described in the thread. -- 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/20160127/f5def1a3/attachment-0001.html>
[Bug 93879] kernel 4.4.0 causes application lockup and unusable interfaces with radeon hardware
https://bugs.freedesktop.org/show_bug.cgi?id=93879 --- Comment #6 from Alex Deucher --- (In reply to boombatower from comment #5) > I had planned to test reverting those commits, but after reading through the > thread it seems those commits simply further exposed symptoms of a larger > issue that I believe was fixed in > http://lists.freedesktop.org/archives/dri-devel/2016-January/097880.html. > > I am running a 4.4.0 kernel with that patch applied and so far have not seen > the issues I described. Although, ironically, on my first boot I had the > stuck login screen as described in the thread. Different issues. -- 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/20160127/3edc6d0f/attachment.html>
[BUG/REGRESSION] Kernel 4.5-rc1 on Acube Sam460ex AMCC 460ex Power PC motherboards
On Wed, Jan 27, 2016 at 2:18 AM, Julian Margetson wrote:
> On 1/26/2016 9:43 PM, Dan Williams wrote:
> diff --git a/mm/memory.c b/mm/memory.c
> index 30991f83d0bf..c44e387130b2 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1521,6 +1521,8 @@ static int insert_pfn(struct vm_area_struct
> *vma, unsigned long addr,
>entry = pte_mkdevmap(pfn_t_pte(pfn, prot));
>else
>entry = pte_mkspecial(pfn_t_pte(pfn, prot));
> + pr_info("%s: entry: %#llx pfn: %#lx\n", __func__,
> + (unsigned long long) entry, pfn_t_to_pfn(pfn));
>set_pte_at(mm, addr, pte, entry);
>update_mmu_cache(vma, addr, pte); /* XXX: why not for insert_page? */
>
> ...of course for the passing case you'll need to drop the call to
> pfn_t_to_pfn() and just print the pfn directly.
>
> Thank you for the help tracking this down, it's much appreciated.
>
> Happy to help out. Just need some guidance sometimes as I am relatively new
> at this.
No worries.
So, below is the failing case, what does insert_pfn print in the
passing case? No need for the full log just the first few lines after
starting X when running the commit before this failing one... (commit
69660fd797c3 "x86, mm: introduce _PAGE_DEVMAP").
I'm still stumped given that PTE_RPN_SHIFT==PAGE_SHIFT in this
configuration, so there's no 64-bit to 32-bit truncation to worry
about...
> -
> 15.802615] systemd[1]: Started Journal Service.
> [ 44.263074] Oops: Machine check, sig: 7 [#1]
> [ 44.267603] PREEMPT Canyonlands
> [ 44.270938] Modules linked in:
> [ 44.274182] CPU: 0 PID: 586 Comm: Xorg Tainted: GW
> 4.5.0-rc1-Sam460ex #2
> [ 44.282538] task: ecd505c0 ti: efff2000 task.ti: ecd76000
> [ 44.288239] NIP: ccec LR: 1fb81404 CTR: 1fb814d0
> [ 44.293483] REGS: efff3f10 TRAP: 0214 Tainted: GW
> (4.5.0-rc1-Sam460ex)
> [ 44.301926] MSR: 00021000 CR: 84004242 XER:
> [ 44.308185]
> GPR00: 1f045134 bfd0ce80 b7e7b6f0 b763dffc b6e54008 0780 0004
>
> GPR08: b763dffc b6e54010 ecf5 ecf5 0009
> 0780
> GPR16: 0020 1e00 2079b638 0438
> b6e54008
> GPR24: 0780 bfd0ced8 20785770 b763e000 b763e000 b6e54008 1fc89ff4
> 1e00
> [ 44.340039] NIP [ccec] DataTLBError44x+0x6c/0x90
> [ 44.345279] LR [1fb81404] 0x1fb81404
> [ 44.349053] Call Trace:
> [ 44.351631] Instruction dump:
> [ 44.354776] 7d7342a6 816b0040 7d92eaa6 7db00aa6 51ac063e 7d92eba6
> 7d9e0aa6 39a9
> [ 44.363081] 518d57bc 554c6cfa 7d6c582e 556c0029 <4182003c> 514cbd38
> 816c 818c0004
> [ 44.524699] ---[ end trace 439fa29153308785 ]---
> [ 44.529322]
> [ 47.216536] insert_pfn: entry: 0x80ed246b pfn: 0x80ed2
> [ 47.221777] insert_pfn: entry: 0x80ed346b pfn: 0x80ed3
> [ 47.228485] insert_pfn: entry: 0x80ed446b pfn: 0x80ed4
> [ 47.237798] insert_pfn: entry: 0x80ed546b pfn: 0x80ed5
> [ 47.249809] insert_pfn: entry: 0x80ed646b pfn: 0x80ed6
> [ 47.257588] insert_pfn: entry: 0x80ed746b pfn: 0x80ed7
> [ 47.265879] insert_pfn: entry: 0x80ed846b pfn: 0x80ed8
> [ 47.275825] insert_pfn: entry: 0x80ed946b pfn: 0x80ed9
> [ 47.281437] insert_pfn: entry: 0x80eda46b pfn: 0x80eda
> [ 47.288113] insert_pfn: entry: 0x80edb46b pfn: 0x80edb
> [ 47.293660] insert_pfn: entry: 0x80edc46b pfn: 0x80edc
> [ 47.299834] insert_pfn: entry: 0x80edd46b pfn: 0x80edd
> [ 47.305223] insert_pfn: entry: 0x80ede46b pfn: 0x80ede
> [ 47.314891] insert_pfn: entry: 0x80edf46b pfn: 0x80edf
> [ 47.329777] insert_pfn: entry: 0x80ee046b pfn: 0x80ee0
> [ 47.339769] insert_pfn: entry: 0x80ee146b pfn: 0x80ee1
> [ 47.349777] Machine check in kernel mode.
> [ 47.353814] Data Write PLB Error
[PATCH resend] kmstest: fix link error due to library ordering
Recent commit below introduced a new library to be linked (libutil.la): commit 0caf58a6cb82327a3f6a53f05dea8e02f1412a05 Author: Stefan Agner Date: Sat Dec 19 21:52:58 2015 -0800 kmstest: Use util_open() Use the new util_open() helper instead of open-coding the method for finding a usable device. While at it, make the command-line interface more consistent with that of modetest by adding the -D and -M options. Signed-off-by: Stefan Agner v2: correctly use util_open() - swap device, module Signed-off-by: Emil Velikov The ordering of the libraries in kmstest_LDADD is causing the following error on my build system: ld: ../../tests/util/.libs/libutil.a(libutil_la-kms.o): undefined reference to symbol 'drmOpen' ../../.libs/libdrm.so: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Makefile:436: recipe for target 'kmstest' failed make[3]: *** [kmstest] Error 1 The above error is resolved by switching the linking order. Cc: Stefan Agner Cc: Kristian Høgsberg Kristensen Signed-off-by: Reinette Chatre --- This is a resend since first attempt was made when I was not subscribed to mailing list and it only made it to cc list, not the mailing list. tests/kmstest/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/kmstest/Makefile.am b/tests/kmstest/Makefile.am index 100662e..9083620 100644 --- a/tests/kmstest/Makefile.am +++ b/tests/kmstest/Makefile.am @@ -18,8 +18,8 @@ kmstest_SOURCES = \ kmstest_LDADD = \ $(top_builddir)/libdrm.la \ - $(top_builddir)/libkms/libkms.la \ - $(top_builddir)/tests/util/libutil.la + $(top_builddir)/tests/util/libutil.la \ + $(top_builddir)/libkms/libkms.la run: kmstest ./kmstest -- 2.4.3
[PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file
Hi Emil, 2016-01-27 Emil Velikov : > Hi Gustavo, > > On 27 January 2016 at 17:03, Gustavo Padovan wrote: > > Hi Maarten, > > > > 2016-01-27 Maarten Lankhorst : > > > >> Hey, > >> > >> Op 27-01-16 om 14:30 schreef Gustavo Padovan: > >> > From: Gustavo Padovan > >> > > >> > sync_file is useful to connect one or more fences to the file. The file > >> > is > >> > used by userspace to track fences. > >> > > >> > Signed-off-by: Gustavo Padovan > >> > > >> Is there a value in keeping the abi unchanged? > >> If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read. > > > > None from me. I'll look where we can improve the ABI. > > > Speaking of ABI... there are a couple of things that rang bells here: > - In most/all of the kernel a len/size named member variable > indicates the length of the extra data (zero sized array). While here > it includes the size of the struct as well. len in this case is the size of the buffer sent to the kernel, the total length (including the whole struct) is returned in the ioctl. > - struct sync_file_info_data::fence_info is of type __u8 yet it is "a > fence_info struct for every fence in the sync_file". Thus shouldn't > one use "struct fence_info" as the type ? Agreed. But I'm currently thinking if we really should keep this ioctl. Gustavo
[PATCH resend] kmstest: fix link error due to library ordering
Hi Reinette, [added Emil to CC] Hm, I wonder why that did not happen on my system. What OS/gcc version do you use? -- Stefan On 2016-01-27 12:12, Reinette Chatre wrote: > Recent commit below introduced a new library to be linked (libutil.la): > > commit 0caf58a6cb82327a3f6a53f05dea8e02f1412a05 > Author: Stefan Agner > Date: Sat Dec 19 21:52:58 2015 -0800 > > kmstest: Use util_open() > > Use the new util_open() helper instead of open-coding the method for > finding a usable device. While at it, make the command-line interface > more consistent with that of modetest by adding the -D and -M options. > > Signed-off-by: Stefan Agner > v2: correctly use util_open() - swap device, module > Signed-off-by: Emil Velikov > > The ordering of the libraries in kmstest_LDADD is causing the following > error on my build system: > > ld: ../../tests/util/.libs/libutil.a(libutil_la-kms.o): undefined > reference to symbol 'drmOpen' > ../../.libs/libdrm.so: error adding symbols: DSO missing from command line > collect2: error: ld returned 1 exit status > Makefile:436: recipe for target 'kmstest' failed > make[3]: *** [kmstest] Error 1 > > The above error is resolved by switching the linking order. > > Cc: Stefan Agner > Cc: Kristian Høgsberg Kristensen > Signed-off-by: Reinette Chatre > --- > This is a resend since first attempt was made when I was not subscribed to > mailing list and it only made it to cc list, not the mailing list. > > tests/kmstest/Makefile.am | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tests/kmstest/Makefile.am b/tests/kmstest/Makefile.am > index 100662e..9083620 100644 > --- a/tests/kmstest/Makefile.am > +++ b/tests/kmstest/Makefile.am > @@ -18,8 +18,8 @@ kmstest_SOURCES = \ > > kmstest_LDADD = \ > $(top_builddir)/libdrm.la \ > - $(top_builddir)/libkms/libkms.la \ > - $(top_builddir)/tests/util/libutil.la > + $(top_builddir)/tests/util/libutil.la \ > + $(top_builddir)/libkms/libkms.la > > run: kmstest > ./kmstest
[PATCH resend] kmstest: fix link error due to library ordering
Hi Stefan, On 2016-01-27, Stefan Agner wrote: > [added Emil to CC] > Hm, I wonder why that did not happen on my system. What OS/gcc version > do you use? On my host I am building an image using Yocto (http://www.yoctoproject.org/) to contain latest libdrm. In case you are not familiar with Yocto this system will first create its own build environment (think sysroot) and then build this library within it. Since the build environment is separate from host it is very sensitive to dependencies being correct and could explain why this issue is not encountered by folks building on and for their hosts. I have been doing this daily without issue since about April of last year. The version I am using relies on gcc 4.9.2. Reinette
[Bug 93893] R9 390 Hawaii fails resuming from hibernation on amdgpu (linux-4.5.0-rc1)
https://bugs.freedesktop.org/show_bug.cgi?id=93893 Bug ID: 93893 Summary: R9 390 Hawaii fails resuming from hibernation on amdgpu (linux-4.5.0-rc1) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: h.judt at gmx.at Created attachment 121330 --> https://bugs.freedesktop.org/attachment.cgi?id=121330&action=edit dmesg I've hoped it would work better than with radeon, but unfortunately it is even worse and will not even perform a single cycle. All ring tests fail with CAFEDEAD. Dmesg attached. -- 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/20160127/df10ce7e/attachment.html>
[Bug 93893] R9 390 Hawaii fails resuming from hibernation on amdgpu (linux-4.5.0-rc1)
https://bugs.freedesktop.org/show_bug.cgi?id=93893 --- Comment #1 from Harald Judt --- Note I am using the latest firmware files and even hawaii_k_smc (replacing the original hawaii_smc). -- 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/20160127/598abda2/attachment.html>
[PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file
On 01/27/2016 12:25 PM, Gustavo Padovan wrote: Is there a value in keeping the abi unchanged? If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read. >>> >>> None from me. I'll look where we can improve the ABI. Android has existing clients of the current ABI. Thankfully they're all contained in system services like SurfaceFlinger, since end-user apps don't get direct access to fence fds. As long the ABI breaks don't remove functionality we depend on, we can wrap around them in our userspace libsync. I'd rather not have to do that, but it's a price I'm willing to pay to get this moved out of staging. >> - struct sync_file_info_data::fence_info is of type __u8 yet it is "a >> fence_info struct for every fence in the sync_file". Thus shouldn't >> one use "struct fence_info" as the type ? > > Agreed. But I'm currently thinking if we really should keep this ioctl. > > Gustavo > I'm not seeing any consumers of driver_data in our tree. OTOH completely getting rid of the ioctl would be a problem, since SurfaceFlinger depends on the timestamp information for its own bookkeeping.
[PATCH RFC 1/2] clk: sunxi: Add sun8i display support
Hi,
On Tue, Jan 19, 2016 at 09:09:01AM +0100, Jean-Francois Moine wrote:
> On Mon, 18 Jan 2016 20:09:04 +0100
> Maxime Ripard wrote:
>
> > > +static const struct clk_ops clk_sun8i_pll3_fact_ops = {
> > > + .recalc_rate = sun8i_pll3_recalc_rate,
> > > + .round_rate = sun8i_pll3_round_rate,
> > > + .set_rate = sun8i_pll3_set_rate,
> > > +};
> >
> > We have the clk-factors stuff to handle this easily, could you use
> > that instead ?
>
> No, the sun6i/8i pll3 offers direct 297MHz and 270MHz.
That's true, but so far it's something that never has been really
needed. This PLL is not the same one using the fractional mode, so I
guess we could extend the clk-factors to be able to deal with
that. The video pll in the A10 (pll3) is also in this case, so does
the A31 PLL3 and PLL4.
Also note that all these clocks can reach those frequencies through
what allwinner calls the integer mode, so apart from the hardware
readout, we don't really need it anyway.
> > As part of my DRM patches, I've added a clk-display clock that can
> > handle that easily.
> >
> > And actually, as part of bringing up the display engine on the A33, I
> > already did it:
> > https://github.com/mripard/linux/commit/92b6843b5ee5b70cb2be3638df31d3eca28a4dba
> > https://github.com/mripard/linux/commit/81e8ea74be5e72124eb584432bb79ff75f90d9ed
>
> I don't remember any patch request from yours in the Linux
> mailing-lists about these developments.
Indeed, I was waiting for the first DRM developments to get in before
sending those for review.
>
> Otherwise, about this old RFC, Chen-Yu Tsai replied:
>
> > > Add the clock types which are used by the sun8i family for video.
> >
> > These clocks first appeared in the A31.
The video PLL is, the display engine and tcon clocks are a bit
different (mostly because of their weird parent configuration that
need a muxing table). Note that I'm talking about the A23 / A33. I
haven't checked for the H3.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160127/0cf1a529/attachment.sig>
[PATCH resend] kmstest: fix link error due to library ordering
Hi Reinette, Thanks for the patch. I've actually made a similar patch one some 12 hours ago. Silly me forgot to push it - it's in master now. On 27 January 2016 at 21:29, Chatre, Reinette wrote: > Hi Stefan, > > On 2016-01-27, Stefan Agner wrote: >> [added Emil to CC] >> Hm, I wonder why that did not happen on my system. What OS/gcc version >> do you use? > > On my host I am building an image using Yocto (http://www.yoctoproject.org/) > to contain latest libdrm. In case you are not familiar with Yocto this system > will first create its own build environment (think sysroot) and then build > this library within it. Since the build environment is separate from host it > is very sensitive to dependencies being correct and could explain why this > issue is not encountered by folks building on and for their hosts. I have > been doing this daily without issue since about April of last year. The > version I am using relies on gcc 4.9.2. > Err... sorry I'm not sure how that explains it. The missing symbol has been part of libdrm.so since forever, so regardless which version gets picked (the host one or not) it wouldn't error out in such a way. I'm leaning that it's due to different LDFLAGS - what are you using ? The first 'offender' that comes to mind is --as-needed although I might be mistaking. Thanks for the report, it should be working fine now. Emil
[PATCH resend] kmstest: fix link error due to library ordering
Hi Emil, On 2016-01-27, Emil Velikov wrote: > Hi Reinette, > > Thanks for the patch. I've actually made a similar patch one some 12 > hours ago. Silly me forgot to push it - it's in master now. Thank you very much. > > On 27 January 2016 at 21:29, Chatre, Reinette > wrote: >> Hi Stefan, >> >> On 2016-01-27, Stefan Agner wrote: >>> [added Emil to CC] >>> Hm, I wonder why that did not happen on my system. What OS/gcc version >>> do you use? >> >> On my host I am building an image using Yocto > (http://www.yoctoproject.org/) to contain latest libdrm. In case you are not > familiar with Yocto this system will first create its own build environment > (think > sysroot) and then build this library within it. Since the build environment is > separate from host it is very sensitive to dependencies being correct and > could > explain why this issue is not encountered by folks building on and for their > hosts. > I have been doing this daily without issue since about April of last year. The > version I am using relies on gcc 4.9.2. >> > Err... sorry I'm not sure how that explains it. The missing symbol has > been part of libdrm.so since forever, so regardless which version gets > picked (the host one or not) it wouldn't error out in such a way. > > I'm leaning that it's due to different LDFLAGS - what are you using ? > The first 'offender' that comes to mind is --as-needed although I > might be mistaking. I am indeed using --as-needed Reinette
[Bug 93217] [tonga] [powerplay] Radon M395X isn't initialised with the powerplay branch
https://bugs.freedesktop.org/show_bug.cgi?id=93217 --- Comment #27 from Mike Lothian --- I've tried your latest 4.6-wip branch, I still have to disable pcie_dpm to get the kernel to boot, and I have to disable runpm to get performance Let me know if you'd like me to test any of the new sysfs knobs you've added -- 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/20160127/7fe26b9c/attachment.html>
[PATCH] MAINTAINERS: update for Freescale DCU DRM driver
On 2016-01-07 05:21, Jianwei Wang wrote: > Acked-by: Jianwei Wang Applied and pushed to my git tree: http://git.agner.ch/gitweb/?p=linux-drm-fsl-dcu.git;a=shortlog;h=refs/heads/for-next Along with this patch, I will queue some DRM DCU patches currently waiting to be applied. I plan to send a pull request to Dave for the 4.6 merge window. -- Stefan > > On Thu, Jan 7, 2016 at 2:02 PM, Stefan Agner wrote: >> Promote myself as new maintainer of the Freescale DCU DRM driver. >> >> Signed-off-by: Stefan Agner >> --- >> This has been previously discussed privately. The original driver >> author and maintainer Jianwei does not work for Freescale anymore >> and can not carve out spare time to maintain the driver. >> >> As I started to make use of the driver on the Freescale Vybrid SoC >> and already posted several fixes and improvements, I am willing to >> maintain the driver. >> >> Thanks Jianwei for your work on that driver! >> >> Dave, I hope you are OK with that? >> >> I plan to send a pull request with the patches which have been on the >> ml lately, specifically the "Fix no fb check bug" and my fixes and >> enhancements patchset, along with this maintainer change, does that >> sound reasonable? >> >> There is one more pending patchset for this drivers, the TCON and >> Vybrid support patchset, but this is probably not ready yet. I also >> plan to post another patchset which enables multiple overlay planes >> and a cursor plane. >> >> -- >> Stefan >> >> MAINTAINERS | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index e9caa4b..3f0aea3 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -3678,7 +3678,7 @@ F:include/drm/exynos* >> F: include/uapi/drm/exynos* >> >> DRM DRIVERS FOR FREESCALE DCU >> -M: Jianwei Wang >> +M: Stefan Agner >> M: Alison Wang >> L: dri-devel at lists.freedesktop.org >> S: Supported >> -- >> 2.6.4 >>
[RESEND,V2] drm: fsl-dcu: Fix no fb check bug
On 2016-01-26 13:18, Emil Velikov wrote:
> On 14 January 2016 at 08:23, Meng Yi wrote:
>>> >> switch (fb->pixel_format) {
>>> >> case DRM_FORMAT_RGB565:
>>> >> case DRM_FORMAT_RGB888:
>>> >> @@ -85,9 +88,6 @@ static void fsl_dcu_drm_plane_atomic_update(struct
>>> drm_plane *plane,
>>> >> unsigned int alpha, bpp;
>>> >> int index, ret;
>>> >>
>>> >> - if (!fb)
>>> >> - return;
>>> >> -
>>> > ... which no longer has the !fb check, and we'll crash with null deref
>>> > a few lines below ?
>>>
>>>
>>> If there is a legitimate situation where fb is null which also ultimately
>>> leads to a
>>> atomic_commit, I guess we should keep the return here...
>>
>> I think I made a mistake here, fb check should not be removed . As Stefan
>> mentioned, if fb check in fsl_dcu_drm_plane_atomic_check return 0,
>> fsl_dcu_drm_plane_atomic_update will ultimately called, and we'll crash
>> since plane->state->fb is NULL.
>>
> I believe you meant "Emil" in the above ;-) But seriously... afaict a
> fair few drivers do a similar !fb (even !state->crtc) check(s)...
> which makes me wonder if core DRM isn't the better place for it ? Or
> perhaps that's intentional as core provides the flexibility for each
> driver to mangle with the fb between .check and .disable ?
>
There seem to be a consensus to check crtc and fb on atomic_check.
However, in atomic_update, some drives do a NULL check on crtc only, and
some on both, crtc and fb.
The comment in drm_atomic_plane_disabling says CRTC and FB should always
be NULL together... So I guess it does not really matter all that much,
unless there is anyway a bug.
Furthermore, it seems that in the null case, atomic_disable is called
anyway (which this driver implements). Not sure if there is another case
in which either of this two could be NULL and atomic_update could be
called.
Since this patch is mainly addressing the null check in atomic_check, I
will apply it without the change in atomic_update for now.
--
Stefan
[PATCH 7/7] drm/fsl-dcu: use mode flags for hsync/vsync pixelclk polarity
Hi Dave, Hi Thierry,
Not sure how to handle this patch: it contains a little change in
panel-simple.c. I think this should be in one patch, since it changes
the associated logic in the driver... Can I send that through my tree?
--
Stefan
On 2015-11-18 18:42, Stefan Agner wrote:
> The current default configuration is as follows:
> - Display samples data on the falling edge
> - Invert VSYNC signal (active LOW)
> - Invert HSYNC signal (active LOW)
>
> The mode flags allow to specify the required polarity per
> display. Furthermore, none of the current driver settings is
> actually a standard polarity.
>
> This patch applies the current driver standard polarities as
> explicit flags to the display which has been introduced with
> the driver (NEC WQVGA "nec,nl4827hc19-05b"). The driver now
> also parses the flags field and applies the configuration
> accordingly, by using the following values as defaults (e.g.
> if no flags are specified):
> - Display samples data on the rising edge
> - VSYNC signal not inverted (active HIGH)
> - HSYNC signal not inverted (active HIGH)
>
> Signed-off-by: Stefan Agner
> ---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 16 +---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 4 ++--
> drivers/gpu/drm/panel/panel-simple.c | 2 ++
> 3 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> index b2f56e4..db69725 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> @@ -18,6 +18,8 @@
> #include
> #include
>
> +#include
> +
> #include "fsl_dcu_drm_crtc.h"
> #include "fsl_dcu_drm_drv.h"
> #include "fsl_dcu_drm_plane.h"
> @@ -74,7 +76,7 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct
> drm_crtc *crtc)
> struct drm_device *dev = crtc->dev;
> struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> struct drm_display_mode *mode = &crtc->state->mode;
> - unsigned int hbp, hfp, hsw, vbp, vfp, vsw, div, index;
> + unsigned int hbp, hfp, hsw, vbp, vfp, vsw, div, index, pol = 0;
> unsigned long dcuclk;
>
> index = drm_crtc_index(crtc);
> @@ -89,6 +91,15 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct
> drm_crtc *crtc)
> vfp = mode->vsync_start - mode->vdisplay;
> vsw = mode->vsync_end - mode->vsync_start;
>
> + if (!(mode->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE))
> + pol |= DCU_SYN_POL_INV_PXCK_FALL;
> +
> + if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> + pol |= DCU_SYN_POL_INV_HS_LOW;
> +
> + if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> + pol |= DCU_SYN_POL_INV_VS_LOW;
> +
> regmap_write(fsl_dev->regmap, DCU_HSYN_PARA,
>DCU_HSYN_PARA_BP(hbp) |
>DCU_HSYN_PARA_PW(hsw) |
> @@ -101,8 +112,7 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct
> drm_crtc *crtc)
>DCU_DISP_SIZE_DELTA_Y(mode->vdisplay) |
>DCU_DISP_SIZE_DELTA_X(mode->hdisplay));
> regmap_write(fsl_dev->regmap, DCU_DIV_RATIO, div);
> - regmap_write(fsl_dev->regmap, DCU_SYN_POL,
> - DCU_SYN_POL_INV_VS_LOW | DCU_SYN_POL_INV_HS_LOW);
> + regmap_write(fsl_dev->regmap, DCU_SYN_POL, pol);
> regmap_write(fsl_dev->regmap, DCU_BGND, DCU_BGND_R(0) |
>DCU_BGND_G(0) | DCU_BGND_B(0));
> regmap_write(fsl_dev->regmap, DCU_DCU_MODE,
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> index 6413ac9..2a724f3 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> @@ -47,8 +47,8 @@
> #define DCU_VSYN_PARA_FP(x) (x)
>
> #define DCU_SYN_POL 0x0024
> -#define DCU_SYN_POL_INV_PXCK_FALL(0 << 6)
> -#define DCU_SYN_POL_NEG_REMAIN (0 << 5)
> +#define DCU_SYN_POL_INV_PXCK_FALLBIT(6)
> +#define DCU_SYN_POL_NEG_REMAIN BIT(5)
> #define DCU_SYN_POL_INV_VS_LOW BIT(1)
> #define DCU_SYN_POL_INV_HS_LOW BIT(0)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index f97b73e..fa68b56 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -960,6 +960,8 @@ static const struct drm_display_mode
> nec_nl4827hc19_05b_mode = {
> .vsync_end = 272 + 2 + 4,
> .vtotal = 272 + 2 + 4 + 2,
> .vrefresh = 74,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC |
> + DISPLAY_FLAGS_PIXDATA_POSEDGE,
> };
>
> static const struct panel_desc nec_nl4827hc19_05b = {
[PATCH 3/3] vc4: Add headers and .pc files for VC4 userspace development.
Daniel Stone writes: > Hi, > > On 27 January 2016 at 14:16, Emil Velikov wrote: >> On 27 January 2016 at 11:45, Daniel Stone wrote: >>> The Requires will take care of that, so you can just bin the entire >>> 'Libs:' field until you need one: >>> >> In theory this will be sufficient, but Eric wasn't buying it [1] :'-(. >> He's main consern (if I understood him correctly) is to stay >> consistent with the existing libdrm_* providers, regardless if things >> look a bit quirky. > > I suspect he was missing that 'Requires' also pulls in the relevant > flags from those libraries, so PKG_CHECK_MODULES(DRM_VC4, > [libdrm-vc4]) is equivalent to PKG_CHECK_MODULES(DRM_VC4, [libdrm > libdrm-vc4]), if libdrm-vc4.pc has 'Requires: libdrm'. What I heard Emil arguing to me was that a pkg-config request for --libs
[PATCH 3/3 v3] vc4: Add headers and .pc files for VC4 userspace development.
The headers were originally written in Mesa, imported to the kernel, and improved upon in vc4-gpu-tools. These come from the v-g-t copies and will replace the Mesa and v-g-t copies, and hopefully be used from new tests in igt, as well. v2: Fix linking against libdrm_intel instead of libdrm. v3: Drop Libs and Cflags since they'll be inherited from libdrm. Signed-off-by: Eric Anholt --- Makefile.am | 6 + configure.ac | 19 +++ vc4/Makefile.am | 34 + vc4/Makefile.sources | 3 + vc4/libdrm_vc4.pc.in | 11 ++ vc4/vc4_packet.h | 397 ++ vc4/vc4_qpu_defines.h | 274 ++ 7 files changed, 744 insertions(+) create mode 100644 vc4/Makefile.am create mode 100644 vc4/Makefile.sources create mode 100644 vc4/libdrm_vc4.pc.in create mode 100644 vc4/vc4_packet.h create mode 100644 vc4/vc4_qpu_defines.h diff --git a/Makefile.am b/Makefile.am index ca41508..feecba7 100644 --- a/Makefile.am +++ b/Makefile.am @@ -29,6 +29,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \ --enable-radeon \ --enable-amdgpu \ --enable-nouveau \ + --enable-vc4 \ --enable-vmwgfx \ --enable-omap-experimental-api \ --enable-exynos-experimental-api \ @@ -79,6 +80,10 @@ if HAVE_TEGRA TEGRA_SUBDIR = tegra endif +if HAVE_VC4 +VC4_SUBDIR = vc4 +endif + if BUILD_MANPAGES if HAVE_MANPAGES_STYLESHEET MAN_SUBDIR = man @@ -96,6 +101,7 @@ SUBDIRS = \ $(EXYNOS_SUBDIR) \ $(FREEDRENO_SUBDIR) \ $(TEGRA_SUBDIR) \ + $(VC4_SUBDIR) \ tests \ $(MAN_SUBDIR) diff --git a/configure.ac b/configure.ac index a09be61..4dc5394 100644 --- a/configure.ac +++ b/configure.ac @@ -126,6 +126,11 @@ AC_ARG_ENABLE(tegra-experimental-api, [Enable support for Tegra's experimental API (default: disabled)]), [TEGRA=$enableval], [TEGRA=no]) +AC_ARG_ENABLE(vc4, + AS_HELP_STRING([--disable-vc4], + [Enable support for vc4's API (default: auto, enabled on arm)]), + [VC4=$enableval], [VC4=auto]) + AC_ARG_ENABLE(install-test-programs, AS_HELP_STRING([--enable-install-test-programs], [Install test programs (default: no)]), @@ -290,6 +295,12 @@ else *) FREEDRENO=no ;; esac fi + if test "x$VC4" = xauto; then + case $host_cpu in + arm*|aarch64) VC4=yes ;; + *) VC4=no ;; + esac + fi fi if test "x$INTEL" != "xno"; then @@ -396,6 +407,11 @@ if test "x$TEGRA" = xyes; then AC_DEFINE(HAVE_TEGRA, 1, [Have Tegra support]) fi +AM_CONDITIONAL(HAVE_VC4, [test "x$VC4" = xyes]) +if test "x$VC4" = xyes; then + AC_DEFINE(HAVE_VC4, 1, [Have VC4 support]) +fi + AM_CONDITIONAL(HAVE_INSTALL_TESTS, [test "x$INSTALL_TESTS" = xyes]) if test "x$INSTALL_TESTS" = xyes; then AC_DEFINE(HAVE_INSTALL_TESTS, 1, [Install test programs]) @@ -505,6 +521,8 @@ AC_CONFIG_FILES([ freedreno/libdrm_freedreno.pc tegra/Makefile tegra/libdrm_tegra.pc + vc4/Makefile + vc4/libdrm_vc4.pc tests/Makefile tests/modeprint/Makefile tests/modetest/Makefile @@ -535,4 +553,5 @@ echo " OMAP API $OMAP" echo " EXYNOS API $EXYNOS" echo " Freedreno API $FREEDRENO (kgsl: $FREEDRENO_KGSL)" echo " Tegra API $TEGRA" +echo " VC4 API$VC4" echo "" diff --git a/vc4/Makefile.am b/vc4/Makefile.am new file mode 100644 index 000..7e486b4 --- /dev/null +++ b/vc4/Makefile.am @@ -0,0 +1,34 @@ +# Copyright © 2016 Broadcom +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS +# IN THE SOFTWARE. + +include Makefile.sources + +AM_CFLAGS = \ + $(WARN_CFLAGS) \ + -I$(top_srcdir) \ + $(PTHREADSTUBS_CFLAGS) \ + $(VALGRIND_CFLAGS) \
[PATCH] vc4: Add headers and .pc files for VC4 userspace development.
The headers were originally written in Mesa, imported to the kernel, and improved upon in vc4-gpu-tools. These come from the v-g-t copies and will replace the Mesa and v-g-t copies, and hopefully be used from new tests in igt, as well. v2: Fix linking against libdrm_intel instead of libdrm. v3: Drop Libs and Cflags since they'll be inherited from libdrm. Signed-off-by: Eric Anholt --- Resend with git commit --amend actually done. Makefile.am | 6 + configure.ac | 19 +++ vc4/Makefile.am | 34 + vc4/Makefile.sources | 3 + vc4/libdrm_vc4.pc.in | 9 ++ vc4/vc4_packet.h | 397 ++ vc4/vc4_qpu_defines.h | 274 ++ 7 files changed, 742 insertions(+) create mode 100644 vc4/Makefile.am create mode 100644 vc4/Makefile.sources create mode 100644 vc4/libdrm_vc4.pc.in create mode 100644 vc4/vc4_packet.h create mode 100644 vc4/vc4_qpu_defines.h diff --git a/Makefile.am b/Makefile.am index ca41508..feecba7 100644 --- a/Makefile.am +++ b/Makefile.am @@ -29,6 +29,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \ --enable-radeon \ --enable-amdgpu \ --enable-nouveau \ + --enable-vc4 \ --enable-vmwgfx \ --enable-omap-experimental-api \ --enable-exynos-experimental-api \ @@ -79,6 +80,10 @@ if HAVE_TEGRA TEGRA_SUBDIR = tegra endif +if HAVE_VC4 +VC4_SUBDIR = vc4 +endif + if BUILD_MANPAGES if HAVE_MANPAGES_STYLESHEET MAN_SUBDIR = man @@ -96,6 +101,7 @@ SUBDIRS = \ $(EXYNOS_SUBDIR) \ $(FREEDRENO_SUBDIR) \ $(TEGRA_SUBDIR) \ + $(VC4_SUBDIR) \ tests \ $(MAN_SUBDIR) diff --git a/configure.ac b/configure.ac index a09be61..4dc5394 100644 --- a/configure.ac +++ b/configure.ac @@ -126,6 +126,11 @@ AC_ARG_ENABLE(tegra-experimental-api, [Enable support for Tegra's experimental API (default: disabled)]), [TEGRA=$enableval], [TEGRA=no]) +AC_ARG_ENABLE(vc4, + AS_HELP_STRING([--disable-vc4], + [Enable support for vc4's API (default: auto, enabled on arm)]), + [VC4=$enableval], [VC4=auto]) + AC_ARG_ENABLE(install-test-programs, AS_HELP_STRING([--enable-install-test-programs], [Install test programs (default: no)]), @@ -290,6 +295,12 @@ else *) FREEDRENO=no ;; esac fi + if test "x$VC4" = xauto; then + case $host_cpu in + arm*|aarch64) VC4=yes ;; + *) VC4=no ;; + esac + fi fi if test "x$INTEL" != "xno"; then @@ -396,6 +407,11 @@ if test "x$TEGRA" = xyes; then AC_DEFINE(HAVE_TEGRA, 1, [Have Tegra support]) fi +AM_CONDITIONAL(HAVE_VC4, [test "x$VC4" = xyes]) +if test "x$VC4" = xyes; then + AC_DEFINE(HAVE_VC4, 1, [Have VC4 support]) +fi + AM_CONDITIONAL(HAVE_INSTALL_TESTS, [test "x$INSTALL_TESTS" = xyes]) if test "x$INSTALL_TESTS" = xyes; then AC_DEFINE(HAVE_INSTALL_TESTS, 1, [Install test programs]) @@ -505,6 +521,8 @@ AC_CONFIG_FILES([ freedreno/libdrm_freedreno.pc tegra/Makefile tegra/libdrm_tegra.pc + vc4/Makefile + vc4/libdrm_vc4.pc tests/Makefile tests/modeprint/Makefile tests/modetest/Makefile @@ -535,4 +553,5 @@ echo " OMAP API $OMAP" echo " EXYNOS API $EXYNOS" echo " Freedreno API $FREEDRENO (kgsl: $FREEDRENO_KGSL)" echo " Tegra API $TEGRA" +echo " VC4 API$VC4" echo "" diff --git a/vc4/Makefile.am b/vc4/Makefile.am new file mode 100644 index 000..7e486b4 --- /dev/null +++ b/vc4/Makefile.am @@ -0,0 +1,34 @@ +# Copyright © 2016 Broadcom +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS +# IN THE SOFTWARE. + +include Makefile.sources + +AM_CFLAGS = \ + $(WARN_CFLAGS) \ + -I$(top_srcdir) \ + $(PTHR
[PATCH v2 03/26] clk: Add regmap support
On 01/14, Maxime Ripard wrote:
> From: Matthias Brugger
>
> Some devices like SoCs from Mediatek need to use the clock
> through a regmap interface.
> This patch adds regmap support for the simple multiplexer clock,
> the divider clock and the clock gate code.
>
> Signed-off-by: Matthias Brugger
> Signed-off-by: Maxime Ripard
Nak.
The whole anonymous union thing and clk-io.c file is not
appealing at all. I'd prefer we remove clk_readl/writel, not add
to it. Plus we're bloating the basic clock types and adding a
bunch of parallel registration APIs to assign a regmap pointer.
Really, let's stop adding stuff to the basic clock types, it's
getting out of hand.
To move forward on making regmap clks generic for everyone, let's
make sure that regmap clk code is a library that any driver can
use. No OF_CLK_DECLARE should exist because it doesn't make any
sense. No clk_register_regmap_{div,mux,gate}() functions, just a
clk_register_regmap() function to assign the regmap pointer from
the device. Drivers that want to use the code should need to
select a Kconfig symbol, so that we don't compile in support for
regmap clocks unless we really need them.
If we had a clk_regmap structure with a regmap pointer and a
clk_hw inside it I think that's all we would need. Once we had
that, we could let driver writers wrap that in their own
structures for dividers, muxes, gates, etc. and then have them
call library functions from their clk_ops that takes a regmap (or
clk_regmap struct), and offset to do the get_div/set_div,
get_parent/set_parent, enable/disable stuff.
The policy part can be shared with the basic clock types, because
we've already started libifying them. For example, we can ask the
divider code what the hardware value should be for a particular
divider type and it will tell us without writing any registers.
I had a patch for libifying muxes, not sure where it went. The
point being to leave the I/O part to the regmap code without
putting it behind another layer of indirection buried inside the
basic types. Make things flat and easy to follow.
I haven't thought through making new structs to hold the data for
offsets, masks, etc. but I guess we would want those so that we
could assign functions directly to clk_ops and not require any
boiler plate clk_ops implementations in drivers. There are a few
approaches here: different regmap structs for different basic
types, one mega struct that combines all the needs of the basic
types, or some private void pointer inside struct clk_regmap that
points to different basic type structs. Let's see how that goes.
Maybe we can lift drivers/clk/qcom/clk-regmap.c up into the
drivers/clk/ directory too. In the qcom design I put the
enable/disable bits (gate functionality) directly into the
clk_regmap structure. That may need some more thought if it was
the right idea to force enable/disable on every regmap clock
though. If we remove that and introduce a clk_regmap_gate things
should turn out alright.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
