date:20151007

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

--- Comment #10 from MC Return  ---
(In reply to Alex Deucher from comment #6)
> Can you attach your xorg log?

(In reply to Ernst SjÃ¶strand from comment #8)
> xorg.log shows all versions and what's enabled and disabled.

I'm sorry, confused it with .xsession-errors. Uploaded.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/271e9ebe/attachment.html>

[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X

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

--- Comment #9 from MC Return  ---
Created attachment 118743
  --> https://bugs.freedesktop.org/attachment.cgi?id=118743&action=edit
Xorg.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/cc17f4d9/attachment.html>

[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X

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

--- Comment #8 from Ernst SjÃ¶strand  ---
xorg.log shows all versions and what's enabled and disabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/6c5601e9/attachment.html>

[Bug 75602] Unigine Heaven/Valley: Multi monitor rendering does not work

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

MC Return  changed:

   What|Removed |Added

Summary|Unigine Heaven/Vally: Multi |Unigine Heaven/Valley:
   |monitor rendering does not  |Multi monitor rendering
   |work|does not work

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/0730deb5/attachment.html>

[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X

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

--- Comment #7 from MC Return  ---
(In reply to Alex Deucher from comment #6)
> Can you attach your xorg log?

No, as it includes non-public information - but there are no errors logged
during GtkPerf and there are no unusual errors that it contains...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/b0d8327e/attachment-0001.html>

[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X

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

--- Comment #6 from Alex Deucher  ---
Can you attach your xorg log?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/075f1f9e/attachment.html>

[PATCH 00/13] drm/exynos: async G2D and g2d_move()

2015-10-07 Thread Tobias Jakobi

Gentle ping! :-)

- Tobias


Tobias Jakobi wrote:
> Hello,
> 
> this series mostly touches G2D code. It introduces the following:
> 
> (1) drmHandleEvent2() is added to enable processing of vendor-specific
> events. This will be used to expose asynchronous operation of the
> G2D. The necessary kernel infrastructure is already there since
> a lot of kernel versions. [This touches libdrm core code!]
> 
> (2) The necessary infrastructure to handle G2D events. This includes
> adding g2d_config_event() and g2d_exec2() to the public API.
> A test application is provided to ensure that everything works
> as expected.
> 
> (3) A small performance test application which can be used to measure
> the speed of solid color clear operations. Interesting for
> benchmarking and plotting colorful graphs (e.g. through
> Mathematica).
> 
> (4) g2d_move() which works similar to g2d_copy() but like the C
> memmove() properly handles overlapping buffer copies.
> Again a test application is present to check that this
> indeed does what it should.
> 
> (5) Various small changes. A framebuffer colorformat fix for the
> general G2D test application. Moving the currently unused
> g2d_reset() to the public API. Adding a counterpart to
> exynos_bo_map() to unmap buffers again.
> 
> (6) Last but not least a small bump of the Exynos version number.
> 
> Please review and let me know what I should change/improve.
> 
> 
> With best wishes,
> Tobias
> 
> P.S.: Most patches were submitted already some time ago but never
> made it upstream. So if something looks familiar, don't worry! ;)
> 
> Tobias Jakobi (13):
>   drm: Implement drmHandleEvent2()
>   exynos: Introduce exynos_handle_event()
>   tests/exynos: add fimg2d performance analysis
>   exynos/fimg2d: add g2d_config_event
>   exynos: fimg2d: add g2d_exec2
>   tests/exynos: add fimg2d event test
>   tests/exynos: use XRGB for framebuffer
>   exynos: fimg2d: add g2d_set_direction
>   exynos/fimg2d: add g2d_move
>   tests/exynos: add test for g2d_move
>   exynos/fimg2d: add exynos_bo_unmap()
>   exynos/fimg2d: add g2d_reset() to public API
>   exynos: bump version number
> 
>  exynos/exynos-symbol-check |   5 +
>  exynos/exynos_drm.c|  48 ++
>  exynos/exynos_drm.h|  12 ++
>  exynos/exynos_drmif.h  |  27 +++
>  exynos/exynos_fimg2d.c | 164 +--
>  exynos/exynos_fimg2d.h |  49 ++
>  exynos/libdrm_exynos.pc.in |   2 +-
>  tests/exynos/Makefile.am   |  26 ++-
>  tests/exynos/exynos_fimg2d_event.c | 326 
> +
>  tests/exynos/exynos_fimg2d_perf.c  | 320 
>  tests/exynos/exynos_fimg2d_test.c  | 134 ++-
>  xf86drm.h  |  21 +++
>  xf86drmMode.c  |  10 +-
>  13 files changed, 1128 insertions(+), 16 deletions(-)
>  create mode 100644 tests/exynos/exynos_fimg2d_event.c
>  create mode 100644 tests/exynos/exynos_fimg2d_perf.c
>

[PATCH 10/12] drm: bridge/dw_hdmi: fix phy enable/disable handling

On Wed, Oct 07, 2015 at 06:40:11PM +0800, Yakir Yang wrote:
> 
> 
> On 10/07/2015 05:48 PM, Russell King - ARM Linux wrote:
> >On Wed, Oct 07, 2015 at 12:05:37PM +0800, Yakir Yang wrote:
> >>
> >>On 08/09/2015 12:04 AM, Russell King wrote:
> >>>The dw_hdmi enable/disable handling is particularly weak in several
> >>>regards:
> >>>* The hotplug interrupt could call hdmi_poweron() or hdmi_poweroff()
> >>>   while DRM is setting a mode, which could race with a mode being set.
> >>>* Hotplug will always re-enable the phy whenever it detects an active
> >>>   hotplug signal, even if DRM has disabled the output.
> >>>
> >>>Resolve all of these by introducing a mutex to prevent races, and a
> >>>state-tracking bool so we know whether DRM wishes the output to be
> >>>enabled.  We choose to use our own mutex rather than ->struct_mutex
> >>>so that we can still process interrupts in a timely fashion.
> >>>
> >>>Signed-off-by: Russell King 
> >>>---
> >>>  drivers/gpu/drm/bridge/dw_hdmi.c | 29 ++---
> >>>  1 file changed, 22 insertions(+), 7 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> >>>b/drivers/gpu/drm/bridge/dw_hdmi.c
> >>>index 7b8a4e942a71..0ee188930d26 100644
> >>>--- a/drivers/gpu/drm/bridge/dw_hdmi.c
> >>>+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> >>>@@ -125,6 +125,9 @@ struct dw_hdmi {
> >>>   bool sink_is_hdmi;
> >>>   bool sink_has_audio;
> >>>+  struct mutex mutex; /* for state below and previous_mode */
> >>>+  bool disabled;  /* DRM has disabled our bridge */
> >>>+
> >>>   spinlock_t audio_lock;
> >>>   struct mutex audio_mutex;
> >>>   unsigned int sample_rate;
> >>>@@ -1389,8 +1392,12 @@ static void dw_hdmi_bridge_mode_set(struct 
> >>>drm_bridge *bridge,
> >>>  {
> >>>   struct dw_hdmi *hdmi = bridge->driver_private;
> >>>+  mutex_lock(&hdmi->mutex);
> >>>+
> >>>   /* Store the display mode for plugin/DKMS poweron events */
> >>>   memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode));
> >>>+
> >>>+  mutex_unlock(&hdmi->mutex);
> >>>  }
> >>>  static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
> >>>@@ -1404,14 +1411,20 @@ static void dw_hdmi_bridge_disable(struct 
> >>>drm_bridge *bridge)
> >>>  {
> >>>   struct dw_hdmi *hdmi = bridge->driver_private;
> >>>+  mutex_lock(&hdmi->mutex);
> >>>+  hdmi->disabled = true;
> >>>   dw_hdmi_poweroff(hdmi);
> >>>+  mutex_unlock(&hdmi->mutex);
> >>>  }
> >>>  static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
> >>>  {
> >>>   struct dw_hdmi *hdmi = bridge->driver_private;
> >>>+  mutex_lock(&hdmi->mutex);
> >>>   dw_hdmi_poweron(hdmi);
> >>>+  hdmi->disabled = false;
> >>>+  mutex_unlock(&hdmi->mutex);
> >>>  }
> >>>  static void dw_hdmi_bridge_nop(struct drm_bridge *bridge)
> >>>@@ -1534,20 +1547,20 @@ static irqreturn_t dw_hdmi_irq(int irq, void 
> >>>*dev_id)
> >>>   phy_int_pol = hdmi_readb(hdmi, HDMI_PHY_POL0);
> >>>   if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
> >>>+  hdmi_modb(hdmi, ~phy_int_pol, HDMI_PHY_HPD, HDMI_PHY_POL0);
> >>>+  mutex_lock(&hdmi->mutex);
> >>>   if (phy_int_pol & HDMI_PHY_HPD) {
> >>>   dev_dbg(hdmi->dev, "EVENT=plugin\n");
> >>>-  hdmi_modb(hdmi, 0, HDMI_PHY_HPD, HDMI_PHY_POL0);
> >>>-
> >>>-  dw_hdmi_poweron(hdmi);
> >>>+  if (!hdmi->disabled)
> >>>+  dw_hdmi_poweron(hdmi);
> >>>   } else {
> >>>   dev_dbg(hdmi->dev, "EVENT=plugout\n");
> >>>-  hdmi_modb(hdmi, HDMI_PHY_HPD, HDMI_PHY_HPD,
> >>>-HDMI_PHY_POL0);
> >>>-
> >>>-  dw_hdmi_poweroff(hdmi);
> >>>+  if (!hdmi->disabled)
> >>>+  dw_hdmi_poweroff(hdmi);
> >>Just like my reply on 08/12, I thought this could be removed, so
> >>poweron/poweroff would only be called with bridge->enable/
> >>bridge->disable, them maybe no need mutex here.
> >The bridge enable/disable methods do not get called on hotplug changes.
> >
> >[1.363011] dwhdmi-imx 12.hdmi: Detected HDMI controller 
> >0x13:0xa:0xa0:0xc1
> >[1.371341] dwhdmi-imx 12.hdmi: dw_hdmi_irq(I:RX,HPD P:RX3210,HPD 
> >S:RX,HPD)
> >[1.381345] imx-drm display-subsystem: bound 12.hdmi (ops 
> >dw_hdmi_imx_ops)
> >[1.448691] dwhdmi-imx 12.hdmi: dw_hdmi_bridge_disable()
> >[1.450963] dwhdmi-imx 12.hdmi: dw_hdmi_bridge_enable()
> >
> >and then unplugging and re-plugging the HDMI cable:
> >
> >[   68.307505] dwhdmi-imx 12.hdmi: dw_hdmi_irq(I:RX,HPD P:RX3210,--- 
> >S:RX,---)
> >[   73.813970] dwhdmi-imx 12.hdmi: dw_hdmi_irq(I:RX,HPD P:RX3210,HPD 
> >S:RX,HPD)
> >
> >As you can see, during the period of disconnection for five seconds,
> >dw_hdmi_bridge_disable() was not called.
> >
> >So, without the code above, we'd be needlessly wasting power with the
> >bridge enabled, trying to drive a disconnected display.
> 
> Strangely, I

[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X

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

--- Comment #5 from MC Return  ---
(In reply to Alex Deucher from comment #1)
> please attach your xorg log and dmesg output.

dmesg output (x2) attached, xorg.log shows no unusual errors.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/5989ad32/attachment.html>

[PATCH v5 0/17] Add Analogix Core Display Port Driver

Hi Javier,

On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote:
> Hello Yakir,
>
> On 10/07/2015 11:02 AM, Yakir Yang wrote:
>> Hi Javier,
>>
>> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
>>> Hello Yakir,
>>>
>>> On 10/07/2015 08:25 AM, Yakir Yang wrote:
>>>> Hi all,
>>>>
>>>> Friendly ping.   :)
>>>>
>>>>
>>>> Best regards,
>>>> - Yakir
>>>>
>>>>
>>> Do you have a tree that I can use to test these patches?
>> Wow, thanks a lot, I do have a tree on github 
>> [https://github.com/yakir-Yang/linux/tree/analogix_dp],
>> crossing my finger, wish things works..;)
>>
> I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
> but the machine didn't boot. Unfortunately I need to do some soldering
> to have a serial console on this board so don't have a kernel boot log.
>
> I'll let you know if I can get more info about this issue.

Whoops, sorry for the failed, much appreciated for your works.

Besides, I thought maybe I can find a Peach Pit Chromebook in my side,
I remember that some of our guys have brought one, but previously I
thought that mainline kernel wouldn't run on Peach Pit directly.

Maybe you can email me the method the run mainline kernel on Peach
Pit, so I can debug the analogix_dp driver at the same time, that would
be great.
> Also, there is Kconfig recursive dependency that you may want to fix:
>
> $ make exynos_defconfig
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by 
> DRM_ANALOGIX_DP
> drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected 
> by DRM_EXYNOS_DP
> drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on 
> DRM_EXYNOS_FIMD
> drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
> drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
>   

Yeah, recursive dependency detected, guess I should remove the
"DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks
for your remind.

--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,4 +1,3 @@
  config DRM_ANALOGIX_DP
 tristate
 depends on DRM
-   select DRM_KMS_HELPER


Thanks,
- Yakir
>> Thanks,
>> - Yakir
>>
> Best regards,

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/3eaeb23c/attachment.html>

[PATCH 10/12] drm: bridge/dw_hdmi: fix phy enable/disable handling

D P:RX3210,HPD 
> S:RX,HPD)
> [1.381345] imx-drm display-subsystem: bound 12.hdmi (ops 
> dw_hdmi_imx_ops)
> [1.448691] dwhdmi-imx 12.hdmi: dw_hdmi_bridge_disable()
> [1.450963] dwhdmi-imx 12.hdmi: dw_hdmi_bridge_enable()
>
> and then unplugging and re-plugging the HDMI cable:
>
> [   68.307505] dwhdmi-imx 12.hdmi: dw_hdmi_irq(I:RX,HPD P:RX3210,--- 
> S:RX,---)
> [   73.813970] dwhdmi-imx 12.hdmi: dw_hdmi_irq(I:RX,HPD P:RX3210,HPD 
> S:RX,HPD)
>
> As you can see, during the period of disconnection for five seconds,
> dw_hdmi_bridge_disable() was not called.
>
> So, without the code above, we'd be needlessly wasting power with the
> bridge enabled, trying to drive a disconnected display.

Strangely, I do see bridge enable/disable in my side, past the log and 
dump_stack bellow.

And I guess your HDMI maybe not really hot pluged, could you confirm 
that the "status"
of HDMI display card have been changed between "connected" and 
"disconnected".


Do see bridge_disable when I unpluging the HDMI cable
[   16.358717] dwhdmi-rockchip ff98.hdmi: EVENT=plugout
[   20.613221] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   20.631561] [] (show_stack) from [] 
(dump_stack+0x70/0x8c)
[   20.649337] [] (dump_stack) from [] 
(dw_hdmi_bridge_disable+0x1c/0x88)
[   20.668178] [] (dw_hdmi_bridge_disable) from [] 
(drm_encoder_disable+0x34/0x78)
[   20.687857] [] (drm_encoder_disable) from [] 
(__drm_helper_disable_unused_functions+0x68/0xe4)
[   20.708975] [] (__drm_helper_disable_unused_functions) from 
[] (drm_crtc_helper_set_config+0x128/0x85c)
[   20.731180] [] (drm_crtc_helper_set_config) from 
[] (drm_mode_set_config_internal+0x58/0xdc)
[   20.752507] [] (drm_mode_set_config_internal) from 
[] (commit_crtc_state+0x124/0x1ec)
[   20.773342] [] (commit_crtc_state) from [] 
(atomic_commit.isra.3+0x5c/0xc8)
[   20.793397] [] (atomic_commit.isra.3) from [] 
(drm_atomic_commit+0x1c/0x20)
[   20.813467] [] (drm_atomic_commit) from [] 
(drm_mode_setcrtc+0x324/0x3e4)
[   20.833379] [] (drm_mode_setcrtc) from [] 
(drm_ioctl+0x304/0x478)
[   20.852557] [] (drm_ioctl) from [] 
(do_vfs_ioctl+0x494/0x5a8)
[   20.871377] [] (do_vfs_ioctl) from [] 
(SyS_ioctl+0x5c/0x84)
[   20.890038] [] (SyS_ioctl) from [] 
(__sys_trace_return+0x0/0x14)
[   16.890157] --- YAKIR: dw_hdmi_bridge_disable:1656
[   16.897907] --- YAKIR: dw_hdmi_poweroff:1631

Also see bridge have been disabled once before try to bridge_enable when 
I try re-plugging the HDMI cable
[   20.494292] dwhdmi-rockchip ff98.hdmi: EVENT=plugin
[   12.599389] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   12.612238] [] (show_stack) from [] 
(dump_stack+0x70/0x8c)
[   12.624609] [] (dump_stack) from [] 
(dw_hdmi_bridge_disable+0x1c/0x88)
[   12.638055] [] (dw_hdmi_bridge_disable) from [] 
(drm_crtc_helper_set_mode+0x20c/0x4e0)
[   12.652878] [] (drm_crtc_helper_set_mode) from [] 
(drm_crtc_helper_set_config+0x5f4/0x85c)
[   12.668019] [] (drm_crtc_helper_set_config) from 
[] (drm_mode_set_config_internal+0x58/0xdc)
[   12.683442] [] (drm_mode_set_config_internal) from 
[] (commit_crtc_state+0x124/0x1ec)
[   12.698287] [] (commit_crtc_state) from [] 
(atomic_commit.isra.3+0x5c/0xc8)
[   12.712295] [] (atomic_commit.isra.3) from [] 
(drm_atomic_commit+0x1c/0x20)
[   12.726258] [] (drm_atomic_commit) from [] 
(drm_mode_setcrtc+0x324/0x3e4)
[   12.740226] [] (drm_mode_setcrtc) from [] 
(drm_ioctl+0x304/0x478)
[   12.753651] [] (drm_ioctl) from [] 
(do_vfs_ioctl+0x494/0x5a8)
[   12.766794] [] (do_vfs_ioctl) from [] 
(SyS_ioctl+0x5c/0x84)
[   12.779861] [] (SyS_ioctl) from [] 
(__sys_trace_return+0x0/0x14)
[   21.059320] --- YAKIR: dw_hdmi_bridge_disable:1656
[   21.068272] --- YAKIR: dw_hdmi_poweroff:1631
[   21.076714] rockchip-vop ff93.vop: start latency exceeded, new 
value 9333 ns
[   21.088037] rockchip-vop ff93.vop: Attached to iommu domain
[   12.871336] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   12.882067] [] (show_stack) from [] 
(dump_stack+0x70/0x8c)
[   12.892311] [] (dump_stack) from [] 
(dw_hdmi_bridge_enable+0x3c/0xf28)
[   12.903569] [] (dw_hdmi_bridge_enable) from [] 
(drm_crtc_helper_set_mode+0x42c/0x4e0)
[   12.916226] [] (drm_crtc_helper_set_mode) from [] 
(drm_crtc_helper_set_config+0x5f4/0x85c)
[   12.929450] [] (drm_crtc_helper_set_config) from 
[] (drm_mode_set_config_internal+0x58/0xdc)
[   12.942883] [] (drm_mode_set_config_internal) from 
[] (commit_crtc_state+0x124/0x1ec)
[   12.955784] [] (commit_crtc_state) from [] 
(atomic_commit.isra.3+0x5c/0xc8)
[   12.967753] [] (atomic_commit.isra.3) from [] 
(drm_atomic_commit+0x1c/0x20)
[   12.979705] [] (drm_atomic_commit) from [] 
(drm_mode_setcrtc+0x324/0x3e4)
[   12.991568] [] (drm_mode_setcrtc) from [] 
(drm_ioctl+0x304/0x478)
[   13.002817] [] (drm_ioctl) from [] 
(do_vfs_ioctl+0x494/0x5a8)
[   13.013766] [] (do_vfs_ioctl) from [] 
(SyS_ioctl+0x5c/0x84)
[   13.024655] [] (SyS_ioctl) from [] 
(__sys_trace_return+0x0/0x14)
[   21.114556] --- YAKIR: dw_hdmi_bridge_enable:1664
[   21.122889] --- YAKIR: dw_hdmi_poweron:1625


- Yakir

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/58cb9d8f/attachment-0001.html>

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

2015-10-07 Thread Ville Syrjälä

On Wed, Oct 07, 2015 at 10:29:22AM -0400, Nick Bowler wrote:
> On 10/7/15, Ville SyrjÃ¤lÃ¤  wrote:
> > On Tue, Oct 06, 2015 at 11:42:33AM -0400, Nick Bowler wrote:
> >> On 9/24/15, Nick Bowler  wrote:
> >> > Testing out 4.3-rc2, first thing I notice is that the VGA output is
> >> > not working.  Specifically, the display is continuously powering on
> >> > and off -- at no point is any image visible on the screen (I am
> >> > expecting to see the console output).  The display connected to the
> >> > HDMI output is working fine.
> [...]
> >>   b8afb9113c519a8bd742f7df8c424b0af69a75cd is the first bad commit
> >>   commit b8afb9113c519a8bd742f7df8c424b0af69a75cd
> >>   Author: Ville SyrjÃ¤lÃ¤ 
> >>   Date:   Mon Jun 29 15:25:48 2015 +0300
> >>
> >>   drm/i915: Keep GMCH DPLL VGA mode always disabled
> [...]
> > @@ -1790,13 +1790,13 @@ static void i9xx_disable_pll(struct intel_crtc
> > *crtc)
> > /* Make sure the pipe isn't still relying on us */
> > assert_pipe_disabled(dev_priv, pipe);
> >
> > -   I915_WRITE(DPLL(pipe), 0);
> > +   I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS);
> > POSTING_READ(DPLL(pipe));
> >  }
> >
> >
> > That hunk is the only relevant part for your machine. Can you try to revert
> > just that manually?
> >
> > But I'm really surprised that would have any effect since we only used
> > to enable "VGA mode" when the DPLL is off. And when the DPLL is off,
> > there's nothing on the screen anyway.
> 
> Nevertheless, manually reverting just that hunk seems to fix it.

Hmm. You said VGA has the problem, but HDMI does not. Was the problem
happening even when you have both displays enabled at the same time, or
just when VGA was enabled alone?

I've attached two potential patches that might help. Can you give a try
to just patch 1, and if that alone doesn't help then both patches
together?

-- 
Ville SyrjÃ¤lÃ¤
Intel OTC
-- next part --
A non-text attachment was scrubbed...
Name: 0001-restore-DPLL-write.patch
Type: text/x-diff
Size: 768 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/ae7b0ea2/attachment.patch>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-enable-VGA-mode-before-P1-P2-write.patch
Type: text/x-diff
Size: 893 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/ae7b0ea2/attachment-0001.patch>

[PULL] drm-intel-next

Hi Dave,

drm-intel-next-2015-09-28:
- fastboot by default for some systems (Maarten Lankhorts)
- piles of workarounds for bxt and skl
- more fbc work from Paulo
- fix hdmi hotplug detection (Sonika)
- first few patches from Ville to parametrize register macros, prep work for
  typesafe mmio functions
- prep work for nv12 rotation (Tvrtko Ursulin)
- various other bugfixes and improvements all over

Also contains a backmerge of your drm-next branch because conflict fun in
drm/i915 with 4.3.

Cheers, Daniel


The following changes since commit 2d4df13c0f9ef56452b1d9a9016cb3946e17bfe5:

  Merge tag 'topic/drm-misc-2015-09-25' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2015-09-30 08:35:45 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-09-28-merged

for you to fetch changes up to 44cc6c08da0b6c8321c6740bbb6a0c6feb45b2c2:

  Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next 
(2015-09-30 08:47:41 +0200)


Andrzej Hajda (1):
  drm/i915: fix handling gen8_emit_flush_coherentl3_wa result

Animesh Manna (3):
  drm/i915/bxt: Path added of dmc firmware ver1 for BXT.
  drm/i915/bxt: Stepping info added for bxt.
  drm/i915/bxt: Modified HAS_CSR, added support for BXT

Arun Siluvery (3):
  drm/i915/gen9: Add WaDisableSamplerPowerBypassForSOPingPong
  drm/i915/bxt: Add WaSetClckGatingDisableMedia
  drm/i915/bxt: Update revision id for BXT C0

Bob Paauwe (1):
  drm/i915/skl: Don't clear all watermarks when updating. (v2)

Chris Wilson (1):
  drm/i915: Defer adding preallocated stolen objects to the VM list

Damien Lespiau (1):
  drm/i915/bxt: Fix wrongly placed ')' in I915_READ()

Daniel Vetter (4):
  Merge remote-tracking branch 'drm-intel/drm-intel-next-queued' into 
drm-intel-next-queued
  drm/i915: Mark debug mod options as _unsafe
  drm/i915: Update DRIVER_DATE to 20150928
  Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next

Dongwon Kim (1):
  drm/i915: Do not hardcode s_max, ss_max and eu_mask for BXT

Egbert Eich (1):
  drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2

Geliang Tang (2):
  drm/i915: fix kernel-doc warnings in i915_gem.c
  drm/i915: fix task reference leak in i915_debugfs.c

Jani Nikula (1):
  drm/i915/skl: handle port E in cpt_digital_port_connected

Jesse Barnes (5):
  drm/i915: make CSR firmware messages less verbose
  drm/i915: don't try to load GuC fw on pre-gen9
  drm/i915: add more debug info for when atomic updates fail v3
  drm/i915: cleanup pipe_update trace functions with new crtc debug info v3
  drm/i915: fix crash in error state readout on non-execlist platforms v2

Lukas Wunner (1):
  drm/i915: Spell vga_switcheroo consistently

Maarten Lankhorst (6):
  drm/i915: Set csc coefficients in update_pipe_size.
  drm/i915: Remove references to crtc->active from intel_fbdev.c
  drm/i915: Always try to inherit the initial fb.
  drm/i915: Make updating pipe without modeset atomic.
  drm/i915: skip modeset if compatible for everyone.
  drm/i915: Fix fastboot scalers for skylake.

Masanari Iida (1):
  drm/i915: Fix warnings while make xmldocs caused by intel_lrc.c

Matt Roper (1):
  drm/i915: Don't leak VBT mode data

MichaÅ Winiarski (1):
  drm/i915/gtt: Do not initialize drm_mm twice.

Michel Thierry (2):
  drm/i915: WaEnableForceRestoreInCtxtDescForVCS is for video engines only
  drm/i915/lrc: Prevent preemption when lite-restore is disabled

Nick Hoath (3):
  drm/i915/gen9: Add WaDisableMinuteIaClockGating
  drm/i915: Split alloc from init for lrc
  drm/i915: Remove extraneous request cancel.

Paulo Zanoni (9):
  drm/i915: fix the FBC work allocation failure path
  drm/i915: check for the supported strides on HSW+ FBC
  drm/i915: avoid the last 8mb of stolen on BDW/SKL
  drm/i915: print the correct amount of bytes allocated for the CFB
  drm/i915: don't enable FBC when pixel rate exceeds 95% on HSW/BDW
  drm/i915: apply WaFbcAsynchFlipDisableFbcQueue earlier
  drm/i915: don't apply WaFbcAsynchFlipDisableFbcQueue on SKL
  drm/i915: reject invalid formats for FBC
  drm/i915: fix FBC for cases where crtc->base.y is non-zero

Robert Beckett (1):
  drm/i915/gen9: WA ST Unit Power Optimization Disable

Sagar Arun Kamble (8):
  drm/i915: Fix fb object's frontbuffer-bits
  drm/i915/bxt: WaGsvDisableTurbo
  drm/i915: Increase maximum polling time to 50ms for forcewake 
request/clear ack
  drm/i915: Add IS_SKL_GT3 and IS_SKL_GT4 macro.
  drm/i915: WaRsDisableCoarsePowerGating
  drm/i915: WaRsUseTimeoutMode
  drm/i915: WaRsDoubleRc6WrlWithCoarsePowerGating
  drm/i915: Program GuC MAX IDLE Count

Shashank Sharma (3):
  drm/i915/bxt: Enable BXT DSI PLL
  drm/i915/bxt: D

[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X

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

--- Comment #4 from MC Return  ---
Created attachment 118741
  --> https://bugs.freedesktop.org/attachment.cgi?id=118741&action=edit
After restart into Kernel 4.2.3 dmesg now shows no obvious problems, but bench
still slow

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/6e2a3ebc/attachment.html>

[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X

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

--- Comment #3 from MC Return  ---
Created attachment 118740
  --> https://bugs.freedesktop.org/attachment.cgi?id=118740&action=edit
This time dmesg shows Corrupted low memory at 8800f000 (f000 phys) =
00033482

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/e529337e/attachment.html>

[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X

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

--- Comment #2 from MC Return  ---
This happens when the GtkPerf test window is maximized on a 3840x2160 screen
(although the GtkPerf draw area remains much smaller):

GtkPerf 0.40

GtkEntry - time:  0,07
GtkComboBox - time:  0,52
GtkComboBoxEntry - time:  0,37
GtkSpinButton - time:  0,12
GtkProgressBar - time:  0,13
GtkToggleButton - time:  0,45
GtkCheckButton - time:  0,17
GtkRadioButton - time:  0,26
GtkTextView - Add text - time:  0,31
GtkTextView - Scroll - time:  0,00
GtkDrawingArea - Lines - time: 76,11
GtkDrawingArea - Circles - time: 10,23
GtkDrawingArea - Text - time:  0,39
GtkDrawingArea - Pixbufs - time:  0,53
 --- 
Total time: 89,65

The full test now needs almost 90 (!) seconds to finish, Lines test needs 76,11
(!) seconds now...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/38c31524/attachment.html>

[PATCH 08/12] drm: bridge/dw_hdmi: avoid enabling interface in mode_set



On 10/07/2015 05:18 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 07, 2015 at 11:50:53AM +0800, Yakir Yang wrote:
>>
>> On 08/09/2015 12:04 AM, Russell King wrote:
>>> On a mode set, DRM makes the following sequence of calls:
>>> * for_each_encoder
>>> *   bridge  mode_fixup
>>> *   encoder mode_fixup
>>> * crtc  mode_fixup
>>> * for_each_encoder
>>> *   bridge  disable
>>> *   encoder prepare
>>> *   bridge  post_disable
>>> * disable unused encoders
>>> * crtc  prepare
>>> * crtc  mode_set
>>> * for_each_encoder
>>> *   encoder mode_set
>>> *   bridge  mode_set
>>> * crtc  commit
>>> * for_each_encoder
>>> *   bridge  pre_enable
>>> *   encoder commit
>>> *   bridge  enable
>>>
>>> dw_hdmi enables the HDMI output in both the bridge mode_set() and also
>>> the bridge enable() step.  This is duplicated work - we can avoid the
>>> setup in mode_set() and just do it in the enable() stage.  This
>>> simplifies the code a little.
>>>
>>> Signed-off-by: Russell King 
>> I have noticed that dw_hdmi driver have poweron/poweroff when
>> driver detect HPD event in irq thread, that's also duplicated works,
>> would you like to collect that changes into this one:
>>
>> static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>> {
>>  ..
>>
>>  if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>>  if (phy_int_pol & HDMI_PHY_HPD) {
>>  dev_dbg(hdmi->dev, "EVENT=plugin\n");
>>
>>  hdmi_modb(hdmi, 0, HDMI_PHY_HPD, HDMI_PHY_POL0);
>>
>>  dw_hdmi_poweron(hdmi);// no need here
>>  } else {
>>  dev_dbg(hdmi->dev, "EVENT=plugout\n");
>>
>>  hdmi_modb(hdmi, HDMI_PHY_HPD, HDMI_PHY_HPD,
>>HDMI_PHY_POL0);
>>
>>  dw_hdmi_poweroff(hdmi);// no need here
>>  }
>>  drm_helper_hpd_irq_event(hdmi->connector.dev);
>>  }
>>  ..
>> }
> I'm very much of the opinion of making small logical changes.  This
> patch is one small logical change to the DRM-side logic to get rid
> of the identified duplication there without touching anything else.
> If removing the above calls to dw_hdmi_poweron()/dw_hdmi_poweroff()
> were found to cause a regression, then the whole change would end
> up being reverted, which would be annoying.

Hmm... Yeah, it do make some driver logical changes, but I
thought that's good, just make a clean on HPD thread, and I
do give lots of test on chrome tree about this changes, guess
a separate patch would be better.

If you don't feel good enough about this, okay, I would give
more test on that changes, and send upstream to request
comment later.

- Yakir

[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X

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

--- Comment #1 from Alex Deucher  ---
please attach your xorg log and dmesg output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/b189be42/attachment.html>

[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X

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

Bug ID: 92338
   Summary: GtkPerf shows extremely low drawing performance for
GtkDrawingArea - Lines and Circles tests on R390X
   Product: Mesa
   Version: 11.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: mc.return at gmx.net
QA Contact: dri-devel at lists.freedesktop.org

GtkPerf 0.40

GtkEntry - time:  0,03
GtkComboBox - time:  0,34
GtkComboBoxEntry - time:  0,27
GtkSpinButton - time:  0,08
GtkProgressBar - time:  0,14
GtkToggleButton - time:  0,16
GtkCheckButton - time:  0,09
GtkRadioButton - time:  0,16
GtkTextView - Add text - time:  0,17
GtkTextView - Scroll - time:  0,04
GtkDrawingArea - Lines - time: 10,20
GtkDrawingArea - Circles - time:  7,58
GtkDrawingArea - Text - time:  0,24
GtkDrawingArea - Pixbufs - time:  0,47
 --- 
Total time: 19,96

My previous card - a HD6950 - was drawing the Lines and Circles tests at least
10 times faster.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/ae9179b9/attachment.html>

RFC: DRM trivial tree

2015-10-07 Thread Thierry Reding

Hi everyone,

Lately I've noticed that a bunch of trivial patches have been posted
across all drivers. We've also encountered situations in the past where
(relatively trivial) subsystem-wide changes have been made but it ended
up being very difficult to get patches merged (often because they had
inter-dependencies and nobody felt responsible for merging them). Often
Dave has been the last resort for this kind of patches. A side-effect
has been that it often takes a lot of time for such patches to get
merged (if at all) and they usually don't end up in linux-next and
therefore see little testing before they are applied.

To remedy that situation I'd like to propose the addition of a tree to
keep track of these kinds of patches. Note that the target here are
trivial patches, such as coding style fixes, fixes for build warnings
or errors, subsystem-wide API changes, etc. It also targets mostly the
drivers that don't have a branch that feeds into linux-next. Patches
against drivers that already feed into linux-next should go through the
corresponding trees. One reasonable exception for this, in my opinion,
are subsystem-wide changes, because applying them via different trees
usually ends up being messy.

I pushed a branch[0] with a set of patches that I've picked up from
patchwork and which seemed to match the above criteria. I've also Cc'ed
a bunch of people (mostly a subset of what get_maintainer.pl reported
for the patches in the branch).

Before going any further with this I'd like to get some feedback on the
idea. Dave, do you think this is a good idea and would you be willing to
give this a try?

Again, I'm not volunteering to be a maintainer for all of the smaller
drivers. The goal here is to make it easier to get cleanup patches into
linux-next, or provide a place where subsystem-wide changes can be
coordinated. Driver maintainers should still review the patches and in
many cases I'd want to wait for Acked-by or Reviewed-by tags before
taking any patches into the trivial tree. Also, while I'll try to
monitor the list as best I can, it will inevitably happen that I'll miss
patches. When that happens, feel free to Cc me if you think the patches
match the above criteria.

For a while now it's also been difficult to find maintainers for drivers
so I'd like to see more entries being added to MAINTAINERS to help
identify the people that need to be involved and hopefully make this
process easier.

Thierry

[0]: http://cgit.freedesktop.org/tegra/linux/log/?h=drm/trivial/for-next
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/b6b3d530/attachment.sig>

[PATCH] [RFC] drm/doc: Rename docbook to gpu.tmpl

2015-10-07 Thread Jani Nikula

On Wed, 07 Oct 2015, Daniel Vetter  wrote:
> DRM is a lot more than a direct manager nowadays, and there's also a
> bunch of things worth documenting for gpu driver developers outside of
> drivers/gpu/drm, like vgaarb, vga switcheroo or the various hardware
> buses like host1x and ipu-v3.
>
> To avoid further confusion let's rename the top-level to reflect
> reality.
>
> And yes I'm already looking forward to when we need to replace the G
> in GPU with a * ;-)
>
> Inspired by a thread with Lukas since he refused to include the vga
> switcheroo docs into the gpu docs because it's not drm.
>
> Cc: Lukas Wunner 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/DocBook/Makefile |4 +-
>  Documentation/DocBook/drm.tmpl | 4129 
> 
>  Documentation/DocBook/gpu.tmpl | 4129 
> 
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +
>  4 files changed, 4133 insertions(+), 4131 deletions(-)
>  delete mode 100644 Documentation/DocBook/drm.tmpl
>  create mode 100644 Documentation/DocBook/gpu.tmpl

Please use 'git format-patch -M' so it'll be easier to spot the little
easter egg at the end.

[tons of stuff removed]

> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 67ef118ee160..2c0d4dae3a35 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1782,6 +1782,8 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
>   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
>   int ret;
>  
> + BUG();
> +

"whoops" ;)


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v5 0/17] Add Analogix Core Display Port Driver

Hi Javier,

On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
> Hello Yakir,
>
> On 10/07/2015 08:25 AM, Yakir Yang wrote:
>> Hi all,
>>
>> Friendly ping.   :)
>>
>>
>> Best regards,
>> - Yakir
>>
>>
> Do you have a tree that I can use to test these patches?

Wow, thanks a lot, I do have a tree on github 
[https://github.com/yakir-Yang/linux/tree/analogix_dp],
crossing my finger, wish things works..;)

Thanks,
- Yakir

>
> Best regards,

[PATCH 1/2] drm: Stop using drm_vblank_count() as the hw frame counter

Since I already applied Thierry's interface change I've added the unsigned
here as a fixup and dropped patch 2 (since I have that already).

Thanks, Daniel

On Wed, Oct 07, 2015 at 02:54:24PM +0200, Vincent ABRIOU wrote:
> Reviewed-by: Vincent Abriou 
> 
> On 10/02/2015 02:48 PM, Ville SyrjÃ¤lÃ¤ wrote:
> > On Fri, Oct 02, 2015 at 10:25:27AM +0200, Vincent ABRIOU wrote:
> >>
> >>
> >> On 09/30/2015 04:14 PM, Ville SyrjÃ¤lÃ¤ wrote:
> >>> On Wed, Sep 30, 2015 at 04:08:02PM +0200, Daniel Vetter wrote:
>  On Wed, Sep 30, 2015 at 04:46:48PM +0300, ville.syrjala at 
>  linux.intel.com wrote:
> > From: Ville SyrjÃ¤lÃ¤ 
> >
> > drm_vblank_count() returns the software counter. We should not pretend
> > it's the hw counter since we use the hw counter to figuere out what the
> > software counter value should be. So instead provide a new function
> > drm_vblank_no_hw_counter() for drivers that don't have a real hw
> > counter. The new function simply returns 0, which is about the only
> > thing it can do.
> 
>  Shouldn't we instead just make the get_vblank_counter hook optional?
> >>>
> >>> Perhaps. But maybe this way would encourage people to go look for a
> >>> hw frame counter in their hardware?
> >>>
>  -Daniel
> 
> >
> > Cc: Vincent Abriou 
> > Cc: Thierry Reding 
> > Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> > ---
> >drivers/gpu/drm/armada/armada_drv.c  |  2 +-
> >drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
> >drivers/gpu/drm/drm_irq.c| 17 +
> >drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
> >drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c|  2 +-
> >drivers/gpu/drm/imx/imx-drm-core.c   |  2 +-
> >>
> >> [..]
> >>
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -1797,3 +1797,20 @@ bool drm_crtc_handle_vblank(struct drm_crtc 
> > *crtc)
> >   return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
> >}
> >EXPORT_SYMBOL(drm_crtc_handle_vblank);
> > +
> > +/**
> > + * drm_vblank_no_hw_counter - "No hw counter" implementation of 
> > .get_vblank_counter()
> > + * @dev: DRM device
> > + * @pipe: CRTC for which to read the counter
> > + *
> > + * Drivers can plug this into the .get_vblank_counter() function if
> > + * there is no useable hardware frame counter available.
> > + *
> > + * Returns:
> > + * 0
> > + */
> > +u32 drm_vblank_no_hw_counter(struct drm_device *dev, int pipe)
> >>
> >> warning when building the kernel:
> >> int pipe => unsigned int pipe
> >
> > Where exactly? The function pointer signature still has a signed int
> > here, and I was too lazy to go on a rampage to change all the remaining
> > signed ints to unsigned for the vblank driver hooks.
> >

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] drm: s/int pipe/unsigned int pipe/

2015-10-07 Thread Vincent ABRIOU

Reviewed-by: Vincent Abriou 

On 10/02/2015 05:39 PM, Ville SyrjÃ¤lÃ¤ wrote:
> On Fri, Oct 02, 2015 at 03:22:16PM +0200, Vincent ABRIOU wrote:
>>
>>
>> On 10/02/2015 03:12 PM, Ville SyrjÃ¤lÃ¤ wrote:
>>> On Fri, Oct 02, 2015 at 03:07:50PM +0200, Vincent ABRIOU wrote:
 Hi,

 On 09/30/2015 03:46 PM, ville.syrjala at linux.intel.com wrote:
> From: Ville SyrjÃ¤lÃ¤ 
>
> Make the 'pipe' argument to drm_vblank_count() unsigned as it is
> everwhere else.
>
> Cc: Vincent Abriou 
> Cc: Thierry Reding 
> Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> ---
> drivers/gpu/drm/drm_irq.c | 2 +-
> include/drm/drmP.h| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 7d70b7c..f24c57c 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -876,7 +876,7 @@ drm_get_last_vbltimestamp(struct drm_device *dev, 
> unsigned int pipe,
>  * Returns:
>  * The software vblank counter.
>  */
> -u32 drm_vblank_count(struct drm_device *dev, int pipe)
> +u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> {
>   struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index f56..8df4de7 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -928,7 +928,7 @@ extern int drm_irq_uninstall(struct drm_device *dev);
> extern int drm_vblank_init(struct drm_device *dev, unsigned int 
> num_crtcs);
> extern int drm_wait_vblank(struct drm_device *dev, void *data,
>  struct drm_file *filp);
> -extern u32 drm_vblank_count(struct drm_device *dev, int pipe);
> +extern u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe);
> extern u32 drm_crtc_vblank_count(struct drm_crtc *crtc);
> extern u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned 
> int pipe,
>struct timeval *vblanktime);
>


 If you update drm_vblank_count you also need to update
 drm_vblank_no_hw_counter and need to change the u32
 (*get_vblank_counter) prototype.
>>>
>>> No. drm_vblank_count() != .get_vblank_counter()
>>
>> I surely miss something but before your patch in drivers that did not
>> support hw vblank counter we had:
>> .get_vblank_counter = drm_vblank_count;
>
> That was what patch 1/2 fixed.
>

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

2015-10-07 Thread Ville Syrjälä

On Tue, Oct 06, 2015 at 11:42:33AM -0400, Nick Bowler wrote:
> Hi,
> 
> This issue is still present in 4.3-rc4.
> 
> On 9/24/15, Nick Bowler  wrote:
> > Testing out 4.3-rc2, first thing I notice is that the VGA output is
> > not working.  Specifically, the display is continuously powering on
> > and off -- at no point is any image visible on the screen (I am expecting
> > to see the console output).  The display connected to the HDMI output is
> > working fine.
> >
> > Linux 4.2 did not suffer from this problem.
> >
> > In dmesg I see the following messages, which I do not see on a working
> > kernel.  Full dmesg from 4.3-rc2 is attached (gzipped).
> >
> >   [0.115339] [drm:drm_calc_timestamping_constants] *ERROR* crtc
> > 21: Can't calculate constants, dotclock = 0!
> >   [0.117582] [drm:intel_opregion_init] *ERROR* No ACPI video bus found
> >
> > This is an older machine with Intel G45 graphics.
> 
> I was able to identify the commit which fixed my boot crashes, so I
> cherry-picked 80aa93128653 ("drm/i915: disable_shared_pll doesn't
> work on pre-gen5") on top of all otherwise untestable commits.  This
> allowed bisection to proceed:
> 
>   b8afb9113c519a8bd742f7df8c424b0af69a75cd is the first bad commit
>   commit b8afb9113c519a8bd742f7df8c424b0af69a75cd
>   Author: Ville SyrjÃ¤lÃ¤ 
>   Date:   Mon Jun 29 15:25:48 2015 +0300
> 
>   drm/i915: Keep GMCH DPLL VGA mode always disabled
> 
>   We disable the DPLL VGA mode when enabling the DPLL, but we enaable it
>   again when disabling the DPLL. Having VGA mode enabled even in unused
>   DPLLs can cause problems for CHV, so it seems wiser to always keep it
>   disabled. And let's just do that on all GMCH platforms to keep things
>   as similar as possible between them.
> 
>   Signed-off-by: Ville SyrjÃ¤lÃ¤ 
>   Reviewed-by: Sivakumar Thulasimani 
>   Signed-off-by: Daniel Vetter 
> 
>   :04 04 7797d596e73ecf75723375028decd25fbe332ee0
> 9f90a92eec483919853d68563bbb09a71a305532 Mdrivers
> 
> Unfortunately it does not revert cleanly on master.

@@ -1790,13 +1790,13 @@ static void i9xx_disable_pll(struct intel_crtc *crtc)
/* Make sure the pipe isn't still relying on us */
assert_pipe_disabled(dev_priv, pipe);

-   I915_WRITE(DPLL(pipe), 0);
+   I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS);
POSTING_READ(DPLL(pipe));
 }


That hunk is the only relevant part for your machine. Can you try to revert
just that manually?

But I'm really surprised that would have any effect since we only used
to enable "VGA mode" when the DPLL is off. And when the DPLL is off,
there's nothing on the screen anyway.

-- 
Ville SyrjÃ¤lÃ¤
Intel OTC

[PATCH 1/2] drm: Stop using drm_vblank_count() as the hw frame counter

2015-10-07 Thread Vincent ABRIOU

Reviewed-by: Vincent Abriou 

On 10/02/2015 02:48 PM, Ville SyrjÃ¤lÃ¤ wrote:
> On Fri, Oct 02, 2015 at 10:25:27AM +0200, Vincent ABRIOU wrote:
>>
>>
>> On 09/30/2015 04:14 PM, Ville SyrjÃ¤lÃ¤ wrote:
>>> On Wed, Sep 30, 2015 at 04:08:02PM +0200, Daniel Vetter wrote:
 On Wed, Sep 30, 2015 at 04:46:48PM +0300, ville.syrjala at linux.intel.com 
 wrote:
> From: Ville SyrjÃ¤lÃ¤ 
>
> drm_vblank_count() returns the software counter. We should not pretend
> it's the hw counter since we use the hw counter to figuere out what the
> software counter value should be. So instead provide a new function
> drm_vblank_no_hw_counter() for drivers that don't have a real hw
> counter. The new function simply returns 0, which is about the only
> thing it can do.

 Shouldn't we instead just make the get_vblank_counter hook optional?
>>>
>>> Perhaps. But maybe this way would encourage people to go look for a
>>> hw frame counter in their hardware?
>>>
 -Daniel

>
> Cc: Vincent Abriou 
> Cc: Thierry Reding 
> Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> ---
>drivers/gpu/drm/armada/armada_drv.c  |  2 +-
>drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
>drivers/gpu/drm/drm_irq.c| 17 +
>drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
>drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c|  2 +-
>drivers/gpu/drm/imx/imx-drm-core.c   |  2 +-
>>
>> [..]
>>
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1797,3 +1797,20 @@ bool drm_crtc_handle_vblank(struct drm_crtc *crtc)
>   return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
>}
>EXPORT_SYMBOL(drm_crtc_handle_vblank);
> +
> +/**
> + * drm_vblank_no_hw_counter - "No hw counter" implementation of 
> .get_vblank_counter()
> + * @dev: DRM device
> + * @pipe: CRTC for which to read the counter
> + *
> + * Drivers can plug this into the .get_vblank_counter() function if
> + * there is no useable hardware frame counter available.
> + *
> + * Returns:
> + * 0
> + */
> +u32 drm_vblank_no_hw_counter(struct drm_device *dev, int pipe)
>>
>> warning when building the kernel:
>> int pipe => unsigned int pipe
>
> Where exactly? The function pointer signature still has a signed int
> here, and I was too lazy to go on a rampage to change all the remaining
> signed ints to unsigned for the vblank driver hooks.
>

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

On 10/7/15, Ville SyrjÃ¤lÃ¤  wrote:
> On Wed, Oct 07, 2015 at 10:29:22AM -0400, Nick Bowler wrote:
>> On 10/7/15, Ville SyrjÃ¤lÃ¤  wrote:
>> > On Tue, Oct 06, 2015 at 11:42:33AM -0400, Nick Bowler wrote:
>> >> On 9/24/15, Nick Bowler  wrote:
>> >> > Testing out 4.3-rc2, first thing I notice is that the VGA output is
>> >> > not working.  Specifically, the display is continuously powering on
>> >> > and off -- at no point is any image visible on the screen (I am
>> >> > expecting to see the console output).  The display connected to the
>> >> > HDMI output is working fine.
>> [...]
> I've attached two potential patches that might help. Can you give a try
> to just patch 1, and if that alone doesn't help then both patches
> together?

Patch #1: no change.
Patch #1+#2: this works.

Regards,
  Nick

[PATCH v5 0/17] Add Analogix Core Display Port Driver

Hi all,

Friendly ping.   :)


Best regards,
- Yakir


On 09/22/2015 03:20 PM, Yakir Yang wrote:
> Hi all,
>
> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM :)
>
> This time I create this version on linux-next branch (tag is next-20150918),
> and also applied this version to Heiko github eDP branch to verify the 
> function.
> (https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron)
> Glad to say my chromebook "cnm,n116bgeea2" eDP panel just lighted rightly on
> Heiko branch. And after back port this series to chromeos-3.14 tree, my rk3288
> SDK board still can light my 2K DisplayPort monitor. So this time would be 
> okay
> on mainline kernel and chromeos-3.14 tree. ;)
>
> Due to no Exynos board in my side, so I haven't verified the eDP function on
> samsung platform, I only ensure that there are no obvious compiled error. Any
> help would be greatly appreciated. :)
>
> Thanks,
> - Yakir
>
> Changes in v5:
> - Correct the check condition of gpio_is_valid when driver try to get
>the "hpd-gpios" DT propery. (Heiko)
> - Move the platform attach callback in the front of core driver bridge
>attch function. Cause once platform failed at attach, core driver should
>still failed, so no need to init connector before platform attached 
> (Krzysztof)
> - Keep code style no changes with the previous exynos_dp_code.c in this
>patch, and update commit message about the new export symbol (Krzysztof)
> - Gather the device type patch (v4 11/16) into this one. (Krzysztof)
> - leave out the connector registration to analogix platform driver. (Thierry)
> - Resequence this patch after analogix_dp driver have been split
>from exynos_dp code, and rephrase reasonable commit message, and
>remove some controversial style (Krzysztof)
>  -analogix_dp_write_byte_to_dpcd(
>  -dp, DP_TEST_RESPONSE,
>  +analogix_dp_write_byte_to_dpcd(dp,
>  +DP_TEST_RESPONSE,
>   DP_TEST_EDID_CHECKSUM_WRITE);
> - Switch video timing type to "u32", so driver could use 
> "of_property_read_u32"
>to get the backword timing values. Krzysztof suggest me that driver could 
> use
>the "of_property_read_bool" to get backword timing values, but that 
> interfacs
>would modify the original drm_display_mode timing directly (whether those
>properties exists or not).
> - Correct the misspell in commit message. (Krzysztof)
> - Remove the empty line at the end of document, and correct the endpoint
>numbers in the example DT node, and remove the regulator iomux setting
>in driver code while using the pinctl in devicetree instead. (Heiko)
> - Add device type declared, cause the previous "platform device type
>support (v4 11/16)" already merge into (v5 02/14).
> - Implement connector registration code. (Thierry)
> - Split binding doc's from driver changes. (Rob)
> - Add eDP hotplug pinctrl property. (Heiko)
> - Remove "reg" DT property, cause driver could poweron/poweroff phy via
>the exist "grf" syscon already. And rename the example DT node from
>"edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> - Add deivce_node at the front of driver, update phy_ops type from "static
>struct" to "static const struct". And correct the input paramters of
>devm_phy_create() interfaces. (Heiko)
> - Split binding doc's from driver changes. (Rob)
> - Update the rockchip,grf explain in document, and correct the clock required
>elemets in document. (Rob & Heiko)
> - Fix compiled error (Heiko)
> - Using the connector display info message to configure eDP driver input
>video mode, but hard code CRTC video output mode to RGBaaa.
>
> Changes in v4:
> - Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
> - Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
> - Create a separate folder for analogix code in bridge/ (Archit)
> - Update commit message more readable. (Jingoo)
> - Adjust the order from 05 to 04
> - Provide backword compatibility with samsung. (Krzysztof)
> - Split all DTS changes, and provide backward compatibility. Mark old
>properties as deprecated but still support them. (Krzysztof)
> - Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
> - Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
>  "analogix,color-space" & "analogix,color-depth"   &
>  "analogix,link-rate"   & "analogix,lane-count"&
>  "analogix,ycbcr-coeff" & "analogix,dynamic-range" &
>  "vsync-active-high"& "hsync-active-high"  & "interlaces"
> - S

[PATCH v2] drm/rockchip: import dma_buf to gem

2015-10-07 Thread Mark yao



On 2015å¹´10æ02æ¥ 22:33, Heiko StÃ¼bner wrote:
> Hi Mark,
>
> Am Freitag, 26. Juni 2015, 09:27:18 schrieb Mark Yao:
>> We want to display a buffer allocated by other driver, need import
>> the buffer to gem.
>>
>> Signed-off-by: Mark Yao 
> This looks interesting ... do you want to follow up on it?
>
>
> Heiko
Hi Heiko

 Yeah, I forgot to merge this patch last time, If there is no doubt 
on it, I will send
this patch next time.

Thanks.

-- 
ï¼ark Yao

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

--- Comment #14 from Barto  ---
(In reply to Roland Scheidegger from comment #13)
> Does not necessarily mean it is a bug in llvm, maybe we're initializing it
> wrong or something (there were some recent patches to fix some threading
> issues in gallivm recently). Not my area of expertise, though...

I tried the git version of mesa ( master branch ) --> same crash with llvm 3.7

what I am sure is that there is no problem with llvm 3.6.2 and mesa 11.x ( and
even mesa 10.6 + llvm 3.6.2 )

here is the release note of llvm 3.7 :

http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html

I still have no answer from llvm website about my bugreport,

I will try to find the faulty commit in llvm 3.7.x

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/3ea0ac73/attachment.html>

periodic wakeup from DPMS suspend

2015-10-07 Thread Johannes Stezenbach

On Tue, Oct 06, 2015 at 11:04:53PM -0400, Alex Deucher wrote:
> On Tue, Oct 6, 2015 at 11:10 AM, Johannes Stezenbach  wrote:
> >
> > I have a NEC EA244WMi monitor connected to an Asus P8H77-V
> > mainboard with Ivy Bridge Core i5-3550 via DVI.
> > If DPMS suspend is enabled (by xscreensaver, or for testing by
> > "xset dpms force off/suspend/standby"), the monitor
> > enters standby mode but wakes up every 10...30 seconds for
> > 6 seconds to display a "DVI-D: no signal" message.
> 
> Some monitors periodically scan all of their inputs if they are not
> actively being driven by anything to try and automatically switch to
> the connected input.  When the monitor scans the DVI input, it sees
> load on the pins and turns on, only to realize it's not getting a
> signal and then turns off.  If your monitor has an option to turn off
> input probing, that might help.

It's not like I didn't try to twiddle just about every
available menu item, and also used the monitor's
"Reset to Factory Defaults" to no avail.
However, while trying again I found a hidden menu item
which is only available during the short time the
"No Signal" message is displayed, where the left/right
touch buttons open a "Scan Time" setting with "Normal"
and "Slow" options.  After I changed it, the issue was
solved.  I changed it back and the issue doesn't reproduce.
So it looks some internal configuration of the monitor
was messed up and is now fixed by twiddling the hidden
menu item.  "Scan Time" is not documented in the manual
nor is there an indication in the "No Signal" popup.

Case closed.

Thanks,
Johannes

[PATCH v5 0/17] Add Analogix Core Display Port Driver

2015-10-07 Thread Javier Martinez Canillas

Hello Yakir,

On 10/07/2015 01:05 PM, Yakir Yang wrote:
> Hi Javier,
> 
> On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote:
>> Hello Yakir,
>>
>> On 10/07/2015 11:02 AM, Yakir Yang wrote:
>>> Hi Javier,
>>>
>>> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
 Hello Yakir,

 On 10/07/2015 08:25 AM, Yakir Yang wrote:
> Hi all,
>
> Friendly ping.   :)
>
>
> Best regards,
> - Yakir
>
>
 Do you have a tree that I can use to test these patches?
>>> Wow, thanks a lot, I do have a tree on github 
>>> [https://github.com/yakir-Yang/linux/tree/analogix_dp],
>>> crossing my finger, wish things works..;)
>>>
>> I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
>> but the machine didn't boot. Unfortunately I need to do some soldering
>> to have a serial console on this board so don't have a kernel boot log.
>>
>> I'll let you know if I can get more info about this issue.
> 
> Whoops, sorry for the failed, much appreciated for your works.
> 
> Besides, I thought maybe I can find a Peach Pit Chromebook in my side,
> I remember that some of our guys have brought one, but previously I
> thought that mainline kernel wouldn't run on Peach Pit directly.
> 

Great, mainline works correctly on all Exynos based Chromebooks.

> Maybe you can email me the method the run mainline kernel on Peach
> Pit, so I can debug the analogix_dp driver at the same time, that would
> be great.

I wrote a little blog post explaining how to run mainline on these boards:

http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/

That explains the simplest setup though so if you need a different one
(i.e: chain loading a non verified u-boot) or if you have any questions,
feel free to contact me in private and I can help you with the setup.

>> Also, there is Kconfig recursive dependency that you may want to fix:
>>
>> $ make exynos_defconfig
>> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
>> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
>> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on 
>> DRM_KMS_HELPER
>> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by 
>> DRM_ANALOGIX_DP
>> drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is 
>> selected by DRM_EXYNOS_DP
>> drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on 
>> DRM_EXYNOS_FIMD
>> drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
>> drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
>>   
> 
> Yeah, recursive dependency detected, guess I should remove the
> "DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks
> for your remind.
> 
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,4 +1,3 @@
>  config DRM_ANALOGIX_DP
> tristate
> depends on DRM
> -   select DRM_KMS_HELPER
> 
> 

That fixes the recursive dependency issue indeed. Thanks.

> Thanks,
> - Yakir

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[PATCH] drm/virtio: use %llu format string form atomic64_t

On Wednesday 07 October 2015 13:04:06 Arnd Bergmann wrote:
> On Wednesday 07 October 2015 11:45:02 Russell King - ARM Linux wrote:
> > On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote:
> > > The virtgpu driver prints the last_seq variable using the %ld or
> > > %lu format string, which does not work correctly on all architectures
> > > and causes this compiler warning on ARM:
> > > 
> > > drivers/gpu/drm/virtio/virtgpu_fence.c: In function 
> > > 'virtio_timeline_value_str':
> > > drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' 
> > > expects argument of type 'long unsigned int', but argument 4 has type 
> > > 'long long int' [-Wformat=]
> > >   snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq));
> > >   ^
> > > drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 
> > > 'virtio_gpu_debugfs_irq_info':
> > > drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' 
> > > expects argument of type 'long int', but argument 3 has type 'long long 
> > > int' [-Wformat=]
> > >   seq_printf(m, "fence %ld %lld\n",
> > > ^
> > > 
> > > In order to avoid the warnings, this changes the format strings to %llu
> > > and adds a cast to u64, which makes it work the same way everywhere.
> > 
> > You have to wonder why atomic64_* functions do not use u64 types.
> > If they're not reliant on manipulating 64-bit quantities, then what's
> > the point of calling them atomic _64_.
> 
> I haven't checked all architectures, but I assume what happens is that
> 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
> to provide three sets of functions.

scratch that, I just looked at all the architectures and found that it's
just completely arbitrary, even within one architecture you get a mix
of 'long' and 'long long', plus this gem from MIPS:

static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)

which truncates the result to 32 bit.

Arnd

[PATCH] drm/virtio: use %llu format string form atomic64_t

On Wednesday 07 October 2015 11:45:02 Russell King - ARM Linux wrote:
> On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote:
> > The virtgpu driver prints the last_seq variable using the %ld or
> > %lu format string, which does not work correctly on all architectures
> > and causes this compiler warning on ARM:
> > 
> > drivers/gpu/drm/virtio/virtgpu_fence.c: In function 
> > 'virtio_timeline_value_str':
> > drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects 
> > argument of type 'long unsigned int', but argument 4 has type 'long long 
> > int' [-Wformat=]
> >   snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq));
> >   ^
> > drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 
> > 'virtio_gpu_debugfs_irq_info':
> > drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' 
> > expects argument of type 'long int', but argument 3 has type 'long long 
> > int' [-Wformat=]
> >   seq_printf(m, "fence %ld %lld\n",
> > ^
> > 
> > In order to avoid the warnings, this changes the format strings to %llu
> > and adds a cast to u64, which makes it work the same way everywhere.
> 
> You have to wonder why atomic64_* functions do not use u64 types.
> If they're not reliant on manipulating 64-bit quantities, then what's
> the point of calling them atomic _64_.

I haven't checked all architectures, but I assume what happens is that
64-bit ones just #define atomic64_t atomic_long_t, so they don't have
to provide three sets of functions.

Arnd

[PATCH] drm/virtio: use %llu format string form atomic64_t

The virtgpu driver prints the last_seq variable using the %ld or
%lu format string, which does not work correctly on all architectures
and causes this compiler warning on ARM:

drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str':
drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects 
argument of type 'long unsigned int', but argument 4 has type 'long long int' 
[-Wformat=]
  snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq));
  ^
drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 
'virtio_gpu_debugfs_irq_info':
drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' expects 
argument of type 'long int', but argument 3 has type 'long long int' [-Wformat=]
  seq_printf(m, "fence %ld %lld\n",
^

In order to avoid the warnings, this changes the format strings to %llu
and adds a cast to u64, which makes it work the same way everywhere.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c 
b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
index db8b49101a8b..512263919282 100644
--- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
+++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
@@ -34,8 +34,8 @@ virtio_gpu_debugfs_irq_info(struct seq_file *m, void *data)
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct virtio_gpu_device *vgdev = node->minor->dev->dev_private;

-   seq_printf(m, "fence %ld %lld\n",
-  atomic64_read(&vgdev->fence_drv.last_seq),
+   seq_printf(m, "fence %llu %lld\n",
+  (u64)atomic64_read(&vgdev->fence_drv.last_seq),
   vgdev->fence_drv.sync_seq);
return 0;
 }
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c 
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 1da632631dac..67097c9ce9c1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -61,7 +61,7 @@ static void virtio_timeline_value_str(struct fence *f, char 
*str, int size)
 {
struct virtio_gpu_fence *fence = to_virtio_fence(f);

-   snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq));
+   snprintf(str, size, "%llu", (u64)atomic64_read(&fence->drv->last_seq));
 }

 static const struct fence_ops virtio_fence_ops = {

[Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

2015-10-07 Thread David Herrmann

Hi

On Tue, Oct 6, 2015 at 1:19 PM, Chris Wilson  
wrote:
> On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote:
>> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
>> > In addition to the last-in/first-out stack for accessing drm_mm nodes,
>> > we occasionally and in the future often want to find a drm_mm_node by an
>> > address. To do so efficiently we need to track the nodes in an interval
>> > tree - lookups for a particular address will then be O(lg(N)), where N
>> > is the number of nodes in the range manager as opposed to O(N).
>> > Insertion however gains an extra O(lg(N)) step for all nodes
>> > irrespective of whether the interval tree is in use. For future i915
>> > patches, eliminating the linear walk is a significant improvement.
>> >
>> > Signed-off-by: Chris Wilson 
>> > Cc: dri-devel at lists.freedesktop.org
>>
>> For the vma manager David Herrman put the interval tree outside of drm_mm.
>> Whichever way we pick, but I think we should be consistent about this.
>
> Given that the basis of this patch is that functionality exposed by
> drm_mm (i.e. drm_mm_reserve_node) is too slow for our use case (i.e.
> there is a measurable perf degradation if we switch over from the mru
> stack to using fixed addresses) it makes sense to improve that
> functionality. The question is then why the drm_vma_manager didn't use
> and improve the existing functionality...

I didn't want to slow down drm_mm operations, so I kept it separate. I
don't mind if it is merged into drm_mm. It'd be trivial to make the
vma-manager use it (only on the top-level, though).

Thanks
David

[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal

2015-10-07 Thread Lars-Peter Clausen

Added Hans, who's working a lot on the HDMI transmitter drivers (including
audio support) as well as the media list to Cc.

On 10/07/2015 10:19 AM, Arnaud Pouliquen wrote:
> 
> 
>>> My approach is the reverse: DRM driver does not need to know anything
>>> about audio side. As ALSA is the client of DRM, seems more logical from
>>> my point of view ...
>>> Now if a generic solution must be found for all video drivers, sure,
>>> your solution is more flexible.
>>> But if i well understood fbdev drivers are no more accepted for upstream
>>> (please correct me if I'm wrong).
>>> So i don't know we have to keep fbdev in picture...
>>>
>>
>> I am not promoting fbdev support. I am merely asking if we want to force
>> all HDMI drivers to implement a drm_bridge if they want to support audio.
>>
> Yes this is a good point... My implementation is based on hypothesis that
> HDMI drivers are now upstreamed as DRM drivers.

The other place where you can find HDMI support is in V4L2, both receive as
well as transmit. And while the hope for fbdev is that it will be phased out
V4L2 will stay around for a while. And we probably want to have a common API
that can take care of both DRM and V4L so we do not need two sets of helper
functions for things like EDID parsing etc.

- Lars

[PATCH 10/12] drm: bridge/dw_hdmi: fix phy enable/disable handling



On 08/09/2015 12:04 AM, Russell King wrote:
> The dw_hdmi enable/disable handling is particularly weak in several
> regards:
> * The hotplug interrupt could call hdmi_poweron() or hdmi_poweroff()
>while DRM is setting a mode, which could race with a mode being set.
> * Hotplug will always re-enable the phy whenever it detects an active
>hotplug signal, even if DRM has disabled the output.
>
> Resolve all of these by introducing a mutex to prevent races, and a
> state-tracking bool so we know whether DRM wishes the output to be
> enabled.  We choose to use our own mutex rather than ->struct_mutex
> so that we can still process interrupts in a timely fashion.
>
> Signed-off-by: Russell King 
> ---
>   drivers/gpu/drm/bridge/dw_hdmi.c | 29 ++---
>   1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 7b8a4e942a71..0ee188930d26 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -125,6 +125,9 @@ struct dw_hdmi {
>   bool sink_is_hdmi;
>   bool sink_has_audio;
>   
> + struct mutex mutex; /* for state below and previous_mode */
> + bool disabled;  /* DRM has disabled our bridge */
> +
>   spinlock_t audio_lock;
>   struct mutex audio_mutex;
>   unsigned int sample_rate;
> @@ -1389,8 +1392,12 @@ static void dw_hdmi_bridge_mode_set(struct drm_bridge 
> *bridge,
>   {
>   struct dw_hdmi *hdmi = bridge->driver_private;
>   
> + mutex_lock(&hdmi->mutex);
> +
>   /* Store the display mode for plugin/DKMS poweron events */
>   memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode));
> +
> + mutex_unlock(&hdmi->mutex);
>   }
>   
>   static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
> @@ -1404,14 +1411,20 @@ static void dw_hdmi_bridge_disable(struct drm_bridge 
> *bridge)
>   {
>   struct dw_hdmi *hdmi = bridge->driver_private;
>   
> + mutex_lock(&hdmi->mutex);
> + hdmi->disabled = true;
>   dw_hdmi_poweroff(hdmi);
> + mutex_unlock(&hdmi->mutex);
>   }
>   
>   static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
>   {
>   struct dw_hdmi *hdmi = bridge->driver_private;
>   
> + mutex_lock(&hdmi->mutex);
>   dw_hdmi_poweron(hdmi);
> + hdmi->disabled = false;
> + mutex_unlock(&hdmi->mutex);
>   }
>   
>   static void dw_hdmi_bridge_nop(struct drm_bridge *bridge)
> @@ -1534,20 +1547,20 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>   phy_int_pol = hdmi_readb(hdmi, HDMI_PHY_POL0);
>   
>   if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
> + hdmi_modb(hdmi, ~phy_int_pol, HDMI_PHY_HPD, HDMI_PHY_POL0);
> + mutex_lock(&hdmi->mutex);
>   if (phy_int_pol & HDMI_PHY_HPD) {
>   dev_dbg(hdmi->dev, "EVENT=plugin\n");
>   
> - hdmi_modb(hdmi, 0, HDMI_PHY_HPD, HDMI_PHY_POL0);
> -
> - dw_hdmi_poweron(hdmi);
> + if (!hdmi->disabled)
> + dw_hdmi_poweron(hdmi);
>   } else {
>   dev_dbg(hdmi->dev, "EVENT=plugout\n");
>   
> - hdmi_modb(hdmi, HDMI_PHY_HPD, HDMI_PHY_HPD,
> -   HDMI_PHY_POL0);
> -
> - dw_hdmi_poweroff(hdmi);
> + if (!hdmi->disabled)
> + dw_hdmi_poweroff(hdmi);

Just like my reply on 08/12, I thought this could be removed, so 
poweron/poweroff
would only be called with bridge->enable/bridge->disable, them maybe no need
mutex here.

Best regards,
- Yakir
>   }
> + mutex_unlock(&hdmi->mutex);
>   drm_helper_hpd_irq_event(hdmi->bridge->dev);
>   }
>   
> @@ -1617,7 +1630,9 @@ int dw_hdmi_bind(struct device *dev, struct device 
> *master,
>   hdmi->sample_rate = 48000;
>   hdmi->ratio = 100;
>   hdmi->encoder = encoder;
> + hdmi->disabled = true;
>   
> + mutex_init(&hdmi->mutex);
>   mutex_init(&hdmi->audio_mutex);
>   spin_lock_init(&hdmi->audio_lock);
>   

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/d6474140/attachment.html>

[PATCH 09/12] drm: bridge/dw_hdmi: rename dw_hdmi_phy_enable_power()



On 08/09/2015 12:04 AM, Russell King wrote:
> dw_hdmi_phy_enable_power() is not about enabling and disabling power.
> It is about allowing or preventing power-down mode being entered - the
> register is documented as "Power-down enable (active low 0b)."

Same as rockchip hdmi document, great clean, wish I have the
qualification to share review. (If no, that's fine :) )
Reviewed-by: Yakir Yang 

- Yakir
> This can be seen as the bit has no effect when the HDMI phy is
> operational on iMX6 hardware.
>
> Rename the function to dw_hdmi_phy_enable_powerdown() to reflect the
> documentation, make it take a bool for the 'enable' argument, and invert
> the value to be written.
>
> Signed-off-by: Russell King 
> ---
>   drivers/gpu/drm/bridge/dw_hdmi.c | 10 +-
>   1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index fbac8386552b..7b8a4e942a71 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -737,9 +737,9 @@ static int hdmi_phy_i2c_write(struct dw_hdmi *hdmi, 
> unsigned short data,
>   return 0;
>   }
>   
> -static void dw_hdmi_phy_enable_power(struct dw_hdmi *hdmi, u8 enable)
> +static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
>   {
> - hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> + hdmi_mask_writeb(hdmi, !enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_PDZ_OFFSET,
>HDMI_PHY_CONF0_PDZ_MASK);
>   }
> @@ -879,7 +879,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
> unsigned char prep,
>   /* REMOVE CLK TERM */
>   hdmi_phy_i2c_write(hdmi, 0x8000, 0x05);  /* CKCALCTRL */
>   
> - dw_hdmi_phy_enable_power(hdmi, 1);
> + dw_hdmi_phy_enable_powerdown(hdmi, false);
>   
>   /* toggle TMDS enable */
>   dw_hdmi_phy_enable_tmds(hdmi, 0);
> @@ -924,7 +924,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
>   dw_hdmi_phy_sel_data_en_pol(hdmi, 1);
>   dw_hdmi_phy_sel_interface_control(hdmi, 0);
>   dw_hdmi_phy_enable_tmds(hdmi, 0);
> - dw_hdmi_phy_enable_power(hdmi, 0);
> + dw_hdmi_phy_enable_powerdown(hdmi, true);
>   
>   /* Enable CSC */
>   ret = hdmi_phy_configure(hdmi, 0, 8, cscon);
> @@ -1155,7 +1155,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
>   return;
>   
>   dw_hdmi_phy_enable_tmds(hdmi, 0);
> - dw_hdmi_phy_enable_power(hdmi, 0);
> + dw_hdmi_phy_enable_powerdown(hdmi, true);
>   
>   hdmi->phy_enabled = false;
>   }

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/bf2a3c11/attachment.html>

[PATCH 08/12] drm: bridge/dw_hdmi: avoid enabling interface in mode_set



On 08/09/2015 12:04 AM, Russell King wrote:
> On a mode set, DRM makes the following sequence of calls:
> * for_each_encoder
> *   bridgemode_fixup
> *   encoder   mode_fixup
> * crtcmode_fixup
> * for_each_encoder
> *   bridgedisable
> *   encoder   prepare
> *   bridgepost_disable
> * disable unused encoders
> * crtcprepare
> * crtcmode_set
> * for_each_encoder
> *   encoder   mode_set
> *   bridgemode_set
> * crtccommit
> * for_each_encoder
> *   bridgepre_enable
> *   encoder   commit
> *   bridgeenable
>
> dw_hdmi enables the HDMI output in both the bridge mode_set() and also
> the bridge enable() step.  This is duplicated work - we can avoid the
> setup in mode_set() and just do it in the enable() stage.  This
> simplifies the code a little.
>
> Signed-off-by: Russell King 

I have noticed that dw_hdmi driver have poweron/poweroff when
driver detect HPD event in irq thread, that's also duplicated works,
would you like to collect that changes into this one:

static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
{
 ..

 if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
 if (phy_int_pol & HDMI_PHY_HPD) {
 dev_dbg(hdmi->dev, "EVENT=plugin\n");

 hdmi_modb(hdmi, 0, HDMI_PHY_HPD, HDMI_PHY_POL0);

 dw_hdmi_poweron(hdmi);// no need here
 } else {
 dev_dbg(hdmi->dev, "EVENT=plugout\n");

 hdmi_modb(hdmi, HDMI_PHY_HPD, HDMI_PHY_HPD,
   HDMI_PHY_POL0);

 dw_hdmi_poweroff(hdmi);// no need here
 }
 drm_helper_hpd_irq_event(hdmi->connector.dev);
 }
 ..
}

Thanks,
- Yakir
> ---
>   drivers/gpu/drm/bridge/dw_hdmi.c | 2 --
>   1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 578d7362cd65..fbac8386552b 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -1389,8 +1389,6 @@ static void dw_hdmi_bridge_mode_set(struct drm_bridge 
> *bridge,
>   {
>   struct dw_hdmi *hdmi = bridge->driver_private;
>   
> - dw_hdmi_setup(hdmi, mode);
> -
>   /* Store the display mode for plugin/DKMS poweron events */
>   memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode));
>   }

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

On 10/7/15, Nick Bowler  wrote:
> On 10/7/15, Ville SyrjÃ¤lÃ¤  wrote:
>> On Wed, Oct 07, 2015 at 10:29:22AM -0400, Nick Bowler wrote:
>>> On 10/7/15, Ville SyrjÃ¤lÃ¤  wrote:
>>> > On Tue, Oct 06, 2015 at 11:42:33AM -0400, Nick Bowler wrote:
>>> >> On 9/24/15, Nick Bowler  wrote:
>>> >> > Testing out 4.3-rc2, first thing I notice is that the VGA output is
>>> >> > not working.  Specifically, the display is continuously powering on
>>> >> > and off -- at no point is any image visible on the screen (I am
>>> >> > expecting to see the console output).  The display connected to the
>>> >> > HDMI output is working fine.
>>> [...]
>> Hmm. You said VGA has the problem, but HDMI does not. Was the problem
>> happening even when you have both displays enabled at the same time, or
>> just when VGA was enabled alone?
>
> When I boot with HDMI cable disconnected, there is no change in behaviour
> for the VGA output.

Clarification: normally both displays are connected.  So the original issue is
that only one of two displays are working.

[PATCH] drm/virtio: use %llu format string form atomic64_t

On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote:
> The virtgpu driver prints the last_seq variable using the %ld or
> %lu format string, which does not work correctly on all architectures
> and causes this compiler warning on ARM:
> 
> drivers/gpu/drm/virtio/virtgpu_fence.c: In function 
> 'virtio_timeline_value_str':
> drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects 
> argument of type 'long unsigned int', but argument 4 has type 'long long int' 
> [-Wformat=]
>   snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq));
>   ^
> drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 
> 'virtio_gpu_debugfs_irq_info':
> drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' expects 
> argument of type 'long int', but argument 3 has type 'long long int' 
> [-Wformat=]
>   seq_printf(m, "fence %ld %lld\n",
> ^
> 
> In order to avoid the warnings, this changes the format strings to %llu
> and adds a cast to u64, which makes it work the same way everywhere.

You have to wonder why atomic64_* functions do not use u64 types.
If they're not reliant on manipulating 64-bit quantities, then what's
the point of calling them atomic _64_.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

On 10/7/15, Ville SyrjÃ¤lÃ¤  wrote:
> On Wed, Oct 07, 2015 at 10:29:22AM -0400, Nick Bowler wrote:
>> On 10/7/15, Ville SyrjÃ¤lÃ¤  wrote:
>> > On Tue, Oct 06, 2015 at 11:42:33AM -0400, Nick Bowler wrote:
>> >> On 9/24/15, Nick Bowler  wrote:
>> >> > Testing out 4.3-rc2, first thing I notice is that the VGA output is
>> >> > not working.  Specifically, the display is continuously powering on
>> >> > and off -- at no point is any image visible on the screen (I am
>> >> > expecting to see the console output).  The display connected to the
>> >> > HDMI output is working fine.
>> [...]
> Hmm. You said VGA has the problem, but HDMI does not. Was the problem
> happening even when you have both displays enabled at the same time, or
> just when VGA was enabled alone?

When I boot with HDMI cable disconnected, there is no change in behaviour
for the VGA output.

> I've attached two potential patches that might help. Can you give a try
> to just patch 1, and if that alone doesn't help then both patches
> together?

I will try.

Cheers,
  Nick

[PATCH 07/12] drm: bridge/dw_hdmi: enable audio only if sink supports audio

Hi Russell & Andy

On 08/09/2015 12:03 AM, Russell King wrote:
> Only enable audio support if the sink supports audio in some form, as
> defined via its EDID.  We discover this capability using the generic
> drm_detect_monitor_audio() function.
>
> Signed-off-by: Russell King 

Some to 06/12 reply.

Tested-by: Yakir Yang 

- Yakir
> ---
>   drivers/gpu/drm/bridge/dw_hdmi.c | 12 +---
>   1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 7f764716f3c4..578d7362cd65 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -123,6 +123,7 @@ struct dw_hdmi {
>   struct i2c_adapter *ddc;
>   void __iomem *regs;
>   bool sink_is_hdmi;
> + bool sink_has_audio;
>   
>   spinlock_t audio_lock;
>   struct mutex audio_mutex;
> @@ -1271,13 +1272,17 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   /* HDMI Initialization Step B.3 */
>   dw_hdmi_enable_video_path(hdmi);
>   
> - /* not for DVI mode */
> - if (hdmi->sink_is_hdmi) {
> - dev_dbg(hdmi->dev, "%s HDMI mode\n", __func__);
> + if (hdmi->sink_has_audio) {
> + dev_dbg(hdmi->dev, "sink has audio support\n");
>   
>   /* HDMI Initialization Step E - Configure audio */
>   hdmi_clk_regenerator_update_pixel_clock(hdmi);
>   hdmi_enable_audio_clk(hdmi);
> + }
> +
> + /* not for DVI mode */
> + if (hdmi->sink_is_hdmi) {
> + dev_dbg(hdmi->dev, "%s HDMI mode\n", __func__);
>   
>   /* HDMI Initialization Step F - Configure AVI InfoFrame */
>   hdmi_config_AVI(hdmi, mode);
> @@ -1442,6 +1447,7 @@ static int dw_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>   edid->width_cm, edid->height_cm);
>   
>   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> + hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
>   drm_mode_connector_update_edid_property(connector, edid);
>   ret = drm_add_edid_modes(connector, edid);
>   kfree(edid);

[PATCH 06/12] drm: bridge/dw_hdmi: clean up HDMI vs DVI mode handling

Hi Russell & Andy

On 08/09/2015 12:03 AM, Russell King wrote:
> The FSL kernel detects the HDMI vendor id, and uses this to set
> hdmi->edid_cfg.hdmi_cap, which is then used to set mdvi appropriately,
> rather than detecting whether we are outputting a CEA mode.  Update
> the dw_hdmi code to use this logic, but lets eliminate the mdvi
> variable, prefering the more verbose "hdmi->sink_is_hdmi" instead.
>
> Use the generic drm_detect_hdmi_monitor() to detect a HDMI sink.
>
> Signed-off-by: Russell King 

Actually I have posted similarly changes before, feel better about
this one, and I have backport those 06/12 & 07/12 to chrome-3.14
tree, audio still works rightly when I changing the display resolutions.
So I would like to share:

Tested-by: Yakir Yang 

Besides, Andy, would you like to share your ACK here :)

Best regards,
- Yakir
> ---
>   drivers/gpu/drm/bridge/dw_hdmi.c | 26 --
>   1 file changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 2e211b8331ed..7f764716f3c4 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -82,7 +82,6 @@ static const u16 csc_coeff_rgb_in_eitu709[3][4] = {
>   };
>   
>   struct hdmi_vmode {
> - bool mdvi;
>   bool mdataenablepolarity;
>   
>   unsigned int mpixelclock;
> @@ -123,6 +122,7 @@ struct dw_hdmi {
>   
>   struct i2c_adapter *ddc;
>   void __iomem *regs;
> + bool sink_is_hdmi;
>   
>   spinlock_t audio_lock;
>   struct mutex audio_mutex;
> @@ -913,11 +913,10 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
> unsigned char prep,
>   static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
>   {
>   int i, ret;
> - bool cscon = false;
> + bool cscon;
>   
>   /*check csc whether needed activated in HDMI mode */
> - cscon = (is_color_space_conversion(hdmi) &&
> - !hdmi->hdmi_data.video_mode.mdvi);
> + cscon = hdmi->sink_is_hdmi && is_color_space_conversion(hdmi);
>   
>   /* HDMI Phy spec says to do the phy initialization sequence twice */
>   for (i = 0; i < 2; i++) {
> @@ -1094,9 +1093,9 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>   HDMI_FC_INVIDCONF_IN_I_P_INTERLACED :
>   HDMI_FC_INVIDCONF_IN_I_P_PROGRESSIVE;
>   
> - inv_val |= (vmode->mdvi ?
> - HDMI_FC_INVIDCONF_DVI_MODEZ_DVI_MODE :
> - HDMI_FC_INVIDCONF_DVI_MODEZ_HDMI_MODE);
> + inv_val |= hdmi->sink_is_hdmi ?
> + HDMI_FC_INVIDCONF_DVI_MODEZ_HDMI_MODE :
> + HDMI_FC_INVIDCONF_DVI_MODEZ_DVI_MODE;
>   
>   hdmi_writeb(hdmi, inv_val, HDMI_FC_INVIDCONF);
>   
> @@ -1236,10 +1235,8 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   
>   if (!hdmi->vic) {
>   dev_dbg(hdmi->dev, "Non-CEA mode used in HDMI\n");
> - hdmi->hdmi_data.video_mode.mdvi = true;
>   } else {
>   dev_dbg(hdmi->dev, "CEA mode used vic=%d\n", hdmi->vic);
> - hdmi->hdmi_data.video_mode.mdvi = false;
>   }
>   
>   if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
> @@ -1275,10 +1272,8 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   dw_hdmi_enable_video_path(hdmi);
>   
>   /* not for DVI mode */
> - if (hdmi->hdmi_data.video_mode.mdvi) {
> - dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
> - } else {
> - dev_dbg(hdmi->dev, "%s CEA mode\n", __func__);
> + if (hdmi->sink_is_hdmi) {
> + dev_dbg(hdmi->dev, "%s HDMI mode\n", __func__);
>   
>   /* HDMI Initialization Step E - Configure audio */
>   hdmi_clk_regenerator_update_pixel_clock(hdmi);
> @@ -1286,6 +1281,8 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   
>   /* HDMI Initialization Step F - Configure AVI InfoFrame */
>   hdmi_config_AVI(hdmi, mode);
> + } else {
> + dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
>   }
>   
>   hdmi_video_packetize(hdmi);
> @@ -1294,7 +1291,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   hdmi_tx_hdcp_config(hdmi);
>   
>   dw_hdmi_clear_overflow(hdmi);
> - if (hdmi->cable_plugin && !hdmi->hdmi_data.video_mode.mdvi)
> + if (hdmi->cable_plugin && hdmi->sink_is_hdmi)
>   hdmi_enable_overflow_interrupts(hdmi);
>   
>   return 0;
> @@ -1444,6 +1441,7 @@ static int dw_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>   dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
>   edid->width_cm, edid->height_cm);
>   
> + hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
>   drm_mode_connector_update_edid_property(connector, edid);
>   ret = drm_add_edid_modes(connector, edid);
>

[PATCH v5 0/17] Add Analogix Core Display Port Driver

2015-10-07 Thread Javier Martinez Canillas

Hello Yakir,

On 10/07/2015 11:02 AM, Yakir Yang wrote:
> Hi Javier,
> 
> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
>> Hello Yakir,
>>
>> On 10/07/2015 08:25 AM, Yakir Yang wrote:
>>> Hi all,
>>>
>>> Friendly ping.   :)
>>>
>>>
>>> Best regards,
>>> - Yakir
>>>
>>>
>> Do you have a tree that I can use to test these patches?
> 
> Wow, thanks a lot, I do have a tree on github 
> [https://github.com/yakir-Yang/linux/tree/analogix_dp],
> crossing my finger, wish things works..;)
>

I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
but the machine didn't boot. Unfortunately I need to do some soldering
to have a serial console on this board so don't have a kernel boot log.

I'll let you know if I can get more info about this issue.

Also, there is Kconfig recursive dependency that you may want to fix:

$ make exynos_defconfig
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_ANALOGIX_DP
drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected 
by DRM_EXYNOS_DP
drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on 
DRM_EXYNOS_FIMD
drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB

> Thanks,
> - Yakir
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[PATCH] drm/amdgpu: fix 32-bit compiler warning

On Wednesday 07 October 2015 10:57:11 Christian KÃ¶nig wrote:
> On 07.10.2015 09:41, Arnd Bergmann wrote:
> > The new amdgpu driver passes a user space pointer in a 64-bit structure
> > member, which is the correct way to do it, but it attempts to
> > directly cast it to a __user pointer in the kernel, which causes
> > a warning in three places:
> >
> > drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_init':
> > drm/amd/amdgpu/amdgpu_cs.c:180:21: warning: cast to pointer from integer of 
> > different size [-Wint-to-pointer-cast]
> >chunk_array_user = (uint64_t __user *)(cs->in.chunks);
> >
> > This changes all three to add an intermediate cast to 'unsigned long'
> > as other drivers do. This avoids the warning and works correctly on
> > both 32-bit and 64-bit architectures.
> >
> > Signed-off-by: Arnd Bergmann 
> 
> Well if I'm not completely mistaken this is the second time we need to 
> fix this because somebody thought the cast was unnecessary.
> 
> Anyway the patch is Reviewed-by: Christian KÃ¶nig 
>  and I'm going to keep an eye open for the 
> next time somebody tries to remove this.
> 

Ok, thanks.

I guess I should have added

Fixes: e60b344f6c0eff ("drm/amdgpu: optimize amdgpu_parser_init")

Arnd

[Bug 92266] Unigine Valley benchmark hangs up in scene 9 with 3840x2160 resolution on R390X, while lower resolutions work

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

MC Return  changed:

   What|Removed |Added

Summary|Unigine Valley hangs up on  |Unigine Valley benchmark
   |3840x2160 resolution on |hangs up in scene 9 with
   |R390X, while lower  |3840x2160 resolution on
   |resolutions work|R390X, while lower
   ||resolutions work

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/e284d725/attachment.html>

[PATCH] drm/amdgpu: fix 32-bit compiler warning

2015-10-07 Thread Christian König

On 07.10.2015 09:41, Arnd Bergmann wrote:
> The new amdgpu driver passes a user space pointer in a 64-bit structure
> member, which is the correct way to do it, but it attempts to
> directly cast it to a __user pointer in the kernel, which causes
> a warning in three places:
>
> drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_init':
> drm/amd/amdgpu/amdgpu_cs.c:180:21: warning: cast to pointer from integer of 
> different size [-Wint-to-pointer-cast]
>chunk_array_user = (uint64_t __user *)(cs->in.chunks);
>
> This changes all three to add an intermediate cast to 'unsigned long'
> as other drivers do. This avoids the warning and works correctly on
> both 32-bit and 64-bit architectures.
>
> Signed-off-by: Arnd Bergmann 

Well if I'm not completely mistaken this is the second time we need to 
fix this because somebody thought the cast was unnecessary.

Anyway the patch is Reviewed-by: Christian KÃ¶nig 
 and I'm going to keep an eye open for the 
next time somebody tries to remove this.

Regards,
Christian.

>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index cb3c274edb0a..fd16652aa277 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -177,7 +177,7 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, 
> void *data)
>   
>   /* get chunks */
>   INIT_LIST_HEAD(&p->validated);
> - chunk_array_user = (uint64_t __user *)(cs->in.chunks);
> + chunk_array_user = (uint64_t __user *)(unsigned long)(cs->in.chunks);
>   if (copy_from_user(chunk_array, chunk_array_user,
>  sizeof(uint64_t)*cs->in.num_chunks)) {
>   ret = -EFAULT;
> @@ -197,7 +197,7 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, 
> void *data)
>   struct drm_amdgpu_cs_chunk user_chunk;
>   uint32_t __user *cdata;
>   
> - chunk_ptr = (void __user *)chunk_array[i];
> + chunk_ptr = (void __user *)(unsigned long)chunk_array[i];
>   if (copy_from_user(&user_chunk, chunk_ptr,
>  sizeof(struct drm_amdgpu_cs_chunk))) {
>   ret = -EFAULT;
> @@ -208,7 +208,7 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, 
> void *data)
>   p->chunks[i].length_dw = user_chunk.length_dw;
>   
>   size = p->chunks[i].length_dw;
> - cdata = (void __user *)user_chunk.chunk_data;
> + cdata = (void __user *)(unsigned long)user_chunk.chunk_data;
>   p->chunks[i].user_ptr = cdata;
>   
>   p->chunks[i].kdata = drm_malloc_ab(size, sizeof(uint32_t));
>

[Bug 105581] amdgpu: r9 380 Dual Monitor Setup: rotation not working

2015-10-07 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #3 from f.otti at gmx.at ---
(In reply to Michel DÃ¤nzer from comment #2)
> FWIW, rotation doesn't work because glamor fails to initialize, so all
> hardware acceleration is disabled (I posted a xf86-video-amdgpu patch to not
> advertise rotation capability in this case). Looks like Mesa is either
> misconfigured or too old for your card.

Thank you very much, I didn't notice that.
I searched for that problem and tried glxinfo which told me, that llvm version
3.6.1 was required, which I didn't know. So after installing it, the server
doesn't crash anymore upon trying to rotate the screen and it finally works.
It's probably still a bug that the monitors only work with the second DVI slot
and one in HDMI, but this works for me as well.
I'm not sure if I'd call it "resolved" but for me it's at least "workaround is
now good enough"

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 10/12] drm: bridge/dw_hdmi: fix phy enable/disable handling

On Wed, Oct 07, 2015 at 12:05:37PM +0800, Yakir Yang wrote:
> 
> 
> On 08/09/2015 12:04 AM, Russell King wrote:
> >The dw_hdmi enable/disable handling is particularly weak in several
> >regards:
> >* The hotplug interrupt could call hdmi_poweron() or hdmi_poweroff()
> >   while DRM is setting a mode, which could race with a mode being set.
> >* Hotplug will always re-enable the phy whenever it detects an active
> >   hotplug signal, even if DRM has disabled the output.
> >
> >Resolve all of these by introducing a mutex to prevent races, and a
> >state-tracking bool so we know whether DRM wishes the output to be
> >enabled.  We choose to use our own mutex rather than ->struct_mutex
> >so that we can still process interrupts in a timely fashion.
> >
> >Signed-off-by: Russell King 
> >---
> >  drivers/gpu/drm/bridge/dw_hdmi.c | 29 ++---
> >  1 file changed, 22 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> >b/drivers/gpu/drm/bridge/dw_hdmi.c
> >index 7b8a4e942a71..0ee188930d26 100644
> >--- a/drivers/gpu/drm/bridge/dw_hdmi.c
> >+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> >@@ -125,6 +125,9 @@ struct dw_hdmi {
> > bool sink_is_hdmi;
> > bool sink_has_audio;
> >+struct mutex mutex; /* for state below and previous_mode */
> >+bool disabled;  /* DRM has disabled our bridge */
> >+
> > spinlock_t audio_lock;
> > struct mutex audio_mutex;
> > unsigned int sample_rate;
> >@@ -1389,8 +1392,12 @@ static void dw_hdmi_bridge_mode_set(struct drm_bridge 
> >*bridge,
> >  {
> > struct dw_hdmi *hdmi = bridge->driver_private;
> >+mutex_lock(&hdmi->mutex);
> >+
> > /* Store the display mode for plugin/DKMS poweron events */
> > memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode));
> >+
> >+mutex_unlock(&hdmi->mutex);
> >  }
> >  static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
> >@@ -1404,14 +1411,20 @@ static void dw_hdmi_bridge_disable(struct drm_bridge 
> >*bridge)
> >  {
> > struct dw_hdmi *hdmi = bridge->driver_private;
> >+mutex_lock(&hdmi->mutex);
> >+hdmi->disabled = true;
> > dw_hdmi_poweroff(hdmi);
> >+mutex_unlock(&hdmi->mutex);
> >  }
> >  static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
> >  {
> > struct dw_hdmi *hdmi = bridge->driver_private;
> >+mutex_lock(&hdmi->mutex);
> > dw_hdmi_poweron(hdmi);
> >+hdmi->disabled = false;
> >+mutex_unlock(&hdmi->mutex);
> >  }
> >  static void dw_hdmi_bridge_nop(struct drm_bridge *bridge)
> >@@ -1534,20 +1547,20 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> > phy_int_pol = hdmi_readb(hdmi, HDMI_PHY_POL0);
> > if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
> >+hdmi_modb(hdmi, ~phy_int_pol, HDMI_PHY_HPD, HDMI_PHY_POL0);
> >+mutex_lock(&hdmi->mutex);
> > if (phy_int_pol & HDMI_PHY_HPD) {
> > dev_dbg(hdmi->dev, "EVENT=plugin\n");
> >-hdmi_modb(hdmi, 0, HDMI_PHY_HPD, HDMI_PHY_POL0);
> >-
> >-dw_hdmi_poweron(hdmi);
> >+if (!hdmi->disabled)
> >+dw_hdmi_poweron(hdmi);
> > } else {
> > dev_dbg(hdmi->dev, "EVENT=plugout\n");
> >-hdmi_modb(hdmi, HDMI_PHY_HPD, HDMI_PHY_HPD,
> >-  HDMI_PHY_POL0);
> >-
> >-dw_hdmi_poweroff(hdmi);
> >+if (!hdmi->disabled)
> >+dw_hdmi_poweroff(hdmi);
> 
> Just like my reply on 08/12, I thought this could be removed, so
> poweron/poweroff would only be called with bridge->enable/
> bridge->disable, them maybe no need mutex here.

The bridge enable/disable methods do not get called on hotplug changes.

[1.363011] dwhdmi-imx 12.hdmi: Detected HDMI controller 
0x13:0xa:0xa0:0xc1
[1.371341] dwhdmi-imx 12.hdmi: dw_hdmi_irq(I:RX,HPD P:RX3210,HPD 
S:RX,HPD)
[1.381345] imx-drm display-subsystem: bound 12.hdmi (ops 
dw_hdmi_imx_ops)
[1.448691] dwhdmi-imx 12.hdmi: dw_hdmi_bridge_disable()
[1.450963] dwhdmi-imx 12.hdmi: dw_hdmi_bridge_enable()

and then unplugging and re-plugging the HDMI cable:

[   68.307505] dwhdmi-imx 12.hdmi: dw_hdmi_irq(I:RX,HPD P:RX3210,--- 
S:RX,---)
[   73.813970] dwhdmi-imx 12.hdmi: dw_hdmi_irq(I:RX,HPD P:RX3210,HPD 
S:RX,HPD)

As you can see, during the period of disconnection for five seconds,
dw_hdmi_bridge_disable() was not called.

So, without the code above, we'd be needlessly wasting power with the
bridge enabled, trying to drive a disconnected display.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v5 0/17] Add Analogix Core Display Port Driver

2015-10-07 Thread Javier Martinez Canillas

Hello Yakir,

On 10/07/2015 08:25 AM, Yakir Yang wrote:
> Hi all,
> 
> Friendly ping.   :)
> 
> 
> Best regards,
> - Yakir
> 
> 

Do you have a tree that I can use to test these patches?

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal

2015-10-07 Thread Jyri Sarha

On 10/06/15 21:51, Russell King - ARM Linux wrote:
> We at least need some kind of notification system from the video part
> to the other parts, so that we can sanely transmit connect/disconnect/
> edid updates to different parts of the system*not*  that I'm suggesting
> that in the case of the Dove Cubox, seeing a disconnect on HDMI should
> kill the audio - it most_certainly_  _never_  should there, it would be
> utterly insane, and I'm going to play hard-ball on that case.

I am not proposing any automatic mechanism for killing the audio in the 
my hdmi codec patch set. I am merely providing the means for the video 
driver to gracefully abort the audio stream if the driver decides it can 
not support it any more.

For external HDMI encoders that is hardly ever needed, since the CPU DAI 
is usually the bit- and frame-clock master in those cases. The CPU DAI 
can go on banging the bits even if the encoder isn't listening. So we 
can drop the abort_cb() that if it still annoys you after this explanation.

Best regards,
Jyri

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

On 10/7/15, Ville SyrjÃ¤lÃ¤  wrote:
> On Tue, Oct 06, 2015 at 11:42:33AM -0400, Nick Bowler wrote:
>> On 9/24/15, Nick Bowler  wrote:
>> > Testing out 4.3-rc2, first thing I notice is that the VGA output is
>> > not working.  Specifically, the display is continuously powering on
>> > and off -- at no point is any image visible on the screen (I am
>> > expecting to see the console output).  The display connected to the
>> > HDMI output is working fine.
[...]
>>   b8afb9113c519a8bd742f7df8c424b0af69a75cd is the first bad commit
>>   commit b8afb9113c519a8bd742f7df8c424b0af69a75cd
>>   Author: Ville SyrjÃ¤lÃ¤ 
>>   Date:   Mon Jun 29 15:25:48 2015 +0300
>>
>>   drm/i915: Keep GMCH DPLL VGA mode always disabled
[...]
> @@ -1790,13 +1790,13 @@ static void i9xx_disable_pll(struct intel_crtc
> *crtc)
> /* Make sure the pipe isn't still relying on us */
> assert_pipe_disabled(dev_priv, pipe);
>
> -   I915_WRITE(DPLL(pipe), 0);
> +   I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS);
> POSTING_READ(DPLL(pipe));
>  }
>
>
> That hunk is the only relevant part for your machine. Can you try to revert
> just that manually?
>
> But I'm really surprised that would have any effect since we only used
> to enable "VGA mode" when the DPLL is off. And when the DPLL is off,
> there's nothing on the screen anyway.

Nevertheless, manually reverting just that hunk seems to fix it.

Thanks,
  Nick

[Bug 92301] Unigine Sanctuary freeze-crashes R390X

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

--- Comment #13 from MC Return  ---
(In reply to MC Return from comment #11)
> > 
> > It's using the system 32-bit binaries (apparently left over from the oibaf
> > PPA, about one week old snapshot of Git master), because you haven't built
> > any 32-bit binaries yourself.
> 
> I want to ensure that all binaries, including the 32bit ones, are
> self-built, I am rebuilding with the --enable-32-bit flag added right now,
> hope this works...

Nope --enable-32-bit is no longer recognized and I could not find any
instructions on how to ensure a 32bit build...
What flags do I need to add to ./autogen.sh or what needs to be done to to get
that accomplished ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/d4139042/attachment.html>

[PATCH] drm/amdgpu: fix 32-bit compiler warning

2015-10-07 Thread Chris Wilson

On Wed, Oct 07, 2015 at 10:57:11AM +0200, Christian KÃ¶nig wrote:
> On 07.10.2015 09:41, Arnd Bergmann wrote:
> >The new amdgpu driver passes a user space pointer in a 64-bit structure
> >member, which is the correct way to do it, but it attempts to
> >directly cast it to a __user pointer in the kernel, which causes
> >a warning in three places:
> >
> >drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_init':
> >drm/amd/amdgpu/amdgpu_cs.c:180:21: warning: cast to pointer from integer of 
> >different size [-Wint-to-pointer-cast]
> >   chunk_array_user = (uint64_t __user *)(cs->in.chunks);
> >
> >This changes all three to add an intermediate cast to 'unsigned long'
> >as other drivers do. This avoids the warning and works correctly on
> >both 32-bit and 64-bit architectures.
> >
> >Signed-off-by: Arnd Bergmann 
> 
> Well if I'm not completely mistaken this is the second time we need
> to fix this because somebody thought the cast was unnecessary.
> 
> Anyway the patch is Reviewed-by: Christian KÃ¶nig
>  and I'm going to keep an eye open for the
> next time somebody tries to remove this.

We use

static inline void __user *to_user_ptr(u64 address)
{
return (void __user *)(uintptr_t)address;
}

to make the intention clear and hide the cast from prying eyes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal

2015-10-07 Thread Arnaud Pouliquen



>> My approach is the reverse: DRM driver does not need to know anything
>> about audio side. As ALSA is the client of DRM, seems more logical from
>> my point of view ...
>> Now if a generic solution must be found for all video drivers, sure,
>> your solution is more flexible.
>> But if i well understood fbdev drivers are no more accepted for upstream
>> (please correct me if I'm wrong).
>> So i don't know we have to keep fbdev in picture...
>>
>
> I am not promoting fbdev support. I am merely asking if we want to force
> all HDMI drivers to implement a drm_bridge if they want to support audio.
>
Yes this is a good point... My implementation is based on hypothesis 
that HDMI drivers are now upstreamed as DRM drivers.

>>> - HDMI encoder driver implementations that do not use DRM bridge
>>>  abstraction do not need add an extra DRM object just to get the
>>>  audio working.
>>>
>>> Short comings I see in the current HDMI audio bridge approach:
>>>
>>> In its current from the DRM audio bridge abstraction pretends to be a
>>> generic audio abstraction for DRM devices, but the implementation is
>>> quite specific to external HDMI encoders with spdif and/or i2s
>>> interface. There is a lot of HDMI video devices that provide the
>>> digital audio interface (ASoC DAI) directly and there is no need for
>>> anything but dummy codec implementation (if following ASoC
>>> paradigm). Before going forward I think we should at least consider
>>> how this abstraction would serve those devices.
>> Sorry, but i don't see any difference between both implementations for
>> this point.In both implementations, ops are called only if defined.
>> Could you give me name of the drivers you have in mind?
>
> I am not talking about Beaglebone-Black or tda998x here. There are
> platforms where video HW provides the digital audio interface for HDMI
> audio directly. For instance OMAP4 and OMAP5 (see
> sound/soc/omap/omap-hdmi-audio.c and drivers/video/fbdev/omap2/dss/) are
> like that.
Not checked in details but seems similar to your approach except ops 
used by cpu_dai.

>
>>>
>>> Also, I am not entirely happy how the drm_audio_bridge_funcs are used
>>> at the moment. The do not map too well to ASoC DAI callbacks and I do
>>> not see too much point in creating a completely new audio-callback
>>> abstraction, that is sligtly incompatible with ALSA, and then
>>> translating alsa callbacks to these new callbacks. I think the
>>> callbacks should map more or less directly ALSA callbacks.
>>
>> As API is defined in DRM, it seems more logical to match it with the one
>> defined for video. From my windows, i didn't see any blocking point to
>> connect codec callback with this API.
>> But anyway, this API is not freezed, it could be improved with your help.
>
> The most usual things can be made to work with your API too, but the
> translation is not the most efficient one and some features are missing,
> for instance muting.
Could be added but is it necessary if trigger is implemented?( see my 
next comments)

> Also, in ALSA side the prepare and trigger
> callbacks are meant to be used only for starting and stopping the audio
> stream.
Yes but for me, it is required. Otherwise how to manage CPU-DAI master 
configuration?
if stream is stopped, cpu_dai can be stopped as there is no more stream 
to sent on bus. If no information is sent to HDMI, This generates HDMI 
codec or protocol issue...
Use startup/shutdown/digital_mute seems not sufficient.

The stream is configured before either one of those are called.
> With your API each pause+resume from a video client will reconfigure the
> audio from the scratch.
Configuration is sent using pre_enable operation. So no reconfiguration 
should be re-applied.

Best Regards
Arnaud

[PATCH 08/12] drm: bridge/dw_hdmi: avoid enabling interface in mode_set

On Wed, Oct 07, 2015 at 11:50:53AM +0800, Yakir Yang wrote:
> 
> 
> On 08/09/2015 12:04 AM, Russell King wrote:
> >On a mode set, DRM makes the following sequence of calls:
> >* for_each_encoder
> >*   bridge   mode_fixup
> >*   encoder  mode_fixup
> >* crtc   mode_fixup
> >* for_each_encoder
> >*   bridge   disable
> >*   encoder  prepare
> >*   bridge   post_disable
> >* disable unused encoders
> >* crtc   prepare
> >* crtc   mode_set
> >* for_each_encoder
> >*   encoder  mode_set
> >*   bridge   mode_set
> >* crtc   commit
> >* for_each_encoder
> >*   bridge   pre_enable
> >*   encoder  commit
> >*   bridge   enable
> >
> >dw_hdmi enables the HDMI output in both the bridge mode_set() and also
> >the bridge enable() step.  This is duplicated work - we can avoid the
> >setup in mode_set() and just do it in the enable() stage.  This
> >simplifies the code a little.
> >
> >Signed-off-by: Russell King 
> 
> I have noticed that dw_hdmi driver have poweron/poweroff when
> driver detect HPD event in irq thread, that's also duplicated works,
> would you like to collect that changes into this one:
> 
> static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> {
> ..
> 
> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
> if (phy_int_pol & HDMI_PHY_HPD) {
> dev_dbg(hdmi->dev, "EVENT=plugin\n");
> 
> hdmi_modb(hdmi, 0, HDMI_PHY_HPD, HDMI_PHY_POL0);
> 
> dw_hdmi_poweron(hdmi);// no need here
> } else {
> dev_dbg(hdmi->dev, "EVENT=plugout\n");
> 
> hdmi_modb(hdmi, HDMI_PHY_HPD, HDMI_PHY_HPD,
>   HDMI_PHY_POL0);
> 
> dw_hdmi_poweroff(hdmi);// no need here
> }
> drm_helper_hpd_irq_event(hdmi->connector.dev);
> }
> ..
> }

I'm very much of the opinion of making small logical changes.  This
patch is one small logical change to the DRM-side logic to get rid
of the identified duplication there without touching anything else.
If removing the above calls to dw_hdmi_poweron()/dw_hdmi_poweroff()
were found to cause a regression, then the whole change would end
up being reverted, which would be annoying.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Bug 92301] Unigine Sanctuary freeze-crashes R390X

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

--- Comment #12 from MC Return  ---
(In reply to Michel DÃ¤nzer from comment #10)
> (In reply to MC Return from comment #8)
> > GLShader::loadFragment(): error in
> > "core/shaders/render/fragment_occlusion_blur.shader" file
> > defines:
> > UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,
> > USE_TEXTURE_ARRAY,USE_DEFERRED,USE_TRANSLUCENT,USE_PARALLAX,USE_OCCLUSION,
> > USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,
> > USE_ARB_SAMPLE_SHADING,USE_ARB_TEXTURE_MULTISAMPLE,HAS_ARB_DRAW_INSTANCED
> > 0:511(15): error: no function with name 'texelFetch2DOffset'
> 
> These errors may indicate that it's not picking up the correct drirc
> configuration. Does it work if you set the following environment variables
> for running it:
> 
> LIBGL_DEBUG=verbose force_glsl_extensions_warn=true
> disable_blend_func_extended=true
> 
> If not, please provide the corresponding terminal output and log file again.

I set those env vars, but the result was exactly the same - sanctuary crashed
the machine after a few seconds running, but it showed these errors after
changing screens to console mode:

[drm: ci_dpm_enable [radeon]] *ERROR* ci_start_dpm failed
[drm: radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume failed
[drm: radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume failed

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/e64d1e2d/attachment-0001.html>

[Bug 94471] Displayport monitor randomly disconnects

2015-10-07 Thread bugzilla-dae...@bugzilla.kernel.org

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

Jani Nikula  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #5 from Jani Nikula  ---
Long time no updates, closing.

If the problem persists with latest kernels, please file a bug at the
freedesktop.org bugzilla [1], referencing this bug. Thank you.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 92301] Unigine Sanctuary freeze-crashes R390X

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

--- Comment #11 from MC Return  ---
> 
> It's using the system 32-bit binaries (apparently left over from the oibaf
> PPA, about one week old snapshot of Git master), because you haven't built
> any 32-bit binaries yourself.

I want to ensure that all binaries, including the 32bit ones, are self-built, I
am rebuilding with the --enable-32-bit flag added right now, hope this works...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/a8dea971/attachment.html>

[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal

On Wed, Oct 07, 2015 at 09:48:42AM +0200, Arnaud Pouliquen wrote:
> Should ALSA bypasses or not the DRM core/API to access to DRM HDMI
> connector?

You don't need direct access to the connector - and actually, having
direct access to the connector is potentially racy.  So no.

> Concerning bridge usage, I tried to found a link to address DRM driver
> trough DRM API. Bridge seemed a good candidate. Perhaps the DRM encoder API
> could be an other option to study...

Different parts of DRM don't help you with this: whether it's a connector,
encoder or bridge, you still need some way to get information in and out
from the HDMI video component to both HDMI audio and HDMI CEC components.

Please start seeing that the problem you have in front of you covers more
than _just_ audio.  If you design it just for audio, then we'll probably
have to redesign it when addressing CEC support.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] drm/amdgpu: fix 32-bit compiler warning

2015-10-07 Thread Alex Deucher

On Wed, Oct 7, 2015 at 5:18 AM, Arnd Bergmann  wrote:
> On Wednesday 07 October 2015 10:57:11 Christian KÃ¶nig wrote:
>> On 07.10.2015 09:41, Arnd Bergmann wrote:
>> > The new amdgpu driver passes a user space pointer in a 64-bit structure
>> > member, which is the correct way to do it, but it attempts to
>> > directly cast it to a __user pointer in the kernel, which causes
>> > a warning in three places:
>> >
>> > drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_init':
>> > drm/amd/amdgpu/amdgpu_cs.c:180:21: warning: cast to pointer from integer 
>> > of different size [-Wint-to-pointer-cast]
>> >chunk_array_user = (uint64_t __user *)(cs->in.chunks);
>> >
>> > This changes all three to add an intermediate cast to 'unsigned long'
>> > as other drivers do. This avoids the warning and works correctly on
>> > both 32-bit and 64-bit architectures.
>> >
>> > Signed-off-by: Arnd Bergmann 
>>
>> Well if I'm not completely mistaken this is the second time we need to
>> fix this because somebody thought the cast was unnecessary.
>>
>> Anyway the patch is Reviewed-by: Christian KÃ¶nig
>>  and I'm going to keep an eye open for the
>> next time somebody tries to remove this.
>>
>
> Ok, thanks.
>
> I guess I should have added
>
> Fixes: e60b344f6c0eff ("drm/amdgpu: optimize amdgpu_parser_init")

Applied this that comment added.

Thanks!

Alex

>
> Arnd
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] [RFC] drm/doc: Rename docbook to gpu.tmpl

DRM is a lot more than a direct manager nowadays, and there's also a
bunch of things worth documenting for gpu driver developers outside of
drivers/gpu/drm, like vgaarb, vga switcheroo or the various hardware
buses like host1x and ipu-v3.

To avoid further confusion let's rename the top-level to reflect
reality.

And yes I'm already looking forward to when we need to replace the G
in GPU with a * ;-)

Inspired by a thread with Lukas since he refused to include the vga
switcheroo docs into the gpu docs because it's not drm.

Cc: Lukas Wunner 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/Makefile |4 +-
 Documentation/DocBook/drm.tmpl | 4129 
 Documentation/DocBook/gpu.tmpl | 4129 
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +
 4 files changed, 4133 insertions(+), 4131 deletions(-)
 delete mode 100644 Documentation/DocBook/drm.tmpl
 create mode 100644 Documentation/DocBook/gpu.tmpl

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 75b7d9b557b1..2088200badcb 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -14,10 +14,10 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
-   tracepoint.xml drm.xml media_api.xml w1.xml \
+   tracepoint.xml gpu.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml

-MARKDOWNREADY := drm.xml
+MARKDOWNREADY := gpu.xml

 include Documentation/DocBook/media/Makefile

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
deleted file mode 100644
index 6d24ebb97cda..
--- a/Documentation/DocBook/drm.tmpl
+++ /dev/null
@@ -1,4129 +0,0 @@
-
-http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []>
-
-
-  
-Linux DRM Developer's Guide
-
-
-  
-   Jesse
-   Barnes
-   Initial version
-   
- Intel Corporation
- 
-   jesse.barnes at intel.com
- 
-   
-  
-  
-   Laurent
-   Pinchart
-   Driver internals
-   
- Ideas on board SPRL
- 
-   laurent.pinchart at ideasonboard.com
- 
-   
-  
-  
-   Daniel
-   Vetter
-   Contributions all over the place
-   
- Intel Corporation
- 
-   daniel.vetter at ffwll.ch
- 
-   
-  
-
-
-
-  2008-2009
-  2013-2014
-  Intel Corporation
-
-
-  2012
-  Laurent Pinchart
-
-
-
-  
-   The contents of this file may be used under the terms of the GNU
-   General Public License version 2 (the "GPL") as distributed in
-   the kernel source COPYING file.
-  
-
-
-
-  
-  
-   1.0
-   2012-07-13
-   LP
-   Added extensive documentation about driver internals.
-   
-  
-
-  
-
-
-
-
-  DRM Core
-  
-
-  This first part of the DRM Developer's Guide documents core DRM code,
-  helper libraries for writing drivers and generic userspace interfaces
-  exposed by DRM drivers.
-
-  
-
-  
-Introduction
-
-  The Linux DRM layer contains code intended to support the needs
-  of complex graphics devices, usually containing programmable
-  pipelines well suited to 3D graphics acceleration.  Graphics
-  drivers in the kernel may make use of DRM functions to make
-  tasks like memory management, interrupt handling and DMA easier,
-  and provide a uniform interface to applications.
-
-
-  A note on versions: this guide covers features found in the DRM
-  tree, including the TTM memory manager, output configuration and
-  mode setting, and the new vblank internals, in addition to all
-  the regular features found in current kernels.
-
-
-  [Insert diagram of typical DRM stack here]
-
-  
-
-  
-
-  
-DRM Internals
-
-  This chapter documents DRM internals relevant to driver authors
-  and developers working to add support for the latest features to
-  existing drivers.
-
-
-  First, we go over some typical driver initialization
-  requirements, like setting up command buffers, creating an
-  initial output configuration, and initializing core services.
-  Subsequent sections cover core internals in more detail,
-  providing implementation notes and examples.
-
-
-  The DRM layer provides several services to graphics drivers,
-  many of them driven by the application interfaces it provides
-  through libdrm, the library that wraps most of the DRM ioctls.
-  These include vblank event handling, memory
-  management, output management, framebuffer management, command
-  s

[PATCH RFC 2/5] drm/doc: Rename docbook to gpu.tmpl

2015-10-07 Thread Lukas Wunner

From: Daniel Vetter 

DRM is a lot more than a direct rendering manager nowadays, and there's
also a bunch of things worth documenting for gpu driver developers
outside of drivers/gpu/drm, like vgaarb, vga_switcheroo or the various
hardware buses like host1x and ipu-v3.

To avoid further confusion let's rename the top-level to reflect
reality.

And yes I'm already looking forward to when we need to replace the G
in GPU with a * ;-)

Inspired by a thread with Lukas since he refused to include the
vga_switcheroo docs into the drm docs because it's not drm.

Cc: Lukas Wunner 
Signed-off-by: Daniel Vetter 
[Lukas: Drop BUG() easter egg in i915_gem_execbuffer.c spotted by Jani
and fix typos in commit message.]
Signed-off-by: Lukas Wunner 
---
 Documentation/DocBook/Makefile |4 +-
 Documentation/DocBook/drm.tmpl | 4189 
 Documentation/DocBook/gpu.tmpl | 4189 
 3 files changed, 4191 insertions(+), 4191 deletions(-)
 delete mode 100644 Documentation/DocBook/drm.tmpl
 create mode 100644 Documentation/DocBook/gpu.tmpl

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 75b7d9b..2088200 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -14,10 +14,10 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
-   tracepoint.xml drm.xml media_api.xml w1.xml \
+   tracepoint.xml gpu.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml

-MARKDOWNREADY := drm.xml
+MARKDOWNREADY := gpu.xml

 include Documentation/DocBook/media/Makefile

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
deleted file mode 100644
index da1060c..000
--- a/Documentation/DocBook/drm.tmpl
+++ /dev/null
@@ -1,4189 +0,0 @@
-
-http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []>
-
-
-  
-Linux DRM Developer's Guide
-
-
-  
-   Jesse
-   Barnes
-   Initial version
-   
- Intel Corporation
- 
-   jesse.barnes at intel.com
- 
-   
-  
-  
-   Laurent
-   Pinchart
-   Driver internals
-   
- Ideas on board SPRL
- 
-   laurent.pinchart at ideasonboard.com
- 
-   
-  
-  
-   Daniel
-   Vetter
-   Contributions all over the place
-   
- Intel Corporation
- 
-   daniel.vetter at ffwll.ch
- 
-   
-  
-
-
-
-  2008-2009
-  2013-2014
-  Intel Corporation
-
-
-  2012
-  Laurent Pinchart
-
-
-
-  
-   The contents of this file may be used under the terms of the GNU
-   General Public License version 2 (the "GPL") as distributed in
-   the kernel source COPYING file.
-  
-
-
-
-  
-  
-   1.0
-   2012-07-13
-   LP
-   Added extensive documentation about driver internals.
-   
-  
-
-  
-
-
-
-
-  DRM Core
-  
-
-  This first part of the DRM Developer's Guide documents core DRM code,
-  helper libraries for writing drivers and generic userspace interfaces
-  exposed by DRM drivers.
-
-  
-
-  
-Introduction
-
-  The Linux DRM layer contains code intended to support the needs
-  of complex graphics devices, usually containing programmable
-  pipelines well suited to 3D graphics acceleration.  Graphics
-  drivers in the kernel may make use of DRM functions to make
-  tasks like memory management, interrupt handling and DMA easier,
-  and provide a uniform interface to applications.
-
-
-  A note on versions: this guide covers features found in the DRM
-  tree, including the TTM memory manager, output configuration and
-  mode setting, and the new vblank internals, in addition to all
-  the regular features found in current kernels.
-
-
-  [Insert diagram of typical DRM stack here]
-
-  
-
-  
-
-  
-DRM Internals
-
-  This chapter documents DRM internals relevant to driver authors
-  and developers working to add support for the latest features to
-  existing drivers.
-
-
-  First, we go over some typical driver initialization
-  requirements, like setting up command buffers, creating an
-  initial output configuration, and initializing core services.
-  Subsequent sections cover core internals in more detail,
-  providing implementation notes and examples.
-
-
-  The DRM layer provides several services to graphics drivers,
-  many of them driven by the application interfaces it provides
-  through libdrm, the library that wraps most of the DRM ioctls.
-  These include vblank event handling, memo

[PATCH v3 1/6] vga_switcheroo: Add support for switching only the DDC

On Tue, Oct 06, 2015 at 08:27:44PM +0200, Lukas Wunner wrote:
> Hi Daniel,
> 
> On Tue, Oct 06, 2015 at 01:10:00PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 06, 2015 at 12:10:48PM +0200, Lukas Wunner wrote:
> > > On Tue, Oct 06, 2015 at 09:27:24AM +0200, Daniel Vetter wrote:
> > > > Also while reading the patch I realized that the new lock really 
> > > > protects
> > > > hw state (instead of our software-side tracking and driver 
> > > > resume/suspend
> > > > code). And at least myself I have no idea what vgasr means, so what 
> > > > about
> > > > renaming it to hw_mutex? We have this pattern of low-level locks to 
> > > > avoid
> > > > concurrent hw access in a lot of places like i2c, dp_aux, and it's very
> > > > often called hw_lock or similar.
> > > 
> > > Hm, hw_lock sounds a bit ambiguous.
> > > 
> > > vgasr_mutex is really a catch-all that protects access to the vgasr_priv
> > > structure and also protects various hardware state. (Power state of each
> > > GPU, mux state.) Up until now this approach worked fine, it looks like
> > > there was no need for additional locks. We may need to move to more
> > > fine-grained locking as new features get added to vga_switcheroo.
> > > The newly introduced ddc_lock is a first step and I think is aptly
> > > named since it only protects the mux state for the DDC lines.
> > 
> > Oops sorry mixed up the names. I meant rename the ddc_lock to hw_lock
> > since it protects a bit more than just the ddc (it protects the entire hw
> > switch state since we grab it both for dcc switching and for full-blown
> > switching of everything).
> 
> Interesting observation. Actually the intention is to use ddc_lock to
> only lock hardware state of the DDC switch, but you're right, it also
> locks hardware state of the panel switch. That's an unintended
> consequence of the ->switchto callback in apple-gmux also switching
> DDC, and the need to avoid races because of this.
> 
> Now that you mention it I'm contemplating removing DDC switching from the
> ->switchto callback in apple-gmux. Then I don't need to take the ddc_lock
> when switching the full panel.

I think switching everything together makes some sense, but either way
should be find.

> > > > Also, the revised docbook patch seems to be missing from this iteration,
> > > > please follow up with that one.
> > > 
> > > The docbook patch posted September 17 automatically picks up the
> > > kernel-doc for the new functions through the !E directive.
> > 
> > I asked for the inclusion to be moved to drm.tmpl instead of creating a
> > new docbook.
> 
> Your argument was that including it in drm.tmpl will increase the chances
> it's read. Quite honestly I think that reasoning is a bit thin. One might
> as well argue that people won't find the information in the juggernaut of
> 180 kByte XML text that is drm.tmpl.
> 
> The (honest) question is this, vga_switcheroo is not located in the DRM
> tree, so it's a separate subsystem. Then why should someone be looking
> for its documentation in the DRM DocBook?

DRM has essentially become the gfx subsystem of the kernel, the name is
purely historical accident. And DRM maintainers generally take care of
everything under drivers/gpu/* so I think it makes sense to include it
there.

If you think the DRM in the docbook is confusing then we can fix that
easily by renaming it to gpu.tmpl and GPU Developer's Guide. Actually that
seems like a decent idea, so let me write that patch.

> > > By the way, Jani has kindly provided a Reviewed-By: for patch 6 of
> > > the vga_switcheroo docs series. The patch is not dependent on the
> > > preceding patch 5 which is awaiting an ack from Takashi, so could
> > > be merged now:
> > > [PATCH 06/15] vga_switcheroo: Use enum vga_switcheroo_state instead
> > > 
> > > Patches 7 and 8 are similarly trivial cleanups:
> > > [PATCH 07/15] vga_switcheroo: Use VGA_SWITCHEROO_UNKNOWN_ID instead
> > > [PATCH 08/15] vga_switcheroo: Use enum vga_switcheroo_client_id
> > > 
> > > And patch 10 has gotten a Reviewed-By: from Takashi:
> > > [PATCH 10/15] ALSA: hda - Spell vga_switcheroo consistently
> > 
> > Hm those patches aren't in this series, that makes it really hard for me
> > to know what's still pending. I think it would be best to resend
> > _everything_, so including docs and cleanups and all that. Otherwise I
> > think this will take a lot longer than necessary to pull in.
> 
> I updated my vga_switcheroo_docs branch on GitHub as the Reviewed-Bys
> came in and just rebased it to current topic/drm-misc, so you can pull
> from there if you're comfortable with that:
> https://github.com/l1k/linux/commits/vga_switcheroo_docs
> 
> If on the other hand you prefer merging stuff via the mailing list,
> I'll be happy to resend.

Mailing list is highly preferred.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal

2015-10-07 Thread Arnaud Pouliquen


On 10/06/2015 04:33 PM, Jean-Francois Moine wrote:
> On Tue, 6 Oct 2015 11:23:03 +0200
> Arnaud Pouliquen  wrote:
>   [snip]
>> As API is defined in DRM, it seems more logical to match it with the one
>> defined for video. From my windows, i didn't see any blocking point to
>> connect codec callback with this API.
>> But anyway, this API is not freezed, it could be improved with your help.
>
> Arnaud, your implementation seems more heavy than Jyri's, and I don't
> feel the DRM bridge.
>
> For HDMI, the exchanges between DRM and ALSA are only:
> - DRM -> ALSA
>- device connection with the audio constraints
>- device disconnection
> - ALSA -> DRM
>- start audio with the chosen audio parameters
>- stop audio
>
> and, in the system, the HDMI devices are seen as DRM connectors (video
> view) and as ASoC CODECs (audio view).
>
> We just need a link between these entities.
> I don't think that the bridge offers this.
Not so heavy...
In fact another way to differentiate the twice approaches could be to
answer to this question:
Should ALSA bypasses or not the DRM core/API to access to DRM HDMI 
connector?

Concerning bridge usage, I tried to found a link to address DRM driver 
trough DRM API. Bridge seemed a good candidate. Perhaps the DRM encoder 
API could be an other option to study...

Ken ar wech all/ best Regards
Arnaud

[PATCH] drm/amdgpu: fix 32-bit compiler warning

The new amdgpu driver passes a user space pointer in a 64-bit structure
member, which is the correct way to do it, but it attempts to
directly cast it to a __user pointer in the kernel, which causes
a warning in three places:

drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_init':
drm/amd/amdgpu/amdgpu_cs.c:180:21: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
  chunk_array_user = (uint64_t __user *)(cs->in.chunks);

This changes all three to add an intermediate cast to 'unsigned long'
as other drivers do. This avoids the warning and works correctly on
both 32-bit and 64-bit architectures.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index cb3c274edb0a..fd16652aa277 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -177,7 +177,7 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void 
*data)

/* get chunks */
INIT_LIST_HEAD(&p->validated);
-   chunk_array_user = (uint64_t __user *)(cs->in.chunks);
+   chunk_array_user = (uint64_t __user *)(unsigned long)(cs->in.chunks);
if (copy_from_user(chunk_array, chunk_array_user,
   sizeof(uint64_t)*cs->in.num_chunks)) {
ret = -EFAULT;
@@ -197,7 +197,7 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void 
*data)
struct drm_amdgpu_cs_chunk user_chunk;
uint32_t __user *cdata;

-   chunk_ptr = (void __user *)chunk_array[i];
+   chunk_ptr = (void __user *)(unsigned long)chunk_array[i];
if (copy_from_user(&user_chunk, chunk_ptr,
   sizeof(struct drm_amdgpu_cs_chunk))) {
ret = -EFAULT;
@@ -208,7 +208,7 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void 
*data)
p->chunks[i].length_dw = user_chunk.length_dw;

size = p->chunks[i].length_dw;
-   cdata = (void __user *)user_chunk.chunk_data;
+   cdata = (void __user *)(unsigned long)user_chunk.chunk_data;
p->chunks[i].user_ptr = cdata;

p->chunks[i].kdata = drm_malloc_ab(size, sizeof(uint32_t));

i.mx6 video out in mainline

2015-10-07 Thread Lucas Stach

Am Dienstag, den 06.10.2015, 16:02 -0700 schrieb Pushpal Sidhu:
> On Tue, Oct 6, 2015 at 3:16 PM, Fabio Estevam 
> wrote:
> > On Tue, Oct 6, 2015 at 6:52 PM, Pushpal Sidhu  > > wrote:
> > > Hi All,
> > > 
> > > I'm attempting to use a standard fb console (using the
> > > imx6qdl-gw54xx.dtsi), but I find that it only draws to the
> > > 1024x768p
> > > portion of the screen. This is also true when running the
> > > userspace
> > > tool fb-test.
> > 
> > Looking at imx6qdl-gw54xx.dtsi I see you have a LVDS panel with
> > 1024x768 resolution.
> > 
> > I sent a patch that allows LDB and HDMI to work simultaneously:
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
> > mit/arch/arm/boot/dts/imx6qdl
> > -sabresd.dtsi?id=d28be499c45e6e16d7a042ce280eb872dc06952b
> > 
> > Can you try to adapt it for imx6qdl-gw54xx.dtsi?
> > 
> > If this still does not help your HDMI output, please try disabling
> > the LVDS.
> 
> When I took your patch and adapted it for imx6qdl-gw54xx.dtsi, I
> found
> that HDMI video out was slightly shifted to the left and resolution
> remained at 1024x768p.
> 
> I also found that when I disabled DRM_IMX_LDB, HDMI out stopped
> working altogether, though if I stripped out the ldb section in
> device
> tree, the resolution comes back at 1080p (regardless of setting
> DRM_IMX_LDB or not). There is definitely some strange interdependency
> between lvds and hdmi here. Do you have an idea of where I should
> start looking for this problem?
> 
This isn't strange, but actually really simple to explain:

1. The DRM driver is a componentized driver that needs all of its
components to come up before it registers the DRM device. So if you
have the LDB enabled in your DT you also need the LDB driver, otherwise
you won't get any video out. If you don't want to have LDB, don't
disable the driver alone, but also add a status = "disabled" in the DT
LDB node.

2. The kernels framebuffer emulation layer will try to put the
framebuffer on both displays. So if you have a smaller LVDS display
connected the framebuffer will only have the size of the smaller
display. Solution is to not depend on the kernels frambuffer emulation,
but actually set a mode from userspace and work with the KMS interface
directly.

Regards,
Lucas

[Bug 105581] amdgpu: r9 380 Dual Monitor Setup: rotation not working

2015-10-07 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #2 from Michel DÃ¤nzer  ---
FWIW, rotation doesn't work because glamor fails to initialize, so all hardware
acceleration is disabled (I posted a xf86-video-amdgpu patch to not advertise
rotation capability in this case). Looks like Mesa is either misconfigured or
too old for your card.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 105601] drm_wait_vblank log spam with reverse PRIME (intel+nouveau)

2015-10-07 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #2 from Matthias Schiffer  
---
Thanks for the quick reply, I'll open a bug report there.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 92086] AMD Trinity No screen at HDMI after S3 wakeup

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

--- Comment #8 from BalÃ¡zs Vinarz  ---
Created attachment 118728
  --> https://bugs.freedesktop.org/attachment.cgi?id=118728&action=edit
pmagic.xorg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/302b1067/attachment.html>

[Bug 92086] AMD Trinity No screen at HDMI after S3 wakeup

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

--- Comment #7 from BalÃ¡zs Vinarz  ---
Created attachment 118727
  --> https://bugs.freedesktop.org/attachment.cgi?id=118727&action=edit
pmagic.dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/22de9776/attachment.html>

[Bug 92086] AMD Trinity No screen at HDMI after S3 wakeup

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

--- Comment #6 from BalÃ¡zs Vinarz  ---
Update: 
The same behavior, if the first monitor connected to Displayport(+HDMI
adapter).
Partedmagic dmesg and Xorg also added.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/59694cd5/attachment.html>

[Bug 92301] Unigine Sanctuary freeze-crashes R390X

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

--- Comment #10 from Michel DÃ¤nzer  ---
(In reply to MC Return from comment #8)
> GLShader::loadFragment(): error in
> "core/shaders/render/fragment_occlusion_blur.shader" file
> defines:
> UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,
> USE_TEXTURE_ARRAY,USE_DEFERRED,USE_TRANSLUCENT,USE_PARALLAX,USE_OCCLUSION,
> USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,
> USE_ARB_SAMPLE_SHADING,USE_ARB_TEXTURE_MULTISAMPLE,HAS_ARB_DRAW_INSTANCED
> 0:511(15): error: no function with name 'texelFetch2DOffset'

These errors may indicate that it's not picking up the correct drirc
configuration. Does it work if you set the following environment variables for
running it:

LIBGL_DEBUG=verbose force_glsl_extensions_warn=true
disable_blend_func_extended=true

If not, please provide the corresponding terminal output and log file again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151007/ee727016/attachment.html>

[Bug 92301] Unigine Sanctuary freeze-crashes R390X