Re: [PULL] drm-intel-fixes

[Dave Airlie]

On 20 September 2017 at 15:43, Dave Airlie  wrote:
> On 20 September 2017 at 09:03, Rodrigo Vivi  wrote:
>> Hi Dave,
>
> Hi Rodrigo,
>
> This pull request is generated wrongly, it contains some commits from
> drm-next in it.

Sorry contains some commits from drm-fixes in it.
>
> Please regenerate it, I'm assuming you generated against 4.14-rc1 and
> not against drm-next.

not against drm-fixes :-)

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

Re: [PULL] drm-intel-fixes

[Dave Airlie]

On 20 September 2017 at 09:03, Rodrigo Vivi  wrote:
> Hi Dave,

Hi Rodrigo,

This pull request is generated wrongly, it contains some commits from
drm-next in it.

Please regenerate it, I'm assuming you generated against 4.14-rc1 and
not against drm-next.

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

[radeon-alex:amd-staging-drm-next 1046/1053] drivers/gpu//drm/amd/lib/chash.c:213:51: warning: self-comparison always evaluates to false

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   dcae401d111324489c066aa57ed9c77b97b475f9
commit: 18c073719186a393b41715686cf95175c58919df [1046/1053] drm/amd: Closed 
hash table with low overhead
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 18c073719186a393b41715686cf95175c58919df
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu//drm/amd/lib/chash.c: In function 'chash_iter_relocate':
>> drivers/gpu//drm/amd/lib/chash.c:213:51: warning: self-comparison always 
>> evaluates to false [-Wtautological-compare]
 BUG_ON(src.table->key_size != src.table->key_size);
  ^~
   drivers/gpu//drm/amd/lib/chash.c:214:53: warning: self-comparison always 
evaluates to false [-Wtautological-compare]
 BUG_ON(src.table->value_size != src.table->value_size);
^~

vim +213 drivers/gpu//drm/amd/lib/chash.c

   209  
   210  static void chash_iter_relocate(struct chash_iter dst, struct 
chash_iter src)
   211  {
   212  BUG_ON(src.table == dst.table && src.slot == dst.slot);
 > 213  BUG_ON(src.table->key_size != src.table->key_size);
   214  BUG_ON(src.table->value_size != src.table->value_size);
   215  
   216  if (dst.table->key_size == 4)
   217  dst.table->keys32[dst.slot] = 
src.table->keys32[src.slot];
   218  else
   219  dst.table->keys64[dst.slot] = 
src.table->keys64[src.slot];
   220  
   221  if (dst.table->value_size)
   222  memcpy(chash_iter_value(dst), chash_iter_value(src),
   223 dst.table->value_size);
   224  
   225  chash_iter_set_valid(dst);
   226  chash_iter_set_invalid(src);
   227  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] qxl: fix framebuffer unpinning

[Gabriel Krisman Bertazi]

Gerd Hoffmann  writes:

> On Tue, 2017-09-19 at 11:35 -0300, Gabriel Krisman Bertazi wrote:
>> Gerd Hoffmann  writes:
>> 
>> > qxl_plane_cleanup_fb() unpins the just activated framebuffer
>> > instead of the old one.  Oops.  Fix it.
>> > 
>> > Cc: Gabriel Krisman Bertazi 
>> > Fixes: 1277eed5fecb8830c8cc414ad70c1ef640464bc0
>> > Signed-off-by: Gerd Hoffmann 
>> > ---
>> >  drivers/gpu/drm/qxl/qxl_display.c | 7 ---
>> >  1 file changed, 4 insertions(+), 3 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/qxl/qxl_display.c
>> > b/drivers/gpu/drm/qxl/qxl_display.c
>> > index e1dd05423e..afbf50d0c0 100644
>> > --- a/drivers/gpu/drm/qxl/qxl_display.c
>> > +++ b/drivers/gpu/drm/qxl/qxl_display.c
>> > @@ -702,14 +702,15 @@ static void qxl_plane_cleanup_fb(struct
>> > drm_plane *plane,
>> >    struct drm_gem_object *obj;
>> >    struct qxl_bo *user_bo;
>> >  
>> > -  if (!plane->state->fb) {
>> > -  /* we never executed prepare_fb, so there's
>> > nothing to
>> > +  if (!old_state->fb) {
>> > +  /*
>> > +   * we never executed prepare_fb, so there's
>> > nothing to
>> >     * unpin.
>> >     */
>> >    return;
>> >    }
>> >  
>> > -  obj = to_qxl_framebuffer(plane->state->fb)->obj;
>> > +  obj = to_qxl_framebuffer(old_state->fb)->obj;
>> 
>> I am not sure about this patch.  My idea was to pin/unpin the current
>> buffer on prepare/cleanup, and only keep it pinned during the atomic
>> commit.  This was the goal of 37235451c6990683a8, for instance.
>
> I'm pretty sure the buffer must remain pinned while it is displayed.
>

ok, then it makes sense indeed :)

>> Anyway, if that goal is wrong, I think that, with your change, we
>> forget to
>> unpin the final plane before removing the device.
>
> "removing the device"?  qxl can't be hotplugged ...
> Or do you mean "rmmod qxl"?

rmmod qxl

>
> cheers,
>   Gerd
>

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

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

--- Comment #52 from Shmerl  ---
(In reply to Samuel Pitoiset from comment #51)
> Guys, can you apply the proposed special hacky patch and try to reproduce
> the hang? It should, at least, partially "fix" the issue in the Velen area
> (cf the savegame file).
> 

I applied your hack patch, and here is the output I got (with my other settings
active):

ATTENTION: default value of option mesa_glthread overridden by environment.
*** The Witcher 3 SPECIAL HACK ENABLED ***
Aborted! TFB varyings not correctly set!
source->Id = 250
AL lib: (EE) alc_cleanup: 2 devices not closed

The game indeed aborts, rather than hangs there.

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

Re: [PATCH 2/3] drm/rockchip: Add support for Rockchip Soc RGB output interface

[Sandy Huang]

Hi sean,
Thanks for your review.

在 2017/9/20 7:02, Sean Paul 写道:

On Thu, Sep 14, 2017 at 11:43:23AM +0800, Sandy Huang wrote:

Like rockchip rv1108 crtc can directly output parallel and serial
RGB data to panel or conversion chip, so we add this driver to
probe encoder and connector.

Signed-off-by: Sandy Huang 
---
  drivers/gpu/drm/rockchip/Kconfig|   9 +
  drivers/gpu/drm/rockchip/Makefile   |   1 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
  drivers/gpu/drm/rockchip/rockchip_rgb.c | 327 
  5 files changed, 340 insertions(+)
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0c31f0a..ff1c781 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -8,6 +8,7 @@ config DRM_ROCKCHIP
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+   select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
  Choose this option if you have a Rockchip soc chipset.
@@ -65,4 +66,12 @@ config ROCKCHIP_LVDS
  Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
  support LVDS, rgb, dual LVDS output mode. say Y to enable its
  driver.
+
+config ROCKCHIP_RGB
+   bool "Rockchip RGB support"
+   help
+ Choose this option to enable support for Rockchip RGB output.
+ Like Rockchip rv1108 SoC CRTC can directly output parallel and


The wording here is a little awkward. Perhaps change to:

Some Rockchip CRTCs, like rv1108, can directly output parallel and
...


ok, i will update at next version.


+ serial RGB format to panel or connect to a conversion chip.
+ say Y to enable its driver.
  endif
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a881d2c..f32a17f 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -13,5 +13,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
  rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
+rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
  
  obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 082c251..36e602a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -449,6 +449,8 @@ static int __init rockchip_drm_init(void)
CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
+   ADD_ROCKCHIP_SUB_DRIVER(rockchip_rgb_driver,
+   CONFIG_ROCKCHIP_RGB);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver,
CONFIG_ROCKCHIP_DW_HDMI);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 498dfbc..6b0ec7e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -70,5 +70,6 @@ extern struct platform_driver dw_mipi_dsi_driver;
  extern struct platform_driver inno_hdmi_driver;
  extern struct platform_driver rockchip_dp_driver;
  extern struct platform_driver rockchip_lvds_driver;
+extern struct platform_driver rockchip_rgb_driver;
  extern struct platform_driver vop_platform_driver;
  #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c 
b/drivers/gpu/drm/rockchip/rockchip_rgb.c
new file mode 100644
index 000..0f0e6b464
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Sandy Huang 
+ *
+ * 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 "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_rgb(c) container_of(c, struct rockchip_rgb, connector)
+#define encoder_to_rgb(c) 

Re: [PATCH 1/3] dt-bindings: Add document for rockchip RGB output interface

[Sandy Huang]

在 2017/9/20 9:51, Sandy Huang 写道:

Hi rob,
     thanks for you review.

在 2017/9/19 22:46, Rob Herring 写道:

On Thu, Sep 14, 2017 at 11:43:18AM +0800, Sandy Huang wrote:

This path add support rv1108 rgb output interface driver.

Signed-off-by: Sandy Huang 
---
  .../bindings/display/rockchip/rockchip-rgb.txt | 80 
++

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


diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

new file mode 100644
index 000..4164512
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

@@ -0,0 +1,80 @@
+Rockchip RV1108 RGB interface
+
+
+Required properties:
+- compatible: matching the soc type:
+    - "rockchip,rv1108-rgb";
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this interface.
+
+Required nodes:
+- rockchip,rgb-mode: should be "p888", "p666", "p565", "s888", 
"s888-dummy"


This should be a standard property. Any device with a parallel interface
is going to need something like this.

so, i need to move this property to panel? or just rename 
rockchip,rgb-mode to rgb-mode?



+    - p888: output r8-g8-b8 at each dclk cycle for per-pixel
+    - p666: output r6-g6-b6 at each dclk cycle for per-pixel
+    - p565: output r5-g6-b5 at each dclk cycle for per-pixel
+    - s888: output r8-g8-b8 in three dclk cycle for per-pixel
+    - s888-dmmy: output r8-g8-b8-dummy in four dclk cycle for per-pixel
+
+The rgb has two video ports described by:
+    Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+    Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe 
vopb/vopl/vop

+- video port 1 for either a panel or subsequent encoder
+
+the panel described by:
+    Documentation/devicetree/bindings/display/panel/simple-panel.txt
+Panel other required properties:
+- ports for remote rgb output.
+
+Example:
+
+panel: panel {
+    compatible = "auo,b101ean01";
+    enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
+
+    ports {
+    panel_in_rgb: endpoint {
+    remote-endpoint = <_out_panel>;
+    };
+    };
+};
+
+For Rockchip RV1108:
+
+    rgb: rgb {
+    compatible = "rockchip,rv1108-rgb";
+    pinctrl-names = "lcdc";
+    pinctrl-0 = <_ctl>;
+    rockchip,rgb-mode = "p888";
+
+    ports {
+    #address-cells = <1>;
+    #size-cells = <0>;
+
+    rgb_in: port@0 {
+    reg = <0>;
+    #address-cells = <1>;
+    #size-cells = <0>;
+
+    rgb_in_vop: endpoint@0 {
+    reg = <0>;


Don't need reg for a single endpoint.


ok, this will be deleted at next version.

+    remote-endpoint = <_out_rgb>;
+    };
+    };
+
+    rgb_out: port@1 {
+    reg = <1>;
+    #address-cells = <1>;
+    #size-cells = <0>;
+
+    rgb_out_panel: endpoint@0 {
+    reg = <0>;


ditto.


ok, this will be deleted at next version.
sorry,this can't be deleted, because rgb output remote endpoint maybe 
panel or convert chip, the dts node maybe like this:


panel: panel {
status = "disabled";
ports {
panel_in_rgb: endpoint {
remote-endpoint =  <_out_panel>;
};
};
};

bridge: bridge {
status = "okay";
ports {
bridge_in_rgb: endpoint {
remote-endpoint =  <_out_bridge>;
};
};
};

rgb_out: port@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
rgb_out_panel: endpoint@0 {
 reg = <0>;
remote-endpoint = <_in_rgb>;
};
rgb_out_bridge: endpoint@1 {
 reg = <1>;
remote-endpoint = <_in_rgb>;
};
 };

so rockchip_rgb_bind() @ rockchip_rgb.c use reg id to find the remote 
actived endpoint.


for_each_child_of_node(port, endpoint) {
of_property_read_u32(endpoint, "reg", _id);
	ret = drm_of_find_panel_or_bridge(dev->of_node, 1, endpoint_id, 
>panel, >bridge);

if (!ret)
break;
}


+    remote-endpoint = <_in_rgb>;
+    };
+    };
+    };
+    };
--
2.7.4









___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip


___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

[Joe Perches]

On Wed, 2017-09-20 at 05:46 +0800, Zhenyu Wang wrote:
> On 2017.09.19 16:55:34 +0100, Colin King wrote:
> > From: Colin Ian King 
> > 
> > An earlier fix changed the return type from find_bb_size however the
> > integer return is being assigned to a unsigned int so the -ve error
> > check will never be detected. Make bb_size an int to fix this.
> > 
> > Detected by CoverityScan CID#1456886 ("Unsigned compared against 0")
> > 
> > Fixes: 1e3197d6ad73 ("drm/i915/gvt: Refine error handling for 
> > perform_bb_shadow")
> > Signed-off-by: Colin Ian King 
> > ---
> >  drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
> > b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > index 2c0ccbb817dc..f41cbf664b69 100644
> > --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > @@ -1628,7 +1628,7 @@ static int perform_bb_shadow(struct parser_exec_state 
> > *s)
> > struct intel_shadow_bb_entry *entry_obj;
> > struct intel_vgpu *vgpu = s->vgpu;
> > unsigned long gma = 0;
> > -   uint32_t bb_size;
> > +   int bb_size;
> > void *dst = NULL;
> > int ret = 0;
> >  
> 
> Applied this, thanks!

Is it possible for bb_size to be both >= 2g and valid?

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

Re: [PATCH 1/3] dt-bindings: Add document for rockchip RGB output interface

[Sandy Huang]

Hi rob,
thanks for you review.

在 2017/9/19 22:46, Rob Herring 写道:

On Thu, Sep 14, 2017 at 11:43:18AM +0800, Sandy Huang wrote:

This path add support rv1108 rgb output interface driver.

Signed-off-by: Sandy Huang 
---
  .../bindings/display/rockchip/rockchip-rgb.txt | 80 ++
  1 file changed, 80 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
new file mode 100644
index 000..4164512
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
@@ -0,0 +1,80 @@
+Rockchip RV1108 RGB interface
+
+
+Required properties:
+- compatible: matching the soc type:
+   - "rockchip,rv1108-rgb";
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this interface.
+
+Required nodes:
+- rockchip,rgb-mode: should be "p888", "p666", "p565", "s888", "s888-dummy"


This should be a standard property. Any device with a parallel interface
is going to need something like this.

so, i need to move this property to panel? or just rename 
rockchip,rgb-mode to rgb-mode?



+   - p888: output r8-g8-b8 at each dclk cycle for per-pixel
+   - p666: output r6-g6-b6 at each dclk cycle for per-pixel
+   - p565: output r5-g6-b5 at each dclk cycle for per-pixel
+   - s888: output r8-g8-b8 in three dclk cycle for per-pixel
+   - s888-dmmy: output r8-g8-b8-dummy in four dclk cycle for per-pixel
+
+The rgb has two video ports described by:
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop
+- video port 1 for either a panel or subsequent encoder
+
+the panel described by:
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+Panel other required properties:
+- ports for remote rgb output.
+
+Example:
+
+panel: panel {
+   compatible = "auo,b101ean01";
+   enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
+
+   ports {
+   panel_in_rgb: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+};
+
+For Rockchip RV1108:
+
+   rgb: rgb {
+   compatible = "rockchip,rv1108-rgb";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+   rockchip,rgb-mode = "p888";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in_vop: endpoint@0 {
+   reg = <0>;


Don't need reg for a single endpoint.


ok, this will be deleted at next version.

+   remote-endpoint = <_out_rgb>;
+   };
+   };
+
+   rgb_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_out_panel: endpoint@0 {
+   reg = <0>;


ditto.


ok, this will be deleted at next version.

+   remote-endpoint = <_in_rgb>;
+   };
+   };
+   };
+   };
--
2.7.4








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

[Bug 102885] regression - 17.2 sparkle grid in shadows

[bugzilla-daemon]

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

--- Comment #2 from Thomas J. Moore  ---
(In reply to Samuel Pitoiset from comment #1)
> Can you record a trace with apitrace that reproduces the issue?

I could, I guess.  I've never used the tool before, though, and have no idea
how to trim it to the relevant part.  I can't attach a 179MB trace file (109M
compressed).   I tried trimming to just the relevant region(s), but it's screwy
at best, and mostly garbage in the replay, I doubt it's useful.

> If not, which games are affected? What Wine version? Is CSMT enabled?

I dunno.  I erased my notes after I discovered at least 4 broken games; at that
point, I realized that these problems only started around the later tests,
where Mesa had been auto-updated to 17.2-some rc by my regular system updates,
so I stopped blaming wine and tried reverting Mesa instead.  The only ones I
still remember are KOTOR (because it was worst) and Chains of Satinav.  The
attached picture is from the former; I test the presence of the bug using the
latter, because KOTOR often has (unrelated) trouble starting up.  Note that
neither game shows this problem all the time:  Satinav only shows it in the
cursor when the cursor is over a selectable area, and KOTOR only shows it at
certain viewing angles (I don't really know what the difference is).  Both, and
others that had issues, displayed brief flashes of dot grids at various other
times as well.  I currently use Wine 2.0.2, 2.15, 2.15-staging, and
with/without gallium-d3d9.  I can assure you that I tried all combinations of
the above when I discovered it didn't work normally.  2.0.2 doesn't use csmt by
default, and 2.15 does, so apparently csmt doesn't make a difference.

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

[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave,

Here are drm/i915 the fixes for 4.14-rc1.

Couple fixes for stable:

- Fix MIPI panels on BXT.
- Fix PCI BARs information on GVT.

Plus other fixes:

- Fix minimal brightness for BXT, GLK, CFL and CNL.
- Fix compilation warning: unused in_vbl
- Fix error handling in intel_framebuffer_init

Thanks,
Rodrigo.

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-09-19

for you to fetch changes up to 99df13b6ea811a63eeacb278d05a5b914ce28073:

  drm/i915: Remove unused 'in_vbl' from i915_get_crtc_scanoutpos() (2017-09-18 
15:22:37 -0700)


drm/i915 fixes for 4.14-rc1

Couple fixes for stable:

- Fix MIPI panels on BXT.
- Fix PCI BARs information on GVT.

Plus other fixes:

- Fix minimal brightness for BXT, GLK, CFL and CNL.
- Fix compilation warning: unused in_vbl
- Fix error handling in intel_framebuffer_init


Changbin Du (1):
  drm/i915/gvt: Fix incorrect PCI BARs reporting

Chris Wilson (1):
  drm/i915: Remove unused 'in_vbl' from i915_get_crtc_scanoutpos()

Christophe JAILLET (1):
  drm/i915: Fix an error handling in 'intel_framebuffer_init()'

Dave Airlie (1):
  Merge tag 'drm-amdkfd-next-2017-09-02' of 
git://people.freedesktop.org/~gabbayo/linux into drm-fixes

Himanshu Jha (1):
  drm/amdkfd: remove memset before memcpy

Lee, Shawn C (2):
  drm/i915/bxt: set min brightness from VBT
  drm/i915/cnp: set min brightness from VBT

Mikko Rapeli (1):
  uapi linux/kfd_ioctl.h: only use __u32 and __u64

Oded Gabbay (1):
  drm/amdkfd: pass queue's mqd when destroying mqd

Uma Shankar (1):
  Revert "drm/i915/bxt: Disable device ready before shutdown command"

 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c  |   2 +-
 .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |   1 -
 drivers/gpu/drm/i915/gvt/cfg_space.c   | 113 ++
 drivers/gpu/drm/i915/i915_irq.c|   3 -
 drivers/gpu/drm/i915/intel_display.c   |   2 +-
 drivers/gpu/drm/i915/intel_dsi.c   |  11 --
 drivers/gpu/drm/i915/intel_panel.c |   4 +
 include/uapi/linux/kfd_ioctl.h | 172 ++---
 8 files changed, 140 insertions(+), 168 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/rockchip: vop: Add more RGB output interface type

[Sean Paul]

On Thu, Sep 14, 2017 at 11:43:28AM +0800, Sandy Huang wrote:
> This patch add serial RGB output interface for rockchip vop, the
> more info about serial RGB output interface described at the
> following file:
> 
> Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
> 
> Signed-off-by: Sandy Huang 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 56bbd2e..59a01c3 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -209,6 +209,8 @@ struct vop_data {
>  #define ROCKCHIP_OUT_MODE_P888   0
>  #define ROCKCHIP_OUT_MODE_P666   1
>  #define ROCKCHIP_OUT_MODE_P565   2
> +#define ROCKCHIP_OUT_MODE_S888   8
> +#define ROCKCHIP_OUT_MODE_S888_DUMMY 12
>  /* for use special outface */
>  #define ROCKCHIP_OUT_MODE_   15
>  
> -- 
> 2.7.4
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm/rockchip: Add support for Rockchip Soc RGB output interface

[Sean Paul]

On Thu, Sep 14, 2017 at 11:43:23AM +0800, Sandy Huang wrote:
> Like rockchip rv1108 crtc can directly output parallel and serial
> RGB data to panel or conversion chip, so we add this driver to
> probe encoder and connector.
> 
> Signed-off-by: Sandy Huang 
> ---
>  drivers/gpu/drm/rockchip/Kconfig|   9 +
>  drivers/gpu/drm/rockchip/Makefile   |   1 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
>  drivers/gpu/drm/rockchip/rockchip_rgb.c | 327 
> 
>  5 files changed, 340 insertions(+)
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c
> 
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index 0c31f0a..ff1c781 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -8,6 +8,7 @@ config DRM_ROCKCHIP
>   select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
>   select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
>   select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
> + select DRM_RGB if ROCKCHIP_RGB
>   select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
>   help
> Choose this option if you have a Rockchip soc chipset.
> @@ -65,4 +66,12 @@ config ROCKCHIP_LVDS
> Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
> support LVDS, rgb, dual LVDS output mode. say Y to enable its
> driver.
> +
> +config ROCKCHIP_RGB
> + bool "Rockchip RGB support"
> + help
> +   Choose this option to enable support for Rockchip RGB output.
> +   Like Rockchip rv1108 SoC CRTC can directly output parallel and

The wording here is a little awkward. Perhaps change to:

Some Rockchip CRTCs, like rv1108, can directly output parallel and
...

> +   serial RGB format to panel or connect to a conversion chip.
> +   say Y to enable its driver.
>  endif
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index a881d2c..f32a17f 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -13,5 +13,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
>  
>  obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 082c251..36e602a 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -449,6 +449,8 @@ static int __init rockchip_drm_init(void)
>   CONFIG_ROCKCHIP_LVDS);
>   ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
>   CONFIG_ROCKCHIP_ANALOGIX_DP);
> + ADD_ROCKCHIP_SUB_DRIVER(rockchip_rgb_driver,
> + CONFIG_ROCKCHIP_RGB);
>   ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
>   ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver,
>   CONFIG_ROCKCHIP_DW_HDMI);
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index 498dfbc..6b0ec7e 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -70,5 +70,6 @@ extern struct platform_driver dw_mipi_dsi_driver;
>  extern struct platform_driver inno_hdmi_driver;
>  extern struct platform_driver rockchip_dp_driver;
>  extern struct platform_driver rockchip_lvds_driver;
> +extern struct platform_driver rockchip_rgb_driver;
>  extern struct platform_driver vop_platform_driver;
>  #endif /* _ROCKCHIP_DRM_DRV_H_ */
> diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c 
> b/drivers/gpu/drm/rockchip/rockchip_rgb.c
> new file mode 100644
> index 000..0f0e6b464
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
> @@ -0,0 +1,327 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author:
> + *  Sandy Huang 
> + *
> + * 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 "rockchip_drm_drv.h"
> +#include "rockchip_drm_vop.h"
> +
> +#define connector_to_rgb(c) container_of(c, struct 

[Bug 92248] [KBL/SKL/BYT/BXT/GLK] igt/kms_plane_scaling fail

[bugzilla-daemon]

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

--- Comment #40 from Armando Antonio  ---
The following test cases are failing on CFL with latest configuration

=== 
Test List
===
igt@kms_plane_scaling


==
 Software
==
kernel version  : 4.14.0-rc1-drm-tip-ww38-commit-099f750+
hostname: CFL-CNP
architecture: x86_64
os version  : Ubuntu 16.10
os codename : yakkety
kernel driver   : i915
bios revision   : 95.4
bios release date   : 07/24/2017
ksc : 1.5
hardware acceleration   : disabled
swap partition  : enabled on (/dev/sda3)

==
Graphic drivers
==
grep: /opt/X11R7/var/log/Xorg.0.log: No such file or directory
libdrm  : 2.4.83
cairo   : 1.15.9
intel-gpu-tools (tag)   : intel-gpu-tools-1.19-304-g93f72b2
intel-gpu-tools (commit): 93f72b2

==
 Hardware
==
motherboard model  : CoffeeLakeClientPlatform
motherboard id : CoffeeLakeSUDIMMRVP
form factor: Desktop
manufacturer   : IntelCorporation
cpu family : Other
cpu family id  : 6
cpu information: Genuine Intel(R) CPU  @ 3.60GHz
gpu card   : Intel Corporation Device 3e92 (prog-if 00 [VGA
controller])
memory ram : 15.58 GB
max memory ram : 32 GB
cpu thread : 12
cpu core   : 6
cpu model  : 158
cpu stepping   : 10
socket : Other
hard drive : 111GiB (120GB)
current cd clock frequency : 337500 kHz
maximum cd clock frequency : 675000 kHz
displays connected : eDP-1 DP-1 DP-2

==
 Firmware
==
dmc fw loaded : yes
dmc version   : 1.1
guc fw loaded : SUCCESS
guc version wanted: 9.14
guc version found : 9.14
huc fw loaded : yes

==
 kernel parameters
==
quiet drm.debug=0x1e pci=pcie_bus_safe intel_iommu=igfx_off auto panic=1
nmi_watchdog=panic i915.alpha_support=1 i915.enable_guc_loading=2
i915.enable_guc_submission=2 resume=/dev/sda3 fastboot

==
Output summary
==
(kms_plane_scaling:1967) igt-kms-DEBUG: display: SetPlane A.2, fb 74, src =
(100, 100) 1720x880 dst = (100, 100) 1720x880
(kms_plane_scaling:1967) igt-kms-CRITICAL: Test assertion failure function
igt_drm_plane_commit, file igt_kms.c:2245:
(kms_plane_scaling:1967) igt-kms-CRITICAL: Failed assertion: ret == 0
(kms_plane_scaling:1967) igt-kms-CRITICAL: Last errno: 22, Invalid argument
(kms_plane_scaling:1967) igt-kms-CRITICAL: error: -22 != 0
Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [do_display_commit+0xa9c]
  #2 [+0xa9c]
Test kms_plane_scaling failed.
 DEBUG 

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

[PATCH libdrm] Android: move libraries to /vendor

[Rob Herring]

As part of Treble project in Android O, all the device specific files have
to be located in a separate vendor partition. This is done by setting
LOCAL_PROPRIETARY_MODULE (the name is misleading). This change will not
break existing platforms without a vendor partition as it will just move
files to /system/vendor.

Signed-off-by: Rob Herring 
---
 Android.mk| 1 +
 amdgpu/Android.mk | 3 ++-
 data/Android.mk   | 3 ++-
 etnaviv/Android.mk| 1 +
 freedreno/Android.mk  | 1 +
 intel/Android.mk  | 1 +
 nouveau/Android.mk| 1 +
 radeon/Android.mk | 1 +
 tests/modetest/Android.mk | 1 +
 tests/proptest/Android.mk | 1 +
 10 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/Android.mk b/Android.mk
index 292be2360263..8b2abba89ba1 100644
--- a/Android.mk
+++ b/Android.mk
@@ -49,6 +49,7 @@ include $(BUILD_STATIC_LIBRARY)
 # Shared library for the device
 include $(CLEAR_VARS)
 LOCAL_MODULE := libdrm
+LOCAL_PROPRIETARY_MODULE := true
 
 LOCAL_SRC_FILES := $(LIBDRM_FILES)
 LOCAL_EXPORT_C_INCLUDE_DIRS := \
diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
index 88d376511730..3a897f01c1fa 100644
--- a/amdgpu/Android.mk
+++ b/amdgpu/Android.mk
@@ -5,13 +5,14 @@ include $(CLEAR_VARS)
 include $(LOCAL_PATH)/Makefile.sources
 
 LOCAL_MODULE := libdrm_amdgpu
+LOCAL_PROPRIETARY_MODULE := true
 
 LOCAL_SHARED_LIBRARIES := libdrm
 
 LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
 
 LOCAL_CFLAGS := \
-   -DAMDGPU_ASIC_ID_TABLE=\"/system/etc/hwdata/amdgpu.ids\" \
+   -DAMDGPU_ASIC_ID_TABLE=\"/vendor/etc/hwdata/amdgpu.ids\" \
-DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(shell egrep -ci 
'^[0-9a-f]{4},.*[0-9a-f]+,' $(LIBDRM_TOP)/data/amdgpu.ids)
 
 LOCAL_REQUIRED_MODULES := amdgpu.ids
diff --git a/data/Android.mk b/data/Android.mk
index 3c1fd7c62fb9..62013f0cb46b 100644
--- a/data/Android.mk
+++ b/data/Android.mk
@@ -4,6 +4,7 @@ include $(CLEAR_VARS)
 LOCAL_MODULE := amdgpu.ids
 LOCAL_MODULE_TAGS := optional
 LOCAL_MODULE_CLASS := ETC
-LOCAL_MODULE_PATH := $(TARGET_OUT_ETC)/hwdata
+LOCAL_PROPRIETARY_MODULE := true
+LOCAL_MODULE_RELATIVE_PATH := hwdata
 LOCAL_SRC_FILES := $(LOCAL_MODULE)
 include $(BUILD_PREBUILT)
diff --git a/etnaviv/Android.mk b/etnaviv/Android.mk
index 390f9a98924d..9b32deb833a1 100644
--- a/etnaviv/Android.mk
+++ b/etnaviv/Android.mk
@@ -5,6 +5,7 @@ include $(CLEAR_VARS)
 include $(LOCAL_PATH)/Makefile.sources
 
 LOCAL_MODULE := libdrm_etnaviv
+LOCAL_PROPRIETARY_MODULE := true
 
 LOCAL_SHARED_LIBRARIES := libdrm
 
diff --git a/freedreno/Android.mk b/freedreno/Android.mk
index 2b582aeded74..c31101c9b99b 100644
--- a/freedreno/Android.mk
+++ b/freedreno/Android.mk
@@ -5,6 +5,7 @@ include $(CLEAR_VARS)
 include $(LOCAL_PATH)/Makefile.sources
 
 LOCAL_MODULE := libdrm_freedreno
+LOCAL_PROPRIETARY_MODULE := true
 
 LOCAL_SHARED_LIBRARIES := libdrm
 
diff --git a/intel/Android.mk b/intel/Android.mk
index 5407ff3ed208..457eafe199f2 100644
--- a/intel/Android.mk
+++ b/intel/Android.mk
@@ -28,6 +28,7 @@ include $(CLEAR_VARS)
 include $(LOCAL_PATH)/Makefile.sources
 
 LOCAL_MODULE := libdrm_intel
+LOCAL_PROPRIETARY_MODULE := true
 
 LOCAL_SRC_FILES := $(LIBDRM_INTEL_FILES)
 
diff --git a/nouveau/Android.mk b/nouveau/Android.mk
index b430af4fdd70..f58386fcb976 100644
--- a/nouveau/Android.mk
+++ b/nouveau/Android.mk
@@ -5,6 +5,7 @@ include $(CLEAR_VARS)
 include $(LOCAL_PATH)/Makefile.sources
 
 LOCAL_MODULE := libdrm_nouveau
+LOCAL_PROPRIETARY_MODULE := true
 
 LOCAL_SHARED_LIBRARIES := libdrm
 
diff --git a/radeon/Android.mk b/radeon/Android.mk
index 71040dab79b8..b770728e67c6 100644
--- a/radeon/Android.mk
+++ b/radeon/Android.mk
@@ -5,6 +5,7 @@ include $(CLEAR_VARS)
 include $(LOCAL_PATH)/Makefile.sources
 
 LOCAL_MODULE := libdrm_radeon
+LOCAL_PROPRIETARY_MODULE := true
 
 LOCAL_SHARED_LIBRARIES := libdrm
 
diff --git a/tests/modetest/Android.mk b/tests/modetest/Android.mk
index c1a71fd9702a..80c806afd765 100644
--- a/tests/modetest/Android.mk
+++ b/tests/modetest/Android.mk
@@ -6,6 +6,7 @@ include $(LOCAL_PATH)/Makefile.sources
 LOCAL_SRC_FILES := $(MODETEST_FILES)
 
 LOCAL_MODULE := modetest
+LOCAL_PROPRIETARY_MODULE := true
 
 LOCAL_SHARED_LIBRARIES := libdrm
 LOCAL_STATIC_LIBRARIES := libdrm_util
diff --git a/tests/proptest/Android.mk b/tests/proptest/Android.mk
index 91a590fc9fca..b6e1f5ef1fb5 100644
--- a/tests/proptest/Android.mk
+++ b/tests/proptest/Android.mk
@@ -6,6 +6,7 @@ include $(LOCAL_PATH)/Makefile.sources
 LOCAL_SRC_FILES := $(PROPTEST_FILES)
 
 LOCAL_MODULE := proptest
+LOCAL_PROPRIETARY_MODULE := true
 
 LOCAL_SHARED_LIBRARIES := libdrm
 LOCAL_STATIC_LIBRARIES := libdrm_util
-- 
2.11.0

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

Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

[Zhenyu Wang]

On 2017.09.19 16:55:34 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> An earlier fix changed the return type from find_bb_size however the
> integer return is being assigned to a unsigned int so the -ve error
> check will never be detected. Make bb_size an int to fix this.
> 
> Detected by CoverityScan CID#1456886 ("Unsigned compared against 0")
> 
> Fixes: 1e3197d6ad73 ("drm/i915/gvt: Refine error handling for 
> perform_bb_shadow")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index 2c0ccbb817dc..f41cbf664b69 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -1628,7 +1628,7 @@ static int perform_bb_shadow(struct parser_exec_state 
> *s)
>   struct intel_shadow_bb_entry *entry_obj;
>   struct intel_vgpu *vgpu = s->vgpu;
>   unsigned long gma = 0;
> - uint32_t bb_size;
> + int bb_size;
>   void *dst = NULL;
>   int ret = 0;
>  

Applied this, thanks!

-- 
Open Source Technology Center, Intel ltd.

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


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

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

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

--- Comment #25 from Thomas Hellström  ---
Comment on attachment 134344
  --> https://bugs.freedesktop.org/attachment.cgi?id=134344
Patch to protect the loader_dri3_drawable struct

OK, thanks, that's good to know.

Note the patch isn't complete yet. Just enough to verify what the problem was.

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

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

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

--- Comment #24 from har...@gmx.de ---
I tested your patch (~20 minutes): 

No freezes at all, good work!

I will continue later and meanwhile i'am trying to understand what the meanings
of all that different xx_swap_buffers() functions/callbacks could be :)

Thanks,
Jens

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

[Bug 102885] regression - 17.2 sparkle grid in shadows

[bugzilla-daemon]

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

--- Comment #1 from Samuel Pitoiset  ---
Can you record a trace with apitrace that reproduces the issue?

If not, which games are affected? What Wine version? Is CSMT enabled?

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

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

--- Comment #51 from Samuel Pitoiset  ---
Created attachment 134349
  --> https://bugs.freedesktop.org/attachment.cgi?id=134349=edit
special varying hack

Guys, can you apply the proposed special hacky patch and try to reproduce the
hang? It should, at least, partially "fix" the issue in the Velen area (cf the
savegame file).

To be sure the hack is enabled, please redirect stderr (wine witcher3.exe &>
log) and look for "*** The Witcher 3 SPECIAL HACK ENABLED ***".

If the game exits with "Aborted! TFB varyings not correctly set!", there is
something else, but I wouldn't be surprised as the patch is a huge hack just
used to demonstrate the issue. Please report anyways. Thanks!

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

[Bug 102885] regression - 17.2 sparkle grid in shadows

[bugzilla-daemon]

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

Bug ID: 102885
   Summary: regression - 17.2 sparkle grid in shadows
   Product: Mesa
   Version: 17.2
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: dark...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 134348
  --> https://bugs.freedesktop.org/attachment.cgi?id=134348=edit
Ugly shaded areas

See attached image.  While I was retesting many games in wine, I noticed that
multiple games, when run in wine, show black background with dot grids instead
of alpha blending, apparently.  Reverting to 17.1.x fixed this.  I haven't the
patience or continuous power to my machine to git-bisect; the only thing I can
help with is that it doesn't do this with LIBGL_ALWAYS_SOFTWARE=1, so it's
likely a radeonsi bug rather than mesa core.

Hardware:
Device: AMD Radeon R7 Graphics (AMD CARRIZO / DRM 3.18.0 / 4.13.2-gentoo,
LLVM 5.0.0) (0x9874)
OpenGL renderer string: AMD Radeon R7 Graphics (AMD CARRIZO / DRM 3.18.0 /
4.13.2-gentoo, LLVM 5.0.0)

Note that this has been broken since the earliest rc I tried, also with earlier
releases of the kernel and llvm, firmware from both before and after 06 Sept.

Apologies if this has already been reported; I can't really tell and it has
been broken now for at least all rcs I've tried, 17.2 release, and 17.2.1.

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

Re: [PATCH 4/7] drm/rockchip/dsi: correct phy parameter setting

[Sean Paul]

On Mon, Sep 18, 2017 at 05:05:36PM +0800, Nickey Yang wrote:
> As MIPI PHY document show, icpctrl<3..0> and lpfctrl<5..0>
> should depend on frequency,so fix it.
> 
> Signed-off-by: Nickey Yang 
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 70 
> +++---
>  1 file changed, 40 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 9265b7f..d5250e8 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -228,10 +228,10 @@
>  #define VCO_IN_CAP_CON_HIGH  (0x2 << 1)
>  #define REF_BIAS_CUR_SEL BIT(0)
>  
> -#define CP_CURRENT_3MA   BIT(3)
> +#define CP_CURRENT_SEL(val)  ((val) & 0xf)
>  #define CP_PROGRAM_ENBIT(7)
>  #define LPF_PROGRAM_EN   BIT(6)
> -#define LPF_RESISTORS_20_KOHM0
> +#define LPF_RESISTORS_SEL(val)   ((val) & 0x3f)
>  
>  #define HSFREQRANGE_SEL(val) (((val) & 0x3f) << 1)
>  
> @@ -340,32 +340,44 @@ enum dw_mipi_dsi_mode {
>   DW_MIPI_DSI_VID_MODE,
>  };
>  
> -struct dphy_pll_testdin_map {
> +struct dphy_pll_parameter_map {
>   unsigned int max_mbps;
> - u8 testdin;
> + u8 hsfreqrange;
> + u8 icpctrl;
> + u8 lpfctrl;
>  };
>  
>  /* The table is based on 27MHz DPHY pll reference clock. */
> -static const struct dphy_pll_testdin_map dptdin_map[] = {
> - {  90, 0x00}, { 100, 0x10}, { 110, 0x20}, { 130, 0x01},
> - { 140, 0x11}, { 150, 0x21}, { 170, 0x02}, { 180, 0x12},
> - { 200, 0x22}, { 220, 0x03}, { 240, 0x13}, { 250, 0x23},
> - { 270, 0x04}, { 300, 0x14}, { 330, 0x05}, { 360, 0x15},
> - { 400, 0x25}, { 450, 0x06}, { 500, 0x16}, { 550, 0x07},
> - { 600, 0x17}, { 650, 0x08}, { 700, 0x18}, { 750, 0x09},
> - { 800, 0x19}, { 850, 0x29}, { 900, 0x39}, { 950, 0x0a},
> - {1000, 0x1a}, {1050, 0x2a}, {1100, 0x3a}, {1150, 0x0b},
> - {1200, 0x1b}, {1250, 0x2b}, {1300, 0x3b}, {1350, 0x0c},
> - {1400, 0x1c}, {1450, 0x2c}, {1500, 0x3c}
> +static const struct dphy_pll_parameter_map dppa_map[] = {
> + {  90, 0x00, 0x1 ,0x02}, { 100, 0x10 ,0x1, 0x02},

s/ ,/, /g

Switching icpctrl and lpfctrl values to hardcoded numbers obfuscates the value
they're being set to (ie: 3mA and 20kOhm). Can you please replace the hardcoded
values with #defines describing what the values mean?

> + { 110, 0x20, 0x1, 0x02}, { 130, 0x01, 0x1, 0x01},
> + { 140, 0x11, 0x1, 0x01}, { 150, 0x21, 0x1, 0x01},
> + { 170, 0x02, 0x9, 0x02}, { 180, 0x12, 0x9, 0x02},
> + { 200, 0x22, 0x9, 0x02}, { 220, 0x03, 0x2, 0x02},
> + { 240, 0x13, 0x2, 0x02}, { 250, 0x23, 0x2, 0x02},
> + { 270, 0x04, 0x9, 0x04}, { 300, 0x14, 0x9, 0x04},
> + { 330, 0x05, 0x1, 0x01}, { 360, 0x15, 0x1, 0x01},
> + { 400, 0x25, 0x1, 0x01}, { 450, 0x06, 0x6, 0x04},
> + { 500, 0x16, 0x6, 0x04}, { 550, 0x07, 0x6, 0x08},
> + { 600, 0x17, 0x6, 0x08}, { 650, 0x08, 0x6, 0x04},
> + { 700, 0x18, 0x6, 0x04}, { 750, 0x09, 0x6, 0x04},
> + { 800, 0x19, 0x6, 0x04}, { 850, 0x29, 0x6, 0x04},
> + { 900, 0x39, 0x6, 0x04}, { 950, 0x0a, 0xb, 0x10},
> + {1000, 0x1a, 0xb, 0x10}, {1050, 0x2a, 0xb, 0x10},
> + {1100, 0x3a, 0xb, 0x10}, {1150, 0x0b, 0xb, 0x08},
> + {1200, 0x1b, 0xb, 0x08}, {1250, 0x2b, 0xb, 0x08},
> + {1300, 0x3b, 0xb, 0x08}, {1350, 0x0c, 0xb, 0x08},
> + {1400, 0x1c, 0xb, 0x08}, {1450, 0x2c, 0xb, 0x08},
> + {1500, 0x3c, 0xb, 0x08}
>  };
>  
> -static int max_mbps_to_testdin(unsigned int max_mbps)
> +static int max_mbps_to_parameter(unsigned int max_mbps)
>  {
>   int i;
>  
> - for (i = 0; i < ARRAY_SIZE(dptdin_map); i++)
> - if (dptdin_map[i].max_mbps > max_mbps)
> - return dptdin_map[i].testdin;
> + for (i = 0; i < ARRAY_SIZE(dppa_map); i++)
> + if (dppa_map[i].max_mbps > max_mbps)
> + return i;
>  
>   return -EINVAL;
>  }
> @@ -447,16 +459,16 @@ static inline unsigned int ns2ui(struct dw_mipi_dsi 
> *dsi, int ns)
>  
>  static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>  {
> - int ret, testdin, vco, val;
> + int ret, i, vco, val;
>  
>   vco = (dsi->lane_mbps < 200) ? 0 : (dsi->lane_mbps + 100) / 200;
>  
> - testdin = max_mbps_to_testdin(dsi->lane_mbps);
> - if (testdin < 0) {
> + i = max_mbps_to_parameter(dsi->lane_mbps);
> + if (i < 0) {
>   dev_err(dsi->dev,
> - "failed to get testdin for %dmbps lane clock\n",
> + "failed to get parameter for %dmbps lane clock\n",
>   dsi->lane_mbps);
> - return testdin;
> + return i;
>   }
>  
>   /* Start by clearing PHY state */
> @@ -475,12 +487,10 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>VCO_IN_CAP_CON_LOW |
>REF_BIAS_CUR_SEL);
>  
> - 

Re: [PATCH 1/7] drm/rockchip/dsi: correct Feedback divider setting

[Sean Paul]

On Tue, Sep 19, 2017 at 11:19:01AM -0700, Brian Norris wrote:
> Hi Sean,
> 
> On Tue, Sep 19, 2017 at 11:00:25AM -0700, Sean Paul wrote:
> > On Mon, Sep 18, 2017 at 05:05:33PM +0800, Nickey Yang wrote:
> > > This patch correct Feedback divider setting:
> > > 1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
> > > 2、Due to the use of a "by 2 pre-scaler," the range of the
> > > feedback multiplication Feedback divider is limited to even
> > > division numbers, and Feedback divider must be greater than
> > > 12, less than 1000.
> > > 3、Make the previously configured Feedback divider(LSB)
> > > factors effective
> > > 
> > > Signed-off-by: Nickey Yang 
> > > ---
> > >  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 83 
> > > ++
> > >  1 file changed, 54 insertions(+), 29 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> > > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > > index 9a20b9d..52698b7 100644
> > > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > > @@ -228,7 +228,7 @@
> > >  #define LOW_PROGRAM_EN   0
> > >  #define HIGH_PROGRAM_EN  BIT(7)
> > >  #define LOOP_DIV_LOW_SEL(val)(((val) - 1) & 0x1f)
> > > -#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0x1f)
> > > +#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0xf)
> > >  #define PLL_LOOP_DIV_EN  BIT(5)
> > >  #define PLL_INPUT_DIV_EN BIT(4)
> > >  
> > > @@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi 
> > > *dsi)
> > >   dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
> > >   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_LOW_SEL(dsi->feedback_div) |
> > >LOW_PROGRAM_EN);
> > > + dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
> > 
> > You do the same write 2 lines down. Are both needed? It would be nice if the
> > register names were also defined, so this is easier to read.
> 
> If I'm reading correctly, I think this is what Nickey meant by:
> 
> "3、Make the previously configured Feedback divider(LSB)
> factors effective"
> 
> . My reading of the databook is that this step finalizes the previous
> two writes (to test code 0x17 and 0x18).
> 
> Given this was buggy (?) previously, it does seem like having some extra
> language to document this could help. Register names (or "test codes",
> per the docs?) could help, but additionally, maybe a few more comments.
> 

Ah, yeah, thanks for the explanation. It's not clear that this latches the 
values above. I think register names and comments would be immensely helpful.

Sean

> > >   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
> > >HIGH_PROGRAM_EN);
> > >   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
> 
> [...]
> 
> Brian

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/7] drm/rockchip/dsi: add dual mipi channel support

[Sean Paul]

On Mon, Sep 18, 2017 at 05:05:34PM +0800, Nickey Yang wrote:

Hi Nickey,
You're adding a substantial new feature to the driver. You should add a commit
message that describes what you're adding, why you're adding it, and how it is
done.

> Signed-off-by: Nickey Yang 
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 353 
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   2 +
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   3 +
>  4 files changed, 257 insertions(+), 102 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 52698b7..9265b7f 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -42,6 +42,17 @@
>  #define RK3399_GRF_SOC_CON22 0x6258
>  #define RK3399_GRF_DSI_MODE  0x
>  
> +/* disable turndisable, forcetxstopmode, forcerxmode, enable */
> +#define RK3399_GRF_SOC_CON23 0x625c
> +#define RK3399_GRF_DSI1_MODE10x
> +#define RK3399_GRF_DSI1_ENABLE   0x000f000f

Please break these out into separate defines so we know which bit is
responsible for turning on/off each feature.

> +/* disable basedir and enable clk*/
> +#define RK3399_GRF_SOC_CON24 0x6260
> +#define RK3399_TXRX_MASTERSLAVEZ BIT(7)
> +#define RK3399_TXRX_ENABLECLKBIT(6)
> +#define RK3399_TXRX_BASEDIR  BIT(5)
> +#define RK3399_GRF_DSI1_MODE20x00e00080

Same comment here.

> +
>  #define DSI_VERSION  0x00
>  #define DSI_PWR_UP   0x04
>  #define RESET0
> @@ -282,6 +293,12 @@ struct dw_mipi_dsi_plat_data {
>   u32 grf_switch_reg;
>   u32 grf_dsi0_mode;
>   u32 grf_dsi0_mode_reg;
> + u32 grf_dsi1_mode;
> + u32 grf_dsi1_mode_reg1;
> + u32 dsi1_basedir;
> + u32 dsi1_masterslavez;
> + u32 dsi1_enableclk;
> + u32 grf_dsi1_mode_reg2;
>   unsigned int flags;
>   unsigned int max_data_lanes;
>  };
> @@ -300,6 +317,12 @@ struct dw_mipi_dsi {
>   struct clk *pclk;
>   struct clk *phy_cfg_clk;
>  
> + /* dual-channel */
> + struct dw_mipi_dsi *master;
> + struct dw_mipi_dsi *slave;
> + struct device_node *panel_node;
> + int id;
> +
>   int dpms_mode;
>   unsigned int lane_mbps; /* per lane */
>   u32 channel;
> @@ -526,6 +549,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
> *dsi,
>   unsigned int target_mbps = 1000;
>   unsigned int max_mbps = dptdin_map[ARRAY_SIZE(dptdin_map) - 1].max_mbps;
>   int bpp;
> + int lanes = dsi->lanes;
>   unsigned long best_freq = 0;
>   unsigned long fvco_min, fvco_max, fin ,fout;
>   unsigned int min_prediv, max_prediv;
> @@ -540,10 +564,13 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
> *dsi,
>   return bpp;
>   }
>  
> + if (dsi->slave || dsi->master)
> + lanes = dsi->lanes * 2;
> +
>   mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
>   if (mpclk) {
>   /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
> - tmp = mpclk * (bpp / dsi->lanes) * 10 / 8;
> + tmp = mpclk * (bpp / lanes) * 10 / 8;
>   if (tmp < max_mbps)
>   target_mbps = tmp;
>   else
> @@ -605,17 +632,26 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host 
> *host,
>  struct mipi_dsi_device *device)
>  {
>   struct dw_mipi_dsi *dsi = host_to_dsi(host);
> + int lanes = dsi->slave ? device->lanes / 2 : device->lanes;
>  
> - if (device->lanes > dsi->pdata->max_data_lanes) {
> + if (lanes > dsi->pdata->max_data_lanes) {
>   dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
> - device->lanes);
> + lanes);
>   return -EINVAL;
>   }
>  
> - dsi->lanes = device->lanes;
> + dsi->lanes = lanes;
>   dsi->channel = device->channel;
>   dsi->format = device->format;
>   dsi->mode_flags = device->mode_flags;
> +
> + if (dsi->slave) {
> + dsi->slave->lanes = lanes;
> + dsi->slave->channel = device->channel;
> + dsi->slave->format = device->format;
> + dsi->slave->mode_flags = device->mode_flags;
> + }
> +
>   dsi->panel = of_drm_find_panel(device->dev.of_node);
>   if (dsi->panel)
>   return drm_panel_attach(dsi->panel, >connector);
> @@ -745,15 +781,22 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
> mipi_dsi_host *host,
>   int ret;
>  
>   dw_mipi_message_config(dsi, msg);
> + if (dsi->slave)
> + dw_mipi_message_config(dsi->slave, msg);
>  
>   switch (msg->type) {
>   case MIPI_DSI_DCS_SHORT_WRITE:
>   case 

[Bug 102809] Rust shadows(?) flash random colours

[bugzilla-daemon]

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

--- Comment #6 from Grazvydas Ignotas  ---
There is no 'flashing' on rx470 either on mesa git + llvm r311849 (~month old).

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

Re: [PATCH 1/7] drm/rockchip/dsi: correct Feedback divider setting

[Brian Norris]

Hi Sean,

On Tue, Sep 19, 2017 at 11:00:25AM -0700, Sean Paul wrote:
> On Mon, Sep 18, 2017 at 05:05:33PM +0800, Nickey Yang wrote:
> > This patch correct Feedback divider setting:
> > 1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
> > 2、Due to the use of a "by 2 pre-scaler," the range of the
> > feedback multiplication Feedback divider is limited to even
> > division numbers, and Feedback divider must be greater than
> > 12, less than 1000.
> > 3、Make the previously configured Feedback divider(LSB)
> > factors effective
> > 
> > Signed-off-by: Nickey Yang 
> > ---
> >  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 83 
> > ++
> >  1 file changed, 54 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > index 9a20b9d..52698b7 100644
> > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > @@ -228,7 +228,7 @@
> >  #define LOW_PROGRAM_EN 0
> >  #define HIGH_PROGRAM_ENBIT(7)
> >  #define LOOP_DIV_LOW_SEL(val)  (((val) - 1) & 0x1f)
> > -#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
> > +#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0xf)
> >  #define PLL_LOOP_DIV_ENBIT(5)
> >  #define PLL_INPUT_DIV_EN   BIT(4)
> >  
> > @@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
> > dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
> > dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_LOW_SEL(dsi->feedback_div) |
> >  LOW_PROGRAM_EN);
> > +   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
> 
> You do the same write 2 lines down. Are both needed? It would be nice if the
> register names were also defined, so this is easier to read.

If I'm reading correctly, I think this is what Nickey meant by:

"3、Make the previously configured Feedback divider(LSB)
factors effective"

. My reading of the databook is that this step finalizes the previous
two writes (to test code 0x17 and 0x18).

Given this was buggy (?) previously, it does seem like having some extra
language to document this could help. Register names (or "test codes",
per the docs?) could help, but additionally, maybe a few more comments.

> > dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
> >  HIGH_PROGRAM_EN);
> > dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);

[...]

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

Re: [PATCH 1/7] drm/rockchip/dsi: correct Feedback divider setting

[Sean Paul]

On Mon, Sep 18, 2017 at 05:05:33PM +0800, Nickey Yang wrote:
> This patch correct Feedback divider setting:
> 1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
> 2、Due to the use of a "by 2 pre-scaler," the range of the
> feedback multiplication Feedback divider is limited to even
> division numbers, and Feedback divider must be greater than
> 12, less than 1000.
> 3、Make the previously configured Feedback divider(LSB)
> factors effective
> 
> Signed-off-by: Nickey Yang 
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 83 
> ++
>  1 file changed, 54 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 9a20b9d..52698b7 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -228,7 +228,7 @@
>  #define LOW_PROGRAM_EN   0
>  #define HIGH_PROGRAM_EN  BIT(7)
>  #define LOOP_DIV_LOW_SEL(val)(((val) - 1) & 0x1f)
> -#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0x1f)
> +#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0xf)
>  #define PLL_LOOP_DIV_EN  BIT(5)
>  #define PLL_INPUT_DIV_EN BIT(4)
>  
> @@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
>   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_LOW_SEL(dsi->feedback_div) |
>LOW_PROGRAM_EN);
> + dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);

You do the same write 2 lines down. Are both needed? It would be nice if the
register names were also defined, so this is easier to read.

>   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
>HIGH_PROGRAM_EN);
>   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
> @@ -521,11 +522,16 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>  static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
>   struct drm_display_mode *mode)
>  {
> - unsigned int i, pre;
> - unsigned long mpclk, pllref, tmp;
> - unsigned int m = 1, n = 1, target_mbps = 1000;
> + unsigned long mpclk, tmp;
> + unsigned int target_mbps = 1000;
>   unsigned int max_mbps = dptdin_map[ARRAY_SIZE(dptdin_map) - 1].max_mbps;
>   int bpp;
> + unsigned long best_freq = 0;
> + unsigned long fvco_min, fvco_max, fin ,fout;
> + unsigned int min_prediv, max_prediv;
> + unsigned int _prediv, uninitialized_var(best_prediv);
> + unsigned long _fbdiv, uninitialized_var(best_fbdiv);
> + unsigned long min_delta = UINT_MAX;

Once you explicitly type these, make sure you use the appropriate _MAX value
(ie: U64_MAX)

>  
>   bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
>   if (bpp < 0) {
> @@ -544,34 +550,53 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
> *dsi,
>   dev_err(dsi->dev, "DPHY clock frequency is out of 
> range\n");
>   }
>  
> - pllref = DIV_ROUND_UP(clk_get_rate(dsi->pllref_clk), USEC_PER_SEC);
> - tmp = pllref;
> -
> - /*
> -  * The limits on the PLL divisor are:
> -  *
> -  *  5MHz <= (pllref / n) <= 40MHz
> -  *
> -  * we walk over these values in descreasing order so that if we hit
> -  * an exact match for target_mbps it is more likely that "m" will be
> -  * even.
> -  *
> -  * TODO: ensure that "m" is even after this loop.
> -  */
> - for (i = pllref / 5; i > (pllref / 40); i--) {
> - pre = pllref / i;
> - if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) {
> - tmp = target_mbps % pre;
> - n = i;
> - m = target_mbps / pre;
> + fin = clk_get_rate(dsi->pllref_clk);
> + fout = target_mbps * USEC_PER_SEC;
> +
> + /* constraint: 5Mhz < Fref / N < 40MHz */
> + min_prediv = DIV_ROUND_UP(fin, 40 * USEC_PER_SEC);
> + max_prediv = fin / (5 * USEC_PER_SEC);
> +
> + /* constraint: 80MHz < Fvco < 1500Mhz */
> + fvco_min = 80 * USEC_PER_SEC;
> + fvco_max = 1500 * USEC_PER_SEC;
> +
> + for (_prediv = min_prediv; _prediv <= max_prediv; _prediv++) {
> + u32 delta;
> + /* Fvco = Fref * M / N */
> + tmp = fout * _prediv;
> + do_div(tmp, fin);
> + _fbdiv = tmp;

Why use tmp at all? Can't you just use _fbdiv directly in do_div?

> + /*
> +  * Due to the use of a "by 2 pre-scaler," the range of the
> +  * feedback multiplication value M is limited to even division
> +  * numbers, and m must be greater than 12, less than 1000.
> +  */
> + if (_fbdiv < 12 || _fbdiv > 1000)
> + 

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

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

Thomas Hellström  changed:

   What|Removed |Added

 Attachment #133776|0   |1
is obsolete||

--- Comment #23 from Thomas Hellström  ---
Created attachment 134344
  --> https://bugs.freedesktop.org/attachment.cgi?id=134344=edit
Patch to protect the loader_dri3_drawable struct

So here is a patch that doesn't fully make dri3 drawables thread-safe, but it
should at least make sure threads don't steal events from eachother.

Please try,
Thomas

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

Re: [PATCH 5/5] ARM: dts: exynos: Add status property to Exynos 54xx Mixer nodes

[Krzysztof Kozlowski]

On Fri, Sep 15, 2017 at 11:11:23AM +0200, Marek Szyprowski wrote:
> HDMI support requires some additional off-SoC logic, so Mixer device (part
> of HDMI display path) should be disabled by default in SoC dtsi and enabled
> then in each board dts. This patch unifies Mixer handling with other
> Exynos SoCs.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts  | 4 
>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  | 4 
>  arch/arm/boot/dts/exynos5420.dtsi  | 1 +
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4 
>  5 files changed, 17 insertions(+)
> 

Thanks, applied.

Best regards,
Krzysztof

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

Re: [PATCH 4/5] ARM: dts: exynos: Add status property to Exynos 5250 HDMI and Mixer nodes

[Krzysztof Kozlowski]

On Fri, Sep 15, 2017 at 11:11:22AM +0200, Marek Szyprowski wrote:
> HDMI support requires some additional off-SoC logic, so HDMI and Mixer
> devices should be disabled by default in  SoC dtsi and enabled then
> in each board dts. This patch unifies HDMI and Mixer handling with other
> Exynos SoCs.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts  | 5 +
>  arch/arm/boot/dts/exynos5250-smdk5250.dts | 5 +
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 5 +
>  arch/arm/boot/dts/exynos5250-spring.dts   | 5 +
>  arch/arm/boot/dts/exynos5250.dtsi | 4 +++-
>  5 files changed, 23 insertions(+), 1 deletion(-)
> 

Thanks, applied.

Best regards,
Krzysztof

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

Re: [PATCH 3/5] ARM: dts: exynos: Cleanup HDMI DCC definitions

[Krzysztof Kozlowski]

On Fri, Sep 15, 2017 at 11:11:21AM +0200, Marek Szyprowski wrote:
> Commit 2b7681326dc2 ("drm/exynos: hdmi: remove the i2c drivers and use")
> merged to v3.15 kernel added a required 'ddc' property to Exynos HDMI
> device tree bindings, which should point to i2c bus used for handling DDC
> (mainly reading display's EDID information). It has been enough time to
> convert all boards to use new bindings, but sadly due to copy/paste design
> the old approach using separate node with 'samsung,exynos4210-hdmiddc'
> compatible was used also for many new boards. This patch finally converts
> all boards to the new approach and unifies HDMI DDC definition across all
> Exynos boards.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts   | 9 ++---
>  arch/arm/boot/dts/exynos5250-smdk5250.dts  | 7 ++-
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi  | 6 +-
>  arch/arm/boot/dts/exynos5250-spring.dts| 6 +-
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  | 7 ++-
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>  6 files changed, 10 insertions(+), 32 deletions(-)
> 

Thanks, applied.

Best regards,
Krzysztof

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

Re: [PATCH 2/5] ARM: dts: exynos: Move HDMI PHY node to exynos5250.dtsi

[Krzysztof Kozlowski]

On Fri, Sep 15, 2017 at 11:11:20AM +0200, Marek Szyprowski wrote:
> All Exynos 5250 SoCs have HDMI PHY connected via dedicated I2C bus (bus
> number 8), so HDMI PHY should be defined in exynos5250.dtsi instead of
> duplicating it in every board, which enable HDMI support.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts  | 8 +---
>  arch/arm/boot/dts/exynos5250-smdk5250.dts | 6 +-
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 7 +--
>  arch/arm/boot/dts/exynos5250-spring.dts   | 7 +--
>  arch/arm/boot/dts/exynos5250.dtsi | 6 ++
>  5 files changed, 10 insertions(+), 24 deletions(-)
> 

Thanks, applied.

Best regards,
Krzysztof

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

[Bug 102814] Blender 2.79 flickering

[bugzilla-daemon]

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

--- Comment #7 from Luke A. Guest  ---
(In reply to freedesktop from comment #5)
> It can't be old because Blender 2.79 is brand-new (released last week) and
> Blender 2.78 didn't suffer from this issue.

It is and it did. I had to turn it on for 2.78 and then turn it back on for
2.79 because it decided to overwrite the settings. e.g. from 2016
https://developer.blender.org/T49537

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

Re: [PATCH 1/5] dt-bindings: Explicitely mark Exynos HDMI DDC node as deprecated

[Krzysztof Kozlowski]

On Fri, Sep 15, 2017 at 11:11:19AM +0200, Marek Szyprowski wrote:
> Commit 2b7681326dc2 ("drm/exynos: hdmi: remove the i2c drivers and use")
> merged to v3.15 kernel added a required 'ddc' property to Exynos HDMI
> device tree bindings, which should point to i2c bus used for handling DDC
> (mainly reading display's EDID information). Since that commit
> separate node with "samsung,exynos4210-hdmiddc" compatible is no longer
> needed, so mark it finally as deprecated.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 

Acked-by: Krzysztof Kozlowski 
(I guess this patch will go through DRM or media, but let me know if I
should take it)

Best regards,
Krzysztof

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

Re: [PATCH v4 2/4] ARM: dts: exynos: Add clean name of compatible.

[Krzysztof Kozlowski]

On Wed, Sep 13, 2017 at 08:41:53PM +0900, Hoegeun Kwon wrote:
> Exynos 5250 and 5420 have different hardware rotation limits. However,
> currently it uses only one compatible - "exynos5-gsc". Since we have
> to distinguish between these two, we add different compatible.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
>  arch/arm/boot/dts/exynos5250.dtsi | 8 
>  arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 

Thanks, applied with modified subject.

Best regards,
Krzysztof

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

[Bug 102796] steam not rendering correctly on VEGA 56

[bugzilla-daemon]

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

--- Comment #3 from Tom Englund  ---
its fixed with one of the components today.

OpenGL renderer string: AMD VEGA10 (DRM 3.20.0 / 4.12.0-1-amdgpu-zen-4.12, LLVM
6.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.0-devel
(git-7343d27136)

its rendering correctly now.

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

[PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

[Colin King]

From: Colin Ian King 

An earlier fix changed the return type from find_bb_size however the
integer return is being assigned to a unsigned int so the -ve error
check will never be detected. Make bb_size an int to fix this.

Detected by CoverityScan CID#1456886 ("Unsigned compared against 0")

Fixes: 1e3197d6ad73 ("drm/i915/gvt: Refine error handling for 
perform_bb_shadow")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 2c0ccbb817dc..f41cbf664b69 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1628,7 +1628,7 @@ static int perform_bb_shadow(struct parser_exec_state *s)
struct intel_shadow_bb_entry *entry_obj;
struct intel_vgpu *vgpu = s->vgpu;
unsigned long gma = 0;
-   uint32_t bb_size;
+   int bb_size;
void *dst = NULL;
int ret = 0;
 
-- 
2.14.1

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

Re: [radeon-alex:amd-staging-drm-next 1046/1053] drivers/gpu//drm/amd/lib/../include/linux/chash.h:286:50: error: '_BITOPS_LONG_SHIFT' undeclared

[Felix Kuehling]

_BITOPS_LONG_SHIFT seems to be x86-specific. I'll get rid of it.

I'm also looking into a separate problem with 64-bit divisions. I've
reproduced that with a 32-bit build. As I understand it, u64 / u64
should be OK, but for some reason it's doing a signed division
somewhere. I'm trying to track that down. It's somewhere in the hash
table statistics code. A build that disables statistics doesn't have a
problem.

Regards,
  Felix


On 2017-09-19 01:42 AM, kbuild test robot wrote:
> tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
> head:   dcae401d111324489c066aa57ed9c77b97b475f9
> commit: 18c073719186a393b41715686cf95175c58919df [1046/1053] drm/amd: Closed 
> hash table with low overhead
> config: ia64-allyesconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 6.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 18c073719186a393b41715686cf95175c58919df
> # save the attached .config to linux build tree
> make.cross ARCH=ia64 
>
> All error/warnings (new ones prefixed by >>):
>
>In file included from drivers/gpu//drm/amd/lib/chash.c:30:0:
>drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
> 'chash_iter_is_valid':
>>> drivers/gpu//drm/amd/lib/../include/linux/chash.h:286:50: error: 
>>> '_BITOPS_LONG_SHIFT' undeclared (first use in this function)
>  return !!(iter.table->valid_bitmap[iter.slot >> _BITOPS_LONG_SHIFT] &
>  ^~
>drivers/gpu//drm/amd/lib/../include/linux/chash.h:286:50: note: each 
> undeclared identifier is reported only once for each function it appears in
>drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
> 'chash_iter_is_empty':
>drivers/gpu//drm/amd/lib/../include/linux/chash.h:292:49: error: 
> '_BITOPS_LONG_SHIFT' undeclared (first use in this function)
>  return !(iter.table->occup_bitmap[iter.slot >> _BITOPS_LONG_SHIFT] &
> ^~
>drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
> 'chash_iter_set_valid':
>drivers/gpu//drm/amd/lib/../include/linux/chash.h:299:40: error: 
> '_BITOPS_LONG_SHIFT' undeclared (first use in this function)
>  iter.table->valid_bitmap[iter.slot >> _BITOPS_LONG_SHIFT] |= iter.mask;
>^~
>drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
> 'chash_iter_set_invalid':
>drivers/gpu//drm/amd/lib/../include/linux/chash.h:305:40: error: 
> '_BITOPS_LONG_SHIFT' undeclared (first use in this function)
>  iter.table->valid_bitmap[iter.slot >> _BITOPS_LONG_SHIFT] &= ~iter.mask;
>^~
>drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
> 'chash_iter_set_empty':
>drivers/gpu//drm/amd/lib/../include/linux/chash.h:310:40: error: 
> '_BITOPS_LONG_SHIFT' undeclared (first use in this function)
>  iter.table->occup_bitmap[iter.slot >> _BITOPS_LONG_SHIFT] &= ~iter.mask;
>^~
>drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
> 'chash_iter_is_valid':
>>> drivers/gpu//drm/amd/lib/../include/linux/chash.h:288:1: warning: control 
>>> reaches end of non-void function [-Wreturn-type]
> }
> ^
>drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
> 'chash_iter_is_empty':
>drivers/gpu//drm/amd/lib/../include/linux/chash.h:294:1: warning: control 
> reaches end of non-void function [-Wreturn-type]
> }
> ^
>
> vim +/_BITOPS_LONG_SHIFT +286 
> drivers/gpu//drm/amd/lib/../include/linux/chash.h
>
>252
>253/**
>254 * CHASH_ITER_INIT - Initialize a hash table iterator
>255 * @tbl: Pointer to hash table to iterate over
>256 * @s: Initial slot number
>257 */
>258#define CHASH_ITER_INIT(table, s) { \
>259table,  \
>2601UL << ((s) & (BITS_PER_LONG - 1)), \
>261s   \
>262}
>263/**
>264 * CHASH_ITER_SET - Set hash table iterator to new slot
>265 * @iter: Iterator
>266 * @s: Slot number
>267 */
>268#define CHASH_ITER_SET(iter, s) 
> \
>269(iter).mask = 1UL << ((s) & (BITS_PER_LONG - 1)),   
> \
>270(iter).slot = (s)
>271/**
>272 * CHASH_ITER_INC - Increment hash table iterator
>273 * @table: Hash table to iterate over
>274 *
>275 * Wraps around at the 

Re: [PATCH v3 0/2] drm/edid: transparent low-level override/firmware EDIDs

[Jani Nikula]

On Tue, 12 Sep 2017, Jani Nikula  wrote:
> Patch 1 is v3 of [1]. There are no functional changes to the previous
> version, just a rebase and a slight refresh of the commit message and
> comments. I think the conclusion from the discussion was that this
> should work just fine. At least one user reported this helped with their
> audio woes with firmware EDID.
>
> Patch 2 is an attempt to mitigate the problem of moving the
> edid_firmware module parameter from drm_kms_helper to drm. Not sure if
> it's too much or too little or just right. Need input here. Pedantically
> it should be part of patch 1, but this division should be easier to
> grasp in review.

Pushed to drm-misc-next, with the updated version of patch 2 to handle
drm_kms_helper.edid_firmware backwards compat properly.

BR,
Jani.


>
> BR,
> Jani.
>
>
> [1] 
> http://patchwork.freedesktop.org/patch/msgid/1487344854-18777-5-git-send-email-jani.nik...@intel.com
>
> Cc: Abdiel Janulgue 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
>
>
> Jani Nikula (2):
>   drm: handle override and firmware EDID at drm_do_get_edid() level
>   drm: add backwards compatibility support for
> drm_kms_helper.edid_firmware
>
>  Documentation/admin-guide/kernel-parameters.txt |  2 +-
>  drivers/gpu/drm/Kconfig |  2 +-
>  drivers/gpu/drm/Makefile|  2 +-
>  drivers/gpu/drm/drm_edid.c  | 15 +++
>  drivers/gpu/drm/drm_edid_load.c |  7 +++
>  drivers/gpu/drm/drm_kms_helper_common.c | 19 +++
>  drivers/gpu/drm/drm_probe_helper.c  | 19 +--
>  include/drm/drm_edid.h  |  2 ++
>  8 files changed, 47 insertions(+), 21 deletions(-)

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

[Bug 102809] Rust shadows(?) flash random colours

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
 QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
  Component|Mesa core   |Drivers/Gallium/radeonsi

--- Comment #5 from Alex Deucher  ---
Please attach your xorg log, dmesg output, and glxinfo output.

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

Re: [PATCH] qxl: fix framebuffer unpinning

[Gerd Hoffmann]

On Tue, 2017-09-19 at 11:35 -0300, Gabriel Krisman Bertazi wrote:
> Gerd Hoffmann  writes:
> 
> > qxl_plane_cleanup_fb() unpins the just activated framebuffer
> > instead of the old one.  Oops.  Fix it.
> > 
> > Cc: Gabriel Krisman Bertazi 
> > Fixes: 1277eed5fecb8830c8cc414ad70c1ef640464bc0
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  drivers/gpu/drm/qxl/qxl_display.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> > b/drivers/gpu/drm/qxl/qxl_display.c
> > index e1dd05423e..afbf50d0c0 100644
> > --- a/drivers/gpu/drm/qxl/qxl_display.c
> > +++ b/drivers/gpu/drm/qxl/qxl_display.c
> > @@ -702,14 +702,15 @@ static void qxl_plane_cleanup_fb(struct
> > drm_plane *plane,
> >     struct drm_gem_object *obj;
> >     struct qxl_bo *user_bo;
> >  
> > -   if (!plane->state->fb) {
> > -   /* we never executed prepare_fb, so there's
> > nothing to
> > +   if (!old_state->fb) {
> > +   /*
> > +    * we never executed prepare_fb, so there's
> > nothing to
> >      * unpin.
> >      */
> >     return;
> >     }
> >  
> > -   obj = to_qxl_framebuffer(plane->state->fb)->obj;
> > +   obj = to_qxl_framebuffer(old_state->fb)->obj;
> 
> I am not sure about this patch.  My idea was to pin/unpin the current
> buffer on prepare/cleanup, and only keep it pinned during the atomic
> commit.  This was the goal of 37235451c6990683a8, for instance.

I'm pretty sure the buffer must remain pinned while it is displayed.

> Anyway, if that goal is wrong, I think that, with your change, we
> forget to
> unpin the final plane before removing the device.

"removing the device"?  qxl can't be hotplugged ...
Or do you mean "rmmod qxl"?

cheers,
  Gerd

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

[Bug 102296] R9 285 VCE corruption since drm/amdgpu/gmc8: use the vram location programmed by the vbios

[bugzilla-daemon]

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

--- Comment #13 from Andy Furniss  ---
Re-reading this I notice I didn't paste the full diff between good and bad so
here's a bit more -

diff good bad though other rings do vary a bit in the second field, ring 12
(VCE?) is the only one that's different in the first field.

< amdgpu :01:00.0: fence driver on ring 12 use gpu addr 0x00821f40,
cpu addr 0xc9000364ef40
---
> amdgpu :01:00.0: fence driver on ring 12 use gpu addr 0x00f400821f40, 
> cpu addr 0xc9000104ef40

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

Re: [PATCHv2 0/2] drm/bridge/adv7511: add CEC support

[Geert Uytterhoeven]

Hi Hans,

On Tue, Sep 19, 2017 at 9:33 AM, Hans Verkuil  wrote:
> From: Hans Verkuil 
>
> I should have posted this a month ago, but I completely forgot about
> it. Apologies for that.
>
> This patch series adds CEC support to the drm adv7511/adv7533 drivers.
>
> I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
> and the Renesas R-Car Koelsch board (adv7511 based).
>
> I only have the Koelsch board to test with, but it looks like other
> R-Car boards use the same adv7511. It would be nice if someone can
> add CEC support to the other R-Car boards as well. The main thing
> to check is if they all use the same 12 MHz fixed CEC clock source.

Have a 12 MHz fixed CEC clock source connected to the CEC_CLK pin
on ADV7511:
  - r8a7790/lager
  - r8a7791/koelsch
  - r8a7791/porter
  - r8a7792/blanche
  - r8a7793/gose
  - r8a7794/alt
  - r8a7794/silk

I don't know about r8a7792/wheat. But according to its .dts file, it has two
instances of the ADV7513, not ADV7511.

Gr{oetje,eeting}s,

Geert

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

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

[Bug 196777] Virtual guest using video device QXL does not reach GDM

[bugzilla-daemon]

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

--- Comment #11 from Gerd Hoffmann (kra...@redhat.com) ---
(In reply to Justin M. Forbes from comment #10)
> After going through these with a number of users:
> 
> qxl: fix primary surface handling - This patch is widely reported to cause
> serious screen flickering that is not there without it, making the system
> unusable.

Workaround #1: turn off wayland.
Workaround #2: use virtio-vga instead. wayland doesn't use qxl 2d accel anyway.

Fundamental problem here is that the qxl virtual hardware simply doesn't
support pageflip, we have to destroy + re-create the primary surface instead. 
This is where the flicker comes from.

Commit "058e9f5c82 drm/qxl: simple crtc page flipping emulated using buffer
copy" handles the issue with a pretty gross hack, blitting one framebuffer over
the other instead of a proper primary surface update.  With atomic modesetting
that doesn't work any more.

We could possibly decouple the primary surface from the drm framebuffers, so
the drm framebuffers effectively become shadow framebuffers, and every display
update becomes a drm framebuffer -> primary surface blit.  Not sure whenever
that scheme can work properly with xorg though.  Also has a high chance to
cause xorg performance regressions.

> qxl: fix pinning: This patch resolves the GDM login issues with plymouth.

Good.

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

[Bug 102296] R9 285 VCE corruption since drm/amdgpu/gmc8: use the vram location programmed by the vbios

[bugzilla-daemon]

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

--- Comment #12 from Andy Furniss  ---
Oops the issue does still exist.
I pasted the wrong command line, which also explains why it was slightly
slower.

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

[Bug 102296] R9 285 VCE corruption since drm/amdgpu/gmc8: use the vram location programmed by the vbios

[bugzilla-daemon]

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

--- Comment #11 from Andy Furniss  ---
This seems work OK on current drm-next-4.15-wip, don't know if it's luck or not
yet. Perf is very slightly lower and I haven't been testing every iteration of
new kernels due to testing vce stuff.

There is also an unrelated to vce, powerplay/display regression on this kernel,
which I'll try to find later and file a bug.

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

Re: [PATCH 1/3] dt-bindings: Add document for rockchip RGB output interface

[Rob Herring]

On Thu, Sep 14, 2017 at 11:43:18AM +0800, Sandy Huang wrote:
> This path add support rv1108 rgb output interface driver.
> 
> Signed-off-by: Sandy Huang 
> ---
>  .../bindings/display/rockchip/rockchip-rgb.txt | 80 
> ++
>  1 file changed, 80 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt 
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
> new file mode 100644
> index 000..4164512
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
> @@ -0,0 +1,80 @@
> +Rockchip RV1108 RGB interface
> +
> +
> +Required properties:
> +- compatible: matching the soc type:
> + - "rockchip,rv1108-rgb";
> +
> +Optional properties:
> +- pinctrl-names: must contain a "lcdc" entry.
> +- pinctrl-0: pin control group to be used for this interface.
> +
> +Required nodes:
> +- rockchip,rgb-mode: should be "p888", "p666", "p565", "s888", "s888-dummy"

This should be a standard property. Any device with a parallel interface 
is going to need something like this.

> + - p888: output r8-g8-b8 at each dclk cycle for per-pixel
> + - p666: output r6-g6-b6 at each dclk cycle for per-pixel
> + - p565: output r5-g6-b5 at each dclk cycle for per-pixel
> + - s888: output r8-g8-b8 in three dclk cycle for per-pixel
> + - s888-dmmy: output r8-g8-b8-dummy in four dclk cycle for per-pixel
> +
> +The rgb has two video ports described by:
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +Their connections are modeled using the OF graph bindings specified in
> + Documentation/devicetree/bindings/graph.txt.
> +
> +- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop
> +- video port 1 for either a panel or subsequent encoder
> +
> +the panel described by:
> + Documentation/devicetree/bindings/display/panel/simple-panel.txt
> +Panel other required properties:
> +- ports for remote rgb output.
> +
> +Example:
> +
> +panel: panel {
> + compatible = "auo,b101ean01";
> + enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
> +
> + ports {
> + panel_in_rgb: endpoint {
> + remote-endpoint = <_out_panel>;
> + };
> + };
> +};
> +
> +For Rockchip RV1108:
> +
> + rgb: rgb {
> + compatible = "rockchip,rv1108-rgb";
> + pinctrl-names = "lcdc";
> + pinctrl-0 = <_ctl>;
> + rockchip,rgb-mode = "p888";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + rgb_in: port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + rgb_in_vop: endpoint@0 {
> + reg = <0>;

Don't need reg for a single endpoint.

> + remote-endpoint = <_out_rgb>;
> + };
> + };
> +
> + rgb_out: port@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + rgb_out_panel: endpoint@0 {
> + reg = <0>;

ditto.

> + remote-endpoint = <_in_rgb>;
> + };
> + };
> + };
> + };
> -- 
> 2.7.4
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 196777] Virtual guest using video device QXL does not reach GDM

[bugzilla-daemon]

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

--- Comment #10 from Justin M. Forbes (jmfor...@linuxtx.org) ---
After going through these with a number of users:

qxl: fix primary surface handling - This patch is widely reported to cause
serious screen flickering that is not there without it, making the system
unusable.

qxl: fix pinning: This patch resolves the GDM login issues with plymouth.

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

Re: [PATCH] qxl: fix framebuffer unpinning

[Gabriel Krisman Bertazi]

Gerd Hoffmann  writes:

> qxl_plane_cleanup_fb() unpins the just activated framebuffer
> instead of the old one.  Oops.  Fix it.
>
> Cc: Gabriel Krisman Bertazi 
> Fixes: 1277eed5fecb8830c8cc414ad70c1ef640464bc0
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/qxl/qxl_display.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
> b/drivers/gpu/drm/qxl/qxl_display.c
> index e1dd05423e..afbf50d0c0 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -702,14 +702,15 @@ static void qxl_plane_cleanup_fb(struct drm_plane 
> *plane,
>   struct drm_gem_object *obj;
>   struct qxl_bo *user_bo;
>  
> - if (!plane->state->fb) {
> - /* we never executed prepare_fb, so there's nothing to
> + if (!old_state->fb) {
> + /*
> +  * we never executed prepare_fb, so there's nothing to
>* unpin.
>*/
>   return;
>   }
>  
> - obj = to_qxl_framebuffer(plane->state->fb)->obj;
> + obj = to_qxl_framebuffer(old_state->fb)->obj;

I am not sure about this patch.  My idea was to pin/unpin the current
buffer on prepare/cleanup, and only keep it pinned during the atomic
commit.  This was the goal of 37235451c6990683a8, for instance.

Anyway, if that goal is wrong, I think that, with your change, we forget to
unpin the final plane before removing the device.

Thanks,

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

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

[Tomi Valkeinen]


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 19/09/17 16:48, Boris Brezillon wrote:
> On Tue, 19 Sep 2017 16:38:31 +0300
> Tomi Valkeinen  wrote:
> 
>> 
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>
>> On 19/09/17 16:25, Boris Brezillon wrote:
>>> On Tue, 19 Sep 2017 15:59:20 +0300
>>> Tomi Valkeinen  wrote:
>>>   
 Hi Boris,


 Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
 Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

 On 31/08/17 18:55, Boris Brezillon wrote:  
> Add a driver for Cadence DPI -> DSI bridge.
>
> This driver only support a subset of Cadence DSI bridge capabilities.
>
> Here is a non-exhaustive list of missing features:
>  * burst mode
>  * dynamic configuration of the DPHY based on the
>  * support for additional input interfaces (SDI input)
>
> Signed-off-by: Boris Brezillon 

 
  
> + dsi->pclk = devm_clk_get(>dev, "pclk");
> + if (IS_ERR(dsi->pclk))
> + return PTR_ERR(dsi->pclk);

 What's the purpose of pclk? Isn't that normally dealt with the normal
 modesetting, enabled with the video stream? How could it even be enabled
 here, without anyone setting the rate?  
>>>
>>> It's the peripheral clock, not the pixel clock, and AFAIU it has to be
>>> enabled before accessing DSI registers.  
>>
>> Is that the dsi_p_clk? I can't find "peripheral clock" in the specs.
> 
> Yep, it is dsi_p_clk (the APB clock).
> 
>>
>> I think calling it "pclk" in a display driver is very confusing, as
>> pclk, at least for me, always means pixel clock =).
> 
> I can rename it if you prefer. What name would you like to see?
> abp_clk? periph_clk? Something else?

Is there something wrong with dsi_p_clk? If possible, it's nice if the
terms in SW match to the HW docs. In the minimum, the DT doc should give
the mapping from SW to HW terms, at the moment it just says "pclk".

 Tomi

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

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

On Tue, 19 Sep 2017 16:38:31 +0300
Tomi Valkeinen  wrote:

> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 19/09/17 16:25, Boris Brezillon wrote:
> > On Tue, 19 Sep 2017 15:59:20 +0300
> > Tomi Valkeinen  wrote:
> >   
> >> Hi Boris,
> >>
> >>
> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> >> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> >>
> >> On 31/08/17 18:55, Boris Brezillon wrote:  
> >>> Add a driver for Cadence DPI -> DSI bridge.
> >>>
> >>> This driver only support a subset of Cadence DSI bridge capabilities.
> >>>
> >>> Here is a non-exhaustive list of missing features:
> >>>  * burst mode
> >>>  * dynamic configuration of the DPHY based on the
> >>>  * support for additional input interfaces (SDI input)
> >>>
> >>> Signed-off-by: Boris Brezillon 
> >>
> >> 
> >>  
> >>> + dsi->pclk = devm_clk_get(>dev, "pclk");
> >>> + if (IS_ERR(dsi->pclk))
> >>> + return PTR_ERR(dsi->pclk);
> >>
> >> What's the purpose of pclk? Isn't that normally dealt with the normal
> >> modesetting, enabled with the video stream? How could it even be enabled
> >> here, without anyone setting the rate?  
> > 
> > It's the peripheral clock, not the pixel clock, and AFAIU it has to be
> > enabled before accessing DSI registers.  
> 
> Is that the dsi_p_clk? I can't find "peripheral clock" in the specs.

Yep, it is dsi_p_clk (the APB clock).

> 
> I think calling it "pclk" in a display driver is very confusing, as
> pclk, at least for me, always means pixel clock =).

I can rename it if you prefer. What name would you like to see?
abp_clk? periph_clk? Something else?

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

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

[Tomi Valkeinen]


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 19/09/17 16:25, Boris Brezillon wrote:
> On Tue, 19 Sep 2017 15:59:20 +0300
> Tomi Valkeinen  wrote:
> 
>> Hi Boris,
>>
>>
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>
>> On 31/08/17 18:55, Boris Brezillon wrote:
>>> Add a driver for Cadence DPI -> DSI bridge.
>>>
>>> This driver only support a subset of Cadence DSI bridge capabilities.
>>>
>>> Here is a non-exhaustive list of missing features:
>>>  * burst mode
>>>  * dynamic configuration of the DPHY based on the
>>>  * support for additional input interfaces (SDI input)
>>>
>>> Signed-off-by: Boris Brezillon   
>>
>> 
>>
>>> +   dsi->pclk = devm_clk_get(>dev, "pclk");
>>> +   if (IS_ERR(dsi->pclk))
>>> +   return PTR_ERR(dsi->pclk);  
>>
>> What's the purpose of pclk? Isn't that normally dealt with the normal
>> modesetting, enabled with the video stream? How could it even be enabled
>> here, without anyone setting the rate?
> 
> It's the peripheral clock, not the pixel clock, and AFAIU it has to be
> enabled before accessing DSI registers.

Is that the dsi_p_clk? I can't find "peripheral clock" in the specs.

I think calling it "pclk" in a display driver is very confusing, as
pclk, at least for me, always means pixel clock =).

 Tomi

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

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

On Tue, 19 Sep 2017 15:59:20 +0300
Tomi Valkeinen  wrote:

> Hi Boris,
> 
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 31/08/17 18:55, Boris Brezillon wrote:
> > Add a driver for Cadence DPI -> DSI bridge.
> > 
> > This driver only support a subset of Cadence DSI bridge capabilities.
> > 
> > Here is a non-exhaustive list of missing features:
> >  * burst mode
> >  * dynamic configuration of the DPHY based on the
> >  * support for additional input interfaces (SDI input)
> > 
> > Signed-off-by: Boris Brezillon   
> 
> 
> 
> > +   dsi->pclk = devm_clk_get(>dev, "pclk");
> > +   if (IS_ERR(dsi->pclk))
> > +   return PTR_ERR(dsi->pclk);  
> 
> What's the purpose of pclk? Isn't that normally dealt with the normal
> modesetting, enabled with the video stream? How could it even be enabled
> here, without anyone setting the rate?

It's the peripheral clock, not the pixel clock, and AFAIU it has to be
enabled before accessing DSI registers.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 resend] drm/panel: Add driver for Seiko 43WVF1G panel

[Fabio Estevam]

Hi Thierry,

On Wed, Aug 30, 2017 at 11:12 AM, Thierry Reding
 wrote:
> On Tue, Aug 29, 2017 at 02:29:08PM -0300, Fabio Estevam wrote:
>> Hi Thierry,
>>
>> On Fri, Aug 18, 2017 at 12:08 PM, Thierry Reding
>>  wrote:
>>
>> > I've applied, though somewhat reluctantly, this to drm-misc-next without
>> > Rob's Acked-by, but the device tree bindings look trivial enough.
>>
>> Was it really applied? I am not able to find this patch in linux-next.
>
> Yeah, this is still in drm-misc-next, but due to bad timing on my part
> it missed the window for 4.14 by just a couple of minutes.
>
> Apologies for that. It should show up in linux-next shortly after
> 4.14-rc1.

Still does not show up in linux-next. Could you please double check it?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

[Tomi Valkeinen]

Hi Boris,


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 31/08/17 18:55, Boris Brezillon wrote:
> Add a driver for Cadence DPI -> DSI bridge.
> 
> This driver only support a subset of Cadence DSI bridge capabilities.
> 
> Here is a non-exhaustive list of missing features:
>  * burst mode
>  * dynamic configuration of the DPHY based on the
>  * support for additional input interfaces (SDI input)
> 
> Signed-off-by: Boris Brezillon 



> + dsi->pclk = devm_clk_get(>dev, "pclk");
> + if (IS_ERR(dsi->pclk))
> + return PTR_ERR(dsi->pclk);

What's the purpose of pclk? Isn't that normally dealt with the normal
modesetting, enabled with the video stream? How could it even be enabled
here, without anyone setting the rate?

 Tomi

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

Re: [PATCH 5/7] arm64: dts: rockchip: rk3399: Correct MIPI DPHY PLL clock

[Nickey Yang]

Hi Heiko,


On 2017年09月18日 19:31, Heiko Stübner wrote:

Hi Nickey,

Am Montag, 18. September 2017, 17:05:37 CEST schrieb Nickey Yang:

clk_24m --> Gate11[14] --> clk_mipidphy_ref --> Gate21[0] --> clk_dphy_pll

please try to be a bit more verbose in your commit messages :-) .

It looks to me, like this patch does not depend on the other ones and
I can just pick it directly. Correct?

Yes, this patch is independent,you can pick it directly.


Heiko


Signed-off-by: Nickey Yang 
---
  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index d79e9b3..6aa43fd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1629,7 +1629,7 @@
compatible = "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi";
reg = <0x0 0xff96 0x0 0x8000>;
interrupts = ;
-   clocks = < SCLK_MIPIDPHY_REF>, < PCLK_MIPI_DSI0>,
+   clocks = < SCLK_DPHY_PLL>, < PCLK_MIPI_DSI0>,
 < SCLK_DPHY_TX0_CFG>;
clock-names = "ref", "pclk", "phy_cfg";
power-domains = < RK3399_PD_VIO>;







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

Re: [PATCH 2/2] drm/exynos: Fix suspend/resume support

[Krzysztof Kozlowski]

On Thu, Sep 14, 2017 at 2:01 PM, Marek Szyprowski
 wrote:
> Commit 7d902c05b480 ("drm: Nuke drm_atomic_helper_connector_dpms")
> removed drm_atomic_helper_connector_dpms() helper saying that it was a dead
> code. It was however indirectly used by Exynos DRM driver for implementing
> suspend/resume support. To fix this regression (after that patch Exynos DRM
> suspend/resume functions became no-ops and hardware fails to suspend),
> this patch rewrites them with drm_atomic_helper_suspend/resume() helpers.
>
> Fixes: 7d902c05b480 ("drm: Nuke drm_atomic_helper_connector_dpms")
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 40 
> ++-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 10 
>  4 files changed, 43 insertions(+), 28 deletions(-)

Acked-by: Krzysztof Kozlowski 

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

Re: [PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

[Krzysztof Kozlowski]

On Tue, Aug 29, 2017 at 07:58:52AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Aug 29, 2017 at 4:52 AM, Hoegeun Kwon  
> wrote:
> > Hi Krzysztof,
> >
> > The driver has been merged into exynos-drm-misc.
> > Could you please check this patch(3/3).
> 
> Hi, OK, no problems for me but it is too late for current cycle so it
> will go in for v4.15.
>

Patch does not apply. Could you rebase on current mainline (v4.14-rc1) and 
resend?

Best regards,
Krzysztof

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

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

Hello!

On 9/19/2017 10:33 AM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
  Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
  1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
  - adi,disable-timing-generator: Only for ADV7533. Disables the internal timing
generator. The chip will rely on the sync signals in the DSI data lanes,
rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


   It's called "phandle" in the DT speak. :-)
   Are you sure the clock specifier would always be absent?


+- clock-names: from common clock binding: must be "cec".
  
  Required nodes:
  

[...]

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

[PATCH 2/7] drm/rockchip/dsi: add dual mipi channel support

[Nickey Yang]

Signed-off-by: Nickey Yang 
---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 353 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   3 +
 4 files changed, 257 insertions(+), 102 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 52698b7..9265b7f 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -42,6 +42,17 @@
 #define RK3399_GRF_SOC_CON22   0x6258
 #define RK3399_GRF_DSI_MODE0x
 
+/* disable turndisable, forcetxstopmode, forcerxmode, enable */
+#define RK3399_GRF_SOC_CON23   0x625c
+#define RK3399_GRF_DSI1_MODE1  0x
+#define RK3399_GRF_DSI1_ENABLE 0x000f000f
+/* disable basedir and enable clk*/
+#define RK3399_GRF_SOC_CON24   0x6260
+#define RK3399_TXRX_MASTERSLAVEZ   BIT(7)
+#define RK3399_TXRX_ENABLECLK  BIT(6)
+#define RK3399_TXRX_BASEDIRBIT(5)
+#define RK3399_GRF_DSI1_MODE2  0x00e00080
+
 #define DSI_VERSION0x00
 #define DSI_PWR_UP 0x04
 #define RESET  0
@@ -282,6 +293,12 @@ struct dw_mipi_dsi_plat_data {
u32 grf_switch_reg;
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
+   u32 grf_dsi1_mode;
+   u32 grf_dsi1_mode_reg1;
+   u32 dsi1_basedir;
+   u32 dsi1_masterslavez;
+   u32 dsi1_enableclk;
+   u32 grf_dsi1_mode_reg2;
unsigned int flags;
unsigned int max_data_lanes;
 };
@@ -300,6 +317,12 @@ struct dw_mipi_dsi {
struct clk *pclk;
struct clk *phy_cfg_clk;
 
+   /* dual-channel */
+   struct dw_mipi_dsi *master;
+   struct dw_mipi_dsi *slave;
+   struct device_node *panel_node;
+   int id;
+
int dpms_mode;
unsigned int lane_mbps; /* per lane */
u32 channel;
@@ -526,6 +549,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
unsigned int target_mbps = 1000;
unsigned int max_mbps = dptdin_map[ARRAY_SIZE(dptdin_map) - 1].max_mbps;
int bpp;
+   int lanes = dsi->lanes;
unsigned long best_freq = 0;
unsigned long fvco_min, fvco_max, fin ,fout;
unsigned int min_prediv, max_prediv;
@@ -540,10 +564,13 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
*dsi,
return bpp;
}
 
+   if (dsi->slave || dsi->master)
+   lanes = dsi->lanes * 2;
+
mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
if (mpclk) {
/* take 1 / 0.8, since mbps must big than bandwidth of RGB */
-   tmp = mpclk * (bpp / dsi->lanes) * 10 / 8;
+   tmp = mpclk * (bpp / lanes) * 10 / 8;
if (tmp < max_mbps)
target_mbps = tmp;
else
@@ -605,17 +632,26 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host 
*host,
   struct mipi_dsi_device *device)
 {
struct dw_mipi_dsi *dsi = host_to_dsi(host);
+   int lanes = dsi->slave ? device->lanes / 2 : device->lanes;
 
-   if (device->lanes > dsi->pdata->max_data_lanes) {
+   if (lanes > dsi->pdata->max_data_lanes) {
dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
-   device->lanes);
+   lanes);
return -EINVAL;
}
 
-   dsi->lanes = device->lanes;
+   dsi->lanes = lanes;
dsi->channel = device->channel;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
+
+   if (dsi->slave) {
+   dsi->slave->lanes = lanes;
+   dsi->slave->channel = device->channel;
+   dsi->slave->format = device->format;
+   dsi->slave->mode_flags = device->mode_flags;
+   }
+
dsi->panel = of_drm_find_panel(device->dev.of_node);
if (dsi->panel)
return drm_panel_attach(dsi->panel, >connector);
@@ -745,15 +781,22 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
mipi_dsi_host *host,
int ret;
 
dw_mipi_message_config(dsi, msg);
+   if (dsi->slave)
+   dw_mipi_message_config(dsi->slave, msg);
 
switch (msg->type) {
case MIPI_DSI_DCS_SHORT_WRITE:
case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
case MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE:
+   case MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM:
ret = dw_mipi_dsi_dcs_short_write(dsi, msg);
+   if (dsi->slave)
+   ret = dw_mipi_dsi_dcs_short_write(dsi->slave, msg);
break;
case MIPI_DSI_DCS_LONG_WRITE:
ret = dw_mipi_dsi_dcs_long_write(dsi, msg);
+   if (dsi->slave)
+   ret = 

[PATCH 1/7] drm/rockchip/dsi: correct Feedback divider setting

[Nickey Yang]

This patch correct Feedback divider setting:
1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
2、Due to the use of a "by 2 pre-scaler," the range of the
feedback multiplication Feedback divider is limited to even
division numbers, and Feedback divider must be greater than
12, less than 1000.
3、Make the previously configured Feedback divider(LSB)
factors effective

Signed-off-by: Nickey Yang 
---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 83 ++
 1 file changed, 54 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 9a20b9d..52698b7 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -228,7 +228,7 @@
 #define LOW_PROGRAM_EN 0
 #define HIGH_PROGRAM_ENBIT(7)
 #define LOOP_DIV_LOW_SEL(val)  (((val) - 1) & 0x1f)
-#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
+#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0xf)
 #define PLL_LOOP_DIV_ENBIT(5)
 #define PLL_INPUT_DIV_EN   BIT(4)
 
@@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_LOW_SEL(dsi->feedback_div) |
 LOW_PROGRAM_EN);
+   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
 HIGH_PROGRAM_EN);
dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
@@ -521,11 +522,16 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
 static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
struct drm_display_mode *mode)
 {
-   unsigned int i, pre;
-   unsigned long mpclk, pllref, tmp;
-   unsigned int m = 1, n = 1, target_mbps = 1000;
+   unsigned long mpclk, tmp;
+   unsigned int target_mbps = 1000;
unsigned int max_mbps = dptdin_map[ARRAY_SIZE(dptdin_map) - 1].max_mbps;
int bpp;
+   unsigned long best_freq = 0;
+   unsigned long fvco_min, fvco_max, fin ,fout;
+   unsigned int min_prediv, max_prediv;
+   unsigned int _prediv, uninitialized_var(best_prediv);
+   unsigned long _fbdiv, uninitialized_var(best_fbdiv);
+   unsigned long min_delta = UINT_MAX;
 
bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
if (bpp < 0) {
@@ -544,34 +550,53 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
*dsi,
dev_err(dsi->dev, "DPHY clock frequency is out of 
range\n");
}
 
-   pllref = DIV_ROUND_UP(clk_get_rate(dsi->pllref_clk), USEC_PER_SEC);
-   tmp = pllref;
-
-   /*
-* The limits on the PLL divisor are:
-*
-*  5MHz <= (pllref / n) <= 40MHz
-*
-* we walk over these values in descreasing order so that if we hit
-* an exact match for target_mbps it is more likely that "m" will be
-* even.
-*
-* TODO: ensure that "m" is even after this loop.
-*/
-   for (i = pllref / 5; i > (pllref / 40); i--) {
-   pre = pllref / i;
-   if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) {
-   tmp = target_mbps % pre;
-   n = i;
-   m = target_mbps / pre;
+   fin = clk_get_rate(dsi->pllref_clk);
+   fout = target_mbps * USEC_PER_SEC;
+
+   /* constraint: 5Mhz < Fref / N < 40MHz */
+   min_prediv = DIV_ROUND_UP(fin, 40 * USEC_PER_SEC);
+   max_prediv = fin / (5 * USEC_PER_SEC);
+
+   /* constraint: 80MHz < Fvco < 1500Mhz */
+   fvco_min = 80 * USEC_PER_SEC;
+   fvco_max = 1500 * USEC_PER_SEC;
+
+   for (_prediv = min_prediv; _prediv <= max_prediv; _prediv++) {
+   u32 delta;
+   /* Fvco = Fref * M / N */
+   tmp = fout * _prediv;
+   do_div(tmp, fin);
+   _fbdiv = tmp;
+   /*
+* Due to the use of a "by 2 pre-scaler," the range of the
+* feedback multiplication value M is limited to even division
+* numbers, and m must be greater than 12, less than 1000.
+*/
+   if (_fbdiv < 12 || _fbdiv > 1000)
+   continue;
+
+   if (_fbdiv % 2)
+   ++_fbdiv;
+
+   tmp = (u64)_fbdiv * fin;
+   do_div(tmp, _prediv);
+   if (tmp < fvco_min || tmp > fvco_max)
+   continue;
+
+   delta = abs(fout - tmp);
+   if (delta < min_delta) {
+   best_prediv = _prediv;
+   best_fbdiv = _fbdiv;
+   min_delta = delta;
+   

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 9/19/2017 12:29 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
   Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
   1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
   - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
 generator. The chip will rely on the sync signals in the DSI data lanes,
 rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


 It's called "phandle" in the DT speak. :-)
 Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


   No, you only say that there'll be the clock phandle only. The clock 
specifier may follow the phandle for the clock devices that have 
"#clock-cells" prop != 0.



Regards,

 Hans

[...]

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

Re: [RESEND PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

[Krzysztof Kozlowski]

On Mon, Sep 18, 2017 at 11:54:24AM +0900, Hoegeun Kwon wrote:
>  The display-timing and delay are included in the panel driver. So it
>  should be removed in dts.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
> 
> Hi Krzysztof,
> 
> This patch was rebased to the mainline (v4.14-rc1).
> 
> Best regards,
> Hoegeun
> 
>  arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
>  1 file changed, 22 deletions(-)
> 

Thanks, applied.

Best regards,
Krzysztof

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

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 09/19/2017 01:59 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
  Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
  1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
  - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
generator. The chip will rely on the sync signals in the DSI data lanes,
rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


It's called "phandle" in the DT speak. :-)
Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


   No, you only say that there'll be the clock phandle only. The clock
specifier may follow the phandle for the clock devices that have
"#clock-cells" prop != 0.


I have to say that I just copy-and-pasted this from other bindings.


  :-)


Would this be better?

- clocks: list of clock specifiers, corresponding to entries in
 the clock-names property;


  Didn't you say that there'll be only one clock, "cec"? If so, there's
gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)


- clock-names: from common clock binding: must be "cec".


- clocks: cec clock phandle, corresponding to the clock-names entry.


 The clock phandle and specifier.


- clock-names: from common clock binding: must be "cec".

This OK?


 Well, you seem to be going in circles, the above was almost the same as
the original prop description...


- clocks: from common clock binding: reference to the CEC clock.
- clock-names: from common clock binding: must be "cec".

This avoids the whole issue of having just a phandle or a phandle + specifier.


   OK, let's go with this one. Thank you!


Regards,

Hans


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

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 9/19/2017 1:35 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
 - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
   generator. The chip will rely on the sync signals in the DSI data lanes,
   rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


   It's called "phandle" in the DT speak. :-)
   Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


  No, you only say that there'll be the clock phandle only. The clock
specifier may follow the phandle for the clock devices that have
"#clock-cells" prop != 0.


I have to say that I just copy-and-pasted this from other bindings.


 :-)


Would this be better?

- clocks: list of clock specifiers, corresponding to entries in
the clock-names property;


 Didn't you say that there'll be only one clock, "cec"? If so, there's
gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)


- clock-names: from common clock binding: must be "cec".


- clocks: cec clock phandle, corresponding to the clock-names entry.


   The clock phandle and specifier.


- clock-names: from common clock binding: must be "cec".

This OK?


   Well, you seem to be going in circles, the above was almost the same as 
the original prop description...



Regards,

Hans


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

Re: [PATCH 3/7] dt-bindings: add the rockchip,dual-channel for dw-mipi-dsi

[Brian Norris]

Hi,

On Mon, Sep 18, 2017 at 05:05:35PM +0800, Nickey Yang wrote:
> Configure dsi slave channel when driving a panel
> which needs 2 DSI links.
> 
> Signed-off-by: Nickey Yang 
> ---
>  .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 2 
> ++
>  1 file changed, 2 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> index 6bb59ab..e13e1a3 100644
> --- 
> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> +++ 
> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> @@ -19,6 +19,8 @@ Optional properties:
>  - power-domains: a phandle to mipi dsi power domain node.
>  - resets: list of phandle + reset specifier pairs, as described in [3].
>  - reset-names: string reset name, must be "apb".
> +- rockchip,dual-channel: configure dsi slave channel when driving a panel

The wording "configure dsi slave channel" doesn't really tell you
exactly what this *is*; in fact, it's more like a description of the SW
than the HW (DT is supposed to describe HW).

You probably want something like "phandle to a 2nd DSI channel; useful
as a slave channel when driving a panel which needs 2 DSI links".

Brian

> +  which needs 2 DSI links.
>  
>  [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>  [2] Documentation/devicetree/bindings/media/video-interfaces.txt
> -- 
> 1.9.1
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Call sysfs_notify after changing drm_connector::dpms

[Karsten Wiese]

This makes poll work for the
/sys/class/drm/cardX/connectorY/dpms attributes.

Tested with i915 suspended by XScreenServer and
suspend to RAM.

Signed-off-by: Karsten Wiese 
---
 drivers/gpu/drm/drm_atomic.c| 4 
 drivers/gpu/drm/drm_atomic_helper.c | 6 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2fd383d..b6fa87b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1880,6 +1880,10 @@ int drm_atomic_connector_commit_dpms(struct 
drm_atomic_state *state,
 out:
if (ret != 0)
connector->dpms = old_mode;
+   else
+   if (connector->dpms != old_mode)
+   sysfs_notify(>kdev->kobj, NULL, "dpms");
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 4e53aae..6198772 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -921,12 +921,16 @@ drm_atomic_helper_update_legacy_modeset_state(struct 
drm_device *dev,
crtc = new_conn_state->crtc;
if ((!crtc && old_conn_state->crtc) ||
(crtc && drm_atomic_crtc_needs_modeset(crtc->state))) {
-   int mode = DRM_MODE_DPMS_OFF;
+   int old_mode, mode = DRM_MODE_DPMS_OFF;
 
if (crtc && crtc->state->active)
mode = DRM_MODE_DPMS_ON;
 
+   old_mode = connector->dpms;
connector->dpms = mode;
+   if (old_mode != mode)
+   sysfs_notify(>kdev->kobj,
+   NULL, "dpms");
}
}
 
-- 
2.7.4

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

Re: [PATCH 1/7] drm/rockchip/dsi: correct Feedback divider setting

[Brian Norris]

Hi Nickey,

On Mon, Sep 18, 2017 at 05:05:33PM +0800, Nickey Yang wrote:
> This patch correct Feedback divider setting:
> 1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
> 2、Due to the use of a "by 2 pre-scaler," the range of the
> feedback multiplication Feedback divider is limited to even
> division numbers, and Feedback divider must be greater than
> 12, less than 1000.
> 3、Make the previously configured Feedback divider(LSB)
> factors effective
> 
> Signed-off-by: Nickey Yang 
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 83 
> ++
>  1 file changed, 54 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 9a20b9d..52698b7 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -228,7 +228,7 @@
>  #define LOW_PROGRAM_EN   0
>  #define HIGH_PROGRAM_EN  BIT(7)
>  #define LOOP_DIV_LOW_SEL(val)(((val) - 1) & 0x1f)
> -#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0x1f)
> +#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0xf)
>  #define PLL_LOOP_DIV_EN  BIT(5)
>  #define PLL_INPUT_DIV_EN BIT(4)
>  
> @@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
>   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_LOW_SEL(dsi->feedback_div) |
>LOW_PROGRAM_EN);
> + dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
>   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
>HIGH_PROGRAM_EN);
>   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
> @@ -521,11 +522,16 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>  static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
>   struct drm_display_mode *mode)
>  {
> - unsigned int i, pre;
> - unsigned long mpclk, pllref, tmp;
> - unsigned int m = 1, n = 1, target_mbps = 1000;
> + unsigned long mpclk, tmp;
> + unsigned int target_mbps = 1000;
>   unsigned int max_mbps = dptdin_map[ARRAY_SIZE(dptdin_map) - 1].max_mbps;
>   int bpp;
> + unsigned long best_freq = 0;
> + unsigned long fvco_min, fvco_max, fin ,fout;
> + unsigned int min_prediv, max_prediv;
> + unsigned int _prediv, uninitialized_var(best_prediv);
> + unsigned long _fbdiv, uninitialized_var(best_fbdiv);
> + unsigned long min_delta = UINT_MAX;
>  
>   bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
>   if (bpp < 0) {
> @@ -544,34 +550,53 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
> *dsi,
>   dev_err(dsi->dev, "DPHY clock frequency is out of 
> range\n");
>   }
>  
> - pllref = DIV_ROUND_UP(clk_get_rate(dsi->pllref_clk), USEC_PER_SEC);
> - tmp = pllref;
> -
> - /*
> -  * The limits on the PLL divisor are:
> -  *
> -  *  5MHz <= (pllref / n) <= 40MHz
> -  *
> -  * we walk over these values in descreasing order so that if we hit
> -  * an exact match for target_mbps it is more likely that "m" will be
> -  * even.
> -  *
> -  * TODO: ensure that "m" is even after this loop.
> -  */
> - for (i = pllref / 5; i > (pllref / 40); i--) {
> - pre = pllref / i;
> - if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) {
> - tmp = target_mbps % pre;
> - n = i;
> - m = target_mbps / pre;
> + fin = clk_get_rate(dsi->pllref_clk);
> + fout = target_mbps * USEC_PER_SEC;
> +
> + /* constraint: 5Mhz < Fref / N < 40MHz */
> + min_prediv = DIV_ROUND_UP(fin, 40 * USEC_PER_SEC);
> + max_prediv = fin / (5 * USEC_PER_SEC);
> +
> + /* constraint: 80MHz < Fvco < 1500Mhz */
> + fvco_min = 80 * USEC_PER_SEC;
> + fvco_max = 1500 * USEC_PER_SEC;
> +
> + for (_prediv = min_prediv; _prediv <= max_prediv; _prediv++) {
> + u32 delta;
> + /* Fvco = Fref * M / N */
> + tmp = fout * _prediv;
> + do_div(tmp, fin);
> + _fbdiv = tmp;
> + /*
> +  * Due to the use of a "by 2 pre-scaler," the range of the
> +  * feedback multiplication value M is limited to even division
> +  * numbers, and m must be greater than 12, less than 1000.
> +  */
> + if (_fbdiv < 12 || _fbdiv > 1000)
> + continue;
> +
> + if (_fbdiv % 2)
> + ++_fbdiv;
> +
> + tmp = (u64)_fbdiv * fin;

Are you relying on this being able to handle >32-bit integers? They you
should declare 'tmp' as a 64-bit type; 'unsigned long' isn't guaranteed
on 32-bit architectures. 

Re: [PATCH v1 1/3] media: vsp1: Prevent resuming DRM pipelines

[Kieran Bingham]

Hi Laurent,

On 15/09/17 17:58, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Friday, 15 September 2017 19:42:05 EEST Kieran Bingham wrote:
>> DRM pipelines utilising the VSP must stop all frame processing as part
>> of the suspend operation to ensure the hardware is idle. Upon resume,
>> the pipeline must not be started until the DU performs an atomic flush
>> to restore the hardware configuration and state.
>>
>> Therefore the vsp1_pipeline_resume() call is not needed for DRM
>> pipelines, and we can disable it in this instance.
> 
> Being familiar with the issue I certainly understand the commit message, but 
> I 
> think it can be a bit confusing to a reader not familiar to the VSP/DU. How 
> about something similar to the following ?
> 
> "When used as part of a display pipeline, the VSP is stopped and restarted 
> explicitly by the DU from its suspend and resume handlers. There is thus no 
> need to stop or restart pipelines in the VSP suspend and resume handlers."

That's fine with me.


>> CC: linux-me...@vger.kernel.org
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/media/platform/vsp1/vsp1_drv.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
>> b/drivers/media/platform/vsp1/vsp1_drv.c index 962e4c304076..7604c7994c74
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_drv.c
>> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
>> @@ -582,7 +582,13 @@ static int __maybe_unused vsp1_pm_resume(struct device
>> *dev) struct vsp1_device *vsp1 = dev_get_drvdata(dev);
>>
>>  pm_runtime_force_resume(vsp1->dev);
>> -vsp1_pipelines_resume(vsp1);
>> +
>> +/*
>> + * DRM pipelines are stopped before suspend, and will be resumed after
>> + * the DRM subsystem has reconfigured its pipeline with an atomic flush
>> + */
> 
> I would also adapt this comment similarly to the commit message.
> 
>> +if (!vsp1->drm)
>> +vsp1_pipelines_resume(vsp1);
> 
> Should we do the same in vsp1_pm_suspend() ? I know it shouldn't be strictly 
> needed at the moment as vsp1_pipelines_suspend() should be a no-op when the 
> pipelines are already stopped, but a symmetrical implementation sounds better 
> to me.

I'm OK with that, it's not needed - but it doesn't hurt to be symmetrical.

(Updated locally for a v1.1 repost or such)

> I also wonder whether the check shouldn't be moved inside the 
> vsp1_pipelines_suspend() and vsp1_pipelines_resume() functions as we will 
> likely need to handle suspend/resume of display pipelines when adding 
> writeback support, but we could do so later.

I'll have to retest the writeback implementation - but I think that has got
quite stale now anyway and will need some rework.

> 
>>  return 0;
>>  }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 9/19/2017 1:07 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
- adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
  generator. The chip will rely on the sync signals in the DSI data lanes,
  rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


  It's called "phandle" in the DT speak. :-)
  Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


 No, you only say that there'll be the clock phandle only. The clock
specifier may follow the phandle for the clock devices that have
"#clock-cells" prop != 0.


I have to say that I just copy-and-pasted this from other bindings.


   :-)


Would this be better?

- clocks: list of clock specifiers, corresponding to entries in
   the clock-names property;


   Didn't you say that there'll be only one clock, "cec"? If so, there's 
gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)



- clock-names: from common clock binding: must be "cec".

Regards,

Hans


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

Re: [PATCH v3 0/3] Split default display handling out from VGA arbiter

[Daniel Axtens]

Hi all,

The merge window is well over by now - is there anything else I can do
to get this series to a mergeable state? I'm not particularly across the
rules for drm-misc, so please let me know if there are things I need to
be doing.

Regards,
Daniel

Daniel Axtens  writes:

> This patch set:
>
>  - splits the default display handling out from VGA arbiter, into its
>own file and behind its own Kconfig option (and gives the functions
>better names).
>
>  - adds extra detection of default devices. To be nominated, the vga
>arbiter and platform hooks must not have nominated a default. A
>card will then only be nominated if it has a driver attached and
>has IO or memory decoding enabled.
>
>  - adds relevant documentation.
>
> The practical impact of this is improved X autoconfiguration on some
> arm64 systems.
>
> Changes in v3:
>
>  - Add documentation - thanks Daniel Vetter for pointing it out.
>
>  - Clarify explanations. Thanks to everyone for continuing to bear
>with my incomplete understanding of PCI and provide some clarity.
>
>  - Split refactoring and adding functionality.
>
> Changes in v2: https://www.spinics.net/lists/linux-pci/msg64007.html
>
> Drop all the powerpc patches. [explanation snipped]
>
> v1: https://www.spinics.net/lists/linux-pci/msg63581.html
>
> Regards,
> Daniel
>
> Daniel Axtens (3):
>   drm: split default display handler out of VGA arbiter
>   drm: add fallback default device detection
>   drm: documentation for default display device
>
>  Documentation/gpu/default_display.rst |  93 +++
>  Documentation/gpu/index.rst   |   1 +
>  arch/ia64/pci/fixup.c |   6 +-
>  arch/powerpc/kernel/pci-common.c  |   6 +-
>  arch/x86/pci/fixup.c  |   6 +-
>  arch/x86/video/fbdev.c|   4 +-
>  drivers/gpu/vga/Kconfig   |  12 +++
>  drivers/gpu/vga/Makefile  |   1 +
>  drivers/gpu/vga/default_display.c | 163 
> ++
>  drivers/gpu/vga/vga_switcheroo.c  |   8 +-
>  drivers/gpu/vga/vgaarb.c  |  61 +++--
>  drivers/pci/pci-sysfs.c   |   4 +-
>  include/linux/default_display.h   |  44 +
>  include/linux/vgaarb.h|  15 
>  14 files changed, 344 insertions(+), 80 deletions(-)
>  create mode 100644 Documentation/gpu/default_display.rst
>  create mode 100644 drivers/gpu/vga/default_display.c
>  create mode 100644 include/linux/default_display.h
>
> -- 
> 2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/panel: add Kingdisplay kd097d04 panel driver

[Nickey Yang]

Support Kingdisplay kd097d04 9.7" 1536x2048 TFT LCD panel,
it is a MIPI DSI panel.

Signed-off-by: Nickey Yang 
---
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c | 485 +
 3 files changed, 497 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d84a031..8b1f0bd 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -50,6 +50,17 @@ config DRM_PANEL_JDI_LT070ME05000
  The panel has a 1200(RGB)??1920 (WUXGA) resolution and uses
  24 bit per pixel.
 
+config DRM_PANEL_KINGDISPLAY_KD097D04
+   tristate "Kingdisplay kd097d04 panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Kingdisplay kd097d04
+ TFT-LCD modules. The panel has a 1536x2048 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
 config DRM_PANEL_SAMSUNG_LD9040
tristate "Samsung LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 9f6610d..2548931 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
+obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
diff --git a/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c 
b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
new file mode 100644
index 000..359cd34
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
@@ -0,0 +1,485 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct kingdisplay_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *link;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+   struct gpio_desc *enable_gpio;
+
+   bool prepared;
+   bool enabled;
+};
+
+struct kingdisplay_pannel_cmd {
+   char cmd;
+   char data;
+};
+
+static const struct kingdisplay_pannel_cmd init_code[] = {
+   /* voltage setting */
+   { 0xB0, 0x00 },
+   { 0xB2, 0x02 },
+   { 0xB3, 0x11 },
+   { 0xB4, 0x00 },
+   { 0xB6, 0x80 },
+   /* VCOM disable */
+   { 0xB8, 0x80 },
+   { 0xBA, 0x43 },
+   /* VCOM setting */
+   { 0xBB, 0x53 },
+   /* VSP setting */
+   { 0xBC, 0x0A },
+   /* VSN setting */
+   { 0xBD, 0x4A },
+   /* VGH setting */
+   { 0xBE, 0x2F },
+   /* VGL setting */
+   { 0xBF, 0x1A },
+   { 0xF0, 0x39 },
+   { 0xF1, 0x21 },
+   /* Gamma setting */
+   { 0xB0, 0x02 },
+   { 0xC0, 0x00 },
+   { 0xC1, 0x01 },
+   { 0xC2, 0x0B },
+   { 0xC3, 0x15 },
+   { 0xC4, 0x22 },
+   { 0xC5, 0x11 },
+   { 0xC6, 0x15 },
+   { 0xC7, 0x19 },
+   { 0xC8, 0x1A },
+   { 0xC9, 0x16 },
+   { 0xCA, 0x18 },
+   { 0xCB, 0x13 },
+   { 0xCC, 0x18 },
+   { 0xCD, 0x13 },
+   { 0xCE, 0x1C },
+   { 0xCF, 0x19 },
+   { 0xD0, 0x21 },
+   { 0xD1, 0x2C },
+   { 0xD2, 0x2F },
+   { 0xD3, 0x30 },
+   { 0xD4, 0x19 },
+   { 0xD5, 0x1F },
+   { 0xD6, 0x00 },
+   { 0xD7, 0x01 },
+   { 0xD8, 0x0B },
+   { 0xD9, 0x15 },
+   { 0xDA, 0x22 },
+   { 0xDB, 0x11 },
+   { 0xDC, 0x15 },
+   { 0xDD, 0x19 },
+   { 0xDE, 0x1A },
+   { 0xDF, 0x16 },
+   { 0xE0, 0x18 },
+   { 0xE1, 0x13 },
+   { 0xE2, 0x18 },
+   { 0xE3, 0x13 },
+   { 0xE4, 0x1C },
+   { 0xE5, 0x19 },
+   { 0xE6, 0x21 },
+   { 0xE7, 0x2C },
+   { 0xE8, 0x2F },
+   { 0xE9, 0x30 },
+   { 0xEA, 0x19 },
+   { 0xEB, 0x1F },
+   /* GOA MUX setting */
+   { 0xB0, 0x01 },
+   { 0xC0, 0x10 },
+   { 0xC1, 0x0F },
+   { 0xC2, 0x0E },
+   { 0xC3, 0x0D },
+   { 0xC4, 0x0C },
+   { 0xC5, 

[PATCH 3/3] dt-bindings: Add KINGDISPLAY KD097D04 panel bindings

[Nickey Yang]

The KINGDISPLAY KD097D04 is a 9.7" panel with a 1536x2048
resolution and connected to DSI using 8 lanes.

Signed-off-by: Nickey Yang 
---
 .../display/panel/kingdisplay,kd097d04.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt 
b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
new file mode 100644
index 000..164a5fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
@@ -0,0 +1,22 @@
+Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel
+
+Required properties:
+- compatible: should be "kingdisplay,kd097d04"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   _dsi {
+   panel {
+   compatible = "kingdisplay,kd097d04";
+   reg = <0>;
+   power-supply = <...>;
+   backlight = <>;
+   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
1.9.1


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

Re: [PATCH 1/2] drm/exynos: Fix locking in the suspend/resume paths

[Krzysztof Kozlowski]

On Thu, Sep 14, 2017 at 2:01 PM, Marek Szyprowski
 wrote:
> Commit 48a92916729b ("drm/exynos: use drm_for_each_connector_iter()")
> replaced unsafe drm_for_each_connector() with drm_for_each_connector_iter()
> and removed surrounding drm_modeset_lock calls. However, that lock was
> there not only to protect unsafe drm_for_each_connector(), but it was also
> required to be held by the dpms code which was called from the loop body.
> This patch restores those drm_modeset_lock calls to fix broken suspend
> and resume of Exynos DRM subsystem in v4.13 kernel.
>
> Fixes: 48a92916729b ("drm/exynos: use drm_for_each_connector_iter()")
> CC: sta...@vger.kernel.org # v4.13
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 
>  1 file changed, 4 insertions(+)

Acked-by: Krzysztof Kozlowski 

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

[PATCH 5/7] arm64: dts: rockchip: rk3399: Correct MIPI DPHY PLL clock

[Nickey Yang]

clk_24m --> Gate11[14] --> clk_mipidphy_ref --> Gate21[0] --> clk_dphy_pll

Signed-off-by: Nickey Yang 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d79e9b3..6aa43fd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1629,7 +1629,7 @@
compatible = "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi";
reg = <0x0 0xff96 0x0 0x8000>;
interrupts = ;
-   clocks = < SCLK_MIPIDPHY_REF>, < PCLK_MIPI_DSI0>,
+   clocks = < SCLK_DPHY_PLL>, < PCLK_MIPI_DSI0>,
 < SCLK_DPHY_TX0_CFG>;
clock-names = "ref", "pclk", "phy_cfg";
power-domains = < RK3399_PD_VIO>;
-- 
1.9.1


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

[PATCH 4/7] drm/rockchip/dsi: correct phy parameter setting

[Nickey Yang]

As MIPI PHY document show, icpctrl<3..0> and lpfctrl<5..0>
should depend on frequency,so fix it.

Signed-off-by: Nickey Yang 
---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 70 +++---
 1 file changed, 40 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 9265b7f..d5250e8 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -228,10 +228,10 @@
 #define VCO_IN_CAP_CON_HIGH(0x2 << 1)
 #define REF_BIAS_CUR_SEL   BIT(0)
 
-#define CP_CURRENT_3MA BIT(3)
+#define CP_CURRENT_SEL(val)((val) & 0xf)
 #define CP_PROGRAM_EN  BIT(7)
 #define LPF_PROGRAM_EN BIT(6)
-#define LPF_RESISTORS_20_KOHM  0
+#define LPF_RESISTORS_SEL(val) ((val) & 0x3f)
 
 #define HSFREQRANGE_SEL(val)   (((val) & 0x3f) << 1)
 
@@ -340,32 +340,44 @@ enum dw_mipi_dsi_mode {
DW_MIPI_DSI_VID_MODE,
 };
 
-struct dphy_pll_testdin_map {
+struct dphy_pll_parameter_map {
unsigned int max_mbps;
-   u8 testdin;
+   u8 hsfreqrange;
+   u8 icpctrl;
+   u8 lpfctrl;
 };
 
 /* The table is based on 27MHz DPHY pll reference clock. */
-static const struct dphy_pll_testdin_map dptdin_map[] = {
-   {  90, 0x00}, { 100, 0x10}, { 110, 0x20}, { 130, 0x01},
-   { 140, 0x11}, { 150, 0x21}, { 170, 0x02}, { 180, 0x12},
-   { 200, 0x22}, { 220, 0x03}, { 240, 0x13}, { 250, 0x23},
-   { 270, 0x04}, { 300, 0x14}, { 330, 0x05}, { 360, 0x15},
-   { 400, 0x25}, { 450, 0x06}, { 500, 0x16}, { 550, 0x07},
-   { 600, 0x17}, { 650, 0x08}, { 700, 0x18}, { 750, 0x09},
-   { 800, 0x19}, { 850, 0x29}, { 900, 0x39}, { 950, 0x0a},
-   {1000, 0x1a}, {1050, 0x2a}, {1100, 0x3a}, {1150, 0x0b},
-   {1200, 0x1b}, {1250, 0x2b}, {1300, 0x3b}, {1350, 0x0c},
-   {1400, 0x1c}, {1450, 0x2c}, {1500, 0x3c}
+static const struct dphy_pll_parameter_map dppa_map[] = {
+   {  90, 0x00, 0x1 ,0x02}, { 100, 0x10 ,0x1, 0x02},
+   { 110, 0x20, 0x1, 0x02}, { 130, 0x01, 0x1, 0x01},
+   { 140, 0x11, 0x1, 0x01}, { 150, 0x21, 0x1, 0x01},
+   { 170, 0x02, 0x9, 0x02}, { 180, 0x12, 0x9, 0x02},
+   { 200, 0x22, 0x9, 0x02}, { 220, 0x03, 0x2, 0x02},
+   { 240, 0x13, 0x2, 0x02}, { 250, 0x23, 0x2, 0x02},
+   { 270, 0x04, 0x9, 0x04}, { 300, 0x14, 0x9, 0x04},
+   { 330, 0x05, 0x1, 0x01}, { 360, 0x15, 0x1, 0x01},
+   { 400, 0x25, 0x1, 0x01}, { 450, 0x06, 0x6, 0x04},
+   { 500, 0x16, 0x6, 0x04}, { 550, 0x07, 0x6, 0x08},
+   { 600, 0x17, 0x6, 0x08}, { 650, 0x08, 0x6, 0x04},
+   { 700, 0x18, 0x6, 0x04}, { 750, 0x09, 0x6, 0x04},
+   { 800, 0x19, 0x6, 0x04}, { 850, 0x29, 0x6, 0x04},
+   { 900, 0x39, 0x6, 0x04}, { 950, 0x0a, 0xb, 0x10},
+   {1000, 0x1a, 0xb, 0x10}, {1050, 0x2a, 0xb, 0x10},
+   {1100, 0x3a, 0xb, 0x10}, {1150, 0x0b, 0xb, 0x08},
+   {1200, 0x1b, 0xb, 0x08}, {1250, 0x2b, 0xb, 0x08},
+   {1300, 0x3b, 0xb, 0x08}, {1350, 0x0c, 0xb, 0x08},
+   {1400, 0x1c, 0xb, 0x08}, {1450, 0x2c, 0xb, 0x08},
+   {1500, 0x3c, 0xb, 0x08}
 };
 
-static int max_mbps_to_testdin(unsigned int max_mbps)
+static int max_mbps_to_parameter(unsigned int max_mbps)
 {
int i;
 
-   for (i = 0; i < ARRAY_SIZE(dptdin_map); i++)
-   if (dptdin_map[i].max_mbps > max_mbps)
-   return dptdin_map[i].testdin;
+   for (i = 0; i < ARRAY_SIZE(dppa_map); i++)
+   if (dppa_map[i].max_mbps > max_mbps)
+   return i;
 
return -EINVAL;
 }
@@ -447,16 +459,16 @@ static inline unsigned int ns2ui(struct dw_mipi_dsi *dsi, 
int ns)
 
 static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
 {
-   int ret, testdin, vco, val;
+   int ret, i, vco, val;
 
vco = (dsi->lane_mbps < 200) ? 0 : (dsi->lane_mbps + 100) / 200;
 
-   testdin = max_mbps_to_testdin(dsi->lane_mbps);
-   if (testdin < 0) {
+   i = max_mbps_to_parameter(dsi->lane_mbps);
+   if (i < 0) {
dev_err(dsi->dev,
-   "failed to get testdin for %dmbps lane clock\n",
+   "failed to get parameter for %dmbps lane clock\n",
dsi->lane_mbps);
-   return testdin;
+   return i;
}
 
/* Start by clearing PHY state */
@@ -475,12 +487,10 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
 VCO_IN_CAP_CON_LOW |
 REF_BIAS_CUR_SEL);
 
-   dw_mipi_dsi_phy_write(dsi, 0x11, CP_CURRENT_3MA);
+   dw_mipi_dsi_phy_write(dsi, 0x11, CP_CURRENT_SEL(dppa_map[i].icpctrl));
dw_mipi_dsi_phy_write(dsi, 0x12, CP_PROGRAM_EN | LPF_PROGRAM_EN |
-LPF_RESISTORS_20_KOHM);
-
-   dw_mipi_dsi_phy_write(dsi, 0x44, HSFREQRANGE_SEL(testdin));
-
+

[PATCH 3/7] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

[Nickey Yang]

Configure dsi slave channel when driving a panel
which needs 2 DSI links.

Signed-off-by: Nickey Yang 
---
 .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 6bb59ab..e13e1a3 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -19,6 +19,8 @@ Optional properties:
 - power-domains: a phandle to mipi dsi power domain node.
 - resets: list of phandle + reset specifier pairs, as described in [3].
 - reset-names: string reset name, must be "apb".
+- rockchip,dual-channel: configure dsi slave channel when driving a panel
+  which needs 2 DSI links.
 
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 [2] Documentation/devicetree/bindings/media/video-interfaces.txt
-- 
1.9.1


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

Re: [PATCH v4 2/2] ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

[Krzysztof Kozlowski]

On Tue, Sep 12, 2017 at 09:34:08AM +0200, Maciej Purski wrote:
> Add HDMI and Sil9234 MHL converter to Trats2 board.
> Following in SoC devices have been enabled:
> - HDMI (HDMI signal encoder),
> - Mixer (video buffer scanout device),
> - I2C_5 bus (used for HDMI DDC)
> - I2C_8 bus (used for HDMI_PHY control).
> 
> Based on previous work by:
> Tomasz Stanislawski 
> 
> Signed-off-by: Maciej Purski 
> ---
>  arch/arm/boot/dts/exynos4412-trats2.dts | 112 
> 
>  1 file changed, 112 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 35e9b94..742e02a 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  / {
>   model = "Samsung Trats 2 based on Exynos4412";
> @@ -97,6 +98,34 @@
>   gpio = < 5 GPIO_ACTIVE_HIGH>;
>   enable-active-high;
>   };
> +
> + vsil12: voltage-regulator-6 {
> + compatible = "regulator-fixed";
> + regulator-name = "VSIL_1.2V";
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + gpio = < 4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + vin-supply = <_reg>;
> + };
> +
> + vcc33mhl: voltage-regulator-7 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3.3_MHL";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vcc18mhl: voltage-regulator-8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_1.8_MHL";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + gpio = < 4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
>   };
>  
>   gpio-keys {
> @@ -229,6 +258,36 @@
>   };
>   };
>  
> + i2c-mhl {
> + compatible = "i2c-gpio";
> + gpios = < 4 GPIO_ACTIVE_HIGH  6 GPIO_ACTIVE_HIGH>;

Please split it like in other nodes:
gpios = <...>, <...>

AFAIR they should work the same so keep it consistent.

Rest looks good but the bindings have to be accepted first.

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

[Bug 102616] [CI][SNB,HSW,APL,KBL] igt@gem_eio@in-flight - Failed assertion: __vgem_fence_signal(fd, fence) == 0

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

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

--- Comment #7 from Chris Wilson  ---
commit 92e457d0ffe930369d09bc83d3d3ed90c9bd6cb1
Author: Chris Wilson 
Date:   Fri Sep 8 11:33:15 2017 +0100

igt/gem_eio: inflight wedged requires long plugging

As our hangcheck may exceed 10s to declare the device wedged, we need to
hold the plugging fence indefinitely. This makes using vgem as our input
fence unusable, so resort to using sw_sync. At the same time, we can
then check that the async result is also -EIO.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102616
Signed-off-by: Chris Wilson 
Reviewed-by: Michał Winiarski 

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

Re: [PATCH 4/4] drm/ttm: Remove TTM dma tracepoint since it's not required anymore

[Christian König]

Am 19.09.2017 um 13:15 schrieb Tom St Denis:

On 19/09/17 07:13 AM, Christian König wrote:

Am 18.09.2017 um 19:33 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 


Mhm, I sometimes have good use for those. But just adding a printk at 
the right place does the job as well.


So patch is Reviewed-by: Christian König .


Well if you want to keep them we should not apply patch #3 then since 
we're the only users of it :-)


I'm ok with dropping #3/#4 if you want (also less work for Alex since 
we won't have to prune that history out of the branch we submit 
upstream).


Please remove that for now. The next time I need it I can cleanup and 
resubmit the patches so that they work for all drivers in the kernel.


Christian.



umr has already been ported over to the new iova file though so it 
won't be using the trace.


Cheers,
Tom




Regards,
Christian.


---
  drivers/gpu/drm/ttm/Makefile  |  2 +-
  drivers/gpu/drm/ttm/ttm_debug.c   | 74 
-
  drivers/gpu/drm/ttm/ttm_trace.h   | 87 
---

  drivers/gpu/drm/ttm/ttm_tracepoints.c | 45 --
  4 files changed, 1 insertion(+), 207 deletions(-)
  delete mode 100644 drivers/gpu/drm/ttm/ttm_debug.c
  delete mode 100644 drivers/gpu/drm/ttm/ttm_trace.h
  delete mode 100644 drivers/gpu/drm/ttm/ttm_tracepoints.c

diff --git a/drivers/gpu/drm/ttm/Makefile 
b/drivers/gpu/drm/ttm/Makefile

index ab2bef1219e5..4d0c938ff4b2 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -4,7 +4,7 @@
  ttm-y := ttm_memory.o ttm_tt.o ttm_bo.o \
  ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
  ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
-ttm_bo_manager.o ttm_page_alloc_dma.o ttm_debug.o 
ttm_tracepoints.o

+ttm_bo_manager.o ttm_page_alloc_dma.o
  ttm-$(CONFIG_AGP) += ttm_agp_backend.o
  obj-$(CONFIG_DRM_TTM) += ttm.o
diff --git a/drivers/gpu/drm/ttm/ttm_debug.c 
b/drivers/gpu/drm/ttm/ttm_debug.c

deleted file mode 100644
index ef5f0d090154..
--- a/drivers/gpu/drm/ttm/ttm_debug.c
+++ /dev/null
@@ -1,74 +0,0 @@
-/** 


- *
- * Copyright (c) 2017 Advanced Micro Devices, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person 
obtaining a

- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, 
subject to

- * the following conditions:
- *
- * The above copyright notice and this permission notice (including 
the
- * next paragraph) shall be included in all copies or substantial 
portions

- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO 
EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE 
FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, 
TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE 
SOFTWARE OR THE

- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- 
**/ 


-/*
- * Authors: Tom St Denis 
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "ttm_trace.h"
-
-void ttm_trace_dma_map(struct device *dev, struct ttm_dma_tt *tt)
-{
-unsigned i;
-
-if (unlikely(trace_ttm_dma_map_enabled())) {
-for (i = 0; i < tt->ttm.num_pages; i++) {
-trace_ttm_dma_map(
-dev,
-tt->ttm.pages[i],
-tt->dma_address[i]);
-}
-}
-}
-EXPORT_SYMBOL(ttm_trace_dma_map);
-
-void ttm_trace_dma_unmap(struct device *dev, struct ttm_dma_tt *tt)
-{
-unsigned i;
-
-if (unlikely(trace_ttm_dma_unmap_enabled())) {
-for (i = 0; i < tt->ttm.num_pages; i++) {
-trace_ttm_dma_unmap(
-dev,
-tt->ttm.pages[i],
-tt->dma_address[i]);
-}
-}
-}
-EXPORT_SYMBOL(ttm_trace_dma_unmap);
-
diff --git a/drivers/gpu/drm/ttm/ttm_trace.h 
b/drivers/gpu/drm/ttm/ttm_trace.h

deleted file mode 100644
index 715ce68b7b33..
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ /dev/null
@@ -1,87 +0,0 @@
-/** 


- *
- * Copyright (c) 2017 Advanced Micro Devices, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any 

Re: [PATCH 4/4] drm/ttm: Remove TTM dma tracepoint since it's not required anymore

[Tom St Denis]

On 19/09/17 07:13 AM, Christian König wrote:

Am 18.09.2017 um 19:33 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 


Mhm, I sometimes have good use for those. But just adding a printk at 
the right place does the job as well.


So patch is Reviewed-by: Christian König .


Well if you want to keep them we should not apply patch #3 then since 
we're the only users of it :-)


I'm ok with dropping #3/#4 if you want (also less work for Alex since we 
won't have to prune that history out of the branch we submit upstream).


umr has already been ported over to the new iova file though so it won't 
be using the trace.


Cheers,
Tom




Regards,
Christian.


---
  drivers/gpu/drm/ttm/Makefile  |  2 +-
  drivers/gpu/drm/ttm/ttm_debug.c   | 74 
-
  drivers/gpu/drm/ttm/ttm_trace.h   | 87 
---

  drivers/gpu/drm/ttm/ttm_tracepoints.c | 45 --
  4 files changed, 1 insertion(+), 207 deletions(-)
  delete mode 100644 drivers/gpu/drm/ttm/ttm_debug.c
  delete mode 100644 drivers/gpu/drm/ttm/ttm_trace.h
  delete mode 100644 drivers/gpu/drm/ttm/ttm_tracepoints.c

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index ab2bef1219e5..4d0c938ff4b2 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -4,7 +4,7 @@
  ttm-y := ttm_memory.o ttm_tt.o ttm_bo.o \
  ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
  ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
-    ttm_bo_manager.o ttm_page_alloc_dma.o ttm_debug.o ttm_tracepoints.o
+    ttm_bo_manager.o ttm_page_alloc_dma.o
  ttm-$(CONFIG_AGP) += ttm_agp_backend.o
  obj-$(CONFIG_DRM_TTM) += ttm.o
diff --git a/drivers/gpu/drm/ttm/ttm_debug.c 
b/drivers/gpu/drm/ttm/ttm_debug.c

deleted file mode 100644
index ef5f0d090154..
--- a/drivers/gpu/drm/ttm/ttm_debug.c
+++ /dev/null
@@ -1,74 +0,0 @@
-/** 


- *
- * Copyright (c) 2017 Advanced Micro Devices, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person 
obtaining a

- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial 
portions

- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT 
SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR 
ANY CLAIM,

- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE 
OR THE

- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- 
**/ 


-/*
- * Authors: Tom St Denis 
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "ttm_trace.h"
-
-void ttm_trace_dma_map(struct device *dev, struct ttm_dma_tt *tt)
-{
-    unsigned i;
-
-    if (unlikely(trace_ttm_dma_map_enabled())) {
-    for (i = 0; i < tt->ttm.num_pages; i++) {
-    trace_ttm_dma_map(
-    dev,
-    tt->ttm.pages[i],
-    tt->dma_address[i]);
-    }
-    }
-}
-EXPORT_SYMBOL(ttm_trace_dma_map);
-
-void ttm_trace_dma_unmap(struct device *dev, struct ttm_dma_tt *tt)
-{
-    unsigned i;
-
-    if (unlikely(trace_ttm_dma_unmap_enabled())) {
-    for (i = 0; i < tt->ttm.num_pages; i++) {
-    trace_ttm_dma_unmap(
-    dev,
-    tt->ttm.pages[i],
-    tt->dma_address[i]);
-    }
-    }
-}
-EXPORT_SYMBOL(ttm_trace_dma_unmap);
-
diff --git a/drivers/gpu/drm/ttm/ttm_trace.h 
b/drivers/gpu/drm/ttm/ttm_trace.h

deleted file mode 100644
index 715ce68b7b33..
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ /dev/null
@@ -1,87 +0,0 @@
-/** 


- *
- * Copyright (c) 2017 Advanced Micro Devices, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person 
obtaining a

- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, 

Re: [PATCH 4/4] drm/ttm: Remove TTM dma tracepoint since it's not required anymore

[Christian König]

Am 18.09.2017 um 19:33 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 


Mhm, I sometimes have good use for those. But just adding a printk at 
the right place does the job as well.


So patch is Reviewed-by: Christian König .

Regards,
Christian.


---
  drivers/gpu/drm/ttm/Makefile  |  2 +-
  drivers/gpu/drm/ttm/ttm_debug.c   | 74 -
  drivers/gpu/drm/ttm/ttm_trace.h   | 87 ---
  drivers/gpu/drm/ttm/ttm_tracepoints.c | 45 --
  4 files changed, 1 insertion(+), 207 deletions(-)
  delete mode 100644 drivers/gpu/drm/ttm/ttm_debug.c
  delete mode 100644 drivers/gpu/drm/ttm/ttm_trace.h
  delete mode 100644 drivers/gpu/drm/ttm/ttm_tracepoints.c

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index ab2bef1219e5..4d0c938ff4b2 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -4,7 +4,7 @@
  ttm-y := ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
-   ttm_bo_manager.o ttm_page_alloc_dma.o ttm_debug.o ttm_tracepoints.o
+   ttm_bo_manager.o ttm_page_alloc_dma.o
  ttm-$(CONFIG_AGP) += ttm_agp_backend.o
  
  obj-$(CONFIG_DRM_TTM) += ttm.o

diff --git a/drivers/gpu/drm/ttm/ttm_debug.c b/drivers/gpu/drm/ttm/ttm_debug.c
deleted file mode 100644
index ef5f0d090154..
--- a/drivers/gpu/drm/ttm/ttm_debug.c
+++ /dev/null
@@ -1,74 +0,0 @@
-/**
- *
- * Copyright (c) 2017 Advanced Micro Devices, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- **/
-/*
- * Authors: Tom St Denis 
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "ttm_trace.h"
-
-void ttm_trace_dma_map(struct device *dev, struct ttm_dma_tt *tt)
-{
-   unsigned i;
-
-   if (unlikely(trace_ttm_dma_map_enabled())) {
-   for (i = 0; i < tt->ttm.num_pages; i++) {
-   trace_ttm_dma_map(
-   dev,
-   tt->ttm.pages[i],
-   tt->dma_address[i]);
-   }
-   }
-}
-EXPORT_SYMBOL(ttm_trace_dma_map);
-
-void ttm_trace_dma_unmap(struct device *dev, struct ttm_dma_tt *tt)
-{
-   unsigned i;
-
-   if (unlikely(trace_ttm_dma_unmap_enabled())) {
-   for (i = 0; i < tt->ttm.num_pages; i++) {
-   trace_ttm_dma_unmap(
-   dev,
-   tt->ttm.pages[i],
-   tt->dma_address[i]);
-   }
-   }
-}
-EXPORT_SYMBOL(ttm_trace_dma_unmap);
-
diff --git a/drivers/gpu/drm/ttm/ttm_trace.h b/drivers/gpu/drm/ttm/ttm_trace.h
deleted file mode 100644
index 715ce68b7b33..
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ /dev/null
@@ -1,87 +0,0 @@
-/**
- *
- * Copyright (c) 2017 Advanced Micro Devices, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including 

Re: [PATCH 3/4] drm/amd/amdgpu: remove usage of ttm trace

[Christian König]

Am 18.09.2017 um 19:33 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 36 +++--
  1 file changed, 3 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 02ae32378e1c..b41d03226c26 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -34,7 +34,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
@@ -704,22 +703,6 @@ void amdgpu_ttm_tt_mark_user_pages(struct ttm_tt *ttm)
}
  }
  
-static void amdgpu_trace_dma_map(struct ttm_tt *ttm)

-{
-   struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
-   struct amdgpu_ttm_tt *gtt = (void *)ttm;
-
-   ttm_trace_dma_map(adev->dev, >ttm);
-}
-
-static void amdgpu_trace_dma_unmap(struct ttm_tt *ttm)
-{
-   struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
-   struct amdgpu_ttm_tt *gtt = (void *)ttm;
-
-   ttm_trace_dma_unmap(adev->dev, >ttm);
-}
-
  /* prepare the sg table with the user pages */
  static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
  {
@@ -746,8 +729,6 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
 gtt->ttm.dma_address, ttm->num_pages);
  
-	amdgpu_trace_dma_map(ttm);

-
return 0;
  
  release_sg:

@@ -773,8 +754,6 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
  
  	amdgpu_ttm_tt_mark_user_pages(ttm);
  
-	amdgpu_trace_dma_unmap(ttm);

-
sg_free_table(ttm->sg);
  }
  
@@ -958,7 +937,6 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)

  {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
-   int r;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
  
  	if (ttm->state != tt_unpopulated)

@@ -978,22 +956,16 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
 gtt->ttm.dma_address, 
ttm->num_pages);
ttm->state = tt_unbound;
-   r = 0;
-   goto trace_mappings;
+   return 0;
}
  
  #ifdef CONFIG_SWIOTLB

if (swiotlb_nr_tbl()) {
-   r = ttm_dma_populate(>ttm, adev->dev);
-   goto trace_mappings;
+   return ttm_dma_populate(>ttm, adev->dev);
}
  #endif
  
-	r = ttm_populate_and_map_pages(adev->dev, >ttm);

-trace_mappings:
-   if (likely(!r))
-   amdgpu_trace_dma_map(ttm);
-   return r;
+   return ttm_populate_and_map_pages(adev->dev, >ttm);
  }
  
  static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)

@@ -1014,8 +986,6 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
  
  	adev = amdgpu_ttm_adev(ttm->bdev);
  
-	amdgpu_trace_dma_unmap(ttm);

-
  #ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, adev->dev);



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

Re: [PATCH 2/4] drm/amd/amdgpu: add support for iova_to_phys to replace TTM trace (v3)

[Christian König]

Am 18.09.2017 um 19:33 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 

(v2): Add domain to iova debugfs
(v3): Add true read/write methods to access system memory of pages
   mapped to the device
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 104 
  1 file changed, 104 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 50d20903de4f..02ae32378e1c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -43,6 +43,7 @@
  #include 
  #include 
  #include 
+#include 
  #include "amdgpu.h"
  #include "amdgpu_trace.h"
  #include "bif/bif_4_1_d.h"
@@ -1810,6 +1811,108 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
  #endif
  
  
+static void *transform_page(uint64_t phys)

+{
+   if (PageHighMem(pfn_to_page(PFN_DOWN(phys
+   return kmap(pfn_to_page(PFN_DOWN(phys)));
+   else
+   return __va(phys);
+}
+
+static void untransform_page(uint64_t phys)
+{
+   if (PageHighMem(pfn_to_page(PFN_DOWN(phys
+   return kunmap(pfn_to_page(PFN_DOWN(phys)));
+}


No need for the extra PageHighMem check, just use kmap()/kunmap() they 
should do the right thing IIRC.



+
+static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,
+  size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   ssize_t result, n;
+   int r;
+   uint64_t phys;
+   void *ptr;
+
+   result = 0;
+   while (size) {
+   // get physical address and map
+   phys = iommu_iova_to_phys(iommu_get_domain_for_dev(adev->dev), 
*pos);


Not sure what iommu_get_domain_for_dev does exactly, but the iommu 
domain for the device should always be the same so I would call the 
function only once before the loop.


Also failing with -ENODEV here when iommu_get_domain_for_dev() returns 
NULL sounds like a good idea to me.



+
+   // copy upto one page
+   if (size > PAGE_SIZE)
+   n = PAGE_SIZE;
+   else
+   n = size;
+
+   // to end of the page
+   if (((*pos & (PAGE_SIZE - 1)) + n) >= PAGE_SIZE)
+   n = PAGE_SIZE - (*pos & (PAGE_SIZE - 1));
+
+   ptr = transform_page(phys);
+   if (!ptr)
+   return -EFAULT;
+
+   r = copy_to_user(buf, ptr, n);
+   untransform_page(phys);
+   if (r)
+   return -EFAULT;
+
+   *pos += n;
+   size -= n;
+   result += n;
+   }
+
+   return result;
+}
+
+static ssize_t amdgpu_iova_to_phys_write(struct file *f, const char __user 
*buf,
+  size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   ssize_t result, n;
+   int r;
+   uint64_t phys;
+   void *ptr;
+
+   result = 0;
+   while (size) {
+   // get physical address and map
+   phys = iommu_iova_to_phys(iommu_get_domain_for_dev(adev->dev), 
*pos);


Same comment as above.

Apart from that looks good to me,
Christian.


+
+   // copy upto one page
+   if (size > PAGE_SIZE)
+   n = PAGE_SIZE;
+   else
+   n = size;
+
+   // to end of the page
+   if (((*pos & (PAGE_SIZE - 1)) + n) >= PAGE_SIZE)
+   n = PAGE_SIZE - (*pos & (PAGE_SIZE - 1));
+
+   ptr = transform_page(phys);
+   if (!ptr)
+   return -EFAULT;
+
+   r = copy_from_user(ptr, buf, n);
+   untransform_page(phys);
+   if (r)
+   return -EFAULT;
+
+   *pos += n;
+   size -= n;
+   result += n;
+   }
+
+   return result;
+}
+
+static const struct file_operations amdgpu_ttm_iova_fops = {
+   .owner = THIS_MODULE,
+   .read = amdgpu_iova_to_phys_read,
+   .write = amdgpu_iova_to_phys_write,
+   .llseek = default_llseek
+};
  
  static const struct {

char *name;
@@ -1820,6 +1923,7 @@ static const struct {
  #ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
{ "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT },
  #endif
+   { "amdgpu_iova", _ttm_iova_fops, TTM_PL_SYSTEM },
  };
  
  #endif



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

Re: [PATCH 1/4] drm/amd/amdgpu: Fold TTM debugfs entries into array (v2)

[Christian König]

Am 18.09.2017 um 19:33 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 


Reviewed-by: Christian König 



(v2): add domains and avoid strcmp
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 54 ++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  4 +--
  2 files changed, 32 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8ee16dfdb8af..50d20903de4f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1809,6 +1809,19 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
  
  #endif
  
+

+
+static const struct {
+   char *name;
+   const struct file_operations *fops;
+   int domain;
+} ttm_debugfs_entries[] = {
+   { "amdgpu_vram", _ttm_vram_fops, TTM_PL_VRAM },
+#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
+   { "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT },
+#endif
+};
+
  #endif
  
  static int amdgpu_ttm_debugfs_init(struct amdgpu_device *adev)

@@ -1819,22 +1832,21 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
struct drm_minor *minor = adev->ddev->primary;
struct dentry *ent, *root = minor->debugfs_root;
  
-	ent = debugfs_create_file("amdgpu_vram", S_IFREG | S_IRUGO, root,

- adev, _ttm_vram_fops);
-   if (IS_ERR(ent))
-   return PTR_ERR(ent);
-   i_size_write(ent->d_inode, adev->mc.mc_vram_size);
-   adev->mman.vram = ent;
-
-#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
-   ent = debugfs_create_file("amdgpu_gtt", S_IFREG | S_IRUGO, root,
- adev, _ttm_gtt_fops);
-   if (IS_ERR(ent))
-   return PTR_ERR(ent);
-   i_size_write(ent->d_inode, adev->mc.gart_size);
-   adev->mman.gtt = ent;
+   for (count = 0; count < ARRAY_SIZE(ttm_debugfs_entries); count++) {
+   ent = debugfs_create_file(
+   ttm_debugfs_entries[count].name,
+   S_IFREG | S_IRUGO, root,
+   adev,
+   ttm_debugfs_entries[count].fops);
+   if (IS_ERR(ent))
+   return PTR_ERR(ent);
+   if (ttm_debugfs_entries[count].domain == TTM_PL_VRAM)
+   i_size_write(ent->d_inode, adev->mc.mc_vram_size);
+   else if (ttm_debugfs_entries[count].domain == TTM_PL_TT)
+   i_size_write(ent->d_inode, adev->mc.gart_size);
+   adev->mman.debugfs_entries[count] = ent;
+   }
  
-#endif

count = ARRAY_SIZE(amdgpu_ttm_debugfs_list);
  
  #ifdef CONFIG_SWIOTLB

@@ -1844,7 +1856,6 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
  
  	return amdgpu_debugfs_add_files(adev, amdgpu_ttm_debugfs_list, count);

  #else
-
return 0;
  #endif
  }
@@ -1852,14 +1863,9 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
  static void amdgpu_ttm_debugfs_fini(struct amdgpu_device *adev)
  {
  #if defined(CONFIG_DEBUG_FS)
+   unsigned i;
  
-	debugfs_remove(adev->mman.vram);

-   adev->mman.vram = NULL;
-
-#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
-   debugfs_remove(adev->mman.gtt);
-   adev->mman.gtt = NULL;
-#endif
-
+   for (i = 0; i < ARRAY_SIZE(ttm_debugfs_entries); i++)
+   debugfs_remove(adev->mman.debugfs_entries[i]);
  #endif
  }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 64709e041d5b..7abae6867339 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -24,6 +24,7 @@
  #ifndef __AMDGPU_TTM_H__
  #define __AMDGPU_TTM_H__
  
+#include "amdgpu.h"

  #include "gpu_scheduler.h"
  
  #define AMDGPU_PL_GDS		(TTM_PL_PRIV + 0)

@@ -45,8 +46,7 @@ struct amdgpu_mman {
boolinitialized;
  
  #if defined(CONFIG_DEBUG_FS)

-   struct dentry   *vram;
-   struct dentry   *gtt;
+   struct dentry   *debugfs_entries[8];
  #endif
  
  	/* buffer handling */



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

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Hans Verkuil]

On 09/19/17 12:42, Sergei Shtylyov wrote:
> On 9/19/2017 1:35 PM, Hans Verkuil wrote:
> 
 From: Hans Verkuil 

 Document the cec clock binding.

 Signed-off-by: Hans Verkuil 
 Acked-by: Rob Herring 
 ---
  Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
 | 4 
  1 file changed, 4 insertions(+)

 diff --git 
 a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
 b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 index 06668bca7ffc..4497ae054d49 100644
 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 @@ -68,6 +68,8 @@ Optional properties:
  - adi,disable-timing-generator: Only for ADV7533. Disables the 
 internal timing
generator. The chip will rely on the sync signals in the DSI 
 data lanes,
rather than generate its own timings for HDMI output.
 +- clocks: from common clock binding: handle to CEC clock.
>>>
>>>It's called "phandle" in the DT speak. :-)
>>>Are you sure the clock specifier would always be absent?
>>
>> Sorry? I don't understand the question. Did you mean: "can be absent?"?
>
>   No, you only say that there'll be the clock phandle only. The clock
> specifier may follow the phandle for the clock devices that have
> "#clock-cells" prop != 0.

 I have to say that I just copy-and-pasted this from other bindings.
>>>
>>>  :-)
>>>
 Would this be better?

 - clocks: list of clock specifiers, corresponding to entries in
 the clock-names property;
>>>
>>>  Didn't you say that there'll be only one clock, "cec"? If so, there's
>>> gonna  be a single clock phandle+specifier pair. They always go in pairs. 
>>> :-)
>>>
 - clock-names: from common clock binding: must be "cec".
>>
>> - clocks: cec clock phandle, corresponding to the clock-names entry.
> 
> The clock phandle and specifier.
> 
>> - clock-names: from common clock binding: must be "cec".
>>
>> This OK?
> 
> Well, you seem to be going in circles, the above was almost the same as 
> the original prop description...

- clocks: from common clock binding: reference to the CEC clock.
- clock-names: from common clock binding: must be "cec".

This avoids the whole issue of having just a phandle or a phandle + specifier.

Regards,

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

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Hans Verkuil]

On 09/19/17 12:15, Sergei Shtylyov wrote:
> On 9/19/2017 1:07 PM, Hans Verkuil wrote:
> 
>> From: Hans Verkuil 
>>
>> Document the cec clock binding.
>>
>> Signed-off-by: Hans Verkuil 
>> Acked-by: Rob Herring 
>> ---
>> Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
>> 
>> 1 file changed, 4 insertions(+)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> index 06668bca7ffc..4497ae054d49 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> @@ -68,6 +68,8 @@ Optional properties:
>> - adi,disable-timing-generator: Only for ADV7533. Disables the 
>> internal timing
>>   generator. The chip will rely on the sync signals in the DSI data 
>> lanes,
>>   rather than generate its own timings for HDMI output.
>> +- clocks: from common clock binding: handle to CEC clock.
>
>   It's called "phandle" in the DT speak. :-)
>   Are you sure the clock specifier would always be absent?

 Sorry? I don't understand the question. Did you mean: "can be absent?"?
>>>
>>>  No, you only say that there'll be the clock phandle only. The clock
>>> specifier may follow the phandle for the clock devices that have
>>> "#clock-cells" prop != 0.
>>
>> I have to say that I just copy-and-pasted this from other bindings.
> 
> :-)
> 
>> Would this be better?
>>
>> - clocks: list of clock specifiers, corresponding to entries in
>>the clock-names property;
> 
> Didn't you say that there'll be only one clock, "cec"? If so, there's 
> gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)
> 
>> - clock-names: from common clock binding: must be "cec".

- clocks: cec clock phandle, corresponding to the clock-names entry.
- clock-names: from common clock binding: must be "cec".

This OK?

Regards,

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

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Hans Verkuil]

On 09/19/17 11:35, Sergei Shtylyov wrote:
> On 9/19/2017 12:29 PM, Hans Verkuil wrote:
> 
 From: Hans Verkuil 

 Document the cec clock binding.

 Signed-off-by: Hans Verkuil 
 Acked-by: Rob Herring 
 ---
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
 
1 file changed, 4 insertions(+)

 diff --git 
 a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
 b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 index 06668bca7ffc..4497ae054d49 100644
 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 @@ -68,6 +68,8 @@ Optional properties:
- adi,disable-timing-generator: Only for ADV7533. Disables the internal 
 timing
  generator. The chip will rely on the sync signals in the DSI data 
 lanes,
  rather than generate its own timings for HDMI output.
 +- clocks: from common clock binding: handle to CEC clock.
>>>
>>>  It's called "phandle" in the DT speak. :-)
>>>  Are you sure the clock specifier would always be absent?
>>
>> Sorry? I don't understand the question. Did you mean: "can be absent?"?
> 
> No, you only say that there'll be the clock phandle only. The clock 
> specifier may follow the phandle for the clock devices that have 
> "#clock-cells" prop != 0.

I have to say that I just copy-and-pasted this from other bindings. Would
this be better?

- clocks: list of clock specifiers, corresponding to entries in
  the clock-names property;
- clock-names: from common clock binding: must be "cec".

Regards,

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

Re: [PATCH v2] drm: exynos: Add driver for HDMI audio interface

[Sylwester Nawrocki]

On 09/19/2017 10:30 AM, Andrzej Hajda wrote:

On 18.09.2017 18:19, Sylwester Nawrocki wrote:



diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 214fa5e..dc254b7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -40,7 +40,7 @@



+struct hdmi_audio {
+   struct platform_device *pdev;
+   struct hdmi_audio_infoframe infoframe;
+   unsigned int sample_rate;
+   unsigned int sample_width;
+   u8 enable;


Why not bool ?


Yes, I also asked myself that question after submitting the patch.

-static void hdmi_audio_init(struct hdmi_context *hdata)
+static void hdmi_audio_config(struct hdmi_context *hdata)
  {
-   u32 sample_rate, bits_per_sample;
-   u32 data_num, bit_ch, sample_frq;
-   u32 val;
+   u32 data_num, sample_freq, val;
+   u32 bit_ch = 1;

-   sample_rate = 44100;
-   bits_per_sample = 16;

-   switch (bits_per_sample) {
+   switch (hdata->audio.sample_width) {
case 20:
data_num = 2;
-   bit_ch = 1;
break;
case 24:
data_num = 3;
-   bit_ch = 1;
break;
default:
data_num = 1;
@@ -1019,7 +1034,7 @@ static void hdmi_audio_init(struct hdmi_context *hdata)
break;
}

-   hdmi_reg_acr(hdata, sample_rate);
+   hdmi_reg_acr(hdata, hdata->audio.sample_rate);

hdmi_reg_writeb(hdata, HDMI_I2S_MUX_CON, HDMI_I2S_IN_DISABLE
| HDMI_I2S_AUD_I2S | HDMI_I2S_CUV_I2S_ENABLE
@@ -1030,10 +1045,21 @@ static void hdmi_audio_init(struct hdmi_context *hdata)

hdmi_reg_writeb(hdata, HDMI_I2S_MUX_CUV, HDMI_I2S_CUV_RL_EN);

-   sample_frq = (sample_rate == 44100) ? 0 :
-   (sample_rate == 48000) ? 2 :
-   (sample_rate == 32000) ? 3 :
-   (sample_rate == 96000) ? 0xa : 0x0;
+   switch (hdata->audio.sample_rate) {
+   case 32000:
+   sample_freq = 0x3;
+   break;
+   case 48000:
+   sample_freq = 0x2;
+   break;
+   case 96000:
+   sample_freq = 0xa;
+   break;
+   case 44100:
+   default:
+   sample_freq = 0;
+   break;
+   }

hdmi_reg_writeb(hdata, HDMI_I2S_CLK_CON, HDMI_I2S_CLK_DIS);
hdmi_reg_writeb(hdata, HDMI_I2S_CLK_CON, HDMI_I2S_CLK_EN);
@@ -1067,7 +1093,7 @@ static void hdmi_audio_init(struct hdmi_context *hdata)
hdmi_reg_writeb(hdata, HDMI_I2S_CH_ST_1, HDMI_I2S_CD_PLAYER);
hdmi_reg_writeb(hdata, HDMI_I2S_CH_ST_2, HDMI_I2S_SET_SOURCE_NUM(0));
hdmi_reg_writeb(hdata, HDMI_I2S_CH_ST_3, HDMI_I2S_CLK_ACCUR_LEVEL_2
-   | HDMI_I2S_SET_SMP_FREQ(sample_frq));
+   | HDMI_I2S_SET_SMP_FREQ(sample_freq));
hdmi_reg_writeb(hdata, HDMI_I2S_CH_ST_4,
HDMI_I2S_ORG_SMP_FREQ_44_1
| HDMI_I2S_WORD_LEN_MAX24_24BITS


I am not audio expert, so maybe I miss something but I wonder if it
wouldn't be good to fill HDMI_I2S_CH_ST_* with content of
hdmi_codec_params.iec.status?
This way you can remove some magic code above, but maybe it could be
done in separate patch.


Yes, makes sense, I will try and see if it works properly with
the HDMI_I2S_CH_ST_? registers written directly with values from
the IEC status arrray.


@@ -1076,13 +1102,15 @@ static void hdmi_audio_init(struct hdmi_context *hdata)
hdmi_reg_writeb(hdata, HDMI_I2S_CH_ST_CON, HDMI_I2S_CH_STATUS_RELOAD);
  }

-static void hdmi_audio_control(struct hdmi_context *hdata, bool onoff)
+static void hdmi_audio_control(struct hdmi_context *hdata)
  {
+   bool enable = hdata->audio.enable;
+
if (hdata->dvi_mode)
return;

-   hdmi_reg_writeb(hdata, HDMI_AUI_CON, onoff ? 2 : 0);
-   hdmi_reg_writemask(hdata, HDMI_CON_0, onoff ?
+   hdmi_reg_writeb(hdata, HDMI_AUI_CON, enable ? 2 : 0);


While at it you can replace magic '2' to HDMI_AUI_CON_EVERY_VSYNC.


Changed.


+   hdmi_reg_writemask(hdata, HDMI_CON_0, enable ?
HDMI_ASP_EN : HDMI_ASP_DIS, HDMI_ASP_MASK);
  }




  static void hdmi_disable(struct drm_encoder *encoder)
  {
struct hdmi_context *hdata = encoder_to_hdmi(encoder);

-   if (!hdata->powered)
+   mutex_lock(>mutex);
+
+   if (hdata->powered) {
+   /*
+* The SFRs of VP and Mixer are updated by Vertical Sync of
+* Timing generator which is a part of HDMI so the sequence
+* to disable TV Subsystem should be as following,
+*  VP -> Mixer -> HDMI
+*
+* To achieve such sequence HDMI is disabled together with
+* HDMI PHY, via pipe clock callback.
+*/
+   mutex_unlock(>mutex);
+   

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Hans Verkuil]

On 09/19/17 11:20, Sergei Shtylyov wrote:
> Hello!
> 
> On 9/19/2017 10:33 AM, Hans Verkuil wrote:
> 
>> From: Hans Verkuil 
>>
>> Document the cec clock binding.
>>
>> Signed-off-by: Hans Verkuil 
>> Acked-by: Rob Herring 
>> ---
>>   Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> index 06668bca7ffc..4497ae054d49 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> @@ -68,6 +68,8 @@ Optional properties:
>>   - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
>> timing
>> generator. The chip will rely on the sync signals in the DSI data lanes,
>> rather than generate its own timings for HDMI output.
>> +- clocks: from common clock binding: handle to CEC clock.
> 
> It's called "phandle" in the DT speak. :-)
> Are you sure the clock specifier would always be absent?

Sorry? I don't understand the question. Did you mean: "can be absent?"?

Regards,

Hans

> 
>> +- clock-names: from common clock binding: must be "cec".
>>   
>>   Required nodes:
>>   
> [...]
> 
> MBR, Sergei
> 

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

[Bug 101768] [HSW] [IGT] kms_cursor_legacy@flip-vs-cursor-busy-crc-* produces a GPU hang

[bugzilla-daemon]

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

Maarten Lankhorst  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |b...@mblankhorst.nl
   |.org|
 Status|NEW |ASSIGNED

--- Comment #6 from Maarten Lankhorst  ---
Quite likely same issue as 102259, could you test the patch posted there?

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

Re: [PATCH v1 1/3] media: vsp1: Prevent resuming DRM pipelines

[Laurent Pinchart]

Hi Kieran,

On Monday, 18 September 2017 03:04:13 EEST Kieran Bingham wrote:
> On 15/09/17 17:58, Laurent Pinchart wrote:
> > On Friday, 15 September 2017 19:42:05 EEST Kieran Bingham wrote:
> >> DRM pipelines utilising the VSP must stop all frame processing as part
> >> of the suspend operation to ensure the hardware is idle. Upon resume,
> >> the pipeline must not be started until the DU performs an atomic flush
> >> to restore the hardware configuration and state.
> >> 
> >> Therefore the vsp1_pipeline_resume() call is not needed for DRM
> >> pipelines, and we can disable it in this instance.
> > 
> > Being familiar with the issue I certainly understand the commit message,
> > but I think it can be a bit confusing to a reader not familiar to the
> > VSP/DU. How about something similar to the following ?
> > 
> > "When used as part of a display pipeline, the VSP is stopped and restarted
> > explicitly by the DU from its suspend and resume handlers. There is thus
> > no need to stop or restart pipelines in the VSP suspend and resume
> > handlers."
> 
> That's fine with me.
> 
> >> CC: linux-me...@vger.kernel.org
> >> 
> >> Signed-off-by: Kieran Bingham 
> >> ---
> >> 
> >>  drivers/media/platform/vsp1/vsp1_drv.c | 8 +++-
> >>  1 file changed, 7 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
> >> b/drivers/media/platform/vsp1/vsp1_drv.c index 962e4c304076..7604c7994c74
> >> 100644
> >> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> >> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> >> @@ -582,7 +582,13 @@ static int __maybe_unused vsp1_pm_resume(struct
> >> device
> >> *dev) struct vsp1_device *vsp1 = dev_get_drvdata(dev);
> >> 
> >>pm_runtime_force_resume(vsp1->dev);
> >> 
> >> -  vsp1_pipelines_resume(vsp1);
> >> +
> >> +  /*
> >> +   * DRM pipelines are stopped before suspend, and will be resumed after
> >> +   * the DRM subsystem has reconfigured its pipeline with an atomic flush
> >> +   */
> > 
> > I would also adapt this comment similarly to the commit message.
> > 
> >> +  if (!vsp1->drm)
> >> +  vsp1_pipelines_resume(vsp1);
> > 
> > Should we do the same in vsp1_pm_suspend() ? I know it shouldn't be
> > strictly needed at the moment as vsp1_pipelines_suspend() should be a
> > no-op when the pipelines are already stopped, but a symmetrical
> > implementation sounds better to me.
> 
> I'm OK with that, it's not needed - but it doesn't hurt to be symmetrical.
> 
> (Updated locally for a v1.1 repost or such)

I've taken patches 2/3 and 3/3 in my tree so feel free to report 1/3 only.

> > I also wonder whether the check shouldn't be moved inside the
> > vsp1_pipelines_suspend() and vsp1_pipelines_resume() functions as we will
> > likely need to handle suspend/resume of display pipelines when adding
> > writeback support, but we could do so later.
> 
> I'll have to retest the writeback implementation - but I think that has got
> quite stale now anyway and will need some rework.

Agreed, I don't expect it to work out of the box. We can move the check later 
when rebasing the writeback patches.

> >>return 0;
> >>  
> >>  }

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2] drm: exynos: Add driver for HDMI audio interface

[Andrzej Hajda]

On 18.09.2017 18:19, Sylwester Nawrocki wrote:
> The hdmi-codec interface added in this patch is required to properly
> support HDMI audio. Currently the audio part of the SoC internal
> HDMI transmitter is configured with fixed values, which makes HDMI
> audio working by chance, only on boards having an external audio
> codec connected in parallel with the HDMI audio transmitter's input
> I2S interface.
>
> Signed-off-by: Sylwester Nawrocki 
> ---
> Patch tested on Odroid XU3 and Odroid XU4 with Ubuntu 14.04.
>
> Changes since v1:
>  - rebased onto v4.14-rc1 and adapted locking
>
> Changes since RFC version:
>  - fixed hdmi-codec locking issue
>  - added a comment documenting struct hdmi_contex::mutex
> ---
>  drivers/gpu/drm/exynos/Kconfig   |   1 +
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 253 
> +--
>  2 files changed, 210 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 305dc3d..5a7c9d8 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -3,6 +3,7 @@ config DRM_EXYNOS
>   depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS || 
> ARCH_MULTIPLATFORM)
>   select DRM_KMS_HELPER
>   select VIDEOMODE_HELPERS
> + select SND_SOC_HDMI_CODEC if SND_SOC
>   help
> Choose this option if you have a Samsung SoC EXYNOS chipset.
> If M is selected the module will be called exynosdrm.
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 214fa5e..dc254b7 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -40,7 +40,7 @@
>  #include 
>  #include 
>  #include 
> -
> +#include 
>  #include 
>
>  #include 
> @@ -111,12 +111,19 @@ struct hdmi_driver_data {
>   struct string_array_spec clk_muxes;
>  };
>
> +struct hdmi_audio {
> + struct platform_device *pdev;
> + struct hdmi_audio_infoframe infoframe;
> + unsigned int sample_rate;
> + unsigned int sample_width;
> + u8 enable;

Why not bool ?

> +};
> +
>  struct hdmi_context {
>   struct drm_encoder  encoder;
>   struct device   *dev;
>   struct drm_device   *drm_dev;
>   struct drm_connectorconnector;
> - boolpowered;
>   booldvi_mode;
>   struct delayed_work hotplug_work;
>   struct drm_display_mode current_mode;
> @@ -137,6 +144,11 @@ struct hdmi_context {
>   struct regulator*reg_hdmi_en;
>   struct exynos_drm_clk   phy_clk;
>   struct drm_bridge   *bridge;
> +
> + /* mutex protecting subsequent fields below */
> + struct mutexmutex;
> + struct hdmi_audio   audio;
> + boolpowered;
>  };
>
>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
> @@ -768,6 +780,22 @@ static int hdmi_clk_set_parents(struct hdmi_context 
> *hdata, bool to_phy)
>   return ret;
>  }
>
> +static int hdmi_audio_infoframe_apply(struct hdmi_context *hdata)
> +{
> + struct hdmi_audio_infoframe *infoframe = >audio.infoframe;
> + u8 buf[HDMI_INFOFRAME_SIZE(AUDIO)];
> + int len;
> +
> + len = hdmi_audio_infoframe_pack(infoframe, buf, sizeof(buf));
> + if (len < 0)
> + return len;
> +
> + hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
> + hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, len);
> +
> + return 0;
> +}
> +
>  static void hdmi_reg_infoframes(struct hdmi_context *hdata)
>  {
>   union hdmi_infoframe frm;
> @@ -805,15 +833,7 @@ static void hdmi_reg_infoframes(struct hdmi_context 
> *hdata)
>   hdmi_reg_write_buf(hdata, HDMI_VSI_DATA(0), buf + 3, ret - 3);
>   }
>
> - ret = hdmi_audio_infoframe_init();
> - if (!ret) {
> - frm.audio.channels = 2;
> - ret = hdmi_audio_infoframe_pack(, buf, sizeof(buf));
> - }
> - if (ret > 0) {
> - hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
> - hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, ret);
> - }
> + hdmi_audio_infoframe_apply(hdata);
>  }
>
>  static enum drm_connector_status hdmi_detect(struct drm_connector *connector,
> @@ -995,23 +1015,18 @@ static void hdmi_reg_acr(struct hdmi_context *hdata, 
> u32 freq)
>   hdmi_reg_writeb(hdata, HDMI_ACR_CON, 4);
>  }
>
> -static void hdmi_audio_init(struct hdmi_context *hdata)
> +static void hdmi_audio_config(struct hdmi_context *hdata)
>  {
> - u32 sample_rate, bits_per_sample;
> - u32 data_num, bit_ch, sample_frq;
> - u32 val;
> + u32 data_num, sample_freq, val;
> + u32 bit_ch = 1;
>
> - sample_rate = 44100;
> - bits_per_sample = 16;
>
> - switch (bits_per_sample) {
> + 

[Bug 98520] System randomly crashes / freezes while playing certain games

[bugzilla-daemon]

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

Jack  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #39 from Jack  ---
Help, I have a XFX RX 460, with ubuntu 17.04 latest updates and a fresh
install.
My system still crashes randomly when playing games, and due to a lack of
skills I am unable to diagnose my issue.

Any ideas?

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

Re: [PATCH] drm: add backwards compatibility support for drm_kms_helper.edid_firmware

[Jani Nikula]

On Mon, 18 Sep 2017, Ville Syrjälä  wrote:
> On Mon, Sep 18, 2017 at 09:20:03PM +0300, Jani Nikula wrote:
>> Add drm_kms_helper.edid_firmware module parameter with param ops hooks
>> to set drm.edid_firmware instead, for backwards compatibility.
>> 
>> Suggested-by: Ville Syrjälä 
>> Cc: Abdiel Janulgue 
>> Cc: Daniel Vetter 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/drm_edid_load.c | 16 
>>  drivers/gpu/drm/drm_kms_helper_common.c | 28 
>>  include/drm/drm_edid.h  |  2 ++
>>  3 files changed, 46 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_edid_load.c 
>> b/drivers/gpu/drm/drm_edid_load.c
>> index 1c0495acf341..a4915099aaa9 100644
>> --- a/drivers/gpu/drm/drm_edid_load.c
>> +++ b/drivers/gpu/drm/drm_edid_load.c
>> @@ -31,6 +31,22 @@ module_param_string(edid_firmware, edid_firmware, 
>> sizeof(edid_firmware), 0644);
>>  MODULE_PARM_DESC(edid_firmware, "Do not probe monitor, use specified EDID 
>> blob "
>>  "from built-in data or /lib/firmware instead. ");
>>  
>> +/* Use only for backward compatibility with drm_kms_helper.edid_firmware */
>> +int __drm_set_edid_firmware_path(const char *path)
>> +{
>> +scnprintf(edid_firmware, sizeof(edid_firmware), "%s", path);
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(__drm_set_edid_firmware_path);
>> +
>> +/* Use only for backward compatibility with drm_kms_helper.edid_firmware */
>> +int __drm_get_edid_firmware_path(char *buf, size_t bufsize)
>> +{
>> +return scnprintf(buf, bufsize, "%s", edid_firmware);
>
> I guess these could just use strlcpy() or something.

strlcpy() returns strlen(source) while scnprintf() returns the number of
chars written to destination (minus the terminating NUL), and that's
what the kernel param ops expect. I took this directly from
kernel/params.c, and preferred to use the same for both get and set.

>
>> +}
>> +EXPORT_SYMBOL(__drm_get_edid_firmware_path);
>> +
>>  #define GENERIC_EDIDS 6
>>  static const char * const generic_edid_name[GENERIC_EDIDS] = {
>>  "edid/800x600.bin",
>> diff --git a/drivers/gpu/drm/drm_kms_helper_common.c 
>> b/drivers/gpu/drm/drm_kms_helper_common.c
>> index 6e35a56a6102..5051c3aa4d5d 100644
>> --- a/drivers/gpu/drm/drm_kms_helper_common.c
>> +++ b/drivers/gpu/drm/drm_kms_helper_common.c
>> @@ -26,6 +26,7 @@
>>   */
>>  
>>  #include 
>> +#include 
>>  
>>  #include "drm_crtc_helper_internal.h"
>>  
>> @@ -33,6 +34,33 @@ MODULE_AUTHOR("David Airlie, Jesse Barnes");
>>  MODULE_DESCRIPTION("DRM KMS helper");
>>  MODULE_LICENSE("GPL and additional rights");
>>  
>> +#if IS_ENABLED(CONFIG_DRM_LOAD_EDID_FIRMWARE)
>> +
>> +/* Backward compatibility for drm_kms_helper.edid_firmware */
>> +static int edid_firmware_set(const char *val, const struct kernel_param *kp)
>> +{
>> +DRM_NOTE("drm_kms_firmware.edid_firmware is deprecated, please use 
>> drm.edid_firmware intead.\n");
>> +
>> +return __drm_set_edid_firmware_path(val);
>> +}
>> +
>> +static int edid_firmware_get(char *buffer, const struct kernel_param *kp)
>> +{
>> +return __drm_get_edid_firmware_path(buffer, PAGE_SIZE);
>> +}
>> +
>> +const struct kernel_param_ops edid_firmware_ops = {
>> +.set = edid_firmware_set,
>> +.get = edid_firmware_get,
>> +};
>> +
>> +module_param_cb(edid_firmware, _firmware_ops, NULL, 0644);
>
> Do we want the __parm_check thing here? Looks like it's just some kind of
> compile time type check though so not critical by any means.

It's useless here, because we don't actually store the parameter here,
and just pass NULL.

> Otherwise looks technically correct so
> Reviewed-by: Ville Syrjälä 

Thanks,
Jani.

>
>> +__MODULE_PARM_TYPE(edid_firmware, "charp");
>> +MODULE_PARM_DESC(edid_firmware,
>> + "DEPRECATED. Use drm.edid_firmware module parameter instead.");
>> +
>> +#endif
>> +
>>  static int __init drm_kms_helper_init(void)
>>  {
>>  int ret;
>> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>> index 1e1908a6b1d6..6f35909b8add 100644
>> --- a/include/drm/drm_edid.h
>> +++ b/include/drm/drm_edid.h
>> @@ -341,6 +341,8 @@ int drm_av_sync_delay(struct drm_connector *connector,
>>  
>>  #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
>>  struct edid *drm_load_edid_firmware(struct drm_connector *connector);
>> +int __drm_set_edid_firmware_path(const char *path);
>> +int __drm_get_edid_firmware_path(char *buf, size_t bufsize);
>>  #else
>>  static inline struct edid *
>>  drm_load_edid_firmware(struct drm_connector *connector)
>> -- 
>> 2.11.0

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

[PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Hans Verkuil]

From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
 - adi,disable-timing-generator: Only for ADV7533. Disables the internal timing
   generator. The chip will rely on the sync signals in the DSI data lanes,
   rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.
+- clock-names: from common clock binding: must be "cec".
 
 Required nodes:
 
@@ -89,6 +91,8 @@ Example
reg = <39>;
interrupt-parent = <>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+   clocks = <_clock>;
+   clock-names = "cec";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
-- 
2.14.1

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

[PATCHv2 2/2] drm: adv7511/33: add HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

Add support for HDMI CEC to the drm adv7511/adv7533 drivers.

The CEC registers that we need to use are identical for both drivers,
but they appear at different offsets in the register map.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/bridge/adv7511/Kconfig   |   8 +
 drivers/gpu/drm/bridge/adv7511/Makefile  |   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511.h |  43 +++-
 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 337 +++
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 116 +++--
 drivers/gpu/drm/bridge/adv7511/adv7533.c |  38 +--
 6 files changed, 485 insertions(+), 58 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index 2fed567f9943..592b9d2ec034 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -21,3 +21,11 @@ config DRM_I2C_ADV7533
default y
help
  Support for the Analog Devices ADV7533 DSI to HDMI encoder.
+
+config DRM_I2C_ADV7511_CEC
+   bool "ADV7511/33 HDMI CEC driver"
+   depends on DRM_I2C_ADV7511
+   select CEC_CORE
+   default y
+   help
+ When selected the HDMI transmitter will support the CEC feature.
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 5ba675534f6e..5bb384938a71 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,4 +1,5 @@
 adv7511-y := adv7511_drv.o
 adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
 adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index fe18a5d2d84b..543a5eb91624 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -195,6 +195,25 @@
 #define ADV7511_PACKET_GM(x)   ADV7511_PACKET(5, x)
 #define ADV7511_PACKET_SPARE(x)ADV7511_PACKET(6, x)
 
+#define ADV7511_REG_CEC_TX_FRAME_HDR   0x00
+#define ADV7511_REG_CEC_TX_FRAME_DATA0 0x01
+#define ADV7511_REG_CEC_TX_FRAME_LEN   0x10
+#define ADV7511_REG_CEC_TX_ENABLE  0x11
+#define ADV7511_REG_CEC_TX_RETRY   0x12
+#define ADV7511_REG_CEC_TX_LOW_DRV_CNT 0x14
+#define ADV7511_REG_CEC_RX_FRAME_HDR   0x15
+#define ADV7511_REG_CEC_RX_FRAME_DATA0 0x16
+#define ADV7511_REG_CEC_RX_FRAME_LEN   0x25
+#define ADV7511_REG_CEC_RX_ENABLE  0x26
+#define ADV7511_REG_CEC_RX_BUFFERS 0x4a
+#define ADV7511_REG_CEC_LOG_ADDR_MASK  0x4b
+#define ADV7511_REG_CEC_LOG_ADDR_0_1   0x4c
+#define ADV7511_REG_CEC_LOG_ADDR_2 0x4d
+#define ADV7511_REG_CEC_CLK_DIV0x4e
+#define ADV7511_REG_CEC_SOFT_RESET 0x50
+
+#define ADV7533_REG_CEC_OFFSET 0x70
+
 enum adv7511_input_clock {
ADV7511_INPUT_CLOCK_1X,
ADV7511_INPUT_CLOCK_2X,
@@ -297,6 +316,8 @@ enum adv7511_type {
ADV7533,
 };
 
+#define ADV7511_MAX_ADDRS 3
+
 struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
@@ -343,15 +364,27 @@ struct adv7511 {
 
enum adv7511_type type;
struct platform_device *audio_pdev;
+
+   struct cec_adapter *cec_adap;
+   u8   cec_addr[ADV7511_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+   struct clk *cec_clk;
+   u32 cec_clk_freq;
 };
 
+#ifdef CONFIG_DRM_I2C_ADV7511_CEC
+int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
+unsigned int offset);
+void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
+#endif
+
 #ifdef CONFIG_DRM_I2C_ADV7533
 void adv7533_dsi_power_on(struct adv7511 *adv);
 void adv7533_dsi_power_off(struct adv7511 *adv);
 void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode *mode);
 int adv7533_patch_registers(struct adv7511 *adv);
-void adv7533_uninit_cec(struct adv7511 *adv);
-int adv7533_init_cec(struct adv7511 *adv);
+int adv7533_patch_cec_registers(struct adv7511 *adv);
 int adv7533_attach_dsi(struct adv7511 *adv);
 void adv7533_detach_dsi(struct adv7511 *adv);
 int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
@@ -374,11 +407,7 @@ static inline int adv7533_patch_registers(struct adv7511 
*adv)
return -ENODEV;
 }
 
-static inline void adv7533_uninit_cec(struct adv7511 *adv)
-{
-}
-
-static inline int adv7533_init_cec(struct adv7511 *adv)
+static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
 {
return -ENODEV;
 }
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
new file mode 100644
index ..b33d730e4d73
--- /dev/null
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
@@ -0,0 +1,337 @@
+/*
+ * 

[PATCHv2 0/2] drm/bridge/adv7511: add CEC support

[Hans Verkuil]

From: Hans Verkuil 

I should have posted this a month ago, but I completely forgot about
it. Apologies for that.

This patch series adds CEC support to the drm adv7511/adv7533 drivers.

I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).

I only have the Koelsch board to test with, but it looks like other
R-Car boards use the same adv7511. It would be nice if someone can
add CEC support to the other R-Car boards as well. The main thing
to check is if they all use the same 12 MHz fixed CEC clock source.

Anyone who wants to test this will need the CEC utilities that
are part of the v4l-utils git repository:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh
./configure
make
sudo make install

Now configure the CEC adapter as a Playback device:

cec-ctl --playback

Discover other CEC devices:

cec-ctl -S

Regards,

Hans

Changes since v1:
- Incorporate Archit's comments:
use defines for irq masks
combine the adv7511/33 regmap_configs
adv7511_cec_init now handles dt parsing & CEC registration
- Use the new (4.14) CEC_CAP_DEFAULTS define

Hans Verkuil (2):
  dt-bindings: adi,adv7511.txt: document cec clock
  drm: adv7511/33: add HDMI CEC support

 .../bindings/display/bridge/adi,adv7511.txt|   4 +
 drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
 drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  43 ++-
 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 337 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 116 ++-
 drivers/gpu/drm/bridge/adv7511/adv7533.c   |  38 +--
 7 files changed, 489 insertions(+), 58 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c

-- 
2.14.1

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

[Bug 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

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

--- Comment #5 from Mike Lothian  ---
Created attachment 134327
  --> https://bugs.freedesktop.org/attachment.cgi?id=134327=edit
Xorg.0.log

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

[Bug 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 Attachment #133715|0   |1
is obsolete||

--- Comment #4 from Mike Lothian  ---
Created attachment 134326
  --> https://bugs.freedesktop.org/attachment.cgi?id=134326=edit
Dmesg

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