[Bug 95528] BioShock Infinite graphical glitches on radeonsi

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

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

--- Comment #15 from Daniel Scharrer  ---
Created attachment 124722
  --> https://bugs.freedesktop.org/attachment.cgi?id=124722=edit
Trimmed R600_DEBUG=vs,ps output & shader GL calls with LLVM r273782, but with
r266378 reverted

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

[Bug 95528] BioShock Infinite graphical glitches on radeonsi

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

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

--- Comment #14 from Daniel Scharrer  ---
Created attachment 124721
  --> https://bugs.freedesktop.org/attachment.cgi?id=124721=edit
Trimmed R600_DEBUG=vs,ps output & shader GL calls with LLVM r273782

I could not record an apitrace (game hangs before getting to the main menu,
possibly performance related), but I was able to dump the shaders and narrow
down (some of) the affected ones.

The game uses two passes to render the flags and banners: The first pass
(possibly a z prepass?) uses pipeline=20 in the attached logs (vertex
shader=73, program=74; fragment shader=89, program=90).

The second pass is depth-tested against the results of the first, but uses
different shaders - pipeline=105 (vertex shader=383 program=384; fragment
shader=381, program=382).

With LLVM r266378 reverted, the results of the two passes line up, with current
LLVM they do not causing the z-fighting visible in the video linked in the bug
description. Even when disabling the depth test in the second pass, there are
still visible parts of "white" background so this is a) most likely an issue
with one of the vertex shaders and b) not just a depth precision issue. You can
also see this by looking closely at the flags in the video - the while (holes
punched by the z-prepass) and textured parts sway differently.

Since the game compiles an enormous amount of shaders on startup, the full 
R600_DEBUG=cs,vs,tcs,tes,gs,ps output is quite large - I have attached a
trimmed output that only contains the two vertex/fragment shader pairs used for
the banners. The full logs are available at:
 http://constexpr.org/tmp/bioshockinfinite-bad.log (20 MiB)
 http://constexpr.org/tmp/bioshockinfinite-good.log (21 MiB)

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

[Bug 96622] [radeonsi,apitrace] "Dreamfall Chapters: The longest Journey" shows visual corruption

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

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

--- Comment #5 from Nicolai Hähnle  ---
Great to hear that and thank you for following up on here :)

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

[radeon-alex:polaris-test 19/19] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c:1798:4: warning: this decimal constant is unsigned only in ISO C90

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git polaris-test
head:   0812a945fbb814e7946fbe6ddcc81d054c8b6c91
commit: 0812a945fbb814e7946fbe6ddcc81d054c8b6c91 [19/19] drm/amd/powerplay: 
Update CKS on/ CKS off voltage offset calculation
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout 0812a945fbb814e7946fbe6ddcc81d054c8b6c91
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c: In function 
'polaris10_populate_clock_stretcher_data_table':
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c:1798:4: 
>> warning: this decimal constant is unsigned only in ISO C90
   volt_without_cks = (uint32_t)((2753594000 + 
(sclk_table->entries[i].clk/100) * 136418 -(ro - 70) * 100) / \
   ^~~~
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c:1803:4: 
warning: this decimal constant is unsigned only in ISO C90
   volt_without_cks = (uint32_t)((2416794800 + 
(sclk_table->entries[i].clk/100) * 1476925/10 -(ro - 50) * 100) / \
   ^~~~
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c:1805:4: 
warning: this decimal constant is unsigned only in ISO C90
   volt_with_cks = (uint32_t)((2999656000 + sclk_table->entries[i].clk * 
392803/100 - (ro - 44) * 100) / \
   ^

vim +1798 drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c

  1782  min = 1000;
  1783  max = 2300;
  1784  } else {
  1785  min = 1100;
  1786  max = 2100;
  1787  }
  1788  
  1789  ro = efuse * (max -min)/255 + min;
  1790  
  1791  /* Populate Sclk_CKS_masterEn0_7 and Sclk_voltageOffset
  1792   * there is a little difference in calculating
  1793   * volt_with_cks with windows */
  1794  for (i = 0; i < sclk_table->count; i++) {
  1795  data->smc_state_table.Sclk_CKS_masterEn0_7 |=
  1796  sclk_table->entries[i].cks_enable << i;
  1797  if (hwmgr->chip_id == CHIP_POLARIS10) {
> 1798  volt_without_cks = (uint32_t)((2753594000 + 
> (sclk_table->entries[i].clk/100) * 136418 -(ro - 70) * 100) / \
  1799  (2424180 - 
(sclk_table->entries[i].clk/100) * 1132925/1000));
  1800  volt_with_cks = (uint32_t)((279720200 + 
sclk_table->entries[i].clk * 3232 - (ro - 65) * 1) / \
  1801  (252248000 - 
sclk_table->entries[i].clk/100 * 115764));
  1802  } else {
  1803  volt_without_cks = (uint32_t)((2416794800 + 
(sclk_table->entries[i].clk/100) * 1476925/10 -(ro - 50) * 100) / \
  1804  (2625416 - 
(sclk_table->entries[i].clk/100) * 12586807/1));
  1805  volt_with_cks = (uint32_t)((2999656000 + 
sclk_table->entries[i].clk * 392803/100 - (ro - 44) * 100) / \
  1806  (3422454 - 
sclk_table->entries[i].clk/100 * 18886376/1));

---
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: 55035 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160625/a4c91bb2/attachment-0001.obj>

[PATCH 2/2] drm:fsl-dcu: add support for drm bridge

[Stefan Agner]

On 2016-06-24 02:00, Meng Yi wrote:
> The current output code only supports connection to drm panels.
> Add codes to support drm bridge, to supports connection to

I sense to many s here.

Code in the C program code sense is typically an uncountable noun, hence
drop the s.

And "to support connections"


> external connectors.
> 
> Signed-off-by: Meng Yi 
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> index 57a030b..f19e9b1 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -189,6 +189,7 @@ err_cleanup:
>  static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev,
>   const struct of_endpoint *ep)
>  {
> + struct drm_bridge *bridge;
>   struct device_node *np;
>   int ret;
>  
> @@ -200,8 +201,21 @@ static int fsl_dcu_attach_endpoint(struct
> fsl_dcu_drm_device *fsl_dev,
>   ret = fsl_dcu_attach_panel(fsl_dev, fsl_dev->connector.panel);
>   if (ret)
>   return -EPROBE_DEFER;
> + return 0;
>   }
>  
> + bridge = of_drm_find_bridge(np);
> + of_node_put(np);
> + if (!bridge)
> + return -ENODEV;
> +
> + fsl_dev->encoder.bridge = bridge;
> + bridge->encoder = _dev->encoder;
> +
> + ret = drm_bridge_attach(fsl_dev->drm, bridge);
> + if (ret)
> + return -EPROBE_DEFER;

Just return whatever drm_bridge_attach is returning.

--
Stefan

> +
>   return 0;
>  }

[PATCH 1/2] drm:fsl-dcu: rework codes to support of_graph dt binding for panel

[Stefan Agner]

Use "drm/fsl-dcu:" in the subject, that is what we commonly used.

On 2016-06-24 02:00, Meng Yi wrote:
> This patch rework the output code to add of_graph dt binding support
> for panel device and also keeps the backward compatibility
> 
> Signed-off-by: Meng Yi 
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c|  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h |  3 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 76 
> 
>  3 files changed, 57 insertions(+), 24 deletions(-)

I tested the patch with the old and new Syntax on a Colibri module,
seems to work fine. From a 210 lines patchset to a patchset which adds
barley 47 lines net... Nice work!

Please update the binding documentation with the new syntax, and mention
that fsl,panel property is deprecated.

Also add a patch which updates the existing device trees using
port/endpoints.


> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> index c564ec6..b48ffa7 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> @@ -43,7 +43,7 @@ int fsl_dcu_drm_modeset_init(struct
> fsl_dcu_drm_device *fsl_dev)
>   if (ret)
>   goto fail_encoder;
>  
> - ret = fsl_dcu_drm_connector_create(fsl_dev, _dev->encoder);
> + ret = fsl_dcu_create_outputs(fsl_dev);
>   if (ret)
>   goto fail_connector;
>  
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> index 7093109..5a7b88e 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> @@ -25,9 +25,8 @@ to_fsl_dcu_connector(struct drm_connector *con)
>: NULL;
>  }
>  
> -int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
> -  struct drm_encoder *encoder);
>  int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device *fsl_dev,
>  struct drm_crtc *crtc);
> +int fsl_dcu_create_outputs(struct fsl_dcu_drm_device *fsl_dev);
>  
>  #endif /* __FSL_DCU_DRM_CONNECTOR_H__ */
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> index 98c998d..57a030b 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Add that some lines above, where the other linux/ includes are.

>  
>  #include "fsl_dcu_drm_drv.h"
>  #include "fsl_tcon.h"
> @@ -141,15 +142,15 @@ static const struct drm_connector_helper_funcs
> connector_helper_funcs = {
>   .mode_valid = fsl_dcu_drm_connector_mode_valid,
>  };
>  
> -int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
> -  struct drm_encoder *encoder)
> +static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device  *fsl_dev,

There is a superfluous space after fsl_dcu_drm_device.

> + struct drm_panel *panel)
>  {
> + struct drm_encoder *encoder = _dev->encoder;
>   struct drm_connector *connector = _dev->connector.base;
>   struct drm_mode_config *mode_config = _dev->drm->mode_config;
> - struct device_node *panel_node;
>   int ret;
>  
> - fsl_dev->connector.encoder = encoder;
> + fsl_dev->connector.encoder = _dev->encoder;
>  
>   ret = drm_connector_init(fsl_dev->drm, connector,
>_dcu_drm_connector_funcs,
> @@ -170,21 +171,7 @@ int fsl_dcu_drm_connector_create(struct
> fsl_dcu_drm_device *fsl_dev,
> mode_config->dpms_property,
> DRM_MODE_DPMS_OFF);
>  
> - panel_node = of_parse_phandle(fsl_dev->np, "fsl,panel", 0);
> - if (!panel_node) {
> - dev_err(fsl_dev->dev, "fsl,panel property not found\n");
> - ret = -ENODEV;
> - goto err_sysfs;
> - }
> -
> - fsl_dev->connector.panel = of_drm_find_panel(panel_node);
> - if (!fsl_dev->connector.panel) {
> - ret = -EPROBE_DEFER;
> - goto err_panel;
> - }
> - of_node_put(panel_node);
> -
> - ret = drm_panel_attach(fsl_dev->connector.panel, connector);
> + ret = drm_panel_attach(panel, connector);
>   if (ret) {
>   dev_err(fsl_dev->dev, "failed to attach panel\n");
>   goto err_sysfs;
> @@ -192,11 +179,58 @@ int fsl_dcu_drm_connector_create(struct
> fsl_dcu_drm_device *fsl_dev,
>  
>   return 0;
>  
> -err_panel:
> - of_node_put(panel_node);
>  err_sysfs:
>   drm_connector_unregister(connector);
>  err_cleanup:
>   drm_connector_cleanup(connector);
>   return ret;
>  }
> +
> +static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev,
> + const struct of_endpoint *ep)
> +{
> + struct device_node *np;
> + int ret;
> +

[PATCHv16 04/13] cec: add HDMI CEC framework

[Hans Verkuil]

On 06/16/2016 06:00 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 29 Apr 2016 15:52:19 +0200
> Hans Verkuil  escreveu:
> 
>> From: Hans Verkuil 
>>
>> The added HDMI CEC framework provides a generic kernel interface for
>> HDMI CEC devices.
>>
>> Besides the cec module itself it also adds a cec-edid module that
>> contains helper functions to find and manipulate the CEC physical
>> address inside an EDID. Even if the CEC support itself is disabled,
>> drivers will still need these functions.
>>
>> Note that the CEC framework is added to staging/media and that the
>> cec.h and cec-funcs.h headers are not exported yet. While the kABI
>> is mature, I would prefer to allow the uABI some more time before
>> it is mainlined in case it needs more tweaks.
> 
> As pointed via IRC, it sounds like checkpatch were never used
> on this patch series. Just this one got more than 100 errors/warnings:
> 
> total: 6 errors, 107 warnings, 5895 lines checked
> 
> NOTE: For some of the reported defects, checkpatch may be able to
>   mechanically convert to the typical style using --fix or --fix-inplace.
> 
> Please fix, except if you have a good reason why not follow the
> CodingStyle.

When I saw this reply the first time I thought you gave up reviewing at
this point and I missed all the review comments below.

Apologies for that!



>> +static unsigned cec_get_edid_spa_location(const u8 *edid, unsigned size)
>> +{
>> +u8 d;
>> +
>> +if (size < 256)
>> +return 0;
>> +
>> +if (edid[0x7e] != 1 || edid[0x80] != 0x02 || edid[0x81] != 0x03)
>> +return 0;
> 
> Hmm... looking at E-EDID spec:
>   http://read.pudn.com/downloads110/ebook/456020/E-EDID%20Standard.pdf
> 
> you're expecting that EDID will have just *one* extension? If so, please
> state so, adding a FIXME to warn about future needs to change the code
> to support bigger EDID data. Also, in such case, the EDID size should
> always be 256.

I've improved the code to accept more than one extension block. Note that
any device that puts the CEA-861 block in a different position is unlikely
to work. Most HDMI receivers only support one extension block.

> I would also check the checksum, to be sure that the vendor specific
> data block is not pointing to some invalid location.

This should not happen. I think it is safe to assume that the EDID is
correct when this function is called. Invalid EDIDs should be rejected
when they are read.

> 
>> +
>> +/* search Vendor Specific Data Block (tag 3) */
>> +d = edid[0x82] & 0x7f;
>> +if (d > 4) {
>> +int i = 0x84;
>> +int end = 0x80 + d;
>> +
>> +do {
>> +u8 tag = edid[i] >> 5;
>> +u8 len = edid[i] & 0x1f;
>> +
>> +if (tag == 3 && len >= 5)
>> +return i + 4;
>> +i += len + 1;
>> +} while (i < end);
>> +}
> 
> It looked weird that check for size at the beginning, since the size
> is not being used in the routine itself. Ok, after looking at the
> code 3 or 4 times, I understood that you're implicitly using the
> size at the "end" variable, as you're doing a loop between
>   'd', with ranges from 0 to 0x7f
>   'end', with ranges from 0x85 to 0xff.
>   'i', ranging from 0x84 to 0xfe.
>   return value, ranging from 0x88 to 0x102 (i + 4)
> 
> As the code seems to rely on having just one extension, allowing to go
> past 0xff seems a mistake.
> 
> I guess the loop should be checking if it won't return a value
> past of the EDID array.

I've made the code more robust to safeguard against broken EDIDs (intentionally
or not).

> 
>> +return 0;
>> +}
>> +
>> +u16 cec_get_edid_phys_addr(const u8 *edid, unsigned size, unsigned *offset)
>> +{
>> +unsigned loc = cec_get_edid_spa_location(edid, size);
>> +
>> +if (offset)
>> +*offset = loc;
>> +if (loc == 0)
>> +return CEC_PHYS_ADDR_INVALID;
>> +return (edid[loc] << 8) | edid[loc + 1];
> 
> Yeah, if I'm not mistaken, you may be reading past the EDID
> array here, if loc > 0xfe, and size = 256.

With the more robust location code this is now guaranteed to be safe.

> 
>> +}
>> +EXPORT_SYMBOL_GPL(cec_get_edid_phys_addr);
>> +
>> +void cec_set_edid_phys_addr(u8 *edid, unsigned size, u16 phys_addr)
>> +{
>> +unsigned loc = cec_get_edid_spa_location(edid, size);
>> +u8 sum = 0;
>> +unsigned i;
>> +
>> +if (loc == 0)
>> +return;
>> +edid[loc] = phys_addr >> 8;
>> +edid[loc + 1] = phys_addr & 0xff;
>> +loc &= ~0x7f;
>> +
>> +/* update the checksum */
>> +for (i = loc; i < loc + 127; i++)
>> +sum += edid[i];
>> +edid[i] = 256 - sum;
> 
> Here, you can also go past the EDID array, as you're not checking the
> size inside the for loop.

With the more robust location code this is now correct (if loc != 0, then
the size is guaranteed to be a multiple of 128).

> 
>> +}
>> 

[GIT PULL] drm/fsl-dcu: reworked suspend/resume for v4.8

[Stefan Agner]

Hi Dave,

This is the main dcu-fsl pull request for 4.8. It depends on a fix which
is part of 4.7-rc3, hence this is based ontop of v4.7-rc3 (but merges
fine with current drm-next).

The patchset contains a new helper in drm_fb_cma_helper.c for suspend/
resume when using cma backed framebuffers.

The following changes since commit 5edb56491d4812c42175980759da53388e5d86f5:

  Linux 4.7-rc3 (2016-06-12 07:20:35 -0700)

are available in the git repository at:

  http://git.agner.ch/git/linux-drm-fsl-dcu.git for-next

for you to fetch changes up to f5bce4309db6597003e683d28d12b1b4bc9408b0:

  drm/fsl-dcu: disable vblank events on CRTC disable (2016-06-18 18:34:31 -0700)


Stefan Agner (6):
  drm/fb_cma_helper: add suspend helper
  drm/fsl-dcu: store layer registers in soc_data
  drm/fsl-dcu: move layer initialization to plane file
  drm/fsl-dcu: use clk helpers
  drm/fsl-dcu: implement suspend/resume using atomic helpers
  drm/fsl-dcu: disable vblank events on CRTC disable

 drivers/gpu/drm/drm_fb_cma_helper.c | 15 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c  | 21 -
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   | 47 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h   |  2 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 16 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h |  1 +
 include/drm/drm_fb_cma_helper.h |  1 +
 7 files changed, 76 insertions(+), 27 deletions(-)

[PATCH 1/4] ARM: dts: vf610-twr: Enable display controller

[Stefan Agner]

On 2016-06-24 12:44, Anthony Felice wrote:
> This adds nodes to enable tcon0 and dcu0 for the Vybrid Tower. These
> are used to drive the Vybrid Tower TWR-LCD-RGB display. Also, a node
> for the nec nl4827hc19-05b panel on the TWR-LCD-RGB display has been
> added.

So my pixel clock polarity changes which will be part of 4.7 work for
Tower? I could never actually test that since I don't have the display
here...
https://patchwork.kernel.org/patch/8874971/

This patch looks good to me:
Acked-by: Stefan Agner 

--
Stefan

> 
> Signed-off-by: Anthony Felice 
> ---
>  arch/arm/boot/dts/vf610-twr.dts | 48 
> +
>  1 file changed, 48 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
> index cdc1007..ad1aff9 100644
> --- a/arch/arm/boot/dts/vf610-twr.dts
> +++ b/arch/arm/boot/dts/vf610-twr.dts
> @@ -66,6 +66,10 @@
>   clock-frequency = <5000>;
>   };
>  
> + panel: panel {
> + compatible = "nec,nl4827hc19-05b";
> + };
> +
>   regulators {
>   compatible = "simple-bus";
>   #address-cells = <1>;
> @@ -134,6 +138,13 @@
>< VF610_CLK_ENET_EXT>;
>  };
>  
> + {
> + fsl,panel = <>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_dcu0>;
> + status = "okay";
> +};
> +
>   {
>   bus-num = <0>;
>   pinctrl-names = "default";
> @@ -210,6 +221,39 @@
>  
>   {
>   vf610-twr {
> + pinctrl_dcu0: dcu0grp {
> + fsl,pins = <
> + VF610_PAD_PTE0__DCU0_HSYNC  0x42
> + VF610_PAD_PTE1__DCU0_VSYNC  0x42
> + VF610_PAD_PTE2__DCU0_PCLK   0x42
> + VF610_PAD_PTE4__DCU0_DE 0x42
> + VF610_PAD_PTE5__DCU0_R0 0x42
> + VF610_PAD_PTE6__DCU0_R1 0x42
> + VF610_PAD_PTE7__DCU0_R2 0x42
> + VF610_PAD_PTE8__DCU0_R3 0x42
> + VF610_PAD_PTE9__DCU0_R4 0x42
> + VF610_PAD_PTE10__DCU0_R50x42
> + VF610_PAD_PTE11__DCU0_R60x42
> + VF610_PAD_PTE12__DCU0_R70x42
> + VF610_PAD_PTE13__DCU0_G00x42
> + VF610_PAD_PTE14__DCU0_G10x42
> + VF610_PAD_PTE15__DCU0_G20x42
> + VF610_PAD_PTE16__DCU0_G30x42
> + VF610_PAD_PTE17__DCU0_G40x42
> + VF610_PAD_PTE18__DCU0_G50x42
> + VF610_PAD_PTE19__DCU0_G60x42
> + VF610_PAD_PTE20__DCU0_G70x42
> + VF610_PAD_PTE21__DCU0_B00x42
> + VF610_PAD_PTE22__DCU0_B10x42
> + VF610_PAD_PTE23__DCU0_B20x42
> + VF610_PAD_PTE24__DCU0_B30x42
> + VF610_PAD_PTE25__DCU0_B40x42
> + VF610_PAD_PTE26__DCU0_B50x42
> + VF610_PAD_PTE27__DCU0_B60x42
> + VF610_PAD_PTE28__DCU0_B70x42
> + >;
> + };
> +
>   pinctrl_adc0_ad5: adc0ad5grp {
>   fsl,pins = <
>   VF610_PAD_PTC30__ADC0_SE5   0xa1
> @@ -370,6 +414,10 @@
>   status = "okay";
>  };
>  
> + {
> + status = "okay";
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_uart1>;

[PATCH 2/4] input: touchscreen: crtouch_ts: Add driver

[Stefan Agner]

On 2016-06-24 12:44, Anthony Felice wrote:
> Add driver for the Vybrid Tower CRTouch-based touchscreen. This is
> required for the touchscreen on the TWR-LCD-RGB to work on the Vybrid
> Tower platform.
> 
> There is a known issue with this driver: rarely, SW1 on the TWR-LCD-RGB
> module needs to be pressed in order for the touchscreen to begin
> functioning.
> 
> Signed-off-by: Anthony Felice 
> ---
>  .../bindings/input/touchscreen/crtouch_ts.txt  |  14 ++
>  drivers/input/touchscreen/Kconfig  |  10 +
>  drivers/input/touchscreen/Makefile |   1 +
>  drivers/input/touchscreen/crtouch_ts.c | 279 
> +
>  4 files changed, 304 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
>  create mode 100644 drivers/input/touchscreen/crtouch_ts.c
> 
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
> b/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
> new file mode 100644
> index 000..cfb966c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
> @@ -0,0 +1,14 @@
> +* Freescale CRTOUCH based touchscreen
> +
> +Required Properties:
> +- compatible must be fsl,crtouch_ts

Compatible strings usually use a dash instead of underline.


> +- reg: I2C address of the touchscreen
> +- irq-gpio: GPIO to use as event IRQ
> +
> +Example:
> +
> + touch: crtouch at 49 {
> + compatible = "fsl,crtouch_ts";
> + reg = <0x49>;
> + irq-gpio = < 21 GPIO_ACTIVE_HIGH>;
> + };
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 8ecdc38..799e342 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1155,4 +1155,14 @@ config TOUCHSCREEN_ROHM_BU21023
> To compile this driver as a module, choose M here: the
> module will be called bu21023_ts.
>  
> +config TOUCHSCREEN_CRTOUCH
> + tristate "Freescale CRTOUCH based touchscreen"
> + depends on I2C

You probably also need to add OF here.

> + help
> +   Say Y here if you have a CRTOUCH based touchscreen
> +   controller.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called crtouch_ts.
> +
>  endif
> diff --git a/drivers/input/touchscreen/Makefile
> b/drivers/input/touchscreen/Makefile
> index f42975e..8cb0a7a 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -95,3 +95,4 @@ obj-$(CONFIG_TOUCHSCREEN_TPS6507X)  += tps6507x-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50)   += colibri-vf50-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_ROHM_BU21023)   += rohm_bu21023.o
> +obj-$(CONFIG_TOUCHSCREEN_CRTOUCH)+= crtouch_ts.o
> diff --git a/drivers/input/touchscreen/crtouch_ts.c
> b/drivers/input/touchscreen/crtouch_ts.c
> new file mode 100644
> index 000..bb87a8e
> --- /dev/null
> +++ b/drivers/input/touchscreen/crtouch_ts.c
> @@ -0,0 +1,279 @@
> +/*
> + * Driver for Freescale Semiconductor CRTOUCH - A Resistive and Capacitive
> + * touch device with i2c interface
> + *
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Resistive touch sense status registers */
> +#define RES_STA_ERROR0x00
> +#define RES_STA_STATUS1  0x01
> +#define  RES_STA_STATUS2 0x02

Nit: there is a tab between define and RES_STA_STATUS2, all other lines
have spaces.

--
Stefan

[Bug 96588] [regression] [amdgpu] Errors scheduling IBs

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

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

--- Comment #15 from Mike Lothian  ---
The patch already seems to have landed in drm-next-4.8-wip and it does indeed
seem to fix it

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

[drm-intel:for-linux-next 5/22] drivers/gpu/drm/i915/i915_drv.h:3612:48: error: parameter name omitted

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   883445d43e45ddc5ef19274a169a1aa603428ab6
commit: 1dac891c1c95a8528f3558b481fbb9a45d653619 [5/22] drm/i915: Register 
debugfs interface last
config: x86_64-randconfig-s2-06251012 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout 1dac891c1c95a8528f3558b481fbb9a45d653619
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/i915/intel_dp_mst.c:27:0:
   drivers/gpu/drm/i915/i915_drv.h: In function 'i915_debugfs_register':
>> drivers/gpu/drm/i915/i915_drv.h:3612:48: error: parameter name omitted
static inline int i915_debugfs_register(struct drm_i915_private *) {return 
0;}
   ^~~~
   drivers/gpu/drm/i915/i915_drv.h: In function 'i915_debugfs_unregister':
   drivers/gpu/drm/i915/i915_drv.h:3613:51: error: parameter name omitted
static inline void i915_debugfs_unregister(struct drm_i915_private *) {}
  ^~~~

vim +3612 drivers/gpu/drm/i915/i915_drv.h

  3606  #ifdef CONFIG_DEBUG_FS
  3607  int i915_debugfs_register(struct drm_i915_private *dev_priv);
  3608  void i915_debugfs_unregister(struct drm_i915_private *dev_priv);
  3609  int i915_debugfs_connector_add(struct drm_connector *connector);
  3610  void intel_display_crc_init(struct drm_device *dev);
  3611  #else
> 3612  static inline int i915_debugfs_register(struct drm_i915_private *) 
> {return 0;}
  3613  static inline void i915_debugfs_unregister(struct drm_i915_private *) {}
  3614  static inline int i915_debugfs_connector_add(struct drm_connector 
*connector)
  3615  { return 0; }

---
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: 29187 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160625/d58f3edd/attachment-0001.obj>

[PATCH 1/3] drm/vgem: Fix mmaping

[Chris Wilson]

On Thu, Jun 23, 2016 at 03:35:32PM +0100, Chris Wilson wrote:
> The vGEM mmap code has bitrotted slightly and now immediately BUGs.
> Since vGEM was last updated, there are new core GEM facilities to
> provide more common functions, so let's use those here.
> 
> v2: drm_gem_free_mmap_offset() is performed from
> drm_gem_object_release() so we can remove the redundant call.
> 
> Testcase: igt/vgem_basic/mmap
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96603
> Signed-off-by: Chris Wilson 
> Cc: Sean Paul 
> Cc: Zach Reizner 
> Cc: Matthew Auld 
> Tested-by: Humberto Israel Perez Rodriguez  intel.com>
> Reviewed-by: Matthew Auld 

Hi Thierry, Daniel recommended to bug you for stewardship of drm-misc in
his absence. Could you please consider this patch? Our CI is now
tripping over this issue.

Sean or Zach could you please ack? And have a look at the following pair
of dma-buf fence patches? I have tests ready for our CI that use the
vgem dma-buf to demonstrate the lack of synchronisation in i915.ko (and
so exercise the fixes without requiring a second piece of hardware).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 04/25] drm: Restore double clflush on the last partial cacheline

[Chris Wilson]

This effectively reverts

commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
Author: Chris Wilson 
Date:   Wed Jun 10 15:58:01 2015 +0100

drm: Avoid the double clflush on the last cache line in 
drm_clflush_virt_range()

as we have observed issues with serialisation of the clflush operations
on Baytrail+ Atoms with partial updates. Applying the double flush on the
last cacheline forces that clflush to be ordered with respect to the
previous clflush, and the mfence then protects against prefetches crossing
the clflush boundary.

The same issue can be demonstrated in userspace with igt/gem_exec_flush.

Fixes: afcd950cafea6 (drm: Avoid the double clflush on the last cache...)
Testcase: igt/gem_concurrent_blit
Testcase: igt/gem_partial_pread_pwrite
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92845
Signed-off-by: Chris Wilson 
Cc: dri-devel at lists.freedesktop.org
Cc: Akash Goel 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Cc: stable at vger.kernel.org
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/drm_cache.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 059f7c39c582..a7916e5f8864 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -136,6 +136,7 @@ drm_clflush_virt_range(void *addr, unsigned long length)
mb();
for (; addr < end; addr += size)
clflushopt(addr);
+   clflushopt(end - 1); /* force serialisation */
mb();
return;
}
-- 
2.8.1

[PATCH -next] gpu: i915: fix build errors when ACPI is not enabled

[Randy Dunlap]

From: Randy Dunlap 

Fix build errors when ACPI is not enabled by adding function stubs:

../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend':
../drivers/gpu/drm/i915/i915_drv.c:635:2: error: implicit declaration of 
function 'intel_opregion_unregister' [-Werror=implicit-function-declaration]
  intel_opregion_unregister(dev_priv);
../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_resume':
../drivers/gpu/drm/i915/i915_drv.c:798:2: error: implicit declaration of 
function 'intel_opregion_register' [-Werror=implicit-function-declaration]
  intel_opregion_register(dev_priv);

Signed-off-by: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_drv.h |2 ++
 1 file changed, 2 insertions(+)

--- linux-next-20160624.orig/drivers/gpu/drm/i915/i915_drv.h
+++ linux-next-20160624/drivers/gpu/drm/i915/i915_drv.h
@@ -3694,6 +3694,8 @@ extern int intel_opregion_notify_adapter
 extern int intel_opregion_get_panel_type(struct drm_i915_private *dev_priv);
 #else
 static inline int intel_opregion_setup(struct drm_i915_private *dev) { return 
0; }
+static inline void intel_opregion_register(struct drm_i915_private *dev_priv) 
{ }
+static inline void intel_opregion_unregister(struct drm_i915_private 
*dev_priv) { }
 static inline void intel_opregion_init(struct drm_i915_private *dev) { }
 static inline void intel_opregion_fini(struct drm_i915_private *dev) { }
 static inline void intel_opregion_asle_intr(struct drm_i915_private *dev_priv)

[Bug 96672] [radeonsi][LLVM 3.9] ARK: Survival Evolved, Missing text glyphs

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

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

--- Comment #1 from Shawn Starr  ---
Created attachment 124711
  --> https://bugs.freedesktop.org/attachment.cgi?id=124711=edit
Incorrect rendering of text glyph (completely missing)

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

[Bug 96672] [radeonsi][LLVM 3.9] ARK: Survival Evolved, Missing text glyphs

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

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

Bug ID: 96672
   Summary: [radeonsi][LLVM 3.9] ARK: Survival Evolved, Missing
text glyphs
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: shawn.starr at rogers.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 124710
  --> https://bugs.freedesktop.org/attachment.cgi?id=124710=edit
Correct rendering

I've discovered a regression in ARK. It appears our usage of LLVM 3.9 broke ARK
while LLVM 3.8 is fine.

Bisecting mesa from November 19th, I was unable to see any issues using LLVM
3.8, this includes Git mesa master.

Attached is two screenshots using LLVM 3.8/3.9 showing the same scene. The text
is missing in the top and in other places in game where certain text is used.

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

[PATCH 1/2] drm/ttm: fix stupid parameter inversion in the pipeline code

[Alex Deucher]

On Fri, Jun 24, 2016 at 3:51 PM, Christian König
 wrote:
> From: Christian König 
>
> We want to keep the newest fence, not the oldest one.
>
> Signed-off-by: Christian König 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 0c389a5..4da0e78 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -753,7 +753,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
>  */
>
> spin_lock(>move_lock);
> -   if (!from->move || fence_is_later(from->move, fence)) {
> +   if (!from->move || fence_is_later(fence, from->move)) {
> fence_put(from->move);
> from->move = fence_get(fence);
> }
> --
> 2.5.0
>
> ___
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx