[patch 2/2] drm/exynos: mic: remove some dead code
On Fri, Mar 25, 2016 at 05:51:20PM +0900, Inki Dae wrote: > Hi Dan, > > 2016ë 03ì 17ì¼ 19:39ì Dan Carpenter ì´(ê°) ì´ ê¸: > > We know "ret" is zero and the test makes static checkers complain so > > let's delete this printk. > > > > Signed-off-by: Dan Carpenter > > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c > > b/drivers/gpu/drm/exynos/exynos_drm_mic.c > > index 890c9b1..12db353 100644 > > --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c > > +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c > > @@ -130,8 +130,6 @@ static void mic_set_path(struct exynos_mic *mic, bool > > enable) > > val &= ~(MIC0_RGB_MUX | MIC0_I80_MUX | MIC0_ON_MUX); > > > > regmap_write(mic->sysreg, DSD_CFG_MUX, val); > > - if (ret) > > - DRM_ERROR("mic: Failed to read system register\n"); > > I think we missed to keep return value from regmap_write function, > ret = regmap_write(mic->sysreg, ); > if (ret) > ... Yeah. You're right. regards, dan carpenter
[patch 2/2 v2] drm/exynos: fix a warning message
The "ret = regmap_write()" assignment was missing so this error message is never printed. Signed-off-by: Dan Carpenter --- v2: in v1 I just deleted the error message diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c index 9869d70..ea2ea17 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c @@ -129,7 +129,7 @@ static void mic_set_path(struct exynos_mic *mic, bool enable) } else val &= ~(MIC0_RGB_MUX | MIC0_I80_MUX | MIC0_ON_MUX); - regmap_write(mic->sysreg, DSD_CFG_MUX, val); + ret = regmap_write(mic->sysreg, DSD_CFG_MUX, val); if (ret) DRM_ERROR("mic: Failed to read system register\n"); }
[RFC 1/5] drm: Add DRM support for tiny LCD displays
Den 23.03.2016 18:37, skrev David Herrmann: > Hey > > On Wed, Mar 16, 2016 at 2:34 PM, Noralf Trønnes > wrote: >> tinydrm provides a very simplified view of DRM for displays that has >> onboard video memory and is connected through a slow bus like SPI/I2C. >> >> Signed-off-by: Noralf Trønnes >> --- [...] >> +static struct drm_driver tinydrm_driver = { >> + .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME >> + | DRIVER_ATOMIC, >> + .load = tinydrm_load, >> + .lastclose = tinydrm_lastclose, >> +// .unload = tinydrm_unload, >> + .get_vblank_counter = drm_vblank_count, >> +// .enable_vblank = tinydrm_enable_vblank, >> +// .disable_vblank = tinydrm_disable_vblank, >> + .gem_free_object= drm_gem_cma_free_object, >> + .gem_vm_ops = &drm_gem_cma_vm_ops, >> + .prime_handle_to_fd = drm_gem_prime_handle_to_fd, >> + .prime_fd_to_handle = drm_gem_prime_fd_to_handle, >> + .gem_prime_import = drm_gem_prime_import, >> + .gem_prime_export = drm_gem_prime_export, >> + .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, >> + .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, >> + .gem_prime_vmap = drm_gem_cma_prime_vmap, >> + .gem_prime_vunmap = drm_gem_cma_prime_vunmap, >> + .gem_prime_mmap = drm_gem_cma_prime_mmap, >> + .dumb_create= drm_gem_cma_dumb_create, >> + .dumb_map_offset= drm_gem_cma_dumb_map_offset, >> + .dumb_destroy = drm_gem_dumb_destroy, >> + .fops = &tinydrm_fops, >> + .name = "tinydrm", >> + .desc = "tinydrm", >> + .date = "20150916", > Can we just drop "date" and "desc" from new drivers? It doesn't add any value. > >> + .major = 1, >> + .minor = 0, >> +}; >> + >> +void tinydrm_release(struct tinydrm_device *tdev) > We usually prefer "unregister()" to stay consistent with "register()". Sure. >> +{ >> + DRM_DEBUG_KMS("\n"); >> + >> + if (tdev->deferred) >> + cancel_delayed_work_sync(&tdev->deferred->dwork); >> + >> + tinydrm_fbdev_fini(tdev); >> + >> + drm_panel_detach(&tdev->panel); >> + drm_panel_remove(&tdev->panel); >> + >> + drm_mode_config_cleanup(tdev->base); >> + drm_dev_unregister(tdev->base); >> + drm_dev_unref(tdev->base); >> +} >> +EXPORT_SYMBOL(tinydrm_release); >> + >> +int tinydrm_register(struct device *dev, struct tinydrm_device *tdev) >> +{ >> + struct drm_driver *driver = &tinydrm_driver; >> + struct drm_device *ddev; >> + int ret; >> + >> + dev_info(dev, "%s\n", __func__); >> + >> +dev->coherent_dma_mask = DMA_BIT_MASK(32); >> + >> + if (WARN_ON(!tdev->dirtyfb)) >> + return -EINVAL; >> + >> + ddev = drm_dev_alloc(driver, dev); >> + if (!ddev) >> + return -ENOMEM; >> + >> + tdev->base = ddev; >> + ddev->dev_private = tdev; >> + >> + ret = drm_dev_set_unique(ddev, dev_name(ddev->dev)); >> + if (ret) >> + goto err_free; >> + >> + ret = drm_dev_register(ddev, 0); >> + if (ret) >> + goto err_free; > Whatever your .load() callback does, do that here and drop it. It is > really not needed. Optionally do it before calling drm_dev_register(), > depending on which semantics you want. Ok. > In general, this looks very similar to what I did with SimpleDRM. SimpleDRM was the first drm code I studied and tinydrm started with chunks of code from it :-) > However, I wonder whether we can make it more modular. Right now it > always adds code for fbdev, CMA, backlight, etc., but as Daniel > mentioned those better live in DRM-core helpers. Yes I will make the next version more modular. Instead of trying to guess which parts would fit as core helpers, I just put everything into one module and posted an RFC hoping to get some feedback. I will try an implement the suggestions Daniel has made. > I'll try forward porting the SimpleDRM drivers to it, and let you know > whether it works out. > > Thanks > David
[Bug 94708] Open source radeon drivers not working properly with Radeon HD 8550M
https://bugs.freedesktop.org/show_bug.cgi?id=94708 Bug ID: 94708 Summary: Open source radeon drivers not working properly with Radeon HD 8550M Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: markotikvic at gmail.com Dear Maintainer, I have a Lenovo laptop with hybrid AMD/Intel graphics cards. I would like to use the discrete Radeon card for heavy rendering operations such as game development and gaming. Output of xrandr --listproviders: Provider 0: id: 0x76 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 4 associated providers: 1 name:Intel Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 1 name:radeon But I get lower fps when I run games with discrete GPU: xrandr --setprovideroffloadsink radeon Intel env DRI_PRIME=1 <- results in barely 20 fps for Dota 2 than if I run them with integrated Intel's card: env DRI_PRIME=0 <- results in 50-60 fps for Dota 2 The output of DRI_PRIME=0 glxinfo | grep 'OpenGL renderer' is: OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile and the ouput of DRI_PRIME=1 glxinfo | grep 'OpenGL renderer' is: OpenGL renderer string: Gallium 0.4 on AMD HAINAN >From dmesg I can see this error occuring after starting the game with DRI_PRIME=1 flag set: [ 1406.107887] [drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0 [ 1406.107892] [drm] PCIE gen 2 link speeds already enabled [ 1406.110997] [drm] PCIE GART of 1024M enabled (table at 0x0004). [ 1406.111090] radeon :0a:00.0: WB enabled [ 1406.111093] radeon :0a:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x88009ae5bc00 [ 1406.111094] radeon :0a:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0x88009ae5bc04 [ 1406.111096] radeon :0a:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x88009ae5bc08 [ 1406.111097] radeon :0a:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0x88009ae5bc0c [ 1406.111098] radeon :0a:00.0: fence driver on ring 4 use gpu addr 0x8c10 and cpu addr 0x88009ae5bc10 [ 1406.305207] [drm] ring test on 0 succeeded in 1 usecs [ 1406.305213] [drm] ring test on 1 succeeded in 1 usecs [ 1406.305218] [drm] ring test on 2 succeeded in 1 usecs [ 1406.305226] [drm] ring test on 3 succeeded in 4 usecs [ 1406.305233] [drm] ring test on 4 succeeded in 4 usecs [ 1406.305294] [drm] ib test on ring 0 succeeded in 0 usecs [ 1406.305347] [drm] ib test on ring 1 succeeded in 0 usecs [ 1406.305399] [drm] ib test on ring 2 succeeded in 0 usecs [ 1406.305412] [drm] ib test on ring 3 succeeded in 0 usecs [ 1406.305424] [drm] ib test on ring 4 succeeded in 0 usecs [ 1406.305677] [drm:si_dpm_set_power_state] *ERROR* si_upload_sw_state failed I know the GPU is being used because the vgaswitcheroo shows it as DynPwr when I run apps with it. What I would expect to see is performance AT LEAST as good as integrated GPU, instead I get a very bad performance. The poor perfomance is also observable when I run Unity 3D editor (with DRI_PRIME=1) in terms of screen tearing and system freezing. I also tried running the game with vblank_mode=0 option but it had no effect on performance. The scenario is similar with any app I run with DRI_PRIME=1 and it's mostly noticeable with screen tearing. Kernel version: Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux I have searched tons of forum threads and websites and I couldn't find a solution (there were some similar open and unresolved threads but nothing useful), so I turn to you for some hardcore professional help. Is there anything I can try to fix this? Oh, I also tried using LXDE desktop but it made no difference, the problems were the same. Let me know if you need other logs and outputs in order to figure this thing out. I am more than happy to help. Thank you in advance, Marko. P.S. Forgive me if I've post this to the wrong package thread but it definitely has something to do with DRI/radeon/xserver package(s). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/568cfb84/attachment.html>
[Bug 94692] Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0"
https://bugs.freedesktop.org/show_bug.cgi?id=94692 Nicholas Vaughan changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Nicholas Vaughan --- (In reply to Alex Deucher from comment #3) > Created attachment 122546 [details] [review] > fix > > The attached patch will be applied upstream and onto the stable kernel > series. Thank you very much. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/672a0b30/attachment.html>
[patch 2/2] drm/exynos: mic: remove some dead code
Hi Dan, 2016ë 03ì 17ì¼ 19:39ì Dan Carpenter ì´(ê°) ì´ ê¸: > We know "ret" is zero and the test makes static checkers complain so > let's delete this printk. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c > b/drivers/gpu/drm/exynos/exynos_drm_mic.c > index 890c9b1..12db353 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c > @@ -130,8 +130,6 @@ static void mic_set_path(struct exynos_mic *mic, bool > enable) > val &= ~(MIC0_RGB_MUX | MIC0_I80_MUX | MIC0_ON_MUX); > > regmap_write(mic->sysreg, DSD_CFG_MUX, val); > - if (ret) > - DRM_ERROR("mic: Failed to read system register\n"); I think we missed to keep return value from regmap_write function, ret = regmap_write(mic->sysreg, ); if (ret) ... Thanks, Inki Dae > } > > static int mic_sw_reset(struct exynos_mic *mic) > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >
[Bug 94705] [radeonsi] blue ground in Company of Heroes 2
https://bugs.freedesktop.org/show_bug.cgi?id=94705 Laurent carlier changed: What|Removed |Added Attachment #122566|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/b504d865/attachment.html>
[Bug 94705] [radeonsi] blue ground in Company of Heroes 2
https://bugs.freedesktop.org/show_bug.cgi?id=94705 Bug ID: 94705 Summary: [radeonsi] blue ground in Company of Heroes 2 Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: lordheavym at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 122566 --> https://bugs.freedesktop.org/attachment.cgi?id=122566&action=edit battlefield with some blue ground * radeon Tonga (was the same with Pitcairn) * kernel 4.5.0 * mesa-git 511ce29 * llvm-svn r264392 Please note that it isn't a regression, this bug is present since the release of the game for Linux Here is the link to an apitrace: https://drive.google.com/file/d/0B1WCo3k21FK3NW9DaGZpR1cxWjA/view?usp=sharing -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/77669c50/attachment.html>
[Bug 115141] radeon kernel module hangs suspend
https://bugzilla.kernel.org/show_bug.cgi?id=115141 --- Comment #7 from Eugene Shalygin --- Indeed, mine is Clevo P177SM -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 115141] radeon kernel module hangs suspend
https://bugzilla.kernel.org/show_bug.cgi?id=115141 --- Comment #6 from Alex Deucher --- This is a duplicate of bug 112781. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 115141] radeon kernel module hangs suspend
https://bugzilla.kernel.org/show_bug.cgi?id=115141 --- Comment #5 from Eugene Shalygin --- commit f95429eccc570dc45d589c327bfcfddcdc3e8228. Reverting that makes suspend work with 4.5.0. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94692] Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0"
https://bugs.freedesktop.org/show_bug.cgi?id=94692 --- Comment #3 from Alex Deucher --- Created attachment 122546 --> https://bugs.freedesktop.org/attachment.cgi?id=122546&action=edit fix The attached patch will be applied upstream and onto the stable kernel series. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/8bb9615f/attachment.html>
[Bug 92260] ASUS [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=92260 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Alex Deucher --- Already added in: commit 2b02ec79004388a8c65e227bc289ed891b5ac8c6 Author: Alex Deucher Date: Fri Oct 2 16:12:07 2015 -0400 drm/radeon: add quirk for ASUS R7 370 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92260 Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c index e9115d3..e72bf46 100644 --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -2928,6 +2928,7 @@ static struct si_dpm_quirk si_dpm_quirk_list[] = { { PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0xe271, 0, 12 }, { PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 9 }, { PCI_VENDOR_ID_ATI, 0x6811, 0x1762, 0x2015, 0, 12 }, + { PCI_VENDOR_ID_ATI, 0x6811, 0x1043, 0x2015, 0, 12 }, { 0, 0, 0, 0 }, }; -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/a31260fe/attachment.html>
[PATCHv14 18/18] cec: add ARC and CDC support
From: Hans Verkuil Preliminary ARC and CDC support. Untested and experimental! Signed-off-by: Hans Verkuil --- .../DocBook/media/v4l/cec-ioc-adap-g-caps.xml | 10 ++ Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml | 36 Documentation/cec.txt | 75 drivers/media/cec.c| 198 - drivers/media/pci/cobalt/cobalt-driver.c | 4 +- drivers/media/pci/cobalt/cobalt-v4l2.c | 37 include/media/cec.h| 11 ++ include/uapi/linux/cec.h | 5 + 8 files changed, 372 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml b/Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml index 7b22bf3..648ad3c 100644 --- a/Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml +++ b/Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml @@ -135,6 +135,16 @@ This CEC adapter is an HDMI source, &ie; it has an HDMI output connector. + + CEC_CAP_ARC + 0x0080 + This adapter supports the Audio Return Channel protocol. + + + CEC_CAP_CDC_HPD + 0x0100 + This adapter supports the hotplug detect protocol over CDC. + diff --git a/Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml b/Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml index c6260ae..b08b0c4 100644 --- a/Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml +++ b/Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml @@ -187,6 +187,42 @@ The follower can of course always call &CEC-TRANSMIT;. &cs-def; + CEC_MSG_INITIATE_ARC + + + + CEC_MSG_TERMINATE_ARC + + + + CEC_MSG_REQUEST_ARC_INITIATION + + + + CEC_MSG_REQUEST_ARC_TERMINATION + + + + CEC_MSG_REPORT_ARC_INITIATED + + + + CEC_MSG_REPORT_ARC_TERMINATED + If CEC_CAP_ARC is not set, then just pass + it on to userspace for processing. However, if CEC_CAP_ARC is + set, then the core framework processes this message and userspace will + not see it, not even in passthrough mode. + + + CEC_MSG_CDC_MESSAGE + If CEC_CAP_CDC_HPD is not set, then just pass + it on to userspace for processing. Do the same if the CDC command is not + one of CEC_MSG_CDC_HPD_REPORT_STATE or + CEC_MSG_CDC_HPD_SET_STATE. Else the core framework + processes this message and userspace will not see it, not even in passthrough + mode. + + CEC_MSG_GET_CEC_VERSION When in passthrough mode this message has to be handled by userspace, otherwise the core will return the CEC version that was set with &CEC-ADAP-S-LOG-ADDRS;. diff --git a/Documentation/cec.txt b/Documentation/cec.txt index 9d62a02..52bf1f3 100644 --- a/Documentation/cec.txt +++ b/Documentation/cec.txt @@ -217,6 +217,16 @@ struct cec_adap_ops { /* High-level CEC message callback */ int (*received)(struct cec_adapter *adap, struct cec_msg *msg); + + /* High-level CDC Hotplug Detect callbacks */ + u8 (*source_cdc_hpd)(struct cec_adapter *adap, u8 cdc_hpd_state); + void (*sink_cdc_hpd)(struct cec_adapter *adap, u8 cdc_hpd_state, u8 cdc_hpd_error); + + /* High-level Audio Return Channel callbacks */ + int (*sink_initiate_arc)(struct cec_adapter *adap); + int (*sink_terminate_arc)(struct cec_adapter *adap); + int (*source_arc_initiated)(struct cec_adapter *adap); + int (*source_arc_terminated)(struct cec_adapter *adap); }; The received() callback allows the driver to optionally handle a newly @@ -229,6 +239,62 @@ callback. If it doesn't want to handle this message, then it should return -ENOMSG, otherwise the CEC framework assumes it processed this message and it will not no anything with it. +The other callbacks deal with two CEC features: CDC Hotplug Detect and +Audio Return Channel. Here the framework takes care of handling these +messages and it calls the callbacks to notify the driver when it needs +to take action. + +CDC Hotplug Support +--- + +A source received a hotplug state change message: + + u8 (*source_cdc_hpd)(struct cec_adapter *adap, u8 cdc_hpd_state); + +A source received a CEC_MSG_CDC_HPD_SET_STATE message. The framework will +reply with a CEC_MSG_CDC_HPD_REPORT_STATE message and this callback is used +to fill in the HPD Error Code Operand of the REPORT_STATE message. In addition, +the driver can act in this callback on the hotplug state change. + +Only implement if CEC_CAP_CDC_HPD is set.
[PATCHv14 17/18] vivid: add CEC emulation
From: Hans Verkuil The vivid driver has been extended to provide CEC adapters for the HDMI input and HDMI outputs in order to test CEC applications. This CEC emulation is faithful to the CEC timings (i.e., it all at a snail's pace). Signed-off-by: Hans Verkuil --- Documentation/video4linux/vivid.txt | 36 ++- drivers/media/platform/vivid/Kconfig | 1 + drivers/media/platform/vivid/vivid-core.c| 354 ++- drivers/media/platform/vivid/vivid-core.h| 27 ++ drivers/media/platform/vivid/vivid-kthread-cap.c | 11 + drivers/media/platform/vivid/vivid-vid-cap.c | 20 +- drivers/media/platform/vivid/vivid-vid-common.c | 7 + 7 files changed, 441 insertions(+), 15 deletions(-) diff --git a/Documentation/video4linux/vivid.txt b/Documentation/video4linux/vivid.txt index e35d376..0d89715 100644 --- a/Documentation/video4linux/vivid.txt +++ b/Documentation/video4linux/vivid.txt @@ -74,7 +74,8 @@ Section 11: Cropping, Composing, Scaling Section 12: Formats Section 13: Capture Overlay Section 14: Output Overlay -Section 15: Some Future Improvements +Section 15: CEC (Consumer Electronics Control) +Section 16: Some Future Improvements Section 1: Configuring the driver @@ -364,7 +365,11 @@ For HDMI inputs it is possible to set the EDID. By default a simple EDID is provided. You can only set the EDID for HDMI inputs. Internally, however, the EDID is shared between all HDMI inputs. -No interpretation is done of the EDID data. +No interpretation is done of the EDID data with the exception of the +physical address. See the CEC section for more details. + +There is a maximum of 15 HDMI inputs (if there are more, then they will be +reduced to 15) since that's the limitation of the EDID physical address. Section 3: Video Output @@ -409,6 +414,9 @@ standard, and for all others a 1:1 pixel aspect ratio is returned. An HDMI output has a valid EDID which can be obtained through VIDIOC_G_EDID. +There is a maximum of 15 HDMI outputs (if there are more, then they will be +reduced to 15) since that's the limitation of the EDID physical address. See +also the CEC section for more details. Section 4: VBI Capture -- @@ -1108,7 +1116,26 @@ capabilities will slow down the video loop considerably as a lot of checks have to be done per pixel. -Section 15: Some Future Improvements +Section 15: CEC (Consumer Electronics Control) +-- + +If there are HDMI inputs then a CEC adapter will be created that has +the same number of input ports. This is the equivalent of e.g. a TV that +has that number of inputs. Each HDMI output will also create a +CEC adapter that is hooked up to the corresponding input port, or (if there +are more outputs than inputs) is not hooked up at all. In other words, +this is the equivalent of hooking up each output device to an input port of +the TV. Any remaining output devices remain unconnected. + +The EDID that each output reads reports a unique CEC physical address that is +based on the physical address of the EDID of the input. So if the EDID of the +receiver has physical address A.B.0.0, then each output will see an EDID +containing physical address A.B.C.0 where C is 1 to the number of inputs. If +there are more outputs than inputs then the remaining outputs have a CEC adapter +that is disabled and reports an invalid physical address. + + +Section 16: Some Future Improvements Just as a reminder and in no particular order: @@ -1121,8 +1148,6 @@ Just as a reminder and in no particular order: - Fix sequence/field numbering when looping of video with alternate fields - Add support for V4L2_CID_BG_COLOR for video outputs - Add ARGB888 overlay support: better testing of the alpha channel -- Add custom DV timings support -- Add support for V4L2_DV_FL_REDUCED_FPS - Improve pixel aspect support in the tpg code by passing a real v4l2_fract - Use per-queue locks and/or per-device locks to improve throughput - Add support to loop from a specific output to a specific input across @@ -1133,3 +1158,4 @@ Just as a reminder and in no particular order: - Make a thread for the RDS generation, that would help in particular for the "Controls" RDS Rx I/O Mode as the read-only RDS controls could be updated in real-time. +- Changing the EDID should cause hotplug detect emulation to happen. diff --git a/drivers/media/platform/vivid/Kconfig b/drivers/media/platform/vivid/Kconfig index 0885e93..8645bb6 100644 --- a/drivers/media/platform/vivid/Kconfig +++ b/drivers/media/platform/vivid/Kconfig @@ -6,6 +6,7 @@ config VIDEO_VIVID select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT + select MEDIA_CEC select VIDEOBUF2_VMALLOC default n ---help--- diff --git a/drivers/media/platform/vivid/vivid-core.c b/drivers/media/platform/vivid/vivid-core.c index ec125bec..a
[PATCHv14 16/18] cec: s5p-cec: Add s5p-cec driver
From: Kamil Debski Add CEC interface driver present in the Samsung Exynos range of SoCs. The following files were based on work by SangPil Moon: - exynos_hdmi_cec.h - exynos_hdmi_cecctl.c Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- .../devicetree/bindings/media/s5p-cec.txt | 31 +++ MAINTAINERS| 7 + drivers/media/platform/Kconfig | 12 + drivers/media/platform/Makefile| 1 + drivers/media/platform/s5p-cec/Makefile| 2 + drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 38 +++ .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 210 +++ drivers/media/platform/s5p-cec/regs-cec.h | 96 +++ drivers/media/platform/s5p-cec/s5p_cec.c | 294 + drivers/media/platform/s5p-cec/s5p_cec.h | 76 ++ 10 files changed, 767 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt 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 diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt b/Documentation/devicetree/bindings/media/s5p-cec.txt new file mode 100644 index 000..925ab4d --- /dev/null +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt @@ -0,0 +1,31 @@ +* Samsung HDMI CEC driver + +The HDMI CEC module is present is Samsung SoCs and its purpose is to +handle communication between HDMI connected devices over the CEC bus. + +Required properties: + - compatible : value should be following + "samsung,s5p-cec" + + - reg : Physical base address of the IP registers and length of memory + mapped region. + + - interrupts : HDMI CEC interrupt number to the CPU. + - clocks : from common clock binding: handle to HDMI CEC clock. + - clock-names : from common clock binding: must contain "hdmicec", + corresponding to entry in the clocks property. + - samsung,syscon-phandle - phandle to the PMU system controller + +Example: + +hdmicec: cec at 100B { + compatible = "samsung,s5p-cec"; + reg = <0x100B 0x200>; + interrupts = <0 114 0>; + clocks = <&clock CLK_HDMI_CEC>; + clock-names = "hdmicec"; + samsung,syscon-phandle = <&pmu_system_controller>; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_cec>; + status = "okay"; +}; diff --git a/MAINTAINERS b/MAINTAINERS index 9b10806..1eb422b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1543,6 +1543,13 @@ L: linux-media at vger.kernel.org S: Maintained F: drivers/media/platform/s5p-tv/ +ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT +M: Kyungmin Park +L: linux-arm-kernel at lists.infradead.org +L: linux-media at vger.kernel.org +S: Maintained +F: drivers/media/platform/s5p-cec/ + ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT M: Andrzej Pietrasiewicz M: Jacek Anaszewski diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 201f5c2..8a5597e 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -108,6 +108,18 @@ config VIDEO_S3C_CAMIF source "drivers/media/platform/soc_camera/Kconfig" source "drivers/media/platform/exynos4-is/Kconfig" source "drivers/media/platform/s5p-tv/Kconfig" + +config VIDEO_SAMSUNG_S5P_CEC + tristate "Samsung S5P CEC driver" + depends on VIDEO_DEV && VIDEO_V4L2 && (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST) + select MEDIA_CEC + default n + ---help--- + This is a driver for Samsung S5P HDMI CEC interface. It uses the + generic CEC framework interface. + CEC bus is present in the HDMI connector and enables communication + between compatible devices. + source "drivers/media/platform/am437x/Kconfig" source "drivers/media/platform/xilinx/Kconfig" diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index bbb7bd1..f598c80 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/ +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/ diff --git a/drivers/media/platform/s5p-cec/Makefile b/drivers/media/platform/s5p-cec/Makefile new file mode 100644 index 000..0e2cf45 --- /dev/null +++ b/drivers/media/platform/s5p-cec/Makefil
[PATCHv14 15/18] cobalt: add cec support
From: Hans Verkuil Add CEC support to the cobalt driver. Signed-off-by: Hans Verkuil --- drivers/media/pci/cobalt/Kconfig | 1 + drivers/media/pci/cobalt/cobalt-driver.c | 102 +-- drivers/media/pci/cobalt/cobalt-driver.h | 2 + drivers/media/pci/cobalt/cobalt-irq.c| 3 + drivers/media/pci/cobalt/cobalt-v4l2.c | 96 ++--- drivers/media/pci/cobalt/cobalt-v4l2.h | 2 + 6 files changed, 180 insertions(+), 26 deletions(-) diff --git a/drivers/media/pci/cobalt/Kconfig b/drivers/media/pci/cobalt/Kconfig index a01f0cc..9125747 100644 --- a/drivers/media/pci/cobalt/Kconfig +++ b/drivers/media/pci/cobalt/Kconfig @@ -4,6 +4,7 @@ config VIDEO_COBALT depends on PCI_MSI && MTD_COMPLEX_MAPPINGS depends on GPIOLIB || COMPILE_TEST depends on SND + select MEDIA_CEC select I2C_ALGOBIT select VIDEO_ADV7604 select VIDEO_ADV7511 diff --git a/drivers/media/pci/cobalt/cobalt-driver.c b/drivers/media/pci/cobalt/cobalt-driver.c index 8d6f04f..dff92ef 100644 --- a/drivers/media/pci/cobalt/cobalt-driver.c +++ b/drivers/media/pci/cobalt/cobalt-driver.c @@ -76,6 +76,7 @@ static u8 edid[256] = { 0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x68, + 0x02, 0x03, 0x1a, 0xc0, 0x48, 0xa2, 0x10, 0x04, 0x02, 0x01, 0x21, 0x14, 0x13, 0x23, 0x09, 0x07, 0x07, 0x65, 0x03, 0x0c, 0x00, 0x10, 0x00, 0xe2, @@ -149,17 +150,42 @@ static void cobalt_notify(struct v4l2_subdev *sd, struct cobalt *cobalt = to_cobalt(sd->v4l2_dev); unsigned sd_nr = cobalt_get_sd_nr(sd); struct cobalt_stream *s = &cobalt->streams[sd_nr]; - bool hotplug = arg ? *((int *)arg) : false; + struct v4l2_subdev_cec_tx_done *tx_done = arg; - if (s->is_output) + switch (notification) { + case V4L2_SUBDEV_CEC_TX_DONE: + cec_transmit_done(s->cec_adap, tx_done->status, + tx_done->arb_lost_cnt, tx_done->nack_cnt, + tx_done->low_drive_cnt, tx_done->error_cnt); + return; + case V4L2_SUBDEV_CEC_RX_MSG: + cec_received_msg(s->cec_adap, arg); return; + default: + break; + } + + if (s->is_output) { + switch (notification) { + case ADV7511_EDID_DETECT: { + struct adv7511_edid_detect *ed = arg; + + cec_s_phys_addr(s->cec_adap, ed->phys_addr, false); + break; + } + } + return; + } switch (notification) { - case ADV76XX_HOTPLUG: + case ADV76XX_HOTPLUG: { + bool hotplug = arg ? *((int *)arg) : false; + cobalt_s_bit_sysctrl(cobalt, COBALT_SYS_CTRL_HPD_TO_CONNECTOR_BIT(sd_nr), hotplug); cobalt_dbg(1, "Set hotplug for adv %d to %d\n", sd_nr, hotplug); break; + } case V4L2_DEVICE_NOTIFY_EVENT: cobalt_dbg(1, "Format changed for adv %d\n", sd_nr); v4l2_event_queue(&s->vdev, arg); @@ -438,12 +464,15 @@ static void cobalt_stream_struct_init(struct cobalt *cobalt) for (i = 0; i < COBALT_NUM_STREAMS; i++) { struct cobalt_stream *s = &cobalt->streams[i]; + struct video_device *vdev = &s->vdev; s->cobalt = cobalt; s->flags = 0; s->is_audio = false; s->is_output = false; s->is_dummy = true; + snprintf(vdev->name, sizeof(vdev->name), +"%s-%d", cobalt->v4l2_dev.name, i); /* The Memory DMA channels will always get a lower channel * number than the FIFO DMA. Video input should map to the @@ -485,6 +514,19 @@ static void cobalt_stream_struct_init(struct cobalt *cobalt) } } +static int cobalt_create_cec_adap(struct cobalt_stream *s) +{ + u32 caps = CEC_CAP_TRANSMIT | CEC_CAP_LOG_ADDRS | + CEC_CAP_PASSTHROUGH | CEC_CAP_RC; + + if (s->is_output) + caps |= CEC_CAP_IS_SOURCE; + s->cec_adap = cec_create_adapter(&cobalt_cec_adap_ops, +s, s->vdev.name, caps, 1, +&s->cobalt->pci_dev->dev); + return PTR_ERR_OR_ZERO(s->cec_adap); +} + static int cobalt_subdevs_init(struct cobalt *cobalt) { static struct adv76xx_platform_data adv7604_pdata = { @@ -508,10 +550,10 @@ static int cobalt_subdevs_init(struct cobalt *cobalt) .platform_data = &adv7604_pdata, }; - struct cobalt_stream *s = cobalt->streams; int i; for (i = 0; i < COBALT_NUM_INPUTS; i++) { + struct cobalt_stream *s = c
[PATCHv14 14/18] cec: adv7511: add cec support.
From: Hans Verkuil Add CEC support to the adv7511 driver. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- drivers/media/i2c/Kconfig | 2 +- drivers/media/i2c/adv7511.c | 356 +++- include/media/i2c/adv7511.h | 6 +- 3 files changed, 350 insertions(+), 14 deletions(-) diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 11ca81c..98edc74 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -445,7 +445,7 @@ config VIDEO_ADV7393 config VIDEO_ADV7511 tristate "Analog Devices ADV7511 encoder" - depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && MEDIA_CEC select HDMI ---help--- Support for the Analog Devices ADV7511 video encoder. diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c index bd822f0..cee768b 100644 --- a/drivers/media/i2c/adv7511.c +++ b/drivers/media/i2c/adv7511.c @@ -33,6 +33,7 @@ #include #include #include +#include static int debug; module_param(debug, int, 0644); @@ -59,6 +60,8 @@ MODULE_LICENSE("GPL v2"); #define ADV7511_MIN_PIXELCLOCK 2000 #define ADV7511_MAX_PIXELCLOCK 22500 +#define ADV7511_MAX_ADDRS (3) + /* ** * @@ -90,12 +93,19 @@ struct adv7511_state { struct v4l2_ctrl_handler hdl; int chip_revision; u8 i2c_edid_addr; - u8 i2c_cec_addr; u8 i2c_pktmem_addr; + u8 i2c_cec_addr; + + struct i2c_client *i2c_cec; + u8 cec_addr[ADV7511_MAX_ADDRS]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + /* Is the adv7511 powered on? */ bool power_on; /* Did we receive hotplug and rx-sense signals? */ bool have_monitor; + bool enabled_irq; /* timings from s_dv_timings */ struct v4l2_dv_timings dv_timings; u32 fmt_code; @@ -227,7 +237,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client *client, return ret; } -static inline void adv7511_edid_rd(struct v4l2_subdev *sd, u16 len, u8 *buf) +static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf) { struct adv7511_state *state = get_adv7511_state(sd); int i; @@ -242,6 +252,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, u16 len, u8 *buf) v4l2_err(sd, "%s: i2c read error\n", __func__); } +static inline int adv7511_cec_read(struct v4l2_subdev *sd, u8 reg) +{ + struct adv7511_state *state = get_adv7511_state(sd); + + return i2c_smbus_read_byte_data(state->i2c_cec, reg); +} + +static int adv7511_cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) +{ + struct adv7511_state *state = get_adv7511_state(sd); + int ret; + int i; + + for (i = 0; i < 3; i++) { + ret = i2c_smbus_write_byte_data(state->i2c_cec, reg, val); + if (ret == 0) + return 0; + } + v4l2_err(sd, "%s: I2C Write Problem\n", __func__); + return ret; +} + +static inline int adv7511_cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return adv7511_cec_write(sd, reg, (adv7511_cec_read(sd, reg) & mask) | val); +} + static int adv7511_pktmem_rd(struct v4l2_subdev *sd, u8 reg) { struct adv7511_state *state = get_adv7511_state(sd); @@ -425,16 +463,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = { #ifdef CONFIG_VIDEO_ADV_DEBUG static void adv7511_inv_register(struct v4l2_subdev *sd) { + struct adv7511_state *state = get_adv7511_state(sd); + v4l2_info(sd, "0x000-0x0ff: Main Map\n"); + if (state->i2c_cec) + v4l2_info(sd, "0x100-0x1ff: CEC Map\n"); } static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + reg->size = 1; switch (reg->reg >> 8) { case 0: reg->val = adv7511_rd(sd, reg->reg & 0xff); break; + case 1: + if (state->i2c_cec) { + reg->val = adv7511_cec_read(sd, reg->reg & 0xff); + break; + } + /* fall through */ default: v4l2_info(sd, "Register %03llx not supported\n", reg->reg); adv7511_inv_register(sd); @@ -445,10 +495,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register * static int adv7511_s_register(struct v4l2_subdev *sd, const struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + switch (reg->reg >> 8) { case 0: adv7511_wr(sd, reg->r
[PATCHv14 13/18] cec: adv7842: add cec support
From: Hans Verkuil Add CEC support to the adv7842 driver. Signed-off-by: Hans Verkuil --- drivers/media/i2c/Kconfig | 2 +- drivers/media/i2c/adv7842.c | 323 +++- 2 files changed, 261 insertions(+), 64 deletions(-) diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 3d01ffc..11ca81c 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -220,7 +220,7 @@ config VIDEO_ADV7604 config VIDEO_ADV7842 tristate "Analog Devices ADV7842 decoder" - depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && MEDIA_CEC select HDMI ---help--- Support for the Analog Devices ADV7842 video decoder. diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c index 7ccb85d..32cfeca 100644 --- a/drivers/media/i2c/adv7842.c +++ b/drivers/media/i2c/adv7842.c @@ -39,6 +39,7 @@ #include #include #include +#include #include #include #include @@ -79,6 +80,8 @@ MODULE_LICENSE("GPL"); #define ADV7842_OP_SWAP_CB_CR (1 << 0) +#define ADV7842_MAX_ADDRS (3) + /* ** * @@ -142,6 +145,10 @@ struct adv7842_state { struct v4l2_ctrl *free_run_color_ctrl_manual; struct v4l2_ctrl *free_run_color_ctrl; struct v4l2_ctrl *rgb_quantization_range_ctrl; + + u8 cec_addr[ADV7842_MAX_ADDRS]; + u8 cec_valid_addrs; + bool cec_enabled_adap; }; /* Unsupported timings. This device cannot support 720p30. */ @@ -418,9 +425,9 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) return adv_smbus_write_byte_data(state->i2c_cec, reg, val); } -static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 val) +static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 val) { - return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val); + return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val); } static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg) @@ -696,6 +703,18 @@ adv7842_get_dv_timings_cap(struct v4l2_subdev *sd) /* --- */ +static u16 adv7842_read_cable_det(struct v4l2_subdev *sd) +{ + u8 reg = io_read(sd, 0x6f); + u16 val = 0; + + if (reg & 0x02) + val |= 1; /* port A */ + if (reg & 0x01) + val |= 2; /* port B */ + return val; +} + static void adv7842_delayed_work_enable_hotplug(struct work_struct *work) { struct delayed_work *dwork = to_delayed_work(work); @@ -762,50 +781,17 @@ static int edid_write_vga_segment(struct v4l2_subdev *sd) return 0; } -static int edid_spa_location(const u8 *edid) -{ - u8 d; - - /* -* TODO, improve and update for other CEA extensions -* currently only for 1 segment (256 bytes), -* i.e. 1 extension block and CEA revision 3. -*/ - if ((edid[0x7e] != 1) || - (edid[0x80] != 0x02) || - (edid[0x81] != 0x03)) { - return -EINVAL; - } - /* -* search Vendor Specific Data Block (tag 3) -*/ - d = edid[0x82] & 0x7f; - if (d > 4) { - int i = 0x84; - int end = 0x80 + d; - do { - u8 tag = edid[i]>>5; - u8 len = edid[i] & 0x1f; - - if ((tag == 3) && (len >= 5)) - return i + 4; - i += len + 1; - } while (i < end); - } - return -EINVAL; -} - static int edid_write_hdmi_segment(struct v4l2_subdev *sd, u8 port) { struct i2c_client *client = v4l2_get_subdevdata(sd); struct adv7842_state *state = to_state(sd); - const u8 *val = state->hdmi_edid.edid; - int spa_loc = edid_spa_location(val); + const u8 *edid = state->hdmi_edid.edid; + int spa_loc; int err = 0; int i; - v4l2_dbg(2, debug, sd, "%s: write EDID on port %c (spa at 0x%x)\n", - __func__, (port == ADV7842_EDID_PORT_A) ? 'A' : 'B', spa_loc); + v4l2_dbg(2, debug, sd, "%s: write EDID on port %c\n", + __func__, (port == ADV7842_EDID_PORT_A) ? 'A' : 'B'); /* HPA disable on port A and B */ io_write_and_or(sd, 0x20, 0xcf, 0x00); @@ -816,24 +802,30 @@ static int edid_write_hdmi_segment(struct v4l2_subdev *sd, u8 port) if (!state->hdmi_edid.present) return 0; + cec_get_edid_phys_addr(edid, 256, &spa_loc); + + /* +* Return an error if no location of the source physical address +* was found. +*/ + if (spa_loc == 0) + return -EINVAL; + /* edid segment pointer '0' for HDMI ports */
[PATCHv14 12/18] cec: adv7604: add cec support.
From: Hans Verkuil Add CEC support to the adv7604 driver. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] [k.debski at samsung.com: add missing methods cec/io_write_and_or] [k.debski at samsung.com: change adv7604 to adv76xx in added functions] [hansverk at cisco.com: use _clr_set instead of _and_or] --- drivers/media/i2c/Kconfig | 2 +- drivers/media/i2c/adv7604.c | 286 ++-- 2 files changed, 251 insertions(+), 37 deletions(-) diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 993dc50..3d01ffc 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -206,7 +206,7 @@ config VIDEO_ADV7183 config VIDEO_ADV7604 tristate "Analog Devices ADV7604 decoder" - depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && MEDIA_CEC depends on GPIOLIB || COMPILE_TEST select HDMI ---help--- diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index 41a1bfc..f1d254f 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -40,6 +40,7 @@ #include #include +#include #include #include #include @@ -80,6 +81,8 @@ MODULE_LICENSE("GPL"); #define ADV76XX_OP_SWAP_CB_CR (1 << 0) +#define ADV76XX_MAX_ADDRS (3) + enum adv76xx_type { ADV7604, ADV7611, @@ -184,6 +187,10 @@ struct adv76xx_state { u16 spa_port_a[2]; struct v4l2_fract aspect_ratio; u32 rgb_quantization_range; + u8 cec_addr[ADV76XX_MAX_ADDRS]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + struct workqueue_struct *work_queues; struct delayed_work delayed_work_enable_hotplug; bool restart_stdi_once; @@ -381,7 +388,8 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg, u8 val) return regmap_write(state->regmap[ADV76XX_PAGE_IO], reg, val); } -static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 val) +static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) { return io_write(sd, reg, (io_read(sd, reg) & ~mask) | val); } @@ -414,6 +422,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) return regmap_write(state->regmap[ADV76XX_PAGE_CEC], reg, val); } +static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val); +} + static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg) { struct adv76xx_state *state = to_state(sd); @@ -872,9 +886,9 @@ static int adv76xx_s_detect_tx_5v_ctrl(struct v4l2_subdev *sd) { struct adv76xx_state *state = to_state(sd); const struct adv76xx_chip_info *info = state->info; + u16 cable_det = info->read_cable_det(sd); - return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, - info->read_cable_det(sd)); + return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, cable_det); } static int find_and_set_predefined_video_timings(struct v4l2_subdev *sd, @@ -1900,6 +1914,200 @@ static int adv76xx_set_format(struct v4l2_subdev *sd, return 0; } +static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status) +{ + struct v4l2_subdev_cec_tx_done tx_done = {}; + + if ((cec_read(sd, 0x11) & 0x01) == 0) { + v4l2_dbg(1, debug, sd, "%s: tx raw: tx disabled\n", __func__); + return; + } + + if (tx_raw_status & 0x02) { + v4l2_dbg(1, debug, sd, "%s: tx raw: arbitration lost\n", +__func__); + tx_done.status = CEC_TX_STATUS_ARB_LOST; + tx_done.arb_lost_cnt = 1; + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, &tx_done); + return; + } + if (tx_raw_status & 0x04) { + v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__); + /* +* We set this status bit since this hardware performs +* retransmissions. +*/ + tx_done.status = CEC_TX_STATUS_MAX_RETRIES; + tx_done.nack_cnt = cec_read(sd, 0x14) & 0xf; + if (tx_done.nack_cnt) + tx_done.status |= CEC_TX_STATUS_NACK; + tx_done.low_drive_cnt = cec_read(sd, 0x14) >> 4; + if (tx_done.low_drive_cnt) + tx_done.status |= CEC_TX_STATUS_LOW_DRIVE; + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, &tx_done); + return; + } + if (tx_raw_status & 0x01) { + v4l2_dbg(1, debug, sd, "%s: tx raw: ready ok\n", __func__); + tx_done.status = CEC_TX_STATU
[PATCHv14 11/18] v4l2-subdev: add HDMI CEC ops
From: Hans Verkuil Add CEC callbacks to the new v4l2_subdev_cec_ops struct. These are the low-level CEC ops that subdevs that support CEC have to implement. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski --- include/media/v4l2-subdev.h | 21 + 1 file changed, 21 insertions(+) diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index 11e2dfe..8fa660e 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -42,6 +42,17 @@ #defineV4L2_DEVICE_NOTIFY_EVENT_IOW('v', 2, struct v4l2_event) +struct v4l2_subdev_cec_tx_done { + u8 status; + u8 arb_lost_cnt; + u8 nack_cnt; + u8 low_drive_cnt; + u8 error_cnt; +}; + +#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 3, struct v4l2_subdev_cec_tx_done) +#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 4, struct cec_msg) + struct v4l2_device; struct v4l2_ctrl_handler; struct v4l2_event; @@ -51,6 +62,7 @@ struct v4l2_subdev; struct v4l2_subdev_fh; struct tuner_setup; struct v4l2_mbus_frame_desc; +struct cec_msg; /* decode_vbi_line */ struct v4l2_decode_vbi_line { @@ -645,6 +657,14 @@ struct v4l2_subdev_pad_ops { struct v4l2_mbus_frame_desc *fd); }; +struct v4l2_subdev_cec_ops { + unsigned (*adap_available_log_addrs)(struct v4l2_subdev *sd); + int (*adap_enable)(struct v4l2_subdev *sd, bool enable); + int (*adap_log_addr)(struct v4l2_subdev *sd, u8 logical_addr); + int (*adap_transmit)(struct v4l2_subdev *sd, u8 attempts, +u32 signal_free_time, struct cec_msg *msg); +}; + struct v4l2_subdev_ops { const struct v4l2_subdev_core_ops *core; const struct v4l2_subdev_tuner_ops *tuner; @@ -654,6 +674,7 @@ struct v4l2_subdev_ops { const struct v4l2_subdev_ir_ops *ir; const struct v4l2_subdev_sensor_ops *sensor; const struct v4l2_subdev_pad_ops*pad; + const struct v4l2_subdev_cec_ops*cec; }; /* -- 2.7.0
[PATCHv14 10/18] DocBook/media: add CEC documentation
From: Hans Verkuil Add DocBook documentation for the CEC API. Signed-off-by: Hans Verkuil [k.debski at samsung.com: add documentation for passthrough mode] [k.debski at samsung.com: minor fixes and change of reserved field sizes] Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Documentation/DocBook/device-drivers.tmpl | 3 + Documentation/DocBook/media/Makefile | 2 + Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml| 73 + 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-adap-g-caps.xml | 146 + .../DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml | 343 + .../DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml | 82 + .../DocBook/media/v4l/cec-ioc-adap-log-status.xml | 51 +++ .../DocBook/media/v4l/cec-ioc-dqevent.xml | 204 Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml | 245 +++ .../DocBook/media/v4l/cec-ioc-receive.xml | 261 Documentation/DocBook/media_api.tmpl | 6 +- 16 files changed, 1740 insertions(+), 1 deletion(-) 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-adap-g-caps.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-log-status.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-dqevent.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index cc303a2..9db705d 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -269,6 +269,9 @@ X!Isound/sound_firmware.c !Iinclude/media/media-devnode.h !Iinclude/media/media-entity.h + Consumer Electronics Control devices +!Iinclude/media/cec.h + diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 2840ff4..497b57e 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -64,6 +64,7 @@ IOCTLS = \ $(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/cec.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ DEFINES = \ @@ -100,6 +101,7 @@ STRUCTS = \ $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/ && !/_old/)' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/cec.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h) diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index 9beb30f..87f1d24 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -342,6 +342,16 @@ in the frequency range from 87,5 to 108,0 MHz Specification Version 1.4a + + HDMI2 + + HDMI Licensing LLC +(http://www.hdmi.org";>http://www.hdmi.org) + + High-Definition Multimedia Interface + Specification Version 2.0 + + DP diff --git a/Documentation/DocBook/media/v4l/cec-api.xml b/Documentation/DocBook/media/v4l/cec-api.xml new file mode 100644 index 000..fdf243c --- /dev/null +++ b/Documentation/DocBook/m
[PATCHv14 09/18] cec.txt: add CEC framework documentation
From: Hans Verkuil Document the new HDMI CEC framework. Signed-off-by: Hans Verkuil [k.debski at samsung.com: add DocBook documentation by Hans Verkuil, with Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Documentation/cec.txt | 281 ++ 1 file changed, 281 insertions(+) create mode 100644 Documentation/cec.txt diff --git a/Documentation/cec.txt b/Documentation/cec.txt new file mode 100644 index 000..9d62a02 --- /dev/null +++ b/Documentation/cec.txt @@ -0,0 +1,281 @@ +CEC Kernel Support +== + +The CEC framework provides a unified kernel interface for use with HDMI CEC +hardware. It is designed to handle a multiple types of hardware (receivers, +transmitters, USB dongles). The framework also gives the option to decide +what to do in the kernel driver and what should be handled by userspace +applications. In addition it integrates the remote control passthrough +feature into the kernel's remote control framework. + + +The CEC Protocol + + +The CEC protocol enables consumer electronic devices to communicate with each +other through the HDMI connection. The protocol uses logical addresses in the +communication. The logical address is strictly connected with the functionality +provided by the device. The TV acting as the communication hub is always +assigned address 0. The physical address is determined by the physical +connection between devices. + +The CEC framework described here is up to date with the CEC 2.0 specification. +It is documented in the HDMI 1.4 specification with the new 2.0 bits documented +in the HDMI 2.0 specification. But for most of the features the freely available +HDMI 1.3a specification is sufficient: + +http://www.microprocessor.org/HDMISpecification13a.pdf + + +The Kernel Interface + + +CEC Adapter +--- + +The struct cec_adapter represents the CEC adapter hardware. It is created by +calling cec_create_adapter() and deleted by calling cec_delete_adapter(): + +struct cec_adapter *cec_create_adapter(const struct cec_adap_ops *ops, + void *priv, const char *name, u32 caps, u8 available_las, + struct device *parent); +void cec_delete_adapter(struct cec_adapter *adap); + +To create an adapter you need to pass the following information: + +ops: adapter operations which are called by the CEC framework and that you +have to implement. + +priv: will be stored in adap->priv and can be used by the adapter ops. + +name: the name of the CEC adapter. Note: this name will be copied. + +caps: capabilities of the CEC adapter. These capabilities determine the + capabilities of the hardware and which parts are to be handled + by userspace and which parts are handled by kernelspace. The + capabilities are returned by CEC_ADAP_G_CAPS. + +available_las: the number of simultaneous logical addresses that this + adapter can handle. Must be 1 <= available_las <= CEC_MAX_LOG_ADDRS. + Can optionally be changed later by calling cec_s_available_log_addrs(). + +parent: the parent device. + + +To register the /dev/cecX device node and the remote control device (if +CEC_CAP_RC is set) you call: + +int cec_register_adapter(struct cec_adapter *adap); + +To unregister the devices call: + +void cec_unregister_adapter(struct cec_adapter *adap); + +Note: if cec_register_adapter() fails, then call cec_delete_adapter() to +clean up. But if cec_register_adapter() succeeded, then only call +cec_unregister_adapter() to clean up, never cec_delete_adapter(). The +unregister function will delete the adapter automatically once the last user +of that /dev/cecX device has closed its file handle. + + +Implementing the Low-Level CEC Adapter +-- + +The following low-level adapter operations have to be implemented in +your driver: + +struct cec_adap_ops { + /* Low-level callbacks */ + int (*adap_enable)(struct cec_adapter *adap, bool enable); + int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable); + int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); + int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, +u32 signal_free_time, struct cec_msg *msg); + void (*adap_log_status)(struct cec_adapter *adap); + + /* High-level callbacks */ + ... +}; + +The three low-level ops deal with various aspects of controlling the CEC adapter +hardware: + + +To enable/disable the hardware: + + int (*adap_enable)(struct cec_adapter *adap, bool enable); + +This callback enables or disables the CEC hardware. Enabling the CEC hardware +means powering it up in a state where no logical addresses are claimed. This +op assumes that the physical address (adap->phys_addr) is valid when enable is +true and will not change while the CEC adapter remains enabled. The initial +state of the CEC adapter after calling cec_create_adapte
[PATCHv14 08/18] cec: add compat32 ioctl support
From: Hans Verkuil The CEC ioctls didn't have compat32 support, so they returned -ENOTTY when used in a 32 bit application on a 64 bit kernel. Since all the CEC ioctls are 32-bit compatible adding support for this API is trivial. Signed-off-by: Hans Verkuil --- fs/compat_ioctl.c | 13 + 1 file changed, 13 insertions(+) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index 6402eaf..4f17e4e 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -57,6 +57,7 @@ #include #include #include +#include #include "internal.h" @@ -1399,6 +1400,18 @@ COMPATIBLE_IOCTL(VIDEO_GET_NAVI) COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES) COMPATIBLE_IOCTL(VIDEO_GET_SIZE) COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE) +/* cec */ +COMPATIBLE_IOCTL(CEC_ADAP_G_CAPS) +COMPATIBLE_IOCTL(CEC_ADAP_LOG_STATUS) +COMPATIBLE_IOCTL(CEC_ADAP_G_LOG_ADDRS) +COMPATIBLE_IOCTL(CEC_ADAP_S_LOG_ADDRS) +COMPATIBLE_IOCTL(CEC_ADAP_G_PHYS_ADDR) +COMPATIBLE_IOCTL(CEC_ADAP_S_PHYS_ADDR) +COMPATIBLE_IOCTL(CEC_G_MODE) +COMPATIBLE_IOCTL(CEC_S_MODE) +COMPATIBLE_IOCTL(CEC_TRANSMIT) +COMPATIBLE_IOCTL(CEC_RECEIVE) +COMPATIBLE_IOCTL(CEC_DQEVENT) /* joystick */ COMPATIBLE_IOCTL(JSIOCGVERSION) -- 2.7.0
[PATCHv14 07/18] cec: add HDMI CEC framework
From: Hans Verkuil The added HDMI CEC framework provides a generic kernel interface for HDMI CEC devices. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.debski at samsung.com: Merged Update author commit by Hans Verkuil] [k.debski at samsung.com: change kthread handling when setting logical address] [k.debski at samsung.com: code cleanup and fixes] [k.debski at samsung.com: add missing CEC commands to match spec] [k.debski at samsung.com: add RC framework support] [k.debski at samsung.com: move and edit documentation] [k.debski at samsung.com: add vendor id reporting] [k.debski at samsung.com: add possibility to clear assigned logical addresses] [k.debski at samsung.com: documentation fixes, clenaup and expansion] [k.debski at samsung.com: reorder of API structs and add reserved fields] [k.debski at samsung.com: fix handling of events and fix 32/64bit timespec problem] [k.debski at samsung.com: add cec.h to include/uapi/linux/Kbuild] [k.debski at samsung.com: add sequence number handling] [k.debski at samsung.com: add passthrough mode] [k.debski at samsung.com: fix CEC defines, add missing CEC 2.0 commands] minor additions] Signed-off-by: Kamil Debski --- MAINTAINERS| 14 + drivers/media/Kconfig |5 + drivers/media/Makefile |2 + drivers/media/cec.c| 2534 include/media/cec.h| 204 include/uapi/linux/Kbuild |2 + include/uapi/linux/cec-funcs.h | 1852 + include/uapi/linux/cec.h | 917 +++ 8 files changed, 5530 insertions(+) create mode 100644 drivers/media/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 diff --git a/MAINTAINERS b/MAINTAINERS index 99bd725..9b10806 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2704,6 +2704,20 @@ F: drivers/net/ieee802154/cc2520.c F: include/linux/spi/cc2520.h F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt +CEC DRIVER +M: Hans Verkuil +L: linux-media at vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Supported +F: Documentation/cec.txt +F: Documentation/DocBook/media/v4l/cec* +F: drivers/media/cec.c +F: drivers/media/rc/keymaps/rc-cec.c +F: include/media/cec.h +F: include/uapi/linux/cec.h +F: include/uapi/linux/cec-funcs.h + CELL BROADBAND ENGINE ARCHITECTURE M: Arnd Bergmann L: linuxppc-dev at lists.ozlabs.org diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index a8518fb..ef8192e 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -80,6 +80,11 @@ config MEDIA_RC_SUPPORT Say Y when you have a TV or an IR device. +config MEDIA_CEC + tristate "CEC API (EXPERIMENTAL)" + ---help--- + Enable the CEC API. + # # Media controller # Selectable only for webcam/grabbers, as other drivers don't use it diff --git a/drivers/media/Makefile b/drivers/media/Makefile index e608bbc..58e8554 100644 --- a/drivers/media/Makefile +++ b/drivers/media/Makefile @@ -2,6 +2,8 @@ # Makefile for the kernel multimedia device drivers. # +obj-$(CONFIG_MEDIA_CEC) += cec.o + media-objs := media-device.o media-devnode.o media-entity.o # diff --git a/drivers/media/cec.c b/drivers/media/cec.c new file mode 100644 index 000..55d5b86 --- /dev/null +++ b/drivers/media/cec.c @@ -0,0 +1,2534 @@ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define CEC_NUM_DEVICES256 +#define CEC_NAME "cec" + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, "debug level (0-2)"); + +/* + * 400 ms is the time it takes for one 16 byte message to be + * transferred and 5 is the maximum number of retries. Add + * another 100 ms as a margin. So if the transmit doesn't + * finish before that time something is really wrong and we + * have to time out. + * + * This is a sign that something it really wrong and a warning + * will be issued. + */ +#define CEC_XFER_TIMEOUT_MS (5 * 400 + 100) + +#define dprintk(lvl, fmt, arg...) \ + do {\ + if (lvl <= debug) \ + pr_info("cec-%s: " fmt, adap->name, ## arg);\ + } while (0) + +#define call_op(adap, op, arg...) \ + (adap->ops->op ? adap->ops->op(adap, ## arg) : 0) + +#define call_void_op(adap, op, arg...) \ + do {\ + if (adap->ops->op) \ + adap->ops->op(adap, ## arg);\ + } while (0) + +static dev_t cec_dev_t; + +/* Active dev
[PATCHv14 06/18] rc: Add HDMI CEC protocol handling
From: Kamil Debski Add handling of remote control events coming from the HDMI CEC bus. This patch includes a new keymap that maps values found in the CEC messages to the keys pressed and released. Also, a new protocol has been added to the core. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- drivers/media/rc/keymaps/Makefile | 1 + drivers/media/rc/keymaps/rc-cec.c | 174 ++ drivers/media/rc/rc-main.c| 1 + include/media/rc-map.h| 5 +- 4 files changed, 180 insertions(+), 1 deletion(-) create mode 100644 drivers/media/rc/keymaps/rc-cec.c diff --git a/drivers/media/rc/keymaps/Makefile b/drivers/media/rc/keymaps/Makefile index fbbd3bb..9cffcc6 100644 --- a/drivers/media/rc/keymaps/Makefile +++ b/drivers/media/rc/keymaps/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \ rc-behold.o \ rc-behold-columbus.o \ rc-budget-ci-old.o \ + rc-cec.o \ rc-cinergy-1400.o \ rc-cinergy.o \ rc-delock-61959.o \ diff --git a/drivers/media/rc/keymaps/rc-cec.c b/drivers/media/rc/keymaps/rc-cec.c new file mode 100644 index 000..193cdca --- /dev/null +++ b/drivers/media/rc/keymaps/rc-cec.c @@ -0,0 +1,174 @@ +/* Keytable for the CEC remote control + * + * Copyright (c) 2015 by Kamil Debski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include +#include + +/* CEC Spec "High-Definition Multimedia Interface Specification" can be obtained + * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf + * The list of control codes is listed in Table 27: User Control Codes p. 95 */ + +static struct rc_map_table cec[] = { + { 0x00, KEY_OK }, + { 0x01, KEY_UP }, + { 0x02, KEY_DOWN }, + { 0x03, KEY_LEFT }, + { 0x04, KEY_RIGHT }, + { 0x05, KEY_RIGHT_UP }, + { 0x06, KEY_RIGHT_DOWN }, + { 0x07, KEY_LEFT_UP }, + { 0x08, KEY_LEFT_DOWN }, + { 0x09, KEY_ROOT_MENU }, /* CEC Spec: Device Root Menu - see Note 2 */ + /* Note 2: This is the initial display that a device shows. It is +* device-dependent and can be, for example, a contents menu, setup +* menu, favorite menu or other menu. The actual menu displayed +* may also depend on the device's current state. */ + { 0x0a, KEY_SETUP }, + { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */ + { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */ + { 0x0d, KEY_EXIT }, + /* 0x0e-0x0f: Reserved */ + { 0x10, KEY_MEDIA_TOP_MENU }, + { 0x11, KEY_CONTEXT_MENU }, + /* 0x12-0x1c: Reserved */ + { 0x1d, KEY_DIGITS }, /* CEC Spec: select/toggle a Number Entry Mode */ + { 0x1e, KEY_NUMERIC_11 }, + { 0x1f, KEY_NUMERIC_12 }, + /* 0x20-0x29: Keys 0 to 9 */ + { 0x20, KEY_NUMERIC_0 }, + { 0x21, KEY_NUMERIC_1 }, + { 0x22, KEY_NUMERIC_2 }, + { 0x23, KEY_NUMERIC_3 }, + { 0x24, KEY_NUMERIC_4 }, + { 0x25, KEY_NUMERIC_5 }, + { 0x26, KEY_NUMERIC_6 }, + { 0x27, KEY_NUMERIC_7 }, + { 0x28, KEY_NUMERIC_8 }, + { 0x29, KEY_NUMERIC_9 }, + { 0x2a, KEY_DOT }, + { 0x2b, KEY_ENTER }, + { 0x2c, KEY_CLEAR }, + /* 0x2d-0x2e: Reserved */ + { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */ + { 0x30, KEY_CHANNELUP }, + { 0x31, KEY_CHANNELDOWN }, + { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */ + { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */ + { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */ + { 0x35, KEY_INFO }, /* CEC Spec: Display Information */ + { 0x36, KEY_HELP }, + { 0x37, KEY_PAGEUP }, + { 0x38, KEY_PAGEDOWN }, + /* 0x39-0x3f: Reserved */ + { 0x40, KEY_POWER }, + { 0x41, KEY_VOLUMEUP }, + { 0x42, KEY_VOLUMEDOWN }, + { 0x43, KEY_MUTE }, + { 0x44, KEY_PLAYCD }, + { 0x45, KEY_STOPCD }, + { 0x46, KEY_PAUSECD }, + { 0x47, KEY_RECORD }, + { 0x48, KEY_REWIND }, + { 0x49, KEY_FASTFORWARD }, + { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */ + { 0x4b, KEY_FORWARD }, + { 0x4c, KEY_BACK }, + { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */ + { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */ + /* 0x4f: Reserved */ + { 0x50, KEY_ANGLE }, + { 0x51, KEY_TV2 }, + { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */ + { 0x53, KEY_EPG }, + { 0x54, KEY_TIME }, /* CEC Spec: Timer */ + { 0x55, KEY_CONFIG }, + /* The following codes are hard to implement at this moment, as they +
[PATCHv14 05/18] HID: add HDMI CEC specific keycodes
From: Kamil Debski Add HDMI CEC specific keycodes to the keycodes definition. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- include/uapi/linux/input-event-codes.h | 30 ++ 1 file changed, 30 insertions(+) diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 87cf351..02b7b3a 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -611,6 +611,36 @@ #define KEY_KBDINPUTASSIST_ACCEPT 0x264 #define KEY_KBDINPUTASSIST_CANCEL 0x265 +/* Diagonal movement keys */ +#define KEY_RIGHT_UP 0x266 +#define KEY_RIGHT_DOWN 0x267 +#define KEY_LEFT_UP0x268 +#define KEY_LEFT_DOWN 0x269 + +#define KEY_ROOT_MENU 0x26a /* Show Device's Root Menu */ +#define KEY_MEDIA_TOP_MENU 0x26b /* Show Top Menu of the Media (e.g. DVD) */ +#define KEY_NUMERIC_11 0x26c +#define KEY_NUMERIC_12 0x26d +/* + * Toggle Audio Description: refers to an audio service that helps blind and + * visually impaired consumers understand the action in a program. Note: in + * some countries this is referred to as "Video Description". + */ +#define KEY_AUDIO_DESC 0x26e +#define KEY_3D_MODE0x26f +#define KEY_NEXT_FAVORITE 0x270 +#define KEY_STOP_RECORD0x271 +#define KEY_PAUSE_RECORD 0x272 +#define KEY_VOD0x273 /* Video on Demand */ +#define KEY_UNMUTE 0x274 +#define KEY_FASTREVERSE0x275 +#define KEY_SLOWREVERSE0x276 +/* + * Control a data application associated with the currently viewed channel, + * e.g. teletext or data broadcast application (MHEG, MHP, HbbTV, etc.) + */ +#define KEY_DATA 0x275 + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1 -- 2.7.0
[PATCHv14 04/18] input.h: add BUS_CEC type
From: Hans Verkuil Inputs can come in over the HDMI CEC bus, so add a new type for this. Signed-off-by: Hans Verkuil Acked-by: Dmitry Torokhov --- include/uapi/linux/input.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index 2758687..4f8c813 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -246,6 +246,7 @@ struct input_mask { #define BUS_GSC0x1A #define BUS_ATARI 0x1B #define BUS_SPI0x1C +#define BUS_CEC0x1D /* * MT_TOOL types -- 2.7.0
[PATCHv14 03/18] dts: exynos4412-odroid*: enable the HDMI CEC device
From: Marek Szyprowski Add a dts node entry and enable the HDMI CEC device present in the Exynos4 family of SoCs. Signed-off-by: Marek Szyprowski Signed-off-by: Hans Verkuil --- arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi index 395c3ca..c9b1425 100644 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi @@ -500,3 +500,7 @@ &watchdog { status = "okay"; }; + +&hdmicec { + status = "okay"; +}; -- 2.7.0
[PATCHv14 02/18] dts: exynos4: add node for the HDMI CEC device
From: Kamil Debski This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 045785c..8913408 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -751,6 +751,18 @@ status = "disabled"; }; + hdmicec: cec at 100B { + compatible = "samsung,s5p-cec"; + reg = <0x100B 0x200>; + interrupts = <0 114 0>; + clocks = <&clock CLK_HDMI_CEC>; + clock-names = "hdmicec"; + samsung,syscon-phandle = <&pmu_system_controller>; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_cec>; + status = "disabled"; + }; + mixer: mixer at 12C1 { compatible = "samsung,exynos4210-mixer"; interrupts = <0 91 0>; -- 2.7.0
[PATCHv14 01/18] dts: exynos4*: add HDMI CEC pin definition to pinctrl
From: Kamil Debski Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and Exynos4x12 SoCs. These are required by the HDMI CEC device. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 +++ arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 7 +++ 2 files changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi index a7c2128..9331c62 100644 --- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi +++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi @@ -820,6 +820,13 @@ samsung,pin-pud = <1>; samsung,pin-drv = <0>; }; + + hdmi_cec: hdmi-cec { + samsung,pins = "gpx3-6"; + samsung,pin-function = <3>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; }; pinctrl at 0386 { diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi index bac25c6..856b292 100644 --- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi +++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi @@ -885,6 +885,13 @@ samsung,pin-pud = <0>; samsung,pin-drv = <0>; }; + + hdmi_cec: hdmi-cec { + samsung,pins = "gpx3-6"; + samsung,pin-function = <3>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; }; pinctrl_2: pinctrl at 0386 { -- 2.7.0
[PATCHv14 00/18] HDMI CEC framework
From: Hans Verkuil Hi all, The fourteenth version of this patchset takes care of the TODO items from the previous patch series: the ARC/CDC code has been split off into a separate patch which I do not intend to upstream until I have been able to test it with actual hardware. The way CEC adapters are enabled and physical addresses are handled has been improved substantially. Drivers or userspace (if CEC_CAP_PHYS_ADDR is set) only have to provide the right physical address and the framework will enable or disable (for address f.f.f.f) the hardware accordingly. You also can now call CEC_ADAP_S_LOG_ADDRS only once and the framework will try to reinitialize the logical addresses automatically if the physical address went away and came back. As a result of these changes the old state and vendor ID ioctls have been removed, simplifying the API nicely. See the changelog below for more details. The cec-ctl and cec-compliance utilities used to test the CEC framework can be found here: http://git.linuxtv.org/cgit.cgi/hverkuil/v4l-utils.git/log/?h=cec Note that I started the first steps towards a proper CEC compliance test where I can put a CEC adapter in follower mode (where it replies to messages emulating a device) and/or initiator mode where the device sends messages to remote CEC adapters, testing those. The TODO items on my list are: - how does one determine whether this adapter is for a receiver, transmitter or repeater/switch? This is done with CEC_CAP_IS_SOURCE at the moment, but that won't work for a repeater/switch or a USB dongle. I am working on adding support for the Pulse Eight USB CEC dongle (thanks to Hans de Goede for telling me how to handle devices that use a serial port for communicating) so I can better test this use-case. - add test code to v4l2-compliance to test CEC_EVENT_STATE_CHANGE. I want to make sure I didn't miss anything there. - would the combination of physical address f.f.f.f and Unregistered make any sense? Currently the adapter is always disabled if f.f.f.f is set. Best regards, Hans Changes since v13 = - Removed CEC_CAP_STATE and _VENDOR_ID - Removed CEC_ADAP_G/S_STATE and CEC_ADAP_G/S_VENDOR_ID - Add vendor_id to struct cec_log_addrs - CEC_EVENT_STATE_CHANGE now reports the physical address, the logical address mask and the logical address type mask. - Add the logical address mask and the logical address type mask to struct cec_log_addrs. - Dropped cec_enable, instead enable/disable the adapter based on the physical address. - Once a valid physical address is available and userspace or driver specified the requested logical address configuration the framework will automatically claim the needed logical addresses. It will retry the last used addresses first, as per the recommendation in the CEC specification. - Dropped CEC power status handling: it's not clear if the kernel should handle that, and if it has to, whether this is the correct way. - Dropped CEC_EVENT_PHYS_ADDR_CHANGE, this is now handled by CEC_EVENT_STATE_CHANGE. - Add helper functions for manipulating physical addresses. - Updated documentation. - Dropped ninputs field in struct cec_caps. - Dropped CEC_EVENT_INPUTS_CHANGE, was never used and it is unclear if it is needed. Changes since v12 = - Added driver and name fields to the cec_caps struct. Without this it was very difficult to tell CEC adapters apart in a human readable manner. - Renamed CEC_CAP_IO to CEC_CAP_TRANSMIT, which better describes this capability. - Added the CEC_ADAP_LOG_STATUS to log the current status of the CEC adapter. Very useful when debugging. - Added comments to the cec.c source. - Added a timeout when waiting for a transmit to finish. Without the timeout the state machine could lock up when dealing with broken CEC adapter drivers or just unlucky situations. - Commenting the code also found a number of bugs which have been fixed. - Trying to poll yourself is now handled by the framework since different hardware would give different results. The framework will just NACK it. - Disabling the CEC adapter doesn't clear the physical address anymore. This turned out to be quite painful for applications. - Merged the CLAIM/RELEASE, G/S_MONITOR and G_PASSTHROUGH ioctls into two G/S_MODE ioctls. This allows you to tell the driver which initiator and follower modes you want, and greatly simplifies how these modes are handled. Changes since v11 = - Add a new CEC_EVENT_PHYS_ADDR_CHANGED to report when the physical address of the CEC adapter changes. Since the physical address is obtained from the EDID the application has to be informed when the kernel (or userspace for that matter) sets that. - Add a new internal cec_set_phys_addr() function to change the physical address and post the event. - Modified the retry-transmit mechanism: the framework will do the retry if the low-level driver returns a TX_STATUS error, bu
[PATCH 5/5] drm/i915: Add support for new aspect ratios
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds support for these aspect ratios in I915 driver, at various places. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_modes.c | 12 drivers/gpu/drm/i915/intel_hdmi.c | 6 ++ drivers/gpu/drm/i915/intel_sdvo.c | 6 ++ 3 files changed, 24 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 6e66136..11f219a 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1482,6 +1482,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out, case HDMI_PICTURE_ASPECT_16_9: out->flags |= DRM_MODE_FLAG_PAR16_9; break; + case HDMI_PICTURE_ASPECT_64_27: + out->flags |= DRM_MODE_FLAG_PAR64_27; + break; + case DRM_MODE_PICTURE_ASPECT_256_135: + out->flags |= DRM_MODE_FLAG_PAR256_135; + break; case HDMI_PICTURE_ASPECT_NONE: case HDMI_PICTURE_ASPECT_RESERVED: default: @@ -1544,6 +1550,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out, case DRM_MODE_FLAG_PAR16_9: out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9; break; + case DRM_MODE_FLAG_PAR64_27: + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27; + break; + case DRM_MODE_FLAG_PAR256_135: + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135; + break; default: out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index e2dab48..bc8e2c8 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1545,6 +1545,12 @@ intel_hdmi_set_property(struct drm_connector *connector, case DRM_MODE_PICTURE_ASPECT_16_9: intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; break; + case DRM_MODE_PICTURE_ASPECT_64_27: + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; + break; + case DRM_MODE_PICTURE_ASPECT_256_135: + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; + break; default: return -EINVAL; } diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index fae64bc..370e4f9 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -2071,6 +2071,12 @@ intel_sdvo_set_property(struct drm_connector *connector, case DRM_MODE_PICTURE_ASPECT_16_9: intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; break; + case DRM_MODE_PICTURE_ASPECT_64_27: + intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; + break; + case DRM_MODE_PICTURE_ASPECT_256_135: + intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; + break; default: return -EINVAL; } -- 1.9.1
[PATCH 4/5] drm: Add flags for new aspect ratios
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds DRM flags for the new aspect ratios in the existing aspect ratio flags. Signed-off-by: Shashank Sharma --- include/uapi/drm/drm_mode.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 0dc9f6b..05a808d 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -77,6 +77,8 @@ #define DRM_MODE_PICTURE_ASPECT_NONE 0 #define DRM_MODE_PICTURE_ASPECT_4_31 #define DRM_MODE_PICTURE_ASPECT_16_9 2 +#define DRM_MODE_PICTURE_ASPECT_64_27 3 +#define DRM_MODE_PICTURE_ASPECT_256_1354 /* Aspect ratio flag bitmask (4 bits 21:19) */ #define DRM_MODE_FLAG_PARMASK (0x0F<<19) @@ -86,6 +88,10 @@ (DRM_MODE_PICTURE_ASPECT_4_3 << 19) #define DRM_MODE_FLAG_PAR16_9 \ (DRM_MODE_PICTURE_ASPECT_16_9 << 19) +#define DRM_MODE_FLAG_PAR64_27 \ + (DRM_MODE_PICTURE_ASPECT_64_27 << 19) +#define DRM_MODE_FLAG_PAR256_135 \ + (DRM_MODE_PICTURE_ASPECT_256_135 << 19) /* DPMS flags */ /* bit compatible with the xorg definitions. */ -- 1.9.1
[PATCH 3/5] video: Add new aspect ratios for HDMI 2.0
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds enumeration for the new aspect ratios in the existing aspect ratio list. Signed-off-by: Shashank Sharma --- drivers/video/hdmi.c | 4 include/linux/hdmi.h | 2 ++ 2 files changed, 6 insertions(+) diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index 1626892..1cf907e 100644 --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect) return "4:3"; case HDMI_PICTURE_ASPECT_16_9: return "16:9"; + case HDMI_PICTURE_ASPECT_64_27: + return "64:27"; + case HDMI_PICTURE_ASPECT_256_135: + return "256:135"; case HDMI_PICTURE_ASPECT_RESERVED: return "Reserved"; } diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index e974420..edbb4fc 100644 --- a/include/linux/hdmi.h +++ b/include/linux/hdmi.h @@ -78,6 +78,8 @@ enum hdmi_picture_aspect { HDMI_PICTURE_ASPECT_NONE, HDMI_PICTURE_ASPECT_4_3, HDMI_PICTURE_ASPECT_16_9, + HDMI_PICTURE_ASPECT_64_27, + HDMI_PICTURE_ASPECT_256_135, HDMI_PICTURE_ASPECT_RESERVED, }; -- 1.9.1
[PATCH 2/5] drm: Add aspect ratio parsing in DRM layer
Current DRM layer functions dont parse aspect ratio information while converting a user mode->kernel mode or viceversa. This causes modeset to pick mode with wrong aspect ratio, eventually cauing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information in DRM's mode conversion and mode comparision functions, to make sure kernel picks mode with right aspect ratio (as per the VIC). Signed-off-by: Shashank Sharma Signed-off-by: Lin, Jia Signed-off-by: Akashdeep Sharma --- drivers/gpu/drm/drm_modes.c | 34 ++ 1 file changed, 34 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index f7448a5..6e66136 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -939,6 +939,9 @@ bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1, const struct (mode2->flags & DRM_MODE_FLAG_3D_MASK)) return false; + if (mode1->picture_aspect_ratio != mode2->picture_aspect_ratio) + return false; + return drm_mode_equal_no_clocks_no_stereo(mode1, mode2); } EXPORT_SYMBOL(drm_mode_equal_no_clocks); @@ -967,6 +970,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1, mode1->vsync_end == mode2->vsync_end && mode1->vtotal == mode2->vtotal && mode1->vscan == mode2->vscan && + mode1->picture_aspect_ratio == mode2->picture_aspect_ratio && (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) == (mode2->flags & ~DRM_MODE_FLAG_3D_MASK)) return true; @@ -1469,6 +1473,22 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out, out->vrefresh = in->vrefresh; out->flags = in->flags; out->type = in->type; + out->flags &= ~DRM_MODE_FLAG_PARMASK; + + switch (in->picture_aspect_ratio) { + case HDMI_PICTURE_ASPECT_4_3: + out->flags |= DRM_MODE_FLAG_PAR4_3; + break; + case HDMI_PICTURE_ASPECT_16_9: + out->flags |= DRM_MODE_FLAG_PAR16_9; + break; + case HDMI_PICTURE_ASPECT_NONE: + case HDMI_PICTURE_ASPECT_RESERVED: + default: + out->flags |= DRM_MODE_FLAG_PARNONE; + break; + } + strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN); out->name[DRM_DISPLAY_MODE_LEN-1] = 0; } @@ -1514,6 +1534,20 @@ int drm_mode_convert_umode(struct drm_display_mode *out, strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN); out->name[DRM_DISPLAY_MODE_LEN-1] = 0; + /* Clearing picture aspect ratio bits from out flags */ + out->flags &= ~DRM_MODE_FLAG_PARMASK; + + switch (in->flags & DRM_MODE_FLAG_PARMASK) { + case DRM_MODE_FLAG_PAR4_3: + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3; + break; + case DRM_MODE_FLAG_PAR16_9: + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9; + break; + default: + out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; + } + out->status = drm_mode_validate_basic(out); if (out->status != MODE_OK) goto out; -- 1.9.1
[PATCH 1/5] drm: add picture aspect ratio flags
This patch adds drm flag bits for aspect ratio information Currently drm flag bits don't have field for mode's picture aspect ratio. This field will help the driver to pick mode with right aspect ratio, and help in setting right VIC field in avi infoframes. Signed-off-by: Shashank Sharma --- include/uapi/drm/drm_mode.h | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index c021743..0dc9f6b 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -73,6 +73,19 @@ #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14) #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14) +/* Picture aspect ratio options */ +#define DRM_MODE_PICTURE_ASPECT_NONE 0 +#define DRM_MODE_PICTURE_ASPECT_4_31 +#define DRM_MODE_PICTURE_ASPECT_16_9 2 + +/* Aspect ratio flag bitmask (4 bits 21:19) */ +#define DRM_MODE_FLAG_PARMASK (0x0F<<19) +#define DRM_MODE_FLAG_PARNONE \ + (DRM_MODE_PICTURE_ASPECT_NONE << 19) +#define DRM_MODE_FLAG_PAR4_3 \ + (DRM_MODE_PICTURE_ASPECT_4_3 << 19) +#define DRM_MODE_FLAG_PAR16_9 \ + (DRM_MODE_PICTURE_ASPECT_16_9 << 19) /* DPMS flags */ /* bit compatible with the xorg definitions. */ @@ -88,11 +101,6 @@ #define DRM_MODE_SCALE_CENTER 2 /* Centered, no scaling */ #define DRM_MODE_SCALE_ASPECT 3 /* Full screen, preserve aspect */ -/* Picture aspect ratio options */ -#define DRM_MODE_PICTURE_ASPECT_NONE 0 -#define DRM_MODE_PICTURE_ASPECT_4_31 -#define DRM_MODE_PICTURE_ASPECT_16_9 2 - /* Dithering mode options */ #define DRM_MODE_DITHERING_OFF 0 #define DRM_MODE_DITHERING_ON 1 -- 1.9.1
[PATCH 0/5] Add aspect ratio parsing
Currently DRM framework doesn't parse aspect ratio of a videomode while converting it from a umode->kmode or viceversa. This causes modeset of CEA modes with incorrect aspect ratio. While running HDMI complaince, tests (like 7-27) expect the DUT to apply the mode as per the VIC, but as driver does not consider the aspect ratio part while searching a mode from modedb, we end up setting mode with a wrong VIC, causing the test to fail. What this patch set does: Patch 1-2 - Adds aspect ratio flags in the DRM layer, in form of flags. - Adds parsing of aspect ratio, during conversion of a umode->kmode and viceversa. - Adds aspect ratio check while finding a mode, during modeset. Patch 3-5 - Adds some new aspect ratio defined in CEA-861-F specs to support HDMI 2.0 displays, in DRM and I915 layer. Shashank Sharma (5): drm: add picture aspect ratio flags drm: Add aspect ratio parsing in DRM layer video: Add new aspect ratios for HDMI 2.0 drm: Add flags for new aspect ratios drm/i915: Add support for new aspect ratios drivers/gpu/drm/drm_modes.c | 46 +++ drivers/gpu/drm/i915/intel_hdmi.c | 6 + drivers/gpu/drm/i915/intel_sdvo.c | 6 + drivers/video/hdmi.c | 4 include/linux/hdmi.h | 2 ++ include/uapi/drm/drm_mode.h | 24 +++- 6 files changed, 83 insertions(+), 5 deletions(-) -- 1.9.1
[PATCH] drm/amd: Beef up ACP Kconfig menu text
From: Borislav Petkov The current "text" needs a user to use a crystal ball in order to find out what this ACP thing is. Use the text from a8fe58cec351 ("drm/amd: add ACP driver support") to make it a bit more understandable to the rest of the world. Signed-off-by: Borislav Petkov Cc: Alex Deucher Cc: Chunming Zhou Cc: Jammy Zhou Cc: Maruthi Bayyavarapu Cc: Murali Krishna Vemuri --- drivers/gpu/drm/amd/acp/Kconfig | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/acp/Kconfig b/drivers/gpu/drm/amd/acp/Kconfig index 0f734ee05274..ca77ec10147c 100644 --- a/drivers/gpu/drm/amd/acp/Kconfig +++ b/drivers/gpu/drm/amd/acp/Kconfig @@ -1,10 +1,14 @@ -menu "ACP Configuration" +menu "ACP (Audio CoProcessor) Configuration" config DRM_AMD_ACP - bool "Enable ACP IP support" + bool "Enable AMD Audio CoProcessor IP support" select MFD_CORE select PM_GENERIC_DOMAINS if PM help Choose this option to enable ACP IP support for AMD SOCs. + This adds the ACP (Audio CoProcessor) IP driver and wires + it up into the amdgpu driver. The ACP block provides the DMA + engine for the i2s-based ALSA driver. It is required for audio + on APUs which utilize an i2s codec. endmenu -- 2.7.3
[RFC 0/6] drm/fences: add in-fences to DRM
Hi all, On 25 March 2016 at 11:58, Rob Clark wrote: > On Thu, Mar 24, 2016 at 7:49 PM, Inki Dae wrote: >> It's definitely different case. This tries to add new user-space interfaces >> to expose fences to user-space. At least, implicit interfaces are embedded >> into drivers. >> So I'd like to give you a question. Why exposing fences to user-space is >> required? To provide easy-to-debug solution to rendering pipleline? To >> provide merge fence feature? > > Well, implicit sync and explicit sync are two different cases. > Implicit sync ofc remains the default, but userspace could opt-in to > explicit sync instead. For example, on the gpu side of things, > depending on flags userspace passes in to the submit ioctl we would > either attach the fence to all the written buffers (implicit) or > return it as a fence fd to userspace (explicit), which userspace could > then pass in to atomic ioctl to synchronize pageflip. > > And visa-versa, we can pass the pageflip (atomic) completion fence > back in to gpu so it doesn't start rendering the next frame until the > buffer is off screen. > > fwiw, currently android is the first user of explicit sync (although I > expect wayland/weston to follow suit). Second, really. Vulkan avoids implicit sync entirely, and exposes fence-like primitives throughout its whole API. These include being able to pass prerequisite fences for display (what Gustavo is adding here: something to block on before display), and also when the user acquires a buffer as a render target, it is given another prerequisite fence (the other side of what Gustavo is suggesting, i.e. the fence triggers when the buffer is no longer displayed and becomes available for rendering). In order to implement this correctly, and avoid performance bubbles, we need a primitive like this exposed through the KMS API, from both sides. This is especially important when you take the case of userspace suballocation, where userspace allocates larger blocks and divides the allocation internally for different uses. Implicit sync does not work at all for that case. As stated before, there are other benefits, including much better traceability. I would expect Wayland/Weston to also start pushing support for this API relatively soon. > A couple linaro folks have > android running with an upstream kernel + mesa + atomic/kms hwc on a > couple devices (nexus7 and db410c with freedreno, and qemu with > virgl). But there are some limitations due to missing the > EGL_ANDROID_native_fence_sync extension in mesa. I plan to implement > that, but I ofc need the fence fd stuff in order to do so ;-) Yes, having that would be a godsend for a lot of people. >> And if we need really to expose fences to user-space and there is really >> real user, then we have already good candidates, DMA-BUF-IOCTL-SYNC or maybe >> fcntl system call because we share already DMA buffer between CPU <-> DMA >> and DMA <-> DMA using DMABUF. >> For DMA-BUF-IOCTL-SYNC, I think you remember that was what I tried long time >> ago because you was there. Several years ago, I tried to couple exposing the >> fences to user-space with cache operation although at that time, I really >> misleaded the fence machnism. My trying was also for the potential users. > > Note that this is not (just) about sw sync, but also sync between > multiple hw devices. Sync isn't quite good enough, because it's a mandatory blocking point for userspace. We want to push the explicit fences further down the line, so userspace can parallelise its work. Even if none of the above requirements held true, I don't think being able to support Android is a bad thing. It's completely right to be worried about pushing in Android work and APIs for the sake of it - hence why we didn't take ADF! - but in this case it's definitely a good thing. This is also the model that ChromeOS is moving towards, so it becomes more important from that point of view as well. Cheers, Daniel
[RFC 1/5] drm: Add DRM support for tiny LCD displays
Den 23.03.2016 18:28, skrev Daniel Vetter: > On Wed, Mar 23, 2016 at 06:07:56PM +0100, Noralf Trønnes wrote: >> Den 18.03.2016 18:47, skrev Daniel Vetter: >>> On Thu, Mar 17, 2016 at 10:51:55PM +0100, Noralf Trønnes wrote: Den 16.03.2016 16:11, skrev Daniel Vetter: > On Wed, Mar 16, 2016 at 02:34:15PM +0100, Noralf Trønnes wrote: >> tinydrm provides a very simplified view of DRM for displays that has >> onboard video memory and is connected through a slow bus like SPI/I2C. >> >> Signed-off-by: Noralf Trønnes > Yay, it finally happens! I already made a comment on the cover letter > about the fbdev stuff, I think that's the biggest part to split out from > tinydrm here. I'm not entirely sure a detailed code review makes sense > before that part is done (and hey we can start merging already), so just a > high level review for now: >> [...] >>> > In the case of tinydrm I think that means we should have a bunch of new > drm helpers, or extensions for existing ones: > - fbdev deferred io support using ->dirtyfb in drm_fb_helper.c. Are you thinking something like this? struct drm_fb_helper_funcs { int (*dirtyfb)(struct drm_fb_helper *fb_helper, struct drm_clip_rect *clip); >>> We already have a dirty_fb function in >>> dev->mode_config->funcs->dirty_fb(). This is the official interface native >>> drm/kms userspace is supposed to use to flush frontbuffer rendering. The >>> xfree86-video-modesetting driver uses it. >> I couldn't find this dirty_fb() function, but I assume you mean >> drm_framebuffer_funcs.dirty(). > Yup. > }; struct drm_fb_helper { spinlock_t dirty_lock; struct drm_clip_rect *dirty_clip; }; >>> Yeah, this part is needed for the delayed work for the fbdev helper. >>> struct work dirty_fb_work; is missing. >> This confuses me. >> If we have this then there's no need for a fb->funcs->dirty() call, >> the driver can just add a work function here instead. >> >> Possible fb dirty() call chain: >> Calls to drm_fb_helper_sys_* or mmap page writes will schedule >> fb_info->deferred_work. The worker func fb_deferred_io_work() calls >> fb_info->fbdefio->deferred_io(). >> Then deferred_io() can call fb_helper->fb->funcs->dirty(). >> >> In my use-case this dirty() function would schedule a delayed_work to run >> immediately since it has already been deferred collecting changes. >> The regular drm side framebuffer dirty() collects damage and schedules >> the same worker to run deferred. >> >> I don't see an easy way for a driver to set the dirty() function in >> drm_fb_cma_helper apart from doing this: >> >> struct drm_fbdev_cma { >> struct drm_fb_helperfb_helper; >> struct drm_fb_cma *fb; >> +int (*dirty)(struct drm_framebuffer *framebuffer, >> + struct drm_file *file_priv, unsigned flags, >> + unsigned color, struct drm_clip_rect *clips, >> + unsigned num_clips); >> }; > Well my point is that drm core already has a canonical interface > (drm_framebuffer_funcs.dirty) to flush out rendering. And it's supposed to > be called from process context, and userspace is supposed to batch up > dirty updates. Batched up into one ioctl call? If that's the case, then I don't have to use delayed_work like I do now. I can just queue a work_struct to run immediately. This comment in include/uapi/drm/drm_mode.h made me think that I might receive multiple calls: * The kernel or hardware is free to update more then just the * region specified by the clip rects. The kernel or hardware * may also delay and/or coalesce several calls to dirty into a * single update. I have assumed that I can't run the whole display update from the ioctl call since one full display update on the "worst" display takes ~200ms. But maybe it's fine to run all this in the ioctl call? > What I'd like is that the fbdev emulation uses exactly that interface, > without requiring drivers to write any additional fbdev code (like qxl and > udl currently have). Since the drm_framebuffer_funcs.dirty is already > expected to run in process context I think the only bit we need is the > deferred_work you already added in fbdev, so that we can schedule the > driver's ->dirty() function. > > There shouldn't be any need to have another ->dirty() function anywhere > else. I'll try and see if I can explain better with some code. First the drm_fb_helper part: void drm_fb_helper_deferred_io(struct fb_info *info, struct list_head *pagelist) { struct drm_fb_helper *helper = info->par; unsigned long start, end, min, max; struct drm_clip_rect clip; struct page *page; if (!helper->fb->funcs->dirty) return; spin_lock(&helper->dirty_lock); clip = *helper->dirty_clip; /* reset dirty_clip */ s
[PATCH v2] drm: rcar-du: Use ARCH_RENESAS
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that RENESAS seems to be a more appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. Signed-off-by: Simon Horman Acked-by: Laurent Pinchart --- Laurent, Dave, please consider applying this patch. Based on drm-next v2 * Rebased * Added Ack from Laurent Pinchart --- drivers/gpu/drm/rcar-du/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index 1f10fa0928b4..465d588eff00 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -2,7 +2,7 @@ config DRM_RCAR_DU tristate "DRM Support for R-Car Display Unit" depends on DRM && OF depends on ARM || ARM64 - depends on ARCH_SHMOBILE || COMPILE_TEST + depends on ARCH_RENESAS || COMPILE_TEST select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER -- 2.1.4
[PATCH] drm/amd: Beef up ACP Kconfig menu text
On Fri, Mar 25, 2016 at 7:27 AM, Borislav Petkov wrote: > From: Borislav Petkov > > The current "text" needs a user to use a crystal ball in order to find > out what this ACP thing is. > > Use the text from > > a8fe58cec351 ("drm/amd: add ACP driver support") > > to make it a bit more understandable to the rest of the world. > > Signed-off-by: Borislav Petkov > Cc: Alex Deucher > Cc: Chunming Zhou > Cc: Jammy Zhou > Cc: Maruthi Bayyavarapu > Cc: Murali Krishna Vemuri Applied. Thanks! Alex > --- > drivers/gpu/drm/amd/acp/Kconfig | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/acp/Kconfig b/drivers/gpu/drm/amd/acp/Kconfig > index 0f734ee05274..ca77ec10147c 100644 > --- a/drivers/gpu/drm/amd/acp/Kconfig > +++ b/drivers/gpu/drm/amd/acp/Kconfig > @@ -1,10 +1,14 @@ > -menu "ACP Configuration" > +menu "ACP (Audio CoProcessor) Configuration" > > config DRM_AMD_ACP > - bool "Enable ACP IP support" > + bool "Enable AMD Audio CoProcessor IP support" > select MFD_CORE > select PM_GENERIC_DOMAINS if PM > help > Choose this option to enable ACP IP support for AMD SOCs. > + This adds the ACP (Audio CoProcessor) IP driver and wires > + it up into the amdgpu driver. The ACP block provides the DMA > + engine for the i2s-based ALSA driver. It is required for audio > + on APUs which utilize an i2s codec. > > endmenu > -- > 2.7.3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/vc4: Add DPI driver
On Thu, Mar 24, 2016 at 05:23:50PM -0700, Eric Anholt wrote: > The DPI interface involves taking a ton of our GPIOs to be used as > outputs, and routing display signals over them in parallel. > > v2: Use display_info.bus_formats[] to replace our custom DT > properties. > > Signed-off-by: Eric Anholt > --- > .../devicetree/bindings/display/brcm,bcm-vc4.txt | 36 ++ Acked-by: Rob Herring > drivers/gpu/drm/vc4/Kconfig| 1 + > drivers/gpu/drm/vc4/Makefile | 1 + > drivers/gpu/drm/vc4/vc4_debugfs.c | 1 + > drivers/gpu/drm/vc4/vc4_dpi.c | 520 > + > drivers/gpu/drm/vc4/vc4_drv.c | 1 + > drivers/gpu/drm/vc4/vc4_drv.h | 5 + > 7 files changed, 565 insertions(+) > create mode 100644 drivers/gpu/drm/vc4/vc4_dpi.c
[PATCH 2/5 v4] drm: Add DT bindings documentation for ARC PGU display controller
On Thu, Mar 24, 2016 at 07:48:33PM +0300, Alexey Brodkin wrote: > This add DT bindings documentation for ARC PGU display controller. > > Signed-off-by: Alexey Brodkin > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Ian Campbell > Cc: Kumar Gala > Cc: devicetree at vger.kernel.org > Cc: linux-snps-arc at lists.infradead.org > --- > > Changes v3 -> v4: (addressing Rob's comments) > * Removed "encoder-slave" from required properties > * Removed "0x" from node names > > Changes v2 -> v3: > * Reverted back to initial larger version of example >with minor fixes (thanks Rob for spotting those). > > Changes v1 -> v2: > * Removed everything except PGU node itself. > > .../devicetree/bindings/display/snps,arcpgu.txt| 71 > ++ > 1 file changed, 71 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt > > diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt > b/Documentation/devicetree/bindings/display/snps,arcpgu.txt > new file mode 100644 > index 000..b126577 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt > @@ -0,0 +1,71 @@ > +ARC PGU > + > +This is a display controller found on several development boards produced > +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a > +framebuffer and sends it to a single digital encoder (usually HDMI). > + > +Required properties: > + - compatible: "snps,arcpgu" > + - reg: Physical base address and length of the controller's registers. > + - clocks: A list of phandle + clock-specifier pairs, one for each > +entry in 'clock-names'. > + - clock-names: A list of clock names. For ARC PGU it should contain: > + - "pxlclk" for the clock feeding the output PLL of the controller. > + > +Required sub-nodes: > + - port: The PGU connection to an encoder chip. > + > +Example: > + > +/ { > + ... > + > + pgu at { > + compatible = "snps,arcpgu"; > + reg = <0x 0x400>; > + clocks = <&clock_node>; > + clock-names = "pxlclk"; > + encoder-slave = <&encoder_node>; Still in the example... Otherwise, Acked-by: Rob Herring
[PATCH v2] drm: rcar-du: Use ARCH_RENESAS
Hi Simon, On Friday 25 Mar 2016 10:38:28 Simon Horman wrote: > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more > appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. > > Signed-off-by: Simon Horman > Acked-by: Laurent Pinchart > --- > Laurent, Dave, please consider applying this patch. I took the patch in my tree and send a pull request for v4.7. > Based on drm-next > > v2 > * Rebased > * Added Ack from Laurent Pinchart > --- > drivers/gpu/drm/rcar-du/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/rcar-du/Kconfig > b/drivers/gpu/drm/rcar-du/Kconfig index 1f10fa0928b4..465d588eff00 100644 > --- a/drivers/gpu/drm/rcar-du/Kconfig > +++ b/drivers/gpu/drm/rcar-du/Kconfig > @@ -2,7 +2,7 @@ config DRM_RCAR_DU > tristate "DRM Support for R-Car Display Unit" > depends on DRM && OF > depends on ARM || ARM64 > - depends on ARCH_SHMOBILE || COMPILE_TEST > + depends on ARCH_RENESAS || COMPILE_TEST > select DRM_KMS_HELPER > select DRM_KMS_CMA_HELPER > select DRM_GEM_CMA_HELPER -- Regards, Laurent Pinchart
[PATCH 2/3] devicetree: Add ANX7814 bridge binding.
On Thu, Mar 24, 2016 at 11:41:45AM +0100, Enric Balletbo i Serra wrote: > The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > designed for portable devices. > > Signed-off-by: Enric Balletbo i Serra > --- > .../devicetree/bindings/video/bridge/anx7814.txt | 41 > ++ > 1 file changed, 41 insertions(+) > create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt > > diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt > b/Documentation/devicetree/bindings/video/bridge/anx7814.txt > new file mode 100644 > index 000..5a47a42 > --- /dev/null > +++ b/Documentation/devicetree/bindings/video/bridge/anx7814.txt > @@ -0,0 +1,41 @@ > +Analogix ANX7814 SlimPort (Full-HD Transmitter) > +--- > + > +The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > +designed for portable devices. > + > +Required properties: > + > + - compatible: "analogix,anx7814" > + - reg : I2C address of the device > + - interrupt-parent : Should be the phandle of the interrupt controller > + that services interrupts for this device > + - interrupts: Should contain the INTP interrupt > + - cable-det-gpios : Which GPIO to use for cable detection hpd-gpios is the more standard name. > + - pd-gpios : Which GPIO to use for power down > + - reset-gpios : Which GPIO to use for reset > + > +Optional properties: > + > + - v10-gpios : Which GPIO to use for V10 control. > + - Video port for HDMI output, using the DT bindings defined in [1]. It is HDMI input from this node's perspective, right? > + > +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt > + > +Example: > + > + anx7814: anx7814 at 38 { > + compatible = "analogix,anx7814"; > + reg = <0x38>; > + interrupt-parent = <&gpio0>; > + interrupts = <99 IRQ_TYPE_LEVEL_LOW>; /* INTP */ > + cable-det-gpios = <&pio 36 GPIO_ACTIVE_HIGH>; > + pd-gpios = <&pio 33 GPIO_ACTIVE_HIGH>; > + reset-gpios = <&pio 98 GPIO_ACTIVE_HIGH>; > + v10-gpios = <&pio 35 GPIO_ACTIVE_HIGH>; > + port { > + anx7814_in: endpoint { > + remote-endpoint = <&hdmi0_out>; > + }; > + }; > + }; > -- > 2.1.0 >
[PATCH 1/1] drm: fsl-dcu: Use flat cache
Hi Alexander, On 2016-03-24 06:33, Alexander Stein wrote: > Using REGCACHE_RBTREE for MMIO regmap is not valid as spinlock's will be > used during cache allocation. > > This fixes the following bug: > BUG: sleeping function called from invalid context at mm/slab.h:388 > in_atomic(): 1, irqs_disabled(): 128, pid: 192, name: udevd > [...] > > Signed-off-by: Alexander Stein > --- > Please refer also to the discussion at > https://lists.freedesktop.org/archives/dri-devel/2016-January/098696.html > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > index e8d9337..ea65140 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > @@ -40,7 +40,7 @@ static const struct regmap_config fsl_dcu_regmap_config = { > .reg_bits = 32, > .reg_stride = 4, > .val_bits = 32, > - .cache_type = REGCACHE_RBTREE, > + .cache_type = REGCACHE_FLAT, To use flat regcache you also need to set the max_register. I already have such a patch, see: https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html However, the current suspend/resume implementation (which uses the regcache) is anyway flawed. I currently prepare a patchset to remove the regmap cache entirely and use Thierry's new generic suspend/resume functions. -- Stefan > > .volatile_reg = fsl_dcu_drm_is_volatile_reg, > };
[PATCH 1/3] of: Add vendor prefix for Analogix Semiconductor
On Thu, Mar 24, 2016 at 11:41:44AM +0100, Enric Balletbo i Serra wrote: > Analogix Semiconductor Inc. develops analog and mixed-signal devices for > digital media and communications interconnect applications. > > Signed-off-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring
[PATCH v3 13/19] drm: sun4i: Add DT bindings documentation
On Wed, Mar 23, 2016 at 05:38:36PM +0100, Maxime Ripard wrote: > The display pipeline of the Allwinner A10 is involving several loosely > coupled components. > > Add a documentation for the bindings. > > Signed-off-by: Maxime Ripard > --- > .../bindings/display/sunxi/sun4i-drm.txt | 254 > + > 1 file changed, 254 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > new file mode 100644 > index ..378edb919eae > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -0,0 +1,254 @@ > +Allwinner A10 Display Pipeline > +== > + > +The Allwinner A10 Display pipeline is composed of several components > +that are going to be documented below: > + > +TV Encoder > +-- > + > +The TV Encoder supports the composite and VGA output. It is one end of > +the pipeline. > + > +Required properties: > + - compatible: value should be "allwinner,sun4i-a10-tv-encoder". > + - reg: base address and size of memory-mapped region > + - clocks: the clocks driving the TV encoder > + - resets: phandle to the reset controller driving the encoder > + > +- ports: A ports node with endpoint definitions as defined in > + Documentation/devicetree/bindings/media/video-interfaces.txt. The > + first port should be the input endpoint. > + > +TCON > + > + > +The TCON acts as a timing controller for RGB, LVDS and TV interfaces. > + > +Required properties: > + - compatible: value should be "allwinner,sun5i-a13-tcon". > + - reg: base address and size of memory-mapped region > + - interrupts: interrupt associated to this IP > + - clocks: phandles to the clocks feeding the TCON. Three are needed: > + - 'ahb': the interface clocks > + - 'tcon-ch0': The clock driving the TCON channel 0 > + - 'tcon-ch1': The clock driving the TCON channel 1 > + - resets: phandles to the reset controllers driving the encoder > + - "lcd": the reset line for the TCON channel 0 > + > + - clock-names: the clock names mentioned above > + - reset-names: the reset names mentioned above > + - clock-output-names: Name of the pixel clock created > + > +- ports: A ports node with endpoint definitions as defined in > + Documentation/devicetree/bindings/media/video-interfaces.txt. The > + first port should be the input endpoint, the second one the output The example shows 2 output endpoints. Your diagram shows up to 4 outputs. The number should be how ever many could coexist in a given h/w design. In other words, I'm assuming all 4 can't be used simultaneously, but can all 4 be wired up in a h/w design and switched in s/w? Just be clear on the numbering. > + > +Endpoints optional property: > + - allwinner,panel: boolean to indicate that the endpoint is a panel This can be determined by the endpoint not being TV Encoder (or HDMI). > + > + > +Display Engine Backend > +-- > + > +The display engine backend exposes layers and sprites to the > +system. > + > +Required properties: > + - compatible: value must be one of: > +* allwinner,sun5i-a13-display-backend > + - reg: base address and size of the memory-mapped region. > + - clocks: phandles to the clocks feeding the frontend and backend > +* ahb: the backend interface clock > +* mod: the backend module clock > +* ram: the backend DRAM clock > + - clock-names: the clock names mentioned above > + - resets: phandles to the reset controllers driving the backend > + > +- ports: A ports node with endpoint definitions as defined in > + Documentation/devicetree/bindings/media/video-interfaces.txt. The > + first port should be the input endpoints, the second one the output > + > +Display Engine Frontend > +--- > + > +The display engine frontend does formats conversion, scaling, > +deinterlacing and color space conversion. > + > +Required properties: > + - compatible: value must be one of: > +* allwinner,sun5i-a13-display-frontend > + - reg: base address and size of the memory-mapped region. > + - interrupts: interrupt associated to this IP > + - clocks: phandles to the clocks feeding the frontend and backend > +* ahb: the backend interface clock > +* mod: the backend module clock > +* ram: the backend DRAM clock > + - clock-names: the clock names mentioned above > + - resets: phandles to the reset controllers driving the backend > + > +Display Engine Pipeline > +--- > + > +The display engine pipeline (and its entry point, since it can be > +either directly the backend or the frontend) is represented as an > +extra node. > + > +Required properties: > + - compatible: value must be one of: > +* allwinner,sun5i-a13-display-engine > + - allwinner,pipelines: list of phandle to the entry points of the > +pipeli
[RFC 0/6] drm/fences: add in-fences to DRM
2016ë 03ì 25ì¼ 00:40ì Rob Clark ì´(ê°) ì´ ê¸: > On Thu, Mar 24, 2016 at 4:18 AM, Inki Dae wrote: >> Hi, >> >> 2016ë 03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸: >>> From: Gustavo Padovan >>> >>> Hi, >>> >>> This is a first proposal to discuss the addition of in-fences support >>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file >>> in DRM drivers. The new struct fence_collection contains a array with all >>> fences that a atomic commit needs to wait on >> >> As I mentioned already like below, >> http://www.spinics.net/lists/dri-devel/msg103225.html >> >> I don't see why Android specific thing is tried to propagate to Linux DRM. >> In Linux mainline, it has already implicit sync interfaces for DMA devices >> called dma fence which forces registering a fence obejct to DMABUF through a >> reservation obejct when a dmabuf object is created. However, Android sync >> driver creates a new file for a sync object and this would have different >> point of view. >> >> Is there anyone who can explan why Android specific thing is tried to spread >> into Linux DRM? Was there any consensus to use Android sync driver - which >> uses explicit sync interfaces - as Linux standard? >> > > btw, there is already plane_state->fence .. which I don't think has > any users yet, but I start to use it in my patchset that converts > drm/msm to 'struct fence' Yes, Exynos also started it. > > That said, we do need syncpt as the way to expose fences to userspace > for explicit synchronization, but I'm not entirely sure that the It's definitely different case. This tries to add new user-space interfaces to expose fences to user-space. At least, implicit interfaces are embedded into drivers. So I'd like to give you a question. Why exposing fences to user-space is required? To provide easy-to-debug solution to rendering pipleline? To provide merge fence feature? And if we need really to expose fences to user-space and there is really real user, then we have already good candidates, DMA-BUF-IOCTL-SYNC or maybe fcntl system call because we share already DMA buffer between CPU <-> DMA and DMA <-> DMA using DMABUF. For DMA-BUF-IOCTL-SYNC, I think you remember that was what I tried long time ago because you was there. Several years ago, I tried to couple exposing the fences to user-space with cache operation although at that time, I really misleaded the fence machnism. My trying was also for the potential users. Anyway, my opinion is that we could expose the fences hided by DMABUF to user-space using interfaces it exists already around us. And for this, below Chromium solution would also give us some helps, https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.18/drivers/gpu/drm/drm_sync_helper.c And in /driver/dma-buf/, there are DMABUF-centric modules so looks strange sync_file module of Android is placed in that directory - Android sync driver doesn't use really DMABUF but creates new file for their sync fence instead. For implicit sync interfaces for DMA devices, we use DMABUF and for explict sync interfaces for user-space, we use sync_file not DMABUF? That doesn't make sense. I love really Android but I feel as if we try to give a seat available to Android somehow. Thanks, Inki Dae > various drivers ever need to see that (vs just struct fence), at least > on the kms side of things. > > BR, > -R > > >> Thanks, >> Inki Dae >> >>> >>> /** >>> * struct fence_collection - aggregate fences together >>> * @num_fences: number of fence in the collection. >>> * @user_data: user data. >>> * @func: user callback to put user data. >>> * @fences: array of @num_fences fences. >>> */ >>> struct fence_collection { >>>int num_fences; >>>void *user_data; >>>collection_put_func_t func; >>>struct fence *fences[]; >>> }; >>> >>> >>> The fence_collection is allocated and filled by sync_file_fences_get() and >>> atomic_commit helpers can use fence_collection_wait() to wait the fences to >>> signal. >>> >>> These patches depends on the sync ABI rework: >>> >>> https://www.spinics.net/lists/dri-devel/msg102795.html >>> >>> and the patch to de-stage the sync framework: >>> >>> https://www.spinics.net/lists/dri-devel/msg102799.html >>> >>> >>> I also hacked together some sync support into modetest for testing: >>> >>> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic >>> >>> >>> Gustavo >>> >>> >>> Gustavo Padovan (6): >>> drm/fence: add FENCE_FD property to planes >>> dma-buf/fence: add struct fence_collection >>> dma-buf/sync_file: add sync_file_fences_get() >>> dma-buf/fence: add fence_collection_put() >>> dma-buf/fence: add fence_collection_wait() >>> drm/fence: support fence_collection on atomic commit >>> >>> drivers/dma-buf/fence.c | 33 + >>> drivers/dma-buf/sync_file.c | 36 >>> >>>
[Bug 94692] Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0"
https://bugs.freedesktop.org/show_bug.cgi?id=94692 --- Comment #2 from Nicholas Vaughan --- (In reply to Elia Argentieri from comment #1) > Sadly performance are NOT worth the price of the product. I still prefer my > older HD 6670 with 2GB VRAM which gives me much more stable fps. With R7 > 370, Xonotic is almost unplayable because of stuttering even with lowest > settings. Elia, First of all, wonderful to hear from you that your kernel patch was included! Secondly, the primary graphics load that I put on my desktop is running DotA 2, which runs *phenomenally* now that I have added this quirk-- with one caveat; that caveat being that loading un-seen models (or something like that?) causes stuttering the first time that they are seen. Fortunately, the fix for this, in this game, is trivial: drag the camera view as rapidly as possible over the entire map at the beginning of my first match of the day (this take 2~3 seconds). And by phenomenally, I mean that i got 20~40 fps before adding this quirk, with all options off other than texture quality being on high, and now I get a consistent 60fps with all settings turned on (global lighting, specular, additive lighting pass, etc., etc.), shadow settings on ultra (instead of off), vsync, and anti-aliasing (I assume it is 2x AA). In short, to me, adding this quirk is an incredible boon, removes any desire I've ever had to use Catalyst (yuck.), and I'm just thrilled to have it. I'd like to thank you personally, Elia, because your bug report was the first I saw which was short enough for me to read, but showed a solution to a problem that I've had for ages. With all of my thanks, Nicholas P.S.: Perhaps you, or someone else (not really sure who does what around here) should change the status of your bug from "NEW" to "RESOLVED", possibly with a comment on which kernels now support the quirk? :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/0ea8d9f4/attachment.html>
[RFC 0/6] drm/fences: add in-fences to DRM
Hi Guestavo, 2016ë 03ì 24ì¼ 23:39ì Gustavo Padovan ì´(ê°) ì´ ê¸: > Hi Inki, > > 2016-03-24 Inki Dae : > >> Hi, >> >> 2016ë 03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸: >>> From: Gustavo Padovan >>> >>> Hi, >>> >>> This is a first proposal to discuss the addition of in-fences support >>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file >>> in DRM drivers. The new struct fence_collection contains a array with all >>> fences that a atomic commit needs to wait on >> >> As I mentioned already like below, >> http://www.spinics.net/lists/dri-devel/msg103225.html >> >> I don't see why Android specific thing is tried to propagate to Linux DRM. >> In Linux mainline, it has already implicit sync interfaces for DMA devices >> called dma fence which forces registering a fence obejct to DMABUF through a >> reservation obejct when a dmabuf object is created. However, Android sync >> driver creates a new file for a sync object and this would have different >> point of view. >> >> Is there anyone who can explan why Android specific thing is tried to spread >> into Linux DRM? Was there any consensus to use Android sync driver - which >> uses explicit sync interfaces - as Linux standard? > > Because we want explicit fencing as the Linux standard in the future to > be able to do smart scheduling, e.g., send async jobs to the gpu and at > the same time send async atomic commits with sync_file fd attached so > they can wait the GPU to finish and we don't block in userspace anymore, > quite similar to what Android does. GPU is also DMA device so I think the synchonization should be handled transparent to user-space. And I know that Chromium guy already did similar thing with non-atomic commit only using implicit sync, https://chromium.googlesource.com/chromiumos/third_party/kernel branch name : chromeos-3.14 Of course, this approach uses a new helper framework placed in drm directory so I think if this framework can be moved into dma-buf directory after some cleanup and refactoring them if necessary. Anyway, I'm not sure I understood the smart scheduling you mentioned but I think we could do what you try to do without the explicit fence. > > This would still use dma-buf fences in the driver level, but it has a > lot more advantages than implicit fencing. You means things for rendering pipeline debugging and merging sync fences? Thanks, Inki Dae > > Gustavo > >
[Bug 94692] Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0"
https://bugs.freedesktop.org/show_bug.cgi?id=94692 --- Comment #1 from Elia Argentieri --- Hi, my quirk was included in Linux [1]. In fact from Debian's kernel 4.4 it successfully boots without having to recompile. Sadly performance are NOT worth the price of the product. I still prefer my older HD 6670 with 2GB VRAM which gives me much more stable fps. With R7 370, Xonotic is almost unplayable because of stuttering even with lowest settings. Also after almost an year I see no progress on this front. They included the quirk and nothing more. I still have to understand why all this happens in the first place! What kind of black magic is Catalyst doing? Why can't we do the same? These are my two cents, Elia [1]: https://github.com/torvalds/linux/commit/e71c1b9261d627677590f61273dddc0e87eb6a7e -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/0c698340/attachment-0001.html>
[RFC 0/6] drm/fences: add in-fences to DRM
On Thu, Mar 24, 2016 at 7:49 PM, Inki Dae wrote: > > > 2016ë 03ì 25ì¼ 00:40ì Rob Clark ì´(ê°) ì´ ê¸: >> On Thu, Mar 24, 2016 at 4:18 AM, Inki Dae wrote: >>> Hi, >>> >>> 2016ë 03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸: From: Gustavo Padovan Hi, This is a first proposal to discuss the addition of in-fences support to DRM. It adds a new struct to fence.c to abstract the use of sync_file in DRM drivers. The new struct fence_collection contains a array with all fences that a atomic commit needs to wait on >>> >>> As I mentioned already like below, >>> http://www.spinics.net/lists/dri-devel/msg103225.html >>> >>> I don't see why Android specific thing is tried to propagate to Linux DRM. >>> In Linux mainline, it has already implicit sync interfaces for DMA devices >>> called dma fence which forces registering a fence obejct to DMABUF through >>> a reservation obejct when a dmabuf object is created. However, Android sync >>> driver creates a new file for a sync object and this would have different >>> point of view. >>> >>> Is there anyone who can explan why Android specific thing is tried to >>> spread into Linux DRM? Was there any consensus to use Android sync driver - >>> which uses explicit sync interfaces - as Linux standard? >>> >> >> btw, there is already plane_state->fence .. which I don't think has >> any users yet, but I start to use it in my patchset that converts >> drm/msm to 'struct fence' > > Yes, Exynos also started it. > >> >> That said, we do need syncpt as the way to expose fences to userspace >> for explicit synchronization, but I'm not entirely sure that the > > It's definitely different case. This tries to add new user-space interfaces > to expose fences to user-space. At least, implicit interfaces are embedded > into drivers. > So I'd like to give you a question. Why exposing fences to user-space is > required? To provide easy-to-debug solution to rendering pipleline? To > provide merge fence feature? > Well, implicit sync and explicit sync are two different cases. Implicit sync ofc remains the default, but userspace could opt-in to explicit sync instead. For example, on the gpu side of things, depending on flags userspace passes in to the submit ioctl we would either attach the fence to all the written buffers (implicit) or return it as a fence fd to userspace (explicit), which userspace could then pass in to atomic ioctl to synchronize pageflip. And visa-versa, we can pass the pageflip (atomic) completion fence back in to gpu so it doesn't start rendering the next frame until the buffer is off screen. fwiw, currently android is the first user of explicit sync (although I expect wayland/weston to follow suit). A couple linaro folks have android running with an upstream kernel + mesa + atomic/kms hwc on a couple devices (nexus7 and db410c with freedreno, and qemu with virgl). But there are some limitations due to missing the EGL_ANDROID_native_fence_sync extension in mesa. I plan to implement that, but I ofc need the fence fd stuff in order to do so ;-) > And if we need really to expose fences to user-space and there is really real > user, then we have already good candidates, DMA-BUF-IOCTL-SYNC or maybe fcntl > system call because we share already DMA buffer between CPU <-> DMA and DMA > <-> DMA using DMABUF. > For DMA-BUF-IOCTL-SYNC, I think you remember that was what I tried long time > ago because you was there. Several years ago, I tried to couple exposing the > fences to user-space with cache operation although at that time, I really > misleaded the fence machnism. My trying was also for the potential users. Note that this is not (just) about sw sync, but also sync between multiple hw devices. BR, -R > Anyway, my opinion is that we could expose the fences hided by DMABUF to > user-space using interfaces it exists already around us. And for this, below > Chromium solution would also give us some helps, > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.18/drivers/gpu/drm/drm_sync_helper.c > > And in /driver/dma-buf/, there are DMABUF-centric modules so looks strange > sync_file module of Android is placed in that directory - Android sync driver > doesn't use really DMABUF but creates new file for their sync fence instead. > For implicit sync interfaces for DMA devices, we use DMABUF and for explict > sync interfaces for user-space, we use sync_file not DMABUF? That doesn't > make sense. > > I love really Android but I feel as if we try to give a seat available to > Android somehow. > > Thanks, > Inki Dae > >> various drivers ever need to see that (vs just struct fence), at least >> on the kms side of things. >> >> BR, >> -R >> >> >>> Thanks, >>> Inki Dae >>> /** * struct fence_collection - aggregate fences together * @num_fences: number of fence in the collection. * @user_data: user data. * @func: user callback to put user
[Bug 94692] Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0"
https://bugs.freedesktop.org/show_bug.cgi?id=94692 Nicholas Vaughan changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=91294 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/bf23e7c4/attachment.html>
[Bug 91294] [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=91294 Nicholas Vaughan changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=94692 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/d57f59c5/attachment.html>
[Bug 94692] Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0"
https://bugs.freedesktop.org/show_bug.cgi?id=94692 Nicholas Vaughan changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=92260 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/49e0b9ed/attachment.html>
[Bug 92260] ASUS [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=92260 Nicholas Vaughan changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=94692 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/4c07abf9/attachment.html>
[Bug 94692] Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0"
https://bugs.freedesktop.org/show_bug.cgi?id=94692 Nicholas Vaughan changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=76490 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/7a9dd4d5/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 Nicholas Vaughan changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=94692 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/3d55a757/attachment.html>
[Bug 94692] Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0"
https://bugs.freedesktop.org/show_bug.cgi?id=94692 Bug ID: 94692 Summary: Booting with R7 370 hangs without kernel parameters "nomodeset" or "radeon.dpm=0" Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: nchlsvaughan at gmail.com Specific card: "SAPPHIRE Radeon⢠Dual-X R7 370 2G D5" When booting with radeon.dpm=0, setting the power_method to "dynpm" (from the default of "profile" appears to do nothing. Without changing anything after booting, /sys/kernel/debug/dri/0/radeon_pm_info reports absurdly low memory and engine clock rates. echo'ing "low" or "mid" to /sys/class/drm/card0/device/power_profile causes the clock rates to rise slightly, but still to nowhere near what radeon_pm_info reports the card to be capable of (whether I echo "low" or "mid" does not seem to matter-- they have the same effect on the clocks). After changing the power_profile, changing it to "high", "auto", or even back to "default" causes the system to immediately hang. After seeing Elia Argentieri's success with adding a line to the dpm quirk's array [1], I decided to see if doing something similar would resolve my problem. >From /var/log/Xorg.0.log's (--) PCI:*(0:1:0:0) 1002:6811:174b:2015 rev 129, Mem @ 0xe000/268435456, 0xf7e0/262144, I/O @ 0xe000/256, BIOS @ 0x/131072 line, I presume that my card's specific chip_device, subsys_vendor, and subsys_device are 0x6811, 0x174b, and 0x2015, respectively. As I did not see this set of identifiers listed in the "si_dpm_quirk_list" array in drivers/gpu/drm/radeon/si_dpm.c in kernel 4.4.6 [2], nor in kernel 4.5 [3], I decided to try my hand at compiling the kernel myself. First I compiled the kernel (4.4.6) without modification as a control, to ensure that if I made a modification which caused DPM to work as intended, it was the modification which had fixed the problem. This kernel, as expected, would hang if not booted with the either of the kernel parameters "nomodeset" or "radeon.dpm=0". Then, I added the same line that Elia added to the quirks array, changing only the identifiers specific to my card. Specifically, I added the following line to the quirks array: { PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0x2015, 0, 12 }, Upon compiling, installing, and running the kernel, I found that it booted without "nomodeset" or "radeon.dpm=0", and that DPM actively raised the engine clock to its quoted maximum (985MHz) at power level 4, and raised the memory clock to its quirk-limited maximum of 1200MHz at power level 1 and above, while keeping the clocks down to 300MHz and 150MHz respectively at power level 0 with no noticeable degradation of desktop performance. I would very much like to get this quirk included in the Linux kernel source so that I do not have to manually compile my own kernels. If there is *any* further information I can provide to ensure that this happens, please let me know and I will try to respond as quickly as possible. Elia's quirk seems to have been entirely ignored, and this does not bode well for the quirk my card requires. Your swift reply is appreciated, Nicholas [1] https://bugs.freedesktop.org/show_bug.cgi?id=91294 [2] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/radeon/si_dpm.c?id=refs/tags/v4.4.6#n2925 [3] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/si_dpm.c?id=refs/tags/v4.5#n2925 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/900a37a3/attachment-0001.html>
[git pull] drm fixes
Hi Linus, Just a couple of dma-buf related fixes and some amdgpu fixes, along with a regression fix for radeon off but default feature, but makes my 30" monitor happy again. Dave. The following changes since commit 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7: drm/amdgpu: release_pages requires linux/pagemap.h (2016-03-21 13:22:52 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to 4604202ca8d2a5e33b4bca0812b5d92975ed1bd8: Merge branch 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-next (2016-03-25 16:02:06 +1000) Alex Deucher (1): drm/amdgpu: clean up path handling for powerplay Andrzej Hajda (2): drm/atomic: use helper to get crtc state drm/atmel-hlcdc: use helper to get crtc state Chris Wilson (1): dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access() Christian König (3): dma-buf/fence: fix fence_is_later v2 drm/amdgpu: Revert "remove the userptr rmn->lock" drm/amdgpu: add invalidate_page callback for userptrs Colin Ian King (1): drm/amd/powerplay: fix memory leak of tdp_table Daniel Vetter (1): dma-buf: Update docs for SYNC ioctl Dave Airlie (4): drm/radeon/mst: fix regression in lane/link handling. drm/radeon/mst: cleanup code indentation Merge tag 'topic/drm-misc-2016-03-22' of git://anongit.freedesktop.org/drm-intel into drm-next Merge branch 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-next Luis de Bethencourt (1): drm: remove excess description Documentation/dma-buf-sharing.txt | 11 +- drivers/dma-buf/dma-buf.c | 19 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 120 +++-- drivers/gpu/drm/amd/powerplay/Makefile | 14 +-- .../amd/powerplay/hwmgr/tonga_processpptables.c| 4 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 2 +- drivers/gpu/drm/drm_atomic.c | 1 - drivers/gpu/drm/drm_atomic_helper.c| 14 +-- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 15 +-- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 5 +- drivers/gpu/drm/radeon/radeon_dp_mst.c | 22 ++-- drivers/gpu/drm/udl/udl_fb.c | 4 +- drivers/staging/android/ion/ion.c | 6 +- include/linux/dma-buf.h| 6 +- include/linux/fence.h | 2 +- 15 files changed, 147 insertions(+), 98 deletions(-)
[PATCH] drm: rcar-du: Add Z-order support for VSP planes
Make the Z-order of VSP planes configurable through the zpos property, exactly as for the native DU planes. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16 drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 ++ 2 files changed, 14 insertions(+), 4 deletions(-) This patch depends on "[PATCH 00/51] R-Car VSP improvements for v4.6" patch series posted to the linux-media and linux-renesas-soc mailing lists. diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index de7ef041182b..62e9619eaea4 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c @@ -180,8 +180,9 @@ static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane) WARN_ON(!pixelformat); - vsp1_du_atomic_update(plane->vsp->vsp, plane->index, pixelformat, - fb->pitches[0], paddr, &src, &dst); + vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat, + fb->pitches[0], paddr, &src, &dst, + state->zpos); } static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane, @@ -220,8 +221,8 @@ static void rcar_du_vsp_plane_atomic_update(struct drm_plane *plane, if (plane->state->crtc) rcar_du_vsp_plane_setup(rplane); else - vsp1_du_atomic_update(rplane->vsp->vsp, rplane->index, 0, 0, 0, - NULL, NULL); + vsp1_du_atomic_update_zpos(rplane->vsp->vsp, rplane->index, + 0, 0, 0, NULL, NULL, 0); } static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = { @@ -269,6 +270,7 @@ static void rcar_du_vsp_plane_reset(struct drm_plane *plane) return; state->alpha = 255; + state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1; plane->state = &state->state; plane->state->plane = plane; @@ -283,6 +285,8 @@ static int rcar_du_vsp_plane_atomic_set_property(struct drm_plane *plane, if (property == rcdu->props.alpha) rstate->alpha = val; + else if (property == rcdu->props.zpos) + rstate->zpos = val; else return -EINVAL; @@ -299,6 +303,8 @@ static int rcar_du_vsp_plane_atomic_get_property(struct drm_plane *plane, if (property == rcdu->props.alpha) *val = rstate->alpha; + else if (property == rcdu->props.zpos) + *val = rstate->zpos; else return -EINVAL; @@ -378,6 +384,8 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp) drm_object_attach_property(&plane->plane.base, rcdu->props.alpha, 255); + drm_object_attach_property(&plane->plane.base, + rcdu->props.zpos, 1); } return 0; diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h index df3bf3805c69..510dcc9c6816 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h @@ -44,6 +44,7 @@ static inline struct rcar_du_vsp_plane *to_rcar_vsp_plane(struct drm_plane *p) * @state: base DRM plane state * @format: information about the pixel format used by the plane * @alpha: value of the plane alpha property + * @zpos: value of the plane zpos property */ struct rcar_du_vsp_plane_state { struct drm_plane_state state; @@ -51,6 +52,7 @@ struct rcar_du_vsp_plane_state { const struct rcar_du_format_info *format; unsigned int alpha; + unsigned int zpos; }; static inline struct rcar_du_vsp_plane_state * -- Regards, Laurent Pinchart
[PATCH 1/5 v4] drm: Add support of ARC PGU display controller
Hi Carlos, [auto build test ERROR on drm/drm-next] [also build test ERROR on v4.5 next-20160324] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Alexey-Brodkin/drm-Add-support-of-ARC-PGU-display-controller/20160325-005345 base: git://people.freedesktop.org/~airlied/linux.git drm-next config: i386-allmodconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/gpu/drm/arc/arcpgu_drv.c: In function 'arcpgu_probe': >> drivers/gpu/drm/arc/arcpgu_drv.c:232:8: error: implicit declaration of >> function 'drm_connector_register_all' [-Werror=implicit-function-declaration] ret = drm_connector_register_all(drm); ^ drivers/gpu/drm/arc/arcpgu_drv.c: In function 'arcpgu_remove': >> drivers/gpu/drm/arc/arcpgu_drv.c:254:2: error: implicit declaration of >> function 'drm_connector_unregister_all' >> [-Werror=implicit-function-declaration] drm_connector_unregister_all(drm); ^ cc1: some warnings being treated as errors vim +/drm_connector_register_all +232 drivers/gpu/drm/arc/arcpgu_drv.c 226 goto err_unref; 227 228 ret = drm_dev_register(drm, 0); 229 if (ret) 230 goto err_unload; 231 > 232 ret = drm_connector_register_all(drm); 233 if (ret) 234 goto err_unregister; 235 236 return 0; 237 238 err_unregister: 239 drm_dev_unregister(drm); 240 241 err_unload: 242 arcpgu_unload(drm); 243 244 err_unref: 245 drm_dev_unref(drm); 246 247 return ret; 248 } 249 250 static int arcpgu_remove(struct platform_device *pdev) 251 { 252 struct drm_device *drm = platform_get_drvdata(pdev); 253 > 254 drm_connector_unregister_all(drm); 255 drm_dev_unregister(drm); 256 arcpgu_unload(drm); 257 drm_dev_unref(drm); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/octet-stream Size: 53512 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/f1605ccf/attachment-0001.obj>
[PATCH 02/23] ARM: dts: n950: add display support
Hi, On Thu, Mar 24, 2016 at 05:11:15PM +0200, Jani Nikula wrote: > On Thu, 24 Mar 2016, Sebastian Reichel wrote: > > As I said: I did use 864 initially. That results in missing pixels. > > Sorry, I didn't mean to question this. Go with what works, not with some > old fart's ramblings! No problem. I also wondered why this has been done. If I understood Tomi right, the userspace team feared, that their software would not work with 864, since it was originally written for 854. Anyways I'm pretty sure, that the first 5 pixels are unusable from the users point of view. > > I _think_, that your HW team decided to cover the first and the > > last few pixels of the 864 display with plastic. So technically > > it's a 864 display, but effectively it's 854. > > (*shudder* at "your HW team" ;) ;) > It's plausible, the covers did change slightly for the developer > edition. Assuming the non-developer edition can use the full display it can be "unlocked" with my proposed DT bindings by slight modifications. I guess there exist just a couple of those, so maybe we just ignore it for the mainline kernel? > Good luck with the upstreaming efforts! Thanks. -- Sebastian -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/973bd116/attachment-0001.sig>
[Bug 94484] Kernel BUG with latest radeon driver
https://bugs.freedesktop.org/show_bug.cgi?id=94484 --- Comment #6 from Michel D�nzer --- (In reply to Tyler Brock from comment #5) > Anything I can do to help? Bisecting would be hard as its not reproducible > 100% of the time. It would essentially take a day to test each revision. That's fine; take your time. (If you had started when you reported the bug, you might be done by now :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160325/11a51a63/attachment.html>