[PATCH] drm: bochs: Prevent double-free of fb helper

[Gabriel Krisman Bertazi]

If fbdev registration fails for whatever reason, the error path of
bochs_fbdev_init() will call bochs_fbdev_fini(), but since an fbdev
initialization error is not fatal to the probe function, a subsequent
device removal will try to call bochs_fbdev_fini() again, hitting the
Oops below.

This was detected by 0-day with a failing framebuffer registration and
CONFIG_DEBUG_TEST_DRIVER_REMOVE=y.  This reproduces the scenario I
mentioned above at insmod time, because the test attempts to remove the
device right after probing.

root@debian:~# insmod bochs-drm.ko
[   17.609635] [drm] Found bochs VGA, ID 0xb0c0.
[   17.612974] [drm] Framebuffer size 16384 kB @ 0xfa00, mmio @ 0xfebf2000.
[   17.613938] [TTM] Zone  kernel: Available graphics memory: 1022244 kiB
[   17.614701] [TTM] Initializing pool allocator
[   17.615427] [TTM] Initializing DMA pool allocator
[   17.619143] fbcon: bochsdrmfb (fb0) is primary device
[   17.619428] Console: switching to colour frame buffer device 128x48
[   17.621047] bochs-drm :00:02.0: fb0: bochsdrmfb frame buffer device
[   17.64] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:02.0 on 
minor 0
[   17.642380] general protection fault:  [#1] SMP
[   17.642985] Modules linked in: bochs_drm(+)
[   17.643259] CPU: 4 PID: 3279 Comm: insmod Tainted: GW   
4.11.0-rc1+ #119
[   17.643259] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   17.643259] task: 88007af35e00 task.stack: c9d84000
[   17.643259] RIP: 0010:drm_fb_helper_fini+0x8e/0x110
[   17.643259] RSP: 0018:c9d87ad0 EFLAGS: 00010202
[   17.643259] RAX: dead0200 RBX: 8800790d5770 RCX: 
[   17.652101] RDX: dead0100 RSI: 7fff RDI: 81eaf820
[   17.652101] RBP: c9d87ae0 R08:  R09: 88007271d918
[   17.652101] R10: c9d87a88 R11:  R12: 
[   17.652101] R13: 8800790d56d0 R14:  R15: 
[   17.652101] FS:  7f9285995700() GS:88007cf0() 
knlGS:
[   17.652101] CS:  0010 DS:  ES:  CR0: 80050033
[   17.652101] CR2: 564f1cf9f1e8 CR3: 79686000 CR4: 06e0
[   17.652101] Call Trace:
[   17.652101]  bochs_fbdev_fini+0x24/0x90 [bochs_drm]
[   17.652101]  bochs_unload+0x16/0x50 [bochs_drm]
[   17.652101]  drm_dev_unregister+0x37/0xd0
[   17.652101]  drm_put_dev+0x31/0x60
[   17.652101]  bochs_pci_remove+0x10/0x20 [bochs_drm]
[   17.652101]  pci_device_remove+0x34/0xb0
[   17.652101]  driver_probe_device+0xd0/0x370
[   17.652101]  __driver_attach+0x96/0xa0
[   17.652101]  ? driver_probe_device+0x370/0x370
[   17.652101]  bus_for_each_dev+0x5b/0x90
[   17.652101]  driver_attach+0x19/0x20
[   17.652101]  bus_add_driver+0x11c/0x220
[   17.652101]  driver_register+0x5b/0xd0
[   17.652101]  ? 0xa0006000
[   17.652101]  __pci_register_driver+0x47/0x50
[   17.652101]  drm_pci_init+0xe1/0xf0
[   17.652101]  ? 0xa0006000
[   17.652101]  bochs_init+0x3c/0x1000 [bochs_drm]
[   17.652101]  do_one_initcall+0x3e/0x180
[   17.652101]  ? kmem_cache_alloc_trace+0x33/0x150
[   17.652101]  do_init_module+0x5a/0x1eb
[   17.652101]  load_module+0x1ea0/0x2650
[   17.652101]  ? __symbol_put+0x40/0x40
[   17.652101]  ? kernel_read_file+0x19e/0x1c0
[   17.652101]  ? kernel_read_file_from_fd+0x44/0x70
[   17.652101]  SYSC_finit_module+0xba/0xc0
[   17.652101]  SyS_finit_module+0x9/0x10
[   17.652101]  entry_SYSCALL_64_fastpath+0x1a/0xa9
[   17.652101] RIP: 0033:0x7f92854da119
[   17.652101] RSP: 002b:7ffcd0390498 EFLAGS: 0246 ORIG_RAX: 
0139
[   17.652101] RAX: ffda RBX: 7f928578eb58 RCX: 7f92854da119
[   17.652101] RDX:  RSI: 564f1c8bd638 RDI: 0003
[   17.652101] RBP: 270e R08:  R09: 7f9285790ea0
[   17.652101] R10: 0003 R11: 0246 R12: 7f928578eb58
[   17.652101] R13: 1020 R14: 564f1cf9e1c0 R15: 7f928578eb00
[   17.652101] Code: c7 20 f8 ea 81 e8 b3 3e 50 00 48 8b 83 d0 00 00 00 48 8d 
93 d0 00 00 00 48 39 c2 74 46 48 8b 83 d8 00 00 00 48 8b 93 d0 00 00 00 <48> 89 
42 08 48 89 10 48 b8 00 01 00 00  ad de 48 89 83 d0
[   17.652101] RIP: drm_fb_helper_fini+0x8e/0x110 RSP: c9d87ad0
[   17.653331] ---[ end trace 542fd75a2e60a6a4 ]---

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/bochs/bochs_fbdev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 471bd588550b..c38deffa14de 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -192,6 +192,8 @@ void bochs_fbdev_fini(struct bochs_device *bochs)
if (bochs->fb.initialized)
bochs_fbdev_destroy(bochs);
 
-   drm_fb_helper_fini(&bochs->fb.help

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

[Zhenyu Wang]

On 2017.03.23 14:43:44 +0100, Frans Klaver wrote:
> On Thu, Mar 23, 2017 at 1:22 PM, Colin King  wrote:
> > From: Colin Ian King 
> >
> > info is being checked to see if it is a null pointer, however, vpgu is
> > dereferencing info before this check, leading to a potential null
> > pointer dereference.  If info is null, then the error message being
> > printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
> > use a null vpgu as the macro has a sanity check to see if vpgu is null,
> > so this is OK.
> >
> > Detected with CoverityScan, CID#1420672 ("Dereference nefore null check")
> 
> s,nefore,before,
> 
> 
> >
> > Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
> > Signed-off-by: Colin Ian King 
> > ---
> >  drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> > b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > index 1ea3eb270de8..f8619a772c44 100644
> > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > @@ -1339,9 +1339,9 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
> >
> >  static bool kvmgt_guest_exit(struct kvmgt_guest_info *info)
> >  {
> > -   struct intel_vgpu *vgpu = info->vgpu;
> > -
> > if (!info) {
> > +   struct intel_vgpu *vgpu = NULL;
> > +
> > gvt_vgpu_err("kvmgt_guest_info invalid\n");
> > return false;
> > }
> 
> Does this mean the original gvt_err() macro is no longer there?
> 
> And apparently gvt_vgpu_err is a macro that depends on the specifics
> of its environment? Yikes.
> 

The null check is redundant there, we can just remove that block and extra
vgpu variable.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Make the decision to keep vblank irq enabled earlier

[Mario Kleiner]

On 03/23/2017 02:26 PM, Ville Syrjälä wrote:

On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote:

We want to provide the vblank irq shadow for pageflip events as well as
vblank queries. Such events are completed within the vblank interrupt
handler, and so the current check for disabling the irq will disable it
from with the same interrupt as the last pageflip event. If we move the
decision on whether to disable the irq (based on there no being no
remaining vblank events, i.e. vblank->refcount == 0) to before we signal
the events, we will only disable the irq on the interrupt after the last
event was signaled. In the normal course of events, this will keep the
vblank irq enabled for the entire flip sequence whereas before it would
flip-flop around every interrupt.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Michel Dänzer 
Cc: Laurent Pinchart 
Cc: Dave Airlie ,
Cc: Mario Kleiner 
---
 drivers/gpu/drm/drm_irq.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 5b77057e91ca..1d6bcee3708f 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1741,6 +1741,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
 {
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
unsigned long irqflags;
+   bool disable_irq;

if (WARN_ON_ONCE(!dev->num_crtcs))
return false;
@@ -1768,16 +1769,19 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
spin_unlock(&dev->vblank_time_lock);

wake_up(&vblank->queue);
-   drm_handle_vblank_events(dev, pipe);

/* With instant-off, we defer disabling the interrupt until after
-* we finish processing the following vblank. The disable has to
-* be last (after drm_handle_vblank_events) so that the timestamp
-* is always accurate.
+* we finish processing the following vblank after all events have
+* been signaled. The disable has to be last (after
+* drm_handle_vblank_events) so that the timestamp is always accurate.


We wouldn't actually do the disable as long there's a reference still
held, so the timestamp should be fine in that case. And if there aren't
any references the timestamp shouldn't matter... I think. But it's
probably more clear to keep to the order you propose here anyway.

Reviewed-by: Ville Syrjälä 



Looks good to me. As a further optimization, i think we could move the 
vblank_disable_fn() call outside/below the spin_unlock_irqrestore for 
event_lock, as vblank_disable_fn() doesn't need any locks held at call 
time, so slightly reduce event_lock hold time. Don't know if it is worth it.


In any case

Reviewed-by: Mario Kleiner 

thanks,
-mario


Oh, and now that I think about this stuff again, I start to wonder why
I made the disable actually update the seq/ts. If the interrupt is
currently enabled the seq/ts should be reasonably uptodate already
when we do disable the interrupt. Perhaps I was only thinking about
drm_vblank_off() when I made that change, or I decided that I didn't
want two different disable codepaths. Anyways, just an idea that
we might be able to make the vblank irq disable a little cheaper.


 */
-   if (dev->vblank_disable_immediate &&
-   drm_vblank_offdelay > 0 &&
-   !atomic_read(&vblank->refcount))
+   disable_irq = (dev->vblank_disable_immediate &&
+  drm_vblank_offdelay > 0 &&
+  !atomic_read(&vblank->refcount));
+
+   drm_handle_vblank_events(dev, pipe);
+
+   if (disable_irq)
vblank_disable_fn((unsigned long)vblank);

spin_unlock_irqrestore(&dev->event_lock, irqflags);
--
2.11.0



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 3/8] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel

[Rob Herring]

On Wed, Mar 15, 2017 at 06:02:09PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre 
> ---
>  .../display/panel/ampire,am-480272h3tmqw-t01h.txt  | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes for 4.11-rc4.

[Dave Airlie]

Hi Linus,

This is the fixes pull request for rc4.

It contains one core drm/fbdev regression fix.
A set of i915 fixes including a few GVT related fixes, along with
some reset fixes.
One new PCI id for amdgpu, and some minor workaround regression fixes.
A set of exynos fixes, dropping support for an old unsupported SoC,
some vblank timing fixes, and an info leak fix.

Dave.

The following changes since commit 97da3854c526d3a6ee05c849c96e48d21527606c:

  Linux 4.11-rc3 (2017-03-19 19:09:39 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.11-rc4

for you to fetch changes up to d64a04720b0e64c1cd0726a3a27b360822fbee22:

  Merge branch 'drm-fixes-4.11' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-03-24
11:05:06 +1000)


i915, amd, exynos and one fbdev regression


Alex Deucher (2):
  drm/radeon: reinstate oland workaround for sclk
  drm/amdgpu: reinstate oland workaround for sclk

Ander Conselvan de Oliveira (1):
  drm/i915/glk: Remove MODULE_FIRMWARE() tag from Geminilake's DMC

Andrzej Hajda (6):
  drm/exynos: move crtc event handling to drivers callbacks
  drm/exynos/decon5433: fix vblank event handling
  drm/exynos/decon5433: signal frame done interrupt at front porch
  drm/exynos/fimd: signal frame done interrupt at front porch
  drm/exynos/decon5433: fix software trigger mask
  drm/exynos/dsi: make te-gpios optional

Changbin Du (2):
  drm/i915/kvmgt: fix suspicious rcu dereference usage
  drm/i915: make context status notifier head be per engine

Chris Wilson (7):
  drm/i915: Split GEM resetting into 3 phases
  drm/i915: Disable engine->irq_tasklet around resets
  drm/i915: Only enable hotplug interrupts if the display
interrupts are enabled
  drm/i915: Stop using RP_DOWN_EI on Baytrail
  drm/i915: Always call i915_gem_reset_finish() following
i915_gem_reset_prepare()
  drm/i915/gvt: Remove bogus retry around i915_wait_request
  drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)

Chuanxiao Dong (2):
  drm/i915/gvt: add enable_execlists check before enable gvt
  drm/i915/gvt: GVT pin/unpin shadow context

Dan Carpenter (1):
  drm/exynos/decon5433: & vs | typo

Dave Airlie (4):
  Merge tag 'drm-intel-fixes-2017-03-22' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'exynos-drm-fixes' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
  Merge tag 'drm-misc-fixes-2017-03-23' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge branch 'drm-fixes-4.11' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Evan Quan (1):
  drm/amd/amdgpu: add POLARIS12 PCI ID

Huang Rui (1):
  drm/amdgpu: fix the clearing wb size

Jani Nikula (1):
  Merge tag 'gvt-fixes-2017-03-17' of
https://github.com/01org/gvt-linux into drm-intel-fixes

Kenneth Graunke (1):
  drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

Krzysztof Kozlowski (2):
  drm/exynos: Remove support for Exynos4415 (SoC not supported anymore)
  drm/exynos: Print kernel pointers in a restricted form

Michel Dänzer (1):
  drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

Tina Zhang (2):
  drm/i915/gvt: replace the gvt_err with gvt_vgpu_err
  drm/i915/gvt: scan shadow indirect context image when valid

Ville Syrjälä (2):
  drm/i915: Reject HDMI 12bpc if the sink doesn't indicate support
  drm/i915: Do .init_clock_gating() earlier to avoid it clobbering
watermarks

Yulei Zhang (1):
  drm/i915/gvt: correct the ggtt valid bit check in pipe control command

Zhao Yan (1):
  drm/i915/gvt: handle force-nonpriv registers, cmd parser part

Zhenyu Wang (1):
  drm/i915/gvt: Fix gvt scheduler interval time

 .../bindings/display/exynos/exynos_dsim.txt|   1 -
 .../bindings/display/exynos/samsung-fimd.txt   |   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   1 +
 drivers/gpu/drm/amd/amdgpu/si_dpm.c|  10 +-
 drivers/gpu/drm/drm_fb_helper.c|   6 +-
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  |  87 +++-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c |   1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |  29 +++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   2 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  24 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c   |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  22 +
 drivers/gpu/drm/exynos/exynos_drm_gem.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c|  22 ++---
 drivers/gpu/drm

[Bug 86351] HDMI audio garbled output on Radeon R9 280X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=86351

--- Comment #26 from Christian Birchinger (jo...@netswarm.net) ---
Haven't used HDMI for almost a year now. The issue is still present and this
time changing prealloc fixes nothing. 2048 used to work, but now all values
i've tried from 64 to 4096 do nothing. The only thing that makes audio play
normal is CPU load.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings

[Chris Zhong]

The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and
connected to DSI using four lanes.

Signed-off-by: Chris Zhong 
Reviewed-by: Brian Norris 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../bindings/display/panel/innolux,p079zca.txt | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
new file mode 100644
index 000..5c70a83
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -0,0 +1,23 @@
+Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,p079zca"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   &mipi_dsi {
+   panel {
+   compatible = "innolux,p079zca";
+   reg = <0>;
+   power-supply = <...>;
+   backlight = <&backlight>;
+   enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+   };
+   };
-- 
2.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 2/2] drm/panel: add innolux,p079zca panel driver

[Chris Zhong]

Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
panel.

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
Tested-by: Brian Norris 
---

Changes in v4:
- remove backlight check after probe
- add bpc info

Changes in v3:
- printk err after regulator_disable(innolux->supply)

Changes in v2:
- add some error check
- always use Low power mode to send commend
- add comments for all the sleep
- use DRM_DEV_ERROR instead of dev_err

 drivers/gpu/drm/panel/Kconfig |  11 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 340 ++
 3 files changed, 352 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..99dd010 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_INNOLUX_P079ZCA
+   tristate "Innolux P079ZCA panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Innolux P079ZCA
+ TFT-LCD modules. The panel has a 1024x768 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
 config DRM_PANEL_JDI_LT070ME05000
tristate "JDI LT070ME05000 WUXGA DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..bda2aa4 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
new file mode 100644
index 000..6ba9344
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -0,0 +1,340 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * 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 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct innolux_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *link;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+   struct gpio_desc *enable_gpio;
+
+   bool prepared;
+   bool enabled;
+};
+
+static inline struct innolux_panel *to_innolux_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct innolux_panel, base);
+}
+
+static int innolux_panel_disable(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err;
+
+   if (!innolux->enabled)
+   return 0;
+
+   innolux->backlight->props.power = FB_BLANK_POWERDOWN;
+   backlight_update_status(innolux->backlight);
+
+   err = mipi_dsi_dcs_set_display_off(innolux->link);
+   if (err < 0)
+   DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
+ err);
+
+   innolux->enabled = false;
+
+   return 0;
+}
+
+static int innolux_panel_unprepare(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err;
+
+   if (!innolux->prepared)
+   return 0;
+
+   err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
+   if (err < 0) {
+   DRM_DEV_ERROR(panel->dev, "failed to enter sleep mode: %d\n",
+ err);
+   return err;
+   }
+
+   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+   /* T8: 80ms - 1000ms */
+   msleep(80);
+
+   err = regulator_disable(innolux->supply);
+   if (err < 0)
+   return err;
+
+   innolux->prepared = false;
+
+   return 0;
+}
+
+static int innolux_panel_prepare(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err, regulator_err;
+
+   if (innolux->prepared)
+   return 0;
+
+   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+   err = regulator_enable(innolux->supply);
+   if (err < 0)
+   return err;
+
+   /* T2: 15ms - 1000ms */
+   usleep_range(15000, 16000

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

[Stefan Agner]

On 2017-03-23 01:53, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> Otherwise this can also prevent modesets e.g. for switching VTs, when
> multiple monitors with different native resolutions are connected.

When changing resolution a regular fbdev driver also changes display
timing accordingly (fb_var_screeninfo contains timings as well). The
fbdev emulation layer does not change timing, so that was the idea why
my patch also rejected any kind of change to the resolution... In the
end it is really a definition of the semantics of that userspace API
(FBIOPUT_VSCREENINFO) and how true DRM emulates them...

Using less of the available framebuffer seems safe, especially since
line width is handled by pitch/line_length.

As far as I remember my case was a fbdev application which fiddled with
bpp/depth, which lead to a totally messed up outcome... So my use case
will still be fine with your change.

I am ok with relaxing that again, so from my side:
Acked-by: Stefan Agner 

--
Stefan


> 
> The depths must match though, so keep the != test for that.
> 
> Also update the DRM_DEBUG output to be slightly more accurate, this
> doesn't only affect requests from userspace.
> 
> Bugzilla: https://bugs.freedesktop.org/99841
> Fixes: 865afb11949e ("drm/fb-helper: reject any changes to the fbdev")
> Signed-off-by: Michel Dänzer 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index f6d4d9700734..324a688b3f30 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1260,9 +1260,9 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
> *var,
>* to KMS, hence fail if different settings are requested.
>*/
>   if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
> - var->xres != fb->width || var->yres != fb->height ||
> - var->xres_virtual != fb->width || var->yres_virtual != fb->height) {
> - DRM_DEBUG("fb userspace requested width/height/bpp different 
> than
> current fb "
> + var->xres > fb->width || var->yres > fb->height ||
> + var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
> + DRM_DEBUG("fb requested width/height/bpp can't fit in current 
> fb "
> "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
> var->xres, var->yres, var->bits_per_pixel,
> var->xres_virtual, var->yres_virtual,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Jose Abreu]

Hi Ville,


On 23-03-2017 18:14, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote:
>> Hi Ville,
>>
>>
>> On 23-03-2017 17:42, Ville Syrjälä wrote:
>>> On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
 Hi Shashank,


 On 23-03-2017 16:43, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 6:33 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 16:08, Sharma, Shashank wrote:
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 3/23/2017 5:57 PM, Jose Abreu wrote:
 Hi Ville,


 On 23-03-2017 15:45, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 15:14, Shashank Sharma wrote:
>>> HDMI 1.4b support the CEA video modes as per range of
>>> CEA-861-D (VIC 1-64).
>>> For any other mode, the VIC filed in AVI infoframes should
>>> be 0.
>>> HDMI 2.0 sinks, support video modes range as per CEA-861-F
>>> spec, which is
>>> extended to (VIC 1-107).
>>>
>>> This patch adds a bool input variable, which indicates if
>>> the connected
>>> sink is a HDMI 2.0 sink or not. This will make sure that we
>>> don't pass a
>>> HDMI 2.0 VIC to a HDMI 1.4 sink.
>>>
>>> This patch touches all drm drivers, who are callers of this
>>> function
>>> drm_hdmi_avi_infoframe_from_display_mode but to make sure
>>> there is
>>> no change in current behavior, is_hdmi2 is kept as false.
>>>
>>> In case of I915 driver, this patch checks the
>>> connector->display_info
>>> to check if the connected display is HDMI 2.0.
>>>
>>> Cc: Ville Syrjala 
>>> Cc: Jose Abreu 
>>> Cc: Andrzej Hajda 
>>> Cc: Alex Deucher 
>>> Cc: Daniel Vetter 
>>>
>>> PS: This patch touches a few lines in few files, which were
>>> already above 80 char, so checkpatch gives 80 char warning
>>> again.
>>> - gpu/drm/omapdrm/omap_encoder.c
>>> - gpu/drm/i915/intel_sdvo.c
>>>
>>> Signed-off-by: Shashank Sharma 
>>> ---
>>>drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>>>drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>>>drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>>>drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>>>drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>>>drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>>>drivers/gpu/drm/drm_edid.c| 12
>>> +++-
>>>drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>>>drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>>>drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>>>drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>>>drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>>>drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>>>drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>>>drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>>>drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>>>drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>>>drivers/gpu/drm/tegra/sor.c   |  2 +-
>>>drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>>>drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>>>include/drm/drm_edid.h|  3 ++-
>>>21 files changed, 38 insertions(+), 21 deletions(-)
>>>
>> [snip]
>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index af93f7a..5ff2886 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct
>>> dw_hdmi *hdmi, struct drm_display_mode *mode)
>>>u8 val;
>>>  /* Initialise info frame from DRM mode */
>>> -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
>>> +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode,
>>> false);
>>>  if (hdmi->hdmi_data.enc_out_format == YCBCR444)
>>>frame.colorspace = HDMI_COLORSPACE_YUV444;
>>>
>> dw-hdmi controller has full support for HDMI 2.0 features.
>> It all
>> depends on the platform it is integrated.
>>
>> I think adding a parameter to
>> drm_hdmi_avi_infoframe_from_display_mode is not the best idea
>> because of this case: A bridge can have su

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Colin Cross]

On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann  wrote:
> On 03/22/2017 02:48 PM, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
>>>
>>> Quoting Rob Clark (2017-03-22 10:07:54)

 I guess an interesting question (from someone who doesn't know meson
 yet) would be whether meson could slurp in the Makefile.sources type
 stuff that we have, which are shared so far between
 android/scons/autotools (and for the most part, kept developers from
 having to care *too* much about the different build systems)
>>>
>>>
>>> Jason and I have talked about that too. I'd suggested that we could write
>>> a
>>> module for meson to read makefile.sources (since we're surely not the
>>> only
>>> project that would benefit from such a module), except that android is
>>> moving to
>>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
>>> doesn't
>>> support using makefile.sources, so it seems somewhat moot in a world of
>>> blueprint for android, meson for *.
>>
>>
>> I guess even if it is only a temporary thing, something that could
>> slurp in Makefile.sources seems like it would be useful for a
>> transition period.
>>
>> I'm not totally up to speed on android/blueprint stuff.. but even some
>> simplified or different "here-are-my-sources" type file that could be
>> shared across build systems would be useful.  Meson sounds a bit more
>> extensible so maybe there is some potential to adapt to whatever
>> android forces on us ;-)
>
>
> +ccross from the Android build team can hopefully provide some input here.

For cases like this, we generally add a python script that translates
the build files into something Blueprint understands, and rerun it
each time we import into the project.

Alternatively, Blueprint efficiently supports globbing for sources, so
if all the source files are always listed in Makefile.sources (which
seems to be true in our copy of libdrm except for intel/test_decode.c)
then we could use globs and ignore the makefiles, possibly manually
excluding a few files.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

[Jose Abreu]

Hi Ville,


On 23-03-2017 19:00, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 06:54:52PM +, Jose Abreu wrote:
>> Hi Ville,
>>
>>
>> On 23-03-2017 15:16, Ville Syrjälä wrote:
>>> On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote:
 Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
 flag which will signal userspace that this is a HDMI 2.0+ mode. It
 is expected that these new flags will not be exported to userspace
 unless client asks to.
>>> W.r.t. the aspect ratio userspace story, there was some discussion
>>> on #dri-devel recently about extending the xrandr protocol for 3d stereo
>>> support. If that is going to happen then it might make sense to try
>>> and get the aspect ratio stuff also included at the same time so
>>> that we would only have to deal with one protocol bump.
>> Hmm, are you saying to just use one knob for 3d and the aspect
>> ratios?
> No. I'm saying that extending xrandr with either means a protocol bump.
> But if we do both at the same time we just need one bump.

Ok. Anything in this series that you think can start helping
contribute for that?

Best regards,
Jose Miguel Abreu

>
>> Aren't there already userspace consumers of the 3d knob?
> Not that I know of. And there's definitely nothing in xrandr for this
> stuff, so any consumer would have to be something non-x11 based.
>
>> Best regards,
>> Jose Miguel Abreu
>>
 Signed-off-by: Jose Abreu 
 Cc: Carlos Palminha 
 Cc: dri-devel@lists.freedesktop.org
 ---
  include/uapi/drm/drm_mode.h | 9 +
  1 file changed, 9 insertions(+)

 diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
 index 8c67fc0..62e679c 100644
 --- a/include/uapi/drm/drm_mode.h
 +++ b/include/uapi/drm/drm_mode.h
 @@ -89,6 +89,8 @@
  #define DRM_MODE_PICTURE_ASPECT_NONE  0
  #define DRM_MODE_PICTURE_ASPECT_4_3   1
  #define DRM_MODE_PICTURE_ASPECT_16_9  2
 +#define DRM_MODE_PICTURE_ASPECT_64_27 3
 +#define DRM_MODE_PICTURE_ASPECT_256_135   4
  
  /* Aspect ratio flag bitmask (4 bits 22:19) */
  #define DRM_MODE_FLAG_PIC_AR_MASK (0x0F<<19)
 @@ -98,6 +100,13 @@
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
  #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
 +#define  DRM_MODE_FLAG_PIC_AR_64_27 \
 +  (DRM_MODE_PICTURE_ASPECT_64_27<<19)
 +#define  DRM_MODE_FLAG_PIC_AR_256_135 \
 +  (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 +
 +/* HDMI 2.0+ mode flag: will only be set if client supports it */
 +#define DRM_MODE_FLAG_HDMI2   (1<<23)
  
  /* DPMS flags */
  /* bit compatible with the xorg definitions. */
 -- 
 1.9.1


 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIDAw&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=BBAO8Rra0sW4KcCLB5lMOfONxg0v9pfUSaDNr5WDh2w&s=p6tAeWYwiSDL7BonKeijv2zmweBF9eW7xV7OX5e5gG4&e=
  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: omapdrm: Fix oops on rmmod

[Tony Lindgren]

Looks like in Linux next we can now get an oops when unloading omapdrm:

Unable to handle kernel NULL pointer dereference at virtual address

...
LR is at omap_drm_irq_uninstall+0xb0/0xe0 [omapdrm]
...
[] (omap_drm_irq_uninstall [omapdrm]) from []
(pdev_remove+0x50/0x88 [omapdrm])
[] (pdev_remove [omapdrm]) from []
(platform_drv_remove+0x24/0x3c)
[] (platform_drv_remove) from []
(device_release_driver_internal+0x160/0x1f4)
[] (device_release_driver_internal) from []
(driver_detach+0x38/0x6c)
[] (driver_detach) from []
(bus_remove_driver+0x4c/0xa0)
[] (bus_remove_driver) from []
(platform_unregister_drivers+0x24/0x30)
[] (platform_unregister_drivers) from []
(SyS_delete_module+0x150/0x218)
[] (SyS_delete_module) from []
(ret_fast_syscall+0x0/0x1c)

Fix the issue by checking get_vblank_counter() before trying to
call it.

Signed-off-by: Tony Lindgren 
---
 drivers/gpu/drm/omapdrm/omap_irq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -303,8 +303,9 @@ void omap_drm_irq_uninstall(struct drm_device *dev)
for (i = 0; i < dev->num_crtcs; i++) {
wake_up(&dev->vblank[i].queue);
dev->vblank[i].enabled = false;
-   dev->vblank[i].last =
-   dev->driver->get_vblank_counter(dev, i);
+   if (dev->driver->get_vblank_counter)
+   dev->vblank[i].last =
+   dev->driver->get_vblank_counter(dev, i);
}
spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
}
-- 
2.11.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

[Jose Abreu]

Hi Andrzej,


On 23-03-2017 11:17, Andrzej Hajda wrote:
> On 23.03.2017 12:04, Jose Abreu wrote:
>> Hi Andrzej,
>>
>>
>> Thanks for the feedback!
>>
>> On 23-03-2017 08:11, Andrzej Hajda wrote:
>>> On 22.03.2017 18:35, Jose Abreu wrote:
 This patch completes CEA table of video modes so that VIC 1-107
 are now available. Use the HDMI 2.0+ flag to signal these are
 modes for HDMI 2.0 onwards.
>>> edid_cea_modes array is used in different contexts, simple extensions of
>>> the array with modes not present in HDMI < 2.0 can result in different
>>> behavior of drivers.
>>> There should be put sentinels somewhere to limit table lookup to old
>>> VICs if device/driver/receiver is not HDMI2.0 compliant.
>>> The only situation I am aware of at the moment is infoframe generation
>>> code. For TVs not supporting 4K modes but not HDMI 2.0 compatible, VIC
>>> field in AVI infoframe should be 0 for 4K modes and vendor infoframe
>>> should be generated with proper HDMI-VIC. With current infoframe helpers
>>> and this patch it will not work this way.
>> But this is what I do in patch 5/5 (see
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9640205_&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=c7Qf9lk2pdXRbmjFNPSsZsy7LKiZWrqGlE72r-OTA-M&s=37RkfhQjJpjdKmQniKnhZwb1vtwb6HXSxY2Y7HrNlp4&e=
>>  ), unless drivers ask
>> to I don't expose the new modes.
> I do not see how it is related to infoframe generation. Look at body of
> drm_hdmi_avi_infoframe_from_display_mode, it calls drm_match_cea_mode,
> which looks for given mode in edid_cea_modes array.

Yes but drm_hdmi_avi_infoframe_from_display_mode is called from
driver context, so the mode bust be previously probed by the drm
core, and it isn't if the hdmi2_allowed flag is not set so the
mode will never reach the driver and the infoframe will never be
built. And also if the receiver is not HDMI 2.0 compliant then
the mode will not also be probed.

But I see a flaw here: If the user specify manually the mode then
it will be passed to driver which will try to match with CEA
table. Is this the scenario you were thinking about? I think with
the new DRM_MODE_FLAG_HDMI2 flag this will not happen, see this:

- Modesetting X driver (for example) does not set HDMI 2 cap
- As the flag is not set HDMI 2 modes will not be exposed to
userspace
- If the user specifies the mode the modesetting driver will
not set HDMI 2 flag
- As the flag is not set then
drm_mode_equal_no_clocks_no_stereo will not match the mode

Of course this needs patches to modesetting X driver, which are
not in this series. What do you think?

> Anyway if there is or will be a patch which deals with it, it should be
> applied before extending edid_cea_modes array, not after.

Right, I will correct this :)

Best regards,
Jose Miguel Abreu

>
>
> Regards
> Andrzej
>
>> Best regards,
>> Jose Miguel Abreu
>>
>>> Regards
>>> Andrzej
 Signed-off-by: Jose Abreu 
 Cc: Carlos Palminha 
 Cc: dri-devel@lists.freedesktop.org
 ---
  drivers/gpu/drm/drm_edid.c | 258 
 +
  1 file changed, 258 insertions(+)

 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index fad3d44..90080368 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -1001,6 +1001,264 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
 +  /* 65 - 1280x720@24Hz */
 +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
 + 3080, 3300, 0, 720, 725, 730, 750, 0,
 + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + DRM_MODE_FLAG_HDMI2),
 +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
 +  /* 66 - 1280x720@25Hz */
 +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
 + 3740, 3960, 0, 720, 725, 730, 750, 0,
 + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + DRM_MODE_FLAG_HDMI2),
 +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
 +  /* 67 - 1280x720@30Hz */
 +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
 + 3080, 3300, 0, 720, 725, 730, 750, 0,
 + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + DRM_MODE_FLAG_HDMI2),
 +.vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
 +  /* 68 - 1280x720@50Hz */
 +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
 + 1760, 1980, 0, 720, 725, 730, 750, 0,
 + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + DRM_MODE_FLAG_HDMI2),
 +.vrefresh = 50, .picture_aspect

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

[Russell King - ARM Linux]

On Thu, Mar 23, 2017 at 10:54:53PM +0100, Linus Walleij wrote:
> Hm, I certainly want it... but it would be unreasonable of me to expect
> Eric to cold-code a big upfront design for systems he can't even test
> this on.
> 
> What I would request would rather be: please do not put in any
> immediate roadblocks and keep it in the back of your head that I will
> maybe come in and add support for the PL110 systems once this
> works. (Of course that would be with the aim to deprecate and
> delete the old fbdev driver in favor of this one.)

I'm only suggesting that it doesn't match the PL110 hardware as long as
it doesn't support the PL110...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 5/5] drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked to

[Jose Abreu]

Hi Daniel,


Thanks for the feedback!


On 23-03-2017 07:25, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 05:36:01PM +, Jose Abreu wrote:
>> Perform sanity checks so that HDMI 2.0+ modes are not exported to
>> drivers or userspace unless asked to.
> Why? They're just normal modes, this doesn't make sense. If you want to
> filter the aspect ratio stuff, that makes sense, but exposing the modes
> with default aspect ratio by default should be doable.

Yes my initial intention was to hide the new aspect ratio modes
from drivers so that only HDMI 1.4 modes will be available to non
HDMI 2.0+ drivers. I think that we should avoid exposing these
new modes to drivers. They have higher pixel clock values and
sometimes EDID can declare that some modes should use a specific
colorspace (YCbCr 4:2:0), but this is another story.

My argument is not very strong though: Pixel clock must always be
checked by drivers and rejected if not supported as well as
aspect ratio flags. Do you know of any driver that does not do this?

>
> I'm also not sure how exactly this is supposed to interact with the
> partially reverted aspect ratio filtering from Shashank. I guess what you
> really want is the feature flag for exposing aspect ratio, and then filter
> accordingly.

So you propose to change this validation to only check for aspect
ratio flags? Shouldn't we play it safe and allow this flag so
that if anything besides aspect ratio arises we can safely
prevent drivers from getting the mode?

Notice that this flag is not for HDMI 2.0 modes only, it is for
HDMI 2.0+. I'm thinking about HDMI 2.1 which will include new
video modes and possible even new flags.

Best regards,
Jose Miguel Abreu

> -Daniel
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/drm_connector.c|  2 ++
>>  drivers/gpu/drm/drm_probe_helper.c |  9 -
>>  include/drm/drm_modes.h| 14 ++
>>  3 files changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c 
>> b/drivers/gpu/drm/drm_connector.c
>> index 9f84761..430bb2b 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1200,6 +1200,8 @@ static bool drm_mode_expose_to_userspace(const struct 
>> drm_display_mode *mode,
>>   */
>>  if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
>>  return false;
>> +if (!file_priv->hdmi2_allowed && drm_mode_is_hdmi2(mode))
>> +return false;
>>  
>>  return true;
>>  }
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>> b/drivers/gpu/drm/drm_probe_helper.c
>> index 85005d5..ddacb5d 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -77,6 +77,10 @@
>>  !(flags & DRM_MODE_FLAG_3D_MASK))
>>  return MODE_NO_STEREO;
>>  
>> +if ((mode->flags & DRM_MODE_FLAG_HDMI2) &&
>> +!(flags & DRM_MODE_FLAG_HDMI2))
>> +return MODE_NO_HDMI2;
>> +
>>  return MODE_OK;
>>  }
>>  
>> @@ -221,7 +225,8 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
>>   *- drm_mode_validate_size() filters out modes larger than @maxX and 
>> @maxY
>>   *  (if specified)
>>   *- drm_mode_validate_flag() checks the modes against basic connector
>> - *  capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
>> + *  capabilities (interlace_allowed,doublescan_allowed,stereo_allowed,
>> + *  hdmi2_allowed)
>>   *- the optional &drm_connector_helper_funcs.mode_valid helper can 
>> perform
>>   *  driver and/or hardware specific checks
>>   *
>> @@ -336,6 +341,8 @@ int drm_helper_probe_single_connector_modes(struct 
>> drm_connector *connector,
>>  mode_flags |= DRM_MODE_FLAG_DBLSCAN;
>>  if (connector->stereo_allowed)
>>  mode_flags |= DRM_MODE_FLAG_3D_MASK;
>> +if (connector->hdmi2_allowed)
>> +mode_flags |= DRM_MODE_FLAG_HDMI2;
>>  
>>  list_for_each_entry(mode, &connector->modes, head) {
>>  if (mode->status == MODE_OK)
>> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
>> index 6dd34280..83466ff 100644
>> --- a/include/drm/drm_modes.h
>> +++ b/include/drm/drm_modes.h
>> @@ -80,6 +80,7 @@
>>   * @MODE_ONE_SIZE: only one resolution is supported
>>   * @MODE_NO_REDUCED: monitor doesn't accept reduced blanking
>>   * @MODE_NO_STEREO: stereo modes not supported
>> + * @MODE_NO_HDMI2: HDMI 2.0+ modes not supported
>>   * @MODE_STALE: mode has become stale
>>   * @MODE_BAD: unspecified reason
>>   * @MODE_ERROR: error condition
>> @@ -124,6 +125,7 @@ enum drm_mode_status {
>>  MODE_ONE_SIZE,
>>  MODE_NO_REDUCED,
>>  MODE_NO_STEREO,
>> +MODE_NO_HDMI2,
>>  MODE_STALE = -3,
>>  MODE_BAD = -2,
>>  MODE_ERROR = -1
>> @@ -422,6 +424,18 @@ static inline bool drm_mode_is_stereo(const struct 
>> drm_display_mode *mode)
>>  return mode->flags & DRM_MODE

[lkp-robot] [drm] f04f7e3e04: general_protection_fault:#[##]

[kernel test robot]

FYI, we noticed the following commit:

commit: f04f7e3e041aab12abbf3ed7b854446af5a624a9 ("drm: bochs: Don't remove 
uninitialized fbdev framebuffer")
url: 
https://github.com/0day-ci/linux/commits/Gabriel-Krisman-Bertazi/drm-bochs-Don-t-remove-uninitialized-fbdev-framebuffer/20170318-164722
base: git://git.kraxel.org/linux drm-qemu

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   | 
cbf87d6a8b | f04f7e3e04 |
+---+++
| boot_successes| 0 
 | 0  |
| boot_failures | 6 
 | 8  |
| WARNING:at_drivers/gpu/drm/drm_mode_config.c:#drm_mode_config_cleanup | 6 
 ||
| kernel_BUG_at_mm/slab.c   | 6 
 ||
| invalid_opcode:#[##]  | 6 
 ||
| Kernel_panic-not_syncing:Fatal_exception  | 6 
 | 8  |
| general_protection_fault:#[##]| 0 
 | 8  |
+---+++



[9.931866] [TTM] Zone  kernel: Available graphics memory: 219250 kiB
[9.932295] [TTM] Initializing pool allocator
[9.932599] [TTM] Initializing DMA pool allocator
[9.937917] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this 
framebuffer
[9.938724] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:02.0 on 
minor 1
[9.939428] general protection fault:  [#1] SMP
[9.939813] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.10.0-rc8-01399-gf04f7e3 #1
[9.940310] task: 88001e468040 task.stack: 88001e46c000
[9.940708] RIP: 0010:drm_fb_helper_crtc_free+0x26/0xa0
[9.941060] RSP: 0018:88001e46fc28 EFLAGS: 00010202
[9.941411] RAX: 6b6b6b6b6b6b6b6b RBX: 0001 RCX: 88001e468ba0
[9.941886] RDX: 0001 RSI: 88001e468b68 RDI: 88001a7ca058
[9.942352] RBP: 88001e46fc48 R08: 78532a4d R09: ae27c820
[9.942820] R10:  R11: f5cb56dd R12: 88001a7ca058
[9.943284] R13:  R14:  R15: 
[9.943759] FS:  () GS:88001f80() 
knlGS:
[9.944547] CS:  0010 DS:  ES:  CR0: 80050033
[9.944968] CR2: 7fb16c28b820 CR3: 02e11000 CR4: 06f0
[9.945441] DR0:  DR1:  DR2: 
[9.945911] DR3:  DR6: fffe0ff0 DR7: 0400
[9.946376] Call Trace:
[9.946547]  drm_fb_helper_fini+0xc6/0x110
[9.946822]  bochs_fbdev_fini+0x24/0x90
[9.947076]  bochs_unload+0x16/0x50
[9.947309]  drm_dev_unregister+0x37/0xd0
[9.947577]  drm_put_dev+0x2f/0x60
[9.947962]  bochs_pci_remove+0x10/0x20
[9.948475]  pci_device_remove+0x34/0xb0
[9.948978]  driver_probe_device+0xd3/0x390
[9.949486]  __driver_attach+0x92/0xa0
[9.949969]  ? driver_probe_device+0x390/0x390
[9.950525]  bus_for_each_dev+0x61/0xa0
[9.951005]  driver_attach+0x19/0x20
[9.951426]  bus_add_driver+0x1a2/0x220
[9.951692]  driver_register+0x5b/0xe0
[9.951970]  __pci_register_driver+0x5b/0x60
[9.952253]  ? qxl_init+0x33/0x33
[9.952472]  drm_pci_init+0xe3/0xf0
[9.952710]  ? idr_init+0x46/0x50
[9.952929]  ? qxl_init+0x33/0x33
[9.953148]  bochs_init+0x25/0x27
[9.953368]  do_one_initcall+0x90/0x14f
[9.953625]  kernel_init_freeable+0x1a0/0x22c
[9.953911]  ? rest_init+0xc0/0xc0
[9.954136]  kernel_init+0x9/0x100
[9.954361]  ret_from_fork+0x2c/0x40
[9.954606] Code: 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 54 53 31 db 8b 
57 20 49 89 fc 85 d2 7e 30 49 8b 44 24 28 4c 63 eb 83 c3 01 4a 8b 04 e8 <48> 8b 
38 48 83 c7 28 e8 8e 0d 02 00 49 8b 44 24 28 4a 8b 3c e8 
[9.955849] RIP: drm_fb_helper_crtc_free+0x26/0xa0 RSP: 88001e46fc28
[9.956296] ---[ end trace e4589f787553d11e ]---
[9.956618] Kernel panic - not syncing: Fatal exception
[9.956979] Kernel Offset: disabled

Elapsed time: 10

initrds=(


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaol

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

[Frans Klaver]

On Thu, Mar 23, 2017 at 1:22 PM, Colin King  wrote:
> From: Colin Ian King 
>
> info is being checked to see if it is a null pointer, however, vpgu is
> dereferencing info before this check, leading to a potential null
> pointer dereference.  If info is null, then the error message being
> printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
> use a null vpgu as the macro has a sanity check to see if vpgu is null,
> so this is OK.
>
> Detected with CoverityScan, CID#1420672 ("Dereference nefore null check")

s,nefore,before,


>
> Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 1ea3eb270de8..f8619a772c44 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1339,9 +1339,9 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
>
>  static bool kvmgt_guest_exit(struct kvmgt_guest_info *info)
>  {
> -   struct intel_vgpu *vgpu = info->vgpu;
> -
> if (!info) {
> +   struct intel_vgpu *vgpu = NULL;
> +
> gvt_vgpu_err("kvmgt_guest_info invalid\n");
> return false;
> }

Does this mean the original gvt_err() macro is no longer there?

And apparently gvt_vgpu_err is a macro that depends on the specifics
of its environment? Yikes.

Cheers,
Frans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

[Jose Abreu]

Hi Ville,


On 23-03-2017 15:16, Ville Syrjälä wrote:
> On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote:
>> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
>> flag which will signal userspace that this is a HDMI 2.0+ mode. It
>> is expected that these new flags will not be exported to userspace
>> unless client asks to.
> W.r.t. the aspect ratio userspace story, there was some discussion
> on #dri-devel recently about extending the xrandr protocol for 3d stereo
> support. If that is going to happen then it might make sense to try
> and get the aspect ratio stuff also included at the same time so
> that we would only have to deal with one protocol bump.

Hmm, are you saying to just use one knob for 3d and the aspect
ratios? Aren't there already userspace consumers of the 3d knob?

Best regards,
Jose Miguel Abreu

>
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>>  include/uapi/drm/drm_mode.h | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index 8c67fc0..62e679c 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -89,6 +89,8 @@
>>  #define DRM_MODE_PICTURE_ASPECT_NONE0
>>  #define DRM_MODE_PICTURE_ASPECT_4_3 1
>>  #define DRM_MODE_PICTURE_ASPECT_16_92
>> +#define DRM_MODE_PICTURE_ASPECT_64_27   3
>> +#define DRM_MODE_PICTURE_ASPECT_256_135 4
>>  
>>  /* Aspect ratio flag bitmask (4 bits 22:19) */
>>  #define DRM_MODE_FLAG_PIC_AR_MASK   (0x0F<<19)
>> @@ -98,6 +100,13 @@
>>  (DRM_MODE_PICTURE_ASPECT_4_3<<19)
>>  #define  DRM_MODE_FLAG_PIC_AR_16_9 \
>>  (DRM_MODE_PICTURE_ASPECT_16_9<<19)
>> +#define  DRM_MODE_FLAG_PIC_AR_64_27 \
>> +(DRM_MODE_PICTURE_ASPECT_64_27<<19)
>> +#define  DRM_MODE_FLAG_PIC_AR_256_135 \
>> +(DRM_MODE_PICTURE_ASPECT_256_135<<19)
>> +
>> +/* HDMI 2.0+ mode flag: will only be set if client supports it */
>> +#define DRM_MODE_FLAG_HDMI2 (1<<23)
>>  
>>  /* DPMS flags */
>>  /* bit compatible with the xorg definitions. */
>> -- 
>> 1.9.1
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIDAw&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=BBAO8Rra0sW4KcCLB5lMOfONxg0v9pfUSaDNr5WDh2w&s=p6tAeWYwiSDL7BonKeijv2zmweBF9eW7xV7OX5e5gG4&e=
>>  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Jose Abreu]

Hi Shashank,


On 23-03-2017 16:08, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 5:57 PM, Jose Abreu wrote:
>> Hi Ville,
>>
>>
>> On 23-03-2017 15:45, Ville Syrjälä wrote:
>>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
 Hi Shashank,


 On 23-03-2017 15:14, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of
> CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should
> be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F
> spec, which is
> extended to (VIC 1-107).
>
> This patch adds a bool input variable, which indicates if
> the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we
> don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.
>
> This patch touches all drm drivers, who are callers of this
> function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure
> there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch checks the
> connector->display_info
> to check if the connected display is HDMI 2.0.
>
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning
> again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> Signed-off-by: Shashank Sharma 
> ---
>   drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>   drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>   drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>   drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>   drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>   drivers/gpu/drm/drm_edid.c| 12 +++-
>   drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>   drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>   drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>   drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>   drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>   drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>   drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>   drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>   drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>   drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>   drivers/gpu/drm/tegra/sor.c   |  2 +-
>   drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>   drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>   include/drm/drm_edid.h|  3 ++-
>   21 files changed, 38 insertions(+), 21 deletions(-)
>
 [snip]

> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index af93f7a..5ff2886 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct
> dw_hdmi *hdmi, struct drm_display_mode *mode)
>   u8 val;
> /* Initialise info frame from DRM mode */
> -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode,
> false);
> if (hdmi->hdmi_data.enc_out_format == YCBCR444)
>   frame.colorspace = HDMI_COLORSPACE_YUV444;
>
 dw-hdmi controller has full support for HDMI 2.0 features.
 It all
 depends on the platform it is integrated.

 I think adding a parameter to
 drm_hdmi_avi_infoframe_from_display_mode is not the best idea
 because of this case: A bridge can have support for HDMI 2.0
 features but the platform may limit this support. I guess it
 can
 happen in other drivers too.
>>> Your driver is in full control of what gets passed here. So I
>>> don't see
>>> why that would be a problem.
>>>
>>> Also this doesn't really have anything to do with the
>>> capabilities of
>>> the source. All we want to make sure is that we don't send a
>>> VIC the
>>> sink will not understand.
>>>
>> But the driver is not aware of the platform limitations, its
>> generic to the controller only. We could add a field in pdata
>> which tells if platform is HDMI 2.0+ but what about other bridge
>> drivers or HDMI drivers? They will have to replicate the same
>> thing also.
>>
>> Best regards,
>> Jose Miguel Abreu
> I think the driver would be aware of the platform's
> capabilities, isn't it ?
> Else how would it even decide which mode to allow, and which to
> reject ?

The DRM core propagates the mode to the chain of configuration
before reaching the bridge driver also, there is a callback
supplied by pdata (mode_valid) which can chec

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Jose Abreu]

Hi Ville,


On 23-03-2017 15:36, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
>> For any other mode, the VIC filed in AVI infoframes should be 0.
>> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
>> extended to (VIC 1-107).
>>
>> This patch adds a bool input variable, which indicates if the connected
>> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
>> HDMI 2.0 VIC to a HDMI 1.4 sink.
> The spec is unfortunately vague when it comes to the CEA-861-F VIC
> transmission when there is a corresponding HDMI VIC for the same mode.
> I'm not sure if it's telling us to set both or just one depending on
> whether we're transmitting 3D video or not. Or at least I can't parse
> that information from the spec. Anyone have a better crystal ball
> in their possession?
>

I've been working in HDMI receivers and this is what I've got in
a comment:

1282
/*  
 

1283  * Update current VIC: When transmitting any
extended video format   
1284  * indicated through use of the HDMI_VIC field in
the HDMI Vendor
1285  * Specific InfoFrame or any other format which is
not described in  
1286  * the above cases, an HDMI Source shall set the AVI
InfoFrame VIC   
1287  * field to
zero.   
 

1288  */

This was directly taken from the spec, can't remember exactly
were though.

So, the VIC in AVIIF must be set to 0 and the HDMI_VIC field in
VSIF shall be set to the HDMI 4k VIC.

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Jose Abreu]

Hi Shashank,


On 23-03-2017 15:14, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
>
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.
>
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch checks the connector->display_info
> to check if the connected display is HDMI 2.0.
>
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>  drivers/gpu/drm/drm_edid.c| 12 +++-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>  drivers/gpu/drm/tegra/sor.c   |  2 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>  include/drm/drm_edid.h|  3 ++-
>  21 files changed, 38 insertions(+), 21 deletions(-)
>

[snip]

> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index af93f7a..5ff2886 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, 
> struct drm_display_mode *mode)
>   u8 val;
>  
>   /* Initialise info frame from DRM mode */
> - drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>  
>   if (hdmi->hdmi_data.enc_out_format == YCBCR444)
>   frame.colorspace = HDMI_COLORSPACE_YUV444;
>

dw-hdmi controller has full support for HDMI 2.0 features. It all
depends on the platform it is integrated.

I think adding a parameter to
drm_hdmi_avi_infoframe_from_display_mode is not the best idea
because of this case: A bridge can have support for HDMI 2.0
features but the platform may limit this support. I guess it can
happen in other drivers too.

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Jose Abreu]

Hi Ville,


On 23-03-2017 15:45, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 15:14, Shashank Sharma wrote:
>>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
>>> For any other mode, the VIC filed in AVI infoframes should be 0.
>>> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
>>> extended to (VIC 1-107).
>>>
>>> This patch adds a bool input variable, which indicates if the connected
>>> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
>>> HDMI 2.0 VIC to a HDMI 1.4 sink.
>>>
>>> This patch touches all drm drivers, who are callers of this function
>>> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
>>> no change in current behavior, is_hdmi2 is kept as false.
>>>
>>> In case of I915 driver, this patch checks the connector->display_info
>>> to check if the connected display is HDMI 2.0.
>>>
>>> Cc: Ville Syrjala 
>>> Cc: Jose Abreu 
>>> Cc: Andrzej Hajda 
>>> Cc: Alex Deucher 
>>> Cc: Daniel Vetter 
>>>
>>> PS: This patch touches a few lines in few files, which were
>>> already above 80 char, so checkpatch gives 80 char warning again.
>>> - gpu/drm/omapdrm/omap_encoder.c
>>> - gpu/drm/i915/intel_sdvo.c
>>>
>>> Signed-off-by: Shashank Sharma 
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>>>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>>>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>>>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>>>  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>>>  drivers/gpu/drm/drm_edid.c| 12 +++-
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>>>  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>>>  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>>>  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>>>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>>>  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>>>  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>>>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>>>  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>>>  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>>>  drivers/gpu/drm/tegra/sor.c   |  2 +-
>>>  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>>>  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>>>  include/drm/drm_edid.h|  3 ++-
>>>  21 files changed, 38 insertions(+), 21 deletions(-)
>>>
>> [snip]
>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index af93f7a..5ff2886 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, 
>>> struct drm_display_mode *mode)
>>> u8 val;
>>>  
>>> /* Initialise info frame from DRM mode */
>>> -   drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
>>> +   drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>>>  
>>> if (hdmi->hdmi_data.enc_out_format == YCBCR444)
>>> frame.colorspace = HDMI_COLORSPACE_YUV444;
>>>
>> dw-hdmi controller has full support for HDMI 2.0 features. It all
>> depends on the platform it is integrated.
>>
>> I think adding a parameter to
>> drm_hdmi_avi_infoframe_from_display_mode is not the best idea
>> because of this case: A bridge can have support for HDMI 2.0
>> features but the platform may limit this support. I guess it can
>> happen in other drivers too.
> Your driver is in full control of what gets passed here. So I don't see
> why that would be a problem.
>
> Also this doesn't really have anything to do with the capabilities of
> the source. All we want to make sure is that we don't send a VIC the
> sink will not understand.
>

But the driver is not aware of the platform limitations, its
generic to the controller only. We could add a field in pdata
which tells if platform is HDMI 2.0+ but what about other bridge
drivers or HDMI drivers? They will have to replicate the same
thing also.

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Jose Abreu]

Hi Shashank,


On 23-03-2017 16:43, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 6:33 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 16:08, Sharma, Shashank wrote:
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 3/23/2017 5:57 PM, Jose Abreu wrote:
 Hi Ville,


 On 23-03-2017 15:45, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 15:14, Shashank Sharma wrote:
>>> HDMI 1.4b support the CEA video modes as per range of
>>> CEA-861-D (VIC 1-64).
>>> For any other mode, the VIC filed in AVI infoframes should
>>> be 0.
>>> HDMI 2.0 sinks, support video modes range as per CEA-861-F
>>> spec, which is
>>> extended to (VIC 1-107).
>>>
>>> This patch adds a bool input variable, which indicates if
>>> the connected
>>> sink is a HDMI 2.0 sink or not. This will make sure that we
>>> don't pass a
>>> HDMI 2.0 VIC to a HDMI 1.4 sink.
>>>
>>> This patch touches all drm drivers, who are callers of this
>>> function
>>> drm_hdmi_avi_infoframe_from_display_mode but to make sure
>>> there is
>>> no change in current behavior, is_hdmi2 is kept as false.
>>>
>>> In case of I915 driver, this patch checks the
>>> connector->display_info
>>> to check if the connected display is HDMI 2.0.
>>>
>>> Cc: Ville Syrjala 
>>> Cc: Jose Abreu 
>>> Cc: Andrzej Hajda 
>>> Cc: Alex Deucher 
>>> Cc: Daniel Vetter 
>>>
>>> PS: This patch touches a few lines in few files, which were
>>> already above 80 char, so checkpatch gives 80 char warning
>>> again.
>>> - gpu/drm/omapdrm/omap_encoder.c
>>> - gpu/drm/i915/intel_sdvo.c
>>>
>>> Signed-off-by: Shashank Sharma 
>>> ---
>>>drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>>>drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>>>drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>>>drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>>>drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>>>drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>>>drivers/gpu/drm/drm_edid.c| 12
>>> +++-
>>>drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>>>drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>>>drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>>>drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>>>drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>>>drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>>>drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>>>drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>>>drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>>>drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>>>drivers/gpu/drm/tegra/sor.c   |  2 +-
>>>drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>>>drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>>>include/drm/drm_edid.h|  3 ++-
>>>21 files changed, 38 insertions(+), 21 deletions(-)
>>>
>> [snip]
>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index af93f7a..5ff2886 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct
>>> dw_hdmi *hdmi, struct drm_display_mode *mode)
>>>u8 val;
>>>  /* Initialise info frame from DRM mode */
>>> -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
>>> +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode,
>>> false);
>>>  if (hdmi->hdmi_data.enc_out_format == YCBCR444)
>>>frame.colorspace = HDMI_COLORSPACE_YUV444;
>>>
>> dw-hdmi controller has full support for HDMI 2.0 features.
>> It all
>> depends on the platform it is integrated.
>>
>> I think adding a parameter to
>> drm_hdmi_avi_infoframe_from_display_mode is not the best idea
>> because of this case: A bridge can have support for HDMI 2.0
>> features but the platform may limit this support. I guess it
>> can
>> happen in other drivers too.
> Your driver is in full control of what gets passed here. So I
> don't see
> why that would be a problem.
>
> Also this doesn't really have anything to do with the
> capabilities of
> the source. All we want to make sure is that we don't send a
> VIC the
> sink will not understand.
>
 But the driver is not aware of the platform limitations, its
 generic to the controller only. We could add a field in pdata
 which tells if platform is HDMI 2.0+ but what about other
 bridge
 drivers or HDMI drivers? They wil

Re: [PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Maxime Ripard]

On Wed, Mar 22, 2017 at 08:26:07AM -0500, Rob Herring wrote:
> Similar to the previous commit, convert drivers open coding OF graph
> parsing to use drm_of_find_panel_or_bridge instead.
> 
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
> board, so we want to avoid spurious messages. Plus the kernel is not a
> DT validator.
> 
> Signed-off-by: Rob Herring 
> Reviewed-by: Archit Taneja 
> ---
> v3:
> - rebase to v4.11-rc2
> - rework atmel to support 1 to N connections
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 73 ++-
>  drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
>  drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
>  drivers/gpu/drm/bridge/tc358767.c| 27 +--
>  drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 39 +++---
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
>  drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
>  drivers/gpu/drm/imx/parallel-display.c   | 36 ++
>  drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
>  drivers/gpu/drm/mxsfb/mxsfb_out.c| 40 ++-
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
>  drivers/gpu/drm/sun4i/sun4i_rgb.c| 11 +--
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 
> ++--

For sun4i,
Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Colin Cross]

On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker  wrote:
> Quoting Colin Cross (2017-03-23 15:14:16)
>> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann  wrote:
>> > On 03/22/2017 02:48 PM, Rob Clark wrote:
>> >>
>> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
>> >>>
>> >>> Quoting Rob Clark (2017-03-22 10:07:54)
>> 
>>  I guess an interesting question (from someone who doesn't know meson
>>  yet) would be whether meson could slurp in the Makefile.sources type
>>  stuff that we have, which are shared so far between
>>  android/scons/autotools (and for the most part, kept developers from
>>  having to care *too* much about the different build systems)
>> >>>
>> >>>
>> >>> Jason and I have talked about that too. I'd suggested that we could write
>> >>> a
>> >>> module for meson to read makefile.sources (since we're surely not the
>> >>> only
>> >>> project that would benefit from such a module), except that android is
>> >>> moving to
>> >>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
>> >>> doesn't
>> >>> support using makefile.sources, so it seems somewhat moot in a world of
>> >>> blueprint for android, meson for *.
>> >>
>> >>
>> >> I guess even if it is only a temporary thing, something that could
>> >> slurp in Makefile.sources seems like it would be useful for a
>> >> transition period.
>> >>
>> >> I'm not totally up to speed on android/blueprint stuff.. but even some
>> >> simplified or different "here-are-my-sources" type file that could be
>> >> shared across build systems would be useful.  Meson sounds a bit more
>> >> extensible so maybe there is some potential to adapt to whatever
>> >> android forces on us ;-)
>> >
>> >
>> > +ccross from the Android build team can hopefully provide some input here.
>>
>> For cases like this, we generally add a python script that translates
>> the build files into something Blueprint understands, and rerun it
>> each time we import into the project.
>>
>> Alternatively, Blueprint efficiently supports globbing for sources, so
>> if all the source files are always listed in Makefile.sources (which
>> seems to be true in our copy of libdrm except for intel/test_decode.c)
>> then we could use globs and ignore the makefiles, possibly manually
>> excluding a few files.
>
> I'm hoping you can clarify a couple of questions I have about blueprint:
> 1) android is moving to blueprint from android.mk files?

Yes, in a phased transition.  We support both for now.

> 2) is there a publicly available project that uses blueprint I could look at?
>The documentation I've been able to find is pretty sparse.

Blueprint is a framework for writing build systems, and Soong is
AOSP's Blueprint build system.  See
https://android.googlesource.com/platform/build/soong/+/master/README.md
for documentation on Soong.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Julien Isorce]

Hi Michel,

When it happens, the main thread of our gl based app is stuck on a
ioctl(RADEON_CS). I set RADEON_THREAD=false to ease the debugging but same
thing happens if true. Other threads are only si_shader:0,1,2,3 and are
doing nothing, just waiting for jobs. I can also do sudo gdb -p $(pidof
Xorg) to block the X11 server, to make sure there is no ping pong between 2
processes. All other processes are not loading dri/radeonsi_dri.so . And
adding a few traces shows that the above ioctl call is looping for ever on
https://github.com/torvalds/linux/blob/master/drivers/gpu/
drm/ttm/ttm_bo.c#L819 and comes from mesa
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/radeon/drm/radeon_drm_cs.c#n454
.

After adding even more traces I can see that the bo, which is being
indefinitely evicted, has the flag RADEON_GEM_NO_CPU_ACCESS.
And it gets 3 potential placements after calling "radeon_evict_flags".
 1: VRAM cpu inaccessible, fpfn is 65536
 2: VRAM cpu accessible, fpfn is 0
 3: GTT, fpfn is 0

And it looks like it continuously succeeds to move on the second placement.
So I might be wrong but it looks it is not even a ping pong between VRAM
accessible / not accessible, it just keeps being blited in the CPU
accessible part of the VRAM.

Maybe radeon_evict_flags should just not add the second placement if its
current placement is already VRAM cpu accessible.
Or could be a bug in the get_node that should not succeed in that case.

Note that this happens when the VRAM is nearly full.

FWIW I noticed that amdgpu is doing something different:
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c#L205
vs
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/radeon/radeon_ttm.c#L198


Finally the NMI watchdog and the kernel soft lockup and hard lockup
detectors do not detect this looping in that ioctl(RADEON_CS). Maybe
because it estimates it is doing real work. Same for radeon_lockup_timeout,
it does not detect it.

The gpu is a FirePro W600 Cape Verde 2048M.

Thx
Julien

On Thu, Mar 23, 2017 at 8:10 AM, Michel Dänzer  wrote:

> On 23/03/17 03:19 AM, Zachary Michaels wrote:
> > We were experiencing an infinite loop due to VRAM bos getting added back
> > to the VRAM lru on eviction via ttm_bo_mem_force_space,
>
> Can you share more details about what happened? I can imagine that
> moving a BO from CPU visible to CPU invisible VRAM would put it back on
> the LRU, but next time around it shouldn't hit this code anymore but get
> evicted to GTT directly.
>
> Was userspace maybe performing concurrent CPU access to the BOs in
> question?
>
>
> > and reverting this commit solves the problem.
>
> I hope we can find a better solution.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

[Jose Abreu]

Hi Shashank,


On 22-03-2017 18:57, Sharma, Shashank wrote:
> Hi Jose, 
> I can't find the other patches of this series in dri patchwork, am I missing 
> something ?

You can find them now in patchwork (I don't know what happened).

>
> Also, I am planning to publish a series for YUV 420 handling, where I have 
> re-used one of your patch to parse YUV 420 block, with some modifications 
> :-).  

Nice :) Please cc me and I will try to review them.

Best regards,
Jose Miguel Abreu

>
> Regards
> Shashank 
> -Original Message-
> From: Jose Abreu [mailto:jose.ab...@synopsys.com] 
> Sent: Wednesday, March 22, 2017 8:13 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Carlos Palminha ; Vetter, Daniel 
> ; Sharma, Shashank ; 
> ville.syrj...@linux.intel.com
> Subject: Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core
>
> ++ Daniel
>
> ++ Ville
>
> ++ Shashank
>
>
> On 22-03-2017 17:35, Jose Abreu wrote:
>> Hi all,
>>
>> This is a RFC series that aims to collect comments regarding the 
>> handling of HDMI 2.0+ video modes and features in the DRM core.
>>
>> Some of the HDMI 2.0 features are already implemented and only affect 
>> kernel drivers (SDCD for example). There are some features, though, 
>> which can, and will, affect userspace.
>>
>> It is clear that userspace can't be broken, so, based on previous 
>> discussions I started implementing a "HDMI 2.0+ knob" which can be set 
>> by userspace to enable HDMI 2.0+ features.
>>
>> For now this only limits the exposing of the video modes defined in 
>> CEA-861-F, but it can be extended adding, for example, YCbCr 4:2:0.
>>
>> Please do not see this as a formal patch as this wasn't even compiled 
>> tested but, please, feel free to comment :)
>>
>> NOTE: The adding of the new video modes timings was originally done by 
>> Shashank Sharma  so, credit to him. I 
>> modified it a little bit (added the HDMI 2.0+ flag) and I don't know 
>> if I should add his signed-off-by as it was modified.
>>
>> Best regards,
>> Jose Miguel Abreu
>>
>> Cc: Carlos Palminha 
>> Cc: dri-devel@lists.freedesktop.org
>>
>> Jose Abreu (5):
>>   drm: Add HDMI 2.0+ features exposing knob
>>   drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag
>>   drm: edid: Add HDMI 2.0 CEA video modes
>>   drm: connector: Add hdmi2_allowed flag
>>   drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked
>> to
>>
>>  drivers/gpu/drm/drm_connector.c|   2 +
>>  drivers/gpu/drm/drm_edid.c | 258 
>> +
>>  drivers/gpu/drm/drm_ioctl.c|   5 +
>>  drivers/gpu/drm/drm_probe_helper.c |   9 +-
>>  include/drm/drm_connector.h|   2 +
>>  include/drm/drm_file.h |   8 ++
>>  include/drm/drm_modes.h|  14 ++
>>  include/uapi/drm/drm.h |   7 +
>>  include/uapi/drm/drm_mode.h|   9 ++
>>  9 files changed, 313 insertions(+), 1 deletion(-)
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=yaVFU4TjGY0gVF8El1uKcisy6TPsyCl9uN7Wsis-qhY&m=2OKRtIbkxjKURLp5pmoJ8lSSpsZfM6cXwik8mwS0U_4&s=oxPm-LzATMtdXVlKmybIHwYKhKvT-eeayLhz7xRtQkg&e=
>  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Jose Abreu]

Hi Ville,


On 23-03-2017 17:42, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 16:43, Sharma, Shashank wrote:
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 3/23/2017 6:33 PM, Jose Abreu wrote:
 Hi Shashank,


 On 23-03-2017 16:08, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 5:57 PM, Jose Abreu wrote:
>> Hi Ville,
>>
>>
>> On 23-03-2017 15:45, Ville Syrjälä wrote:
>>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
 Hi Shashank,


 On 23-03-2017 15:14, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of
> CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should
> be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F
> spec, which is
> extended to (VIC 1-107).
>
> This patch adds a bool input variable, which indicates if
> the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we
> don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.
>
> This patch touches all drm drivers, who are callers of this
> function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure
> there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch checks the
> connector->display_info
> to check if the connected display is HDMI 2.0.
>
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning
> again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> Signed-off-by: Shashank Sharma 
> ---
>drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>drivers/gpu/drm/drm_edid.c| 12
> +++-
>drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>drivers/gpu/drm/tegra/sor.c   |  2 +-
>drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>include/drm/drm_edid.h|  3 ++-
>21 files changed, 38 insertions(+), 21 deletions(-)
>
 [snip]

> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index af93f7a..5ff2886 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct
> dw_hdmi *hdmi, struct drm_display_mode *mode)
>u8 val;
>  /* Initialise info frame from DRM mode */
> -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode,
> false);
>  if (hdmi->hdmi_data.enc_out_format == YCBCR444)
>frame.colorspace = HDMI_COLORSPACE_YUV444;
>
 dw-hdmi controller has full support for HDMI 2.0 features.
 It all
 depends on the platform it is integrated.

 I think adding a parameter to
 drm_hdmi_avi_infoframe_from_display_mode is not the best idea
 because of this case: A bridge can have support for HDMI 2.0
 features but the platform may limit this support. I guess it
 can
 happen in other drivers too.
>>> Your driver is in full control of what gets passed here. So I
>>> don't see
>>> why that would be a problem.
>>>
>>> Also this doesn't really have anything to do with the
>>> capabilities of

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

[Jose Abreu]

Hi Andrzej,


Thanks for the feedback!

On 23-03-2017 08:11, Andrzej Hajda wrote:
> On 22.03.2017 18:35, Jose Abreu wrote:
>> This patch completes CEA table of video modes so that VIC 1-107
>> are now available. Use the HDMI 2.0+ flag to signal these are
>> modes for HDMI 2.0 onwards.
> edid_cea_modes array is used in different contexts, simple extensions of
> the array with modes not present in HDMI < 2.0 can result in different
> behavior of drivers.
> There should be put sentinels somewhere to limit table lookup to old
> VICs if device/driver/receiver is not HDMI2.0 compliant.
> The only situation I am aware of at the moment is infoframe generation
> code. For TVs not supporting 4K modes but not HDMI 2.0 compatible, VIC
> field in AVI infoframe should be 0 for 4K modes and vendor infoframe
> should be generated with proper HDMI-VIC. With current infoframe helpers
> and this patch it will not work this way.

But this is what I do in patch 5/5 (see
https://patchwork.kernel.org/patch/9640205/), unless drivers ask
to I don't expose the new modes.

Best regards,
Jose Miguel Abreu

>
> Regards
> Andrzej
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/drm_edid.c | 258 
>> +
>>  1 file changed, 258 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index fad3d44..90080368 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1001,6 +1001,264 @@ struct minimode {
>> 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
>> +/* 65 - 1280x720@24Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
>> +   3080, 3300, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>> +   DRM_MODE_FLAG_HDMI2),
>> +  .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 66 - 1280x720@25Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
>> +   3740, 3960, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>> +   DRM_MODE_FLAG_HDMI2),
>> +  .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 67 - 1280x720@30Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
>> +   3080, 3300, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>> +   DRM_MODE_FLAG_HDMI2),
>> +  .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 68 - 1280x720@50Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
>> +   1760, 1980, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>> +   DRM_MODE_FLAG_HDMI2),
>> +  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 69 - 1280x720@60Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
>> +   1430, 1650, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>> +   DRM_MODE_FLAG_HDMI2),
>> +  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 70 - 1280x720@100Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
>> +   1760, 1980, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>> +   DRM_MODE_FLAG_HDMI2),
>> +  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 71 - 1280x720@120Hz */
>> +{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
>> +   1430, 1650, 0, 720, 725, 730, 750, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>> +   DRM_MODE_FLAG_HDMI2),
>> +  .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 72 - 1920x1080@24Hz */
>> +{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
>> +   2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>> +   DRM_MODE_FLAG_HDMI2),
>> +  .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 73 - 1920x1080@25Hz */
>> +{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
>> +   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>> +   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>> +   DRM_MODE_FLAG_HDMI2),
>> +  .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>> +/* 74 - 1920x1080@30Hz */
>> +{ DRM_MODE("1920x1080", DRM_MODE_

Re: [RFC 1/5] drm: Add HDMI 2.0+ features exposing knob

[Jose Abreu]

Hi Daniel,


On 23-03-2017 07:22, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote:
>> We can't expect userspace to have full support for all HDMI 2.0+
>> features. Instead of expecting/waiting for userspace to support
>> the new features add a knob, much like the stereo knob, so that
>> DRM core will only expose the features when asked too.
>>
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/drm_ioctl.c | 5 +
>>  include/drm/drm_file.h  | 8 
>>  include/uapi/drm/drm.h  | 7 +++
>>  3 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>> index a7c61c2..2430e2e 100644
>> --- a/drivers/gpu/drm/drm_ioctl.c
>> +++ b/drivers/gpu/drm/drm_ioctl.c
>> @@ -318,6 +318,11 @@ static int drm_getcap(struct drm_device *dev, void 
>> *data, struct drm_file *file_
>>  file_priv->atomic = req->value;
>>  file_priv->universal_planes = req->value;
>>  break;
>> +case DRM_CLIENT_CAP_HDMI2:
>> +if (req->value > 1)
>> +return -EINVAL;
>> +file_priv->hdmi2_allowed = req->value;
> Needs some userspace to make use of this (like the -modesetting x.org
> driver).
> -Daniel

I see your point but shouldn't this be merged before actually
starting to work in userspace?

Best regards,
Jose Miguel Abreu

>
>> +break;
>>  default:
>>  return -EINVAL;
>>  }
>> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
>> index 5dd27ae..7b97d85 100644
>> --- a/include/drm/drm_file.h
>> +++ b/include/drm/drm_file.h
>> @@ -192,6 +192,14 @@ struct drm_file {
>>  unsigned is_master:1;
>>  
>>  /**
>> + * @hdmi2_allowed:
>> + *
>> + * True if client understands HDMI 2.0+ features like, for example,
>> + * extended aspect ratios
>> + */
>> +unsigned hdmi2_allowed:1;
>> +
>> +/**
>>   * @master:
>>   *
>>   * Master this node is currently associated with. Only relevant if
>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>> index b2c5284..9e25138 100644
>> --- a/include/uapi/drm/drm.h
>> +++ b/include/uapi/drm/drm.h
>> @@ -678,6 +678,13 @@ struct drm_get_cap {
>>   */
>>  #define DRM_CLIENT_CAP_ATOMIC   3
>>  
>> +/**
>> + * DRM_CLIENT_CAP_HDMI2
>> + *
>> + * If set to 1, the DRM core will expose HDMI 2.0+ features to userspace
>> + */
>> +#define DRM_CLIENT_CAP_HDMI24
>> +
>>  /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
>>  struct drm_set_client_cap {
>>  __u64 capability;
>> -- 
>> 1.9.1
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=4lBpQovdR7O8jeC7mV8SX9xvTypMtV8CBDEDg3bGgzw&s=h-gqFlO62i53pir0j2lJ-upE_bXQxhn3BK1nhdxoB6Y&e=
>>  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 8/8] ARM: configs: Add STM32 panel simple support in STM32 defconfig

[Alexandre Torgue]

Hi,

On 03/15/2017 06:02 PM, Yannick Fertre wrote:

Signed-off-by: Yannick Fertre 
---


Same remarks than patch7


 arch/arm/configs/stm32_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 9c6ba54e..f7ddf29b 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -50,6 +50,8 @@ CONFIG_SERIAL_STM32_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
 CONFIG_DRM=y
+CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_MFD_SYSCON=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_NEW_LEDS=y


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 7/8] ARM: configs: Add STM32 LTDC support in STM32 defconfig

[Alexandre Torgue]

Hi

On 03/15/2017 06:02 PM, Yannick Fertre wrote:

Signed-off-by: Yannick Fertre 
---


Can you change commit header by:" ARM: config: stm32: Add LTDC support"
and can you fill a commit message please ?


 arch/arm/configs/stm32_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 436240d..9c6ba54e 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -49,6 +49,7 @@ CONFIG_SERIAL_STM32=y
 CONFIG_SERIAL_STM32_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
+CONFIG_DRM=y
 CONFIG_MFD_SYSCON=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_NEW_LEDS=y


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Colin Cross (2017-03-23 15:14:16)
> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann  wrote:
> > On 03/22/2017 02:48 PM, Rob Clark wrote:
> >>
> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
> >>>
> >>> Quoting Rob Clark (2017-03-22 10:07:54)
> 
>  I guess an interesting question (from someone who doesn't know meson
>  yet) would be whether meson could slurp in the Makefile.sources type
>  stuff that we have, which are shared so far between
>  android/scons/autotools (and for the most part, kept developers from
>  having to care *too* much about the different build systems)
> >>>
> >>>
> >>> Jason and I have talked about that too. I'd suggested that we could write
> >>> a
> >>> module for meson to read makefile.sources (since we're surely not the
> >>> only
> >>> project that would benefit from such a module), except that android is
> >>> moving to
> >>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
> >>> doesn't
> >>> support using makefile.sources, so it seems somewhat moot in a world of
> >>> blueprint for android, meson for *.
> >>
> >>
> >> I guess even if it is only a temporary thing, something that could
> >> slurp in Makefile.sources seems like it would be useful for a
> >> transition period.
> >>
> >> I'm not totally up to speed on android/blueprint stuff.. but even some
> >> simplified or different "here-are-my-sources" type file that could be
> >> shared across build systems would be useful.  Meson sounds a bit more
> >> extensible so maybe there is some potential to adapt to whatever
> >> android forces on us ;-)
> >
> >
> > +ccross from the Android build team can hopefully provide some input here.
> 
> For cases like this, we generally add a python script that translates
> the build files into something Blueprint understands, and rerun it
> each time we import into the project.
> 
> Alternatively, Blueprint efficiently supports globbing for sources, so
> if all the source files are always listed in Makefile.sources (which
> seems to be true in our copy of libdrm except for intel/test_decode.c)
> then we could use globs and ignore the makefiles, possibly manually
> excluding a few files.

I'm hoping you can clarify a couple of questions I have about blueprint:
1) android is moving to blueprint from android.mk files?
2) is there a publicly available project that uses blueprint I could look at?
   The documentation I've been able to find is pretty sparse.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100364

John Brooks  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=90320

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 90320] Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=90320

John Brooks  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=100364

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100364

--- Comment #1 from John Brooks  ---
Created attachment 130407
  --> https://bugs.freedesktop.org/attachment.cgi?id=130407&action=edit
Fix for display not waking

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100364

Bug ID: 100364
   Summary: DisplayPort hotplug warning and monitor sometimes
stays blank
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bugs.freedesk...@fastquake.com

Created attachment 130406
  --> https://bugs.freedesktop.org/attachment.cgi?id=130406&action=edit
Fix for kernel WARN

What I'm using:
- R9 290
- Kernel 4.10.4
- ASUS PB278Q monitor, connected with DisplayPort
- OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.1.0-devel
  (git-d9fef84) 
- radeon DDX 7.8.99 (Git)

On the above setup, I have two problems:
- Kernel warning that happens when I turn the monitor on from an off state
- Display stays blank after being turned on or waking from sleep

First is the kernel WARN. It looks like this:

[102004.855043] [ cut here ]
[102004.855046] WARNING: CPU: 7 PID: 14012 at ./include/drm/drm_crtc.h:1403
drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]
[102004.855046] Modules linked in: vhost_net vhost macvtap macvlan xt_CHECKSUM
iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4
nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT
nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter
ip6_tables iptable_filter ip_tables x_tables binfmt_misc nls_iso8859_1 mxm_wmi
intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul
glue_helper ablk_helper cryptd snd_usb_audio snd_usbmidi_lib input_leds joydev
serio_raw snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi
snd_hda_intel snd_soc_rt5640 snd_hda_codec snd_soc_ssm4567 snd_soc_rl6231
snd_hda_core snd_soc_core snd_hwdep mei_me lpc_ich
[102004.855058]  mei snd_compress shpchp snd_pcm snd_seq_midi
snd_seq_midi_event snd_rawmidi snd_seq snd_timer snd_seq_device snd wmi
elan_i2c soundcore dw_dmac video snd_soc_sst_acpi i2c_designware_platform
snd_soc_sst_match i2c_designware_core 8250_dw mac_hid spi_pxa2xx_platform
acpi_pad tpm_infineon kvm_intel kvm irqbypass sunrpc parport_pc ppdev lp
parport autofs4 btrfs xor raid6_pq dm_mirror dm_region_hash dm_log hid_generic
usbhid amdkfd amd_iommu_v2 radeon(OE) i2c_algo_bit drm_kms_helper syscopyarea
sysfillrect sysimgblt fb_sys_fops ttm e1000e crc32c_intel drm psmouse ahci ptp
libahci pps_core sdhci_acpi sdhci i2c_hid hid fjes
[102004.855070] CPU: 7 PID: 14012 Comm: kworker/7:1 Tainted: GW  OE  
4.9.0 #13
[102004.855070] Hardware name: Gigabyte Technology Co., Ltd.
Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014
[102004.855078] Workqueue: events radeon_dp_work_func [radeon]
[102004.855079]  a82d4c277d20 aa432693 

[102004.855080]  a82d4c277d60 aa082bbb 057b401c8000
8c7641aa1800
[102004.855081]  8c764008a000 8c764008a000 0003

[102004.855082] Call Trace:
[102004.855083]  [] dump_stack+0x63/0x90
[102004.855083]  [] __warn+0xcb/0xf0
[102004.855084]  [] warn_slowpath_null+0x1d/0x20
[102004.855087]  [] drm_helper_choose_crtc_dpms+0x93/0xa0
[drm_kms_helper]
[102004.855089]  [] drm_helper_connector_dpms+0x77/0x100
[drm_kms_helper]
[102004.855096]  [] ? atombios_blank_crtc+0x150/0x150
[radeon]
[102004.855103]  [] radeon_connector_hotplug+0xf6/0x120
[radeon]
[102004.855111]  [] radeon_dp_work_func+0x3f/0x60 [radeon]
[102004.855112]  [] process_one_work+0x16b/0x480
[102004.855113]  [] worker_thread+0x4b/0x500
[102004.855114]  [] ? process_one_work+0x480/0x480
[102004.855115]  [] ? process_one_work+0x480/0x480
[102004.855116]  [] kthread+0xd9/0xf0
[102004.855117]  [] ? kthread_park+0x60/0x60
[102004.855118]  [] ret_from_fork+0x25/0x30
[102004.855118] ---[ end trace cbb9abffe6127dc8 ]---

After some investigation I found that the attached patch will solve the
warning. 

However, it does not solve my other problem, which is that sometimes, when
turning the monitor on, the display will not wake; it will just display "No
Signal". To make it wake up one has to turn the monitor off and on again a few
times, unplug the cable, or (more recently; I'm not sure what changed), turn
off the monitor, go to a TTY, and turn the monitor back on.

I enabled debugging in /sys/module/drm/parameters/debug, and saw some messages
like:
dp_aux_ch flags not zero: 0201

Which lead me to create another patch which I will attach in a reply. The patch
does help the monitor consistently wake up as it should. Though the
radeon_dp_link errors in dmesg still show up.

Both of these issues have been touched on in one way or another in the past.
The mutex issue in my first patch was discussed here:
https:

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Greg Hackmann]

On 03/22/2017 02:48 PM, Rob Clark wrote:

On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:

Quoting Rob Clark (2017-03-22 10:07:54)

I guess an interesting question (from someone who doesn't know meson
yet) would be whether meson could slurp in the Makefile.sources type
stuff that we have, which are shared so far between
android/scons/autotools (and for the most part, kept developers from
having to care *too* much about the different build systems)


Jason and I have talked about that too. I'd suggested that we could write a
module for meson to read makefile.sources (since we're surely not the only
project that would benefit from such a module), except that android is moving to
blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
support using makefile.sources, so it seems somewhat moot in a world of
blueprint for android, meson for *.


I guess even if it is only a temporary thing, something that could
slurp in Makefile.sources seems like it would be useful for a
transition period.

I'm not totally up to speed on android/blueprint stuff.. but even some
simplified or different "here-are-my-sources" type file that could be
shared across build systems would be useful.  Meson sounds a bit more
extensible so maybe there is some potential to adapt to whatever
android forces on us ;-)


+ccross from the Android build team can hopefully provide some input here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

[Linus Walleij]

On Sat, Mar 18, 2017 at 12:09 AM, Russell King - ARM Linux
 wrote:
> On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote:
>> This is a modesetting driver for the pl111 CLCD display controller
>> found on various ARM platforms such as the Versatile Express. The
>> driver has only been tested on the bcm911360_entphn platform so far,
>> with PRIME-based buffer sharing between vc4 and clcd.
>>
>> It reuses the existing devicetree binding, while not using quite as
>> many of its properties as the fbdev driver does (those are left for
>> future work).
>
> As we're multiplatform on ARM, and this is using the PL11x AMBA IDs,
> we must ensure that it's compatible with everything that the fbdev
> driver is compatible with... however, I suspect that's not worth the
> effort (unless Linus W wants it?)

Hm, I certainly want it... but it would be unreasonable of me to expect
Eric to cold-code a big upfront design for systems he can't even test
this on.

What I would request would rather be: please do not put in any
immediate roadblocks and keep it in the back of your head that I will
maybe come in and add support for the PL110 systems once this
works. (Of course that would be with the aim to deprecate and
delete the old fbdev driver in favor of this one.)

I can help with some RealView testing along the way to begin with.

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/2] drm/panel: add innolux,p079zca panel driver

[Stéphane Marchesin]

can you add bps here too?

On Tue, Mar 21, 2017 at 6:53 PM, Chris Zhong  wrote:
> Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
> panel.
>
> Signed-off-by: Chris Zhong 
> Reviewed-by: Sean Paul 
> Tested-by: Brian Norris 
> ---
>
> Changes in v3:
> - printk err after regulator_disable(innolux->supply)
>
> Changes in v2:
> - add some error check
> - always use Low power mode to send commend
> - add comments for all the sleep
> - use DRM_DEV_ERROR instead of dev_err
>
>  drivers/gpu/drm/panel/Kconfig |  11 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  drivers/gpu/drm/panel/panel-innolux-p079zca.c | 345 
> ++
>  3 files changed, 357 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 62aba97..99dd010 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
>   that it can be automatically turned off when the panel goes into a
>   low power state.
>
> +config DRM_PANEL_INNOLUX_P079ZCA
> +   tristate "Innolux P079ZCA panel"
> +   depends on OF
> +   depends on DRM_MIPI_DSI
> +   depends on BACKLIGHT_CLASS_DEVICE
> +   help
> + Say Y here if you want to enable support for Innolux P079ZCA
> + TFT-LCD modules. The panel has a 1024x768 resolution and uses
> + 24 bit RGB per pixel. It provides a MIPI DSI interface to
> + the host and has a built-in LED backlight.
> +
>  config DRM_PANEL_JDI_LT070ME05000
> tristate "JDI LT070ME05000 WUXGA DSI panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index a5c7ec0..bda2aa4 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> +obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
>  obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
>  obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>  obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
> panel-panasonic-vvx10f034n00.o
> diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
> b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> new file mode 100644
> index 000..9f3423a0
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> @@ -0,0 +1,345 @@
> +/*
> + * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct innolux_panel {
> +   struct drm_panel base;
> +   struct mipi_dsi_device *link;
> +
> +   struct backlight_device *backlight;
> +   struct regulator *supply;
> +   struct gpio_desc *enable_gpio;
> +
> +   bool prepared;
> +   bool enabled;
> +};
> +
> +static inline struct innolux_panel *to_innolux_panel(struct drm_panel *panel)
> +{
> +   return container_of(panel, struct innolux_panel, base);
> +}
> +
> +static int innolux_panel_disable(struct drm_panel *panel)
> +{
> +   struct innolux_panel *innolux = to_innolux_panel(panel);
> +   int err;
> +
> +   if (!innolux->enabled)
> +   return 0;
> +
> +   if (innolux->backlight) {
> +   innolux->backlight->props.power = FB_BLANK_POWERDOWN;
> +   backlight_update_status(innolux->backlight);
> +   }
> +
> +   err = mipi_dsi_dcs_set_display_off(innolux->link);
> +   if (err < 0)
> +   DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
> + err);
> +
> +   innolux->enabled = false;
> +
> +   return 0;
> +}
> +
> +static int innolux_panel_unprepare(struct drm_panel *panel)
> +{
> +   struct innolux_panel *innolux = to_innolux_panel(panel);
> +   int err;
> +
> +   if (!innolux->prepared)
> +   return 0;
> +
> +   err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
> +   if (err < 0) {
> +   DRM_DEV_ERROR(panel->dev, "failed to enter sleep mode: %d\n",
> + err);
> +   return err;
> +   }
> +
> +   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
> +
> +   /* T8: 80ms - 1000ms */
> +   msleep(80);
> +
> +   err = regulator_disable(innolux->supply);
> +   if (err < 0)
> +   return err;
> +
> +   innolux->prepared = false;
> +
> +   return 0;
> +}
> +
> +static int innolux_panel_prepare(struct drm_panel *panel)
> +{
> +

[Bug 79431] OpenGL OpenCL interop results in corrupted renderbuffer object image

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=79431

Jan Vesely  changed:

   What|Removed |Added

 Resolution|NOTABUG |---
 Status|RESOLVED|REOPENED
 Blocks|99553   |

--- Comment #5 from Jan Vesely  ---
(In reply to Vedran Miletić from comment #4)
> r600 does support OpenCL, but only on EG/NI (Radeon HD 5000/6000).

my understanding is that this bug is not about clover, but getting r600g GL
work with third party CL.
afaik Marek was looking into that, but that might have been just for GCN+. (the
conclusion might still be that it's unsupported)


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99553
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553

Jan Vesely  changed:

   What|Removed |Added

 Depends on|79431   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79431
[Bug 79431] OpenGL OpenCL interop results in corrupted renderbuffer object
image
-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100289

--- Comment #6 from omegap...@startmail.com ---
Ah sorry I was supposed to xrandr it when it broke - will happen again tomorrow
I'm sure ;)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100289

--- Comment #5 from omegap...@startmail.com ---
Ah, happened again after leaving it off for ~2 hours...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

[Ville Syrjälä]

On Thu, Mar 23, 2017 at 06:54:52PM +, Jose Abreu wrote:
> Hi Ville,
> 
> 
> On 23-03-2017 15:16, Ville Syrjälä wrote:
> > On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote:
> >> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
> >> flag which will signal userspace that this is a HDMI 2.0+ mode. It
> >> is expected that these new flags will not be exported to userspace
> >> unless client asks to.
> > W.r.t. the aspect ratio userspace story, there was some discussion
> > on #dri-devel recently about extending the xrandr protocol for 3d stereo
> > support. If that is going to happen then it might make sense to try
> > and get the aspect ratio stuff also included at the same time so
> > that we would only have to deal with one protocol bump.
> 
> Hmm, are you saying to just use one knob for 3d and the aspect
> ratios?

No. I'm saying that extending xrandr with either means a protocol bump.
But if we do both at the same time we just need one bump.

> Aren't there already userspace consumers of the 3d knob?

Not that I know of. And there's definitely nothing in xrandr for this
stuff, so any consumer would have to be something non-x11 based.

> 
> Best regards,
> Jose Miguel Abreu
> 
> >
> >> Signed-off-by: Jose Abreu 
> >> Cc: Carlos Palminha 
> >> Cc: dri-devel@lists.freedesktop.org
> >> ---
> >>  include/uapi/drm/drm_mode.h | 9 +
> >>  1 file changed, 9 insertions(+)
> >>
> >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >> index 8c67fc0..62e679c 100644
> >> --- a/include/uapi/drm/drm_mode.h
> >> +++ b/include/uapi/drm/drm_mode.h
> >> @@ -89,6 +89,8 @@
> >>  #define DRM_MODE_PICTURE_ASPECT_NONE  0
> >>  #define DRM_MODE_PICTURE_ASPECT_4_3   1
> >>  #define DRM_MODE_PICTURE_ASPECT_16_9  2
> >> +#define DRM_MODE_PICTURE_ASPECT_64_27 3
> >> +#define DRM_MODE_PICTURE_ASPECT_256_135   4
> >>  
> >>  /* Aspect ratio flag bitmask (4 bits 22:19) */
> >>  #define DRM_MODE_FLAG_PIC_AR_MASK (0x0F<<19)
> >> @@ -98,6 +100,13 @@
> >>(DRM_MODE_PICTURE_ASPECT_4_3<<19)
> >>  #define  DRM_MODE_FLAG_PIC_AR_16_9 \
> >>(DRM_MODE_PICTURE_ASPECT_16_9<<19)
> >> +#define  DRM_MODE_FLAG_PIC_AR_64_27 \
> >> +  (DRM_MODE_PICTURE_ASPECT_64_27<<19)
> >> +#define  DRM_MODE_FLAG_PIC_AR_256_135 \
> >> +  (DRM_MODE_PICTURE_ASPECT_256_135<<19)
> >> +
> >> +/* HDMI 2.0+ mode flag: will only be set if client supports it */
> >> +#define DRM_MODE_FLAG_HDMI2   (1<<23)
> >>  
> >>  /* DPMS flags */
> >>  /* bit compatible with the xorg definitions. */
> >> -- 
> >> 1.9.1
> >>
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIDAw&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=BBAO8Rra0sW4KcCLB5lMOfONxg0v9pfUSaDNr5WDh2w&s=p6tAeWYwiSDL7BonKeijv2zmweBF9eW7xV7OX5e5gG4&e=
> >>  

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100304] [bisected] Kernel oops on startup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100304

Alex Deucher  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Alex Deucher  ---
fix squashed into the original patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 21 March 2017 at 05:00, Jonathan Gray  wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner  wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> > > wrote:
>> > > > Seems like we ended up all over the place, so let me try afresh.
>> > > >
>> > > > Above all:
>> > > >  - Saying "I don't care" about your users is arrogant - let us _not_
>> > > > do that, please ?
>> > >
>> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
>> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
>> > > GCC,
>> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> > wasn't OpenBSD to blame here ;-)
>>
>> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
>> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>>
>> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
>> rather not go through the upgrade hassle if I don't have to."
>>
>> Followed by Jose "We're internally building and shipping Mesa compiled with
>> GCC 4.4 (more specifically 4.4.3).
>>
>> It's fine if you require GCC 4.8 on automake, but please leave support
>> for GCC 4.4.x in SCons."
>>
>> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
>> various features backported, from what I understand Mesa would not build on
>> a real GCC 4.2 release and we should not be using it as a min version. IMO
>> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
>> the min GCC version.
>>
>> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
>> deal with it if we move on.
>
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.
>
> We have one platform using clang/lld now (arm64) and are likely to move
> others in future where possible.  libtool has to be patched and the Mesa
> configure script regenerated to make this work or Mesa won't build due
> to libtool.m4 looking for specific strings in ld -v produced by bfd
> binutils or gold...
>
> And yes if you change the configure script to check for a newer version
> I'll revert it locally like I did with the zlib one.
>
> As I get the impression no one cares about patches for older GCC I've
> not being sending them to the list, ie
>
> commit d3d340d6026e516cc405a2eb1d925a7a7a467480
> Author: Jonathan Gray 
> Date:   Thu Mar 16 00:30:07 2017 +1100
>
> i965: don't use designated array initialisation
>
> Don't use a form of designated array initialisation that breaks gcc 4.2.1.
>
Jonathan, I think you meant to say:
Using C99 designated initializers is not allowed in C++ code, thus the
compiler may warn or even fail.

>
> Signed-off-by: Jonathan Gray 
>
> diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp 
> b/src/intel/compiler/brw_vec4_gs_visitor.cpp
> index 4a8b5be30e..e7a502306e 100644
> --- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
> +++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
> @@ -585,23 +585,6 @@ vec4_gs_visitor::gs_end_primitive()
> emit(OR(dst_reg(this->control_data_bits), this->control_data_bits, mask));
>  }
>
> -static const GLuint gl_prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
We already have C helper get_hw_prim_for_gl_prim that we can use instead.
I'll send a patch in a minute.

Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Ville Syrjälä]

On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote:
> Hi Ville,
> 
> 
> On 23-03-2017 17:42, Ville Syrjälä wrote:
> > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
> >> Hi Shashank,
> >>
> >>
> >> On 23-03-2017 16:43, Sharma, Shashank wrote:
> >>> Regards
> >>>
> >>> Shashank
> >>>
> >>>
> >>> On 3/23/2017 6:33 PM, Jose Abreu wrote:
>  Hi Shashank,
> 
> 
>  On 23-03-2017 16:08, Sharma, Shashank wrote:
> > Regards
> >
> > Shashank
> >
> >
> > On 3/23/2017 5:57 PM, Jose Abreu wrote:
> >> Hi Ville,
> >>
> >>
> >> On 23-03-2017 15:45, Ville Syrjälä wrote:
> >>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
>  Hi Shashank,
> 
> 
>  On 23-03-2017 15:14, Shashank Sharma wrote:
> > HDMI 1.4b support the CEA video modes as per range of
> > CEA-861-D (VIC 1-64).
> > For any other mode, the VIC filed in AVI infoframes should
> > be 0.
> > HDMI 2.0 sinks, support video modes range as per CEA-861-F
> > spec, which is
> > extended to (VIC 1-107).
> >
> > This patch adds a bool input variable, which indicates if
> > the connected
> > sink is a HDMI 2.0 sink or not. This will make sure that we
> > don't pass a
> > HDMI 2.0 VIC to a HDMI 1.4 sink.
> >
> > This patch touches all drm drivers, who are callers of this
> > function
> > drm_hdmi_avi_infoframe_from_display_mode but to make sure
> > there is
> > no change in current behavior, is_hdmi2 is kept as false.
> >
> > In case of I915 driver, this patch checks the
> > connector->display_info
> > to check if the connected display is HDMI 2.0.
> >
> > Cc: Ville Syrjala 
> > Cc: Jose Abreu 
> > Cc: Andrzej Hajda 
> > Cc: Alex Deucher 
> > Cc: Daniel Vetter 
> >
> > PS: This patch touches a few lines in few files, which were
> > already above 80 char, so checkpatch gives 80 char warning
> > again.
> > - gpu/drm/omapdrm/omap_encoder.c
> > - gpu/drm/i915/intel_sdvo.c
> >
> > Signed-off-by: Shashank Sharma 
> > ---
> >drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
> >drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
> >drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
> >drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
> >drivers/gpu/drm/bridge/sii902x.c  |  2 +-
> >drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
> >drivers/gpu/drm/drm_edid.c| 12
> > +++-
> >drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
> >drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
> >drivers/gpu/drm/i915/intel_hdmi.c |  5 -
> >drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
> >drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
> >drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
> >drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
> >drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
> >drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
> >drivers/gpu/drm/tegra/hdmi.c  |  2 +-
> >drivers/gpu/drm/tegra/sor.c   |  2 +-
> >drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
> >drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
> >include/drm/drm_edid.h|  3 ++-
> >21 files changed, 38 insertions(+), 21 deletions(-)
> >
>  [snip]
> 
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index af93f7a..5ff2886 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct
> > dw_hdmi *hdmi, struct drm_display_mode *mode)
> >u8 val;
> >  /* Initialise info frame from DRM mode */
> > -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> > +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode,
> > false);
> >  if (hdmi->hdmi_data.enc_out_format == YCBCR444)
> >frame.colorspace = HDMI_COLORSPACE_YUV444;
> >
>  dw-hdmi controller has full support for HDMI 2.0 features.
>  It all
>  depends on the platform it is integrated.
> 
>  I think adding a parameter to
>  drm_hdmi_avi_infoframe_from_display_mode is not the best idea
>  because of this case: A bridge can have support for HDMI 2.0
>  features but the platform ma

[Bug 100067] [OpenCL] const int in argument list crashes build

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100067

--- Comment #6 from Vedran Miletić  ---
(In reply to Mig from comment #5)
> minimal.cpp compiled with
> 
> gcc -c minimal.cpp -g   -o minimal.o
> 
> [miguel@antergos-mig extra]$ gdb
> GNU gdb (GDB) 7.12.1
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb) file ./minimal
> Reading symbols from ./minimal...done.
> (gdb) b 20
> Breakpoint 1 at 0x400cee: file minimal.cpp, line 20.
> (gdb) run
> Starting program:
> /home/miguel/Dokumente/OpenCLExamples/myGEMM-master/extra/minimal 
> >>> Initializing OpenCL...
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> [New Thread 0x7fffef7f8700 (LWP 3517)]
> [New Thread 0x7fffeedf2700 (LWP 3518)]
> [New Thread 0x7fffee5f1700 (LWP 3519)]
> [New Thread 0x7fffeddf0700 (LWP 3520)]
> [New Thread 0x7fffed5ef700 (LWP 3521)]
> % Device: AMD TONGA (DRM 3.9.0 / 4.10.4-1-ARCH, LLVM 3.9.1), 2046.3 MiB
> memory, max allocation 1432.4 MiB, driver  17.0.1
> 
> Thread 1 "minimal" received signal SIGSEGV, Segmentation fault.
> 0x72b9eb18 in
> llvm::SIInstrInfo::getInstSizeInBytes(llvm::MachineInstr const&) const ()
>from /usr/lib/libLLVM-3.9.so
> (gdb)
> 
> 

I need backtrace here (command bt).

> Also when I compile minimal.cl with 
> clang -x cl -target amdgcn-- -mcpu=tonga
> -Dcl_clang_storage_class_specifiers=1 -Xclang -mlink-bitcode-file -Xclang
> /usr/local/lib/clc/tonga-amdgcn--.bc -I/usr/local/include/clc -include
> /usr/local/include/clc/clc.h minimal.cl
> '+fp64-fp16-denormals' is not a recognized feature for this target (ignoring
> feature)
> '+fp64-fp16-denormals' is not a recognized feature for this target (ignoring
> feature)

Not really a problem, it's being ignored.

> minimal.cl:2:15: error: unsupported call to function get_global_id.3
> __kernel void myGEMM1(const int M, 
>   ^
> minimal.cl:2:15: error: unsupported call to function get_global_id.3

Could it be the same thing as bug 99856?

> clang-3.9:
> /home/miguel/Downloads/llvm-3.9.1.src/lib/Target/AMDGPU/SIInstrInfo.cpp:2428:
> void llvm::SIInstrInfo::legalizeOperands(llvm::MachineInstr&) const:
> Assertion `MBB.getParent()->getSubtarget().getGeneration() <
> SISubtarget::VOLCANIC_ISLANDS && "FIXME: Need to emit flat atomics here"'
> failed.

This should be fixed (worked around, to be precise) in LLVM 4.0.

> #0 0x7efe68ec1662 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
> /home/miguel/Downloads/llvm-3.9.1.src/lib/Support/Unix/Signals.inc:402:0
> 
> ...
> 
> I get errors.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Emil Velikov (2017-03-23 04:39:50)
> On 22 March 2017 at 20:10, Dylan Baker  wrote:
> 
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\

Sure, but if it's easier to get right (which I'm asserting it is), then meson
should pay off in the long run by needing less maintenance to remain "bug-free",
since fewer bugs will be introduced.

> Slightly off-topic - 3 days to write the build script for ~10 [nearly]
> identical libraries which do not do anything fancy, seems a lot.
> Which was the most time consuming part ?

Mostly talking with Matt about which patterns from autotools don't make sense to
port to meson. Also in those 3-4 days were a stab at mesa that made me realize
it was too big a of project for the first go, and picking a smaller, simpler
first project made sense. Honestly the about half of that time was spent reading
autotools documentation to figure out what some of the macros did, and then
reading meson bugs to figure out what the meson equivalent is. I have
familiarity with cmake, but this was the first major work with autotools I've
done. At this point working on Mesa the meson is just coming and I spend a lot
more time reading autotools documentation and asking Matt "What does X do, and
does it have side effects?"

> 
> I'm concerned that we would have to enforce the same time penalty onto
> dozens of developers unfamiliar with meson.

Eric (who as done a lot more autotools than me) said it took him 2 days to
become a more comfortable with meson than autotools, having written autotools
for 10 years. Asking Eric, Daniel Stone, or Peter Hutterer, who all have much
more autotools experience than me, would probably be more useful to answer that
question. I can say this, it took me significantly less time to become fluent
with meson than to become passable with cmake.

Dylan


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Ville Syrjälä]

On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
> Hi Shashank,
> 
> 
> On 23-03-2017 16:43, Sharma, Shashank wrote:
> > Regards
> >
> > Shashank
> >
> >
> > On 3/23/2017 6:33 PM, Jose Abreu wrote:
> >> Hi Shashank,
> >>
> >>
> >> On 23-03-2017 16:08, Sharma, Shashank wrote:
> >>> Regards
> >>>
> >>> Shashank
> >>>
> >>>
> >>> On 3/23/2017 5:57 PM, Jose Abreu wrote:
>  Hi Ville,
> 
> 
>  On 23-03-2017 15:45, Ville Syrjälä wrote:
> > On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
> >> Hi Shashank,
> >>
> >>
> >> On 23-03-2017 15:14, Shashank Sharma wrote:
> >>> HDMI 1.4b support the CEA video modes as per range of
> >>> CEA-861-D (VIC 1-64).
> >>> For any other mode, the VIC filed in AVI infoframes should
> >>> be 0.
> >>> HDMI 2.0 sinks, support video modes range as per CEA-861-F
> >>> spec, which is
> >>> extended to (VIC 1-107).
> >>>
> >>> This patch adds a bool input variable, which indicates if
> >>> the connected
> >>> sink is a HDMI 2.0 sink or not. This will make sure that we
> >>> don't pass a
> >>> HDMI 2.0 VIC to a HDMI 1.4 sink.
> >>>
> >>> This patch touches all drm drivers, who are callers of this
> >>> function
> >>> drm_hdmi_avi_infoframe_from_display_mode but to make sure
> >>> there is
> >>> no change in current behavior, is_hdmi2 is kept as false.
> >>>
> >>> In case of I915 driver, this patch checks the
> >>> connector->display_info
> >>> to check if the connected display is HDMI 2.0.
> >>>
> >>> Cc: Ville Syrjala 
> >>> Cc: Jose Abreu 
> >>> Cc: Andrzej Hajda 
> >>> Cc: Alex Deucher 
> >>> Cc: Daniel Vetter 
> >>>
> >>> PS: This patch touches a few lines in few files, which were
> >>> already above 80 char, so checkpatch gives 80 char warning
> >>> again.
> >>> - gpu/drm/omapdrm/omap_encoder.c
> >>> - gpu/drm/i915/intel_sdvo.c
> >>>
> >>> Signed-off-by: Shashank Sharma 
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
> >>>drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
> >>>drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
> >>>drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
> >>>drivers/gpu/drm/bridge/sii902x.c  |  2 +-
> >>>drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
> >>>drivers/gpu/drm/drm_edid.c| 12
> >>> +++-
> >>>drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
> >>>drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
> >>>drivers/gpu/drm/i915/intel_hdmi.c |  5 -
> >>>drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
> >>>drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
> >>>drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
> >>>drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
> >>>drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
> >>>drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
> >>>drivers/gpu/drm/tegra/hdmi.c  |  2 +-
> >>>drivers/gpu/drm/tegra/sor.c   |  2 +-
> >>>drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
> >>>drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
> >>>include/drm/drm_edid.h|  3 ++-
> >>>21 files changed, 38 insertions(+), 21 deletions(-)
> >>>
> >> [snip]
> >>
> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> index af93f7a..5ff2886 100644
> >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct
> >>> dw_hdmi *hdmi, struct drm_display_mode *mode)
> >>>u8 val;
> >>>  /* Initialise info frame from DRM mode */
> >>> -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> >>> +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode,
> >>> false);
> >>>  if (hdmi->hdmi_data.enc_out_format == YCBCR444)
> >>>frame.colorspace = HDMI_COLORSPACE_YUV444;
> >>>
> >> dw-hdmi controller has full support for HDMI 2.0 features.
> >> It all
> >> depends on the platform it is integrated.
> >>
> >> I think adding a parameter to
> >> drm_hdmi_avi_infoframe_from_display_mode is not the best idea
> >> because of this case: A bridge can have support for HDMI 2.0
> >> features but the platform may limit this support. I guess it
> >> can
> >> happen in other drivers too.
> > Your driver is in full control of what gets passed here. So I
> > don't see
> > why that would be a problem.
> >
> > Also this doesn't really have anything to do with the
> > capabilities of
> > the source. All we want to make sure is that we d

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Ville Syrjälä]

On Thu, Mar 23, 2017 at 06:31:33PM +0200, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 3/23/2017 5:52 PM, Jose Abreu wrote:
> > Hi Ville,
> >
> >
> > On 23-03-2017 15:36, Ville Syrjälä wrote:
> >> On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
> >>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 
> >>> 1-64).
> >>> For any other mode, the VIC filed in AVI infoframes should be 0.
> >>> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> >>> extended to (VIC 1-107).
> >>>
> >>> This patch adds a bool input variable, which indicates if the connected
> >>> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> >>> HDMI 2.0 VIC to a HDMI 1.4 sink.
> >> The spec is unfortunately vague when it comes to the CEA-861-F VIC
> >> transmission when there is a corresponding HDMI VIC for the same mode.
> >> I'm not sure if it's telling us to set both or just one depending on
> >> whether we're transmitting 3D video or not. Or at least I can't parse
> >> that information from the spec. Anyone have a better crystal ball
> >> in their possession?
> >>
> > I've been working in HDMI receivers and this is what I've got in
> > a comment:
> >
> > 1282
> > /*
> >
> > 1283  * Update current VIC: When transmitting any
> > extended video format
> > 1284  * indicated through use of the HDMI_VIC field in
> > the HDMI Vendor
> > 1285  * Specific InfoFrame or any other format which is
> > not described in
> > 1286  * the above cases, an HDMI Source shall set the AVI
> > InfoFrame VIC
> > 1287  * field to
> > zero.
> >
> > 1288  */
> >
> > This was directly taken from the spec, can't remember exactly
> > were though.
> >
> > So, the VIC in AVIIF must be set to 0 and the HDMI_VIC field in
> > VSIF shall be set to the HDMI 4k VIC.
> >
> > Best regards,
> > Jose Miguel Abreu
> Even my understanding of the two specs seems similar
> If its a HDMI 1.4b monitor, 2D mode
>  - VIC field in AVI_IF should be set to appropriate VIC [if VIC is 
> not listed in CEA-861-D (VIC 1-64), make VIC=0]
> If its a HDMI 1.4b monitor, 3D mode
>  - VIC field in AVI_IF should be set to appropriate VIC, in 
> conjunction with 3D_structure field in HDMI VSIF
> If its a HDMI 2.0 monitor, 2D mode
>  - VIC filed in the AVI_IF should be set to appropriate VIC (1-107)
> If its a HDMI 2.0 monitor, 3D mode
>  - VIC field in AVI_IF should be set to appropriate VIC, in 
> conjunction with 3D_structure field in HDMI VSIF

You're overlooking the HDMI VIC entirely in that list.

OK, so our code even refuses to send both 3D stuff and HDMI VIC
at the same time. I presume this was an illegal combination in HDMI 1.4.
And since there was no overlap between the CEA VICs and HDMI VICs this
was all that we needed.

But now that there is overlap, I think we'll need to set CEA VIC=0
whenever HDMI VIC!=0. Or at least that's my strictest interpretation of
the spec. I wish they would have stated this stuff more explicitly.

So either we need to pass the AVI IF to
drm_hdmi_vendor_infoframe_from_display_mode() and have it clear the AVI
IF VIC if HDMI VIC is specified, or we need to pass the HDMI IF to
drm_hdmi_avi_infoframe_from_display_mode() and have it not set the AVI
IF VIC if HDMI VIC is specified. Or we need to make the caller handle
this, which would probably lead to more bugs.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Zachary Michaels]

>
> No, I've requested reverting the patch for now because it causes an
> obviously and rather severe problem. If you guys can quickly find how to
> fix it feel free to use that instead.
>
> My mistake! That makes sense. Thanks again.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Sharma, Shashank]

Regards

Shashank


On 3/23/2017 6:33 PM, Jose Abreu wrote:

Hi Shashank,


On 23-03-2017 16:08, Sharma, Shashank wrote:

Regards

Shashank


On 3/23/2017 5:57 PM, Jose Abreu wrote:

Hi Ville,


On 23-03-2017 15:45, Ville Syrjälä wrote:

On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:

Hi Shashank,


On 23-03-2017 15:14, Shashank Sharma wrote:

HDMI 1.4b support the CEA video modes as per range of
CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should
be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F
spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if
the connected
sink is a HDMI 2.0 sink or not. This will make sure that we
don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this
function
drm_hdmi_avi_infoframe_from_display_mode but to make sure
there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the
connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning
again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
   drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
   drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
   drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
   drivers/gpu/drm/bridge/sii902x.c  |  2 +-
   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
   drivers/gpu/drm/drm_edid.c| 12 +++-
   drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
   drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
   drivers/gpu/drm/i915/intel_hdmi.c |  5 -
   drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
   drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
   drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
   drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
   drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
   drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
   drivers/gpu/drm/tegra/hdmi.c  |  2 +-
   drivers/gpu/drm/tegra/sor.c   |  2 +-
   drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
   drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
   include/drm/drm_edid.h|  3 ++-
   21 files changed, 38 insertions(+), 21 deletions(-)


[snip]


diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index af93f7a..5ff2886 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct
dw_hdmi *hdmi, struct drm_display_mode *mode)
   u8 val;
 /* Initialise info frame from DRM mode */
-drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+drm_hdmi_avi_infoframe_from_display_mode(&frame, mode,
false);
 if (hdmi->hdmi_data.enc_out_format == YCBCR444)
   frame.colorspace = HDMI_COLORSPACE_YUV444;


dw-hdmi controller has full support for HDMI 2.0 features.
It all
depends on the platform it is integrated.

I think adding a parameter to
drm_hdmi_avi_infoframe_from_display_mode is not the best idea
because of this case: A bridge can have support for HDMI 2.0
features but the platform may limit this support. I guess it
can
happen in other drivers too.

Your driver is in full control of what gets passed here. So I
don't see
why that would be a problem.

Also this doesn't really have anything to do with the
capabilities of
the source. All we want to make sure is that we don't send a
VIC the
sink will not understand.


But the driver is not aware of the platform limitations, its
generic to the controller only. We could add a field in pdata
which tells if platform is HDMI 2.0+ but what about other bridge
drivers or HDMI drivers? They will have to replicate the same
thing also.

Best regards,
Jose Miguel Abreu

I think the driver would be aware of the platform's
capabilities, isn't it ?
Else how would it even decide which mode to allow, and which to
reject ?

The DRM core propagates the mode to the chain of configuration
before reaching the bridge driver also, there is a callback
supplied by pdata (mode_valid) which can check if the mode is
valid. (see
https://cgit.freedesktop.org/~airlied/linux/tree/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c?h=drm-next#n1740)

Best regards,
Jose Miguel Abreu



Regards
Shashank
Please correct me if my understanding is not right, but drivers call 
mode_valid() to prune/reject modes which they cant support.
and they call drm_set_infoframe_from_videomode() function, when they are 
going ahead to the modeset with a mode.
Why would a driver choose to do a modeset, which it could not support 
(shouldn't 

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Sharma, Shashank]

Regards

Shashank


On 3/23/2017 5:28 PM, Ilia Mirkin wrote:

On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank
 wrote:

On 3/23/2017 5:17 PM, Ilia Mirkin wrote:

On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
 wrote:

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC
1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

Should this patch come before the patch which recognizes VICs 65+?
Otherwise if only the first patch is applied but not this one, you
could end up with the bad scenario. (As can happen in bisections, for
example.)

I kindof agree, this could be the case, but also, for the correct
functionality, you should have the whole series
together.

OK, so ... I have a bug in my filesystem, and I'm bisecting it and
rebooting my box at each step. I happen to hit this commit in my
bisect and my monitor doesn't turn on? Seems unpleasant, no?
Cant say no :-), will happily change the order if this makes you feel 
better.


Regards
Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Sharma, Shashank]

Regards

Shashank


On 3/23/2017 5:52 PM, Jose Abreu wrote:

Hi Ville,


On 23-03-2017 15:36, Ville Syrjälä wrote:

On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

The spec is unfortunately vague when it comes to the CEA-861-F VIC
transmission when there is a corresponding HDMI VIC for the same mode.
I'm not sure if it's telling us to set both or just one depending on
whether we're transmitting 3D video or not. Or at least I can't parse
that information from the spec. Anyone have a better crystal ball
in their possession?


I've been working in HDMI receivers and this is what I've got in
a comment:

1282
/*

1283  * Update current VIC: When transmitting any
extended video format
1284  * indicated through use of the HDMI_VIC field in
the HDMI Vendor
1285  * Specific InfoFrame or any other format which is
not described in
1286  * the above cases, an HDMI Source shall set the AVI
InfoFrame VIC
1287  * field to
zero.

1288  */

This was directly taken from the spec, can't remember exactly
were though.

So, the VIC in AVIIF must be set to 0 and the HDMI_VIC field in
VSIF shall be set to the HDMI 4k VIC.

Best regards,
Jose Miguel Abreu

Even my understanding of the two specs seems similar
If its a HDMI 1.4b monitor, 2D mode
- VIC field in AVI_IF should be set to appropriate VIC [if VIC is 
not listed in CEA-861-D (VIC 1-64), make VIC=0]

If its a HDMI 1.4b monitor, 3D mode
- VIC field in AVI_IF should be set to appropriate VIC, in 
conjunction with 3D_structure field in HDMI VSIF

If its a HDMI 2.0 monitor, 2D mode
- VIC filed in the AVI_IF should be set to appropriate VIC (1-107)
If its a HDMI 2.0 monitor, 3D mode
- VIC field in AVI_IF should be set to appropriate VIC, in 
conjunction with 3D_structure field in HDMI VSIF


Regards
Shashank

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Sharma, Shashank]

Regards

Shashank


On 3/23/2017 5:57 PM, Jose Abreu wrote:

Hi Ville,


On 23-03-2017 15:45, Ville Syrjälä wrote:

On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:

Hi Shashank,


On 23-03-2017 15:14, Shashank Sharma wrote:

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
  drivers/gpu/drm/drm_edid.c| 12 +++-
  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
  drivers/gpu/drm/tegra/sor.c   |  2 +-
  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
  include/drm/drm_edid.h|  3 ++-
  21 files changed, 38 insertions(+), 21 deletions(-)


[snip]


diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index af93f7a..5ff2886 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
u8 val;
  
  	/* Initialise info frame from DRM mode */

-   drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
  
  	if (hdmi->hdmi_data.enc_out_format == YCBCR444)

frame.colorspace = HDMI_COLORSPACE_YUV444;


dw-hdmi controller has full support for HDMI 2.0 features. It all
depends on the platform it is integrated.

I think adding a parameter to
drm_hdmi_avi_infoframe_from_display_mode is not the best idea
because of this case: A bridge can have support for HDMI 2.0
features but the platform may limit this support. I guess it can
happen in other drivers too.

Your driver is in full control of what gets passed here. So I don't see
why that would be a problem.

Also this doesn't really have anything to do with the capabilities of
the source. All we want to make sure is that we don't send a VIC the
sink will not understand.


But the driver is not aware of the platform limitations, its
generic to the controller only. We could add a field in pdata
which tells if platform is HDMI 2.0+ but what about other bridge
drivers or HDMI drivers? They will have to replicate the same
thing also.

Best regards,
Jose Miguel Abreu
I think the driver would be aware of the platform's capabilities, isn't 
it ?

Else how would it even decide which mode to allow, and which to reject ?

Regards
Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Christian König]

Understood -- I thought you might not want to take this patch, but I 
went ahead and sent it out because Christian requested it, and it 
seems like he doesn't think VRAM bos should ever evict back to VRAM at 
all?
No, I've requested reverting the patch for now because it causes an 
obviously and rather severe problem. If you guys can quickly find how to 
fix it feel free to use that instead.


Is my understanding of the original commit correct in that it tries to 
rewrite the eviction placements of CPU accessible bos so that they are 
either size zero (fpfn and lpfn = start of inaccessible VRAM) or they 
are in inaccessible VRAM (fpfn = start of inaccessible VRAM and lpfn = 0)?

That for example could work as well, but see below.

if these sorts of evictions are desirable, would it make more sense to 
treat CPU inaccessible/accessible VRAM as distinct entities with their 
own lrus?
Actually I'm pretty sure that it isn't desirable. See the evict function 
doesn't know if we try to evict BOs because we need CPU accessible VRAM 
or if we just run out of VRAM.


This code only makes sense when we need to move different BOs into the 
CPU accessible part round robin because they are accessed by the CPU, 
but then it is actually better to move them to GTT sooner or later.


Regards,
Christian.

Am 23.03.2017 um 16:31 schrieb Zachary Michaels:


Was userspace maybe performing concurrent CPU access to the BOs in
question?


As far as I know Julien has demonstrated that this is not the case.

I hope we can find a better solution.


Understood -- I thought you might not want to take this patch, but I 
went ahead and sent it out because Christian requested it, and it 
seems like he doesn't think VRAM bos should ever evict back to VRAM at 
all?


Is my understanding of the original commit correct in that it tries to 
rewrite the eviction placements of CPU accessible bos so that they are 
either size zero (fpfn and lpfn = start of inaccessible VRAM) or they 
are in inaccessible VRAM (fpfn = start of inaccessible VRAM and lpfn = 0)?


In this case, to me it seems that the simplest fix would be to iterate 
using i to rewrite all the VRAM placements instead of just the first 
one (rbo->placements[i] instead of rbo->placements[0]). In the case 
where RADEON_GEM_NO_CPU_ACCESS is set, the second placement will be in 
CPU accessible VRAM, and that doesn't seem correct to me as there is 
no longer any sort of ordering for evictions. (Unfortunately I'm not 
currently in a position to test whether this fixes our issue.) Sorry, 
I meant to make a note of this originally.


Also, I don't claim to understand this code well enough, but I wonder: 
if these sorts of evictions are desirable, would it make more sense to 
treat CPU inaccessible/accessible VRAM as distinct entities with their 
own lrus?


I should also note that we are experiencing another issue where the 
kernel locks up in similar circumstances. As Julien noted, we get no 
output, and the watchdogs don't seem to work. It may be the case that 
Xorg and our process are calling ttm_bo_mem_force_space concurrently, 
but I don't think we have enough information yet to say for 
sure. Reverting this commit does not fix that issue. I have some small 
amount of evidence indicating that bos flagged for CPU access are 
getting placed in CPU inaccessible memory. Could that cause this sort 
of kernel lockup?


Thanks for your help.


___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

[Sagalovitch, Serguei]

Christian,

- Are we going to support resizing BAR when kernel 
modesetting  is not enabled and we are running in console 
under VBIOS control (VESA/VGA)? 

- Should we restore PCI configuration if amdgpu
will be unloaded?

- In function amdgpu_resize_bar0():
  If resizing for "max" size failed should we try other 
sizes? What do you think?


Sincerely yours,
Serguei Sagalovitch


From: amd-gfx  on behalf of Zhang, Jerry 

Sent: March 15, 2017 10:41 PM
To: Alex Deucher
Cc: Zhou, David(ChunMing); Ayyappa Ch; linux-...@vger.kernel.org; 
linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; 
platform-driver-...@vger.kernel.org; Christian König; helg...@kernel.org; 
amd-...@lists.freedesktop.org
Subject: RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
    
Thanks for your info.
I see.

Regards,
Jerry (Junwei Zhang)

Linux Base Graphics
SRDC Software Development
_


> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: Thursday, March 16, 2017 10:25
> To: Zhang, Jerry
> Cc: Christian König; Zhou, David(ChunMing); Ayyappa Ch; linux-
> p...@vger.kernel.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> helg...@kernel.org; amd-...@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> 
> On Wed, Mar 15, 2017 at 10:19 PM, Zhang, Jerry  wrote:
> >> -Original Message-
> >> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >> Behalf Of Christian K?nig
> >> Sent: Wednesday, March 15, 2017 17:29
> >> To: Zhou, David(ChunMing); Ayyappa Ch
> >> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; amd-
> >> g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> >> helg...@kernel.org; dri-devel@lists.freedesktop.org
> >> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> >>
> >> Yes, exactly that.
> >
> > (I'm not familiar with PCI too much.)
> > Is there any restrict for PCI device?
> > I'm concerning if any PCI couldn't support it on some motherboard.
> 
> It depends on the PCI root bridge.  This patch set only implements support for
> AMD root bridges.  Intel and other vendors would need similar code.
> 
> Alex
> 
> >
> >>
> >> Christian.
> >>
> >> Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing):
> >> > Does that means we don't need invisible vram later?
> >> >
> >> > David
> >> >
> >> > -Original Message-
> >> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >> > Behalf Of Christian K?nig
> >> > Sent: Wednesday, March 15, 2017 3:38 PM
> >> > To: Ayyappa Ch 
> >> > Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
> >> > amd-...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> >> > helg...@kernel.org; dri-devel@lists.freedesktop.org
> >> > Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> >> >
> >> > Carizzo is an APU and resizing BARs isn't needed nor supported there.
> >> > The CPU can access the full stolen VRAM directly on that hardware.
> >> >
> >> > As far as I know ASICs with support for this are Tonga, Fiji and all 
> >> > Polaris
> variants.
> >> >
> >> > Christian.
> >> >
> >> > Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> >> >> Is it possible on Carrizo asics? Or only supports on newer asics?
> >> >>
> >> >> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
> >> >>  wrote:
> >> >>> From: Christian König 
> >> >>>
> >> >>> Try to resize BAR0 to let CPU access all of VRAM.
> >> >>>
> >> >>> Signed-off-by: Christian König 
> >> >>> ---
> >> >>>    drivers/gpu/drm/amd/amdgpu/amdgpu.h    |  1 +
> >> >>>    drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
> >> +
> >> >>>    drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +---
> >> >>>    drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +---
> >> >>>    4 files changed, 40 insertions(+), 6 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> index 3b81ded..905ded9 100644
> >> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
> >> amdgpu_device *adev, struct ttm_tt *ttm,
> >> >>>    struct ttm_mem_reg *mem);
> >> >>>    void amdgpu_vram_location(struct amdgpu_device *adev, struct
> >> amdgpu_mc *mc, u64 base);
> >> >>>    void amdgpu_gtt_location(struct amdgpu_device *adev, struct
> >> >>> amdgpu_mc *mc);
> >> >>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> >> >>>    void amdgpu_ttm_set_active_vram_size(struct amdgpu_device
> >> >>> *adev,
> >> u64 size);
> >> >>>    int amdgpu_ttm_init(struct amdgpu_device *adev);
> >> >>>    void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
> >> >>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> >>> b/drivers/gpu

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

[Christian König]

- Are we going to support resizing BAR when kernel
modesetting  is not enabled and we are running in console
under VBIOS control (VESA/VGA)?
No, initial I've tried to resize the PCI BAR during probing without the 
help of the driver at all. But the VESA/EFI/VBIOS don't seem to be able 
to handle addresses above 4GB for some reason.


So the approach is to let the driver kick the VESA/EFI drivers out and 
then resize when we know that nobody is accessing the BAR.


That's the only approach I've found without either blacklisting VESA/EFI 
drivers or crashing the system during the resize.



- Should we restore PCI configuration if amdgpu
will be unloaded?

Yeah, thought about the as well. I'm just not sure how to do it.

There is a lot of stuff we need to save and reset when the driver 
unloads for not much gain.



- In function amdgpu_resize_bar0():
   If resizing for "max" size failed should we try other
sizes? What do you think?
Probably not worth it. If we get the BAR moved to a 64bit address we 
should have enough address space in almost all cases, so setting it to 
the maximum should succeed.


But I think we could add another parameter to allow limiting the resized 
size for all corner cases and for testing.


Regards,
Christian.

Am 23.03.2017 um 15:30 schrieb Sagalovitch, Serguei:

Christian,

- Are we going to support resizing BAR when kernel
modesetting  is not enabled and we are running in console
under VBIOS control (VESA/VGA)?

- Should we restore PCI configuration if amdgpu
will be unloaded?

- In function amdgpu_resize_bar0():
   If resizing for "max" size failed should we try other
sizes? What do you think?


Sincerely yours,
Serguei Sagalovitch


From: amd-gfx  on behalf of Zhang, Jerry 

Sent: March 15, 2017 10:41 PM
To: Alex Deucher
Cc: Zhou, David(ChunMing); Ayyappa Ch; linux-...@vger.kernel.org; 
linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; 
platform-driver-...@vger.kernel.org; Christian König; helg...@kernel.org; 
amd-...@lists.freedesktop.org
Subject: RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
 
Thanks for your info.

I see.

Regards,
Jerry (Junwei Zhang)

Linux Base Graphics
SRDC Software Development
_



-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Thursday, March 16, 2017 10:25
To: Zhang, Jerry
Cc: Christian König; Zhou, David(ChunMing); Ayyappa Ch; linux-
p...@vger.kernel.org; linux-ker...@vger.kernel.org; dri-
de...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
helg...@kernel.org; amd-...@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

On Wed, Mar 15, 2017 at 10:19 PM, Zhang, Jerry  wrote:

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
Behalf Of Christian K?nig
Sent: Wednesday, March 15, 2017 17:29
To: Zhou, David(ChunMing); Ayyappa Ch
Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; amd-
g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
helg...@kernel.org; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

Yes, exactly that.

(I'm not familiar with PCI too much.)
Is there any restrict for PCI device?
I'm concerning if any PCI couldn't support it on some motherboard.

It depends on the PCI root bridge.  This patch set only implements support for
AMD root bridges.  Intel and other vendors would need similar code.

Alex


Christian.

Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing):

Does that means we don't need invisible vram later?

David

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
Behalf Of Christian K?nig
Sent: Wednesday, March 15, 2017 3:38 PM
To: Ayyappa Ch 
Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
amd-...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
helg...@kernel.org; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

Carizzo is an APU and resizing BARs isn't needed nor supported there.
The CPU can access the full stolen VRAM directly on that hardware.

As far as I know ASICs with support for this are Tonga, Fiji and all Polaris

variants.

Christian.

Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:

Is it possible on Carrizo asics? Or only supports on newer asics?

On Mon, Mar 13, 2017 at 6:11 PM, Christian König
 wrote:

From: Christian König 

Try to resize BAR0 to let CPU access all of VRAM.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29

+

 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +---
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +---
 4 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..90

[Bug 69728] Radeon Redwood (5670) GPU Lockup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=69728

--- Comment #12 from pablow.1...@gmail.com ---
(In reply to Vedran Miletić from comment #11)
> Is this still an issue?

Hi! I no longer have that video card, so no idea if it's still an issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-fixes-2017-03-23:
One fbdev regression fix from Michel

Cheers, Daniel


The following changes since commit 97da3854c526d3a6ee05c849c96e48d21527606c:

  Linux 4.11-rc3 (2017-03-19 19:09:39 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-03-23

for you to fetch changes up to 12ffed96d4369f086261ba2ee734fa8c932d7f55:

  drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again 
(2017-03-23 15:12:07 +0100)


One fbdev regression fix from Michel


Michel Dänzer (1):
  drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

 drivers/gpu/drm/drm_fb_helper.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100289

--- Comment #4 from omegap...@startmail.com ---
Just 'Invalid argument' currently.

I just did 10 tests turning the monitor off for just over 30 seconds, and on
turning it back on, the display layout did not break (but I got the usual flip
queue messages):

==

tail -F /var/log/Xorg.0.log | grep -iE 'flip|allocate'

[181332.656] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[181356.321] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[181356.742] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[181357.947] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840
[181387.340] (II) RADEON(0): Allocate new frame buffer 5760x1200 stride 5760
[201695.702] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[201696.734] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840
[201722.513] (II) RADEON(0): Allocate new frame buffer 5760x1200 stride 5760
[220260.080] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253009.764] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253022.375] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253034.800] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253060.151] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253109.552] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253109.561] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253153.533] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253203.721] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253204.176] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253251.989] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253296.426] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253359.934] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253360.370] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253413.594] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253508.625] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253508.630] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument
[253509.047] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid
argument

==

This shows a few 'normal' failures from yesterday earlier on. When I came back
from work and turned it on (so hours off), nothing broke... so it looks like
something has changed or there is an unknown trigger.

I can sit on this until it happens again.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Ville Syrjälä]

On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
> Hi Shashank,
> 
> 
> On 23-03-2017 15:14, Shashank Sharma wrote:
> > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> > For any other mode, the VIC filed in AVI infoframes should be 0.
> > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> > extended to (VIC 1-107).
> >
> > This patch adds a bool input variable, which indicates if the connected
> > sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> > HDMI 2.0 VIC to a HDMI 1.4 sink.
> >
> > This patch touches all drm drivers, who are callers of this function
> > drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> > no change in current behavior, is_hdmi2 is kept as false.
> >
> > In case of I915 driver, this patch checks the connector->display_info
> > to check if the connected display is HDMI 2.0.
> >
> > Cc: Ville Syrjala 
> > Cc: Jose Abreu 
> > Cc: Andrzej Hajda 
> > Cc: Alex Deucher 
> > Cc: Daniel Vetter 
> >
> > PS: This patch touches a few lines in few files, which were
> > already above 80 char, so checkpatch gives 80 char warning again.
> > - gpu/drm/omapdrm/omap_encoder.c
> > - gpu/drm/i915/intel_sdvo.c
> >
> > Signed-off-by: Shashank Sharma 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
> >  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
> >  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
> >  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
> >  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
> >  drivers/gpu/drm/drm_edid.c| 12 +++-
> >  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
> >  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
> >  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
> >  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
> >  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
> >  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
> >  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
> >  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
> >  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
> >  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
> >  drivers/gpu/drm/tegra/sor.c   |  2 +-
> >  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
> >  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
> >  include/drm/drm_edid.h|  3 ++-
> >  21 files changed, 38 insertions(+), 21 deletions(-)
> >
> 
> [snip]
> 
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index af93f7a..5ff2886 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, 
> > struct drm_display_mode *mode)
> > u8 val;
> >  
> > /* Initialise info frame from DRM mode */
> > -   drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> > +   drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> >  
> > if (hdmi->hdmi_data.enc_out_format == YCBCR444)
> > frame.colorspace = HDMI_COLORSPACE_YUV444;
> >
> 
> dw-hdmi controller has full support for HDMI 2.0 features. It all
> depends on the platform it is integrated.
> 
> I think adding a parameter to
> drm_hdmi_avi_infoframe_from_display_mode is not the best idea
> because of this case: A bridge can have support for HDMI 2.0
> features but the platform may limit this support. I guess it can
> happen in other drivers too.

Your driver is in full control of what gets passed here. So I don't see
why that would be a problem.

Also this doesn't really have anything to do with the capabilities of
the source. All we want to make sure is that we don't send a VIC the
sink will not understand.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Ville Syrjälä]

On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
> 
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.

The spec is unfortunately vague when it comes to the CEA-861-F VIC
transmission when there is a corresponding HDMI VIC for the same mode.
I'm not sure if it's telling us to set both or just one depending on
whether we're transmitting 3D video or not. Or at least I can't parse
that information from the spec. Anyone have a better crystal ball
in their possession?

> 
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
> 
> In case of I915 driver, this patch checks the connector->display_info
> to check if the connected display is HDMI 2.0.
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 
> 
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>  drivers/gpu/drm/drm_edid.c| 12 +++-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>  drivers/gpu/drm/tegra/sor.c   |  2 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>  include/drm/drm_edid.h|  3 ++-
>  21 files changed, 38 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index d4452d8..ab7a399 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
> *encoder,
>   dce_v10_0_audio_write_sad_regs(encoder);
>   dce_v10_0_audio_write_latency_fields(encoder, mode);
>  
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>   if (err < 0) {
>   DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
>   return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 5b24e89..3c5fd83 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
> *encoder,
>   dce_v11_0_audio_write_sad_regs(encoder);
>   dce_v11_0_audio_write_latency_fields(encoder, mode);
>  
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>   if (err < 0) {
>   DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
>   return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index d2590d7..c564dca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
> *encoder,
>   dce_v8_0_audio_write_sad_regs(encoder);
>   dce_v8_0_audio_write_latency_fields(encoder, mode);
>  
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>   if (err < 0) {
>   DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
>   return;
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index a2a8236..f9b77b8 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/d

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Zachary Michaels]

>
> Was userspace maybe performing concurrent CPU access to the BOs in
> question?


As far as I know Julien has demonstrated that this is not the case.


> I hope we can find a better solution.


Understood -- I thought you might not want to take this patch, but I went
ahead and sent it out because Christian requested it, and it seems like he
doesn't think VRAM bos should ever evict back to VRAM at all?

Is my understanding of the original commit correct in that it tries to
rewrite the eviction placements of CPU accessible bos so that they are
either size zero (fpfn and lpfn = start of inaccessible VRAM) or they are
in inaccessible VRAM (fpfn = start of inaccessible VRAM and lpfn = 0)?

In this case, to me it seems that the simplest fix would be to iterate
using i to rewrite all the VRAM placements instead of just the first one
(rbo->placements[i] instead of rbo->placements[0]). In the case where
RADEON_GEM_NO_CPU_ACCESS
is set, the second placement will be in CPU accessible VRAM, and that
doesn't seem correct to me as there is no longer any sort of ordering for
evictions. (Unfortunately I'm not currently in a position to test whether
this fixes our issue.) Sorry, I meant to make a note of this originally.

Also, I don't claim to understand this code well enough, but I wonder: if
these sorts of evictions are desirable, would it make more sense to treat
CPU inaccessible/accessible VRAM as distinct entities with their own lrus?

I should also note that we are experiencing another issue where the kernel
locks up in similar circumstances. As Julien noted, we get no output, and
the watchdogs don't seem to work. It may be the case that Xorg and our
process are calling ttm_bo_mem_force_space concurrently, but I don't think
we have enough information yet to say for sure. Reverting this commit does
not fix that issue. I have some small amount of evidence indicating that
bos flagged for CPU access are getting placed in CPU inaccessible memory.
Could that cause this sort of kernel lockup?

Thanks for your help.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100304] [bisected] Kernel oops on startup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100304

--- Comment #6 from Mike Lothian  ---
Thanks, that's working great for me

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Ilia Mirkin]

On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank
 wrote:
> On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
>>
>> On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
>>  wrote:
>>>
>>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC
>>> 1-64).
>>> For any other mode, the VIC filed in AVI infoframes should be 0.
>>> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
>>> extended to (VIC 1-107).
>>>
>>> This patch adds a bool input variable, which indicates if the connected
>>> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
>>> HDMI 2.0 VIC to a HDMI 1.4 sink.
>>
>> Should this patch come before the patch which recognizes VICs 65+?
>> Otherwise if only the first patch is applied but not this one, you
>> could end up with the bad scenario. (As can happen in bisections, for
>> example.)
>
> I kindof agree, this could be the case, but also, for the correct
> functionality, you should have the whole series
> together.

OK, so ... I have a bug in my filesystem, and I'm bisecting it and
rebooting my box at each step. I happen to hit this commit in my
bisect and my monitor doesn't turn on? Seems unpleasant, no?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

[Sharma, Shashank]

You guys might wanna use this series, to solve this problem.

https://patchwork.freedesktop.org/series/21773/

Patch 1: completes the CEA modes 1-107

Patch 2: Protects HDMI 1.4 monitors from HDMI 2.0 VICs


Regards
Shashank
On 3/23/2017 1:07 PM, Sharma, Shashank wrote:

Regards

Shashank


On 3/23/2017 10:11 AM, Andrzej Hajda wrote:

On 22.03.2017 18:35, Jose Abreu wrote:

This patch completes CEA table of video modes so that VIC 1-107
are now available. Use the HDMI 2.0+ flag to signal these are
modes for HDMI 2.0 onwards.

edid_cea_modes array is used in different contexts, simple extensions of
the array with modes not present in HDMI < 2.0 can result in different
behavior of drivers.
There should be put sentinels somewhere to limit table lookup to old
VICs if device/driver/receiver is not HDMI2.0 compliant.
The only situation I am aware of at the moment is infoframe generation
code. For TVs not supporting 4K modes but not HDMI 2.0 compatible, VIC
field in AVI infoframe should be 0 for 4K modes and vendor infoframe
should be generated with proper HDMI-VIC. With current infoframe helpers
and this patch it will not work this way.

Regards
Andrzej
I had a small discussion with Ville on this, and we were thinking on 
adding monitor info before
VIC calculation in match_cea_modes() function, so that it should give 
a VIC of 0 for HDMI 1.4 sinks

but appropriate VIC for HDMI 2.0 sink. Consider WIP.

- Shashank

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: dri-devel@lists.freedesktop.org
---
  drivers/gpu/drm/drm_edid.c | 258 
+

  1 file changed, 258 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fad3d44..90080368 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1001,6 +1001,264 @@ struct minimode {
 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
 DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
   .vrefresh = 100, .picture_aspect_ratio = 
HDMI_PICTURE_ASPECT_16_9, },

+/* 65 - 1280x720@24Hz */
+{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+   3080, 3300, 0, 720, 725, 730, 750, 0,
+   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_HDMI2),
+  .vrefresh = 24, .picture_aspect_ratio = 
HDMI_PICTURE_ASPECT_64_27, },

+/* 66 - 1280x720@25Hz */
+{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+   3740, 3960, 0, 720, 725, 730, 750, 0,
+   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_HDMI2),
+  .vrefresh = 25, .picture_aspect_ratio = 
HDMI_PICTURE_ASPECT_64_27, },

+/* 67 - 1280x720@30Hz */
+{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+   3080, 3300, 0, 720, 725, 730, 750, 0,
+   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_HDMI2),
+  .vrefresh = 30, .picture_aspect_ratio = 
HDMI_PICTURE_ASPECT_64_27, },

+/* 68 - 1280x720@50Hz */
+{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+   1760, 1980, 0, 720, 725, 730, 750, 0,
+   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_HDMI2),
+  .vrefresh = 50, .picture_aspect_ratio = 
HDMI_PICTURE_ASPECT_64_27, },

+/* 69 - 1280x720@60Hz */
+{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+   1430, 1650, 0, 720, 725, 730, 750, 0,
+   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_HDMI2),
+  .vrefresh = 60, .picture_aspect_ratio = 
HDMI_PICTURE_ASPECT_64_27, },

+/* 70 - 1280x720@100Hz */
+{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+   1760, 1980, 0, 720, 725, 730, 750, 0,
+   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_HDMI2),
+  .vrefresh = 100, .picture_aspect_ratio = 
HDMI_PICTURE_ASPECT_64_27, },

+/* 71 - 1280x720@120Hz */
+{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+   1430, 1650, 0, 720, 725, 730, 750, 0,
+   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_HDMI2),
+  .vrefresh = 120, .picture_aspect_ratio = 
HDMI_PICTURE_ASPECT_64_27, },

+/* 72 - 1920x1080@24Hz */
+{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+   2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_HDMI2),
+  .vrefresh = 24, .picture_aspect_ratio = 
HDMI_PICTURE_ASPECT_64_27, },

+/* 73 - 1920x1080@25Hz */
+{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_HDMI2),
+  .vrefresh = 25, .picture_aspect_ratio = 
HDMI_PICTURE_ASPECT_64_27, },

+/* 74 - 1920x1080@30Hz */
+{ DRM_MODE("1920x1080", 

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Sharma, Shashank]

Regards

Shashank


On 3/23/2017 5:17 PM, Ilia Mirkin wrote:

On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
 wrote:

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

Should this patch come before the patch which recognizes VICs 65+?
Otherwise if only the first patch is applied but not this one, you
could end up with the bad scenario. (As can happen in bisections, for
example.)
I kindof agree, this could be the case, but also, for the correct 
functionality, you should have the whole series

together.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
  drivers/gpu/drm/drm_edid.c| 12 +++-
  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
  drivers/gpu/drm/tegra/sor.c   |  2 +-
  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
  include/drm/drm_edid.h|  3 ++-
  21 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index d4452d8..ab7a399 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
 dce_v10_0_audio_write_sad_regs(encoder);
 dce_v10_0_audio_write_latency_fields(encoder, mode);

-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
 if (err < 0) {
 DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
 return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 5b24e89..3c5fd83 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
 dce_v11_0_audio_write_sad_regs(encoder);
 dce_v11_0_audio_write_latency_fields(encoder, mode);

-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
 if (err < 0) {
 DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
 return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index d2590d7..c564dca 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
*encoder,
 dce_v8_0_audio_write_sad_regs(encoder);
 dce_v8_0_audio_write_latency_fields(encoder, mode);

-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
 if (err < 0) {
 DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
 return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..f9b77b8 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_s

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Ilia Mirkin]

On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
 wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
>
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.

Should this patch come before the patch which recognizes VICs 65+?
Otherwise if only the first patch is applied but not this one, you
could end up with the bad scenario. (As can happen in bisections, for
example.)

>
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch checks the connector->display_info
> to check if the connected display is HDMI 2.0.
>
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>  drivers/gpu/drm/drm_edid.c| 12 +++-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>  drivers/gpu/drm/tegra/sor.c   |  2 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>  include/drm/drm_edid.h|  3 ++-
>  21 files changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index d4452d8..ab7a399 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
> *encoder,
> dce_v10_0_audio_write_sad_regs(encoder);
> dce_v10_0_audio_write_latency_fields(encoder, mode);
>
> -   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> +   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 5b24e89..3c5fd83 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
> *encoder,
> dce_v11_0_audio_write_sad_regs(encoder);
> dce_v11_0_audio_write_latency_fields(encoder, mode);
>
> -   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> +   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index d2590d7..c564dca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
> *encoder,
> dce_v8_0_audio_write_sad_regs(encoder);
> dce_v8_0_audio_write_latency_fields(encoder, mode);
>
> -   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> +   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index a2a8236..f9b77b8 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge 
> *bridg

Re: [RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

[Ville Syrjälä]

On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote:
> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
> flag which will signal userspace that this is a HDMI 2.0+ mode. It
> is expected that these new flags will not be exported to userspace
> unless client asks to.

W.r.t. the aspect ratio userspace story, there was some discussion
on #dri-devel recently about extending the xrandr protocol for 3d stereo
support. If that is going to happen then it might make sense to try
and get the aspect ratio stuff also included at the same time so
that we would only have to deal with one protocol bump.

> 
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  include/uapi/drm/drm_mode.h | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 8c67fc0..62e679c 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -89,6 +89,8 @@
>  #define DRM_MODE_PICTURE_ASPECT_NONE 0
>  #define DRM_MODE_PICTURE_ASPECT_4_3  1
>  #define DRM_MODE_PICTURE_ASPECT_16_9 2
> +#define DRM_MODE_PICTURE_ASPECT_64_273
> +#define DRM_MODE_PICTURE_ASPECT_256_135  4
>  
>  /* Aspect ratio flag bitmask (4 bits 22:19) */
>  #define DRM_MODE_FLAG_PIC_AR_MASK(0x0F<<19)
> @@ -98,6 +100,13 @@
>   (DRM_MODE_PICTURE_ASPECT_4_3<<19)
>  #define  DRM_MODE_FLAG_PIC_AR_16_9 \
>   (DRM_MODE_PICTURE_ASPECT_16_9<<19)
> +#define  DRM_MODE_FLAG_PIC_AR_64_27 \
> + (DRM_MODE_PICTURE_ASPECT_64_27<<19)
> +#define  DRM_MODE_FLAG_PIC_AR_256_135 \
> + (DRM_MODE_PICTURE_ASPECT_256_135<<19)
> +
> +/* HDMI 2.0+ mode flag: will only be set if client supports it */
> +#define DRM_MODE_FLAG_HDMI2  (1<<23)
>  
>  /* DPMS flags */
>  /* bit compatible with the xorg definitions. */
> -- 
> 1.9.1
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Shashank Sharma]

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
 drivers/gpu/drm/bridge/sii902x.c  |  2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
 drivers/gpu/drm/drm_edid.c| 12 +++-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c |  5 -
 drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
 drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
 drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
 drivers/gpu/drm/tegra/hdmi.c  |  2 +-
 drivers/gpu/drm/tegra/sor.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
 drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
 include/drm/drm_edid.h|  3 ++-
 21 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index d4452d8..ab7a399 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 5b24e89..3c5fd83 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index d2590d7..c564dca 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..f9b77b8 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge 
*bridge,
 
mutex_lock(&anx78xx->lock);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted_mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted_mode,
+  false);
if (err) {
DRM_ERROR("Failed to setup AVI infoframe: %d\n", err);
goto unlock;
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 

[PATCH v4 1/2] drm/edid: Complete CEA modedb(VIC 1-107)

[Shashank Sharma]

CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 

V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107

V3: Rebase on drm-tip, added R-B from Jose, Alex.
V4: Addressed review comments from Andrzej not to modify the
VIC filed for HDMI 1.4b sinks (by adding another patch).

Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 215 +
 1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e66397a..3b494c2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1001,6 +1001,221 @@ static const struct drm_display_mode edid_cea_modes[] = 
{
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080@60Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
+  2052, 22

vsps DT property (was: Re: [PATCH 10/22] drm: rcar-du: Expose the VSP1 compositor through KMS planes)

[Geert Uytterhoeven]

Hi Laurent,

On Mon, Sep 14, 2015 at 12:50 AM, Laurent Pinchart
 wrote:
> Signed-off-by: Laurent Pinchart 

> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c

> +int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
> +{
> +   struct rcar_du_device *rcdu = vsp->dev;
> +   struct platform_device *pdev;
> +   struct device_node *np;
> +   unsigned int i;
> +   int ret;
> +
> +   /* Find the VSP device and initialize it. */
> +   np = of_parse_phandle(rcdu->dev->of_node, "vsps", vsp->index);
> +   if (!np) {
> +   dev_err(rcdu->dev, "vsps node not found\n");
> +   return -ENXIO;
> +   }

Apparently the "vsps" DT property was never documented in
Documentation/devicetree/bindings/display/renesas,du.txt.

Can you please fix that? Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100304] [bisected] Kernel oops on startup

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100304

--- Comment #5 from Alex Deucher  ---
Created attachment 130399
  --> https://bugs.freedesktop.org/attachment.cgi?id=130399&action=edit
possible fix

This should fix the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

[Andrzej Hajda]

On 23.03.2017 12:35, Jose Abreu wrote:
> Hi Andrzej,
>
>
> On 23-03-2017 11:17, Andrzej Hajda wrote:
>> On 23.03.2017 12:04, Jose Abreu wrote:
>>> Hi Andrzej,
>>>
>>>
>>> Thanks for the feedback!
>>>
>>> On 23-03-2017 08:11, Andrzej Hajda wrote:
 On 22.03.2017 18:35, Jose Abreu wrote:
> This patch completes CEA table of video modes so that VIC 1-107
> are now available. Use the HDMI 2.0+ flag to signal these are
> modes for HDMI 2.0 onwards.
 edid_cea_modes array is used in different contexts, simple extensions of
 the array with modes not present in HDMI < 2.0 can result in different
 behavior of drivers.
 There should be put sentinels somewhere to limit table lookup to old
 VICs if device/driver/receiver is not HDMI2.0 compliant.
 The only situation I am aware of at the moment is infoframe generation
 code. For TVs not supporting 4K modes but not HDMI 2.0 compatible, VIC
 field in AVI infoframe should be 0 for 4K modes and vendor infoframe
 should be generated with proper HDMI-VIC. With current infoframe helpers
 and this patch it will not work this way.
>>> But this is what I do in patch 5/5 (see
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9640205_&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=c7Qf9lk2pdXRbmjFNPSsZsy7LKiZWrqGlE72r-OTA-M&s=37RkfhQjJpjdKmQniKnhZwb1vtwb6HXSxY2Y7HrNlp4&e=
>>>  ), unless drivers ask
>>> to I don't expose the new modes.
>> I do not see how it is related to infoframe generation. Look at body of
>> drm_hdmi_avi_infoframe_from_display_mode, it calls drm_match_cea_mode,
>> which looks for given mode in edid_cea_modes array.
> Yes but drm_hdmi_avi_infoframe_from_display_mode is called from
> driver context, so the mode bust be previously probed by the drm
> core, and it isn't if the hdmi2_allowed flag is not set so the
> mode will never reach the driver and the infoframe will never be
> built. And also if the receiver is not HDMI 2.0 compliant then
> the mode will not also be probed.
>
> But I see a flaw here: If the user specify manually the mode then
> it will be passed to driver which will try to match with CEA
> table. Is this the scenario you were thinking about? I think with
> the new DRM_MODE_FLAG_HDMI2 flag this will not happen, see this:
>
> - Modesetting X driver (for example) does not set HDMI 2 cap
> - As the flag is not set HDMI 2 modes will not be exposed to
> userspace
> - If the user specifies the mode the modesetting driver will
> not set HDMI 2 flag
> - As the flag is not set then
> drm_mode_equal_no_clocks_no_stereo will not match the mode

OK I see, HDMI2 flag in mode will distinguish between 4K modes in
HDMI1.4 and HDMI2.0, even if all other fields are the same.
For now it looks safe indeed in case of HDMI<2 devices.
I am not sure if this approach will not generate problems with drivers
supporting both HDMI2 and 4K modes, but this 'issue' is already raised
by Daniel.

Regards
Andrzej


>
> Of course this needs patches to modesetting X driver, which are
> not in this series. What do you think?
>
>> Anyway if there is or will be a patch which deals with it, it should be
>> applied before extending edid_cea_modes array, not after.
> Right, I will correct this :)
>
> Best regards,
> Jose Miguel Abreu
>
>>
>> Regards
>> Andrzej
>>
>>> Best regards,
>>> Jose Miguel Abreu
>>>
 Regards
 Andrzej
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_edid.c | 258 
> +
>  1 file changed, 258 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index fad3d44..90080368 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1001,6 +1001,264 @@ struct minimode {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720@24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
> +DRM_MODE_FLAG_HDMI2),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720@25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
> +DRM_MODE_FLAG_HDMI2),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720@30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 

[PATCH] drm/sti: fix GDP size to support up to UHD resolution

[Vincent Abriou]

On stih407-410 chip family the GDP layers are able to support up to UHD
resolution (3840 x 2160).

Signed-off-by: Vincent Abriou 
---
 drivers/gpu/drm/sti/sti_gdp.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index 86279f5..88f16cd 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -66,7 +66,9 @@ static struct gdp_format_to_str {
 #define GAM_GDP_ALPHARANGE_255  BIT(5)
 #define GAM_GDP_AGC_FULL_RANGE  0x00808080
 #define GAM_GDP_PPT_IGNORE  (BIT(1) | BIT(0))
-#define GAM_GDP_SIZE_MAX0x7FF
+
+#define GAM_GDP_SIZE_MAX_WIDTH  3840
+#define GAM_GDP_SIZE_MAX_HEIGHT 2160
 
 #define GDP_NODE_NB_BANK2
 #define GDP_NODE_PER_FIELD  2
@@ -632,8 +634,8 @@ static int sti_gdp_atomic_check(struct drm_plane *drm_plane,
/* src_x are in 16.16 format */
src_x = state->src_x >> 16;
src_y = state->src_y >> 16;
-   src_w = clamp_val(state->src_w >> 16, 0, GAM_GDP_SIZE_MAX);
-   src_h = clamp_val(state->src_h >> 16, 0, GAM_GDP_SIZE_MAX);
+   src_w = clamp_val(state->src_w >> 16, 0, GAM_GDP_SIZE_MAX_WIDTH);
+   src_h = clamp_val(state->src_h >> 16, 0, GAM_GDP_SIZE_MAX_HEIGHT);
 
format = sti_gdp_fourcc2format(fb->format->format);
if (format == -1) {
@@ -741,8 +743,8 @@ static void sti_gdp_atomic_update(struct drm_plane 
*drm_plane,
/* src_x are in 16.16 format */
src_x = state->src_x >> 16;
src_y = state->src_y >> 16;
-   src_w = clamp_val(state->src_w >> 16, 0, GAM_GDP_SIZE_MAX);
-   src_h = clamp_val(state->src_h >> 16, 0, GAM_GDP_SIZE_MAX);
+   src_w = clamp_val(state->src_w >> 16, 0, GAM_GDP_SIZE_MAX_WIDTH);
+   src_h = clamp_val(state->src_h >> 16, 0, GAM_GDP_SIZE_MAX_HEIGHT);
 
list = sti_gdp_get_free_nodes(gdp);
top_field = list->top_field;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/etnaviv: add lockdep assert to fence allocation

[Lucas Stach]

Make sure the GPU lock is taken, so that fence completion order matches
seqno order.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index da48819ff2e6..f01bf17a54ef 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1051,6 +1051,12 @@ static struct dma_fence *etnaviv_gpu_fence_alloc(struct 
etnaviv_gpu *gpu)
 {
struct etnaviv_fence *f;
 
+   /*
+* GPU lock must already be held, otherwise fence completion order might
+* not match the seqno order assigned here.
+*/
+   lockdep_assert_held(&gpu->lock);
+
f = kzalloc(sizeof(*f), GFP_KERNEL);
if (!f)
return NULL;
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/etnaviv: (re-)protect fence allocation with GPU mutex

[Lucas Stach]

The fence allocation needs to be protected by the GPU mutex, otherwise
the fence seqnos of concurrent submits might not match the insertion order
of the jobs in the kernel ring. This breaks the assumption that jobs
complete with monotonically increasing fence seqnos.

Fixes: d9853490176c (drm/etnaviv: take GPU lock later in the submit process)
CC: sta...@vger.kernel.org #4.9+
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 130d7d517a19..da48819ff2e6 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1311,6 +1311,8 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
goto out_pm_put;
}
 
+   mutex_lock(&gpu->lock);
+
fence = etnaviv_gpu_fence_alloc(gpu);
if (!fence) {
event_free(gpu, event);
@@ -1318,8 +1320,6 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
goto out_pm_put;
}
 
-   mutex_lock(&gpu->lock);
-
gpu->event[event].fence = fence;
submit->fence = fence->seqno;
gpu->active_fence = submit->fence;
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 0/5] drm/i915: SKL+ render decompression support

[Daniel Stone]

Hi Ville,

On 21 March 2017 at 18:12,   wrote:
> Another iteration of the i915 CCS support. Main change is lifting the
> fb dimensions hsub/vsub alignment restrictions from the core. Without that
> userspace would have to align the fb size be a multiple of 8x16 pixels
> which isn't something they are interested in doing.

With a rebase of Ben's GBM branch[0], and my last Weston atomic
series, for Y_CCS this series is:
Tested-by: Daniel Stone 

I had to disable Yf_CCS due to complaints about the kernel's idea of
the tiling mode not matching the modifier. Not sure if this is
something which has subsequently been fixed, or ...

Cheers,
Daniel

[0]: 
https://git.collabora.com/cgit/user/daniels/mesa.git/log/?h=wip/2017-03/modifiers-v9-rebased
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

[Daniel Vetter]

On Thu, Mar 23, 2017 at 12:01:30PM +, Daniel Stone wrote:
> Hi Michel,
> 
> On 23 March 2017 at 08:53, Michel Dänzer  wrote:
> > Otherwise this can also prevent modesets e.g. for switching VTs, when
> > multiple monitors with different native resolutions are connected.
> >
> > The depths must match though, so keep the != test for that.
> >
> > Also update the DRM_DEBUG output to be slightly more accurate, this
> > doesn't only affect requests from userspace.
> 
> This test looks much more sensible, and also fixes VT switching for me.
> 
> Reviewed-by: Daniel Stone 

Applied to drm-misc-fixes, will send a pull request for it asap.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Make the decision to keep vblank irq enabled earlier

[Ville Syrjälä]

On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote:
> We want to provide the vblank irq shadow for pageflip events as well as
> vblank queries. Such events are completed within the vblank interrupt
> handler, and so the current check for disabling the irq will disable it
> from with the same interrupt as the last pageflip event. If we move the
> decision on whether to disable the irq (based on there no being no
> remaining vblank events, i.e. vblank->refcount == 0) to before we signal
> the events, we will only disable the irq on the interrupt after the last
> event was signaled. In the normal course of events, this will keep the
> vblank irq enabled for the entire flip sequence whereas before it would
> flip-flop around every interrupt.
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Michel Dänzer 
> Cc: Laurent Pinchart 
> Cc: Dave Airlie ,
> Cc: Mario Kleiner 
> ---
>  drivers/gpu/drm/drm_irq.c | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 5b77057e91ca..1d6bcee3708f 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1741,6 +1741,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
> int pipe)
>  {
>   struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>   unsigned long irqflags;
> + bool disable_irq;
>  
>   if (WARN_ON_ONCE(!dev->num_crtcs))
>   return false;
> @@ -1768,16 +1769,19 @@ bool drm_handle_vblank(struct drm_device *dev, 
> unsigned int pipe)
>   spin_unlock(&dev->vblank_time_lock);
>  
>   wake_up(&vblank->queue);
> - drm_handle_vblank_events(dev, pipe);
>  
>   /* With instant-off, we defer disabling the interrupt until after
> -  * we finish processing the following vblank. The disable has to
> -  * be last (after drm_handle_vblank_events) so that the timestamp
> -  * is always accurate.
> +  * we finish processing the following vblank after all events have
> +  * been signaled. The disable has to be last (after
> +  * drm_handle_vblank_events) so that the timestamp is always accurate.

We wouldn't actually do the disable as long there's a reference still
held, so the timestamp should be fine in that case. And if there aren't
any references the timestamp shouldn't matter... I think. But it's
probably more clear to keep to the order you propose here anyway.

Reviewed-by: Ville Syrjälä 

Oh, and now that I think about this stuff again, I start to wonder why
I made the disable actually update the seq/ts. If the interrupt is
currently enabled the seq/ts should be reasonably uptodate already
when we do disable the interrupt. Perhaps I was only thinking about
drm_vblank_off() when I made that change, or I decided that I didn't
want two different disable codepaths. Anyways, just an idea that
we might be able to make the vblank irq disable a little cheaper.

>*/
> - if (dev->vblank_disable_immediate &&
> - drm_vblank_offdelay > 0 &&
> - !atomic_read(&vblank->refcount))
> + disable_irq = (dev->vblank_disable_immediate &&
> +drm_vblank_offdelay > 0 &&
> +!atomic_read(&vblank->refcount));
> +
> + drm_handle_vblank_events(dev, pipe);
> +
> + if (disable_irq)
>   vblank_disable_fn((unsigned long)vblank);
>  
>   spin_unlock_irqrestore(&dev->event_lock, irqflags);
> -- 
> 2.11.0

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/scdc: declare drm_scdc_get_scrambling_status

[Jani Nikula]

On Wed, 22 Mar 2017, "Sharma, Shashank"  wrote:
> Thanks for this patch, Jani.
>
> Reviewed-by: Shashank Sharma 

And pushed to drm-misc-next, thanks for the review.

BR,
Jani.


>
>
> Regards
> Shashank
> On 3/22/2017 4:33 PM, Jani Nikula wrote:
>> Fix sparse warning:
>>
>> drivers/gpu/drm/drm_scdc_helper.c:138:6: warning: symbol
>> 'drm_scdc_get_scrambling_status' was not declared. Should it be static?
>>
>> Fixes: 62c58af32c93 ("drm/edid: detect SCDC support in HF-VSDB")
>> Cc: Shashank Sharma 
>> Signed-off-by: Jani Nikula 
>> ---
>>   include/drm/drm_scdc_helper.h | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/include/drm/drm_scdc_helper.h b/include/drm/drm_scdc_helper.h
>> index ab6bcfbceba9..c25122bb490a 100644
>> --- a/include/drm/drm_scdc_helper.h
>> +++ b/include/drm/drm_scdc_helper.h
>> @@ -129,6 +129,8 @@ static inline int drm_scdc_writeb(struct i2c_adapter 
>> *adapter, u8 offset,
>>  return drm_scdc_write(adapter, offset, &value, sizeof(value));
>>   }
>>   
>> +bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter);
>> +
>>   /**
>>* drm_scdc_set_scrambling - enable scrambling
>>* @adapter: I2C adapter for DDC channel
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

[Daniel Vetter]

On Thu, Mar 23, 2017 at 11:32:49AM +0100, Thomas Hellstrom wrote:
> On 03/23/2017 11:10 AM, Daniel Vetter wrote:
> > On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote:
> >> Hi, Daniel,
> >>
> >> On 03/23/2017 08:31 AM, Daniel Vetter wrote:
> >>> On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote:
>  On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote:
> > On 03/22/2017 10:50 PM, Daniel Vetter wrote:
> >> It's been around forever, no one bothered to address the FIXME, so I
> >> presume it's all fine.
> >>
> >> Cc: Sinclair Yeh 
> >> Cc: Thomas Hellstrom 
> >> Signed-off-by: Daniel Vetter 
> > NAK. We need to properly address this. Probably as part of the atomic
> > update.
>  So could someone with vmwgfx understanding explain this? Note that the
>  FIXME was originally added by me years ago, because I wasn't sure (only
>  about 90%) that this is safe, and was essentially pleading for a vmwgfx
>  expert to review this?
> 
>  Since it didn't happen I presume it's not that terribly and probably safe
>  ...
> 
>  I'm still 90% sure that this is correct, but I'd love for a vmwgfx to
>  audit it. Replying with a NAK is kinda not the response I was hoping for
>  (and yes I guess I should have explained what's going on here better, but
>  it's just a git blame of the FIXME comment away).
> >> So the code has been left in place because it works. Altering it now
> >> will create unnecessary merge conflicts with the atomic code, and the
> >> change isn't tested and audited which means we need to drop focus from
> >> what we're doing and audit and test code that isn't going to be used
> >> anyway for not apparent reason? But otoh put in the below context there
> >> indeed is a reason.
> >>
> >> From a quick audit of the existing code it seems like at least
> >> vmw_cursor_update_position is touching global device state so I think at
> >> a minimum we need to take a spinlock in that function. Otherwise it
> >> seems to be safe.
> > Note that you're holding the crtc lock already, which gives you exclusion
> > against concurrent page_flips, mode_sets and property changes. Note also
> > that page_flips themselves also only hold the crtc lock, so you can run
> > multiple page_flips in parallel on different crtc (iirc vmwgfx has
> > multiple crtc, if not this discussion is entirely moot).
> >
> > tbh I'd be surprised if my patch really breaks something that hasn't been
> > a pre-existing issue for a long time. The original commit which added this
> > FIXME comment is from 2012. Note also that because it's a hack, you
> > already have a pretty a real race with the core drm state keeping, and no
> > one seems to have hit that either.
> >
> > I mean I can dig through vmwgfx code and do the audit, but it'll take a
> > few hours and vmwgfx is it's own world, so much harder to understand (for
> > me).
> >
> 
> I'm thinking of the situation when someone would call a cursor_set ioctl
> in parallell
> for two crtcs at the same time and race writing the position registers?
> Note that the device has only a single global cursor.
> Admittedly the effects of a race would probably be small, but I'd rather
> see it being
> properly protected.

Hm, didn't realize you only have 1 cursor for everything together. In that
case you indeed have a problem. Not sure why that didn't come up 4 years
ago with the original patch, would be pretty easy to add a quite mutex in
v2 ... Since read-only global state is perfectly fine, having the crtc
lock gives you a read-only global state lock (for legacy drivers at least,
not for atomic).
>
> >> But I prefer if we can do that as part of the atomic update?
> > When does that vmwgfx atomic happen?
> 
> We're targeting 4.12, which means the code that is currently under
> testing will need to be sent out for review pretty soon.
> It's already in our standalone testing repo at
> 
> git://git.freedesktop.org/git/mesa/vmwgfx

Deadline is in 2 weeks for 4.12 feature work, per the discussion we've had
after the 4.11 merge window fallout with Linus. You pretty much have to
submit the patches now to have a reasonable chance of them landing in
time. Since vmwgfx has traditionally been the odd kms driver out I'd
really like to give the new atomic code at least a quick read-through, to
make sure it's aligned as much as possible with the other 20+ atomic
drivers.

> but the cursor code hasn't been fixed in that repo yet.

Well if you switched to universal planes it's pretty easy to fix with the
acquire ctx and grabbing mode_config.connection_mutex. Without that you
can just add a global cursor mutex (equally few lines) to patch it up.
> 
> BTW is this blocking some other core drm work you're doing?

Just removing lock_crtc and preventing abuse from spreading. Somehow both
tegra and tilcdc starting using it in places it was definitely not meant
for. vmwgfx (with this FIXME here) was the only legit 

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

[Chris Wilson]

On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote:
> From: Colin Ian King 
> 
> info is being checked to see if it is a null pointer, however, vpgu is
> dereferencing info before this check, leading to a potential null
> pointer dereference.  If info is null, then the error message being
> printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
> use a null vpgu as the macro has a sanity check to see if vpgu is null,
> so this is OK.

It is never NULL, it gets checked by its only caller.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Tue, Mar 21, 2017 at 04:00:37PM +1100, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
> > 
> > 
> > On 21/03/17 06:39, Emil Velikov wrote:
> > > On 20 March 2017 at 18:30, Matt Turner  wrote:
> > > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov 
> > > >  wrote:
> > > > > Seems like we ended up all over the place, so let me try afresh.
> > > > > 
> > > > > Above all:
> > > > >  - Saying "I don't care" about your users is arrogant - let us _not_
> > > > > do that, please ?
> > > > 
> > > > Let's be honest, the OpenBSD is subjecting itself to some pretty
> > > > arbitrary restrictions caused including Mesa in its core: 10+ year old
> > > > GCC,
> > > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> > > wasn't OpenBSD to blame here ;-)
> > 
> > Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
> > switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
> > 
> > Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
> > rather not go through the upgrade hassle if I don't have to."
> > 
> > Followed by Jose "We're internally building and shipping Mesa compiled with
> > GCC 4.4 (more specifically 4.4.3).
> > 
> > It's fine if you require GCC 4.8 on automake, but please leave support
> > for GCC 4.4.x in SCons."
> > 
> > By this point I got bored and moved on. But OpenBSDs GCC is a fork with
> > various features backported, from what I understand Mesa would not build on
> > a real GCC 4.2 release and we should not be using it as a min version. IMO
> > if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
> > the min GCC version.
> > 
> > I believe Jonathan would like us to stick with 4.2 as min but is prepared to
> > deal with it if we move on.
> 
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.
> 
> We have one platform using clang/lld now (arm64) and are likely to move
> others in future where possible.  libtool has to be patched and the Mesa
> configure script regenerated to make this work or Mesa won't build due
> to libtool.m4 looking for specific strings in ld -v produced by bfd
> binutils or gold...
> 
> And yes if you change the configure script to check for a newer version
> I'll revert it locally like I did with the zlib one.
> 
> As I get the impression no one cares about patches for older GCC I've
> not being sending them to the list, ie

And to be clear this is code in Mesa violating the C++ standard
according to clang++ --std=c++14 -pedantic.

compiler/brw_vec4_gs_visitor.cpp:589:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_POINTS] =_3DPRIM_POINTLIST,
   ^~
compiler/brw_vec4_gs_visitor.cpp:590:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINES] = _3DPRIM_LINELIST,
   ^
compiler/brw_vec4_gs_visitor.cpp:591:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINE_LOOP] = _3DPRIM_LINELOOP,
   ^
compiler/brw_vec4_gs_visitor.cpp:592:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINE_STRIP] = _3DPRIM_LINESTRIP,
   ^~~
compiler/brw_vec4_gs_visitor.cpp:593:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_TRIANGLES] = _3DPRIM_TRILIST,
   ^~~~
compiler/brw_vec4_gs_visitor.cpp:594:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_TRIANGLE_STRIP] = _3DPRIM_TRISTRIP,
   ^~
compiler/brw_vec4_gs_visitor.cpp:595:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_TRIANGLE_FAN] = _3DPRIM_TRIFAN,
   ^~
compiler/brw_vec4_gs_visitor.cpp:596:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_QUADS] = _3DPRIM_QUADLIST,
   ^
compiler/brw_vec4_gs_visitor.cpp:597:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_QUAD_STRIP] = _3DPRIM_QUADSTRIP,
   ^~~
compiler/brw_vec4_gs_visitor.cpp:598:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_POLYGON] = _3DPRIM_POLYGON,
   ^~
compiler/brw_vec4_gs_visitor.cpp:599:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINES_ADJACENCY] = _3DPRIM_LINELIST_ADJ,
   ^~~
compiler/brw_vec4_gs_visitor.cpp:600:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINE_STRIP_ADJACENCY] = _3DPRIM_LINESTRIP_ADJ,
 

[PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

[Colin King]

From: Colin Ian King 

info is being checked to see if it is a null pointer, however, vpgu is
dereferencing info before this check, leading to a potential null
pointer dereference.  If info is null, then the error message being
printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
use a null vpgu as the macro has a sanity check to see if vpgu is null,
so this is OK.

Detected with CoverityScan, CID#1420672 ("Dereference nefore null check")

Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 1ea3eb270de8..f8619a772c44 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1339,9 +1339,9 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
 
 static bool kvmgt_guest_exit(struct kvmgt_guest_info *info)
 {
-   struct intel_vgpu *vgpu = info->vgpu;
-
if (!info) {
+   struct intel_vgpu *vgpu = NULL;
+
gvt_vgpu_err("kvmgt_guest_info invalid\n");
return false;
}
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

[Daniel Stone]

Hi Michel,

On 23 March 2017 at 08:53, Michel Dänzer  wrote:
> Otherwise this can also prevent modesets e.g. for switching VTs, when
> multiple monitors with different native resolutions are connected.
>
> The depths must match though, so keep the != test for that.
>
> Also update the DRM_DEBUG output to be slightly more accurate, this
> doesn't only affect requests from userspace.

This test looks much more sensible, and also fixes VT switching for me.

Reviewed-by: Daniel Stone 

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 22 March 2017 at 20:10, Dylan Baker  wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
>> I guess I'm a little late to the party here, but I haven't had time to
>> really let all of this sink in and actually look at meson.  It doesn't
>> seem so bad with a quick look and I think I could probably sort it out
>> when the time came, but there would still be a bit of a learning
>> curve.  While that may not be a big deal at the micro level, I have
>> concerns at the macro level.
>>
>> First, I'm concerned it may discourage casual developers and
>> packagers.  autotools isn't great, but most people are familiar enough
>> with it that they can get by.  Most people have enough knowledge of
>> autotools that they can pretty easily diagnose a configuration based
>> failure. There are a lot of resources for autotools.  I'm not sure
>> that would be the case for meson.  Do we as a community feel we have
>> enough meson experience to get people over the hump?  Anything that
>> makes it harder for someone to try a new build or do a bisect is a big
>> problem in my opinion.
>
> One of the things that's prompted this on our side (I've talked this over with
> other people at Intel before starting), was that clearly we *don't* know
> autotools well enough to get it right.
You do know that I'm always happy to answer questions and help people
;-) Just last night I gave a 2 minute crash course to Lyude why things
behave strange and how to get the desired workflow.

> Emil almost always finds cases were we've
> done things *almost*, but not quite right.
>
Care I say it - I'm a pessimist forged by unfortunate circumstances.
Hence I always see things that are wrong - Mesa build system is no
exception.
I'm fairly confident that if/when we move to Meson we (I?) will be
fixing bugs for at least two releases.

The more frustrating part is that atm autotools build is "bug-free"
and with meson will have to go through the same route again :-\

> For my part, it took me about 3 or 4 days of reading through the docs and
> writing the libdrm port to get it right, and a lot of that is just the
> boilerplate of having ~8 drivers that all need basically the same logic.
>
Slightly off-topic - 3 days to write the build script for ~10 [nearly]
identical libraries which do not do anything fancy, seems a lot.
Which was the most time consuming part ?

I'm concerned that we would have to enforce the same time penalty onto
dozens of developers unfamiliar with meson.

Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

[Andrzej Hajda]

On 23.03.2017 12:04, Jose Abreu wrote:
> Hi Andrzej,
>
>
> Thanks for the feedback!
>
> On 23-03-2017 08:11, Andrzej Hajda wrote:
>> On 22.03.2017 18:35, Jose Abreu wrote:
>>> This patch completes CEA table of video modes so that VIC 1-107
>>> are now available. Use the HDMI 2.0+ flag to signal these are
>>> modes for HDMI 2.0 onwards.
>> edid_cea_modes array is used in different contexts, simple extensions of
>> the array with modes not present in HDMI < 2.0 can result in different
>> behavior of drivers.
>> There should be put sentinels somewhere to limit table lookup to old
>> VICs if device/driver/receiver is not HDMI2.0 compliant.
>> The only situation I am aware of at the moment is infoframe generation
>> code. For TVs not supporting 4K modes but not HDMI 2.0 compatible, VIC
>> field in AVI infoframe should be 0 for 4K modes and vendor infoframe
>> should be generated with proper HDMI-VIC. With current infoframe helpers
>> and this patch it will not work this way.
> But this is what I do in patch 5/5 (see
> https://patchwork.kernel.org/patch/9640205/), unless drivers ask
> to I don't expose the new modes.

I do not see how it is related to infoframe generation. Look at body of
drm_hdmi_avi_infoframe_from_display_mode, it calls drm_match_cea_mode,
which looks for given mode in edid_cea_modes array.
Anyway if there is or will be a patch which deals with it, it should be
applied before extending edid_cea_modes array, not after.


Regards
Andrzej

>
> Best regards,
> Jose Miguel Abreu
>
>> Regards
>> Andrzej
>>> Signed-off-by: Jose Abreu 
>>> Cc: Carlos Palminha 
>>> Cc: dri-devel@lists.freedesktop.org
>>> ---
>>>  drivers/gpu/drm/drm_edid.c | 258 
>>> +
>>>  1 file changed, 258 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index fad3d44..90080368 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -1001,6 +1001,264 @@ struct minimode {
>>>2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>>>DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>>>  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
>>> +   /* 65 - 1280x720@24Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
>>> +  3080, 3300, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>>> +  DRM_MODE_FLAG_HDMI2),
>>> + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 66 - 1280x720@25Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
>>> +  3740, 3960, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>>> +  DRM_MODE_FLAG_HDMI2),
>>> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 67 - 1280x720@30Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
>>> +  3080, 3300, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>>> +  DRM_MODE_FLAG_HDMI2),
>>> + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 68 - 1280x720@50Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
>>> +  1760, 1980, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>>> +  DRM_MODE_FLAG_HDMI2),
>>> + .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 69 - 1280x720@60Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
>>> +  1430, 1650, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>>> +  DRM_MODE_FLAG_HDMI2),
>>> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 70 - 1280x720@100Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
>>> +  1760, 1980, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>>> +  DRM_MODE_FLAG_HDMI2),
>>> + .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 71 - 1280x720@120Hz */
>>> +   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
>>> +  1430, 1650, 0, 720, 725, 730, 750, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>>> +  DRM_MODE_FLAG_HDMI2),
>>> + .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>>> +   /* 72 - 1920x1080@24Hz */
>>> +   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
>>> +  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
>>> +  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
>>> +  DRM_MODE_FLAG_HDMI2),
>>> + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, }

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

[Sharma, Shashank]

Regards

Shashank


On 3/23/2017 10:11 AM, Andrzej Hajda wrote:

On 22.03.2017 18:35, Jose Abreu wrote:

This patch completes CEA table of video modes so that VIC 1-107
are now available. Use the HDMI 2.0+ flag to signal these are
modes for HDMI 2.0 onwards.

edid_cea_modes array is used in different contexts, simple extensions of
the array with modes not present in HDMI < 2.0 can result in different
behavior of drivers.
There should be put sentinels somewhere to limit table lookup to old
VICs if device/driver/receiver is not HDMI2.0 compliant.
The only situation I am aware of at the moment is infoframe generation
code. For TVs not supporting 4K modes but not HDMI 2.0 compatible, VIC
field in AVI infoframe should be 0 for 4K modes and vendor infoframe
should be generated with proper HDMI-VIC. With current infoframe helpers
and this patch it will not work this way.

Regards
Andrzej
I had a small discussion with Ville on this, and we were thinking on 
adding monitor info before
VIC calculation in match_cea_modes() function, so that it should give a 
VIC of 0 for HDMI 1.4 sinks

but appropriate VIC for HDMI 2.0 sink. Consider WIP.

- Shashank

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: dri-devel@lists.freedesktop.org
---
  drivers/gpu/drm/drm_edid.c | 258 +
  1 file changed, 258 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fad3d44..90080368 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1001,6 +1001,264 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_

Re: [RFC 1/5] drm: Add HDMI 2.0+ features exposing knob

[Daniel Vetter]

On Thu, Mar 23, 2017 at 10:44:16AM +, Jose Abreu wrote:
> Hi Daniel,
> 
> 
> On 23-03-2017 07:22, Daniel Vetter wrote:
> > On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote:
> >> We can't expect userspace to have full support for all HDMI 2.0+
> >> features. Instead of expecting/waiting for userspace to support
> >> the new features add a knob, much like the stereo knob, so that
> >> DRM core will only expose the features when asked too.
> >>
> >> Signed-off-by: Jose Abreu 
> >> Cc: Carlos Palminha 
> >> Cc: dri-devel@lists.freedesktop.org
> >> ---
> >>  drivers/gpu/drm/drm_ioctl.c | 5 +
> >>  include/drm/drm_file.h  | 8 
> >>  include/uapi/drm/drm.h  | 7 +++
> >>  3 files changed, 20 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> >> index a7c61c2..2430e2e 100644
> >> --- a/drivers/gpu/drm/drm_ioctl.c
> >> +++ b/drivers/gpu/drm/drm_ioctl.c
> >> @@ -318,6 +318,11 @@ static int drm_getcap(struct drm_device *dev, void 
> >> *data, struct drm_file *file_
> >>file_priv->atomic = req->value;
> >>file_priv->universal_planes = req->value;
> >>break;
> >> +  case DRM_CLIENT_CAP_HDMI2:
> >> +  if (req->value > 1)
> >> +  return -EINVAL;
> >> +  file_priv->hdmi2_allowed = req->value;
> > Needs some userspace to make use of this (like the -modesetting x.org
> > driver).
> > -Daniel
> 
> I see your point but shouldn't this be merged before actually
> starting to work in userspace?

No, see

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

for reasons behind this and the precise flow.

Cheers, Daniel

> 
> Best regards,
> Jose Miguel Abreu
> 
> >
> >> +  break;
> >>default:
> >>return -EINVAL;
> >>}
> >> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> >> index 5dd27ae..7b97d85 100644
> >> --- a/include/drm/drm_file.h
> >> +++ b/include/drm/drm_file.h
> >> @@ -192,6 +192,14 @@ struct drm_file {
> >>unsigned is_master:1;
> >>  
> >>/**
> >> +   * @hdmi2_allowed:
> >> +   *
> >> +   * True if client understands HDMI 2.0+ features like, for example,
> >> +   * extended aspect ratios
> >> +   */
> >> +  unsigned hdmi2_allowed:1;
> >> +
> >> +  /**
> >> * @master:
> >> *
> >> * Master this node is currently associated with. Only relevant if
> >> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> >> index b2c5284..9e25138 100644
> >> --- a/include/uapi/drm/drm.h
> >> +++ b/include/uapi/drm/drm.h
> >> @@ -678,6 +678,13 @@ struct drm_get_cap {
> >>   */
> >>  #define DRM_CLIENT_CAP_ATOMIC 3
> >>  
> >> +/**
> >> + * DRM_CLIENT_CAP_HDMI2
> >> + *
> >> + * If set to 1, the DRM core will expose HDMI 2.0+ features to userspace
> >> + */
> >> +#define DRM_CLIENT_CAP_HDMI2  4
> >> +
> >>  /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
> >>  struct drm_set_client_cap {
> >>__u64 capability;
> >> -- 
> >> 1.9.1
> >>
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=4lBpQovdR7O8jeC7mV8SX9xvTypMtV8CBDEDg3bGgzw&s=h-gqFlO62i53pir0j2lJ-upE_bXQxhn3BK1nhdxoB6Y&e=
> >>  
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

[Sharma, Shashank]

I realized it was too early to search that in dri-devel last night, I 
guess it takes some time to sync.


Now I can see them all :)


On 3/23/2017 12:37 PM, Jose Abreu wrote:

Hi Shashank,


On 22-03-2017 18:57, Sharma, Shashank wrote:

Hi Jose,
I can't find the other patches of this series in dri patchwork, am I missing 
something ?

You can find them now in patchwork (I don't know what happened).


Also, I am planning to publish a series for YUV 420 handling, where I have 
re-used one of your patch to parse YUV 420 block, with some modifications :-).

Nice :) Please cc me and I will try to review them.

Best regards,
Jose Miguel Abreu


Regards
Shashank
-Original Message-
From: Jose Abreu [mailto:jose.ab...@synopsys.com]
Sent: Wednesday, March 22, 2017 8:13 PM
To: dri-devel@lists.freedesktop.org
Cc: Carlos Palminha ; Vetter, Daniel 
; Sharma, Shashank ; 
ville.syrj...@linux.intel.com
Subject: Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

++ Daniel

++ Ville

++ Shashank


On 22-03-2017 17:35, Jose Abreu wrote:

Hi all,

This is a RFC series that aims to collect comments regarding the
handling of HDMI 2.0+ video modes and features in the DRM core.

Some of the HDMI 2.0 features are already implemented and only affect
kernel drivers (SDCD for example). There are some features, though,
which can, and will, affect userspace.

It is clear that userspace can't be broken, so, based on previous
discussions I started implementing a "HDMI 2.0+ knob" which can be set
by userspace to enable HDMI 2.0+ features.

For now this only limits the exposing of the video modes defined in
CEA-861-F, but it can be extended adding, for example, YCbCr 4:2:0.

Please do not see this as a formal patch as this wasn't even compiled
tested but, please, feel free to comment :)

NOTE: The adding of the new video modes timings was originally done by
Shashank Sharma  so, credit to him. I
modified it a little bit (added the HDMI 2.0+ flag) and I don't know
if I should add his signed-off-by as it was modified.

Best regards,
Jose Miguel Abreu

Cc: Carlos Palminha 
Cc: dri-devel@lists.freedesktop.org

Jose Abreu (5):
   drm: Add HDMI 2.0+ features exposing knob
   drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag
   drm: edid: Add HDMI 2.0 CEA video modes
   drm: connector: Add hdmi2_allowed flag
   drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked
 to

  drivers/gpu/drm/drm_connector.c|   2 +
  drivers/gpu/drm/drm_edid.c | 258 +
  drivers/gpu/drm/drm_ioctl.c|   5 +
  drivers/gpu/drm/drm_probe_helper.c |   9 +-
  include/drm/drm_connector.h|   2 +
  include/drm/drm_file.h |   8 ++
  include/drm/drm_modes.h|  14 ++
  include/uapi/drm/drm.h |   7 +
  include/uapi/drm/drm_mode.h|   9 ++
  9 files changed, 313 insertions(+), 1 deletion(-)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=yaVFU4TjGY0gVF8El1uKcisy6TPsyCl9uN7Wsis-qhY&m=2OKRtIbkxjKURLp5pmoJ8lSSpsZfM6cXwik8mwS0U_4&s=oxPm-LzATMtdXVlKmybIHwYKhKvT-eeayLhz7xRtQkg&e=


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

[Thomas Hellstrom]

On 03/23/2017 11:10 AM, Daniel Vetter wrote:
> On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote:
>> Hi, Daniel,
>>
>> On 03/23/2017 08:31 AM, Daniel Vetter wrote:
>>> On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote:
 On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote:
> On 03/22/2017 10:50 PM, Daniel Vetter wrote:
>> It's been around forever, no one bothered to address the FIXME, so I
>> presume it's all fine.
>>
>> Cc: Sinclair Yeh 
>> Cc: Thomas Hellstrom 
>> Signed-off-by: Daniel Vetter 
> NAK. We need to properly address this. Probably as part of the atomic
> update.
 So could someone with vmwgfx understanding explain this? Note that the
 FIXME was originally added by me years ago, because I wasn't sure (only
 about 90%) that this is safe, and was essentially pleading for a vmwgfx
 expert to review this?

 Since it didn't happen I presume it's not that terribly and probably safe
 ...

 I'm still 90% sure that this is correct, but I'd love for a vmwgfx to
 audit it. Replying with a NAK is kinda not the response I was hoping for
 (and yes I guess I should have explained what's going on here better, but
 it's just a git blame of the FIXME comment away).
>> So the code has been left in place because it works. Altering it now
>> will create unnecessary merge conflicts with the atomic code, and the
>> change isn't tested and audited which means we need to drop focus from
>> what we're doing and audit and test code that isn't going to be used
>> anyway for not apparent reason? But otoh put in the below context there
>> indeed is a reason.
>>
>> From a quick audit of the existing code it seems like at least
>> vmw_cursor_update_position is touching global device state so I think at
>> a minimum we need to take a spinlock in that function. Otherwise it
>> seems to be safe.
> Note that you're holding the crtc lock already, which gives you exclusion
> against concurrent page_flips, mode_sets and property changes. Note also
> that page_flips themselves also only hold the crtc lock, so you can run
> multiple page_flips in parallel on different crtc (iirc vmwgfx has
> multiple crtc, if not this discussion is entirely moot).
>
> tbh I'd be surprised if my patch really breaks something that hasn't been
> a pre-existing issue for a long time. The original commit which added this
> FIXME comment is from 2012. Note also that because it's a hack, you
> already have a pretty a real race with the core drm state keeping, and no
> one seems to have hit that either.
>
> I mean I can dig through vmwgfx code and do the audit, but it'll take a
> few hours and vmwgfx is it's own world, so much harder to understand (for
> me).
>

I'm thinking of the situation when someone would call a cursor_set ioctl
in parallell
for two crtcs at the same time and race writing the position registers?
Note that the device has only a single global cursor.
Admittedly the effects of a race would probably be small, but I'd rather
see it being
properly protected.

>> But I prefer if we can do that as part of the atomic update?
> When does that vmwgfx atomic happen?
> -Daniel

We're targeting 4.12, which means the code that is currently under
testing will need to be sent out for review pretty soon.
It's already in our standalone testing repo at

git://git.freedesktop.org/git/mesa/vmwgfx

but the cursor code hasn't been fixed in that repo yet.

BTW is this blocking some other core drm work you're doing?

Thanks,

/Thomas



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 23/24] drm/msm/mdp5: Reset CTL blend registers before configuring them

[Archit Taneja]

Assigning LMs dynamically to CRTCs results in REG_MDP5_CTL_LAYER_REGs
and REG_MDP5_CTL_LAYER_EXT_REGs maintaining old values for a LM that
isn't used by our CTL instance anymore.

Clear the ctl's CTL_LAYER_REG and CTL_LAYER_EXT_REGs for all LM
instances. The ones that need to be configured are configured later
in this func.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
index 15d78b218935..fddde84afdc3 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
@@ -355,6 +355,22 @@ static u32 mdp_ctl_blend_ext_mask(enum mdp5_pipe pipe,
}
 }
 
+static void mdp5_ctl_reset_blend_regs(struct mdp5_ctl *ctl)
+{
+   unsigned long flags;
+   struct mdp5_ctl_manager *ctl_mgr = ctl->ctlm;
+   int i;
+
+   spin_lock_irqsave(&ctl->hw_lock, flags);
+
+   for (i = 0; i < ctl_mgr->nlm; i++) {
+   ctl_write(ctl, REG_MDP5_CTL_LAYER_REG(ctl->id, i), 0x0);
+   ctl_write(ctl, REG_MDP5_CTL_LAYER_EXT_REG(ctl->id, i), 0x0);
+   }
+
+   spin_unlock_irqrestore(&ctl->hw_lock, flags);
+}
+
 #define PIPE_LEFT  0
 #define PIPE_RIGHT 1
 int mdp5_ctl_blend(struct mdp5_ctl *ctl, struct mdp5_pipeline *pipeline,
@@ -369,6 +385,8 @@ int mdp5_ctl_blend(struct mdp5_ctl *ctl, struct 
mdp5_pipeline *pipeline,
u32 r_blend_cfg = 0, r_blend_ext_cfg = 0;
int i, start_stage;
 
+   mdp5_ctl_reset_blend_regs(ctl);
+
if (ctl_blend_op_flags & MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT) {
start_stage = STAGE0;
blend_cfg |= MDP5_CTL_LAYER_REG_BORDER_COLOR;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 22/24] drm/msm/mdp5: Assign 'right' mixer to CRTC state

[Archit Taneja]

Dynamically assign a right mixer to mdp5_crtc_state in the CRTC's
atomic_check path. Assigning the right mixer has some constraints,
i.e, only a few LMs can be paired together. Update mdp5_mixer_assign
to handle these constraints.

Firstly, we need to identify whether we need a right mixer or not.
At the moment, there are 2 scenarios where a right mixer might be
needed:
- If any of the planes connected to this CRTC is too wide (i.e, is
  comprised of 2 hwpipes).
- If the CRTC's mode itself is too wide (i.e, a 4K mode on HDMI).

We implement both these checks in the mdp5_crtc_atomic_check(), and
pass 'need_right_mixer' to mdp5_setup_pipeline.

If a CRTC is already assigned a single mixer, and a new atomic commit
brings in a drm_plane that needs 2 hwpipes, we can successfully commit
this mode without requiring a full modeset, provided that we still use
the previously assigned mixer as the left mixer. If such an assignment
isn't possible, we'd need to do a full modeset. This scenario has been
ignored for now.

The mixer assignment code is a bit messy, considering we have at most
4 LM instances in hardware. This can probably be re-visited later with
simplified logic.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c  | 49 +---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mixer.c | 97 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mixer.h |  5 +-
 3 files changed, 129 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index d0559962f85b..42fef018c04e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -455,7 +455,8 @@ static void mdp5_crtc_enable(struct drm_crtc *crtc)
 }
 
 int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
-struct drm_crtc_state *new_crtc_state)
+struct drm_crtc_state *new_crtc_state,
+bool need_right_mixer)
 {
struct mdp5_crtc_state *mdp5_cstate =
to_mdp5_crtc_state(new_crtc_state);
@@ -465,15 +466,32 @@ int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
 
new_mixer = !pipeline->mixer;
 
+   if ((need_right_mixer && !pipeline->r_mixer) ||
+   (!need_right_mixer && pipeline->r_mixer))
+   new_mixer = true;
+
if (new_mixer) {
struct mdp5_hw_mixer *old_mixer = pipeline->mixer;
+   struct mdp5_hw_mixer *old_r_mixer = pipeline->r_mixer;
+   u32 caps;
+   int ret;
+
+   caps = MDP_LM_CAP_DISPLAY;
+   if (need_right_mixer)
+   caps |= MDP_LM_CAP_PAIR;
 
-   pipeline->mixer = mdp5_mixer_assign(new_crtc_state->state, crtc,
-   MDP_LM_CAP_DISPLAY);
-   if (IS_ERR(pipeline->mixer))
-   return PTR_ERR(pipeline->mixer);
+   ret = mdp5_mixer_assign(new_crtc_state->state, crtc, caps,
+   &pipeline->mixer, need_right_mixer ?
+   &pipeline->r_mixer : NULL);
+   if (ret)
+   return ret;
 
mdp5_mixer_release(new_crtc_state->state, old_mixer);
+   if (old_r_mixer) {
+   mdp5_mixer_release(new_crtc_state->state, old_r_mixer);
+   if (!need_right_mixer)
+   pipeline->r_mixer = NULL;
+   }
}
 
/*
@@ -550,7 +568,9 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
struct plane_state pstates[STAGE_MAX + 1];
const struct mdp5_cfg_hw *hw_cfg;
const struct drm_plane_state *pstate;
+   const struct drm_display_mode *mode = &state->adjusted_mode;
bool cursor_plane = false;
+   bool need_right_mixer = false;
int cnt = 0, i;
int ret;
enum mdp_mixer_stage_id start;
@@ -561,6 +581,12 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
pstates[cnt].plane = plane;
pstates[cnt].state = to_mdp5_plane_state(pstate);
 
+   /*
+* if any plane on this crtc uses 2 hwpipes, then we need
+* the crtc to have a right hwmixer.
+*/
+   if (pstates[cnt].state->r_hwpipe)
+   need_right_mixer = true;
cnt++;
 
if (plane->type == DRM_PLANE_TYPE_CURSOR)
@@ -571,7 +597,16 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
if (!cnt)
return 0;
 
-   ret = mdp5_crtc_setup_pipeline(crtc, state);
+   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
+
+   /*
+* we need a right hwmixer if the mode's width is greater than a single
+* LM's max width
+*/
+   if (mode->hdisplay > hw_cfg->lm.max_width)
+

[PATCH 24/24] drm/msm/mdp5: Enable 3D mux in mdp5_ctl

[Archit Taneja]

3D mux is a small block placed after the DSPPs in MDP5. It can merge
2 LM/DSPP outputs and feed it to a single interface.

Enable 3D Mux if our mdp5_pipeline has 2 active LMs. This check
will need to be made more specific later when we add Dual DSI
support with source split enabled. In that use case, each LM feeds to a
separae INTF, so the 3D mux isn't needed.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
index fddde84afdc3..439e0a300e25 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
@@ -138,9 +138,10 @@ static void set_display_intf(struct mdp5_kms *mdp5_kms,
spin_unlock_irqrestore(&mdp5_kms->resource_lock, flags);
 }
 
-static void set_ctl_op(struct mdp5_ctl *ctl, struct mdp5_interface *intf)
+static void set_ctl_op(struct mdp5_ctl *ctl, struct mdp5_pipeline *pipeline)
 {
unsigned long flags;
+   struct mdp5_interface *intf = pipeline->intf;
u32 ctl_op = 0;
 
if (!mdp5_cfg_intf_is_virtual(intf->type))
@@ -161,6 +162,10 @@ static void set_ctl_op(struct mdp5_ctl *ctl, struct 
mdp5_interface *intf)
break;
}
 
+   if (pipeline->r_mixer)
+   ctl_op |= MDP5_CTL_OP_PACK_3D_ENABLE |
+ MDP5_CTL_OP_PACK_3D(1);
+
spin_lock_irqsave(&ctl->hw_lock, flags);
ctl_write(ctl, REG_MDP5_CTL_OP(ctl->id), ctl_op);
spin_unlock_irqrestore(&ctl->hw_lock, flags);
@@ -183,7 +188,7 @@ int mdp5_ctl_set_pipeline(struct mdp5_ctl *ctl, struct 
mdp5_pipeline *pipeline)
if (!mdp5_cfg_intf_is_virtual(intf->type))
set_display_intf(mdp5_kms, intf);
 
-   set_ctl_op(ctl, intf);
+   set_ctl_op(ctl, pipeline);
 
return 0;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 18/24] drm/msm/mdp5: Configure 'right' hwpipe

[Archit Taneja]

Now that we have a right hwpipe in mdp5_plane_state, configure it
mdp5_plane_mode_set(). The only parameters that vary between the
left and right hwpipes are the src_w, src_img_w, src_x and crtc_x
as we just even chop the fb into left and right halves.

Add a mdp5_plane_right_pipe() which will be used by the crtc code
to set up LM stages.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 46 ++-
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 2505632658ad..a8100c8e9c2f 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -281,6 +281,7 @@ void mdp5_irq_domain_fini(struct mdp5_kms *mdp5_kms);
 
 uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
 enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
+enum mdp5_pipe mdp5_plane_right_pipe(struct drm_plane *plane);
 struct drm_plane *mdp5_plane_init(struct drm_device *dev,
  enum drm_plane_type type);
 
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index c50b17e54dcb..5e116532f543 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -880,6 +880,7 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct mdp5_hw_pipe *hwpipe = to_mdp5_plane_state(pstate)->hwpipe;
struct mdp5_kms *mdp5_kms = get_kms(plane);
enum mdp5_pipe pipe = hwpipe->pipe;
+   struct mdp5_hw_pipe *right_hwpipe;
const struct mdp_format *format;
uint32_t nplanes, config = 0;
struct phase_step step = { 0 };
@@ -893,6 +894,8 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
uint32_t src_x, src_y;
uint32_t src_w, src_h;
uint32_t src_img_w, src_img_h;
+   uint32_t src_x_r;
+   int crtc_x_r;
unsigned long flags;
int ret;
 
@@ -928,6 +931,21 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
fb->base.id, src_x, src_y, src_w, src_h,
crtc->base.id, crtc_x, crtc_y, crtc_w, crtc_h);
 
+   right_hwpipe = to_mdp5_plane_state(pstate)->r_hwpipe;
+   if (right_hwpipe) {
+   /*
+* if the plane comprises of 2 hw pipes, assume that the width
+* is split equally across them. The only parameters that varies
+* between the 2 pipes are src_x and crtc_x
+*/
+   crtc_w /= 2;
+   src_w /= 2;
+   src_img_w /= 2;
+
+   crtc_x_r = crtc_x + crtc_w;
+   src_x_r = src_x + src_w;
+   }
+
ret = calc_scalex_steps(plane, pix_format, src_w, crtc_w, step.x);
if (ret)
return ret;
@@ -964,6 +982,12 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
 crtc_x, crtc_y, crtc_w, crtc_h,
 src_img_w, src_img_h,
 src_x, src_y, src_w, src_h);
+   if (right_hwpipe)
+   mdp5_hwpipe_mode_set(mdp5_kms, right_hwpipe, fb, &step, &pe,
+config, hdecm, vdecm, hflip, vflip,
+crtc_x_r, crtc_y, crtc_w, crtc_h,
+src_img_w, src_img_h,
+src_x_r, src_y, src_w, src_h);
 
spin_unlock_irqrestore(&mdp5_plane->pipe_lock, flags);
 
@@ -1049,6 +1073,10 @@ static int mdp5_update_cursor_plane_legacy(struct 
drm_plane *plane,
  src_x, src_y, src_w, src_h);
 }
 
+/*
+ * Use this func and the one below only after the atomic state has been
+ * successfully swapped
+ */
 enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane)
 {
struct mdp5_plane_state *pstate = to_mdp5_plane_state(plane->state);
@@ -1059,14 +1087,30 @@ enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane)
return pstate->hwpipe->pipe;
 }
 
+enum mdp5_pipe mdp5_plane_right_pipe(struct drm_plane *plane)
+{
+   struct mdp5_plane_state *pstate = to_mdp5_plane_state(plane->state);
+
+   if (!pstate->r_hwpipe)
+   return SSPP_NONE;
+
+   return pstate->r_hwpipe->pipe;
+}
+
 uint32_t mdp5_plane_get_flush(struct drm_plane *plane)
 {
struct mdp5_plane_state *pstate = to_mdp5_plane_state(plane->state);
+   u32 mask;
 
if (WARN_ON(!pstate->hwpipe))
return 0;
 
-   return pstate->hwpipe->flush_mask;
+   mask = pstate->hwpipe->flush_mask;
+
+   if (pstate->r_hwpipe)
+   mask |= pstate->r_hwpipe->flush_mask;
+
+   return mask;
 }
 
 /* initialize plane */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___