[RFC 1/5] drm: Add DRM support for tiny LCD displays

[Noralf Trønnes]

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 = _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   = _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(>deferred->dwork);
>> +
>> +   tinydrm_fbdev_fini(tdev);
>> +
>> +   drm_panel_detach(>panel);
>> +   drm_panel_remove(>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 = _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

[bugzilla-dae...@freedesktop.org]

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"

[bugzilla-dae...@freedesktop.org]

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

[Inki Dae]

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

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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=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

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@bugzilla.kernel.org]

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"

[bugzilla-dae...@freedesktop.org]

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=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

[bugzilla-dae...@freedesktop.org]

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

[Hans Verkuil]

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,  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_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 
.
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.
+
+A sink received a 

[PATCHv14 17/18] vivid: add CEC emulation

[Hans Verkuil]

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 

[PATCHv14 16/18] cec: s5p-cec: Add s5p-cec driver

[Hans Verkuil]

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 = < CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <_system_controller>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_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
+++ 

[PATCHv14 15/18] cobalt: add cec support

[Hans Verkuil]

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 = >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(>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 = >streams[i];
+   struct video_device *vdev = >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(_cec_adap_ops,
+s, s->vdev.name, caps, 1,
+>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 = _pdata,
};

-   struct cobalt_stream *s = cobalt->streams;
int i;

for (i = 0; i < COBALT_NUM_INPUTS; i++) {
+   struct cobalt_stream *s = cobalt->streams 

[PATCHv14 14/18] cec: adv7511: add cec support.

[Hans Verkuil]

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:
 

[PATCHv14 13/18] cec: adv7842: add cec support

[Hans Verkuil]

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, _loc);
+
+   /*
+* Return an error if no location of the source physical address
+* was found.
+*/
+   if (spa_loc == 0)
+   return -EINVAL;
+
/* edid segment pointer '0' 

[PATCHv14 12/18] cec: adv7604: add cec support.

[Hans Verkuil]

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, _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, _done);
+   return;
+   }
+   if (tx_raw_status & 0x01) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: ready ok\n", __func__);
+   

[PATCHv14 11/18] v4l2-subdev: add HDMI CEC ops

[Hans Verkuil]

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

[Hans Verkuil]

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
+++ 

[PATCHv14 09/18] cec.txt: add CEC framework documentation

[Hans Verkuil]

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 

[PATCHv14 08/18] cec: add compat32 ioctl support

[Hans Verkuil]

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

[Hans Verkuil]

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 

[PATCHv14 06/18] rc: Add HDMI CEC protocol handling

[Hans Verkuil]

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 

[PATCHv14 05/18] HID: add HDMI CEC specific keycodes

[Hans Verkuil]

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

[Hans Verkuil]

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

[Hans Verkuil]

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 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
-- 
2.7.0

[PATCHv14 02/18] dts: exynos4: add node for the HDMI CEC device

[Hans Verkuil]

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 = < CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <_system_controller>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_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

[Hans Verkuil]

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

[Hans Verkuil]

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 

[PATCH 5/5] drm/i915: Add support for new aspect ratios

[Shashank Sharma]

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

[Shashank Sharma]

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

[Shashank Sharma]

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

[Shashank Sharma]

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

[Shashank Sharma]

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

[Shashank Sharma]

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

[Borislav Petkov]

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

[Daniel Stone]

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

[Noralf Trønnes]

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(>dirty_lock);
 clip = *helper->dirty_clip;
 /* reset dirty_clip */
 

[PATCH v2] drm: rcar-du: Use ARCH_RENESAS

[Simon Horman]

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

[Alex Deucher]

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

[Rob Herring]

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

[Rob Herring]

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 = <_node>;
> + clock-names = "pxlclk";
> + encoder-slave = <_node>;

Still in the example...

Otherwise,

Acked-by: Rob Herring 

[PATCH v2] drm: rcar-du: Use ARCH_RENESAS

[Laurent Pinchart]

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.

[Rob Herring]

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 = <>;
> + interrupts = <99 IRQ_TYPE_LEVEL_LOW>;   /* INTP */
> + cable-det-gpios = < 36 GPIO_ACTIVE_HIGH>;
> + pd-gpios = < 33 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 98 GPIO_ACTIVE_HIGH>;
> + v10-gpios = < 35 GPIO_ACTIVE_HIGH>;
> + port {
> + anx7814_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> -- 
> 2.1.0
> 

[PATCH 1/1] drm: fsl-dcu: Use flat cache

[Stefan Agner]

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

[Rob Herring]

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

[Rob Herring]

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
> +

[RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

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"

[bugzilla-dae...@freedesktop.org]

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

[Inki Dae]

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"

[bugzilla-dae...@freedesktop.org]

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

[Rob Clark]

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"

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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"

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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"

[bugzilla-dae...@freedesktop.org]

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)

[bugzilla-dae...@freedesktop.org]

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"

[bugzilla-dae...@freedesktop.org]

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

[Dave Airlie]

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

[Laurent Pinchart]

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, , );
+   vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
+  fb->pitches[0], paddr, , ,
+  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;
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.base,
   rcdu->props.alpha, 255);
+   drm_object_attach_property(>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

[kbuild test robot]

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

[Sebastian Reichel]

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

[bugzilla-dae...@freedesktop.org]

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>

Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver

[Alexandre Demers]

As a follow up, I've been away for quite some time now (long overdue 
vacations), but I'm back home now. This will be my main project, so we 
may get something working if I'm lucky. I'll soon be posting a link to 
my repository where things will be worked on.

Cheers.

Alexandre Demers

On 2016-01-20 20:21, Alexandre Demers wrote:
> Thanks to all your feedback. Well, it seems achievable. I may ask some 
> questions here and there, but I think I'll give it a try.
>
> Alexandre Demers
>
> On 2016-01-19 07:58, Christian König wrote:
>>> I think Graham summed it up pretty well :)
>> Indeed, but there is a detail missing. The main problem for moving SI 
>> and CIK support from radeon to amdgpu is that we can't break existing 
>> userspace.
>>
>> Fortunately amdgpu wasn't designed from scratch, instead it's rather 
>> a evaluational successor of radeon. Because of that a lot of the 
>> internal interfaces are still the same.
>>
>> Additional to that I made the IOCTL numbers from Radeon and Amdgpu 
>> intentional disjoint. Amdgpu is using 0x00-0x12 and KMS on Radeon is 
>> using 0x1c-0x2d (we never supported UMS for SI/CIK).
>>
>> So in theory it would be possible that somebody implements a 
>> compatibility mode which provides the old Radeon IOCTLs for SI and 
>> CIK hardware generation in Amdgpu.
>>
>> This way we could support SI on Amdgpu as well and remove the support 
>> for SI and CIK from Radeon.
>>
>> The biggest differences are indeed in the multimedia area, e.g. UVD 
>> and VCE. But it's still mostly copying the Radeon code to Amdgpu (if 
>> somebody cares we could even move that into an independent module 
>> shared by both).
>>
>> Regards,
>> Christian.
>>
>> Am 18.01.2016 um 23:19 schrieb Deucher, Alexander:
 -Original Message-
 From: Sellers, Graham
 Sent: Monday, January 18, 2016 10:38 AM
 To: alexandre.f.demers at gmail.com; Deucher, Alexander
 Cc: dri-devel
 Subject: RE: Porting GCN pre-1.2 parts from radeon to amdgpu kernel 
 driver

 Hi Alexandre,

 Yes, your understanding is correct.

 Frankly, Alex or one of the other guys on the open source team 
 would be
 best positioned to answer your questions as to what would 
 specifically need
 to be done. However, yes, the gap we have here is in the amdgpu kernel
 driver. I pretty much only work on the user-mode side of things. Think
 "libVulkan.so" or "vulkan.dll" - the bit that applications link to. 
 We talk to our
 kernel drivers through standard interfaces. It's the kernel driver 
 that deals
 with a lot of the differences between different parts of hardware. 
 amdgpu is
 a ground-up redesign of our kernel solution for Linux. The 
 closed-source
 kernel driver that we were using in our Catalyst packages has been 
 put out to
 pasture. For the amdgpu project, given the number of engineers we 
 have,
 we have to make a tough decision between supporting interesting new
 features of new GPUs, or sticking with pretty basic support but 
 backporting
 to older GPUs.

 The differences in the graphics core itself between SI, CI and VI 
 are actually
 pretty minimal (as far as the kernel driver is concerned, anyway). 
 Where
 there are bigger differences are in things like the multimedia 
 (video) engines,
 display controller, power management and so on. The radeon KMD has 
 full
 support for all SI and CI (and earlier) "un-core" parts of the GPU. 
 amdgpu has
 VI product support and some minimal (albeit disabled) support for 
 CI, and
 basically nothing from SI.

 Our user-mode Vulkan driver (and closed source OpenGL driver, for that
 matter) can talk to the amdgpu kernel driver, but not to the radeon 
 kernel
 driver. The interfaces are quite different, and honestly, the 
 radeon kernel
 interface isn't a great fit for Vulkan. We had considered trying to 
 support
 radeon KMD in our Vulkan driver, but it doesn't seem practical. So, 
 it seems
 that the options would be really to port the non-core support from 
 radeon
 KMD into amdgpu, or somehow port the new KMD interfaces to radeon
 KMD, which would allow our Vulkan drivers to run on it, but seems 
 like a bit
 of a backwards step.

 There are other complications - such as it being frowned upon to 
 have two
 kernel drivers for the same piece of hardware, so you'd need to 
 port SI and
 CI stuff from radeon to amdgpu, and then somehow disable (or remove 
 it) in
 the radeon KMD such that there was still only one driver for the 
 GPU. It's
 non-trivial, but not insurmountable. Also, even though the code is 
 there and
 working in radeon KMD, there are enough differences in the 
 infrastructure
 that the ported support would need to be re-validated and all that 
 stuff.

 If