drm/i915: Decouple execbuf uAPI from internal implementation

2016-01-29 Thread Dan Carpenter
Hello Tvrtko Ursulin,

The patch de1add360522: "drm/i915: Decouple execbuf uAPI from
internal implementation" from Jan 15, 2016, leads to the following
static checker warning:

drivers/gpu/drm/i915/i915_gem_execbuffer.c:1411 eb_select_ring()
warn: buffer overflow 'dev_priv->ring' 5 <= 16385

drivers/gpu/drm/i915/i915_gem_execbuffer.c
  1397  if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
  1398  unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
  1399  
  1400  if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
  1401  bsd_idx = gen8_dispatch_bsd_ring(dev_priv, 
file);
  1402  } else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
  1403 bsd_idx <= I915_EXEC_BSD_RING2) {
  1404  bsd_idx--;
^
This should probablye be "bsd_idx = (bsd_idx >> 13) - 1;" or something.

  1405  } else {
  1406  DRM_DEBUG("execbuf with unknown bsd ring: %u\n",
  1407bsd_idx);
  1408  return -EINVAL;
  1409  }
  1410  
  1411  *ring = &dev_priv->ring[_VCS(bsd_idx)];

Otherwise we're way past the end of this array.

  1412  } else {
  1413  *ring = &dev_priv->ring[user_ring_map[user_ring_id]];
  1414  }
  1415  
  1416  if (!intel_ring_initialized(*ring)) {
  1417  DRM_DEBUG("execbuf with invalid ring: %u\n", 
user_ring_id);
  1418  return -EINVAL;
  1419  }

regards,
dan carpenter


[git pull] drm fixes

2016-01-29 Thread Dave Airlie

Hi Linus,

Misc amdgpu/radeon fixes,
VC4 build fix
vmwgfx fix
misc rockchip fixes,

The etnaviv guys had an API feature they wanted in their first release, so
I've merged that with their fixes.

Dave.

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to d8b8eb829d4c30cd1e41a1ddc308a0e7c22169da:

  Merge branch 'drm-rockchip-next-fixes-2016-01-22' of 
https://github.com/markyzq/kernel-drm-rockchip into drm-fixes (2016-01-29 
10:04:29 +1000)


Alex Deucher (5):
  drm/amdgpu: fix tonga smu resume
  drm/amdgpu: Add some tweaks to gfx 8 soft reset
  drm/amdgpu: add a message to indicate when powerplay is enabled (v2)
  drm/radeon: properly byte swap vce firmware setup
  drm/amdgpu: don't init fbdev if we don't have any connectors

Andrzej Hajda (1):
  drm/rockchip/dsi: fix handling mipi_dsi_pixel_format_to_bpp result

Christian König (2):
  drm/amdgpu: fix amdgpu_bo_pin_restricted VRAM placing v2
  drm/amdgpu: fix next_rptr handling for debugfs

Dave Airlie (4):
  Merge branch 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'drm-etnaviv-fixes' of 
git://git.pengutronix.de/git/lst/linux into drm-fixes
  Merge tag 'drm-vc4-fixes-2015-01-19' of http://github.com/anholt/linux 
into drm-fixes
  Merge branch 'drm-rockchip-next-fixes-2016-01-22' of 
https://github.com/markyzq/kernel-drm-rockchip into drm-fixes

Eric Anholt (1):
  drm/vc4: Remove broken attempt at GPU reset using genpd.

Eric Huang (1):
  drm/amd/amdgpu: Improve amdgpu_dpm* macros to avoid unexpected result (v2)

Fabio Estevam (1):
  drm/etnaviv: remove owner assignment from platform_driver

John Keeping (5):
  drm/rockchip: vop: fix mask when updating interrupts
  drm/atomic-helper: Export framebuffer_changed()
  drm/rockchip: don't wait for vblank if fb hasn't changed
  drm/rockchip: explain why we can't wait_for_vblanks
  drm/rockchip: respect CONFIG_DRM_FBDEV_EMULATION

Jordan Lazare (1):
  drm/amdgpu: Allow the driver to load if amdgpu.powerplay=1 on asics 
without powerplay support

Lucas Stach (5):
  drm/etnaviv: hold object lock while getting pages for coredump
  drm/etnaviv: fix memory leak in IOMMU init path
  drm/etnaviv: fix get pages error path in etnaviv_gem_vaddr
  drm/etnaviv: rename etnaviv_gem_vaddr to etnaviv_gem_vmap
  drm/etnaviv: call correct function when trying to vmap a DMABUF

Mark Yao (3):
  drm/rockchip: Don't build rockchip_drm_vop as modules
  drm/rockchip: cleanup unnecessary export symbol
  drm/rockchip: fix wrong pitch/size using on gem

Matthew Dawson (1):
  drm/radeon: Ensure radeon bo is unreserved in radeon_gem_va_ioctl

Michel Dänzer (1):
  drm/amdgpu: Use drm_calloc_large for VM page_tables array

Nicolai Hähnle (1):
  drm/amdgpu: only move pt bos in LRU list on success

Rex Zhu (1):
  drm/amd/powerplay: Update SMU firmware loading for Stoney

Rob Clark (2):
  drm/radeon: only init fbdev if we have connectors
  drm/vmwgfx: respect 'nomodeset'

Russell King (7):
  drm/etnaviv: fix failure path if model is zero
  drm/etnaviv: ignore VG GPUs with FE2.0
  drm/etnaviv: update common and state_hi xml.h files
  drm/etnaviv: use defined constants for the chip model
  drm/etnaviv: add helper to extract bitfields
  drm/etnaviv: add helper for comparing model/revision IDs
  drm/etnaviv: add further minor features and varyings count

Slava Grigorev (3):
  drm/radeon: cleaned up VCO output settings for DP audio
  drm/radeon: Add a common function for DFS handling
  drm/radeon: fix DP audio support for APU with DCE4.1 display engine

 drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  44 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c   |   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c   |   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c|  25 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   |   7 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c|  23 ++-
 drivers/gpu/drm/amd/amdgpu/tonga_dpm.c   |  17 +-
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c|   5 +
 drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c |  41 +++--
 drivers/gpu/drm/drm_atomic_helper.c  |  24 ++-
 drivers/gpu/drm/etnaviv/common.xml.h |  59 ++-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c|   1 -
 drivers/gpu/drm/etnaviv/etnaviv_drv.h|   2 +-
 drivers/gpu/drm/etnaviv/etnaviv_dump.c   |   6 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.c|  36 +++--
 drivers/gpu/

[PATCH v7 0/2] Add Rockchip Inno-HDMI driver

2016-01-29 Thread Mark yao
On 2016年01月26日 10:59, Yakir Yang wrote:
> Here are a brief introduction to Innosilicon HDMI IP:
>- Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
>- Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
>- Digital video interface supports a pixel size of 24, 30, 36, 48bits 
> color depth in RGB
>- S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission
>  (32-192kHz Fs) using IEC60958 and IEC 61937
>- The EDID and CEC function are also supported by Innosilicon HDMI 
> Transmitter Controlle
>
> Changes in v7:
> - Correct the module licnese statement (Paul)
>   - MODULE_LICENSE("GPL");
>   + MODULE_LICENSE("GPL v2");
> - Start indentation with tabs and fix the misspell in Kconfig (Paul)
> - Carry the lost device-binding document (Heiko)
>
> Changes in v6:
> - Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver 
> (Caeser)
>
> Changes in v5:
> - Use hdmi_infoframe helper functions to packed the infoframe (Russell)
> - Remove the unused double wait_for_completion_timeout for ddc transfer 
> (Russell)
> - Remove the unused local variable in "inno_hdmi_i2c_write()" function 
> (Russell)
>
> Changes in v4:
> - Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
> - Correct the "DKMS" to "DPMS" (Mark)
> - Fix over 80 characters problems (Mark)
> - Remove encoder .prepare/.commit helper functions, and move the vop mode
> configure function into encoder .enable helper functions. (Mark)
>
> Changes in v3:
> - Use encoder enable/disable function, and remove the encoder DPMS function
> - Keep HDMI PLL power on in standby mode
>
> Changes in v2:
> - Using DRM atomic helper functions for connector init (Mark)
> - Remove "hdmi->connector.encoder = encoder;" (Mark)
> - Add the Acked-by tags from Rob
> - Correct the misspell "rk3036-dw-hdmi" (Heiko)
>
> Yakir Yang (2):
>drm/rockchip: hdmi: add Innosilicon HDMI support
>dt-bindings: add document for Innosilicon HDMI on Rockchip platform
>
>   .../display/rockchip/inno_hdmi-rockchip.txt|  50 ++
>   drivers/gpu/drm/rockchip/Kconfig   |   8 +
>   drivers/gpu/drm/rockchip/Makefile  |   1 +
>   drivers/gpu/drm/rockchip/inno_hdmi.c   | 941 
> +
>   drivers/gpu/drm/rockchip/inno_hdmi.h   | 362 
>   5 files changed, 1362 insertions(+)
>   create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>   create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
>   create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
>

Ping, inno HDMI driver looks good for me, and it works, So I'd like to 
merge it into drm/rockchip if there is no doubt these days.

Thanks.

-- 
ï¼­ark Yao




[Bug 81045] [r600] Unreal Engine 4 demo crashed kernel

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=81045

--- Comment #8 from Michel D�nzer  ---
(In reply to famo from comment #7)
> However - there is some severe and very annoying stuttering. Which I can
> also replicate on games using that engine...
> Can someone else confirm?

Yes, it's because of shader recompiles. This is being addressed and will
hopefully be fixed before too long. It's not related to this bug report though.

-- 
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/20160129/6a67436c/attachment-0001.html>


[Bug 93911] Radeon rv635 with KMS and no dpm, intermittent/random GPU lockup

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93911

Michel D�nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Michel D�nzer  ---
Probably a duplicate of bug 91268, please try a newer kernel or the fix
referenced there.

*** This bug has been marked as a duplicate of bug 91268 ***

-- 
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/20160129/5c2f192e/attachment.html>


[Bug 91268] R6xx freezes with kernel 3.17 and up

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91268

Michel D�nzer  changed:

   What|Removed |Added

 CC||dabreese00 at gmail.com

--- Comment #26 from Michel D�nzer  ---
*** Bug 93911 has been marked as a duplicate of this bug. ***

-- 
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/20160129/6902006f/attachment.html>


[PATCH] nouveau: need to handle failed allocation

2016-01-29 Thread Ben Skeggs
On 01/29/2016 10:12 AM, Insu Yun wrote:
> 
> On Thu, Jan 28, 2016 at 7:08 PM, Ilia Mirkin  <mailto:imirkin at alum.mit.edu>> wrote:
> 
> On Thu, Jan 28, 2016 at 7:09 PM, Insu Yun  <mailto:wuninsu at gmail.com>> wrote:
> > drm_property_create_range can be failed in memory pressure.
> > So, it needs to be handled.
> >
> > Signed-off-by: Insu Yun mailto:wuninsu at 
> gmail.com>>
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_display.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> > index 24be27d..26b4902 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> > @@ -443,6 +443,12 @@ nouveau_display_create_properties(struct 
> drm_device *dev)
> > /* -100..+100 */
> > disp->color_vibrance_property =
> > drm_property_create_range(dev, 0, "color vibrance", 0, 
> 200);
> > +
> > +   if (!disp->underscan_hborder_property ||
> > +   !disp->underscan_vborder_property ||
> > +   !disp->vibrant_hue_property ||
> > +   !disp->color_vibrance_property)
> > +   return;
> 
> Aren't we at the end of the function anyways?
> 
> 
> Sorry. it is not perfect patch 
> I found this by my static analyzer.
> I have limited knowledge about this driver.
> I don't want to mass up your driver.
> What I want to do is to tell you there is a bug.
> I think we need to return error to caller.
I'm not so sure we do.  We check for valid pointers for these when
they're actually used, so no OOPS will occur.  Worst case, the driver
still loads correctly with some missing properties.

Ben.

>  
> 
> 
> >  }
> >
> >  int
> > --
> > 1.9.1
>     >
> 
> 
> 
> 
> -- 
> Regards
> Insu Yun

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160129/ce86d3fc/attachment.sig>


[Bug 93895] GPU lockup on AMD A4-3400 APU when starting X server on opensource drivers. (works fine with fglrx)

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93895

--- Comment #5 from Azari  ---
(In reply to Alex Deucher from comment #4)
> Created attachment 121340 [details] [review]
> possible fix
> 
> Does this kernel patch help?

I just finished compiling and testing a kernel with that patch; it didn't help,
it still has the same issues. =(

Thanks for the prompt reply by the way.

-- 
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/20160129/3e615b76/attachment.html>


[PATCH v2 1/2] drm: rockchip/hdmi: add Innosilicon HDMI support

2016-01-29 Thread Yakir Yang
Hi ZhengYang,

Thanks for your comments ;)

On 01/29/2016 02:17 PM, 郑阳 wrote:
> 在 2016年01月07日 18:03, Yakir Yang 写道:
>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
>> b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> new file mode 100644
>> index 000..9327617
>> --- /dev/null
>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>
>> +static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi)
>> +{
>> +
>> +if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) + 
>> avi_color_mode = AVI_COLOR_MODE_RGB;
>> +else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
>> +avi_color_mode = AVI_COLOR_MODE_YCBCR444;
>> +else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
>> +avi_color_mode = AVI_COLOR_MODE_YCBCR422;
>> +else
>> +avi_color_mode = AVI_COLOR_MODE_RGB;
>> +
> Fist if is no need, its result is same to "else".
Got it
>> +static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
>> +{
>>
>> +if (data->enc_out_format == data->enc_out_format)  {
>> +if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
>> +(data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
>> +value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>> +hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>> +
>> +hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>> +  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>> +  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>> +  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>> +return 0;
>> +}
>> +}
>>
> It seems should be if (data->enc_in_format == data->enc_out_format).
>
Ah, good catch, thanks

- Yakir
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160129/7f63372c/attachment-0001.html>


[PATCH v8 0/2] Add Rockchip Inno-HDMI driver

2016-01-29 Thread Yakir Yang

Here are a brief introduction to Innosilicon HDMI IP:
  - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
  - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
  - Digital video interface supports a pixel size of 24, 30, 36, 48bits color 
depth in RGB
  - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission
(32-192kHz Fs) using IEC60958 and IEC 61937
  - The EDID and CEC function are also supported by Innosilicon HDMI 
Transmitter Controlle

Changes in v8:
- Don't check whether encoder output format is RGB colorspace, cause driver
  default configure the output colorspace to RGB. (ZhengYang)
- Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
- if (data->enc_out_format == data->enc_out_format) {
+ if (data->enc_in_format == data->enc_out_format) {

Changes in v7:
- Correct the module licnese statement (Paul)
 - MODULE_LICENSE("GPL");
 + MODULE_LICENSE("GPLv2");
- Start indentation with tabs and fix the misspell in Kconfig (Paul)
- Carry the lost device-binding document (Heiko)

Changes in v6:
- Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver 
(Caeser)

Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc transfer 
(Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)

Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop mode
configure function into encoder .enable helper functions. (Mark)

Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS function
- Keep HDMI PLL power on in standby mode

Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

Yakir Yang (2):
  drm/rockchip: hdmi: add Innosilicon HDMI support
  dt-bindings: add document for Innosilicon HDMI on Rockchip platform

 .../display/rockchip/inno_hdmi-rockchip.txt|  50 ++
 drivers/gpu/drm/rockchip/Kconfig   |   8 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/inno_hdmi.c   | 939 +
 drivers/gpu/drm/rockchip/inno_hdmi.h   | 362 
 5 files changed, 1360 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h

-- 
1.9.1




[Bug 93879] kernel 4.4.0 causes application lockup and unusable interfaces with radeon hardware

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93879

--- Comment #11 from langkamp at tomblog.de ---
I tried again with 4.4.0 Tumbleweed on my APU system. I can not trigger the
problem here. Resizing chromium and snapping to the edges etc. all works. Tried
every kwin combination of EGL GLX and openGL 3.1 2.0. So APU Systems may have
never been affected (or the mesa-update 11.1.1 yesterday evening helped).

-- 
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/20160129/ef3e59d0/attachment.html>


[PATCH v8 1/2] drm/rockchip: hdmi: add Innosilicon HDMI support

2016-01-29 Thread Yakir Yang
The Innosilicon HDMI is a low power HDMI 1.4 transmitter
IP, and it have been integrated on some rockchip CPUs
(like RK3036, RK312x).

Signed-off-by: Yakir Yang 
---
Changes in v8:
- Don't check whether encoder output format is RGB colorspace, cause driver
  default configure the output colorspace to RGB. (ZhengYang)
- Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
- if (data->enc_out_format == data->enc_out_format) {
+ if (data->enc_in_format == data->enc_out_format) {

Changes in v7:
- Correct the module licnese statement (Paul)
 - MODULE_LICENSE("GPL");
 + MODULE_LICENSE("GPLv2");
- Start indentation with tabs and fix the misspell in Kconfig (Paul)
- Carry the lost device-binding document (Heiko)

Changes in v6:
- Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver 
(Caeser)

Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc transfer 
(Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)

Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop mode
configure function into encoder .enable helper functions. (Mark)

Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS function
- Keep HDMI PLL power on in standby mode

Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)

 drivers/gpu/drm/rockchip/Kconfig |   8 +
 drivers/gpu/drm/rockchip/Makefile|   1 +
 drivers/gpu/drm/rockchip/inno_hdmi.c | 939 +++
 drivers/gpu/drm/rockchip/inno_hdmi.h | 362 ++
 4 files changed, 1310 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 8573985..76b3362 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -35,3 +35,11 @@ config ROCKCHIP_DW_MIPI_DSI
 for the Synopsys DesignWare HDMI driver. If you want to
 enable MIPI DSI on RK3288 based SoC, you should selet this
 option.
+
+config ROCKCHIP_INNO_HDMI
+   tristate "Rockchip specific extensions for Innosilicon HDMI"
+   depends on DRM_ROCKCHIP
+   help
+ This selects support for Rockchip SoC specific extensions
+ for the Innosilicon HDMI driver. If you want to enable
+ HDMI on RK3036 based SoC, you should select this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index f6a809a..df8fbef 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -8,5 +8,6 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += 
rockchip_drm_fbdev.o

 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o

 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
b/drivers/gpu/drm/rockchip/inno_hdmi.c
new file mode 100644
index 000..c99d88d
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -0,0 +1,939 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *Zheng Yang 
+ *Yakir Yang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#include "inno_hdmi.h"
+
+#define to_inno_hdmi(x)container_of(x, struct inno_hdmi, x)
+
+struct hdmi_data_info {
+   int vic;
+   bool sink_is_hdmi;
+   bool sink_has_audio;
+   unsigned int enc_in_format;
+   unsigned int enc_out_format;
+   unsigned int colorimetry;
+};
+
+struct inno_hdmi_i2c {
+   struct i2c_adapter adap;
+
+   u8 ddc_addr;
+   u8 segment_addr;
+
+   struct mutex lock;
+   struct completion cmp;
+};
+
+struct inno_hdmi {
+   struct device *dev;
+   struct drm_device *drm_dev;
+
+   int irq;
+   struct clk *pclk;
+   void __iomem *regs;
+
+   struct drm_connectorconnector;
+   struct drm_encoder  

[PATCH v8 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform

2016-01-29 Thread Yakir Yang
Signed-off-by: Yakir Yang 

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

 .../display/rockchip/inno_hdmi-rockchip.txt| 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
new file mode 100644
index 000..8096a29
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
@@ -0,0 +1,50 @@
+Rockchip specific extensions to the Innosilicon HDMI
+
+
+Required properties:
+- compatible:
+   "rockchip,rk3036-inno-hdmi";
+- reg:
+   Physical base address and length of the controller's registers.
+- clocks, clock-names:
+   Phandle to hdmi controller clock, name should be "pclk"
+- interrupts:
+   HDMI interrupt number
+- ports:
+   Contain one port node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/graph.txt.
+- pinctrl-0, pinctrl-name:
+   Switch the iomux of HPD/CEC pins to HDMI function.
+
+Example:
+hdmi: hdmi at 20034000 {
+   compatible = "rockchip,rk3036-inno-hdmi";
+   reg = <0x20034000 0x4000>;
+   interrupts = ;
+   clocks = <&cru  PCLK_HDMI>;
+   clock-names = "pclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <&hdmi_ctl>;
+   status = "disabled";
+
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_lcdc: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <&lcdc_out_hdmi>;
+   };
+   };
+};
+
+&pinctrl {
+   hdmi {
+   hdmi_ctl: hdmi-ctl {
+   rockchip,pins = <1 8  RK_FUNC_1 &pcfg_pull_none>,
+   <1 9  RK_FUNC_1 &pcfg_pull_none>,
+   <1 10 RK_FUNC_1 &pcfg_pull_none>,
+   <1 11 RK_FUNC_1 &pcfg_pull_none>;
+   };
+   };
+
+};
-- 
1.9.1




[PATCH v8 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform

2016-01-29 Thread Mark yao
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160129/276a9afa/attachment.html>


[PATCH v2] drm/i915: refine qemu south bridge detection

2016-01-29 Thread Jani Nikula
On Thu, 28 Jan 2016, Bruno Wolff III  wrote:
> On Mon, Jan 25, 2016 at 12:02:28 +0100,
>   Gerd Hoffmann  wrote:
>>The test for the qemu q35 south bridge added by commit
>>"39bfcd52 drm/i915: more virtual south bridge detection"
>>also matches on real hardware.  Having the check for
>>virtual systems last in the list is not enough to avoid
>>that ...
>>
>>Refine the check by additionally verifying the pci
>>subsystem id to see whenever it *really* is qemu.
>>
>>[ v2: fix subvendor tyops ]
>
> I haven't seen this patch (or a revert of 39bfcd52) show up in the intel 
> drm repos yet. Has anyone asked for this tpo be included? Is there some 
> problem with the patch? (It works for me.)

Pushed to drm-intel-next-queued, thanks for the patch and testing.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH v8.1 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform

2016-01-29 Thread Yakir Yang
Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
Changes in v8.1:
- Remove dumplicate Signed-off which add at the v8 (Mark)
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

 .../display/rockchip/inno_hdmi-rockchip.txt| 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
new file mode 100644
index 000..8096a29
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
@@ -0,0 +1,50 @@
+Rockchip specific extensions to the Innosilicon HDMI
+
+
+Required properties:
+- compatible:
+   "rockchip,rk3036-inno-hdmi";
+- reg:
+   Physical base address and length of the controller's registers.
+- clocks, clock-names:
+   Phandle to hdmi controller clock, name should be "pclk"
+- interrupts:
+   HDMI interrupt number
+- ports:
+   Contain one port node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/graph.txt.
+- pinctrl-0, pinctrl-name:
+   Switch the iomux of HPD/CEC pins to HDMI function.
+
+Example:
+hdmi: hdmi at 20034000 {
+   compatible = "rockchip,rk3036-inno-hdmi";
+   reg = <0x20034000 0x4000>;
+   interrupts = ;
+   clocks = <&cru  PCLK_HDMI>;
+   clock-names = "pclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <&hdmi_ctl>;
+   status = "disabled";
+
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_lcdc: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <&lcdc_out_hdmi>;
+   };
+   };
+};
+
+&pinctrl {
+   hdmi {
+   hdmi_ctl: hdmi-ctl {
+   rockchip,pins = <1 8  RK_FUNC_1 &pcfg_pull_none>,
+   <1 9  RK_FUNC_1 &pcfg_pull_none>,
+   <1 10 RK_FUNC_1 &pcfg_pull_none>,
+   <1 11 RK_FUNC_1 &pcfg_pull_none>;
+   };
+   };
+
+};
-- 
1.9.1




[Bug 51189] TTM errors when suspending (call trace)

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=51189

--- Comment #1 from Michel D�nzer  ---
Is this still happening with current kernels?

-- 
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/20160129/dbb656be/attachment.html>


[PATCH v8 1/2] drm/rockchip: hdmi: add Innosilicon HDMI support

2016-01-29 Thread Jean-Francois Moine
On Fri, 29 Jan 2016 14:47:39 +0800
Yakir Yang  wrote:

> The Innosilicon HDMI is a low power HDMI 1.4 transmitter
> IP, and it have been integrated on some rockchip CPUs
> (like RK3036, RK312x).
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v8:
> - Don't check whether encoder output format is RGB colorspace, cause driver
>   default configure the output colorspace to RGB. (ZhengYang)
> - Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
> - if (data->enc_out_format == data->enc_out_format) {
> + if (data->enc_in_format == data->enc_out_format) {
> 
> Changes in v7:
> - Correct the module licnese statement (Paul)
>  - MODULE_LICENSE("GPL");
>  + MODULE_LICENSE("GPLv2");
> - Start indentation with tabs and fix the misspell in Kconfig (Paul)
> - Carry the lost device-binding document (Heiko)
> 
> Changes in v6:
> - Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver 
> (Caeser)
> 
> Changes in v5:
> - Use hdmi_infoframe helper functions to packed the infoframe (Russell)
> - Remove the unused double wait_for_completion_timeout for ddc transfer 
> (Russell)
> - Remove the unused local variable in "inno_hdmi_i2c_write()" function 
> (Russell)
> 
> Changes in v4:
> - Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
> - Correct the "DKMS" to "DPMS" (Mark)
> - Fix over 80 characters problems (Mark)
> - Remove encoder .prepare/.commit helper functions, and move the vop mode
> configure function into encoder .enable helper functions. (Mark)
> 
> Changes in v3:
> - Use encoder enable/disable function, and remove the encoder DPMS function
> - Keep HDMI PLL power on in standby mode
> 
> Changes in v2:
> - Using DRM atomic helper functions for connector init (Mark)
> - Remove "hdmi->connector.encoder = encoder;" (Mark)
> 
>  drivers/gpu/drm/rockchip/Kconfig |   8 +
>  drivers/gpu/drm/rockchip/Makefile|   1 +
>  drivers/gpu/drm/rockchip/inno_hdmi.c | 939 
> +++
>  drivers/gpu/drm/rockchip/inno_hdmi.h | 362 ++
>  4 files changed, 1310 insertions(+)
>  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
>  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
> 
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index 8573985..76b3362 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -35,3 +35,11 @@ config ROCKCHIP_DW_MIPI_DSI
>for the Synopsys DesignWare HDMI driver. If you want to
>enable MIPI DSI on RK3288 based SoC, you should selet this
>option.
> +
> +config ROCKCHIP_INNO_HDMI
> + tristate "Rockchip specific extensions for Innosilicon HDMI"
> + depends on DRM_ROCKCHIP
> + help
> +   This selects support for Rockchip SoC specific extensions
> +   for the Innosilicon HDMI driver. If you want to enable
> +   HDMI on RK3036 based SoC, you should select this option.
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index f6a809a..df8fbef 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -8,5 +8,6 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += 
> rockchip_drm_fbdev.o
>  
>  obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> +obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>  
>  obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> new file mode 100644
> index 000..c99d88d
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -0,0 +1,939 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + *Zheng Yang 
> + *Yakir Yang 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

This is not needed.

> +
> +#include "rockchip_drm_drv.h"
> +#include "rockchip_drm_vop.h"
> +
> +#include "inno_hdmi.h"
[snip]

-- 
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/



[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=65963

Michel D�nzer  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #32 from Michel D�nzer  ---
Assuming fixed per comment 31, otherwise please reopen.

-- 
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/20160129/975656ba/attachment-0001.html>


[Bug 51189] TTM errors when suspending (call trace)

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=51189

Harald Judt  changed:

   What|Removed |Added

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

--- Comment #2 from Harald Judt  ---
No. I'm closing this as my hardware configuration has changed.

-- 
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/20160129/93ed703f/attachment.html>


[Bug 70286] X crashes when using Firefox with logout loop

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=70286

--- Comment #3 from Michel D�nzer  ---
Is this still happening with current versions of Mesa and the kernel?

-- 
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/20160129/ceaa4077/attachment.html>


[Bug 81991] X page allocation errors referencing radeon_vm_get_bos

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=81991

Michel D�nzer  changed:

   What|Removed |Added

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

--- Comment #4 from Michel D�nzer  ---
I think this was fixed long ago.

-- 
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/20160129/14da6337/attachment.html>


[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86864

Michel D�nzer  changed:

   What|Removed |Added

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

--- Comment #11 from Michel D�nzer  ---
Fixed with current kernels.

-- 
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/20160129/d317ef3e/attachment.html>


[PATCH v2] drm/i915: refine qemu south bridge detection

2016-01-29 Thread Jani Nikula
On Mon, 25 Jan 2016, Gerd Hoffmann  wrote:
> The test for the qemu q35 south bridge added by commit
> "39bfcd52 drm/i915: more virtual south bridge detection"
> also matches on real hardware.  Having the check for
> virtual systems last in the list is not enough to avoid
> that ...
>
> Refine the check by additionally verifying the pci
> subsystem id to see whenever it *really* is qemu.
>
> [ v2: fix subvendor tyops ]

Incidentally, I just spotted [1]. Gerd, could you review that one
please, and (once it gets merged) post a follow-up changing our magic
numbers to those constants as well?

Thanks,
Jani.


[1] http://mid.gmane.org/1453739846-3549-1-git-send-email-robbat2 at gentoo.org



>
> Reported-by: Bjørn Mork 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3ac616d..f357058 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -501,7 +501,9 @@ void intel_detect_pch(struct drm_device *dev)
>   WARN_ON(!IS_SKYLAKE(dev) &&
>   !IS_KABYLAKE(dev));
>   } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
> -(id == INTEL_PCH_QEMU_DEVICE_ID_TYPE)) {
> +((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
> + pch->subsystem_vendor == 0x1af4 &&
> + pch->subsystem_device == 0x1100)) {
>   dev_priv->pch_type = intel_virt_detect_pch(dev);
>   } else
>   continue;

-- 
Jani Nikula, Intel Open Source Technology Center


[Bug 93862] [Bisected] "drm/amdgpu: fix amdgpu_bo_pin_restricted VRAM placing v2" is bad

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93862

--- Comment #7 from Ernst Sj�strand  ---
Michael: thanks. Could hurt future bisects?
Could only get past it without the mesa changes but perhaps I messed something
up. Lots of big changes right 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/20160129/54ef5833/attachment.html>


[Bug 93862] [Bisected] "drm/amdgpu: fix amdgpu_bo_pin_restricted VRAM placing v2" is bad

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93862

Michel D�nzer  changed:

   What|Removed |Added

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

--- Comment #8 from Michel D�nzer  ---
Fixed in Mesa and xf86-video-amdgpu master. Both fixes are required.

Module: Mesa
Branch: master
Commit: 62f837e2ea7b854215efb2e110b176dad61c2af0
URL:   
http://cgit.freedesktop.org/mesa/mesa/commit/?id=62f837e2ea7b854215efb2e110b176dad61c2af0

Author: Michel D�nzer 
Date:   Tue Jan 26 16:15:59 2016 +0900

winsys/amdgpu: Handle RADEON_FLAG_NO_CPU_ACCESS


commit a3eac85d812ecc605436e6bd5b9ee7ebf307e3d3
Author: Michel D�nzer 
Date:   Tue Jan 26 16:12:28 2016 +0900

Only map front buffer if glamor acceleration is disabled (v2)

-- 
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/20160129/c52d3e9a/attachment-0001.html>


[PATCH] PCI: QEMU top-level IDs for (sub)vendor & device

2016-01-29 Thread Gerd Hoffmann
On Mo, 2016-01-25 at 08:37 -0800, Robin H. Johnson wrote:
> Introduce PCI_VENDOR/PCI_SUBVENDOR/PCI_SUBDEVICE defines to replace the
> constants scattered in the kernel already used to detect QEMU.
> 
> They are defined in the QEMU codebase per docs/specs/pci-ids.txt.

Reviewed-by: Gerd Hoffmann 

thanks,
  Gerd



[PATCH v2] drm/i915: refine qemu south bridge detection

2016-01-29 Thread Gerd Hoffmann
On Fr, 2016-01-29 at 09:59 +0200, Jani Nikula wrote:
> On Mon, 25 Jan 2016, Gerd Hoffmann  wrote:
> > The test for the qemu q35 south bridge added by commit
> > "39bfcd52 drm/i915: more virtual south bridge detection"
> > also matches on real hardware.  Having the check for
> > virtual systems last in the list is not enough to avoid
> > that ...
> >
> > Refine the check by additionally verifying the pci
> > subsystem id to see whenever it *really* is qemu.
> >
> > [ v2: fix subvendor tyops ]
> 
> Incidentally, I just spotted [1]. Gerd, could you review that one
> please,

Done.

> and (once it gets merged) post a follow-up changing our magic
> numbers to those constants as well?

Sure.

cheers,
  Gerd



[PATCH 1/4] drm/fsl-dcu: Cleanup vblank interrupt mask and status setting code

2016-01-29 Thread Meng Yi
Hi, Stefan
I had tested your patch(https://lkml.org/lkml/2015/11/18/951) in ls1021-twr 
board, I think you can merge this patch to your tree if Jianwei don't have any 
objections.

> On  Tuesday, January 26, 2016 1:45 PM, Stefan Agner  
> wrote:
> 
> As I wrote earlier
> (http://www.spinics.net/lists/dri-devel/msg95703.html), my fixes patchset
> contains a similar patch which also explicitly disable the VBLANK interrupt. I
> think it is the better solution... See:
> https://lkml.org/lkml/2015/11/18/951
> 
> I will soon prepare a git tree and plan to submit that for 4.6, currently I 
> plan to
> include
> - Your "Fix no fb check bug" patch
> - My "fixes and enhancements" patchset
> - My "fix register initialization" and "use flat regmap cache" patch
> 
> Let me know if you have any objections.
> 
> --
> Stefan



[PATCH v2 1/2] drm: rockchip/hdmi: add Innosilicon HDMI support

2016-01-29 Thread 郑阳
在 2016年01月07日 18:03, Yakir Yang 写道:
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> new file mode 100644
> index 000..9327617
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>
> +static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi)
> +{
> +
> + if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) + 
> avi_color_mode = AVI_COLOR_MODE_RGB;
> + else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
> + avi_color_mode = AVI_COLOR_MODE_YCBCR444;
> + else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
> + avi_color_mode = AVI_COLOR_MODE_YCBCR422;
> + else
> + avi_color_mode = AVI_COLOR_MODE_RGB;
> +
Fist if is no need, its result is same to "else".
> +static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
> +{
>
> + if (data->enc_out_format == data->enc_out_format)  {
> + if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
> + (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
> + value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> + hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> +
> + hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> +   m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> +   v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> +   v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> + return 0;
> + }
> + }
>
It seems should be if (data->enc_in_format == data->enc_out_format).

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


[PATCH v2] drm/i915: refine qemu south bridge detection

2016-01-29 Thread Jani Nikula
On Fri, 29 Jan 2016, Gerd Hoffmann  wrote:
> On Fr, 2016-01-29 at 09:59 +0200, Jani Nikula wrote:
>> On Mon, 25 Jan 2016, Gerd Hoffmann  wrote:
>> > The test for the qemu q35 south bridge added by commit
>> > "39bfcd52 drm/i915: more virtual south bridge detection"
>> > also matches on real hardware.  Having the check for
>> > virtual systems last in the list is not enough to avoid
>> > that ...
>> >
>> > Refine the check by additionally verifying the pci
>> > subsystem id to see whenever it *really* is qemu.
>> >
>> > [ v2: fix subvendor tyops ]
>> 
>> Incidentally, I just spotted [1]. Gerd, could you review that one
>> please,
>
> Done.
>
>> and (once it gets merged) post a follow-up changing our magic
>> numbers to those constants as well?
>
> Sure.

Many thanks,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH] PCI: QEMU top-level IDs for (sub)vendor & device

2016-01-29 Thread Jani Nikula

This one's lacking some maintainers, adding for acks. There's already
review from Gerd [1], and seems like a good idea anyway.

Bjorn, I suppose it would make most sense to merge this via PCI tree,
right?


BR,
Jani.


[1] http://mid.gmane.org/1454057342.28516.45.camel at redhat.com



On Mon, 25 Jan 2016, "Robin H. Johnson"  wrote:
> Introduce PCI_VENDOR/PCI_SUBVENDOR/PCI_SUBDEVICE defines to replace the
> constants scattered in the kernel already used to detect QEMU.
>
> They are defined in the QEMU codebase per docs/specs/pci-ids.txt.
>
> Signed-off-by: Robin H. Johnson 
> ---
> This change prompted by a near-miss in the review of recent change:
> 'drm/i915: refine qemu south bridge detection'
>
> Signed-off-by: Robin H. Johnson 
> ---
>  drivers/gpu/drm/bochs/bochs_drv.c   | 4 ++--
>  drivers/gpu/drm/cirrus/cirrus_drv.c | 5 +++--
>  drivers/virtio/virtio_pci_common.c  | 2 +-
>  include/linux/pci_ids.h | 4 
>  sound/pci/intel8x0.c| 4 ++--
>  5 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
> b/drivers/gpu/drm/bochs/bochs_drv.c
> index 7f1a360..b332b4d3 100644
> --- a/drivers/gpu/drm/bochs/bochs_drv.c
> +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> @@ -182,8 +182,8 @@ static const struct pci_device_id bochs_pci_tbl[] = {
>   {
>   .vendor  = 0x1234,
>   .device  = 0x,
> - .subvendor   = 0x1af4,
> - .subdevice   = 0x1100,
> + .subvendor   = PCI_SUBVENDOR_ID_REDHAT_QUMRANET,
> + .subdevice   = PCI_SUBDEVICE_ID_QEMU,
>   .driver_data = BOCHS_QEMU_STDVGA,
>   },
>   {
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
> b/drivers/gpu/drm/cirrus/cirrus_drv.c
> index b1619e2..7bc394e 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
> @@ -33,8 +33,9 @@ static struct drm_driver driver;
>  
>  /* only bind to the cirrus chip in qemu */
>  static const struct pci_device_id pciidlist[] = {
> - { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, 0x1af4, 0x1100, 0,
> -   0, 0 },
> + { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446,
> +   PCI_SUBVENDOR_ID_REDHAT_QUMRANET, PCI_SUBDEVICE_ID_QEMU,
> +   0, 0, 0 },
>   { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, PCI_VENDOR_ID_XEN,
> 0x0001, 0, 0, 0 },
>   {0,}
> diff --git a/drivers/virtio/virtio_pci_common.c 
> b/drivers/virtio/virtio_pci_common.c
> index 36205c2..127dfe4 100644
> --- a/drivers/virtio/virtio_pci_common.c
> +++ b/drivers/virtio/virtio_pci_common.c
> @@ -467,7 +467,7 @@ static const struct dev_pm_ops virtio_pci_pm_ops = {
>  
>  /* Qumranet donated their vendor ID for devices 0x1000 thru 0x10FF. */
>  static const struct pci_device_id virtio_pci_id_table[] = {
> - { PCI_DEVICE(0x1af4, PCI_ANY_ID) },
> + { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
>   { 0 }
>  };
>  
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 37f05cb..6d249d3 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2506,6 +2506,10 @@
>  
>  #define PCI_VENDOR_ID_AZWAVE 0x1a3b
>  
> +#define PCI_VENDOR_ID_REDHAT_QUMRANET0x1af4
> +#define PCI_SUBVENDOR_ID_REDHAT_QUMRANET 0x1af4
> +#define PCI_SUBDEVICE_ID_QEMU0x1100
> +
>  #define PCI_VENDOR_ID_ASMEDIA0x1b21
>  
>  #define PCI_VENDOR_ID_CIRCUITCO  0x1cc8
> diff --git a/sound/pci/intel8x0.c b/sound/pci/intel8x0.c
> index 42bcbac..12c2c18 100644
> --- a/sound/pci/intel8x0.c
> +++ b/sound/pci/intel8x0.c
> @@ -2980,8 +2980,8 @@ static int snd_intel8x0_inside_vm(struct pci_dev *pci)
>   goto fini;
>  
>   /* check for known (emulated) devices */
> - if (pci->subsystem_vendor == 0x1af4 &&
> - pci->subsystem_device == 0x1100) {
> + if (pci->subsystem_vendor == PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
> + pci->subsystem_device == PCI_SUBDEVICE_ID_QEMU) {
>   /* KVM emulated sound, PCI SSID: 1af4:1100 */
>   msg = "enable KVM";
>   } else if (pci->subsystem_vendor == 0x1ab8) {

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH] drm/i915: use #defines for qemu subsystem ids

2016-01-29 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
---
depends on http://mid.gmane.org/1453739846-3549-1-git-send-email-robbat2 at 
gentoo.org
---
 drivers/gpu/drm/i915/i915_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f357058..b200152 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -502,8 +502,10 @@ void intel_detect_pch(struct drm_device *dev)
!IS_KABYLAKE(dev));
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
-   pch->subsystem_vendor == 0x1af4 &&
-   pch->subsystem_device == 0x1100)) {
+   pch->subsystem_vendor ==
+   PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
+   pch->subsystem_device ==
+   PCI_SUBDEVICE_ID_QEMU)) {
dev_priv->pch_type = intel_virt_detect_pch(dev);
} else
continue;
-- 
1.8.3.1



[Intel-gfx] [PATCH] drm/i915: use #defines for qemu subsystem ids

2016-01-29 Thread kbuild test robot
Hi Gerd,

[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v4.5-rc1 next-20160129]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Gerd-Hoffmann/drm-i915-use-defines-for-qemu-subsystem-ids/20160129-172630
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x012-01270835 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_drv.c: In function 'intel_detect_pch':
>> drivers/gpu/drm/i915/i915_drv.c:506:10: error: 
>> 'PCI_SUBVENDOR_ID_REDHAT_QUMRANET' undeclared (first use in this function)
 PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
 ^
   drivers/gpu/drm/i915/i915_drv.c:506:10: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/gpu/drm/i915/i915_drv.c:508:10: error: 'PCI_SUBDEVICE_ID_QEMU' 
>> undeclared (first use in this function)
 PCI_SUBDEVICE_ID_QEMU)) {
 ^

vim +/PCI_SUBVENDOR_ID_REDHAT_QUMRANET +506 drivers/gpu/drm/i915/i915_drv.c

   500  DRM_DEBUG_KMS("Found SunrisePoint LP 
PCH\n");
   501  WARN_ON(!IS_SKYLAKE(dev) &&
   502  !IS_KABYLAKE(dev));
   503  } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) 
||
   504 ((id == 
INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
   505  pch->subsystem_vendor ==
 > 506  
 > PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
   507  pch->subsystem_device ==
 > 508  PCI_SUBDEVICE_ID_QEMU)) {
   509  dev_priv->pch_type = 
intel_virt_detect_pch(dev);
   510  } else
   511  continue;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 27196 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160129/e29706c9/attachment-0001.obj>


[Intel-gfx] [PATCH] drm/i915: use #defines for qemu subsystem ids

2016-01-29 Thread kbuild test robot
Hi Gerd,

[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v4.5-rc1 next-20160129]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Gerd-Hoffmann/drm-i915-use-defines-for-qemu-subsystem-ids/20160129-172630
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x014-01270835 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/ioport.h:12:0,
from include/linux/device.h:16,
from drivers/gpu/drm/i915/i915_drv.c:30:
   drivers/gpu/drm/i915/i915_drv.c: In function 'intel_detect_pch':
   drivers/gpu/drm/i915/i915_drv.c:506:10: error: 
'PCI_SUBVENDOR_ID_REDHAT_QUMRANET' undeclared (first use in this function)
 PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
 ^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
 if (__builtin_constant_p((cond)) ? !!(cond) :   \
   ^
>> drivers/gpu/drm/i915/i915_drv.c:503:11: note: in expansion of macro 'if'
   } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
  ^
   drivers/gpu/drm/i915/i915_drv.c:506:10: note: each undeclared identifier is 
reported only once for each function it appears in
 PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
 ^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
 if (__builtin_constant_p((cond)) ? !!(cond) :   \
   ^
>> drivers/gpu/drm/i915/i915_drv.c:503:11: note: in expansion of macro 'if'
   } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
  ^
   drivers/gpu/drm/i915/i915_drv.c:508:10: error: 'PCI_SUBDEVICE_ID_QEMU' 
undeclared (first use in this function)
 PCI_SUBDEVICE_ID_QEMU)) {
 ^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
 if (__builtin_constant_p((cond)) ? !!(cond) :   \
   ^
>> drivers/gpu/drm/i915/i915_drv.c:503:11: note: in expansion of macro 'if'
   } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
  ^

vim +/if +503 drivers/gpu/drm/i915/i915_drv.c

a35cc9d0c Rodrigo Vivi   2015-01-21  487
WARN_ON(IS_HSW_ULT(dev) || IS_BDW_ULT(dev));
e76e06348 Ben Widawsky   2013-11-07  488} else if (id 
== INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
e76e06348 Ben Widawsky   2013-11-07  489
dev_priv->pch_type = PCH_LPT;
e76e06348 Ben Widawsky   2013-11-07  490
DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
a35cc9d0c Rodrigo Vivi   2015-01-21  491
WARN_ON(!IS_HASWELL(dev) && !IS_BROADWELL(dev));
a35cc9d0c Rodrigo Vivi   2015-01-21  492
WARN_ON(!IS_HSW_ULT(dev) && !IS_BDW_ULT(dev));
e7e7ea202 Satheeshakrishna M 2014-04-09  493} else if (id 
== INTEL_PCH_SPT_DEVICE_ID_TYPE) {
e7e7ea202 Satheeshakrishna M 2014-04-09  494
dev_priv->pch_type = PCH_SPT;
e7e7ea202 Satheeshakrishna M 2014-04-09  495
DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
ef11bdb3e Rodrigo Vivi   2015-10-28  496
WARN_ON(!IS_SKYLAKE(dev) &&
ef11bdb3e Rodrigo Vivi   2015-10-28  497
!IS_KABYLAKE(dev));
e7e7ea202 Satheeshakrishna M 2014-04-09  498} else if (id 
== INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
e7e7ea202 Satheeshakrishna M 2014-04-09  499
dev_priv->pch_type = PCH_SPT;
e7e7ea202 Satheeshakrishna M 2014-04-09  500
DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
ef11bdb3e Rodrigo Vivi   2015-10-28  501
WARN_ON(!IS_SKYLAKE(dev) &&
ef11bdb3e Rodrigo Vivi   2015-10-28  502
!IS_KABYLAKE(dev));
39bfcd523 Gerd Hoffmann  2015-11-26 @503} else if ((id 
== INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
1e859111c Gerd Hoffmann  2016-01-25  504   ((id 
== INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
7e1597c34 Gerd Hoffmann  2016-01-29  505
pch->subsystem_vendor ==
7e1597c34 Gerd Hoffmann  2016-01-29  506
PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
7e1597c34 Gerd Hoffmann  2016-01-29  507
pch->subsystem_device ==
7e1597c34 Gerd Hoffmann  2016-01-29  508  

[PATCH] drm/imx: Add missing DRM_FORMAT_RGB565 to ipu_plane_formats

2016-01-29 Thread Philipp Zabel
From: Enrico Jorns 

DRM_FORMAT_RGB565 is missing from ipu_plane_formats.
The support is there, just need to make it available to userspace.

Signed-off-by: Enrico Jorns 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index e2ff410..32a246cd 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -42,6 +42,7 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_YUV420,
DRM_FORMAT_YVU420,
+   DRM_FORMAT_RGB565,
 };

 int ipu_plane_irq(struct ipu_plane *ipu_plane)
-- 
2.7.0.rc3



[PATCH] drm/imx: notify DRM core about CRTC vblank state

2016-01-29 Thread Philipp Zabel
From: Lucas Stach 

Make sure the DRM core is aware that there will be no vblank interrupts
incoming if the CRTC is disabled. That way the core will reject any
attempts from userspace to wait on a vblank event on a disabled CRTC.

Signed-off-by: Lucas Stach 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 4ab841e..73537c8 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -64,6 +64,7 @@ static void ipu_fb_enable(struct ipu_crtc *ipu_crtc)
/* Start DC channel and DI after IDMAC */
ipu_dc_enable_channel(ipu_crtc->dc);
ipu_di_enable(ipu_crtc->di);
+   drm_crtc_vblank_on(&ipu_crtc->base);

ipu_crtc->enabled = 1;
 }
@@ -80,6 +81,7 @@ static void ipu_fb_disable(struct ipu_crtc *ipu_crtc)
ipu_di_disable(ipu_crtc->di);
ipu_plane_disable(ipu_crtc->plane[0]);
ipu_dc_disable(ipu);
+   drm_crtc_vblank_off(&ipu_crtc->base);

ipu_crtc->enabled = 0;
 }
-- 
2.7.0.rc3



[PATCH] PCI: QEMU top-level IDs for (sub)vendor & device

2016-01-29 Thread Takashi Iwai
On Fri, 29 Jan 2016 10:02:54 +0100,
Jani Nikula wrote:
> 
> 
> This one's lacking some maintainers, adding for acks. There's already
> review from Gerd [1], and seems like a good idea anyway.

Feel free to take my ack, too
  Reviewed-by: Takashi Iwai 


thanks,

Takashi


[PATCH v2] gpu: ipu-v3: Do not bail out on missing optional port nodes

2016-01-29 Thread Philipp Zabel
The port nodes are documented as optional, treat them accordingly.

Reported-by: Martin Fuzzey 
Reported-by: Chris Healy 
Signed-off-by: Philipp Zabel 
Fixes: 304e6be652e2 ("gpu: ipu-v3: Assign of_node of child platform devices to 
corresponding ports")
---
Changes since v1:
 - Avoid leaking platform devices by skipping disabled nodes before
   the platform device allocation.
---
 drivers/gpu/ipu-v3/ipu-common.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index f2e13eb..a0e28f3 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1050,6 +1050,17 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
for (i = 0; i < ARRAY_SIZE(client_reg); i++) {
const struct ipu_platform_reg *reg = &client_reg[i];
struct platform_device *pdev;
+   struct device_node *of_node;
+
+   /* Associate subdevice with the corresponding port node */
+   of_node = of_graph_get_port_by_id(dev->of_node, i);
+   if (!of_node) {
+   dev_info(dev,
+"no port@%d node in %s, not using %s%d\n",
+i, dev->of_node->full_name,
+(i / 2) ? "DI" : "CSI", i % 2);
+   continue;
+   }

pdev = platform_device_alloc(reg->name, id++);
if (!pdev) {
@@ -1057,17 +1068,9 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
goto err_register;
}

+   pdev->dev.of_node = of_node;
pdev->dev.parent = dev;

-   /* Associate subdevice with the corresponding port node */
-   pdev->dev.of_node = of_graph_get_port_by_id(dev->of_node, i);
-   if (!pdev->dev.of_node) {
-   dev_err(dev, "missing port@%d node in %s\n", i,
-   dev->of_node->full_name);
-   ret = -ENODEV;
-   goto err_register;
-   }
-
ret = platform_device_add_data(pdev, ®->pdata,
   sizeof(reg->pdata));
if (!ret)
-- 
2.7.0.rc3



[PATCH v4 0/3] drm_of_encoder_active_endpoint helpers

2016-01-29 Thread Philipp Zabel
Hi,

these are rebased onto v4.5-rc1 and the rockchip patch is updated to also
replace the rockchip_drm_encoder_get_mux_id() call in dw-mipi-dsi.c. The
first two patches are unchanged, I'm just looking for feedback whether
I should include the rockchip patch in the next imx-drm pull request.

Changes since v3:
 - Rebased onto v4.5-rc1,
 - also update dw-mipi-dsi from rockchip_drm_encoder_get_mux_id() to
   drm_of_encoder_active_endpoint().

regards
Philipp

Philipp Zabel (3):
  drm: add drm_of_encoder_active_endpoint helpers
  drm/imx: remove imx_drm_encoder_get_mux_id
  drm/rockchip: remove rockchip_drm_encoder_get_mux_id

 drivers/gpu/drm/drm_of.c| 34 +
 drivers/gpu/drm/imx/dw_hdmi-imx.c   |  2 +-
 drivers/gpu/drm/imx/imx-drm-core.c  | 30 -
 drivers/gpu/drm/imx/imx-drm.h   |  2 --
 drivers/gpu/drm/imx/imx-ldb.c   |  5 +++--
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |  2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 30 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 --
 include/drm/drm_of.h| 32 +++
 10 files changed, 72 insertions(+), 69 deletions(-)

-- 
2.7.0.rc3



[PATCH v4 1/3] drm: add drm_of_encoder_active_endpoint helpers

2016-01-29 Thread Philipp Zabel
This patch adds a helper to parse the encoder endpoint connected to the
encoder's crtc and two helpers to return its id and port id.

This can be used to determine input mux setting from endpoint or port ids.

Suggested-by: Daniel Kurtz 
Reviewed-by: Daniel Kurtz 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/drm_of.c | 34 ++
 include/drm/drm_of.h | 32 
 2 files changed, 66 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 493c05c..bc98bb9 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -149,3 +149,37 @@ int drm_of_component_probe(struct device *dev,
return component_master_add_with_match(dev, m_ops, match);
 }
 EXPORT_SYMBOL(drm_of_component_probe);
+
+/*
+ * drm_of_encoder_active_endpoint - return the active encoder endpoint
+ * @node: device tree node containing encoder input ports
+ * @encoder: drm_encoder
+ *
+ * Given an encoder device node and a drm_encoder with a connected crtc,
+ * parse the encoder endpoint connecting to the crtc port.
+ */
+int drm_of_encoder_active_endpoint(struct device_node *node,
+  struct drm_encoder *encoder,
+  struct of_endpoint *endpoint)
+{
+   struct device_node *ep;
+   struct drm_crtc *crtc = encoder->crtc;
+   struct device_node *port;
+   int ret;
+
+   if (!node || !crtc)
+   return -EINVAL;
+
+   for_each_endpoint_of_node(node, ep) {
+   port = of_graph_get_remote_port(ep);
+   of_node_put(port);
+   if (port == crtc->port) {
+   ret = of_graph_parse_endpoint(ep, endpoint);
+   of_node_put(ep);
+   return ret;
+   }
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 8544665..43d30e8 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -1,9 +1,12 @@
 #ifndef __DRM_OF_H__
 #define __DRM_OF_H__

+#include 
+
 struct component_master_ops;
 struct device;
 struct drm_device;
+struct drm_encoder;
 struct device_node;

 #ifdef CONFIG_OF
@@ -12,6 +15,9 @@ extern uint32_t drm_of_find_possible_crtcs(struct drm_device 
*dev,
 extern int drm_of_component_probe(struct device *dev,
  int (*compare_of)(struct device *, void *),
  const struct component_master_ops *m_ops);
+extern int drm_of_encoder_active_endpoint(struct device_node *node,
+ struct drm_encoder *encoder,
+ struct of_endpoint *endpoint);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
@@ -26,6 +32,33 @@ drm_of_component_probe(struct device *dev,
 {
return -EINVAL;
 }
+
+static inline int drm_of_encoder_active_endpoint(struct device_node *node,
+struct drm_encoder *encoder,
+struct of_endpoint *endpoint)
+{
+   return -EINVAL;
+}
 #endif

+static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
+   struct drm_encoder *encoder)
+{
+   struct of_endpoint endpoint;
+   int ret = drm_of_encoder_active_endpoint(node, encoder,
+&endpoint);
+
+   return ret ?: endpoint.id;
+}
+
+static inline int drm_of_encoder_active_port_id(struct device_node *node,
+   struct drm_encoder *encoder)
+{
+   struct of_endpoint endpoint;
+   int ret = drm_of_encoder_active_endpoint(node, encoder,
+&endpoint);
+
+   return ret ?: endpoint.port;
+}
+
 #endif /* __DRM_OF_H__ */
-- 
2.7.0.rc3



[PATCH v4 2/3] drm/imx: remove imx_drm_encoder_get_mux_id

2016-01-29 Thread Philipp Zabel
It is replaced by drm_of_encoder_active_port_id.

Suggested-by: Daniel Kurtz 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  2 +-
 drivers/gpu/drm/imx/imx-drm-core.c | 30 --
 drivers/gpu/drm/imx/imx-drm.h  |  2 --
 drivers/gpu/drm/imx/imx-ldb.c  |  5 +++--
 4 files changed, 4 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 063825f..38d9c85 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -125,7 +125,7 @@ static void dw_hdmi_imx_encoder_mode_set(struct drm_encoder 
*encoder,
 static void dw_hdmi_imx_encoder_commit(struct drm_encoder *encoder)
 {
struct imx_hdmi *hdmi = container_of(encoder, struct imx_hdmi, encoder);
-   int mux = imx_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
+   int mux = drm_of_encoder_active_port_id(hdmi->dev->of_node, encoder);

regmap_update_bits(hdmi->regmap, IOMUXC_GPR3,
   IMX6Q_GPR3_HDMI_MUX_CTL_MASK,
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 2f57d79..bd0fe20 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -424,36 +424,6 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
 }
 EXPORT_SYMBOL_GPL(imx_drm_encoder_parse_of);

-/*
- * @node: device tree node containing encoder input ports
- * @encoder: drm_encoder
- */
-int imx_drm_encoder_get_mux_id(struct device_node *node,
-  struct drm_encoder *encoder)
-{
-   struct imx_drm_crtc *imx_crtc = imx_drm_find_crtc(encoder->crtc);
-   struct device_node *ep;
-   struct of_endpoint endpoint;
-   struct device_node *port;
-   int ret;
-
-   if (!node || !imx_crtc)
-   return -EINVAL;
-
-   for_each_endpoint_of_node(node, ep) {
-   port = of_graph_get_remote_port(ep);
-   of_node_put(port);
-   if (port == imx_crtc->crtc->port) {
-   ret = of_graph_parse_endpoint(ep, &endpoint);
-   of_node_put(ep);
-   return ret ? ret : endpoint.port;
-   }
-   }
-
-   return -EINVAL;
-}
-EXPORT_SYMBOL_GPL(imx_drm_encoder_get_mux_id);
-
 static const struct drm_ioctl_desc imx_drm_ioctls[] = {
/* none so far */
 };
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 71cf6d9..b0241b9 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -46,8 +46,6 @@ int imx_drm_set_bus_format_pins(struct drm_encoder *encoder,
 int imx_drm_set_bus_format(struct drm_encoder *encoder,
u32 bus_format);

-int imx_drm_encoder_get_mux_id(struct device_node *node,
-   struct drm_encoder *encoder);
 int imx_drm_encoder_parse_of(struct drm_device *drm,
struct drm_encoder *encoder, struct device_node *np);

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 22ac482..0ec3b1d 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -215,7 +216,7 @@ static void imx_ldb_encoder_commit(struct drm_encoder 
*encoder)
struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
struct imx_ldb *ldb = imx_ldb_ch->ldb;
int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
-   int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch->child, encoder);
+   int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);

drm_panel_prepare(imx_ldb_ch->panel);

@@ -265,7 +266,7 @@ static void imx_ldb_encoder_mode_set(struct drm_encoder 
*encoder,
int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
unsigned long serial_clk;
unsigned long di_clk = mode->clock * 1000;
-   int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch->child, encoder);
+   int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);

if (mode->clock > 17) {
dev_warn(ldb->dev,
-- 
2.7.0.rc3



[PATCH v4 3/3] drm/rockchip: remove rockchip_drm_encoder_get_mux_id

2016-01-29 Thread Philipp Zabel
It is replaced by drm_of_encoder_active_endpoint_id.

Suggested-by: Daniel Kurtz 
Reviewed-by: Daniel Kurtz 
Reviewed-by: Heiko Stuebner 
Tested-by: Yakir Yang 
[for dw_hdmi-rockchip]
Acked-by: Mark Yao 
Signed-off-by: Philipp Zabel 
---
Changes since v3:
 - Rebased onto v4.5-rc1: also update dw-mipi-dsi.
---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |  2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 30 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 --
 4 files changed, 2 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 7bfe243..f0aec46 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -884,7 +884,7 @@ static bool dw_mipi_dsi_encoder_mode_fixup(struct 
drm_encoder *encoder,
 static void dw_mipi_dsi_encoder_commit(struct drm_encoder *encoder)
 {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
-   int mux  = rockchip_drm_encoder_get_mux_id(dsi->dev->of_node, encoder);
+   int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 interface_pix_fmt;
u32 val;

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index c65ce8c..3d3cf2f 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -204,7 +204,7 @@ static void dw_hdmi_rockchip_encoder_enable(struct 
drm_encoder *encoder)
rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
  ROCKCHIP_OUT_MODE_);

-   mux = rockchip_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
+   mux = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
if (mux)
val = HDMI_SEL_VOP_LIT | (HDMI_SEL_VOP_LIT << 16);
else
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 8397d1b..183831d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -388,36 +388,6 @@ static const struct dev_pm_ops rockchip_drm_pm_ops = {
rockchip_drm_sys_resume)
 };

-/*
- * @node: device tree node containing encoder input ports
- * @encoder: drm_encoder
- */
-int rockchip_drm_encoder_get_mux_id(struct device_node *node,
-   struct drm_encoder *encoder)
-{
-   struct device_node *ep;
-   struct drm_crtc *crtc = encoder->crtc;
-   struct of_endpoint endpoint;
-   struct device_node *port;
-   int ret;
-
-   if (!node || !crtc)
-   return -EINVAL;
-
-   for_each_endpoint_of_node(node, ep) {
-   port = of_graph_get_remote_port(ep);
-   of_node_put(port);
-   if (port == crtc->port) {
-   ret = of_graph_parse_endpoint(ep, &endpoint);
-   of_node_put(ep);
-   return ret ?: endpoint.id;
-   }
-   }
-
-   return -EINVAL;
-}
-EXPORT_SYMBOL_GPL(rockchip_drm_encoder_get_mux_id);
-
 static int compare_of(struct device *dev, void *data)
 {
struct device_node *np = data;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index bb8b076..3529f69 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -67,8 +67,6 @@ void rockchip_drm_atomic_work(struct work_struct *work);
 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
 const struct rockchip_crtc_funcs *crtc_funcs);
 void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc);
-int rockchip_drm_encoder_get_mux_id(struct device_node *node,
-   struct drm_encoder *encoder);
 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
  int out_mode);
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
-- 
2.7.0.rc3



[Bug 81045] [r600] Unreal Engine 4 demo crashed kernel

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=81045

--- Comment #9 from famo  ---
(In reply to Michel D�nzer from comment #8)
> (In reply to famo from comment #7)
> > However - there is some severe and very annoying stuttering. Which I can
> > also replicate on games using that engine...
> > Can someone else confirm?
> 
> Yes, it's because of shader recompiles. This is being addressed and will
> hopefully be fixed before too long. It's not related to this bug report
> though.
>
Thanks for the info. By adressed you mean in the engine or in the driver?
Also is there a bug report about this / can I track this somewhere?


@reporter:
Please check again, this bug can probably be closed...

-- 
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/20160129/dd818307/attachment.html>


[Intel-gfx] drm/i915: Decouple execbuf uAPI from internal implementation

2016-01-29 Thread Tvrtko Ursulin

Hi Dan,

On 28/01/16 22:30, Dan Carpenter wrote:
> Hello Tvrtko Ursulin,
>
> The patch de1add360522: "drm/i915: Decouple execbuf uAPI from
> internal implementation" from Jan 15, 2016, leads to the following
> static checker warning:
>
>   drivers/gpu/drm/i915/i915_gem_execbuffer.c:1411 eb_select_ring()
>   warn: buffer overflow 'dev_priv->ring' 5 <= 16385
>
> drivers/gpu/drm/i915/i915_gem_execbuffer.c
>1397  if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
>1398  unsigned int bsd_idx = args->flags & 
> I915_EXEC_BSD_MASK;
>1399
>1400  if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
>1401  bsd_idx = gen8_dispatch_bsd_ring(dev_priv, 
> file);
>1402  } else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
>1403 bsd_idx <= I915_EXEC_BSD_RING2) {
>1404  bsd_idx--;
>  ^
> This should probablye be "bsd_idx = (bsd_idx >> 13) - 1;" or something.
>
>1405  } else {
>1406  DRM_DEBUG("execbuf with unknown bsd ring: 
> %u\n",
>1407bsd_idx);
>1408  return -EINVAL;
>1409  }
>1410
>1411  *ring = &dev_priv->ring[_VCS(bsd_idx)];
>
> Otherwise we're way past the end of this array.

Yep, we have already found this and fixed it in "drm/i915: Fix VCS ring 
selection after uapi decoupling".

Thanks for the report, it is very useful!

Regards,

Tvrtko


[PATCH] drm: omap dss: add missing includes

2016-01-29 Thread Tomi Valkeinen


On 15/01/16 12:52, Arnd Bergmann wrote:
> The omapdrm dss driver currently fails to build in some configurations when
> the pinctrl and seq_print declarations are not visible:
> 
> omapdrm/dss/dss.c:1268:2: error: implicit declaration of function 
> 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
> omapdrm/dss/dss.c:1277:2: error: implicit declaration of function 
> 'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration]
> omapdrm/dss/hdmi_wp.c:26:2: error: implicit declaration of function 
> 'seq_printf' [-Werror=implicit-function-declaration]
> omapdrm/dss/hdmi_pll.c:30:2: error: implicit declaration of function 
> 'seq_printf' [-Werror=implicit-function-declaration]
> omapdrm/dss/hdmi_phy.c:34:2: error: implicit declaration of function 
> 'seq_printf' [-Werror=implicit-function-declaration]
> 
> This adds the appropriate include statements.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 9960aa7cb58c ("drm/omap: move omapdss & displays under omapdrm")

Thanks, I've picked this up for 4.5.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160129/0615a463/attachment.sig>


[PATCH 1/2] drm/mst: Don't ignore the MST PBN self-test result

2016-01-29 Thread Imre Deak
Otherwise this call would have no effect.

Caught by Coverity.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6ed90a2..8f749e6 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2854,7 +2854,9 @@ int drm_dp_mst_topology_mgr_init(struct 
drm_dp_mst_topology_mgr *mgr,
if (!mgr->proposed_vcpis)
return -ENOMEM;
set_bit(0, &mgr->payload_mask);
-   test_calc_pbn_mode();
+   if (test_calc_pbn_mode() < 0)
+   DRM_ERROR("MST PBN self-test failed\n");
+
return 0;
 }
 EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init);
-- 
2.5.0



[PATCH 2/2] drm/mst: Add range check for max_payloads during init

2016-01-29 Thread Imre Deak
max_payload is limited by the space we have in
drm_dp_mst_topology_mgr::vcpi_mask,payload_mask. We need to track
max_payloads+1 IDs in these masks, see drm_dp_mst_assign_payload_id().
Add a sanity check for this.

Caught by coverity.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 8f749e6..05c2702 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2847,6 +2847,9 @@ int drm_dp_mst_topology_mgr_init(struct 
drm_dp_mst_topology_mgr *mgr,
mgr->max_dpcd_transaction_bytes = max_dpcd_transaction_bytes;
mgr->max_payloads = max_payloads;
mgr->conn_base_id = conn_base_id;
+   if (max_payloads + 1 > sizeof(mgr->payload_mask) * 8 ||
+   max_payloads + 1 > sizeof(mgr->vcpi_mask) * 8)
+   return -EINVAL;
mgr->payloads = kcalloc(max_payloads, sizeof(struct drm_dp_payload), 
GFP_KERNEL);
if (!mgr->payloads)
return -ENOMEM;
-- 
2.5.0



[PATCH] adv7511: Added mode_fixup function.

2016-01-29 Thread Carlos Palminha
The mode_fixup is necessary when using it in a DRM FB driver pipeline.

Signed-off-by: Carlos Palminha 
---
 drivers/gpu/drm/i2c/adv7511.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index 533d1e3..90082d2 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -648,6 +648,13 @@ adv7511_encoder_detect(struct drm_encoder *encoder,
return status;
 }

+static bool adv7511_encoder_mode_fixup(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
 static int adv7511_encoder_mode_valid(struct drm_encoder *encoder,
  struct drm_display_mode *mode)
 {
@@ -754,6 +761,7 @@ static void adv7511_encoder_mode_set(struct drm_encoder 
*encoder,

 static const struct drm_encoder_slave_funcs adv7511_encoder_funcs = {
.dpms = adv7511_encoder_dpms,
+   .mode_fixup = adv7511_encoder_mode_fixup,
.mode_valid = adv7511_encoder_mode_valid,
.mode_set = adv7511_encoder_mode_set,
.detect = adv7511_encoder_detect,
-- 
2.5.0



[PATCH 1/2] drm/mst: Don't ignore the MST PBN self-test result

2016-01-29 Thread David Weinehall
On Fri, Jan 29, 2016 at 02:44:28PM +0200, Imre Deak wrote:
> Otherwise this call would have no effect.
> 
> Caught by Coverity.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: David Weinehall 

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 6ed90a2..8f749e6 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2854,7 +2854,9 @@ int drm_dp_mst_topology_mgr_init(struct 
> drm_dp_mst_topology_mgr *mgr,
>   if (!mgr->proposed_vcpis)
>   return -ENOMEM;
>   set_bit(0, &mgr->payload_mask);
> - test_calc_pbn_mode();
> + if (test_calc_pbn_mode() < 0)
> + DRM_ERROR("MST PBN self-test failed\n");
> +
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init);
> -- 
> 2.5.0
> 


[PATCH 2/2] drm/mst: Add range check for max_payloads during init

2016-01-29 Thread David Weinehall
On Fri, Jan 29, 2016 at 02:44:29PM +0200, Imre Deak wrote:
> max_payload is limited by the space we have in
> drm_dp_mst_topology_mgr::vcpi_mask,payload_mask. We need to track
> max_payloads+1 IDs in these masks, see drm_dp_mst_assign_payload_id().
> Add a sanity check for this.
> 
> Caught by coverity.
> 
> Signed-off-by: Imre Deak 
Reviewed-by: David Weinehall 

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 8f749e6..05c2702 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2847,6 +2847,9 @@ int drm_dp_mst_topology_mgr_init(struct 
> drm_dp_mst_topology_mgr *mgr,
>   mgr->max_dpcd_transaction_bytes = max_dpcd_transaction_bytes;
>   mgr->max_payloads = max_payloads;
>   mgr->conn_base_id = conn_base_id;
> + if (max_payloads + 1 > sizeof(mgr->payload_mask) * 8 ||
> + max_payloads + 1 > sizeof(mgr->vcpi_mask) * 8)
> + return -EINVAL;
>   mgr->payloads = kcalloc(max_payloads, sizeof(struct drm_dp_payload), 
> GFP_KERNEL);
>   if (!mgr->payloads)
>   return -ENOMEM;
> -- 
> 2.5.0
> 


[PATCH 00/11] sync framework de-staging: part 1 - clean up

2016-01-29 Thread Gustavo Padovan
Hi,

2016-01-25 Maarten Lankhorst :

> Hey,
> 
> Op 21-01-16 om 13:49 schreef Gustavo Padovan:
> > From: Gustavo Padovan 
> >
> > Hi,
> >
> > The following patches are some clean ups on the sync framework before
> > we start the actual de-staging. The main changes here are the move of
> > SW_SYNC_USER to debugfs. Removal of struct sync_pt in favor of direct
> > use of struct fence. And the rename of sync_fence to sync_file, a name
> > to better reflect what it is for, a struct that connects struct fence(s)
> > to a file.
> >
> > Please review. Thanks.
> >
> > Gustavo Padovan (11):
> >   staging/android: fix sync framework documentation
> >   staging/android: sync: remove interfaces that are not used
> >   staging/android: remove not used sync_timeline ops
> >   staging/android: create a 'sync' dir for debugfs information
> >   staging/android: move SW_SYNC_USER to a debugfs file
> >   staging/android: rename sync_fence to sync_file
> >   staging/android: rename 'sync_pt' to 'fence' in struct sync_fence_cb
> >   staging/android: remove struct sync_pt
> >   staging/android: remove unused var from sync_timeline_signal()
> >   staging/android: remove pointless sync_timeline_signal at destroy
> > phase
> >   staging/android: remove sync_fence_create_dma()
> >
> For whole series:
> Reviewed-by: Maarten Lankhorst 
> 
> Renaming sync_fence to sync_file makes sense, it should hopefully reduce 
> confusion.

Poke. What is missing for this to go upstream? Do I need more review
here? Thanks.

Gustavo


[Bug 93928] Tonga valley regression since drm/amdgpu: split VM mappings into smaller operations (v2)

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93928

Bug ID: 93928
   Summary: Tonga valley regression since drm/amdgpu: split VM
mappings into smaller operations (v2)
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

R8285 agd5f drm-next-4.6-wip

Since below Unigine Valley renders mostly a screen full of colored blocks.

Doesn't affect desktop, Unreal Elemental or xonotic.

In case settings are relevant I run valley ultra quality fullscreen 1920x1080
8xAA

commit 8292e95e64134e8c81ccec25fb702f3c838c2a1e
Author: Christian K�nig 
Date:   Mon Jan 25 14:27:31 2016 +0100

drm/amdgpu: split VM mappings into smaller operations (v2)

If we can't copy entries from the GTT or fill them with one command split
up the mapping operation into multiple ones.

v2: agd: rebase on upstream

-- 
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/20160129/24bd9d66/attachment.html>


[PATCH] drm/exynos: dp: Fix panel and bridge lookup logic

2016-01-29 Thread Javier Martinez Canillas
Commit a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support
for panel") made the Exynos DP DT binding more consistent since the OF
graph could be used to lookup either a panel or a bridge device node.

Before that commit, a panel would be looked up using a phandle and a
bridge using the OF graph which made the DT binding not consistent.

But the patch broke the later case since not finding a panel dev node
would cause the driver's to do a probe deferral instead of attempting
to lookup a bridge device node associated with the remote endpoint.

So instead of returning a -EPROBE_DEFER if a panel is not found, check
if there's a bridge and only do a probe deferral if both aren't found.

Fixes: a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support for 
panel")
Signed-off-by: Javier Martinez Canillas 

---

 drivers/gpu/drm/exynos/exynos_dp_core.c | 55 +++--
 1 file changed, 25 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index b79c316c2ad2..673164b331c8 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
 static int exynos_dp_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
-   struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
+   struct device_node *np = NULL, *endpoint = NULL;
struct exynos_dp_device *dp;
int ret;

@@ -1404,41 +1404,36 @@ static int exynos_dp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dp);

/* This is for the backward compatibility. */
-   panel_node = of_parse_phandle(dev->of_node, "panel", 0);
-   if (panel_node) {
-   dp->panel = of_drm_find_panel(panel_node);
-   of_node_put(panel_node);
+   np = of_parse_phandle(dev->of_node, "panel", 0);
+   if (np) {
+   dp->panel = of_drm_find_panel(np);
+   of_node_put(np);
if (!dp->panel)
return -EPROBE_DEFER;
-   } else {
-   endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
-   if (endpoint) {
-   panel_node = of_graph_get_remote_port_parent(endpoint);
-   if (panel_node) {
-   dp->panel = of_drm_find_panel(panel_node);
-   of_node_put(panel_node);
-   if (!dp->panel)
-   return -EPROBE_DEFER;
-   } else {
-   DRM_ERROR("no port node for panel device.\n");
-   return -EINVAL;
-   }
-   }
-   }
-
-   if (endpoint)
goto out;
+   }

endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
if (endpoint) {
-   bridge_node = of_graph_get_remote_port_parent(endpoint);
-   if (bridge_node) {
-   dp->ptn_bridge = of_drm_find_bridge(bridge_node);
-   of_node_put(bridge_node);
-   if (!dp->ptn_bridge)
-   return -EPROBE_DEFER;
-   } else
-   return -EPROBE_DEFER;
+   np = of_graph_get_remote_port_parent(endpoint);
+   if (np) {
+   /* The remote port can be either a panel or a bridge */
+   dp->panel = of_drm_find_panel(np);
+   if (!dp->panel) {
+   dp->ptn_bridge = of_drm_find_bridge(np);
+   if (!dp->ptn_bridge) {
+   of_node_put(np);
+   return -EPROBE_DEFER;
+   }
+   }
+   of_node_put(np);
+   } else {
+   DRM_ERROR("no remote endpoint device node found.\n");
+   return -EINVAL;
+   }
+   } else {
+   DRM_ERROR("no port endpoint subnode found.\n");
+   return -EINVAL;
}

 out:
-- 
2.5.0



[Bug 93928] Tonga valley regression since drm/amdgpu: split VM mappings into smaller operations (v2)

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93928

--- Comment #1 from Nicolai H�hnle  ---
Hi Andy, do you have a screenshot? What version of Mesa are you using? Anything
in 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/20160129/2bef24d0/attachment.html>


[PATCH] drm/amdgpu: no need to load MC firmware on fiji

2016-01-29 Thread Alex Deucher
Vbios does this for us on asic_init.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c0c9a01..875a5e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -44,7 +44,6 @@ static void gmc_v8_0_set_irq_funcs(struct amdgpu_device 
*adev);

 MODULE_FIRMWARE("amdgpu/topaz_mc.bin");
 MODULE_FIRMWARE("amdgpu/tonga_mc.bin");
-MODULE_FIRMWARE("amdgpu/fiji_mc.bin");

 static const u32 golden_settings_tonga_a11[] =
 {
@@ -236,8 +235,6 @@ static int gmc_v8_0_init_microcode(struct amdgpu_device 
*adev)
chip_name = "tonga";
break;
case CHIP_FIJI:
-   chip_name = "fiji";
-   break;
case CHIP_CARRIZO:
case CHIP_STONEY:
return 0;
@@ -1007,7 +1004,8 @@ static int gmc_v8_0_hw_init(void *handle)

gmc_v8_0_mc_program(adev);

-   if (!(adev->flags & AMD_IS_APU)) {
+   if ((adev->asic_type == CHIP_TOPAZ) ||
+   (adev->asic_type == CHIP_TONGA)) {
r = gmc_v8_0_mc_load_microcode(adev);
if (r) {
DRM_ERROR("Failed to load MC firmware!\n");
-- 
2.5.0



[PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain

2016-01-29 Thread Andy Shevchenko
On Thu, Jan 7, 2016 at 5:46 PM, Tomeu Vizoso  
wrote:
> Adds a function that sets the pointer to dev_pm_domain in struct device
> and that warns if the device has already finished probing. The reason
> why we want to enforce that is because in the general case that can
> cause problems and also that we can simplify code quite a bit if we can
> always assume that.
>
> This patch also changes all current code that directly sets the
> dev.pm_domain pointer.


> --- a/drivers/acpi/acpi_lpss.c
> +++ b/drivers/acpi/acpi_lpss.c

> @@ -875,13 +876,14 @@ static int acpi_lpss_platform_notify(struct 
> notifier_block *nb,
>
> switch (action) {
> case BUS_NOTIFY_BIND_DRIVER:
> -   pdev->dev.pm_domain = &acpi_lpss_pm_domain;
> +   dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
> break;
> case BUS_NOTIFY_DRIVER_NOT_BOUND:
> case BUS_NOTIFY_UNBOUND_DRIVER:
> pdev->dev.pm_domain = NULL;

Missed?

> break;
> case BUS_NOTIFY_ADD_DEVICE:
> +   dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
> if (pdata->dev_desc->flags & LPSS_LTR)
> return sysfs_create_group(&pdev->dev.kobj,
>   &lpss_attr_group);
> @@ -889,6 +891,7 @@ static int acpi_lpss_platform_notify(struct 
> notifier_block *nb,
> case BUS_NOTIFY_DEL_DEVICE:
> if (pdata->dev_desc->flags & LPSS_LTR)
> sysfs_remove_group(&pdev->dev.kobj, &lpss_attr_group);
> +   dev_pm_domain_set(&pdev->dev, NULL);
> break;
> default:
> break;

This looks wrong. I didn't test yet, but I have concerns here. Why did
you add those calls?

Have you been aware about the commit b5f88dd1d6ef ("Revert "ACPI /
LPSS: allow to use specific PM domain during ->probe()") ?

Sorry for being too late with this.

-- 
With Best Regards,
Andy Shevchenko


[PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain

2016-01-29 Thread Andy Shevchenko
On Fri, Jan 29, 2016 at 5:38 PM, Andy Shevchenko
 wrote:
> On Thu, Jan 7, 2016 at 5:46 PM, Tomeu Vizoso  
> wrote:
>> Adds a function that sets the pointer to dev_pm_domain in struct device
>> and that warns if the device has already finished probing. The reason
>> why we want to enforce that is because in the general case that can
>> cause problems and also that we can simplify code quite a bit if we can
>> always assume that.
>>
>> This patch also changes all current code that directly sets the
>> dev.pm_domain pointer.
>
>
>> --- a/drivers/acpi/acpi_lpss.c
>> +++ b/drivers/acpi/acpi_lpss.c
>
>> @@ -875,13 +876,14 @@ static int acpi_lpss_platform_notify(struct 
>> notifier_block *nb,
>>
>> switch (action) {
>> case BUS_NOTIFY_BIND_DRIVER:
>> -   pdev->dev.pm_domain = &acpi_lpss_pm_domain;
>> +   dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
>> break;
>> case BUS_NOTIFY_DRIVER_NOT_BOUND:
>> case BUS_NOTIFY_UNBOUND_DRIVER:
>> pdev->dev.pm_domain = NULL;
>
> Missed?
>
>> break;
>> case BUS_NOTIFY_ADD_DEVICE:
>> +   dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
>> if (pdata->dev_desc->flags & LPSS_LTR)
>> return sysfs_create_group(&pdev->dev.kobj,
>>   &lpss_attr_group);
>> @@ -889,6 +891,7 @@ static int acpi_lpss_platform_notify(struct 
>> notifier_block *nb,
>> case BUS_NOTIFY_DEL_DEVICE:
>> if (pdata->dev_desc->flags & LPSS_LTR)
>> sysfs_remove_group(&pdev->dev.kobj, 
>> &lpss_attr_group);
>> +   dev_pm_domain_set(&pdev->dev, NULL);
>> break;
>> default:
>> break;
>
> This looks wrong. I didn't test yet, but I have concerns here. Why did
> you add those calls?


Okay, for first glance it seems working on Intel Braswell. But can
yoyu point me out what was going on before this patch?

-- 
With Best Regards,
Andy Shevchenko


[PATCH libdrm] android: enable building static version of libdrm

2016-01-29 Thread Rob Herring
From: Sumit Semwal 

Android needs libdrm built statically for recovery;
enable that as well.

Signed-off-by: Sumit Semwal 
Signed-off-by: Rob Herring 
Cc: Chih-Wei Huang 
Cc: Emil Velikov 
---
I posted this to mesa-dev, but I guess libdrm patches are supposed to go 
to dri-devel.

Rob

 Android.mk | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Android.mk b/Android.mk
index 90cdcb3..1d8cd65 100644
--- a/Android.mk
+++ b/Android.mk
@@ -27,6 +27,8 @@ include $(CLEAR_VARS)
 # Import variables LIBDRM_{,H_,INCLUDE_H_,INCLUDE_VMWGFX_H_}FILES
 include $(LOCAL_PATH)/Makefile.sources

+#static library for the device (recovery)
+include $(CLEAR_VARS)
 LOCAL_MODULE := libdrm
 LOCAL_MODULE_TAGS := optional

@@ -41,7 +43,24 @@ LOCAL_C_INCLUDES := \
 LOCAL_CFLAGS := \
-DHAVE_VISIBILITY=1 \
-DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
+include $(BUILD_STATIC_LIBRARY)
+
+# Shared library for the device
+include $(CLEAR_VARS)
+LOCAL_MODULE := libdrm
+LOCAL_MODULE_TAGS := optional

+LOCAL_SRC_FILES := $(LIBDRM_FILES)
+LOCAL_EXPORT_C_INCLUDE_DIRS := \
+$(LOCAL_PATH) \
+$(LOCAL_PATH)/include/drm
+
+LOCAL_C_INCLUDES := \
+$(LOCAL_PATH)/include/drm
+
+LOCAL_CFLAGS := \
+-DHAVE_VISIBILITY=1 \
+-DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
 include $(BUILD_SHARED_LIBRARY)

 include $(call all-makefiles-under,$(LOCAL_PATH))
-- 
2.5.0



[Bug 93928] Tonga valley regression since drm/amdgpu: split VM mappings into smaller operations (v2)

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93928

--- Comment #2 from Christian K�nig  ---
Crap, that looks like I haven't pushed the latest version of that to our server
where Alex picket it up. There are numerous bugs in the version of the patch
which went upstream.

I'm going to take a look what went wrong as soon as I have time (going to
FOSDEM this weekend).

-- 
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/20160129/2f34f842/attachment.html>


[PATCH 00/11] sync framework de-staging: part 1 - clean up

2016-01-29 Thread Greg Kroah-Hartman
On Fri, Jan 29, 2016 at 12:47:20PM -0200, Gustavo Padovan wrote:
> Hi,
> 
> 2016-01-25 Maarten Lankhorst :
> 
> > Hey,
> > 
> > Op 21-01-16 om 13:49 schreef Gustavo Padovan:
> > > From: Gustavo Padovan 
> > >
> > > Hi,
> > >
> > > The following patches are some clean ups on the sync framework before
> > > we start the actual de-staging. The main changes here are the move of
> > > SW_SYNC_USER to debugfs. Removal of struct sync_pt in favor of direct
> > > use of struct fence. And the rename of sync_fence to sync_file, a name
> > > to better reflect what it is for, a struct that connects struct fence(s)
> > > to a file.
> > >
> > > Please review. Thanks.
> > >
> > > Gustavo Padovan (11):
> > >   staging/android: fix sync framework documentation
> > >   staging/android: sync: remove interfaces that are not used
> > >   staging/android: remove not used sync_timeline ops
> > >   staging/android: create a 'sync' dir for debugfs information
> > >   staging/android: move SW_SYNC_USER to a debugfs file
> > >   staging/android: rename sync_fence to sync_file
> > >   staging/android: rename 'sync_pt' to 'fence' in struct sync_fence_cb
> > >   staging/android: remove struct sync_pt
> > >   staging/android: remove unused var from sync_timeline_signal()
> > >   staging/android: remove pointless sync_timeline_signal at destroy
> > > phase
> > >   staging/android: remove sync_fence_create_dma()
> > >
> > For whole series:
> > Reviewed-by: Maarten Lankhorst 
> > 
> > Renaming sync_fence to sync_file makes sense, it should hopefully reduce 
> > confusion.
> 
> Poke. What is missing for this to go upstream? Do I need more review
> here? Thanks.

You just sent this, give me a chance to get to it, my staging patch
queue is over 1000 patches at the moment :(

greg k-h


[Bug 93928] Tonga valley regression since drm/amdgpu: split VM mappings into smaller operations (v2)

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93928

--- Comment #3 from Alex Deucher  ---
I'll drop them from my wip tree for 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/20160129/a5e63bb7/attachment.html>


[PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain

2016-01-29 Thread Andy Shevchenko
On Fri, Jan 29, 2016 at 5:51 PM, Andy Shevchenko
 wrote:
> On Fri, Jan 29, 2016 at 5:38 PM, Andy Shevchenko
>  wrote:
>> On Thu, Jan 7, 2016 at 5:46 PM, Tomeu Vizoso  
>> wrote:
>>> Adds a function that sets the pointer to dev_pm_domain in struct device
>>> and that warns if the device has already finished probing. The reason
>>> why we want to enforce that is because in the general case that can
>>> cause problems and also that we can simplify code quite a bit if we can
>>> always assume that.
>>>
>>> This patch also changes all current code that directly sets the
>>> dev.pm_domain pointer.
>>
>>
>>> --- a/drivers/acpi/acpi_lpss.c
>>> +++ b/drivers/acpi/acpi_lpss.c
>>
>>> @@ -875,13 +876,14 @@ static int acpi_lpss_platform_notify(struct 
>>> notifier_block *nb,
>>>
>>> switch (action) {
>>> case BUS_NOTIFY_BIND_DRIVER:
>>> -   pdev->dev.pm_domain = &acpi_lpss_pm_domain;
>>> +   dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
>>> break;
>>> case BUS_NOTIFY_DRIVER_NOT_BOUND:
>>> case BUS_NOTIFY_UNBOUND_DRIVER:
>>> pdev->dev.pm_domain = NULL;
>>
>> Missed?
>>
>>> break;
>>> case BUS_NOTIFY_ADD_DEVICE:
>>> +   dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
>>> if (pdata->dev_desc->flags & LPSS_LTR)
>>> return sysfs_create_group(&pdev->dev.kobj,
>>>   &lpss_attr_group);
>>> @@ -889,6 +891,7 @@ static int acpi_lpss_platform_notify(struct 
>>> notifier_block *nb,
>>> case BUS_NOTIFY_DEL_DEVICE:
>>> if (pdata->dev_desc->flags & LPSS_LTR)
>>> sysfs_remove_group(&pdev->dev.kobj, 
>>> &lpss_attr_group);
>>> +   dev_pm_domain_set(&pdev->dev, NULL);
>>> break;
>>> default:
>>> break;
>>
>> This looks wrong. I didn't test yet, but I have concerns here. Why did
>> you add those calls?
>
>
> Okay, for first glance it seems working on Intel Braswell.

One more test unveils this one

# modprobe -r sdhci-acpi
[ 1289.909441] [ cut here ]
[ 1289.918205] WARNING: CPU: 1 PID: 4374 at
/home/andy/prj/linux-otc/drivers/base/power/common.c:150
dev_pm_domain_set+0x51/0x60()
[ 1289.934681] PM domains can only be changed for unbound devices
[ 1289.944843] Modules linked in: sdhci_acpi(-) sdhci mmc_core
led_class [last unloaded: dw_dmac_core]
[ 1289.958802] CPU: 1 PID: 4374 Comm: modprobe Not tainted 4.5.0-rc1+ #3
[ 1289.969736]  81c38330 88007bb53d18 8133162f
88007bb53d60
[ 1289.981844]  88007bb53d50 8105cd12 88017a007410

[ 1289.993996]  0001 0080 
88007bb53db0
[ 1290.006123] Call Trace:
[ 1290.012600]  [] dump_stack+0x44/0x55
[ 1290.022052]  [] warn_slowpath_common+0x82/0xc0
[ 1290.032462]  [] warn_slowpath_fmt+0x4c/0x50
[ 1290.042589]  [] dev_pm_domain_set+0x51/0x60
[ 1290.052695]  [] acpi_dev_pm_detach+0x3f/0x84
[ 1290.062910]  [] dev_pm_domain_detach+0x27/0x30
[ 1290.073294]  [] platform_drv_remove+0x38/0x40
[ 1290.083585]  [] __device_release_driver+0xa1/0x160
[ 1290.094335]  [] driver_detach+0xa6/0xb0
[ 1290.104009]  [] bus_remove_driver+0x55/0xd0
[ 1290.114053]  [] driver_unregister+0x2c/0x50
[ 1290.124076]  [] platform_driver_unregister+0x12/0x20
[ 1290.134957]  [] sdhci_acpi_driver_exit+0x10/0x12
[sdhci_acpi]
[ 1290.146730]  [] SyS_delete_module+0x199/0x240
[ 1290.156907]  [] ? exit_to_usermode_loop+0x8b/0x90
[ 1290.167478]  [] do_syscall_32_irqs_off+0x53/0xa0
[ 1290.177949]  [] entry_INT80_compat+0x2a/0x40
[ 1290.187986] ---[ end trace a8351c0506ee239b ]---
[ 1290.213855] mmc0: card 0001 removed

Which function is guilty?

> But can
> yoyu point me out what was going on before this patch?

-- 
With Best Regards,
Andy Shevchenko


[Bug 93928] Tonga valley regression since drm/amdgpu: split VM mappings into smaller operations (v2)

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93928

--- Comment #4 from Andy Furniss  ---
(In reply to Alex Deucher from comment #3)
> I'll drop them from my wip tree for now.

OK and have a good time at FOSDEM

-- 
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/20160129/cfa5bdac/attachment.html>


[Bug 93928] Tonga valley regression since drm/amdgpu: split VM mappings into smaller operations (v2)

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93928

--- Comment #5 from Andy Furniss  ---
There was nothing in 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/20160129/9b46d32b/attachment-0001.html>


Exynos Snow board display regression

2016-01-29 Thread Javier Martinez Canillas
Hello Michal,

On 01/29/2016 02:07 PM, Michal Suchanek wrote:
> Hello,
>
> after  commit a9fa852886fd5a7ccec3b7e9eff75f85072f009c
>
> display no longer works on the Snow board. The built-in panel is no
> longer probed.
>
> The commit *supposedly* provides for backwards compatibility and at
> first glance only new options for probing the panel are added.
>
> However, reverting the commit on top of 4.5-rc1 gives working display
> again so there is probably some subtle non-obvious catch in the logic.
>
> Any ideas what might go wrong here?
>

Yes, I noticed the same and posted a fix some hours ago:

https://lkml.org/lkml/2016/1/29/355

> Thanks
>
> Michal
>

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


[PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file

2016-01-29 Thread Greg Hackmann
On 01/28/16 01:23, Daniel Vetter wrote:
> And I think driver_data really shouldn't be there, it makes things
> complicated with the array of variable-sized objects, and generic
> userspace can't really use it - for debug output we already have
> obj/driver_name per fence point, which I think is good enough.

I looked at our device kernels, and some vendors actually are filling in 
driver_data.  I'm just not seeing any accesses to them in our 
*userspace* tree.  And in a lot of cases it looks like they're just 
filling in debugging information that they could get elsewhere.

I'm checking with our vendor contacts to see what they're actually using 
this for (if anything).

> Would that be ok for you from the Android side if Gustavo also provides a
> patch to update libsync? I don't think the ABI is fundamentally broken,
> but this light cleanup would be nice.

No objections here.  Just upload the changes to AOSP and add me as a 
reviewer.

> Wrt keeping SYNC_WAIT: I think that's totally fine. Redundant since
> polling is supported, but not really an issue imo either. If we're totally
> lazy we could implement SYNC_WAIT internally using poll and shave off a
> few lines of the implementation.

Honestly this is the change I'm least worried about, since poll() will 
work with existing kernels too.  The only difference would be that the 
SYNC_WAIT ioctl fails when given something that's not specifically a 
sync fence; but I'm skeptical that anything actually depends on that 
behavior.


[PATCH] adv7511: Added mode_fixup function.

2016-01-29 Thread Laurent Pinchart
Hi Carlos,

Thank you for the patch.

On Friday 29 January 2016 10:33:47 Carlos Palminha wrote:
> The mode_fixup is necessary when using it in a DRM FB driver pipeline.

Instead of implementing stubs in encoder drivers, wouldn't it be better to 
make mode_fixup optional ?

> Signed-off-by: Carlos Palminha 
> ---
>  drivers/gpu/drm/i2c/adv7511.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
> index 533d1e3..90082d2 100644
> --- a/drivers/gpu/drm/i2c/adv7511.c
> +++ b/drivers/gpu/drm/i2c/adv7511.c
> @@ -648,6 +648,13 @@ adv7511_encoder_detect(struct drm_encoder *encoder,
>   return status;
>  }
> 
> +static bool adv7511_encoder_mode_fixup(struct drm_encoder *encoder,
> + const struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + return true;
> +}
> +
>  static int adv7511_encoder_mode_valid(struct drm_encoder *encoder,
> struct drm_display_mode *mode)
>  {
> @@ -754,6 +761,7 @@ static void adv7511_encoder_mode_set(struct drm_encoder
> *encoder,
> 
>  static const struct drm_encoder_slave_funcs adv7511_encoder_funcs = {
>   .dpms = adv7511_encoder_dpms,
> + .mode_fixup = adv7511_encoder_mode_fixup,
>   .mode_valid = adv7511_encoder_mode_valid,
>   .mode_set = adv7511_encoder_mode_set,
>   .detect = adv7511_encoder_detect,

-- 
Regards,

Laurent Pinchart



[PATCH v3 06/18] drm: Add drm_format_plane_width() and drm_format_plane_height()

2016-01-29 Thread ville.syrj...@linux.intel.com
From: Ville Syrjälä 

Add a few helpers to get the dimensions of the chroma plane(s).

v2: Add kernel-doc (Daniel)
v3: Fix kerneldoc "Returns:" style (Daniel)
Uninline the functions and check for num_planes (Daniel)

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 40 
 include/drm/drm_crtc.h |  2 ++
 2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6e6514ef9968..c708b37972de 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5715,6 +5715,46 @@ int drm_format_vert_chroma_subsampling(uint32_t format)
 EXPORT_SYMBOL(drm_format_vert_chroma_subsampling);

 /**
+ * drm_format_plane_width - width of the plane given the first plane
+ * @width: width of the first plane
+ * @format: pixel format
+ * @plane: plane index
+ *
+ * Returns:
+ * The width of @plane, given that the width of the first plane is @width.
+ */
+int drm_format_plane_width(int width, uint32_t format, int plane)
+{
+   if (plane >= drm_format_num_planes(format))
+   return 0;
+
+   if (plane == 0)
+   return width;
+
+   return width / drm_format_horz_chroma_subsampling(format);
+}
+
+/**
+ * drm_format_plane_height - height of the plane given the first plane
+ * @height: height of the first plane
+ * @format: pixel format
+ * @plane: plane index
+ *
+ * Returns:
+ * The height of @plane, given that the height of the first plane is @height.
+ */
+int drm_format_plane_height(int height, uint32_t format, int plane)
+{
+   if (plane >= drm_format_num_planes(format))
+   return 0;
+
+   if (plane == 0)
+   return height;
+
+   return height / drm_format_vert_chroma_subsampling(format);
+}
+
+/**
  * drm_rotation_simplify() - Try to simplify the rotation
  * @rotation: Rotation to be simplified
  * @supported_rotations: Supported rotations
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c65a212db77e..3a4b53ecd121 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2482,6 +2482,8 @@ extern int drm_format_num_planes(uint32_t format);
 extern int drm_format_plane_cpp(uint32_t format, int plane);
 extern int drm_format_horz_chroma_subsampling(uint32_t format);
 extern int drm_format_vert_chroma_subsampling(uint32_t format);
+extern int drm_format_plane_width(int width, uint32_t format, int plane);
+extern int drm_format_plane_height(int height, uint32_t format, int plane);
 extern const char *drm_get_format_name(uint32_t format);
 extern struct drm_property *drm_mode_create_rotation_property(struct 
drm_device *dev,
  unsigned int 
supported_rotations);
-- 
2.4.10



[PATCH] gma500: handling failed allocation

2016-01-29 Thread One Thousand Gnomes
On Thu, 28 Jan 2016 19:05:16 -0500
Insu Yun  wrote:

> Since drm_property_create_range can be failed in memory pressure, 
> it needs to be handled.
> 
> Signed-off-by: Insu Yun 
> ---
>  drivers/gpu/drm/gma500/framebuffer.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
> b/drivers/gpu/drm/gma500/framebuffer.c
> index cb95765..31085e4 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -683,6 +683,8 @@ static int psb_create_backlight_property(struct 
> drm_device *dev)
>   return 0;
>  
>   backlight = drm_property_create_range(dev, 0, "backlight", 0, 100);
> + if (!backlight)
> + return -ENOMEM;
>  
>   dev_priv->backlight_property = backlight;
>  

NAK.

If we fail to create the backlight we are better off continuing than
failing. The user just loses backlight control rather than having no
display at all.

If you check the callers you'll notice that the only caller doesn't even
check the return code anyway so your patch is a no-op. If you are going
to add error checking to anything with a patch please work back through
the call chain and check the effect of the new error return - if any.

A better patch I think would be to just eliminate the function and turn
it into a tiny bit of inlined code.

I'll send a patch to do that shortly.

Alan





[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #79 from Ioannis Panagiotopoulos  ---
Ok, after further testing, It ends up that it might be a xserver driver
problem. I downgraded to ver 7.3.0 x-server driver and the system booted with
dpm enabled, however the Xserver did not have Hardware acceleration. Upgrading
to the latest (7.6.x), makes the x-server fail to start with enabled dpm.

-- 
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/20160129/fe6d0f70/attachment.html>


[PATCH] gma500: clean up an excessive and confusing helper

2016-01-29 Thread Alan
From: Alan Cox 

This is a left over from the great clean ups in the past. It's confusing as
it returns an int, yet has one caller that never uses it. The caller already
has all the right private variables local so the entire function can be
replaced by a simple if call.

Signed-off-by: Alan Cox 
---
 drivers/gpu/drm/gma500/framebuffer.c |   20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index cb95765..033d894 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -674,29 +674,17 @@ static const struct drm_mode_config_funcs psb_mode_funcs 
= {
.output_poll_changed = psbfb_output_poll_changed,
 };

-static int psb_create_backlight_property(struct drm_device *dev)
-{
-   struct drm_psb_private *dev_priv = dev->dev_private;
-   struct drm_property *backlight;
-
-   if (dev_priv->backlight_property)
-   return 0;
-
-   backlight = drm_property_create_range(dev, 0, "backlight", 0, 100);
-
-   dev_priv->backlight_property = backlight;
-
-   return 0;
-}
-
 static void psb_setup_outputs(struct drm_device *dev)
 {
struct drm_psb_private *dev_priv = dev->dev_private;
struct drm_connector *connector;

drm_mode_create_scaling_mode_property(dev);
-   psb_create_backlight_property(dev);

+   /* It is ok for this to fail - we just don't get backlight control */
+   if (!dev_priv->backlight_property)
+   dev_priv->backlight_property = drm_property_create_range(dev, 0,
+   "backlight", 0, 100);
dev_priv->ops->output_init(dev);

list_for_each_entry(connector, &dev->mode_config.connector_list,



[PATCH] gma500: handling failed allocation

2016-01-29 Thread Insu Yun
On Fri, Jan 29, 2016 at 12:46 PM, One Thousand Gnomes <
gnomes at lxorguk.ukuu.org.uk> wrote:

> On Thu, 28 Jan 2016 19:05:16 -0500
> Insu Yun  wrote:
>
> > Since drm_property_create_range can be failed in memory pressure,
> > it needs to be handled.
> >
> > Signed-off-by: Insu Yun 
> > ---
> >  drivers/gpu/drm/gma500/framebuffer.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> b/drivers/gpu/drm/gma500/framebuffer.c
> > index cb95765..31085e4 100644
> > --- a/drivers/gpu/drm/gma500/framebuffer.c
> > +++ b/drivers/gpu/drm/gma500/framebuffer.c
> > @@ -683,6 +683,8 @@ static int psb_create_backlight_property(struct
> drm_device *dev)
> >   return 0;
> >
> >   backlight = drm_property_create_range(dev, 0, "backlight", 0, 100);
> > + if (!backlight)
> > + return -ENOMEM;
> >
> >   dev_priv->backlight_property = backlight;
> >
>
> NAK.
>
> If we fail to create the backlight we are better off continuing than
> failing. The user just loses backlight control rather than having no
> display at all.
>
> If you check the callers you'll notice that the only caller doesn't even
> check the return code anyway so your patch is a no-op. If you are going
> to add error checking to anything with a patch please work back through
> the call chain and check the effect of the new error return - if any.
>
> A better patch I think would be to just eliminate the function and turn
> it into a tiny bit of inlined code.
>
> I'll send a patch to do that shortly.
>

Thanks


>
> Alan
>
>
>
>


-- 
Regards
Insu Yun
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160129/13658e6e/attachment-0001.html>


Exynos Snow board display regression

2016-01-29 Thread Michal Suchanek
On 29 January 2016 at 18:18, Javier Martinez Canillas
 wrote:
> Hello Michal,
>
> On 01/29/2016 02:07 PM, Michal Suchanek wrote:
>>
>> Hello,
>>
>> after  commit a9fa852886fd5a7ccec3b7e9eff75f85072f009c
>>
>> display no longer works on the Snow board. The built-in panel is no
>> longer probed.
>>
> Yes, I noticed the same and posted a fix some hours ago:
>
> https://lkml.org/lkml/2016/1/29/355
>
Tested-by: Michal Suchanek 

on that patch.

Thanks

Michal


Exynos Snow board display regression

2016-01-29 Thread Michal Suchanek
Hello,

after  commit a9fa852886fd5a7ccec3b7e9eff75f85072f009c

display no longer works on the Snow board. The built-in panel is no
longer probed.

The commit *supposedly* provides for backwards compatibility and at
first glance only new options for probing the panel are added.

However, reverting the commit on top of 4.5-rc1 gives working display
again so there is probably some subtle non-obvious catch in the logic.

Any ideas what might go wrong here?

Thanks

Michal

Author: Inki Dae 
Date:   Thu Nov 26 21:34:18 2015 +0900

drm/exynos: dp: add of_graph dt binding support for panel

This patch adds of_graph dt binding support for panel device
and also keeps the backward compatibility.

i.e.,
The dts file for Exynos5800 based peach pi board
has a panel property so we need to keep the backward compatibility.

Changelog v3:
- bind only one of two nodes outbound - panel or bridge.

Changelog v2:
- return -EINVAL if getting a port node failed.

Signed-off-by: Inki Dae 
Reviewed-by: Javier Martinez Canillas 

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 94f02a0..60260a0 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
 static int exynos_dp_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
-   struct device_node *panel_node, *bridge_node, *endpoint;
+   struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
struct exynos_dp_device *dp;
int ret;

@@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device *pdev)

platform_set_drvdata(pdev, dp);

+   /* This is for the backward compatibility. */
panel_node = of_parse_phandle(dev->of_node, "panel", 0);
if (panel_node) {
dp->panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
if (!dp->panel)
return -EPROBE_DEFER;
+   } else {
+   endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+   if (endpoint) {
+   panel_node = of_graph_get_remote_port_parent(endpoint);
+   if (panel_node) {
+   dp->panel = of_drm_find_panel(panel_node);
+   of_node_put(panel_node);
+   if (!dp->panel)
+   return -EPROBE_DEFER;
+   } else {
+   DRM_ERROR("no port node for panel device.\n");
+   return -EINVAL;
+   }
+   }
}

+   if (endpoint)
+   goto out;
+
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
if (endpoint) {
bridge_node = of_graph_get_remote_port_parent(endpoint);
@@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}

+out:
pm_runtime_enable(dev);

ret = component_add(&pdev->dev, &exynos_dp_ops);


[PATCH 00/10] android sync framework: clean up IOCTLs and ABI.

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

Hi,

This patch series clean up IOCTLs and abi of sync framework and it is a follow
up on the clean up series I've sent on Jan 21:

http://thread.gmane.org/gmane.comp.video.dri.devel/145509

The main changes here are:

 * remove of SYNC_WAIT ioctl, poll() should be used instead.
 * rename some structs and macros to better reflect the new internal names.
 * clean up and improve ABI on SYNC_IOC_FILE_INFO
 * add flags filed to all ABI structs

Please review, thanks!

Gustavo Padovan (10):
  staging/android: remove SYNC_WAIT ioctl
  staging/android: rename sync_pt_info to fence_info
  staging/android: rename sync_file_info_data to sync_file_info
  staging/android: remove driver_data from struct fence_info
  staging/android: remove len field from struct fence_info
  staging/android: turn fence_info into a __64 pointer
  staging/android: add num_fences field to struct sync_file_info
  staging/android: rename SYNC_IOC_FENCE_INFO
  staging/android: add flags member to sync ioctl structs
  staging/android: remove redundant comments on sync_merge_data

 drivers/staging/android/sw_sync.c|  14 -
 drivers/staging/android/sync.c   | 113 +++
 drivers/staging/android/sync.h   |  20 ---
 drivers/staging/android/trace/sync.h |  44 --
 drivers/staging/android/uapi/sync.h  |  45 +++---
 5 files changed, 40 insertions(+), 196 deletions(-)

-- 
2.5.0



[PATCH 01/10] staging/android: remove SYNC_WAIT ioctl

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

This ioctl is replicating the work of poll() syscall so let's take the
opportunity that this is still on staging tree and remove the duplication
and force new users to use the poll() standard interface.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c   | 52 
 drivers/staging/android/sync.h   | 13 -
 drivers/staging/android/trace/sync.h | 44 --
 drivers/staging/android/uapi/sync.h  |  7 -
 4 files changed, 116 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 5fa4779..381209a 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -300,44 +300,6 @@ struct sync_file *sync_file_merge(const char *name,
 }
 EXPORT_SYMBOL(sync_file_merge);

-int sync_file_wait(struct sync_file *sync_file, long timeout)
-{
-   long ret;
-   int i;
-
-   if (timeout < 0)
-   timeout = MAX_SCHEDULE_TIMEOUT;
-   else
-   timeout = msecs_to_jiffies(timeout);
-
-   trace_sync_wait(sync_file, 1);
-   for (i = 0; i < sync_file->num_fences; ++i)
-   trace_fence(sync_file->cbs[i].fence);
-   ret = wait_event_interruptible_timeout(sync_file->wq,
-  atomic_read(&sync_file->status) 
<= 0,
-  timeout);
-   trace_sync_wait(sync_file, 0);
-
-   if (ret < 0) {
-   return ret;
-   } else if (ret == 0) {
-   if (timeout) {
-   pr_info("sync_file timeout on [%p] after %dms\n",
-   sync_file, jiffies_to_msecs(timeout));
-   sync_dump();
-   }
-   return -ETIME;
-   }
-
-   ret = atomic_read(&sync_file->status);
-   if (ret) {
-   pr_info("sync_file error %ld on [%p]\n", ret, sync_file);
-   sync_dump();
-   }
-   return ret;
-}
-EXPORT_SYMBOL(sync_file_wait);
-
 static const char *android_fence_get_driver_name(struct fence *fence)
 {
struct sync_timeline *parent = fence_parent(fence);
@@ -478,17 +440,6 @@ static unsigned int sync_file_poll(struct file *file, 
poll_table *wait)
return 0;
 }

-static long sync_file_ioctl_wait(struct sync_file *sync_file,
- unsigned long arg)
-{
-   __s32 value;
-
-   if (copy_from_user(&value, (void __user *)arg, sizeof(value)))
-   return -EFAULT;
-
-   return sync_file_wait(sync_file, value);
-}
-
 static long sync_file_ioctl_merge(struct sync_file *sync_file,
   unsigned long arg)
 {
@@ -629,9 +580,6 @@ static long sync_file_ioctl(struct file *file, unsigned int 
cmd,
struct sync_file *sync_file = file->private_data;

switch (cmd) {
-   case SYNC_IOC_WAIT:
-   return sync_file_ioctl_wait(sync_file, arg);
-
case SYNC_IOC_MERGE:
return sync_file_ioctl_merge(sync_file, arg);

diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 8980b55..af1af99 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 

 #include "uapi/sync.h"
@@ -230,18 +229,6 @@ void sync_file_put(struct sync_file *sync_file);
  */
 void sync_file_install(struct sync_file *sync_file, int fd);

-/**
- * sync_file_wait() - wait on sync file
- * @sync_file: file to wait on
- * @tiemout:   timeout in ms
- *
- * Wait for @sync_file to be signaled or have an error. Waits indefinitely
- * if @timeout < 0.
- *
- * Returns 0 if fence signaled, > 0 if it is still active and <0 on error
- */
-int sync_file_wait(struct sync_file *sync_file, long timeout);
-
 #ifdef CONFIG_DEBUG_FS

 void sync_timeline_debug_add(struct sync_timeline *obj);
diff --git a/drivers/staging/android/trace/sync.h 
b/drivers/staging/android/trace/sync.h
index 87c60e9..a0f80f4 100644
--- a/drivers/staging/android/trace/sync.h
+++ b/drivers/staging/android/trace/sync.h
@@ -32,50 +32,6 @@ TRACE_EVENT(sync_timeline,
TP_printk("name=%s value=%s", __get_str(name), __entry->value)
 );

-TRACE_EVENT(sync_wait,
-   TP_PROTO(struct sync_file *sync_file, int begin),
-
-   TP_ARGS(sync_file, begin),
-
-   TP_STRUCT__entry(
-   __string(name, sync_file->name)
-   __field(s32, status)
-   __field(u32, begin)
-   ),
-
-   TP_fast_assign(
-   __assign_str(name, sync_file->name);
-   __entry->status = atomic_read(&sync_file->status);
-   __entry->begin = begin;
-   ),
-
-   TP_printk("%s name=%s state=%d", __entry->begin ? "begin" : "end",
-   __get_str(name), __entry->status)
-);
-
-TRACE_EVENT(fence,
-   TP_PROTO(struct fence *f

[PATCH 02/10] staging/android: rename sync_pt_info to fence_info

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

As struct sync_pt doesn't exist anymore it is a good idea remove any
reference to it in the sync_framework. sync_pts were replaced directly by
fences.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  |  8 
 drivers/staging/android/uapi/sync.h | 12 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 381209a..ed63001 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -490,12 +490,12 @@ err_put_fd:
return err;
 }

-static int sync_fill_pt_info(struct fence *fence, void *data, int size)
+static int sync_fill_fence_info(struct fence *fence, void *data, int size)
 {
-   struct sync_pt_info *info = data;
+   struct fence_info *info = data;
int ret;

-   if (size < sizeof(struct sync_pt_info))
+   if (size < sizeof(*info))
return -ENOMEM;

info->len = sizeof(struct sync_pt_info);
@@ -553,7 +553,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
for (i = 0; i < sync_file->num_fences; ++i) {
struct fence *fence = sync_file->cbs[i].fence;

-   ret = sync_fill_pt_info(fence, (u8 *)data + len, size - len);
+   ret = sync_fill_fence_info(fence, (u8 *)data + len, size - len);

if (ret < 0)
goto out;
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index 6c88c80..c4703ec 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -27,15 +27,15 @@ struct sync_merge_data {
 };

 /**
- * struct sync_pt_info - detailed sync_pt information
- * @len:   length of sync_pt_info including any driver_data
+ * struct fence_info - detailed fence information
+ * @len:   length of fence_info including any driver_data
  * @obj_name:  name of parent sync_timeline
  * @driver_name:   name of driver implementing the parent
- * @status:status of the sync_pt 0:active 1:signaled <0:error
+ * @status:status of the fence 0:active 1:signaled <0:error
  * @timestamp_ns:  timestamp of status change in nanoseconds
  * @driver_data:   any driver dependent data
  */
-struct sync_pt_info {
+struct fence_info {
__u32   len;
charobj_name[32];
chardriver_name[32];
@@ -52,14 +52,14 @@ struct sync_pt_info {
  * userspace including pt_info.
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
- * @pt_info:   a sync_pt_info struct for every sync_pt in the fence
+ * @fence_info:a fence_info struct for every fence in the sync_file
  */
 struct sync_file_info_data {
__u32   len;
charname[32];
__s32   status;

-   __u8pt_info[0];
+   __u8fence_info[0];
 };

 #define SYNC_IOC_MAGIC '>'
-- 
2.5.0



[PATCH 03/10] staging/android: rename sync_file_info_data to sync_file_info

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

info_data is a bit redundant, let's keep it as only sync_file_info. It is
also smaller.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 26 +-
 drivers/staging/android/uapi/sync.h |  9 -
 2 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index ed63001..a1cf9fd 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -525,7 +525,7 @@ static int sync_fill_fence_info(struct fence *fence, void 
*data, int size)
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
 {
-   struct sync_file_info_data *data;
+   struct sync_file_info *info;
__u32 size;
__u32 len = 0;
int ret, i;
@@ -533,27 +533,27 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
return -EFAULT;

-   if (size < sizeof(struct sync_file_info_data))
+   if (size < sizeof(struct sync_file_info))
return -EINVAL;

if (size > 4096)
size = 4096;

-   data = kzalloc(size, GFP_KERNEL);
-   if (!data)
+   info = kzalloc(size, GFP_KERNEL);
+   if (!info)
return -ENOMEM;

-   strlcpy(data->name, sync_file->name, sizeof(data->name));
-   data->status = atomic_read(&sync_file->status);
-   if (data->status >= 0)
-   data->status = !data->status;
+   strlcpy(info->name, sync_file->name, sizeof(info->name));
+   info->status = atomic_read(&sync_file->status);
+   if (info->status >= 0)
+   info->status = !info->status;

-   len = sizeof(struct sync_file_info_data);
+   len = sizeof(struct sync_file_info);

for (i = 0; i < sync_file->num_fences; ++i) {
struct fence *fence = sync_file->cbs[i].fence;

-   ret = sync_fill_fence_info(fence, (u8 *)data + len, size - len);
+   ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);

if (ret < 0)
goto out;
@@ -561,15 +561,15 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
len += ret;
}

-   data->len = len;
+   info->len = len;

-   if (copy_to_user((void __user *)arg, data, len))
+   if (copy_to_user((void __user *)arg, info, len))
ret = -EFAULT;
else
ret = 0;

 out:
-   kfree(data);
+   kfree(info);

return ret;
 }
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index c4703ec..70d05ad 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -46,15 +46,15 @@ struct fence_info {
 };

 /**
- * struct sync_file_info_data - data returned from fence info ioctl
+ * struct sync_file_info - data returned from fence info ioctl
  * @len:   ioctl caller writes the size of the buffer its passing in.
- * ioctl returns length of sync_file_info_data returned to
+ * ioctl returns length of sync_file_info returned to
  * userspace including pt_info.
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
  * @fence_info:a fence_info struct for every fence in the sync_file
  */
-struct sync_file_info_data {
+struct sync_file_info {
__u32   len;
charname[32];
__s32   status;
@@ -84,7 +84,6 @@ struct sync_file_info_data {
  * pt_info is a buffer containing sync_pt_infos for every sync_pt in the fence.
  * To iterate over the sync_pt_infos, use the sync_pt_info.len field.
  */
-#define SYNC_IOC_FENCE_INFO_IOWR(SYNC_IOC_MAGIC, 2,\
-   struct sync_file_info_data)
+#define SYNC_IOC_FENCE_INFO_IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)

 #endif /* _UAPI_LINUX_SYNC_H */
-- 
2.5.0



[PATCH 04/10] staging/android: remove driver_data from struct fence_info

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

It is unclear in what situations driver_data should be used thus better do
not upstream it for now. If a need arises in the future a discussion can
be started to re-add it.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sw_sync.c   | 14 --
 drivers/staging/android/sync.c  | 21 -
 drivers/staging/android/sync.h  |  7 ---
 drivers/staging/android/uapi/sync.h |  5 +
 4 files changed, 1 insertion(+), 46 deletions(-)

diff --git a/drivers/staging/android/sw_sync.c 
b/drivers/staging/android/sw_sync.c
index 3bee959..af39ff5 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -47,19 +47,6 @@ static int sw_sync_fence_has_signaled(struct fence *fence)
return (pt->value > obj->value) ? 0 : 1;
 }

-static int sw_sync_fill_driver_data(struct fence *fence,
-   void *data, int size)
-{
-   struct sw_sync_pt *pt = (struct sw_sync_pt *)fence;
-
-   if (size < sizeof(pt->value))
-   return -ENOMEM;
-
-   memcpy(data, &pt->value, sizeof(pt->value));
-
-   return sizeof(pt->value);
-}
-
 static void sw_sync_timeline_value_str(struct sync_timeline *sync_timeline,
   char *str, int size)
 {
@@ -78,7 +65,6 @@ static void sw_sync_fence_value_str(struct fence *fence, char 
*str, int size)
 static struct sync_timeline_ops sw_sync_timeline_ops = {
.driver_name = "sw_sync",
.has_signaled = sw_sync_fence_has_signaled,
-   .fill_driver_data = sw_sync_fill_driver_data,
.timeline_value_str = sw_sync_timeline_value_str,
.fence_value_str = sw_sync_fence_value_str,
 };
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index a1cf9fd..ced6e61 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -351,16 +351,6 @@ static bool android_fence_enable_signaling(struct fence 
*fence)
return true;
 }

-static int android_fence_fill_driver_data(struct fence *fence,
- void *data, int size)
-{
-   struct sync_timeline *parent = fence_parent(fence);
-
-   if (!parent->ops->fill_driver_data)
-   return 0;
-   return parent->ops->fill_driver_data(fence, data, size);
-}
-
 static void android_fence_value_str(struct fence *fence,
char *str, int size)
 {
@@ -394,7 +384,6 @@ static const struct fence_ops android_fence_ops = {
.signaled = android_fence_signaled,
.wait = fence_default_wait,
.release = android_fence_release,
-   .fill_driver_data = android_fence_fill_driver_data,
.fence_value_str = android_fence_value_str,
.timeline_value_str = android_fence_timeline_value_str,
 };
@@ -493,22 +482,12 @@ err_put_fd:
 static int sync_fill_fence_info(struct fence *fence, void *data, int size)
 {
struct fence_info *info = data;
-   int ret;

if (size < sizeof(*info))
return -ENOMEM;

info->len = sizeof(struct sync_pt_info);

-   if (fence->ops->fill_driver_data) {
-   ret = fence->ops->fill_driver_data(fence, info->driver_data,
-  size - sizeof(*info));
-   if (ret < 0)
-   return ret;
-
-   info->len += ret;
-   }
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index af1af99..d2a1734 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -32,10 +32,6 @@ struct sync_file;
  *   1 if pt has signaled
  *   0 if pt has not signaled
  *  <0 on error
- * @fill_driver_data:  write implementation specific driver data to data.
- *   should return an error if there is not enough room
- *   as specified by size.  This information is returned
- *   to userspace by SYNC_IOC_FENCE_INFO.
  * @timeline_value_str: fill str with the value of the sync_timeline's counter
  * @fence_value_str:   fill str with the value of the fence
  */
@@ -46,9 +42,6 @@ struct sync_timeline_ops {
int (*has_signaled)(struct fence *fence);

/* optional */
-   int (*fill_driver_data)(struct fence *fence, void *data, int size);
-
-   /* optional */
void (*timeline_value_str)(struct sync_timeline *timeline, char *str,
   int size);

diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index 70d05ad..cdc0f04 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -28,12 +28,11 @@ struct sync_merge_da

[PATCH 05/10] staging/android: remove len field from struct fence_info

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

After removing driver_data struct fence_info has now a fixed size,
thus it doesn't need any field to tell its size, it is already known.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 4 +---
 drivers/staging/android/uapi/sync.h | 2 --
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index ced6e61..f7530f0 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -486,8 +486,6 @@ static int sync_fill_fence_info(struct fence *fence, void 
*data, int size)
if (size < sizeof(*info))
return -ENOMEM;

-   info->len = sizeof(struct sync_pt_info);
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -498,7 +496,7 @@ static int sync_fill_fence_info(struct fence *fence, void 
*data, int size)
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);

-   return info->len;
+   return sizeof(*info);
 }

 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index cdc0f04..ed281fc 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -28,14 +28,12 @@ struct sync_merge_data {

 /**
  * struct fence_info - detailed fence information
- * @len:   length of fence_info
  * @obj_name:  name of parent sync_timeline
  * @driver_name:   name of driver implementing the parent
  * @status:status of the fence 0:active 1:signaled <0:error
  * @timestamp_ns:  timestamp of status change in nanoseconds
  */
 struct fence_info {
-   __u32   len;
charobj_name[32];
chardriver_name[32];
__s32   status;
-- 
2.5.0



[PATCH 06/10] staging/android: turn fence_info into a __64 pointer

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

Making fence_info a pointer enables us to extend the struct in the future
without breaking the ABI.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 2 +-
 drivers/staging/android/uapi/sync.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index f7530f0..51d4f47 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -525,7 +525,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (info->status >= 0)
info->status = !info->status;

-   len = sizeof(struct sync_file_info);
+   len = sizeof(struct sync_file_info) - sizeof(__u64 *);

for (i = 0; i < sync_file->num_fences; ++i) {
struct fence *fence = sync_file->cbs[i].fence;
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index ed281fc..9f07aa7 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -54,7 +54,7 @@ struct sync_file_info {
charname[32];
__s32   status;

-   __u8fence_info[0];
+   __u64   *fence_info;
 };

 #define SYNC_IOC_MAGIC '>'
-- 
2.5.0



[PATCH 07/10] staging/android: add num_fences field to struct sync_file_info

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

Inform the users how many fences are in the fence_info field.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 2 ++
 drivers/staging/android/uapi/sync.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 51d4f47..ae42810 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -525,6 +525,8 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (info->status >= 0)
info->status = !info->status;

+   info->num_fences = sync_file->num_fences;
+
len = sizeof(struct sync_file_info) - sizeof(__u64 *);

for (i = 0; i < sync_file->num_fences; ++i) {
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index 9f07aa7..9a607ea 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -47,12 +47,14 @@ struct fence_info {
  * userspace including pt_info.
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
+ * @num_fences number of fences in the sync_file
  * @fence_info:a fence_info struct for every fence in the sync_file
  */
 struct sync_file_info {
__u32   len;
charname[32];
__s32   status;
+   __u32   num_fences;

__u64   *fence_info;
 };
-- 
2.5.0



[PATCH 08/10] staging/android: rename SYNC_IOC_FENCE_INFO

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

We don't use the 'fence' name to refer to sync_file anymore. So rename it
to SYNC_IOC_FILE_INFO.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 2 +-
 drivers/staging/android/uapi/sync.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index ae42810..e1d4fcb 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -562,7 +562,7 @@ static long sync_file_ioctl(struct file *file, unsigned int 
cmd,
case SYNC_IOC_MERGE:
return sync_file_ioctl_merge(sync_file, arg);

-   case SYNC_IOC_FENCE_INFO:
+   case SYNC_IOC_FILE_INFO:
return sync_file_ioctl_fence_info(sync_file, arg);

default:
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index 9a607ea..b00f0eb 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -81,6 +81,6 @@ struct sync_file_info {
  * pt_info is a buffer containing sync_pt_infos for every sync_pt in the fence.
  * To iterate over the sync_pt_infos, use the sync_pt_info.len field.
  */
-#define SYNC_IOC_FENCE_INFO_IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)
+#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)

 #endif /* _UAPI_LINUX_SYNC_H */
-- 
2.5.0



[PATCH 09/10] staging/android: add flags member to sync ioctl structs

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

Play safe and add flags member to all structs. So we don't need to
break API or create new IOCTL in the future if new features that requires
flags arises.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/uapi/sync.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index b00f0eb..45921f6 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -19,11 +19,13 @@
  * @fd2:   file descriptor of second fence
  * @name:  name of new fence
  * @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
  */
 struct sync_merge_data {
__s32   fd2; /* fd of second fence */
charname[32]; /* name of new fence */
__s32   fence; /* fd on newly created fence */
+   __u32   flags;
 };

 /**
@@ -31,12 +33,14 @@ struct sync_merge_data {
  * @obj_name:  name of parent sync_timeline
  * @driver_name:   name of driver implementing the parent
  * @status:status of the fence 0:active 1:signaled <0:error
+ * @flags: fence_info flags
  * @timestamp_ns:  timestamp of status change in nanoseconds
  */
 struct fence_info {
charobj_name[32];
chardriver_name[32];
__s32   status;
+   __u32   flags;
__u64   timestamp_ns;
 };

@@ -47,6 +51,7 @@ struct fence_info {
  * userspace including pt_info.
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
+ * @flags: sync_file_info flags
  * @num_fences number of fences in the sync_file
  * @fence_info:a fence_info struct for every fence in the sync_file
  */
@@ -54,6 +59,7 @@ struct sync_file_info {
__u32   len;
charname[32];
__s32   status;
+   __u32   flags;
__u32   num_fences;

__u64   *fence_info;
-- 
2.5.0



[PATCH 10/10] staging/android: remove redundant comments on sync_merge_data

2016-01-29 Thread Gustavo Padovan
From: Gustavo Padovan 

struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/uapi/sync.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index 45921f6..0e940cb 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -22,9 +22,9 @@
  * @flags: merge_data flags
  */
 struct sync_merge_data {
-   __s32   fd2; /* fd of second fence */
-   charname[32]; /* name of new fence */
-   __s32   fence; /* fd on newly created fence */
+   __s32   fd2;
+   charname[32];
+   __s32   fence;
__u32   flags;
 };

-- 
2.5.0



[PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain

2016-01-29 Thread Rafael J. Wysocki
On Friday, January 29, 2016 06:35:49 PM Andy Shevchenko wrote:
> On Fri, Jan 29, 2016 at 5:51 PM, Andy Shevchenko
>  wrote:
> > On Fri, Jan 29, 2016 at 5:38 PM, Andy Shevchenko
> >  wrote:
> >> On Thu, Jan 7, 2016 at 5:46 PM, Tomeu Vizoso  >> collabora.com> wrote:
> >>> Adds a function that sets the pointer to dev_pm_domain in struct device
> >>> and that warns if the device has already finished probing. The reason
> >>> why we want to enforce that is because in the general case that can
> >>> cause problems and also that we can simplify code quite a bit if we can
> >>> always assume that.
> >>>
> >>> This patch also changes all current code that directly sets the
> >>> dev.pm_domain pointer.
> >>
> >>
> >>> --- a/drivers/acpi/acpi_lpss.c
> >>> +++ b/drivers/acpi/acpi_lpss.c
> >>
> >>> @@ -875,13 +876,14 @@ static int acpi_lpss_platform_notify(struct 
> >>> notifier_block *nb,
> >>>
> >>> switch (action) {
> >>> case BUS_NOTIFY_BIND_DRIVER:
> >>> -   pdev->dev.pm_domain = &acpi_lpss_pm_domain;
> >>> +   dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
> >>> break;
> >>> case BUS_NOTIFY_DRIVER_NOT_BOUND:
> >>> case BUS_NOTIFY_UNBOUND_DRIVER:
> >>> pdev->dev.pm_domain = NULL;
> >>
> >> Missed?
> >>
> >>> break;
> >>> case BUS_NOTIFY_ADD_DEVICE:
> >>> +   dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
> >>> if (pdata->dev_desc->flags & LPSS_LTR)
> >>> return sysfs_create_group(&pdev->dev.kobj,
> >>>   &lpss_attr_group);
> >>> @@ -889,6 +891,7 @@ static int acpi_lpss_platform_notify(struct 
> >>> notifier_block *nb,
> >>> case BUS_NOTIFY_DEL_DEVICE:
> >>> if (pdata->dev_desc->flags & LPSS_LTR)
> >>> sysfs_remove_group(&pdev->dev.kobj, 
> >>> &lpss_attr_group);
> >>> +   dev_pm_domain_set(&pdev->dev, NULL);
> >>> break;
> >>> default:
> >>> break;
> >>
> >> This looks wrong. I didn't test yet, but I have concerns here. Why did
> >> you add those calls?
> >
> >
> > Okay, for first glance it seems working on Intel Braswell.
> 
> One more test unveils this one
> 
> # modprobe -r sdhci-acpi
> [ 1289.909441] [ cut here ]
> [ 1289.918205] WARNING: CPU: 1 PID: 4374 at
> /home/andy/prj/linux-otc/drivers/base/power/common.c:150
> dev_pm_domain_set+0x51/0x60()
> [ 1289.934681] PM domains can only be changed for unbound devices
> [ 1289.944843] Modules linked in: sdhci_acpi(-) sdhci mmc_core
> led_class [last unloaded: dw_dmac_core]
> [ 1289.958802] CPU: 1 PID: 4374 Comm: modprobe Not tainted 4.5.0-rc1+ #3
> [ 1289.969736]  81c38330 88007bb53d18 8133162f
> 88007bb53d60
> [ 1289.981844]  88007bb53d50 8105cd12 88017a007410
> 
> [ 1289.993996]  0001 0080 
> 88007bb53db0
> [ 1290.006123] Call Trace:
> [ 1290.012600]  [] dump_stack+0x44/0x55
> [ 1290.022052]  [] warn_slowpath_common+0x82/0xc0
> [ 1290.032462]  [] warn_slowpath_fmt+0x4c/0x50
> [ 1290.042589]  [] dev_pm_domain_set+0x51/0x60
> [ 1290.052695]  [] acpi_dev_pm_detach+0x3f/0x84
> [ 1290.062910]  [] dev_pm_domain_detach+0x27/0x30
> [ 1290.073294]  [] platform_drv_remove+0x38/0x40
> [ 1290.083585]  [] __device_release_driver+0xa1/0x160
> [ 1290.094335]  [] driver_detach+0xa6/0xb0
> [ 1290.104009]  [] bus_remove_driver+0x55/0xd0
> [ 1290.114053]  [] driver_unregister+0x2c/0x50
> [ 1290.124076]  [] platform_driver_unregister+0x12/0x20
> [ 1290.134957]  [] sdhci_acpi_driver_exit+0x10/0x12
> [sdhci_acpi]
> [ 1290.146730]  [] SyS_delete_module+0x199/0x240
> [ 1290.156907]  [] ? exit_to_usermode_loop+0x8b/0x90
> [ 1290.167478]  [] do_syscall_32_irqs_off+0x53/0xa0
> [ 1290.177949]  [] entry_INT80_compat+0x2a/0x40
> [ 1290.187986] ---[ end trace a8351c0506ee239b ]---
> [ 1290.213855] mmc0: card 0001 removed
> 
> Which function is guilty?

acpi_dev_pm_detach() calls dev_pm_domain_set() to clear the pm_domain pointer.

One might argue that this is happening too early.

Thanks,
Rafael



[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #80 from Thomas DEBESSE  ---
(In reply to Ioannis Panagiotopoulos from comment #78)
> I replaced the firmware file and run update-initramfs -u
> The system still hangs when it starts X-server on boot.
> My gpu is Club3D R9 390

I don't know if it can help upstream, but Alex asked in comment #1 for vbios
dump, perhaps he will need yours too! (he wrote how to do that)

(In reply to Ioannis Panagiotopoulos from comment #79)
> Ok, after further testing, It ends up that it might be a xserver driver
> problem. I downgraded to ver 7.3.0 x-server driver and the system booted
> with dpm enabled, however the Xserver did not have Hardware acceleration.
> Upgrading to the latest (7.6.x), makes the x-server fail to start with
> enabled dpm.

Well, if your Xserver is not able to get DRI working, you probably do not have
the opportunity to trigger the bug. It's something you must fix first. ^_^

To prevent the auto profile to hang up your GPU while you're playing with your
xserver to fix it while dpm is enabled, do something like that, they looks like
safe options for some people like me:

echo 'low' > '/sys/class/drm/card0/device/power_dpm_force_performance_level'
echo 'battery' > '/sys/class/drm/card0/device/power_dpm_state'

After you get your xserver working with direct rendering enabled, try to do:

echo 'auto' > '/sys/class/drm/card0/device/power_dpm_force_performance_level'

and see if it still crashes.

-- 
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/20160129/2499db93/attachment.html>


drm: imx: callback after probe deferral not working

2016-01-29 Thread Akshay Bhat


On 01/28/2016 05:29 PM, Rob Clark wrote:
> can't really say if that is the issue in this case, but these are the
> symptoms you'd see if the kernel was built without some driver that
> imx-drm depends on[1].  The kernel will only try to reprobe a driver
> if some other driver has loaded since it last deferred (otherwise, it
> would be pointless, you'd just -EPROBE_DEFER again).
>
> [1] which is a really annoying thing about devicetree..  there's no
> good way to figure out which drivers need to be enabled in kernel
> config..
>
> BR,
> -R
>

I agree a missing driver would show the symptoms I am seeing. However I 
have verified this is not the case by moving i2c above gpu in the 
makefile and keeping everything else the same. This results in the i2c 
mux driver init (pca9547) being called before the drm init and 
everything works fine in that case (indicates no missing driver).

Also from the original log you can see that there are a lot of modules 
that are loaded after the drm driver does a probe defer, yet there is no 
entries in the bootlog for the drm driver being re-probed. In the 
next-20151202 kernel log you can see it being re-probed. This points to 
the drm probe deferral being broken.

Thanks for your input, any other ideas are welcome.

Log with i2c init before drm (Makefile hack to avoid probe deferral):
dmesg | grep -i 'drm \| pca'
[1.325962] pca954x 0-0070: registered 8 multiplexed busses for I2C 
mux pca9547
[1.379740] pca954x 1-0070: registered 8 multiplexed busses for I2C 
mux pca9547
[1.387465] [drm] Initialized drm 1.1.0 20060810
[1.578625] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops 
ipu_crtc_ops)
[1.586272] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops 
ipu_crtc_ops)
[1.593905] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops 
ipu_crtc_ops)
[1.601509] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops 
ipu_crtc_ops)
[1.618241] imx-drm display-subsystem: bound 12.hdmi (ops 
dw_hdmi_imx_ops)
[1.634754] imx-drm display-subsystem: bound 
200.aips-bus:ldb at 020e0008 (ops imx_ldb_ops)
[1.902172] imx-drm display-subsystem: fb0:  frame buffer device
[1.929283] [drm] Initialized imx-drm 1.0.0 20120507 on minor 1


> On Thu, Jan 28, 2016 at 2:56 PM, Akshay Bhat  
> wrote:
>> Hi,
>>
>> There appears to be a bug in kernel where after a probe deferral by the drm
>> driver, the deferred drm function is never called again at a later point.
>>
>> I have a iMX6 based board where there is pca9547 i2c mux between the display
>> and the mx6 processor. The drm driver tries to get EDID information but the
>> I2C mux pca9547 driver is not yet called, so drm driver does a probe
>> deferral as expected. However the drm function is never called again after
>> the pca9547 driver completes initialization because of which the display
>> remains blank. Things used to work with next-20151202 and I saw it stop
>> working sometime around next-20151223 onwards.
>>
>> If I comment the "ddc-i2c-bus" entry in device tree, then the display works
>> in next-20160128 since the probe deferral does not happen.
>>
>> Has anyone else seen this issue?
>>
>> Logs provided below.
>>
>> Thanks,
>> Akshay
>>
>> Log where things work in next-20151202:
>> dmesg | grep -i 'drm \| pca'
>> [1.597271] [drm] Initialized drm 1.1.0 20060810
>> [1.638434] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops
>> ipu_crtc_ops)
>> [1.646013] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops
>> ipu_crtc_ops)
>> [1.653669] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops
>> ipu_crtc_ops)
>> [1.661276] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops
>> ipu_crtc_ops)
>> [1.669067] imx-drm display-subsystem: failed to bind 12.hdmi (ops
>> dw_hdmi_imx_ops): -517
>> [1.680883] imx-drm display-subsystem: master bind failed: -517
>> [2.460839] pca954x 0-0070: registered 8 multiplexed busses for I2C mux
>> pca9547
>> [2.515638] pca954x 1-0070: registered 8 multiplexed busses for I2C mux
>> pca9547
>> [3.241065] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops
>> ipu_crtc_ops)
>> [3.248565] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops
>> ipu_crtc_ops)
>> [3.256053] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops
>> ipu_crtc_ops)
>> [3.263566] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops
>> ipu_crtc_ops)
>> [3.283249] imx-drm display-subsystem: bound 12.hdmi (ops
>> dw_hdmi_imx_ops)
>> [3.299943] imx-drm display-subsystem: bound
>> 200.aips-bus:ldb at 020e0008 (ops imx_ldb_ops)
>> [3.547620] imx-drm display-subsystem: fb0:  frame buffer device
>> [3.577445] [drm] Initialized imx-drm 1.0.0 20120507 on minor 1
>>
>> Log where things do not work in next-20160128:
>> dmesg | grep -i 'drm \| pca'
>> [1.265837] [drm] Initialized drm 1.1.0 20060810
>> [1.458511] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops
>> ipu_crtc_ops)
>> [1.4

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #81 from Ioannis Panagiotopoulos  ---
Created attachment 121402
  --> https://bugs.freedesktop.org/attachment.cgi?id=121402&action=edit
Club3D R9 390 Vbios

-- 
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/20160129/597f3ff1/attachment.html>


[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

2016-01-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #82 from Ioannis Panagiotopoulos  ---
I used your method, but it worked 2 out of my 5 attempts. To be precise, I
booted on text mode, set the values as you wrote and then startx. On successful
starts, the environment was still slow, despite the Xorg.log stating that
acceleration was on. The successful starts did not last very long however, as
they crashed after 1-2 minutes.

I attached my GPU Vbios.

-- 
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/20160129/ddbd0a6a/attachment.html>