dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[Bug 60254] New: agd5f wip kernel Oops when provoking GPU lock.
by bugzilla-daemon＠freedesktop.org 30 Jul '15

30 Jul '15

https://bugs.freedesktop.org/show_bug.cgi?id=60254 Priority: medium Bug ID: 60254 Assignee: dri-devel(a)lists.freedesktop.org Summary: agd5f wip kernel Oops when provoking GPU lock. Severity: normal Classification: Unclassified OS: All Reporter: lists(a)andyfurniss.entadsl.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI The GPU lock with Rv670 and openarena is nothing new - it seems to have been a feature for almost a year (I haven't used rv670 for most of that time). On noticing the new gpu reset code in drm-next-3.9-wip I decided to provoke it on my AGP box and got - Feb 3 20:46:56 nf7 kernel: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec Feb 3 20:46:56 nf7 kernel: radeon 0000:02:00.0: GPU lockup (waiting for 0x00000000000111c8 last fence id 0x00000000000111c6) Feb 3 20:46:56 nf7 kernel: radeon 0000:02:00.0: f51df600 unpin not necessary Feb 3 20:46:56 nf7 kernel: radeon 0000:02:00.0: Saved 217 dwords of commands on ring 0. Feb 3 20:46:56 nf7 kernel: BUG: unable to handle kernel paging request at f87aec0c Feb 3 20:46:56 nf7 kernel: IP: [<fa033a3e>] radeon_fence_process+0x7e/0x160 [radeon] Feb 3 20:46:56 nf7 kernel: *pde = 3702f067 *pte = 00000000 Feb 3 20:46:56 nf7 kernel: Oops: 0000 [#1] PREEMPT Feb 3 20:46:56 nf7 kernel: Modules linked in: radeon fbcon font bitblit ttm softcursor drm_kms_helper drm fb fbdev i2c_algo_bit i2c_core cfbcopyarea cfbimgblt cfbfillrect ehci_pci ehci_hcd nvidia_agp agpgart ohci_hcd usbhid usbcore usb_common snd_intel8x0 snd_ac97_codec ac97_bus forcedeth Feb 3 20:46:56 nf7 kernel: Pid: 2511, comm: openarena.i386 Not tainted 3.8.0-rc3-gc7fb5ff #1 /NF7-S/NF7 (nVidia-nForce2) Feb 3 20:46:56 nf7 kernel: EIP: 0060:[<fa033a3e>] EFLAGS: 00210246 CPU: 0 Feb 3 20:46:56 nf7 kernel: EIP is at radeon_fence_process+0x7e/0x160 [radeon] Feb 3 20:46:56 nf7 kernel: EAX: f87aec0c EBX: f73b2848 ECX: f73b2848 EDX: 00000000 Feb 3 20:46:56 nf7 kernel: ESI: 00000000 EDI: f73b2000 EBP: e4765d8c ESP: e4765d58 Feb 3 20:46:56 nf7 kernel: DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Feb 3 20:46:56 nf7 kernel: CR0: 8005003b CR2: f87aec0c CR3: 1e75f000 CR4: 000007d0 Feb 3 20:46:56 nf7 kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 Feb 3 20:46:56 nf7 kernel: DR6: ffff0ff0 DR7: 00000400 Feb 3 20:46:56 nf7 kernel: Process openarena.i386 (pid: 2511, ti=e4764000 task=f70ad2b0 task.ti=e4764000) Feb 3 20:46:56 nf7 kernel: Stack: Feb 3 20:46:56 nf7 kernel: c13d4e58 00765d7c 00000018 f73b2848 f73b2888 00000872 00000003 00000872 Feb 3 20:46:56 nf7 kernel: 00000000 0000000c 00000003 f73b2a5c e4765e0c e4765da4 fa034850 f73b2000 Feb 3 20:46:56 nf7 kernel: f73b2000 f73b2a5c e4765e0c e4765dc4 fa049bb8 f73b28e8 00000000 c12b06cd Feb 3 20:46:56 nf7 kernel: Call Trace: Feb 3 20:46:56 nf7 kernel: [<c13d4e58>] ? sub_preempt_count+0x8/0x80 Feb 3 20:46:56 nf7 kernel: [<fa034850>] radeon_fence_count_emitted+0x20/0x90 [radeon] Feb 3 20:46:56 nf7 kernel: [<fa049bb8>] radeon_ring_backup+0x38/0x100 [radeon] Feb 3 20:46:56 nf7 kernel: [<c12b06cd>] ? _dev_info+0x2d/0x30 Feb 3 20:46:56 nf7 kernel: [<fa020b22>] radeon_gpu_reset+0x62/0x1d0 [radeon] Feb 3 20:46:56 nf7 kernel: [<f8be99c6>] ? ttm_bo_unreserve+0x26/0x50 [ttm] Feb 3 20:46:56 nf7 kernel: [<fa04821d>] radeon_gem_handle_lockup.part.2+0xd/0x20 [radeon] Feb 3 20:46:56 nf7 kernel: [<fa048b13>] radeon_gem_wait_idle_ioctl+0xb3/0xd0 [radeon] Feb 3 20:46:56 nf7 kernel: [<fa048a60>] ? radeon_gem_busy_ioctl+0xf0/0xf0 [radeon] Feb 3 20:46:56 nf7 kernel: [<f8af9e82>] drm_ioctl+0x402/0x460 [drm] Feb 3 20:46:56 nf7 kernel: [<fa048a60>] ? radeon_gem_busy_ioctl+0xf0/0xf0 [radeon] Feb 3 20:46:56 nf7 kernel: [<c104f469>] ? ktime_add_safe+0x9/0x60 Feb 3 20:46:56 nf7 kernel: [<c104fe80>] ? hrtimer_forward+0xa0/0x190 Feb 3 20:46:56 nf7 kernel: [<f8af9a80>] ? drm_copy_field+0x80/0x80 [drm] Feb 3 20:46:56 nf7 kernel: [<c10eb65a>] do_vfs_ioctl+0x7a/0x590 Feb 3 20:46:56 nf7 kernel: [<c101ef0b>] ? lapic_next_event+0x1b/0x20 Feb 3 20:46:56 nf7 kernel: [<c106978d>] ? clockevents_program_event+0x9d/0x150 Feb 3 20:46:56 nf7 kernel: [<c106ab18>] ? tick_program_event+0x28/0x30 Feb 3 20:46:56 nf7 kernel: [<c1050612>] ? hrtimer_interrupt+0x182/0x2f0 Feb 3 20:46:56 nf7 kernel: [<c13d4e58>] ? sub_preempt_count+0x8/0x80 Feb 3 20:46:56 nf7 kernel: [<c1048cf9>] ? __rcu_read_unlock+0x9/0x60 Feb 3 20:46:56 nf7 kernel: [<c10f4bc7>] ? fget_light+0x77/0xd0 Feb 3 20:46:56 nf7 kernel: [<c10ebbac>] sys_ioctl+0x3c/0x70 Feb 3 20:46:56 nf7 kernel: [<c13d7ffa>] sysenter_do_call+0x12/0x22 Feb 3 20:46:56 nf7 kernel: Code: 8b 4d d4 8d 84 51 f0 00 00 00 8b 74 c7 08 89 75 e0 8b 74 c7 0c 8b 45 d8 83 c0 08 80 bf ec 0d 00 00 00 0f 84 bf 00 00 00 8b 40 0c <8b> 00 39 45 e8 8b 4d ec 89 c3 ba 01 00 00 00 0f 47 ce 39 f1 77 Feb 3 20:46:56 nf7 kernel: EIP: [<fa033a3e>] radeon_fence_process+0x7e/0x160 [radeon] SS:ESP 0068:e4765d58 Feb 3 20:46:56 nf7 kernel: CR2: 00000000f87aec0c Feb 3 20:46:56 nf7 kernel: ---[ end trace 457588a7cbc40235 ]--- -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions
by bugzilla-daemon＠freedesktop.org 30 Jul '15

30 Jul '15

https://bugs.freedesktop.org/show_bug.cgi?id=88493 Bug ID: 88493 Summary: No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: adf.lists(a)gmail.com R9270X - audio not perfect normally, but there is none at all after - bead330b1af6fce76aedac9f89d20edcaeae27b3 is the first bad commit commit bead330b1af6fce76aedac9f89d20edcaeae27b3 Author: Slava Grigorev <slava.grigorev(a)amd.com> Date: Tue Dec 2 15:22:43 2014 -0500 radeon/audio: consolidate audio_get_pin() functions There is also another minor issue on head, but I haven't had time to bisect and it doesn't always show. If I bring TV up after booting with TV off there are a few pix of pink on left of screen - doing anything that resets mode/on/off or if on from boot avoids. Didn't see it in the bisect - first was bad so I guess it's in the other half. -- You are receiving this mail because: You are the assignee for the bug.

1 18

[Bug 70227] New: OpenCL reaper-prime app crashes due to atomic_or unimplemented
by bugzilla-daemon＠freedesktop.org 29 Jul '15

29 Jul '15

https://bugs.freedesktop.org/show_bug.cgi?id=70227 Priority: medium Bug ID: 70227 Assignee: dri-devel(a)lists.freedesktop.org Summary: OpenCL reaper-prime app crashes due to atomic_or unimplemented Severity: normal Classification: Unclassified OS: All Reporter: alexxy(a)gentoo.org Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Miner app https://github.com/arnuschky/primecoin-reaper.git crashes with ./reaper \|||||||||||||||||||||/ - Reaper v13 64-bit - - PRIME BETA 2 - - coded by mtrlt - /|||||||||||||||||||||\ Warning: unknown property "use_gpu" in configuration file. I'm now mining primecoin! Share thread started GeneratePrimeTable() : setting nSievePercentage = 1, nSieveSize = 100000 GeneratePrimeTable() : prime table [1, 100000] generated with 9592 primes Available CPU mining algorithms: hp7 Using default: hp7 Creating 1 CPU thread. 1...Warning: can't set thread priority done List of platforms: 0 Default Using platform number 0 Using device 0 OpenCL device 0........ Compiling kernel... this could take up to 2 minutes. 2 warnings generated. Building kernel CalculateMultipliers Building kernel Sieve Building kernel Combine Building kernel Fermat done Compiling kernel... this could take up to 2 minutes. 2 warnings generated. Building kernel CalculateMultipliers Building kernel Sieve Building kernel Combine Building kernel Fermat 0x7f735cdadd00: i32 = GlobalAddress<i32 (...)* @atomic_or> 0 [ORD=104] Stack dump: 0. Running pass 'Function Pass Manager' on module 'radeon'. 1. Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function '@Sieve' Segmentation fault -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 88719] While using nine gallium tracker and wine Dark Souls 2 causes gpu hang
by bugzilla-daemon＠freedesktop.org 28 Jul '15

28 Jul '15

https://bugs.freedesktop.org/show_bug.cgi?id=88719 Bug ID: 88719 Summary: While using nine gallium tracker and wine Dark Souls 2 causes gpu hang Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: sobkas(a)gmail.com Created attachment 112683 --> https://bugs.freedesktop.org/attachment.cgi?id=112683&action=edit A console log from gpu hang While using nine gallium tracker and wine Dark Souls 2 causes gpu hang It happens in no mans wharf while entering shacks or in the last bonfire of old iron crown dlc. It can be worked around by adding R600_DEBUG=notiling to env. Kernel: 3.19.0-rc5-00119-gb942c65-dirty with resume patches: https://bugs.freedesktop.org/attachment.cgi?id=112527 https://bugs.freedesktop.org/attachment.cgi?id=112528 Mesa: I have tried mesa git master(bc6e57e019bd2399a70acabcad21217aadf2944c), https://github.com/iXit/Mesa-3D.git(both rebased on top of mesa git and clean 5ff32e24921c86b087085929e86720cc5b64be35 with additional fix for crash during the start) There was no difference Video card: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 6770] [1002:68ba] I have opened a bug on github: https://github.com/iXit/Mesa-3D/issues/63 and other person was able to reproduce it: https://github.com/iXit/Mesa-3D/issues/59#issuecomment-70933707 -- You are receiving this mail because: You are the assignee for the bug.

1 5

[PATCH RFC] drm/i2c: tda998x: dead-code or unhandled error condition ?
by Nicholas Mc Guire 28 Jul '15

28 Jul '15

event API conformance testing with coccinelle spatches are being used to locate API usage inconsistencies this triggert with: ./drivers/gpu/drm/i2c/tda998x_drv.c:1062 incorrect check for negative return The return of wait_event_timeout is always >= 0, thus the negative check was effectively being ignoring - as the timeout will be checked a few lines below the error condition being checked here seems to be wrong or this is simply dead code which would be my guess as the timeout condition check covers the wait-queue related failure condition. Signed-off-by: Nicholas Mc Guire <hofrat(a)osadl.org> --- Can't really determine what the right fix for this would be - someone that knows this driver would need to check - in any case the current code seems broken. Patch was compile tested with x86_64_defconfig + CONFIG_DRM_I2C_SIL164=m Patch is against 4.1-rc7 (localversion-next is -next-20150610) drivers/gpu/drm/i2c/tda998x_drv.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index fe1599d..d489a6e 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -1065,10 +1065,6 @@ static int read_edid_block(void *data, u8 *buf, unsigned int blk, size_t length) i = wait_event_timeout(priv->wq_edid, !priv->wq_edid_wait, msecs_to_jiffies(100)); - if (i < 0) { - dev_err(&priv->hdmi->dev, "read edid wait err %d\n", i); - return i; - } } else { for (i = 100; i > 0; i--) { msleep(1); -- 1.7.10.4

2 1

[PATCHv7 00/15] HDMI CEC framework
by Hans Verkuil 23 Jul '15

23 Jul '15

Hi all, The seventh version of this patchset addresses comments on the mailing list and many changes due to the work I did on the cec-compliance and cec-ctl utilities (will be posted in a separate patch series). Please see the changelog below for details. Note: I have taken over from Kamil: he no longer had the time to work on this, whereas I needed to get this working. Many thanks to Kamil for the work he did! While this is now in pretty good shape, there are a few TO DOs left before it can be merged: - Support for CDC messages needs to be improved (wrapper functions are needed, and the 'reply' functionality isn't working at the moment). - The documentation is out-of-sync and needs to be updated. - I need to verify the current driver against the CEC 2.0 spec. - Standby handling will need more work (should be a high-level callback, but I need to check which messages would cause the device to go out of standby). - More testing. - The CEC core currently stores physical addresses that were broadcast. But these are not yet communicated to userspace. I need to think about this (and how to handle similar broadcast messages). Best regards, Hans Changes since v6 ================ - added cec-funcs.h to provide wrapper functions that fill in the cec_msg struct. This header is needed both by the kernel and by applications. - fix a missing rc_unregister_device call. - added CEC support for the adv7842 and cobalt drivers. - added CEC operand defines. Rename CEC message defines to CEC_MSG_ and operand defines now use CEC_OP_. - the CEC_VERSION defines are dropped since we now have the CEC_OP_VERSION defines. - ditto: CEC_PRIM_DEVTYPE_ is now CEC_OP_PRIM_DEVTYPE. - ditto: CEC_FL_ALL_DEVTYPE_ is now CEC_OP_ALL_DEVTYPE. - cec-ioc-g-adap-log-addrs.xml: document cec_versions field. - cec-ioc-g-caps.xml: drop vendor_id and version fields. - add MAINTAINERS entry. - add CDC support (not yet fully functional). - add a second debug level for message debugging. - fix a nasty kernel Oops in cec_transmit_msg while waiting for transmit completion (adap->tx_queue[idx].func wasn't set to NULL). - add support for CEC_MSG_REPORT_FEATURES (CEC 2.0 only). - correctly abort unsupported messages. - add support for the device power status feature. - add support for the audio return channel (preliminary). - add support for the CDC hotplug message (preliminary). - added osd_name to struct cec_log_addrs. - reported physical addresses are stored internally. - fix enabling/disabling the CEC adapter (internal fields weren't cleared correctly). - zero reserved fields. - return an error if you try to receive/transmit and the adapter isn't configured. - when creating the adapter provide the owner module and the parent device. - add a CEC_VENDOR_ID_NONE define to signal if no vendor ID was set. - add new capabilities: RC (remote control), ARC (audio return channel) and CDC (Capability Discovery and Control). - applications that want to handle messages for a logical address need to set the CEC_LOG_ADDRS_FL_HANDLE_MSGS flag. Otherwise the CEC core will be the one handling all messages. - Each logical address has its own all_device_types value. So this should be an array, not a single value. - I'm sure I've forgotten some changes... Changes since v5 ================ - drop struct cec_timeval in favour of a __u64 that keeps the timestamp in ns - remove userspace documentation from Documentation/cec.txt as userspace API is described in the DocBook - add missing documentation for the passthrough mode to the DocBook - add information about the number of events that can be queued - fix misspelling of reply - fix behaviour of posting an event in cec_received_msg, such that the behaviour is consistent with the documentation Changes since v4 ================ - add sequence numbering to transmitted messages - add sequence number handling to event hanlding - add passthrough mode - change reserved field sizes - fixed CEC version defines and addec CEC 2.0 commands - add DocBook documentation Changes since v3 ================ - remove the promiscuous mode - rewrite the devicetree patches - fixes, expansion and partial rewrite of the documentation - reorder of API structures and addition of reserved fields - use own struct to report time (32/64 bit safe) - fix of handling events - add cec.h to include/uapi/linux/Kbuild - fixes in the adv76xx driver (add missing methods, change adv7604 to adv76xx) - cleanup of debug messages in s5p-cec driver - remove non necessary claiming of a gpio in the s5p-cec driver - cleanup headers of the s5p-cec driver Changes since v2 ===============- - added promiscuous mode - added new key codes to the input framework - add vendor ID reporting - add the possibility to clear assigned logical addresses - cleanup of the rc cec map Changes since v1 ================ - documentation edited and moved to the Documentation folder - added key up/down message handling - add missing CEC commands to the cec.h file Background ========== The work on a common CEC framework was started over three years ago by Hans Verkuil. Unfortunately the work has stalled. As I have received the task of creating a driver for the CEC interface module present on the Exynos range of SoCs, I got in touch with Hans. He replied that the work stalled due to his lack of time. Original RFC by Hans Verkuil/Martin Bugge ========================================= https://www.mail-archive.com/linux-media@vger.kernel.org/msg28735.html Hans Verkuil (9): input.h: add BUS_CEC type cec: add HDMI CEC framework cec.txt: add CEC framework documentation DocBook/media: add CEC documentation v4l2-subdev: add HDMI CEC ops cec: adv7604: add cec support. adv7842: add cec support cec: adv7511: add cec support. cobalt: add cec support Kamil Debski (6): dts: exynos4*: add HDMI CEC pin definition to pinctrl dts: exynos4: add node for the HDMI CEC device dts: exynos4412-odroid*: enable the HDMI CEC device HID: add HDMI CEC specific keycodes rc: Add HDMI CEC protocol handling cec: s5p-cec: Add s5p-cec driver Documentation/DocBook/media/Makefile | 2 + Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml | 74 + Documentation/DocBook/media/v4l/cec-func-close.xml | 59 + Documentation/DocBook/media/v4l/cec-func-ioctl.xml | 73 + Documentation/DocBook/media/v4l/cec-func-open.xml | 94 ++ Documentation/DocBook/media/v4l/cec-func-poll.xml | 89 ++ .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml | 299 ++++ .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml | 78 + .../DocBook/media/v4l/cec-ioc-g-adap-state.xml | 87 ++ Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml | 138 ++ .../DocBook/media/v4l/cec-ioc-g-event.xml | 125 ++ .../DocBook/media/v4l/cec-ioc-g-passthrough.xml | 88 ++ .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml | 70 + .../DocBook/media/v4l/cec-ioc-receive.xml | 185 +++ Documentation/DocBook/media_api.tmpl | 8 +- Documentation/cec.txt | 166 ++ .../devicetree/bindings/media/s5p-cec.txt | 31 + MAINTAINERS | 11 + arch/arm/boot/dts/exynos4.dtsi | 12 + arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 + arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 + arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 7 + drivers/media/Kconfig | 6 + drivers/media/Makefile | 2 + drivers/media/cec.c | 1580 ++++++++++++++++++++ drivers/media/i2c/adv7511.c | 350 ++++- drivers/media/i2c/adv7604.c | 219 ++- drivers/media/i2c/adv7842.c | 211 ++- drivers/media/pci/cobalt/cobalt-driver.c | 37 +- drivers/media/pci/cobalt/cobalt-driver.h | 2 + drivers/media/pci/cobalt/cobalt-v4l2.c | 110 +- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile | 1 + drivers/media/platform/s5p-cec/Makefile | 2 + drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 37 + .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 208 +++ drivers/media/platform/s5p-cec/regs-cec.h | 96 ++ drivers/media/platform/s5p-cec/s5p_cec.c | 283 ++++ drivers/media/platform/s5p-cec/s5p_cec.h | 76 + drivers/media/rc/keymaps/Makefile | 1 + drivers/media/rc/keymaps/rc-cec.c | 144 ++ drivers/media/rc/rc-main.c | 1 + include/media/adv7511.h | 6 +- include/media/cec.h | 161 ++ include/media/rc-core.h | 1 + include/media/rc-map.h | 5 +- include/media/v4l2-subdev.h | 9 + include/uapi/linux/Kbuild | 2 + include/uapi/linux/cec-funcs.h | 1516 +++++++++++++++++++ include/uapi/linux/cec.h | 709 +++++++++ include/uapi/linux/input.h | 13 + 52 files changed, 7485 insertions(+), 30 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/cec-api.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-close.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-ioctl.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-open.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-poll.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-state.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-event.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-passthrough.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-vendor-id.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml create mode 100644 Documentation/cec.txt create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt create mode 100644 drivers/media/cec.c create mode 100644 drivers/media/platform/s5p-cec/Makefile create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h create mode 100644 drivers/media/rc/keymaps/rc-cec.c create mode 100644 include/media/cec.h create mode 100644 include/uapi/linux/cec-funcs.h create mode 100644 include/uapi/linux/cec.h -- 2.1.4

6 23

[Bug 90681] Radeon Kernel Oops & Lockup when switching on DisplayPort attached monitor
by bugzilla-daemon＠freedesktop.org 21 Jul '15

21 Jul '15

https://bugs.freedesktop.org/show_bug.cgi?id=90681 Bug ID: 90681 Summary: Radeon Kernel Oops & Lockup when switching on DisplayPort attached monitor Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: bradfirj(a)fstab.me Created attachment 116079 --> https://bugs.freedesktop.org/attachment.cgi?id=116079&action=edit journalctl output for crash Switching my DisplayPort attached monitor on (or off and then on again) while booted to multiuser target (no Xorg or Wayland) causes a kernel Oops, followed by soft-lockups which render the system unusable. Doing the same while at the full Graphical target causes gnome-shell to crash, but it is possible to recover the system by logging in again. The kernel error and IP are: >May 24 23:25:28 fedora-workstation.home kernel: BUG: unable to handle kernel NULL pointer dereference at 00000000000003b0 >May 24 23:25:28 fedora-workstation.home kernel: IP: [<ffffffffa0152055>] radeon_connector_edid+0x5/0x70 [radeon] Full journal from a reproduction of the bug will be attached, as will lspci -nn. I have isolated this using git bisect to the following commit (the patch for which is attached to this bug). This is a commit currently part of the linux-stable tree and lies between 4.0.2 and 4.0.3 >016a255b7835ee7e49a3eba3c14ba0bc0221a4f8 is the first bad commit >commit 016a255b7835ee7e49a3eba3c14ba0bc0221a4f8 >Author: Alex Deucher <alexander.deucher(a)amd.com> >Date: Tue Apr 7 09:52:42 2015 -0400 > > drm/radeon: only mark audio as connected if the monitor supports it (v3) > > commit 0f55db36d49d45b80eff0c0a2a498766016f458b upstream. > > Otherwise the driver may try and send audio which may confuse the > monitor. > > v2: set pin to NULL if no audio > v3: avoid crash with analog encoders > > Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>> > >:040000 040000 de0366a6790f5c91d175bcb89cb34956bbe72b26 >bbdb5734961f824558152c7c34a840c78bc3a9a9 M drivers -- You are receiving this mail because: You are the assignee for the bug.

1 14

[PATCH v2 0/5] drm/rockchip: support yuv overlay and plane scale
by Mark Yao 21 Jul '15

21 Jul '15

This series patches are used for yuv image overlay display. Rockchip vop support NV11, NV16, NV24 yuv format, and can scale the image scale 1/8 to 8. Changes in v2: - Uv buffer not support odd offset, align it. - Fix error display when move yuv image. - Fix scale dest info. Mark Yao (5): drm/rockchip: vop: optimize virtual stride calculate drm/rockchip: vop: fix yuv plane support drm/rockchip: vop: support plane scale drm/rockchip: vop: switch cursor plane to window 3 drm/rockchip: default enable win2/3 area0 bit drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 467 ++++++++++++++++++++++++++- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 96 ++++++ 2 files changed, 551 insertions(+), 12 deletions(-) -- 1.7.9.5

4 23

[v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control
by Shobhit Kumar 21 Jul '15

21 Jul '15

Hi, Next update of the series reviewed at https://lkml.org/lkml/2015/6/22/155 Major changes are few review comments from Varka and Ville being addressed. Also except for intel-gfx patches, all patches reviesion history is moved out of commit message. Hope this series finally finds its mark. Regards Shobhit Shobhit Kumar (7): gpiolib: Add support for removing registered consumer lookup table mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM pwm: crc: Add Crystalcove (CRC) PWM driver drm/i915: Use the CRC gpio for panel enable/disable drm/i915: Backlight control using CRC PMIC based PWM driver drivers/gpio/gpiolib.c | 13 ++++ drivers/gpu/drm/i915/intel_bios.h | 7 ++ drivers/gpu/drm/i915/intel_drv.h | 4 ++ drivers/gpu/drm/i915/intel_dsi.c | 37 +++++++++- drivers/gpu/drm/i915/intel_dsi.h | 3 + drivers/gpu/drm/i915/intel_panel.c | 94 ++++++++++++++++++++++-- drivers/mfd/intel_soc_pmic_core.c | 29 ++++++++ drivers/mfd/intel_soc_pmic_crc.c | 3 + drivers/pwm/Kconfig | 7 ++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-crc.c | 143 +++++++++++++++++++++++++++++++++++++ include/linux/gpio/machine.h | 1 + 12 files changed, 335 insertions(+), 7 deletions(-) create mode 100644 drivers/pwm/pwm-crc.c -- 1.9.1

8 17

Re: [PATCH v2 00/10] Color Manager Implementation
by Damien Lespiau 15 Jul '15

15 Jul '15

On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: > From: Kausal Malladi <Kausal.Malladi(a)intel.com> > > This patch set adds color manager implementation in drm/i915 layer. > Color Manager is an extension in i915 driver to support color > correction/enhancement. Various Intel platforms support several > color correction capabilities. Color Manager provides abstraction > of these properties and allows a user space UI agent to > correct/enhance the display. So I did a first rough pass on the API itself. The big question that isn't solved at the moment is: do we want to try to do generic KMS properties for pre-LUT + matrix + post-LUT or not. "Generic" has 3 levels: 1/ Generic for all KMS drivers 2/ Generic for i915 supported platfoms 3/ Specific to each platform At this point, I'm quite tempted to say we should give 1/ a shot. We should be able to have pre-LUT + matrix + post-LUT on CRTC objects and guarantee that, when the drivers expose such properties, user space can at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. It may be possible to use the "try" version of the atomic ioctl to explore the space of possibilities from a generic user space to use bigger LUTs as well. A HAL layer (which is already there in some but not all OSes) would still be able to use those generic properties to load "precision optimized" LUTs with some knowledge of the hardware. Option 3/ is, IMHO, a no-go, we should really try hard to limit the work we need to do per-platform, which means defining a common format for the values we give to the kernel. As stated in various places, 16.16 seems the format of choice, even for the LUTs as we have wide gamut support in some of the LUTs where we can map values > 1.0 to other values > 1.0. Another thing, the documentation of the interface needs to be a bit more crisp. For instance, we don't currently define the order in which the CSC and LUT transforms of this patch set are applied: is this a de-gamma LUT to do the CSC in linear space? but then that means the display is linear, oops. So it must be a post-CSC lut, but then we don't de-gamma sRGB (not technically a single gamma power curve for sRGB, but details, details) before applying a linear transform. So with this interface, we have to enforce the fbs are linear, losing dynamic range. I'm sure later patches would expose more properties, but as a stand-alone patch set, it would seem we can't do anything useful? -- Damien

5 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015