Re: [PATCH v3 4/6] drm/rockchip/dsi: add dual mipi channel support

[Archit Taneja]

On 10/25/2017 01:34 PM, Sean Paul wrote:

On Wed, Oct 25, 2017 at 11:51:01AM +0800, Nickey Yang wrote:

This patch add dual mipi channel support:
1.add definition of dsi1 register and grf operation.
2.dsi0 and dsi1 will work in master and slave mode
when driving dual mipi panel.

Signed-off-by: Nickey Yang 
---


In the last revision, I asked you to provide changelog between revisions,
*please* do this. You received review on the last version and a bunch of the
feedback hasn't been taken into account with no explanation as to why. Please go
back to the last version, read the reviews that people were generous enough to
give and either fix the code or explain why you're not.


  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 377 
  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 +
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   1 +
  5 files changed, 279 insertions(+), 105 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 589b420..25e7b77 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c





+static int rockchip_dsi_dual_channel_probe(struct dw_mipi_dsi *dsi)
+{
+   struct device_node *np;
+   struct platform_device *secondary;
+
+   np = of_parse_phandle(dsi->dev->of_node, "rockchip,dual-channel", 0);
+   if (np) {
+   secondary = of_find_device_by_node(np);
+   dsi->slave = platform_get_drvdata(secondary);
+   of_node_put(np);
+
+   if (!dsi->slave)
+   return -EPROBE_DEFER;


Archit asked you not to do this in the previous review.


I've replied with some more details to the patch which adds this in the DT
binding doc.

Thanks,
Archit




+
+   dsi->slave->master = dsi;
+   }
+
+   return 0;
+}





--
1.9.1





--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

[Archit Taneja]

On 10/25/2017 09:21 AM, 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..a2bea22 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: phandle to a 2nd DSI channel, useful as a slave
+channel when driving a panel which needs 2 DSI links.

The example below is how dual DSI bindings could look like. Let me know what
you think of it.

If both DSI outputs drive the same device (i.e, point to the same panel DT
node), then I think it's reasonable enough to assume that the DSIs are
operating in a 'dual-channel' mode. That being said, we still need DT to
describe which of the DSIs generates the clock for both the channels. This
is done with the 'clock-master' DT binding.

Thanks,
Archit

mipi_dsi: mipi@ff96 {
...
...

clock-master;   /* implies that this DSI instance drivers the clock
 * for both the DSIs.
 */

ports {
mipi_in: port {
...
...
};

/* add extra output ports for both DSIs */
mipi_out: port {
mipi_panel_out: endpoint {
remote-endpoint = <_in_channel0>;
};
};
};

panel {
...
...
/*
 * panel node can describe its input ports, if both the DSIs 
output
 * ports are connected to the same device (i.e, the same DSI 
panel),
 * we can assume that the DSIs need to operate in dual DSI mode
 */
ports {
...
port@0 {
panel_in_channel0: endpoint {
remote-endpoint = <_panel_out>;
};
};

port@1 {
panel_in_channel1: endpoint {
remote-endpoint = <_panel_out>;
};

};
};
};
};


mipi_dsi1: mipi@ff968000 {
...
...

ports {
mipi1_in: port {
...
...
};

mipi1_out: port {
mipi1_panel_out: endpoint {
remote-endpoint = <_in_channel1>;
};
};
};
};

  
  [1] Documentation/devicetree/bindings/clock/clock-bindings.txt

  [2] Documentation/devicetree/bindings/media/video-interfaces.txt



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103370] `DRI_PRIME=1 glxgears -info` halts the system with Intel Graphics [8086:5917] + AMD Graphics [1002:6665].

[bugzilla-daemon]

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

--- Comment #22 from Shih-Yuan Lee  ---
(In reply to Mike Lothian from comment #19)
> You have to blacklist radeon to use amdgpu as both modules try and claim the
> device

After I blacklist radeon, there is no AMD graphics provider from `xrandr
--listproviders`.

[1.937326] amdgpu :01:00.0: enabling device ( -> 0003)
[1.937633] amdgpu :01:00.0: SI support provided by radeon.
[1.937635] amdgpu :01:00.0: Use radeon.si_support=0 amdgpu.si_support=1
to override.

After I use 'radeon.si_support=0 amdgpu.si_support=1', X window system can not
start up.

-- 
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 103370] `DRI_PRIME=1 glxgears -info` halts the system with Intel Graphics [8086:5917] + AMD Graphics [1002:6665].

[bugzilla-daemon]

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

--- Comment #21 from Shih-Yuan Lee  ---
Created attachment 135049
  --> https://bugs.freedesktop.org/attachment.cgi?id=135049=edit
blacklist radeon 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 103370] `DRI_PRIME=1 glxgears -info` halts the system with Intel Graphics [8086:5917] + AMD Graphics [1002:6665].

[bugzilla-daemon]

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

--- Comment #20 from Shih-Yuan Lee  ---
Created attachment 135048
  --> https://bugs.freedesktop.org/attachment.cgi?id=135048=edit
blacklist radeon 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

Re: [PATCH v3 3/6] drm/rockchip/dsi: correct Feedback divider setting

[Archit Taneja]

Hi,

On 10/26/2017 06:39 AM, Brian Norris wrote:

On Wed, Oct 25, 2017 at 03:57:19AM -0400, Sean Paul wrote:

Archit asked a question about moving to
dw-mipi-dsi


That question made me think though: this approach seems backwards. It
seems like someone did copy/paste/fork, and then we're asking the
authors of the original driver to un-fork? It seems like this should
happen the other way around -- those trying to support a new incarnation
should have looked to try to abstract the original driver for their
uses first.


Yes, ST wanted to replicate rockchip's version of the mipi DSI driver and
put it in their folder. If they did that, their KMS driver would have been
the third driver to implement a third instance of the DW DSI controller driver.
Hisilicon and Rockchip being the other 2.

It was either that or attempt at a common DSI DW bridge driver. I suggested
the latter.

The ST guys have abstracted out the PHY pieces, which they knew varied between
rockchip and ST. Ideally, they should have also tried to create a RFC patch to
make the rockchip driver use the bridge too. But they didn't do that, and
the rockchip or hisilicon people were interested in even looking at it,
even after I CC'ed them.



IIUC, that's exactly what Rockchip did for much of their Analogix eDP
code -- they reworked the Exynos DP driver to split common Analogix code
from any Exynos-specific bits.


I get that. I had hoped either ST or Rockchip guys would have done the similar
thing, but no one volunteered.



And actually, the current stuff in
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c is completely unused. It
exports some functions, but I see no users of it. Is that intended? Is


The ST kms driver uses it:

drivers/gpu/drm/stm/dw_mipi_dsi-stm.c


somebody already working on refactoring existing Rockchip code to use
this?


I don't know. If rockchip isn't interested in doing it, we can check with
Philippe from ST if he can try creating a RFC that converts the rockchip
driver to use the dw-mipi-dsi driver.

Thanks,
Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu drm-next-4.15

[Alex Deucher]

Hi Dave,

Just a few fixes for 4.15.

The following changes since commit 282dc8322a95b5c6a246fc781d89e5930821d486:

  Merge tag 'drm-intel-next-2017-10-12' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2017-10-20 10:56:10 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.15

for you to fetch changes up to 4a0144bfc6df1f7a89a04a3e8662f1f4375eb1fe:

  drm/amd/amdgpu: Remove workaround for suspend/resume in uvd7 (2017-10-25 
23:09:40 -0400)


Christian König (2):
  drm/amdgpu: minor cleanup for amdgpu_ttm_bind
  drm/amdgpu: don't flush the TLB before initializing GART

Dan Carpenter (1):
  drm/amd/powerplay: fix amd_powerplay_reset()

Dave Airlie (1):
  amdgpu: add padding to the fence to handle ioctl.

Eric Huang (2):
  drm/amd/powerplay: add one smc message for Vega10
  drm/amd/powerplay: fix performance drop on Vega10

Evan Quan (2):
  drm/amd/powerplay: retrieve the real-time coreClock values
  drm/amdgpu/psp: prevent page fault by checking write_frame address(v4)

Monk Liu (3):
  drm/amdgpu/sriov:now must reinit psp
  drm/amdgpu:fix vf_error_put
  drm/amdgpu:fix wb_clear

Tom St Denis (1):
  drm/amd/amdgpu: Remove workaround for suspend/resume in uvd7

pding (1):
  drm/amdgpu: merge bios post checking functions

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 67 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c   | 13 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vf_error.c   |  7 ++-
 drivers/gpu/drm/amd/amdgpu/psp_v10_0.c | 14 -
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c  | 14 -
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  | 16 ++
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c  |  2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 28 ++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  9 +++
 drivers/gpu/drm/amd/powerplay/inc/vega10_ppsmc.h   |  3 +-
 include/uapi/drm/amdgpu_drm.h  |  1 +
 12 files changed, 95 insertions(+), 82 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm: drm_vblank_cleanup: WARN when refcount > 0

[PrasannaKumar Muralidharan]

Hi Chris,

Sorry I missed adding you in to list while sending the vblank refcount
patch. Hope you saw that.

On 25-Oct-2017 9:55 PM, "PrasannaKumar Muralidharan" <
prasannatsmku...@gmail.com> wrote:

Warn when refcount > 0 in drm_vblank_cleanup.

Signed-off-by: PrasannaKumar Muralidharan 
---
Changes in v3:
* Dropped i915 patch that is used for testing this.

No changes in v2.

 drivers/gpu/drm/drm_vblank.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 70f2b95..3e61aeb 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -405,6 +405,8 @@ void drm_vblank_cleanup(struct drm_device *dev)
for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
struct drm_vblank_crtc *vblank = >vblank[pipe];

+   WARN_ON(atomic_read(>refcount) > 0);
+
WARN_ON(READ_ONCE(vblank->enabled) &&
drm_core_check_feature(dev, DRIVER_MODESET));

--
2.10.0


As you anticipated Intel CI found that this patch triggers the non zero
vblank refcount warning on module unload.

Please advice on what to do next. Should I don't think I have to do
something for this patch. If that's not the case please let me know what to
do from my side for this patch.

Note: Replying from an Android device. Please forgive typos.

Thanks and regards,
PrasannaKumar
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] exynos-drm-next

[Inki Dae]

Hi Dave,

   Improving Exynos DRM HDMI and Mixer drivers and also adding
   HDMI audio support.

   Please kindly let me know if there is any problem.

   Ps. we are reviewing IPP v2 driver[1] which controls post processor devices
   such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request
   git pull one more time after review.

Thanks,
Inki Dae

[1] https://www.spinics.net/lists/linux-samsung-soc/msg60981.html
This is a link to v3 patch set and now v4 has been posted.

The following changes since commit 62884cd386b876638720ef88374b31a84ca7ee5f:

  drm: Add four ioctls for managing drm mode object leases [v7] (2017-10-25 
16:31:30 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-for-v4.15

for you to fetch changes up to 691da76f9c90fa618682b88f386b6a1ef304666e:

  drm: exynos: Add driver for HDMI audio interface (2017-10-26 09:06:34 +0900)


- Improved HDMI and Mixer drivers
  . It moves mode setup and plane update code to commit
like other CRTC drivers
  . It makes mode commit to be called in enable callback only one time
  . some cleanup and fixup to HDMI and Mixer drivers.
  . It adds 1024x768, 1280x1024 and 1366x768 modes support
- Added HDMI audio interface driver
  . As of now, HDMI audio worked on boards with external audio codec connected
in parallel with the HDMI audio transmitter's I2S interface.
This patch is required to support HDMI audio properly.


Andrzej Hajda (10):
  drm/exynos/mixer: abstract out output mode setup code
  drm/exynos/mixer: move mode commit to enable callback
  drm/exynos/mixer: move resolution configuration to single function
  drm/exynos/mixer: fix mode validation code
  drm/exynos/mixer: remove mixer_resources sub-structure
  drm/exynos/hdmi: remove redundant mode field
  drm/exynos: add mode_fixup callback to exynos_drm_crtc_ops
  drm/exynos/mixer: pass actual mode on MIXER to encoder
  drm/exynos/hdmi: quirk for support mode timings conversion
  drm/exynos/mixer: enable support for 1024x768 and 1280x1024 modes

Daniel Drake (1):
  drm/exynos/hdmi: add 85.5MHz pixel clock for v14 HDMI PHY

Sylwester Nawrocki (1):
  drm: exynos: Add driver for HDMI audio interface

 drivers/gpu/drm/exynos/Kconfig   |   1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |  15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   3 +
 drivers/gpu/drm/exynos/exynos_hdmi.c | 310 +++--
 drivers/gpu/drm/exynos/exynos_mixer.c| 460 ---
 drivers/gpu/drm/exynos/regs-hdmi.h   |   8 +-
 6 files changed, 476 insertions(+), 321 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103130] Mesa from git causes games to crash mid-play

[bugzilla-daemon]

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

Adam  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #8 from Adam  ---
LLVM is certainly the issue. I held back that update, and I didn't get the
error. Then pushed the update and received it again going from LLVM 5.0 to LLVM
6.0. However, now the issue seems to be resolved completely. Not quite sure
considering no update was pushed.

-- 
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 v3 3/6] drm/rockchip/dsi: correct Feedback divider setting

[Brian Norris]

On Wed, Oct 25, 2017 at 03:57:19AM -0400, Sean Paul wrote:
> Archit asked a question about moving to
> dw-mipi-dsi

That question made me think though: this approach seems backwards. It
seems like someone did copy/paste/fork, and then we're asking the
authors of the original driver to un-fork? It seems like this should
happen the other way around -- those trying to support a new incarnation
should have looked to try to abstract the original driver for their
uses first.

IIUC, that's exactly what Rockchip did for much of their Analogix eDP
code -- they reworked the Exynos DP driver to split common Analogix code
from any Exynos-specific bits.

And actually, the current stuff in
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c is completely unused. It
exports some functions, but I see no users of it. Is that intended? Is
somebody already working on refactoring existing Rockchip code to use
this?

Brian
___
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 goes
drm-intel-fixes-2017-10-25:

only 1 fix for stable:

- fix perf enable/disable ioctls for 32bits (lionel)
The following changes since commit bb176f67090ca54869fc1262c913aa69d2ede070:

  Linux 4.14-rc6 (2017-10-23 06:49:47 -0400)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2017-10-25

for you to fetch changes up to 7277f755048da562eb2489becacd38d0d05e1e06:

  drm/i915/perf: fix perf enable/disable ioctls with 32bits userspace 
(2017-10-25 08:16:13 -0700)


drm-intel-fixes-2017-10-25:

only 1 fix for stable:

- fix perf enable/disable ioctls for 32bits (lionel)


Lionel Landwerlin (1):
  drm/i915/perf: fix perf enable/disable ioctls with 32bits userspace

 drivers/gpu/drm/i915/i915_perf.c | 4 
 1 file changed, 4 insertions(+)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vgem: Fix vgem_init to get drm device avaliable.

[Deepak Sharma]

From: Deepak Sharma 

Modify vgem_init to take platform dev as parent in drm_dev_init.
This will make drm device available at "/sys/devices/platform/vgem"
in x86 chromebook.

Signed-off-by: Deepak Sharma 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index c938af8c40cf..17e2eafc62b8 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -471,31 +471,30 @@ static int __init vgem_init(void)
if (!vgem_device)
return -ENOMEM;
 
-   ret = drm_dev_init(_device->drm, _driver, NULL);
-   if (ret)
-   goto out_free;
-
vgem_device->platform =
platform_device_register_simple("vgem", -1, NULL, 0);
if (IS_ERR(vgem_device->platform)) {
ret = PTR_ERR(vgem_device->platform);
-   goto out_fini;
+   goto out_free;
}
 
dma_coerce_mask_and_coherent(_device->platform->dev,
 DMA_BIT_MASK(64));
+   ret = drm_dev_init(_device->drm, _driver, 
_device->platform->dev);
+   if (ret)
+   goto out_unregister;
 
/* Final step: expose the device/driver to userspace */
ret  = drm_dev_register(_device->drm, 0);
if (ret)
-   goto out_unregister;
+   goto out_fini;
 
return 0;
 
-out_unregister:
-   platform_device_unregister(vgem_device->platform);
 out_fini:
drm_dev_fini(_device->drm);
+out_unregister:
+   platform_device_unregister(vgem_device->platform);
 out_free:
kfree(vgem_device);
return ret;
-- 
2.14.2

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

Re: [PATCH] drm/amd/powerplay: fix amd_powerplay_reset()

[Alex Deucher]

On Tue, Oct 24, 2017 at 5:44 AM, Dan Carpenter  wrote:
> We accidentally inverted an if statement and turned amd_powerplay_reset()
> into a no-op.
>
> Fixes: ae97988fc89e ("drm/amd/powerplay: tidy up ret checks in 
> amd_powerplay.c (v3)")
> Signed-off-by: Dan Carpenter 

Applied.  thanks!

Alex

> ---
> IMHO, tidying unreadable double negatives is tricky and error prone but
> still worth it in the long run.
>
> diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
> b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> index 3c8ef4bfc205..0f8b6dc853a5 100644
> --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> @@ -1184,7 +1184,7 @@ int amd_powerplay_reset(void *handle)
> int ret;
>
> ret = pp_check(instance);
> -   if (!ret)
> +   if (ret)
> return ret;
>
> ret = pp_hw_fini(instance);
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103370] `DRI_PRIME=1 glxgears -info` halts the system with Intel Graphics [8086:5917] + AMD Graphics [1002:6665].

[bugzilla-daemon]

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

--- Comment #19 from Mike Lothian  ---
You have to blacklist radeon to use amdgpu as both modules try and claim the
device

-- 
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] drm: add connector info/property for non-desktop displays

[Keith Packard]

Daniel Stone  writes:

> I still think putting these behind a client cap is a good idea:
> https://lists.freedesktop.org/archives/dri-devel/2017-October/155616.html

Assuming that everyone eventually catches up, this should be a
short-term issue. So, all we have to do is figure out how to make the
transition, which seems a lot less weighty than something that will
affect the environment for a long time.

We need to consider the cross-version compatibility issues for both the
window system and the kernel. That means an old window system with new
kernel or new window system with old kernel should work as well as it
does today.

Today, an HMD display is presented as a normal output and applications
can discover it through the window system and present an image on it by
placing their image at the right location on the screen. To keep that
working, we can't hide HMD outputs from an older window system.

-- 
-keith


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

Re: [PATCH 1/3] drm: add connector info/property for non-std displays

[Dave Airlie]

On 25 October 2017 at 21:27, Daniel Stone  wrote:
> Hi,
>
> On 19 October 2017 at 17:27, Keith Packard  wrote:
>> Daniel Stone  writes:
>>> Why not add a client cap which hides 'non-standard' displays
>>> completely from non-aware clients? That way you can keep the connected
>>> status as is, and clients either never see the HMD or will be able to
>>> check the property.
>>
>> Most clients are display servers, and it looks like we're settling on
>> using the display server as the way to enumerate all of the displays (as
>> direct enumeration through DRM non-master FDs involve rather drastic
>> permissions changes in the kernel).
>>
>> This means that display servers are going to have to change to both see
>> these displays while keeping them from being part of the desktop. So,
>> while I guess it might be useful to hide HMD from existing display
>> servers with a bit like this, I don't think there's any particular
>> long-term benefit?
>
> I totally agree with you. On the other hand, this gives symmetry to
> making sure we don't put fbcon into someone's retinas: if we're doing
> that, why not also hide it from legacy userspace which isn't going to
> be aware of HMD characteristics?

Not sure it really does, at the moment if you have a kernel without these
patches you get fbcon in your brain. Upgrade your kernel and it goes away.

If your X server puts moire pattern in your brain, you upgrade your X server
and no more moire in your brain.

btw I'm more about not having HMD fbcon wreck other fbcons due to the
cloning we do, I'm not as worried about it being in your retinas.

I don't really like having the kernel hide devices, tagging them with properties
is one thing, but actively hiding them from userspace doesn't seem
like something
we want to pursue, though the suggestion has some merit.

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

Re: [PATCH 1/3] drm: add connector info/property for non-desktop displays

[Dave Airlie]

On 26 October 2017 at 05:24, Dave Airlie  wrote:
> On 25 October 2017 at 21:15, Daniel Stone  wrote:
>> Hi,
>>
>> On 25 October 2017 at 07:30, Dave Airlie  wrote:
>>> This adds the infrastructure needed to quirk displays
>>> using edid and to mark them as non-desktop to denote
>>> that userspace shouldn't display a standard desktop on them.
>>>
>>> A non-desktop display is one which doesn't work like
>>> a normal rectangular monitor or requires some transformation
>>> of the output by the rendering process to make sense.
>>
>> I still think putting these behind a client cap is a good idea:
>> https://lists.freedesktop.org/archives/dri-devel/2017-October/155616.html
>
> We want the X server to see these. How else can someone discover
> there's a HMD plugged in?
>
> So a client cap doesn't make any sense.

Userspace also doesn't help with getting the console off these and not
having them upset your other fbcon monitor, if someone
invents a userspace database and gets it into X.org/mutter/
then I'm happy to use it.

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

Re: [PATCH 1/3] drm: add connector info/property for non-desktop displays

[Dave Airlie]

On 25 October 2017 at 21:15, Daniel Stone  wrote:
> Hi,
>
> On 25 October 2017 at 07:30, Dave Airlie  wrote:
>> This adds the infrastructure needed to quirk displays
>> using edid and to mark them as non-desktop to denote
>> that userspace shouldn't display a standard desktop on them.
>>
>> A non-desktop display is one which doesn't work like
>> a normal rectangular monitor or requires some transformation
>> of the output by the rendering process to make sense.
>
> I still think putting these behind a client cap is a good idea:
> https://lists.freedesktop.org/archives/dri-devel/2017-October/155616.html

We want the X server to see these. How else can someone discover
there's a HMD plugged in?

So a client cap doesn't make any sense.

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

[Bug 103408] [bisected] frames dropped during video replay due to "add hardware_planes_only to list of affected planes"

[bugzilla-daemon]

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

--- Comment #2 from Andy Furniss  ---
I can reproduce this on R9 285 with a different setup.

Made a 60fps 1920x1080 from the vid here, lengthened by repeating 4x + added
time counter, removed audio.

Monitor is 60Hz 1920x1080 DVI-D. CPU and GPU on perf. No TearFree, but same
results if on (I don't need tearfree due to not using a compositing desktop).

mpv vo=vdpau/opengl/vaapi = mostly 10 sec glitches some 20.

kodi = every 5 seconds.

mplayer = 30 seconds.

With the commit reverted all are glitch free.

Also notice that wayland/weston (composited full screen) doesn't have the
issue.

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

[PATCH v3] drm: drm_vblank_cleanup: WARN when refcount > 0

[PrasannaKumar Muralidharan]

Warn when refcount > 0 in drm_vblank_cleanup.

Signed-off-by: PrasannaKumar Muralidharan 
---
Changes in v3:
* Dropped i915 patch that is used for testing this.

No changes in v2.

 drivers/gpu/drm/drm_vblank.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 70f2b95..3e61aeb 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -405,6 +405,8 @@ void drm_vblank_cleanup(struct drm_device *dev)
for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
+   WARN_ON(atomic_read(>refcount) > 0);
+
WARN_ON(READ_ONCE(vblank->enabled) &&
drm_core_check_feature(dev, DRIVER_MODESET));
 
-- 
2.10.0

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

Re: [PATCH v2] drm/framebuffer: Add framebuffer debugfs file

[Ville Syrjälä]

On Wed, Oct 25, 2017 at 05:22:25PM +0200, Noralf Trønnes wrote:
> 
> Den 25.10.2017 15.55, skrev Ville Syrjälä:
> > On Wed, Oct 25, 2017 at 02:05:02PM +0200, Noralf Trønnes wrote:
> >> Add debugfs file that dumps info about the framebuffers and its planes.
> >> Also dump info about any connected gem object(s).
> >>
> >> Signed-off-by: Noralf Trønnes 
> >> ---
> >>
> >> Changes since version 1:
> >> - Remove const in drm_gem_print() argument (kbuild test robot)
> >> - Print framebuffer modifiers (Kristian Høgsberg)
> >>
> >>   drivers/gpu/drm/drm_debugfs.c |  6 +
> >>   drivers/gpu/drm/drm_framebuffer.c | 52 
> >> +++
> >>   drivers/gpu/drm/drm_gem.c | 11 +
> >>   drivers/gpu/drm/drm_internal.h|  4 +++
> >>   4 files changed, 73 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> >> index c1807d5754b2..550f29de6c1f 100644
> >> --- a/drivers/gpu/drm/drm_debugfs.c
> >> +++ b/drivers/gpu/drm/drm_debugfs.c
> >> @@ -158,6 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int 
> >> minor_id,
> >>}
> >>}
> >>   
> >> +  ret = drm_framebuffer_debugfs_init(minor);
> >> +  if (ret) {
> >> +  DRM_ERROR("Failed to create framebuffer debugfs file\n");
> >> +  return ret;
> >> +  }
> >> +
> >>if (dev->driver->debugfs_init) {
> >>ret = dev->driver->debugfs_init(minor);
> >>if (ret) {
> >> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> >> b/drivers/gpu/drm/drm_framebuffer.c
> >> index af279844d7ce..86a6b5f61411 100644
> >> --- a/drivers/gpu/drm/drm_framebuffer.c
> >> +++ b/drivers/gpu/drm/drm_framebuffer.c
> >> @@ -25,7 +25,9 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   
> >> +#include "drm_internal.h"
> >>   #include "drm_crtc_internal.h"
> >>   
> >>   /**
> >> @@ -955,3 +957,53 @@ int drm_framebuffer_plane_height(int height,
> >>return fb_plane_height(height, fb->format, plane);
> >>   }
> >>   EXPORT_SYMBOL(drm_framebuffer_plane_height);
> >> +
> >> +#ifdef CONFIG_DEBUG_FS
> >> +static void drm_framebuffer_print(struct drm_framebuffer *fb,
> > Can be const
> 
> I call drm_framebuffer_read_refcount() and it doesn't like const.

Fix it first then?

> 
> >> +struct drm_printer *p)
> >> +{
> >> +  unsigned int i;
> > int
> >
> >> +
> >> +  drm_printf(p, "[FB:%d] %dx%d@%4.4s modifier=0x%llx refcount=%d\n",
> >> + fb->base.id, fb->width, fb->height,
> >> + (char *)>format->format, fb->modifier,
> > drm_format_get_name(), or whatver it was called.
> >
> > For a bit of extra niceness you could print the dimensions of each
> > plane rather than just the whole fb.
> 
> Where do I find that info?

drm_framebuffer_plane_width/height() or something like that.

> 
> >
> >> + drm_framebuffer_read_refcount(fb));
> >> +
> >> +  for (i = 0; i < fb->format->num_planes; i++) {
> >> +  drm_printf(p, "\t%u: offset=%d pitch=%d",
> >> + i, fb->offsets[i], fb->pitches[i]);
> >> +  if (fb->obj[i]) {
> > Maybe print the handle as well.
> 
> Where do I find that info?

Hmm. Oh, we don't bring that over into drm_framebuffer. Ignore what I
wrote then :)

> 
> > If ->obj[] is not there it might be
> > to nice to have something to indicate which bo is used. I wonder if I
> > should actually make i915 use ->obj[] instead of storing the obj pointer
> > in struct intel_framebuffer...
> >
> > That highlights a slight weakness in this apporach. Drivers can extend
> > drm_framebuffer and drm_gem_object and this of course can't print out
> > any extened information. But I guess we can worry about that later if
> > needed.
> 
> The idea was to add it later on demand as you say, but I can add it now
> if you want it:
> 
> struct drm_driver {
>      /**
>       * @gem_print_info:
>       *
>       * If driver subclasses struct _gem_object, it can implement this
>       * optional hook for printing additional driver specific info.
>       * See drm_gem_print_info().
>       */
>      void (*gem_print_info)(struct drm_printer *p,
>                 struct drm_gem_object *obj);
> };
> 
> struct drm_framebuffer_funcs {
>      /**
>       * @print_info:
>       *
>       * If driver subclasses struct _framebuffer, it can implement this
>       * optional hook for printing additional driver specific info.
>       * See drm_framebuffer_print_info().
>       */
>      void (*print_info)(struct drm_printer *p, struct drm_framebuffer *obj);
> };

We'd also need an actual user for those new hooks, so that'd mean changing
at least one driver. I guess it's good to get the basic stuff in first,
and we can worry about extending it later.

It also occurs to me that we might want to combine this fb dumper with
the atomic state dumper. That one already prints out stuf about
framebuffers in drm_atomic_plane_print_state(). Not sure if there

Re: [PATCH v2] drm/framebuffer: Add framebuffer debugfs file

[Noralf Trønnes]

Den 25.10.2017 15.55, skrev Ville Syrjälä:

On Wed, Oct 25, 2017 at 02:05:02PM +0200, Noralf Trønnes wrote:

Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s).

Signed-off-by: Noralf Trønnes 
---

Changes since version 1:
- Remove const in drm_gem_print() argument (kbuild test robot)
- Print framebuffer modifiers (Kristian Høgsberg)

  drivers/gpu/drm/drm_debugfs.c |  6 +
  drivers/gpu/drm/drm_framebuffer.c | 52 +++
  drivers/gpu/drm/drm_gem.c | 11 +
  drivers/gpu/drm/drm_internal.h|  4 +++
  4 files changed, 73 insertions(+)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index c1807d5754b2..550f29de6c1f 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -158,6 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
}
}
  
+	ret = drm_framebuffer_debugfs_init(minor);

+   if (ret) {
+   DRM_ERROR("Failed to create framebuffer debugfs file\n");
+   return ret;
+   }
+
if (dev->driver->debugfs_init) {
ret = dev->driver->debugfs_init(minor);
if (ret) {
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index af279844d7ce..86a6b5f61411 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -25,7 +25,9 @@
  #include 
  #include 
  #include 
+#include 
  
+#include "drm_internal.h"

  #include "drm_crtc_internal.h"
  
  /**

@@ -955,3 +957,53 @@ int drm_framebuffer_plane_height(int height,
return fb_plane_height(height, fb->format, plane);
  }
  EXPORT_SYMBOL(drm_framebuffer_plane_height);
+
+#ifdef CONFIG_DEBUG_FS
+static void drm_framebuffer_print(struct drm_framebuffer *fb,

Can be const


I call drm_framebuffer_read_refcount() and it doesn't like const.


+ struct drm_printer *p)
+{
+   unsigned int i;

int


+
+   drm_printf(p, "[FB:%d] %dx%d@%4.4s modifier=0x%llx refcount=%d\n",
+  fb->base.id, fb->width, fb->height,
+  (char *)>format->format, fb->modifier,

drm_format_get_name(), or whatver it was called.

For a bit of extra niceness you could print the dimensions of each
plane rather than just the whole fb.


Where do I find that info?




+  drm_framebuffer_read_refcount(fb));
+
+   for (i = 0; i < fb->format->num_planes; i++) {
+   drm_printf(p, "\t%u: offset=%d pitch=%d",
+  i, fb->offsets[i], fb->pitches[i]);
+   if (fb->obj[i]) {

Maybe print the handle as well.


Where do I find that info?


If ->obj[] is not there it might be
to nice to have something to indicate which bo is used. I wonder if I
should actually make i915 use ->obj[] instead of storing the obj pointer
in struct intel_framebuffer...

That highlights a slight weakness in this apporach. Drivers can extend
drm_framebuffer and drm_gem_object and this of course can't print out
any extened information. But I guess we can worry about that later if
needed.


The idea was to add it later on demand as you say, but I can add it now
if you want it:

struct drm_driver {
    /**
     * @gem_print_info:
     *
     * If driver subclasses struct _gem_object, it can implement this
     * optional hook for printing additional driver specific info.
     * See drm_gem_print_info().
     */
    void (*gem_print_info)(struct drm_printer *p,
               struct drm_gem_object *obj);
};

struct drm_framebuffer_funcs {
    /**
     * @print_info:
     *
     * If driver subclasses struct _framebuffer, it can implement this
     * optional hook for printing additional driver specific info.
     * See drm_framebuffer_print_info().
     */
    void (*print_info)(struct drm_printer *p, struct drm_framebuffer *obj);
};


Noralf.


+   drm_printf(p, " GEM: ");
+   drm_gem_print(fb->obj[i], p);
+   } else {
+   drm_printf(p, "\n");
+   }
+   }
+}
+
+static int drm_framebuffer_info(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_printer p = drm_seq_file_printer(m);
+   struct drm_framebuffer *fb;
+
+   mutex_lock(>mode_config.fb_lock);
+   drm_for_each_fb(fb, dev)
+   drm_framebuffer_print(fb, );
+   mutex_unlock(>mode_config.fb_lock);
+
+   return 0;
+}
+
+static const struct drm_info_list drm_framebuffer_debugfs_list[] = {
+   { "framebuffer", drm_framebuffer_info, 0 },
+};
+
+int drm_framebuffer_debugfs_init(struct drm_minor *minor)
+{
+   return drm_debugfs_create_files(drm_framebuffer_debugfs_list,
+   ARRAY_SIZE(drm_framebuffer_debugfs_list),
+   

Re: [PATCH v2 2/2] Test case for drm_vblank_cleanup refcount validation patch

[PrasannaKumar Muralidharan]

Hi All,

On 24 October 2017 at 22:18, PrasannaKumar Muralidharan
 wrote:
> In i915 driver unload drm_vblank_get is added to test whether
> drm_vblank_cleanup refcount validation patch is working.
>
> Signed-off-by: PrasannaKumar Muralidharan 
> ---
> Changes in v2:
> Use drm_crtc_vblank_get instead of _put. In previous patch _put was wrongly
> used.
>
>  drivers/gpu/drm/i915/i915_drv.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9f45cfe..4aee1c0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1373,6 +1373,13 @@ void i915_driver_unload(struct drm_device *dev)
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct pci_dev *pdev = dev_priv->drm.pdev;
>
> +   enum pipe pipe;
> +   for_each_pipe(dev_priv, pipe) {
> +   struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv,
> + pipe);
> +   drm_crtc_vblank_get(>base);
> +   }
> +
> i915_driver_unregister(dev_priv);
>
> if (i915_gem_suspend(dev_priv))
> --
> 2.10.0
>

From 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6167/fi-ilk-650/igt@drv_module_rel...@basic-reload.html
it can be seen that this patch triggers warning when vblank->refcount
> 0 in vblank cleanup. This tests patch 1 successfully.

I think patch 1 is good to go.

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

[Bug 91221] UVD: GPU lockup with BARTS

[bugzilla-daemon]

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

--- Comment #7 from Chí-Thanh Christopher Nguyễn  ---
Thanks for the suggestion. However,
mpv -vo opengl --hwdec=vdpau
triggers the problem in the same way as -vo vdpau

-- 
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/i915/selftests: Convert timers to use timer_setup()

[Jani Nikula]

On Wed, 25 Oct 2017, Kees Cook  wrote:
> On Wed, Oct 25, 2017 at 4:16 PM, Chris Wilson  
> wrote:
>> Quoting Kees Cook (2017-10-25 15:05:13)
>>> On Wed, Oct 25, 2017 at 3:11 PM, Chris Wilson  
>>> wrote:
>>> > Quoting Chris Wilson (2017-10-25 11:24:19)
>>> >> Quoting Chris Wilson (2017-10-24 17:17:09)
>>> >> > Quoting Kees Cook (2017-10-24 16:13:44)
>>> >> > > In preparation for unconditionally passing the struct timer_list 
>>> >> > > pointer to
>>> >> > > all timer callbacks, switch to using the new timer_setup() and 
>>> >> > > from_timer()
>>> >> > > to pass the timer pointer explicitly.
>>> >> > >
>>> >> > > Cc: Jani Nikula 
>>> >> > > Cc: Joonas Lahtinen 
>>> >> > > Cc: Rodrigo Vivi 
>>> >> > > Cc: David Airlie 
>>> >> > > Cc: Tvrtko Ursulin 
>>> >> > > Cc: Chris Wilson 
>>> >> > > Cc: intel-...@lists.freedesktop.org
>>> >> > > Cc: dri-devel@lists.freedesktop.org
>>> >> > > Signed-off-by: Kees Cook 
>>> >> >
>>> >> > Thank you for saving me from having to do this myself,
>>> >> > Reviewed-by: Chris Wilson 
>>> >>
>>> >> I've a small batch of selftests patches queued, so added this one and
>>> >> will push to drm-intel-next-queued shortly.
>>> >
>>> > Oh dear, major faux pas. There is no timer_setup_on_stack yet.
>>>
>>> Argh. Right, sorry. That's only in -next. Since this is mainly a
>>> mechanical change, should I carry this in the timer tree, or wait
>>> until the merge window for it to go via i915?
>>
>> Jani has the final word, but my understanding is that there will be no
>> more from i915 towards the 4.15 merge. Hmm, the origin of this timer,
>>
>> commit 214707fc2ce08d09982bc4fe4b7a1c1f010e82be
>> Author: Chris Wilson 
>> Date:   Thu Oct 12 13:57:25 2017 +0100
>>
>> drm/i915/selftests: Wrap a timer into a i915_sw_fence
>>
>> did make it into 4.15, so it would have been better to put into a
>> separate tree for the 4.15 merge window anyway. In hindsight, yes this
>> probably wants to be carried in the timer tree to be applied after i915.
>> (I guess there will be a few other stragglers that need to be converted
>> at the end of the merge window anyway.)
>
> Yeah, it's going to be messy, but I'll manage. I'll be carrying a lot
> of other stuff as well. Avoiding conflicts will be the trick. Wheee.
> :)

Acked-by: Jani Nikula 

for merging via timer tree. Otherwise we'll need to wait for the changes
to hit Linus' tree, then get backmerges to our tree, and it's v4.16
before you know it. ;)

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

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

[Chris Wilson]

Quoting Kees Cook (2017-10-25 15:05:13)
> On Wed, Oct 25, 2017 at 3:11 PM, Chris Wilson  
> wrote:
> > Quoting Chris Wilson (2017-10-25 11:24:19)
> >> Quoting Chris Wilson (2017-10-24 17:17:09)
> >> > Quoting Kees Cook (2017-10-24 16:13:44)
> >> > > In preparation for unconditionally passing the struct timer_list 
> >> > > pointer to
> >> > > all timer callbacks, switch to using the new timer_setup() and 
> >> > > from_timer()
> >> > > to pass the timer pointer explicitly.
> >> > >
> >> > > Cc: Jani Nikula 
> >> > > Cc: Joonas Lahtinen 
> >> > > Cc: Rodrigo Vivi 
> >> > > Cc: David Airlie 
> >> > > Cc: Tvrtko Ursulin 
> >> > > Cc: Chris Wilson 
> >> > > Cc: intel-...@lists.freedesktop.org
> >> > > Cc: dri-devel@lists.freedesktop.org
> >> > > Signed-off-by: Kees Cook 
> >> >
> >> > Thank you for saving me from having to do this myself,
> >> > Reviewed-by: Chris Wilson 
> >>
> >> I've a small batch of selftests patches queued, so added this one and
> >> will push to drm-intel-next-queued shortly.
> >
> > Oh dear, major faux pas. There is no timer_setup_on_stack yet.
> 
> Argh. Right, sorry. That's only in -next. Since this is mainly a
> mechanical change, should I carry this in the timer tree, or wait
> until the merge window for it to go via i915?

Jani has the final word, but my understanding is that there will be no
more from i915 towards the 4.15 merge. Hmm, the origin of this timer,

commit 214707fc2ce08d09982bc4fe4b7a1c1f010e82be
Author: Chris Wilson 
Date:   Thu Oct 12 13:57:25 2017 +0100

drm/i915/selftests: Wrap a timer into a i915_sw_fence

did make it into 4.15, so it would have been better to put into a
separate tree for the 4.15 merge window anyway. In hindsight, yes this
probably wants to be carried in the timer tree to be applied after i915.
(I guess there will be a few other stragglers that need to be converted
at the end of the merge window anyway.)

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

Re: [PATCH v2] drm/framebuffer: Add framebuffer debugfs file

[Ville Syrjälä]

On Wed, Oct 25, 2017 at 02:05:02PM +0200, Noralf Trønnes wrote:
> Add debugfs file that dumps info about the framebuffers and its planes.
> Also dump info about any connected gem object(s).
> 
> Signed-off-by: Noralf Trønnes 
> ---
> 
> Changes since version 1:
> - Remove const in drm_gem_print() argument (kbuild test robot)
> - Print framebuffer modifiers (Kristian Høgsberg)
> 
>  drivers/gpu/drm/drm_debugfs.c |  6 +
>  drivers/gpu/drm/drm_framebuffer.c | 52 
> +++
>  drivers/gpu/drm/drm_gem.c | 11 +
>  drivers/gpu/drm/drm_internal.h|  4 +++
>  4 files changed, 73 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index c1807d5754b2..550f29de6c1f 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -158,6 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int 
> minor_id,
>   }
>   }
>  
> + ret = drm_framebuffer_debugfs_init(minor);
> + if (ret) {
> + DRM_ERROR("Failed to create framebuffer debugfs file\n");
> + return ret;
> + }
> +
>   if (dev->driver->debugfs_init) {
>   ret = dev->driver->debugfs_init(minor);
>   if (ret) {
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index af279844d7ce..86a6b5f61411 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -25,7 +25,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> +#include "drm_internal.h"
>  #include "drm_crtc_internal.h"
>  
>  /**
> @@ -955,3 +957,53 @@ int drm_framebuffer_plane_height(int height,
>   return fb_plane_height(height, fb->format, plane);
>  }
>  EXPORT_SYMBOL(drm_framebuffer_plane_height);
> +
> +#ifdef CONFIG_DEBUG_FS
> +static void drm_framebuffer_print(struct drm_framebuffer *fb,

Can be const

> +   struct drm_printer *p)
> +{
> + unsigned int i;

int

> +
> + drm_printf(p, "[FB:%d] %dx%d@%4.4s modifier=0x%llx refcount=%d\n",
> +fb->base.id, fb->width, fb->height,
> +(char *)>format->format, fb->modifier,

drm_format_get_name(), or whatver it was called.

For a bit of extra niceness you could print the dimensions of each
plane rather than just the whole fb.

> +drm_framebuffer_read_refcount(fb));
> +
> + for (i = 0; i < fb->format->num_planes; i++) {
> + drm_printf(p, "\t%u: offset=%d pitch=%d",
> +i, fb->offsets[i], fb->pitches[i]);
> + if (fb->obj[i]) {

Maybe print the handle as well. If ->obj[] is not there it might be
to nice to have something to indicate which bo is used. I wonder if I
should actually make i915 use ->obj[] instead of storing the obj pointer
in struct intel_framebuffer...

That highlights a slight weakness in this apporach. Drivers can extend
drm_framebuffer and drm_gem_object and this of course can't print out
any extened information. But I guess we can worry about that later if
needed.

> + drm_printf(p, " GEM: ");
> + drm_gem_print(fb->obj[i], p);
> + } else {
> + drm_printf(p, "\n");
> + }
> + }
> +}
> +
> +static int drm_framebuffer_info(struct seq_file *m, void *data)
> +{
> + struct drm_info_node *node = m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct drm_printer p = drm_seq_file_printer(m);
> + struct drm_framebuffer *fb;
> +
> + mutex_lock(>mode_config.fb_lock);
> + drm_for_each_fb(fb, dev)
> + drm_framebuffer_print(fb, );
> + mutex_unlock(>mode_config.fb_lock);
> +
> + return 0;
> +}
> +
> +static const struct drm_info_list drm_framebuffer_debugfs_list[] = {
> + { "framebuffer", drm_framebuffer_info, 0 },
> +};
> +
> +int drm_framebuffer_debugfs_init(struct drm_minor *minor)
> +{
> + return drm_debugfs_create_files(drm_framebuffer_debugfs_list,
> + ARRAY_SIZE(drm_framebuffer_debugfs_list),
> + minor->debugfs_root, minor);
> +}
> +#endif
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 55d6182555c7..3d6ff9417e51 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "drm_internal.h"
>  
>  /** @file drm_gem.c
> @@ -1040,3 +1041,13 @@ int drm_gem_mmap(struct file *filp, struct 
> vm_area_struct *vma)
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_gem_mmap);
> +
> +#ifdef CONFIG_DEBUG_FS
> +void drm_gem_print(struct drm_gem_object *obj, struct drm_printer *p)
> +{
> + drm_printf(p, "name=%d refcount=%d start=%08lx size=%zu%s\n",
> +obj->name, kref_read(>refcount),
> +drm_vma_node_start(>vma_node), obj->size,
> +

[pull] amdgpu drm-fixes-4.14

[Alex Deucher]

Hi Dave,

Just two small patches for suspend/resume regressions.

The following changes since commit 2cb3a34abd035756f9ba3cde12f44f4b3e4c234b:

  Merge tag 'drm-intel-fixes-2017-10-18-1' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2017-10-19 15:00:47 
+1000)

are available in the git repository at:

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

for you to fetch changes up to d3daa2c7865cbfa830651b11c8ad1df23465b46e:

  drm/amd/amdgpu: Remove workaround check for UVD6 on APUs (2017-10-25 09:32:14 
-0400)


Rex Zhu (1):
  drm/amd/powerplay: fix uninitialized variable

Tom St Denis (1):
  drm/amd/amdgpu: Remove workaround check for UVD6 on APUs

 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c| 16 +---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c |  6 +++---
 2 files changed, 8 insertions(+), 14 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

[Chris Wilson]

Quoting Chris Wilson (2017-10-25 11:24:19)
> Quoting Chris Wilson (2017-10-24 17:17:09)
> > Quoting Kees Cook (2017-10-24 16:13:44)
> > > In preparation for unconditionally passing the struct timer_list pointer 
> > > to
> > > all timer callbacks, switch to using the new timer_setup() and 
> > > from_timer()
> > > to pass the timer pointer explicitly.
> > > 
> > > Cc: Jani Nikula 
> > > Cc: Joonas Lahtinen 
> > > Cc: Rodrigo Vivi 
> > > Cc: David Airlie 
> > > Cc: Tvrtko Ursulin 
> > > Cc: Chris Wilson 
> > > Cc: intel-...@lists.freedesktop.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Signed-off-by: Kees Cook 
> > 
> > Thank you for saving me from having to do this myself,
> > Reviewed-by: Chris Wilson 
> 
> I've a small batch of selftests patches queued, so added this one and
> will push to drm-intel-next-queued shortly.

Oh dear, major faux pas. There is no timer_setup_on_stack yet.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/framebuffer: Add framebuffer debugfs file

[Noralf Trønnes]

Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s).

Signed-off-by: Noralf Trønnes 
---

Changes since version 1:
- Remove const in drm_gem_print() argument (kbuild test robot)
- Print framebuffer modifiers (Kristian Høgsberg)

 drivers/gpu/drm/drm_debugfs.c |  6 +
 drivers/gpu/drm/drm_framebuffer.c | 52 +++
 drivers/gpu/drm/drm_gem.c | 11 +
 drivers/gpu/drm/drm_internal.h|  4 +++
 4 files changed, 73 insertions(+)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index c1807d5754b2..550f29de6c1f 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -158,6 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
}
}
 
+   ret = drm_framebuffer_debugfs_init(minor);
+   if (ret) {
+   DRM_ERROR("Failed to create framebuffer debugfs file\n");
+   return ret;
+   }
+
if (dev->driver->debugfs_init) {
ret = dev->driver->debugfs_init(minor);
if (ret) {
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index af279844d7ce..86a6b5f61411 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -25,7 +25,9 @@
 #include 
 #include 
 #include 
+#include 
 
+#include "drm_internal.h"
 #include "drm_crtc_internal.h"
 
 /**
@@ -955,3 +957,53 @@ int drm_framebuffer_plane_height(int height,
return fb_plane_height(height, fb->format, plane);
 }
 EXPORT_SYMBOL(drm_framebuffer_plane_height);
+
+#ifdef CONFIG_DEBUG_FS
+static void drm_framebuffer_print(struct drm_framebuffer *fb,
+ struct drm_printer *p)
+{
+   unsigned int i;
+
+   drm_printf(p, "[FB:%d] %dx%d@%4.4s modifier=0x%llx refcount=%d\n",
+  fb->base.id, fb->width, fb->height,
+  (char *)>format->format, fb->modifier,
+  drm_framebuffer_read_refcount(fb));
+
+   for (i = 0; i < fb->format->num_planes; i++) {
+   drm_printf(p, "\t%u: offset=%d pitch=%d",
+  i, fb->offsets[i], fb->pitches[i]);
+   if (fb->obj[i]) {
+   drm_printf(p, " GEM: ");
+   drm_gem_print(fb->obj[i], p);
+   } else {
+   drm_printf(p, "\n");
+   }
+   }
+}
+
+static int drm_framebuffer_info(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_printer p = drm_seq_file_printer(m);
+   struct drm_framebuffer *fb;
+
+   mutex_lock(>mode_config.fb_lock);
+   drm_for_each_fb(fb, dev)
+   drm_framebuffer_print(fb, );
+   mutex_unlock(>mode_config.fb_lock);
+
+   return 0;
+}
+
+static const struct drm_info_list drm_framebuffer_debugfs_list[] = {
+   { "framebuffer", drm_framebuffer_info, 0 },
+};
+
+int drm_framebuffer_debugfs_init(struct drm_minor *minor)
+{
+   return drm_debugfs_create_files(drm_framebuffer_debugfs_list,
+   ARRAY_SIZE(drm_framebuffer_debugfs_list),
+   minor->debugfs_root, minor);
+}
+#endif
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 55d6182555c7..3d6ff9417e51 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drm_internal.h"
 
 /** @file drm_gem.c
@@ -1040,3 +1041,13 @@ int drm_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
return ret;
 }
 EXPORT_SYMBOL(drm_gem_mmap);
+
+#ifdef CONFIG_DEBUG_FS
+void drm_gem_print(struct drm_gem_object *obj, struct drm_printer *p)
+{
+   drm_printf(p, "name=%d refcount=%d start=%08lx size=%zu%s\n",
+  obj->name, kref_read(>refcount),
+  drm_vma_node_start(>vma_node), obj->size,
+  obj->import_attach ? " (imported)" : "");
+}
+#endif
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index fbc3f308fa19..0f28be586cb3 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -106,6 +106,7 @@ int drm_gem_open_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
 void drm_gem_open(struct drm_device *dev, struct drm_file *file_private);
 void drm_gem_release(struct drm_device *dev, struct drm_file *file_private);
+void drm_gem_print(struct drm_gem_object *obj, struct drm_printer *p);
 
 /* drm_debugfs.c drm_debugfs_crc.c */
 #if defined(CONFIG_DEBUG_FS)
@@ -173,3 +174,6 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void 
*data,
struct drm_file *file_private);
 int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
  

RE: [PATCH] drm/amd/display: assign fb_location only if bo is pinned

[S, Shirish]

Hi Alex, Michel & Andrey,

 [PATCH] drm/amd/display: assign fb_location only if bo is pinned
 [PATCH 2/2] drm/amd/display: cleanup addReq and fix fb_location

should be dropped and instead:

[PATCH] drm/amd/display: fix high part address in dm_plane_helper_prepare_fb()


should be reviewed .

With this change I don’t have clean-up addReq,  as I get the gpu_offset
required for high part in dm_plane_helper_prepare_fb().


Thanks.
Regards,
Shirish S


-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net] 
Sent: Wednesday, October 25, 2017 1:38 PM
To: S, Shirish ; Grodzovsky, Andrey 

Cc: Deucher, Alexander ; 
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/display: assign fb_location only if bo is pinned

On 25/10/17 07:18 AM, S, Shirish wrote:
>
> Andrey,
> Till now the get_fb_info() never calculated fb_location(as addrReq was
> always false), but since now its required to program the high part of
> the address structure,
> can you move it back into the commit scope and ensure that fb_location
> is calculated everytime.(I have limited knowledge behind why it was
> moved out)
> And in case if you insist on adding pin & unpin in atomic_check() scope
> i can post a patch for it.

The latter on its own couldn't really solve the problem anyway: While a
BO is unpinned, its MC address can change at any time. The MC address
programmed to the hardware must be determined while the BO is and stays
pinned.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Resizable PCI BAR support V9

[Christian König]

Am 24.10.2017 um 21:44 schrieb Bjorn Helgaas:

On Wed, Oct 18, 2017 at 03:58:16PM +0200, Christian König wrote:

Hi everyone,

This is the ninth and hopefully last incarnation of this set of patches. It
enables device drivers to resize and most likely also relocate the PCI BAR of
devices they manage to allow the CPU to access all of the device local memory
at once.

This is very useful for GFX device drivers where the default PCI BAR is only
about 256MB in size for compatibility reasons, but the device easily have
multiple gigabyte of local memory.

Some changes since the last version:
1. Rebased on drm-next, so should be ready to be merged for 4.15.
2. The fixup of the 64bit root window on AMD Family 15h CPUs/APUs is only
enabled when we compile a kernel supporting that hw.
3. Some minor error handling improvements for the amdgpu side. We now
gracefully abort driver loading in case of a critical error instead of
calling BUG().

Bjorn any more comments or can we finally get this into 4.15? I will remove the
version tags from the patches when I send you a pull request if you want this.

I only work on this as a background task, so sorry for the ~3 month delay
between each version of the patchset.

I put these (except for the last) on pci/resource for v4.15.  I'd be
happy to merge the last as well if you like.  My tree does not include
drm-next, so there would be a minor conflict when merging upstream.


Thanks Bjorn, that is great to hear.

I will sync up with Alex and Dave how to merge the last patch.

Christian.



Bjorn



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

Re: [PATCH 1/3] drm: add connector info/property for non-std displays

[Daniel Stone]

Hi,

On 19 October 2017 at 17:27, Keith Packard  wrote:
> Daniel Stone  writes:
>> Why not add a client cap which hides 'non-standard' displays
>> completely from non-aware clients? That way you can keep the connected
>> status as is, and clients either never see the HMD or will be able to
>> check the property.
>
> Most clients are display servers, and it looks like we're settling on
> using the display server as the way to enumerate all of the displays (as
> direct enumeration through DRM non-master FDs involve rather drastic
> permissions changes in the kernel).
>
> This means that display servers are going to have to change to both see
> these displays while keeping them from being part of the desktop. So,
> while I guess it might be useful to hide HMD from existing display
> servers with a bit like this, I don't think there's any particular
> long-term benefit?

I totally agree with you. On the other hand, this gives symmetry to
making sure we don't put fbcon into someone's retinas: if we're doing
that, why not also hide it from legacy userspace which isn't going to
be aware of HMD characteristics?

The display server enumeration/lease model means that display servers
are still going to have to be explicitly aware of HMDs, so somehow
hiding them from legacy display servers makes about as much sense as
hiding fbcon. Assuming we do have the database in the kernel.

>> Either way, I'm still not convinced doing this in the kernel makes any
>> sense.
>
> fbdev. We want to keep the HMD dark until there's something 'real' to
> show on it.
>
> If you accept that fbdev needs to know this, then there's no way to
> avoid maintaining a database in the kernel. Maybe what we need is some
> way to load additional database entries into the kernel at boot time
> from a file in the initrd? And if you want a user-space database too,
> then maybe the kernel data should be generated from that and dumped into
> the initrd? One version of the truth is hard enough to deal with; I'd
> hate to have two.

Yes, I'd still rather userspace prime the kernel, and keep the
database out of the kernel. The only gap this leaves is early boot,
but the VBIOS will have already lit the HMD up at boot anyway, so
you've already lost.

>> We need the shared EDID library anyway in order to deal with the quirk
>> tables replicated between the kernel/Xorg currently, so that's going
>> to happen pretty soon regardless of whether or not the kernel gets its
>> own database.
>
> Yeah, we'll presumably need this support in the Vulkan KHR_display
> extension too, so sharing EDID support up in user space between all of
> these entities seems like a great idea.

Yeah. That doesn't currently exist, but it's something I'd happily
throw some of our time at quite shortly. If it avoids creating and
supporting both uABI and duplicate databases forever, then it seems
like the best thing to do.

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

Re: [PATCH 1/3] drm: add connector info/property for non-desktop displays

[Daniel Stone]

Hi,

On 25 October 2017 at 07:30, Dave Airlie  wrote:
> This adds the infrastructure needed to quirk displays
> using edid and to mark them as non-desktop to denote
> that userspace shouldn't display a standard desktop on them.
>
> A non-desktop display is one which doesn't work like
> a normal rectangular monitor or requires some transformation
> of the output by the rendering process to make sense.

I still think putting these behind a client cap is a good idea:
https://lists.freedesktop.org/archives/dri-devel/2017-October/155616.html

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

[Bug 103365] [GLK] gem_fd_exhaustion produces file-max limit 377904 reached

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

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

--- Comment #1 from Chris Wilson  ---
commit 07f515979e06d4fdc6d09daa19335e91083a96f8 (HEAD, upstream/master)
Author: Chris Wilson 
Date:   Fri Oct 20 11:18:01 2017 +0100

igt/gem_fd_exhaustion: Remove stale assert

__gem_create() doesn't touch the outparam *handle on failure, so we can
no longer assert that it zero. This is reasonable to remove as it is just
testing the library itself and not the kernel, so no loss in coverage.
We already had to remove the false assertion that gem_create() must fail
following fd exhaustion (as we can not prevent the kernel from freeing
VFS fdspace in between calls).

-- 
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/i915/selftests: Convert timers to use timer_setup()

[Chris Wilson]

Quoting Chris Wilson (2017-10-24 17:17:09)
> Quoting Kees Cook (2017-10-24 16:13:44)
> > In preparation for unconditionally passing the struct timer_list pointer to
> > all timer callbacks, switch to using the new timer_setup() and from_timer()
> > to pass the timer pointer explicitly.
> > 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Cc: Rodrigo Vivi 
> > Cc: David Airlie 
> > Cc: Tvrtko Ursulin 
> > Cc: Chris Wilson 
> > Cc: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Kees Cook 
> 
> Thank you for saving me from having to do this myself,
> Reviewed-by: Chris Wilson 

I've a small batch of selftests patches queued, so added this one and
will push to drm-intel-next-queued shortly.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: assign fb_location only if bo is pinned

[Michel Dänzer]

On 25/10/17 12:05 PM, S, Shirish wrote:
> Hi Alex, Michel & Andrey,
> 
>  [PATCH] drm/amd/display: assign fb_location only if bo is pinned
>  [PATCH 2/2] drm/amd/display: cleanup addReq and fix fb_location
> 
> should be dropped and instead:

Since you pushed the latter to amd-staging-drm-next, please revert it
there, or maybe submit another patch removing all fb_location related
code from get_fb_info and fill_plane_attributes_from_fb.


> [PATCH] drm/amd/display: fix high part address in dm_plane_helper_prepare_fb()
> 
> should be reviewed .

Reviewed-by: Michel Dänzer 

But please wait for review from DC folks.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/9] drm/panel: simple: add support for overriding the pixel clock polarity

[Lothar Waßmann]

Hi,

On Tue, 17 Oct 2017 14:45:04 +0200 Thierry Reding wrote:
> On Tue, Oct 17, 2017 at 02:25:07PM +0200, Lothar Waßmann wrote:
> > Hi,
> > 
> > On Tue, 17 Oct 2017 14:14:22 +0200 Thierry Reding wrote:
> > > On Wed, Oct 11, 2017 at 01:23:36PM +0200, Lothar Waßmann wrote:
> > > > The Ka-Ro electronics MB7 baseboard has an on-board LCD->LVDS
> > > > converter that requires a fixed pixelclk polarity, no matter what the
> > > > panel's display_mode specifies. Add an option to override the pixelclk
> > > > polarity defined in the panel's display_mode via DTB.
> > > 
> > > I'd argue that the LCD->LVDS converter should be modelled specifically
> > > in DT to handle this case. It could be a implemented as a DRM bridge
> > > driver, for example.
> > > 
> > IMO that's just overkill for a simple chip that is in no way
> > configurable nor detectable by software.
> 
> I suspect that you're not the only one who runs a board that has this
> kind of quirk. If we solve this in a generic way we can point people in
> that direction when they come asking for such a quirk.
> 
> So this could be something very simple that's instantiated using maybe a
> couple of lines of code.
> 
I found the drivers/gpu/drm/bridge/lvds-encoder.c driver which on first
glance is more or less what I would need. But the driver is currently
dysfunctional due to:
|commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
|Author: Eric Anholt 
|Date:   Fri Jun 2 13:25:14 2017 -0700
|
|drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

Also there is no in-kernel user of this driver, so that it obviously
doesn't get tested in any way.
There is only one dts file (r8a7779-marzen.dts) that instantiate this
driver, but it has an incomplete OF graph. The missing link for the
OF graph is provided by either r8a77xx-aa104xd12-panel.dtsi or
r8a77xx-aa121td01-panel.dtsi, but those files are referenced nowhere in
the kernel source.

Reverting the part of the above mentioned patch that touches
lvds-encoder.c makes the driver functional, but I see no way to use
this driver to enforce specific bus_flags for the interface, since the
code is run prior to the simple-panel's initialization, which would
override whatever settings might have been provided by the lvds-encoder
driver.

Can someone enligthen me, how to enforce specific bus_flags/bus_format
settings for an LCD interface driven by the simple-panel driver apart
from doing it in the simple-panel driver itself?


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

Re: Unicode characters in commit messages?

[SF Markus Elfring]

> These long email threads are a waste of time

They occur for different topics.


> when we already answered your questions completely

There were some attempts for specific details.


> and over and over.

I hope that further useful adjustments can be achieved for
involved information sources.


> The feedback was clear.

I disagree on some aspects.

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

[Bug 103443] [CI] igt@kms_setmode@[clone-exclusive-crtc | invalid-clone-exclusive-crtc] - warn - no modes for connector 76

[bugzilla-daemon]

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

--- Comment #1 from Marta Löfstedt  ---
Instead of changing this from pass to fail, why not also fix the whole issue of
no modes available in igt.

-- 
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: Unicode characters in commit messages?

[Dan Carpenter]

On Wed, Oct 25, 2017 at 09:39:39AM +0200, SF Markus Elfring wrote:
> >> Would you like to support Unicode characters there?
> > 
> > Multiple people have answered this question already and I have answered
> > it multiple times.
> 
> I found the corresponding feedback not sufficient so far to reach
> a final consensus.

Markus, you really have to listen better or you're going to get banned
from more subsystems.  These long email threads are a waste of time when
we already answered your questions completely and over and over.  The
feedback was clear.

regards,
dan carpenter

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

Re: [PATCH] drm/amd/display: assign fb_location only if bo is pinned

[Michel Dänzer]

On 25/10/17 07:18 AM, S, Shirish wrote:
>
> Andrey,
> Till now the get_fb_info() never calculated fb_location(as addrReq was
> always false), but since now its required to program the high part of
> the address structure,
> can you move it back into the commit scope and ensure that fb_location
> is calculated everytime.(I have limited knowledge behind why it was
> moved out)
> And in case if you insist on adding pin & unpin in atomic_check() scope
> i can post a patch for it.

The latter on its own couldn't really solve the problem anyway: While a
BO is unpinned, its MC address can change at any time. The MC address
programmed to the hardware must be determined while the BO is and stays
pinned.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/6] drm/rockchip/dsi: add dual mipi channel support

[Sean Paul]

On Wed, Oct 25, 2017 at 11:51:01AM +0800, Nickey Yang wrote:
> This patch add dual mipi channel support:
> 1.add definition of dsi1 register and grf operation.
> 2.dsi0 and dsi1 will work in master and slave mode
> when driving dual mipi panel.
> 
> Signed-off-by: Nickey Yang 
> ---

In the last revision, I asked you to provide changelog between revisions,
*please* do this. You received review on the last version and a bunch of the
feedback hasn't been taken into account with no explanation as to why. Please go
back to the last version, read the reviews that people were generous enough to
give and either fix the code or explain why you're not.

>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 377 
> 
>  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 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   1 +
>  5 files changed, 279 insertions(+), 105 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 589b420..25e7b77 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c



> +static int rockchip_dsi_dual_channel_probe(struct dw_mipi_dsi *dsi)
> +{
> + struct device_node *np;
> + struct platform_device *secondary;
> +
> + np = of_parse_phandle(dsi->dev->of_node, "rockchip,dual-channel", 0);
> + if (np) {
> + secondary = of_find_device_by_node(np);
> + dsi->slave = platform_get_drvdata(secondary);
> + of_node_put(np);
> +
> + if (!dsi->slave)
> + return -EPROBE_DEFER;

Archit asked you not to do this in the previous review.

> +
> + dsi->slave->master = dsi;
> + }
> +
> + return 0;
> +}



> -- 
> 1.9.1
> 

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

[Bug 91221] UVD: GPU lockup with BARTS

[bugzilla-daemon]

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

--- Comment #6 from Roman Elshin  ---
You may try to use vdpau decoding with opengl video out (if it not this case),
for me it much more stable than using vdpau decoding with vdpau video out (at
least with rv730 agp card).

-- 
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 v3 3/6] drm/rockchip/dsi: correct Feedback divider setting

[Sean Paul]

On Wed, Oct 25, 2017 at 11:51:00AM +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 
> ---

You don't list the changes between this version and the previous ones, so I 
looked
at the feedback from the last time. Archit asked a question about moving to
dw-mipi-dsi, and Kristian asked you to split the patch for each line item in the
above list. I know you split out the register definitions, but an explanation
about why you didn't split the rest would be helpful.

In future, list the changes between patches and Cc people who have given you
review on your previous versions (I've cc'd Archit and Kristian).

Sean


>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 93 
> ++
>  1 file changed, 62 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 09e7bfe..589b420 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -239,7 +239,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)
>  
> @@ -531,6 +531,14 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   dw_mipi_dsi_phy_write(dsi, PLL_LOOP_DIVIDER_RATIO,
> LOOP_DIV_LOW_SEL(dsi->feedback_div) |
> LOW_PROGRAM_EN);
> + /*
> +  * we need set PLL_INPUT_AND_LOOP_DIVIDER_RATIOS_CONTROL immediately
> +  * to make the configrued LSB effective according to IP simulation
> +  * and lab test results.
> +  * Only in this way can we get correct mipi phy pll frequency.
> +  */
> + dw_mipi_dsi_phy_write(dsi, PLL_INPUT_AND_LOOP_DIVIDER_RATIOS_CONTROL,
> +   PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
>   dw_mipi_dsi_phy_write(dsi, PLL_LOOP_DIVIDER_RATIO,
> LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
> HIGH_PROGRAM_EN);
> @@ -604,11 +612,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 = dppa_map[ARRAY_SIZE(dppa_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 = ULONG_MAX;
>  
>   bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
>   if (bpp < 0) {
> @@ -629,35 +642,53 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
> *dsi,
> "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++) {
> + u64 tmp;
> + 

[PATCH v2 00/12] drm: panel: replace dev_info/dev_err/dev_warn with DRM_DEV_*equivalent

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formwatted specific log messages.

Changes in v2:
- split the original patch for each driver

Aastha Gupta (12):
  drm: panel: replace dev_* with DRM_DEV_* equivalent in
panel-innolux-p079zca
  drm: panel: replace dev_* with DRM_DEV_* equivalent in 
panel-jdi-lt070me05000
  drm: panel: replace dev_* with DRM_DEV_* equivalent in
panel-sitronix-st7789v
  drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-simple
  drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-lg-lg4573
  drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-lvds
  drm: panel: replace dev_* with DRM_DEV_* equivalent in
panel-panasonic-vvx10f034n00
  drm: panel: replace dev_* with DRM_DEV_* equivalent in
panel-samsung-ld9040
  drm: panel: replace dev_* with DRM_DEV_* equivalent in
panel-samsung-s6e8aa0
  drm: panel: replace dev_* with DRM_DEV_* equivalent in
panel-samsung-s6e3ha2
  drm: panel: replace dev_* with DRM_DEV_* equivalent in
panel-sharp-ls043t1le01
  drm: panel: replace dev_* with DRM_DEV_* equivalent in
panel-sharp-lq101r1sx01

 drivers/gpu/drm/panel/panel-innolux-p079zca.c  |  2 +-
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 38 +++---
 drivers/gpu/drm/panel/panel-lg-lg4573.c| 18 +++
 drivers/gpu/drm/panel/panel-lvds.c | 28 +-
 .../gpu/drm/panel/panel-panasonic-vvx10f034n00.c   | 13 ++---
 drivers/gpu/drm/panel/panel-samsung-ld9040.c   | 12 ++---
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 14 ++---
 drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c  | 28 +-
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c| 60 +-
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c| 21 
 drivers/gpu/drm/panel/panel-simple.c   | 15 +++---
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c |  8 +--
 12 files changed, 141 insertions(+), 116 deletions(-)

-- 
2.7.4

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

Re: [PATCH v3 2/6] drm/rockchip/dsi: correct phy parameter setting

[Sean Paul]

On Wed, Oct 25, 2017 at 11:50:59AM +0800, Nickey Yang wrote:
> As MIPI PHY document show, icpctrl<3..0> and lpfctrl<5..0>
> should depend on frequency,so fix it.
> 
> Reviewed-by: Sean Paul 
> Reviewed-by: Matthias Kaehlcke 
> Signed-off-by: Nickey Yang 
> ---

In future, please list the differences between versions. It makes reviewing much
easier.

Thanks,

Sean

>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 98 
> --
>  1 file changed, 70 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 95ce253..09e7bfe 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -217,10 +217,21 @@
>  #define VCO_IN_CAP_CON_HIGH  (0x2 << 1)
>  #define REF_BIAS_CUR_SEL BIT(0)
>  
> -#define CP_CURRENT_3MA   BIT(3)
> +#define CP_CURRENT_1_5UA 0x1
> +#define CP_CURRENT_4_5UA 0x2
> +#define CP_CURRENT_7_5UA 0x6
> +#define CP_CURRENT_6UA   0x9
> +#define CP_CURRENT_12UA  0xb
> +#define CP_CURRENT_SEL(val)  ((val) & 0xf)
>  #define CP_PROGRAM_ENBIT(7)
> +
> +#define LPF_RESISTORS_15_5KOHM   0x1
> +#define LPF_RESISTORS_13KOHM 0x2
> +#define LPF_RESISTORS_11_5KOHM   0x4
> +#define LPF_RESISTORS_10_5KOHM   0x8
> +#define LPF_RESISTORS_8KOHM  0x10
>  #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)
>  
> @@ -339,32 +350,63 @@ 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[] = {
> + {  89, 0x00, CP_CURRENT_1_5UA, LPF_RESISTORS_13KOHM},
> + {  99, 0x10, CP_CURRENT_1_5UA, LPF_RESISTORS_13KOHM},
> + { 109, 0x20, CP_CURRENT_1_5UA, LPF_RESISTORS_13KOHM},
> + { 129, 0x01, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
> + { 139, 0x11, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
> + { 149, 0x21, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
> + { 169, 0x02, CP_CURRENT_6UA, LPF_RESISTORS_13KOHM},
> + { 179, 0x12, CP_CURRENT_6UA, LPF_RESISTORS_13KOHM},
> + { 199, 0x22, CP_CURRENT_6UA, LPF_RESISTORS_13KOHM},
> + { 219, 0x03, CP_CURRENT_4_5UA, LPF_RESISTORS_13KOHM},
> + { 239, 0x13, CP_CURRENT_4_5UA, LPF_RESISTORS_13KOHM},
> + { 249, 0x23, CP_CURRENT_4_5UA, LPF_RESISTORS_13KOHM},
> + { 269, 0x04, CP_CURRENT_6UA, LPF_RESISTORS_11_5KOHM},
> + { 299, 0x14, CP_CURRENT_6UA, LPF_RESISTORS_11_5KOHM},
> + { 329, 0x05, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
> + { 359, 0x15, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
> + { 399, 0x25, CP_CURRENT_1_5UA, LPF_RESISTORS_15_5KOHM},
> + { 449, 0x06, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
> + { 499, 0x16, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
> + { 549, 0x07, CP_CURRENT_7_5UA, LPF_RESISTORS_10_5KOHM},
> + { 599, 0x17, CP_CURRENT_7_5UA, LPF_RESISTORS_10_5KOHM},
> + { 649, 0x08, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
> + { 699, 0x18, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
> + { 749, 0x09, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
> + { 799, 0x19, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
> + { 849, 0x29, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
> + { 899, 0x39, CP_CURRENT_7_5UA, LPF_RESISTORS_11_5KOHM},
> + { 949, 0x0a, CP_CURRENT_12UA, LPF_RESISTORS_8KOHM},
> + { 999, 0x1a, CP_CURRENT_12UA, LPF_RESISTORS_8KOHM},
> + {1049, 0x2a, CP_CURRENT_12UA, LPF_RESISTORS_8KOHM},
> + {1099, 0x3a, CP_CURRENT_12UA, LPF_RESISTORS_8KOHM},
> + {1149, 0x0b, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
> + {1199, 0x1b, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
> + {1249, 0x2b, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
> + {1299, 0x3b, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
> + {1349, 0x0c, CP_CURRENT_12UA, LPF_RESISTORS_10_5KOHM},
> +   

[PATCH] video: fbdev: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly. One tracking pointer was added, and
one initialization was cleaned up.

Cc: Bartlomiej Zolnierkiewicz 
Cc: Benjamin Herrenschmidt 
Cc: Tomi Valkeinen 
Cc: David Lechner 
Cc: Daniel Vetter 
Cc: Sean Paul 
Cc: Jean Delvare 
Cc: Hans de Goede 
Cc: "Gustavo A. R. Silva" 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-o...@vger.kernel.org
Signed-off-by: Kees Cook 
---
 drivers/video/fbdev/aty/radeon_base.c  |  8 +++-
 drivers/video/fbdev/core/fbcon.c   | 10 +-
 drivers/video/fbdev/core/fbcon.h   |  1 +
 drivers/video/fbdev/omap/hwa742.c  |  6 ++
 drivers/video/fbdev/omap2/omapfb/dss/dsi.c |  6 ++
 drivers/video/fbdev/pxa3xx-gcu.c   | 12 
 6 files changed, 17 insertions(+), 26 deletions(-)

diff --git a/drivers/video/fbdev/aty/radeon_base.c 
b/drivers/video/fbdev/aty/radeon_base.c
index 8ad1643e7d1c..4d77daeecf99 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -1454,9 +1454,9 @@ static void radeon_write_pll_regs(struct radeonfb_info 
*rinfo, struct radeon_reg
 /*
  * Timer function for delayed LVDS panel power up/down
  */
-static void radeon_lvds_timer_func(unsigned long data)
+static void radeon_lvds_timer_func(struct timer_list *t)
 {
-   struct radeonfb_info *rinfo = (struct radeonfb_info *)data;
+   struct radeonfb_info *rinfo = from_timer(rinfo, t, lvds_timer);
 
radeon_engine_idle();
 
@@ -2291,9 +2291,7 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo->pdev = pdev;

spin_lock_init(>reg_lock);
-   init_timer(>lvds_timer);
-   rinfo->lvds_timer.function = radeon_lvds_timer_func;
-   rinfo->lvds_timer.data = (unsigned long)rinfo;
+   timer_setup(>lvds_timer, radeon_lvds_timer_func, 0);
 
c1 = ent->device >> 8;
c2 = ent->device & 0xff;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 04612f938bab..3b4a96379128 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -395,10 +395,10 @@ static void fb_flashcursor(struct work_struct *work)
console_unlock();
 }
 
-static void cursor_timer_handler(unsigned long dev_addr)
+static void cursor_timer_handler(struct timer_list *t)
 {
-   struct fb_info *info = (struct fb_info *) dev_addr;
-   struct fbcon_ops *ops = info->fbcon_par;
+   struct fbcon_ops *ops = from_timer(ops, t, cursor_timer);
+   struct fb_info *info = ops->info;
 
queue_work(system_power_efficient_wq, >queue);
mod_timer(>cursor_timer, jiffies + ops->cur_blink_jiffies);
@@ -414,8 +414,7 @@ static void fbcon_add_cursor_timer(struct fb_info *info)
if (!info->queue.func)
INIT_WORK(>queue, fb_flashcursor);
 
-   setup_timer(>cursor_timer, cursor_timer_handler,
-   (unsigned long) info);
+   timer_setup(>cursor_timer, cursor_timer_handler, 0);
mod_timer(>cursor_timer, jiffies + ops->cur_blink_jiffies);
ops->flags |= FBCON_FLAGS_CURSOR_TIMER;
}
@@ -714,6 +713,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, 
struct fb_info *info,
 
if (!err) {
ops->cur_blink_jiffies = HZ / 5;
+   ops->info = info;
info->fbcon_par = ops;
 
if (vc)
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 18f3ac144237..9f7744fbc962 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -69,6 +69,7 @@ struct fbcon_ops {
struct timer_list cursor_timer; /* Cursor timer */
struct fb_cursor cursor_state;
struct display *p;
+   struct fb_info *info;
 intcurrcon;/* Current VC. */
intcur_blink_jiffies;
intcursor_flash;
diff --git a/drivers/video/fbdev/omap/hwa742.c 
b/drivers/video/fbdev/omap/hwa742.c
index a4ee65b8f918..6199d4806193 100644
--- a/drivers/video/fbdev/omap/hwa742.c
+++ b/drivers/video/fbdev/omap/hwa742.c
@@ -474,7 +474,7 @@ static void auto_update_complete(void *data)
  jiffies + HWA742_AUTO_UPDATE_TIME);
 }
 
-static void hwa742_update_window_auto(unsigned long arg)
+static void hwa742_update_window_auto(struct timer_list *unused)
 {
LIST_HEAD(req_list);
struct hwa742_request *last;
@@ -1002,9 +1002,7 @@ static int hwa742_init(struct omapfb_device *fbdev, int 
ext_mode,

Re: drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

[Daniele Nicolodi]

On 10/24/17 9:01 AM, SF Markus Elfring wrote:
>>> Do you prefer to delegate the proposed software refactoring
>>> only to a corresponding optimiser?
>>
>> yes.
> 
> Will any applications around the semantic patch language
> (Coccinelle software) fit also in the preferred tool category?

What do you think of quantum computing as a solution instead?

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

Re: drivers/gpu/drm/gma500/mdfld_intel_display.c:102:37: warning: bitwise comparison always evaluates to false [-Wtautological-compare]

[David Binderman]

Hello there,


Code I looked at is in linux-4.14-rc6, released 20171023, so reasonably

up to date.


I did a further check on github.com/torvalds/linux and the code

looks wrong there, too.


So I don't see the fix you mentioned in either of the places I looked.


Regards


David Binderman


From: Jani Nikula 
Sent: 24 October 2017 08:54
To: David Binderman; patrik.r.jakobs...@gmail.com; airl...@linux.ie; 
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: drivers/gpu/drm/gma500/mdfld_intel_display.c:102:37: warning: 
bitwise comparison always evaluates to false [-Wtautological-compare]

On Mon, 23 Oct 2017, David Binderman  wrote:
> Hello there,
>
> Source code is
>
> if ((temp & PIPEACONF_PIPE_STATE) == 1)
> break;
>
> but
>
> $ fgrep PIPEACONF_PIPE_STATE `find drivers/gpu/drm/gma500 -name \*.h -print`
> drivers/gpu/drm/gma500/psb_intel_reg.h:#define PIPEACONF_PIPE_STATE   
> (1 << 30)
> $
>
> Suggest new code
>
> if ((temp & PIPEACONF_PIPE_STATE) != 0)
> break;

Suggest looking at latest sources. ;)

Fixed by 67a3b63a54cb ("drm: gma500: fix logic error").

BR,
Jani.

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

[PATCH v2 12/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-sharp-lq101r1sx01

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 60 +++--
 1 file changed, 37 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 3cce3ca..42a9d4d 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -57,14 +57,14 @@ static int sharp_panel_write(struct sharp_panel *sharp, u16 
offset, u8 value)
 
err = mipi_dsi_generic_write(dsi, payload, sizeof(payload));
if (err < 0) {
-   dev_err(>dev, "failed to write %02x to %04x: %zd\n",
-   value, offset, err);
+   DRM_DEV_ERROR(>dev, "failed to write %02x to %04x: %zd\n",
+ value, offset, err);
return err;
}
 
err = mipi_dsi_dcs_nop(dsi);
if (err < 0) {
-   dev_err(>dev, "failed to send DCS nop: %zd\n", err);
+   DRM_DEV_ERROR(>dev, "failed to send DCS nop: %zd\n", err);
return err;
}
 
@@ -83,8 +83,9 @@ static __maybe_unused int sharp_panel_read(struct sharp_panel 
*sharp,
err = mipi_dsi_generic_read(sharp->link1, , sizeof(offset),
value, sizeof(*value));
if (err < 0)
-   dev_err(>link1->dev, "failed to read from %04x: %zd\n",
-   offset, err);
+   DRM_DEV_ERROR(>link1->dev,
+ "failed to read from %04x: %zd\n",
+ offset, err);
 
return err;
 }
@@ -118,11 +119,13 @@ static int sharp_panel_unprepare(struct drm_panel *panel)
 
err = mipi_dsi_dcs_set_display_off(sharp->link1);
if (err < 0)
-   dev_err(panel->dev, "failed to set display off: %d\n", err);
+   DRM_DEV_ERROR(panel->dev,
+ "failed to set display off: %d\n", err);
 
err = mipi_dsi_dcs_enter_sleep_mode(sharp->link1);
if (err < 0)
-   dev_err(panel->dev, "failed to enter sleep mode: %d\n", err);
+   DRM_DEV_ERROR(panel->dev,
+ "failed to enter sleep mode: %d\n", err);
 
msleep(120);
 
@@ -141,26 +144,30 @@ static int sharp_setup_symmetrical_split(struct 
mipi_dsi_device *left,
 
err = mipi_dsi_dcs_set_column_address(left, 0, mode->hdisplay / 2 - 1);
if (err < 0) {
-   dev_err(>dev, "failed to set column address: %d\n", err);
+   DRM_DEV_ERROR(>dev,
+ "failed to set column address: %d\n", err);
return err;
}
 
err = mipi_dsi_dcs_set_page_address(left, 0, mode->vdisplay - 1);
if (err < 0) {
-   dev_err(>dev, "failed to set page address: %d\n", err);
+   DRM_DEV_ERROR(>dev,
+ "failed to set page address: %d\n", err);
return err;
}
 
err = mipi_dsi_dcs_set_column_address(right, mode->hdisplay / 2,
  mode->hdisplay - 1);
if (err < 0) {
-   dev_err(>dev, "failed to set column address: %d\n", err);
+   DRM_DEV_ERROR(>dev,
+ "failed to set column address: %d\n", err);
return err;
}
 
err = mipi_dsi_dcs_set_page_address(right, 0, mode->vdisplay - 1);
if (err < 0) {
-   dev_err(>dev, "failed to set page address: %d\n", err);
+   DRM_DEV_ERROR(>dev,
+ "failed to set page address: %d\n", err);
return err;
}
 
@@ -190,7 +197,8 @@ static int sharp_panel_prepare(struct drm_panel *panel)
 
err = mipi_dsi_dcs_exit_sleep_mode(sharp->link1);
if (err < 0) {
-   dev_err(panel->dev, "failed to exit sleep mode: %d\n", err);
+   DRM_DEV_ERROR(panel->dev,
+ "failed to exit sleep mode: %d\n", err);
goto poweroff;
}
 
@@ -206,20 +214,23 @@ static int sharp_panel_prepare(struct drm_panel *panel)
/* set left-right mode */
err = sharp_panel_write(sharp, 0x1000, 0x2a);
if (err < 0) {
-   dev_err(panel->dev, "failed to set left-right mode: %d\n", err);
+   DRM_DEV_ERROR(panel->dev,
+  

Re: [RESEND PATCH] drm/hisilicon: Ensure LDI regs are properly configured.

[liuxinliang]

Hi Peter,


On 2017/10/24 1:34, Peter Griffin wrote:

Hi Xinliang,

On 28 August 2017 at 10:27, Xinliang Liu > wrote:


Hi Daniel,

On 28 August 2017 at 16:51, Daniel Vetter > wrote:
> On Mon, Aug 28, 2017 at 04:44:30PM +0800, Xinliang Liu wrote:
>> Hi,
>>
>> On 15 August 2017 at 22:14, Peter Griffin
> wrote:
>>
>> > This patch fixes the following soft lockup:
>> >   BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
>> >
>> > On weston idle-timeout the IP is powered down and reset
>> > asserted. On weston resume we get a massive vblank
>> > IRQ storm due to the LDI registers having lost some state.
>> >
>> > This state loss is caused by ade_crtc_atomic_begin() not
>> > calling ade_ldi_set_mode(). With this patch applied
>> > resuming from Weston idle-timeout works well.
>> >
>> > Signed-off-by: Peter Griffin >
>> > Tested-by: John Stultz >
>> >
>>
>> Thanks Peter,
>> This patch looks good to me.
>> Reviewed-by: Xinliang Liu >
>>
>> @Sean, could you please help to apply to drm-misc if others has
no more
>> comments, thanks.
>
> hisilicon isn't maintained in drm-misc, and you're the
maintainer. This is
> not how it works. So either
> a) pick up the patch and send out a pull request to Dave Airlie
> b) move hisilicon over to drm-misc and become a drm-misc maintainer
> yourself. This needs a MAINTAINERS update to point the git tree at
> drm-misc.
>
> drm-misc maintainers don't maintain everyone else's driver as a
service,
> that simply doesn't scale.

Sorry for my misunderstanding and thanks for pointing out that how
drm-misc works.
So I will pick up the patch and send a pull request.


Did you send the pull request?

I still can't see this patch in the latest kernel RC.
I have sent in last cycle, it seems it didn't catch last cycle. Maybe I 
need to resend again this cycle.

Will send soon.

Thanks,
Xinliang


Peter.


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

[PATCH v2 10/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-samsung-s6e3ha2

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 797bbc7..583f96f 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -454,7 +454,7 @@ static int s6e3ha2_set_brightness(struct backlight_device 
*bl_dev)
 
if (brightness < S6E3HA2_MIN_BRIGHTNESS ||
brightness > bl_dev->props.max_brightness) {
-   dev_err(ctx->dev, "Invalid brightness: %u\n", brightness);
+   DRM_DEV_ERROR(ctx->dev, "Invalid brightness: %u\n", brightness);
return -EINVAL;
}
 
@@ -702,28 +702,28 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
  ctx->supplies);
if (ret < 0) {
-   dev_err(dev, "failed to get regulators: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to get regulators: %d\n", ret);
return ret;
}
 
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset_gpio)) {
-   dev_err(dev, "cannot get reset-gpios %ld\n",
-   PTR_ERR(ctx->reset_gpio));
+   DRM_DEV_ERROR(dev, "cannot get reset-gpios %ld\n",
+ PTR_ERR(ctx->reset_gpio));
return PTR_ERR(ctx->reset_gpio);
}
 
ctx->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->enable_gpio)) {
-   dev_err(dev, "cannot get enable-gpios %ld\n",
-   PTR_ERR(ctx->enable_gpio));
+   DRM_DEV_ERROR(dev, "cannot get enable-gpios %ld\n",
+ PTR_ERR(ctx->enable_gpio));
return PTR_ERR(ctx->enable_gpio);
}
 
ctx->bl_dev = backlight_device_register("s6e3ha2", dev, ctx,
_bl_ops, NULL);
if (IS_ERR(ctx->bl_dev)) {
-   dev_err(dev, "failed to register backlight device\n");
+   DRM_DEV_ERROR(dev, "failed to register backlight device\n");
return PTR_ERR(ctx->bl_dev);
}
 
-- 
2.7.4

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

[PATCH] drm: gma500: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Patrik Jakobsson 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/gma500/psb_lid.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_lid.c b/drivers/gpu/drm/gma500/psb_lid.c
index 1d2ebb5e530f..be6dda58fcae 100644
--- a/drivers/gpu/drm/gma500/psb_lid.c
+++ b/drivers/gpu/drm/gma500/psb_lid.c
@@ -23,9 +23,9 @@
 #include "psb_intel_reg.h"
 #include 
 
-static void psb_lid_timer_func(unsigned long data)
+static void psb_lid_timer_func(struct timer_list *t)
 {
-   struct drm_psb_private * dev_priv = (struct drm_psb_private *)data;
+   struct drm_psb_private *dev_priv = from_timer(dev_priv, t, lid_timer);
struct drm_device *dev = (struct drm_device *)dev_priv->dev;
struct timer_list *lid_timer = _priv->lid_timer;
unsigned long irq_flags;
@@ -77,10 +77,8 @@ void psb_lid_timer_init(struct drm_psb_private *dev_priv)
spin_lock_init(_priv->lid_lock);
spin_lock_irqsave(_priv->lid_lock, irq_flags);
 
-   init_timer(lid_timer);
+   timer_setup(lid_timer, psb_lid_timer_func, 0);
 
-   lid_timer->data = (unsigned long)dev_priv;
-   lid_timer->function = psb_lid_timer_func;
lid_timer->expires = jiffies + PSB_LID_DELAY;
 
add_timer(lid_timer);
-- 
2.7.4


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

[PATCH v2 11/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-sharp-ls043t1le01

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index 3aeb0bd..e6ed6e7 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -137,7 +137,7 @@ static int sharp_nt_panel_unprepare(struct drm_panel *panel)
 
ret = sharp_nt_panel_off(sharp_nt);
if (ret < 0) {
-   dev_err(panel->dev, "failed to set panel off: %d\n", ret);
+   DRM_DEV_ERROR(panel->dev, "failed to set panel off: %d\n", ret);
return ret;
}
 
@@ -175,13 +175,13 @@ static int sharp_nt_panel_prepare(struct drm_panel *panel)
 
ret = sharp_nt_panel_init(sharp_nt);
if (ret < 0) {
-   dev_err(panel->dev, "failed to init panel: %d\n", ret);
+   DRM_DEV_ERROR(panel->dev, "failed to init panel: %d\n", ret);
goto poweroff;
}
 
ret = sharp_nt_panel_on(sharp_nt);
if (ret < 0) {
-   dev_err(panel->dev, "failed to set panel on: %d\n", ret);
+   DRM_DEV_ERROR(panel->dev, "failed to set panel on: %d\n", ret);
goto poweroff;
}
 
@@ -232,9 +232,9 @@ static int sharp_nt_panel_get_modes(struct drm_panel *panel)
 
mode = drm_mode_duplicate(panel->drm, _mode);
if (!mode) {
-   dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   DRM_DEV_ERROR(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
+ default_mode.hdisplay, default_mode.vdisplay,
+ default_mode.vrefresh);
return -ENOMEM;
}
 
@@ -270,8 +270,8 @@ static int sharp_nt_panel_add(struct sharp_nt_panel 
*sharp_nt)
 
sharp_nt->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(sharp_nt->reset_gpio)) {
-   dev_err(dev, "cannot get reset-gpios %ld\n",
-   PTR_ERR(sharp_nt->reset_gpio));
+   DRM_DEV_ERROR(dev, "cannot get reset-gpios %ld\n",
+ PTR_ERR(sharp_nt->reset_gpio));
sharp_nt->reset_gpio = NULL;
} else {
gpiod_set_value(sharp_nt->reset_gpio, 0);
@@ -346,11 +346,12 @@ static int sharp_nt_panel_remove(struct mipi_dsi_device 
*dsi)
 
ret = sharp_nt_panel_disable(_nt->base);
if (ret < 0)
-   dev_err(>dev, "failed to disable panel: %d\n", ret);
+   DRM_DEV_ERROR(>dev, "failed to disable panel: %d\n", ret);
 
ret = mipi_dsi_detach(dsi);
if (ret < 0)
-   dev_err(>dev, "failed to detach from DSI host: %d\n", ret);
+   DRM_DEV_ERROR(>dev,
+ "failed to detach from DSI host: %d\n", ret);
 
drm_panel_detach(_nt->base);
sharp_nt_panel_del(sharp_nt);
-- 
2.7.4

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

Re: [Mesa-dev] XDC 2017 feedback

[Andres Gomez]

Hi,

Just chipping in to leave a couple of additional notes.

As other have said before me, I also think the organization was very
good.

Things mentioned before:

 * Tables layout: kind of agree it was not great for following the
   talks but they were also making it easier to talk with other
   attendees. I have mixed feelings.
 * I agree more power strips would have been welcome.
 * The microphones were having some small problems but it was not too
   bad.

Positive things also mentioned:

 * WiFi worked great.
 * 1 single big room and more time for hallway conversations was good.
 * Food, beverage, snacks, etc. were very good.
 * Google's facilities and staff were great: organization, catering and
   security people. I hope they pass this feedback to them ☺

Additionally:

 * In the "not so good" part; the details (timetable) of the Program
   were published very late (no more than 1 week before the
   conference). I would have liked to know way in advance at what hour
   in the morning the conference was starting. The same with regards to
   the "Social events". I only got to know that there was a "Pre-
   conference social event" the previous evening to the start of the
   conference after that had already happened, for example.

Finally, I took the freedom to complete the Program page with the
missing video links:

https://www.x.org/wiki/Events/XDC2017/Program/


I hope my comments are helpful.

Thanks again for a great conference.

Br.


On Wed, 2017-09-27 at 10:32 -0700, Miguel Angel Vico wrote:
> Hi,
> 
> In general, I think the organization was great. I agree having
> everything happen in a single room was a good point. Here's some of my
> personal feedback:
> 
>  * I didn't like the tables layout at all. I found it to be extremely
>uncomfortable to have to look sideways in order to see the screens
>and presenter.
> 
>  * There were a very few power strips, and not well distributed along
>the tables.
> 
> 
> Also, this is what I've been able to gather from some of my colleagues
> here at NVIDIA::
> 
>  * Some people watching the conference remotely complained about the
>stream quality, and the recordings wouldn't include the presenter.
> 
>In one of the hallway conversations, Martin mentioned in XDC2016
>they had a team of camera experts doing the job, and will try to
>improve that part in future XDC's.
> 
>  * The microphone/audio situation wasn't great either.  I don't know
>how practical it is with something the size of XDC, but at Khronos
>meetings, they usually set up microphones for the audience too, with
>tap-on/tap-off switches, and a ratio of 1:2 or 1:3 for
>microphones:people.  That makes Q a lot easier.  Alternatively,
>having a question queue rather than running mics around the room can
>speed things up, but makes cross-talk harder.
> 
>  * The table/chair layout was really cumbersome. Beyond just the
>orientation, some people had a lot of trouble getting in/out to use
>the restroom, grab snacks, etc.
> 
> 
> On a positive note:
> 
>  * More time for hallway conversations was in general a good thing.
>Some of us got a ton of useful feedback talking to others.
> 
>  * The food was great, and having food on-site gave us even more time
>for hallway-tracking.
> 
>  * Surprisingly, parking was not an issue.
> 
>  * Signage was good, and the security guards were polite/helpful. It
>was easy to find the room and get our badges.
> 
>  * The wifi worked great in general, which is a rarity at conferences.
>It was pretty spotty at XDC 2016.
> 
> 
> Thank you.
> 
> On Tue, 26 Sep 2017 11:49:10 -0700
> Manasi Navare wrote:
> 
> > Hi,
> > 
> > XDC was a really great conference and loved the fact that it was
> > in just one room which kept all the hallway conversations in that room 
> > resulting
> > into more networking.
> > But I agree with Andres that for the videos, it would be great to split the
> > huge youtube video stream per presentation and have seperate links for each
> > talk somewhere on the XDC page.
> > 
> > Regards
> > Manasi
> > 
> > 
> > 
> > On Tue, Sep 26, 2017 at 01:25:15PM -0400, Andres Rodriguez wrote:
> > > Hi,
> > > 
> > > A small piece of feedback from those of us watching remotely. It would be
> > > nice to have a simple to access index for the long livestream videos.
> > > 
> > > I think the XDC 2017 wiki page would be a good place for this 
> > > information. A
> > > brief example:
> > > 
> > > Presentation Title | Presenter Name | Link with timestamp
> > > ---||-
> > > ...| ...| youtu.be/video-id?t=XhYmZs
> > > 
> > > Or alternatively, a list of hyperlinks with the presentation title as text
> > > that point to the correct timestamp in the video would also be sufficient.
> > > 
> > > Really enjoyed the talks, and would like them to be slightly easier to
> > > access and share with others.

RE: Enabling peer to peer device transactions for PCIe devices

[David Laight]

Please don't top post, write shorter lines, and add the odd blank line.
Big blocks of text are hard to read quickly.

> From: Petrosyan, Ludwig [mailto:ludwig.petros...@desy.de]
> Yes I agree it has to be started with the write transaction, according of 
> PCIe standard all write
> transaction are address routed, and I agree with Logan:
> if in write transaction TLP the endpoint address written in header the TLP 
> should not touch CPU, the
> PCIe Switch has to route it to endpoint.

That depends, IIRC there is a feature for PCIe switches to force them
to send all transactions to the root hub.
This is there so that the host can enforce rules to stop p2p transfers.
It might enabled on the switch you have.

> The idea was: in MTCA system there is PCIe Switch on MCH (MTCA crate HUB) 
> this switch connects CPU to
> other Crate Slots, so one port is Upstream and others are Downstream  ports, 
> DMA read from CPU is
> usual write on endpoint side, Xilinx DMA core has two registers Destination 
> Address and Source
> Address,
> device driver to make DMA has to set up these registers,
> usually device driver to start DMA read from Board sets Source address as 
> FPGA memory address and
> Destination address is DMA prepared system address,
> in case of testing p2p I set Destination address as physical address of other 
> endpoint.

Unnecessary detail...

> More detailed:
> we have so called pcie universal driver: the idea behind is
> 1. all pcie configuration staff, find enabled BARs, mapping BARs, usual 
> read/write and common ioctl
> (get slot number, get driver version ...) implemented in universal driver and 
> EXPORTed.
> 2. if some system function in new kernel are changed we change it only in 
> universal parts (easy
> support a big number of drivers )
> so the universal driver something like PCIe Driver API
> 3. the universal driver provides read/writ functions so we have the same 
> device access API for any
> PCIe device, we could use the same user application with any PCIe device

More crap...

> now. during BARs finding and mapping universal driver keeps pcie endpoint 
> physical address in some
> internal structures, any top driver may get physical address
> of other pcie endpoint by slot number.
> in may case during get_resorce the physical address is 0xB200, I check 
> lspci -H1 - -s psie
> switch port bus address (the endpoint connected to this port, checked by 
> lspci -H1 -t) the same
> address (0xB20) is the memory behind bridge,

Overly verbose...

> I want to make p2p writes to offset 0x4, so I set DMA destination address 
> 0xB240
> is something wrong?

Possibly.

You almost certainly need the address that is written into the BAR of the
target endpoint.
This could well be different from the physical address that the cpu uses
to write to the endpoint (as well as the cpu virtual address).

lspci lies [1], run lspci -x  (or hexdump config space through /sys/devices)
to see what is actually in the BAR.

[1] The addresses come from somewhere other than reading the BAR.
If the endpoint resets the BAR lspci will still report the old
addresses.

David

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

[PATCH v2 05/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-lg-lg4573

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-lg-lg4573.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-lg-lg4573.c 
b/drivers/gpu/drm/panel/panel-lg-lg4573.c
index 6989238..77c1c87 100644
--- a/drivers/gpu/drm/panel/panel-lg-lg4573.c
+++ b/drivers/gpu/drm/panel/panel-lg-lg4573.c
@@ -45,7 +45,7 @@ static int lg4573_spi_write_u16(struct lg4573 *ctx, u16 data)
u16 temp = cpu_to_be16(data);
struct spi_message msg;
 
-   dev_dbg(ctx->panel.dev, "writing data: %x\n", data);
+   DRM_DEV_DEBUG(ctx->panel.dev, "writing data: %x\n", data);
xfer.tx_buf = 
spi_message_init();
spi_message_add_tail(, );
@@ -112,7 +112,7 @@ static int lg4573_display_mode_settings(struct lg4573 *ctx)
0x7206, 0x720C, 0x7200, 0x7200,
};
 
-   dev_dbg(ctx->panel.dev, "transfer display mode settings\n");
+   DRM_DEV_DEBUG(ctx->panel.dev, "transfer display mode settings\n");
return lg4573_spi_write_u16_array(ctx, display_mode_settings,
  ARRAY_SIZE(display_mode_settings));
 }
@@ -128,7 +128,7 @@ static int lg4573_power_settings(struct lg4573 *ctx)
0x7263,
};
 
-   dev_dbg(ctx->panel.dev, "transfer power settings\n");
+   DRM_DEV_DEBUG(ctx->panel.dev, "transfer power settings\n");
return lg4573_spi_write_u16_array(ctx, power_settings,
  ARRAY_SIZE(power_settings));
 }
@@ -153,7 +153,7 @@ static int lg4573_gamma_settings(struct lg4573 *ctx)
0x7201, 0x7220, 0x7200, 0x7203,
};
 
-   dev_dbg(ctx->panel.dev, "transfer gamma settings\n");
+   DRM_DEV_DEBUG(ctx->panel.dev, "transfer gamma settings\n");
return lg4573_spi_write_u16_array(ctx, gamma_settings,
  ARRAY_SIZE(gamma_settings));
 }
@@ -162,7 +162,7 @@ static int lg4573_init(struct lg4573 *ctx)
 {
int ret;
 
-   dev_dbg(ctx->panel.dev, "initializing LCD\n");
+   DRM_DEV_DEBUG(ctx->panel.dev, "initializing LCD\n");
 
ret = lg4573_display_mode_settings(ctx);
if (ret)
@@ -216,9 +216,9 @@ static int lg4573_get_modes(struct drm_panel *panel)
 
mode = drm_mode_duplicate(panel->drm, _mode);
if (!mode) {
-   dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   DRM_DEV_ERROR(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
+ default_mode.hdisplay, default_mode.vdisplay,
+ default_mode.vrefresh);
return -ENOMEM;
}
 
@@ -255,7 +255,7 @@ static int lg4573_probe(struct spi_device *spi)
 
ret = spi_setup(spi);
if (ret < 0) {
-   dev_err(>dev, "SPI setup failed: %d\n", ret);
+   DRM_DEV_ERROR(>dev, "SPI setup failed: %d\n", ret);
return ret;
}
 
-- 
2.7.4

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

[PATCH] drm/vc4: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Eric Anholt 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/vc4/vc4_bo.c  |  9 +++--
 drivers/gpu/drm/vc4/vc4_gem.c | 10 --
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 3afdbf4bc10b..ee07e072cd2a 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -461,10 +461,9 @@ static void vc4_bo_cache_time_work(struct work_struct 
*work)
mutex_unlock(>bo_lock);
 }
 
-static void vc4_bo_cache_time_timer(unsigned long data)
+static void vc4_bo_cache_time_timer(struct timer_list *t)
 {
-   struct drm_device *dev = (struct drm_device *)data;
-   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct vc4_dev *vc4 = from_timer(vc4, t, bo_cache.time_timer);
 
schedule_work(>bo_cache.time_work);
 }
@@ -768,9 +767,7 @@ int vc4_bo_cache_init(struct drm_device *dev)
INIT_LIST_HEAD(>bo_cache.time_list);
 
INIT_WORK(>bo_cache.time_work, vc4_bo_cache_time_work);
-   setup_timer(>bo_cache.time_timer,
-   vc4_bo_cache_time_timer,
-   (unsigned long)dev);
+   timer_setup(>bo_cache.time_timer, vc4_bo_cache_time_timer, 0);
 
return 0;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index d0c6bfb68c4e..ce6bca06f937 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -281,10 +281,10 @@ vc4_reset_work(struct work_struct *work)
 }
 
 static void
-vc4_hangcheck_elapsed(unsigned long data)
+vc4_hangcheck_elapsed(struct timer_list *t)
 {
-   struct drm_device *dev = (struct drm_device *)data;
-   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct vc4_dev *vc4 = from_timer(vc4, t, hangcheck.timer);
+   struct drm_device *dev = vc4->dev;
uint32_t ct0ca, ct1ca;
unsigned long irqflags;
struct vc4_exec_info *bin_exec, *render_exec;
@@ -1091,9 +1091,7 @@ vc4_gem_init(struct drm_device *dev)
spin_lock_init(>job_lock);
 
INIT_WORK(>hangcheck.reset_work, vc4_reset_work);
-   setup_timer(>hangcheck.timer,
-   vc4_hangcheck_elapsed,
-   (unsigned long)dev);
+   timer_setup(>hangcheck.timer, vc4_hangcheck_elapsed, 0);
 
INIT_WORK(>job_done_work, vc4_job_done_work);
 
-- 
2.7.4


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

[PATCH v2 04/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-simple

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-simple.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 474fa75..07f8c21 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -111,8 +111,8 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
videomode_from_timing(dt, );
mode = drm_mode_create(drm);
if (!mode) {
-   dev_err(drm->dev, "failed to add mode %ux%u\n",
-   dt->hactive.typ, dt->vactive.typ);
+   DRM_DEV_ERROR(drm->dev, "failed to add mode %ux%u\n",
+ dt->hactive.typ, dt->vactive.typ);
continue;
}
 
@@ -132,8 +132,8 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
 
mode = drm_mode_duplicate(drm, m);
if (!mode) {
-   dev_err(drm->dev, "failed to add mode %ux%u@%u\n",
-   m->hdisplay, m->vdisplay, m->vrefresh);
+   DRM_DEV_ERROR(drm->dev, "failed to add mode %ux%u@%u\n",
+ m->hdisplay, m->vdisplay, m->vrefresh);
continue;
}
 
@@ -210,7 +210,7 @@ static int panel_simple_prepare(struct drm_panel *panel)
 
err = regulator_enable(p->supply);
if (err < 0) {
-   dev_err(panel->dev, "failed to enable supply: %d\n", err);
+   DRM_DEV_ERROR(panel->dev, "failed to enable supply: %d\n", err);
return err;
}
 
@@ -315,7 +315,7 @@ static int panel_simple_probe(struct device *dev, const 
struct panel_desc *desc)
 GPIOD_OUT_LOW);
if (IS_ERR(panel->enable_gpio)) {
err = PTR_ERR(panel->enable_gpio);
-   dev_err(dev, "failed to request GPIO: %d\n", err);
+   DRM_DEV_ERROR(dev, "failed to request GPIO: %d\n", err);
return err;
}
 
@@ -2378,7 +2378,8 @@ static int panel_simple_dsi_remove(struct mipi_dsi_device 
*dsi)
 
err = mipi_dsi_detach(dsi);
if (err < 0)
-   dev_err(>dev, "failed to detach from DSI host: %d\n", err);
+   DRM_DEV_ERROR(>dev,
+ "failed to detach from DSI host: %d\n", err);
 
return panel_simple_remove(>dev);
 }
-- 
2.7.4

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

[PATCH v2 08/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-samsung-ld9040

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-samsung-ld9040.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-ld9040.c 
b/drivers/gpu/drm/panel/panel-samsung-ld9040.c
index 3cf4cf6..a36c2ff 100644
--- a/drivers/gpu/drm/panel/panel-samsung-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-samsung-ld9040.c
@@ -145,7 +145,7 @@ static void ld9040_dcs_write(struct ld9040 *ctx, const u8 
*data, size_t len)
if (ctx->error < 0 || len == 0)
return;
 
-   dev_dbg(ctx->dev, "writing dcs seq: %*ph\n", (int)len, data);
+   DRM_DEV_DEBUG(ctx->dev, "writing dcs seq: %*ph\n", (int)len, data);
ret = ld9040_spi_write_word(ctx, *data);
 
while (!ret && --len) {
@@ -154,8 +154,8 @@ static void ld9040_dcs_write(struct ld9040 *ctx, const u8 
*data, size_t len)
}
 
if (ret) {
-   dev_err(ctx->dev, "error %d writing dcs seq: %*ph\n", ret,
-   (int)len, data);
+   DRM_DEV_ERROR(ctx->dev, "error %d writing dcs seq: %*ph\n", ret,
+ (int)len, data);
ctx->error = ret;
}
 
@@ -338,15 +338,15 @@ static int ld9040_probe(struct spi_device *spi)
 
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
-   dev_err(dev, "cannot get reset-gpios %ld\n",
-   PTR_ERR(ctx->reset_gpio));
+   DRM_DEV_ERROR(dev, "cannot get reset-gpios %ld\n",
+ PTR_ERR(ctx->reset_gpio));
return PTR_ERR(ctx->reset_gpio);
}
 
spi->bits_per_word = 9;
ret = spi_setup(spi);
if (ret < 0) {
-   dev_err(dev, "spi setup failed.\n");
+   DRM_DEV_ERROR(dev, "spi setup failed.\n");
return ret;
}
 
-- 
2.7.4

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

[RESEND PATCH] drm: etnaviv: Replace dev_info with DRM_DEV_INFO

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formwatted specific log messages.

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 4 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 9 +
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index ed9588f..0091a8b 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -125,8 +125,8 @@ static void etnaviv_buffer_dump(struct etnaviv_gpu *gpu,
u32 size = buf->size;
u32 *ptr = buf->vaddr + off;
 
-   dev_info(gpu->dev, "virt %p phys 0x%08x free 0x%08x\n",
-   ptr, etnaviv_cmdbuf_get_va(buf) + off, size - len * 4 - 
off);
+   DRM_DEV_INFO(gpu->dev, "virt %p phys 0x%08x free 0x%08x\n", ptr,
+etnaviv_cmdbuf_get_va(buf) + off, size - len * 4 - off);
 
print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
ptr, len * 4, 0);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index fc9a6a8..862beac 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -344,8 +344,8 @@ static void etnaviv_hw_identify(struct etnaviv_gpu *gpu)
}
}
 
-   dev_info(gpu->dev, "model: GC%x, revision: %x\n",
-gpu->identity.model, gpu->identity.revision);
+   DRM_DEV_INFO(gpu->dev, "model: GC%x, revision: %x\n",
+gpu->identity.model, gpu->identity.revision);
 
gpu->identity.features = gpu_read(gpu, VIVS_HI_CHIP_FEATURE);
 
@@ -673,7 +673,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
/* Exclude VG cores with FE2.0 */
if (gpu->identity.features & chipFeatures_PIPE_VG &&
gpu->identity.features & chipFeatures_FE20) {
-   dev_info(gpu->dev, "Ignoring GPU with VG and FE2.0\n");
+   DRM_DEV_INFO(gpu->dev, "Ignoring GPU with VG and FE2.0\n");
ret = -ENXIO;
goto fail;
}
@@ -695,7 +695,8 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
else
gpu->memory_base = dma_mask - SZ_2G + 1;
} else if (PHYS_OFFSET >= SZ_2G) {
-   dev_info(gpu->dev, "Need to move linear window on MC1.0, 
disabling TS\n");
+   DRM_DEV_INFO(gpu->dev,
+"Need to move linear window on MC1.0, disabling 
TS\n");
gpu->memory_base = PHYS_OFFSET;
gpu->identity.features &= ~chipFeatures_FAST_CLEAR;
}
-- 
2.7.4

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

Re: Resizable PCI BAR support V9

[Bjorn Helgaas]

On Wed, Oct 18, 2017 at 03:58:16PM +0200, Christian König wrote:
> Hi everyone,
> 
> This is the ninth and hopefully last incarnation of this set of patches. It
> enables device drivers to resize and most likely also relocate the PCI BAR of
> devices they manage to allow the CPU to access all of the device local memory
> at once.
> 
> This is very useful for GFX device drivers where the default PCI BAR is only
> about 256MB in size for compatibility reasons, but the device easily have
> multiple gigabyte of local memory.
> 
> Some changes since the last version:
> 1. Rebased on drm-next, so should be ready to be merged for 4.15.
> 2. The fixup of the 64bit root window on AMD Family 15h CPUs/APUs is only
>enabled when we compile a kernel supporting that hw.
> 3. Some minor error handling improvements for the amdgpu side. We now
>gracefully abort driver loading in case of a critical error instead of
>calling BUG().
> 
> Bjorn any more comments or can we finally get this into 4.15? I will remove 
> the
> version tags from the patches when I send you a pull request if you want this.
> 
> I only work on this as a background task, so sorry for the ~3 month delay
> between each version of the patchset.

I put these (except for the last) on pci/resource for v4.15.  I'd be
happy to merge the last as well if you like.  My tree does not include
drm-next, so there would be a minor conflict when merging upstream.

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

[PATCH] drm/i915/selftests: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/lib_sw_fence.c 
b/drivers/gpu/drm/i915/selftests/lib_sw_fence.c
index 3790fdf44a1a..b26f07b55d86 100644
--- a/drivers/gpu/drm/i915/selftests/lib_sw_fence.c
+++ b/drivers/gpu/drm/i915/selftests/lib_sw_fence.c
@@ -49,9 +49,9 @@ void onstack_fence_fini(struct i915_sw_fence *fence)
i915_sw_fence_fini(fence);
 }
 
-static void timed_fence_wake(unsigned long data)
+static void timed_fence_wake(struct timer_list *t)
 {
-   struct timed_fence *tf = (struct timed_fence *)data;
+   struct timed_fence *tf = from_timer(tf, t, timer);
 
i915_sw_fence_commit(>fence);
 }
@@ -60,7 +60,7 @@ void timed_fence_init(struct timed_fence *tf, unsigned long 
expires)
 {
onstack_fence_init(>fence);
 
-   setup_timer_on_stack(>timer, timed_fence_wake, (unsigned long)tf);
+   timer_setup_on_stack(>timer, timed_fence_wake, 0);
 
if (time_after(expires, jiffies))
mod_timer(>timer, expires);
-- 
2.7.4


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

Re: [v3, 4/6] powerpc: dts: acadia: DT fix s/#interrupts-parent/#interrupt-parent/

[Michael Ellerman]

On Fri, 2017-06-02 at 12:38:47 UTC, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> Acked-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/3d2d4339cc326c427638daa67e264d

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

[PATCH v2 02/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-jdi-lt070me05000

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 38 +-
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 5b2340e..9c29035 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -161,7 +161,7 @@ static int jdi_panel_on(struct jdi_panel *jdi)
 
ret = mipi_dsi_dcs_set_display_on(dsi);
if (ret < 0)
-   dev_err(dev, "failed to set display on: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set display on: %d\n", ret);
 
return ret;
 }
@@ -176,11 +176,11 @@ static void jdi_panel_off(struct jdi_panel *jdi)
 
ret = mipi_dsi_dcs_set_display_off(dsi);
if (ret < 0)
-   dev_err(dev, "failed to set display off: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set display off: %d\n", ret);
 
ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
if (ret < 0)
-   dev_err(dev, "failed to enter sleep mode: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to enter sleep mode: %d\n", ret);
 
msleep(100);
 }
@@ -213,7 +213,7 @@ static int jdi_panel_unprepare(struct drm_panel *panel)
 
ret = regulator_bulk_disable(ARRAY_SIZE(jdi->supplies), jdi->supplies);
if (ret < 0)
-   dev_err(dev, "regulator disable failed, %d\n", ret);
+   DRM_DEV_ERROR(dev, "regulator disable failed, %d\n", ret);
 
gpiod_set_value(jdi->enable_gpio, 0);
 
@@ -237,7 +237,7 @@ static int jdi_panel_prepare(struct drm_panel *panel)
 
ret = regulator_bulk_enable(ARRAY_SIZE(jdi->supplies), jdi->supplies);
if (ret < 0) {
-   dev_err(dev, "regulator enable failed, %d\n", ret);
+   DRM_DEV_ERROR(dev, "regulator enable failed, %d\n", ret);
return ret;
}
 
@@ -254,13 +254,13 @@ static int jdi_panel_prepare(struct drm_panel *panel)
 
ret = jdi_panel_init(jdi);
if (ret < 0) {
-   dev_err(dev, "failed to init panel: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to init panel: %d\n", ret);
goto poweroff;
}
 
ret = jdi_panel_on(jdi);
if (ret < 0) {
-   dev_err(dev, "failed to set panel on: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set panel on: %d\n", ret);
goto poweroff;
}
 
@@ -271,7 +271,7 @@ static int jdi_panel_prepare(struct drm_panel *panel)
 poweroff:
ret = regulator_bulk_disable(ARRAY_SIZE(jdi->supplies), jdi->supplies);
if (ret < 0)
-   dev_err(dev, "regulator disable failed, %d\n", ret);
+   DRM_DEV_ERROR(dev, "regulator disable failed, %d\n", ret);
 
gpiod_set_value(jdi->enable_gpio, 0);
 
@@ -319,9 +319,9 @@ static int jdi_panel_get_modes(struct drm_panel *panel)
 
mode = drm_mode_duplicate(panel->drm, _mode);
if (!mode) {
-   dev_err(dev, "failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   DRM_DEV_ERROR(dev, "failed to add mode %ux%ux@%u\n",
+ default_mode.hdisplay, default_mode.vdisplay,
+ default_mode.vrefresh);
return -ENOMEM;
}
 
@@ -416,35 +416,35 @@ static int jdi_panel_add(struct jdi_panel *jdi)
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(jdi->supplies),
  jdi->supplies);
if (ret < 0) {
-   dev_err(dev, "failed to init regulator, ret=%d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to init regulator, ret=%d\n", ret);
return ret;
}
 
jdi->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
if (IS_ERR(jdi->enable_gpio)) {
ret = PTR_ERR(jdi->enable_gpio);
-   dev_err(dev, "cannot get enable-gpio %d\n", ret);
+   DRM_DEV_ERROR(dev, "cannot get enable-gpio %d\n", ret);
return ret;
}
 
jdi->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(jdi->reset_gpio)) {
ret = PTR_ERR(jdi->reset_gpio);
-   dev_err(dev, "cannot get reset-gpios 

[PATCH v2 03/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-sitronix-st7789v

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c 
b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
index 358c64e..b2e4a05 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
@@ -176,9 +176,9 @@ static int st7789v_get_modes(struct drm_panel *panel)
 
mode = drm_mode_duplicate(panel->drm, _mode);
if (!mode) {
-   dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   DRM_DEV_ERROR(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
+ default_mode.hdisplay, default_mode.vdisplay,
+ default_mode.vrefresh);
return -ENOMEM;
}
 
@@ -389,7 +389,7 @@ static int st7789v_probe(struct spi_device *spi)
 
ctx->reset = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset)) {
-   dev_err(>dev, "Couldn't get our reset line\n");
+   DRM_DEV_ERROR(>dev, "Couldn't get our reset line\n");
return PTR_ERR(ctx->reset);
}
 
-- 
2.7.4

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

[PATCH v2 07/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-panasonic-vvx10f034n00

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c 
b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
index 7f915f7..5e17f84 100644
--- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
+++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
@@ -137,7 +137,7 @@ static int wuxga_nt_panel_prepare(struct drm_panel *panel)
 
ret = wuxga_nt_panel_on(wuxga_nt);
if (ret < 0) {
-   dev_err(panel->dev, "failed to set panel on: %d\n", ret);
+   DRM_DEV_ERROR(panel->dev, "failed to set panel on: %d\n", ret);
goto poweroff;
}
 
@@ -188,9 +188,9 @@ static int wuxga_nt_panel_get_modes(struct drm_panel *panel)
 
mode = drm_mode_duplicate(panel->drm, _mode);
if (!mode) {
-   dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   DRM_DEV_ERROR(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
+ default_mode.hdisplay, default_mode.vdisplay,
+ default_mode.vrefresh);
return -ENOMEM;
}
 
@@ -299,11 +299,12 @@ static int wuxga_nt_panel_remove(struct mipi_dsi_device 
*dsi)
 
ret = wuxga_nt_panel_disable(_nt->base);
if (ret < 0)
-   dev_err(>dev, "failed to disable panel: %d\n", ret);
+   DRM_DEV_ERROR(>dev, "failed to disable panel: %d\n", ret);
 
ret = mipi_dsi_detach(dsi);
if (ret < 0)
-   dev_err(>dev, "failed to detach from DSI host: %d\n", ret);
+   DRM_DEV_ERROR(>dev,
+ "failed to detach from DSI host: %d\n", ret);
 
drm_panel_detach(_nt->base);
wuxga_nt_panel_del(wuxga_nt);
-- 
2.7.4

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

[PATCH v2 01/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-innolux-p079zca

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba9344..02e6720 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -228,7 +228,7 @@ static int innolux_panel_add(struct innolux_panel *innolux)
   GPIOD_OUT_HIGH);
if (IS_ERR(innolux->enable_gpio)) {
err = PTR_ERR(innolux->enable_gpio);
-   dev_dbg(dev, "failed to get enable gpio: %d\n", err);
+   DRM_DEV_DEBUG(dev, "failed to get enable gpio: %d\n", err);
innolux->enable_gpio = NULL;
}
 
-- 
2.7.4

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

[PATCH v2 06/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-lvds

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-lvds.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index e2d57c0..e19ad41 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -143,14 +143,16 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
 
ret = of_property_read_u32(np, "width-mm", >width);
if (ret < 0) {
-   dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
-   np, "width-mm");
+   DRM_DEV_ERROR(lvds->dev,
+ "%pOF: invalid or missing %s DT property\n",
+ np, "width-mm");
return -ENODEV;
}
ret = of_property_read_u32(np, "height-mm", >height);
if (ret < 0) {
-   dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
-   np, "height-mm");
+   DRM_DEV_ERROR(lvds->dev,
+ "%pOF: invalid or missing %s DT property\n",
+ np, "height-mm");
return -ENODEV;
}
 
@@ -158,8 +160,9 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
 
ret = of_property_read_string(np, "data-mapping", );
if (ret < 0) {
-   dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
-   np, "data-mapping");
+   DRM_DEV_ERROR(lvds->dev,
+ "%pOF: invalid or missing %s DT property\n",
+ np, "data-mapping");
return -ENODEV;
}
 
@@ -170,8 +173,9 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
} else if (!strcmp(mapping, "vesa-24")) {
lvds->bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
} else {
-   dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
-   np, "data-mapping");
+   DRM_DEV_ERROR(lvds->dev,
+ "%pOF: invalid or missing %s DT property\n",
+ np, "data-mapping");
return -EINVAL;
}
 
@@ -201,8 +205,8 @@ static int panel_lvds_probe(struct platform_device *pdev)
 GPIOD_OUT_LOW);
if (IS_ERR(lvds->enable_gpio)) {
ret = PTR_ERR(lvds->enable_gpio);
-   dev_err(lvds->dev, "failed to request %s GPIO: %d\n",
-   "enable", ret);
+   DRM_DEV_ERROR(lvds->dev, "failed to request %s GPIO: %d\n",
+ "enable", ret);
return ret;
}
 
@@ -210,8 +214,8 @@ static int panel_lvds_probe(struct platform_device *pdev)
 GPIOD_OUT_HIGH);
if (IS_ERR(lvds->reset_gpio)) {
ret = PTR_ERR(lvds->reset_gpio);
-   dev_err(lvds->dev, "failed to request %s GPIO: %d\n",
-   "reset", ret);
+   DRM_DEV_ERROR(lvds->dev, "failed to request %s GPIO: %d\n",
+ "reset", ret);
return ret;
}
 
-- 
2.7.4

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

[PATCH v2 09/12] drm: panel: replace dev_* with DRM_DEV_* equivalent in panel-samsung-s6e8aa0

[Aastha Gupta]

For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to
make this differentiation. We now have DRM_DEV_* variants of the drm
print macros, so we can start to convert those drivers back to using
drm-formatted specific log messages.

This patch is using following Coccinelle script:
@@
@@

(
- dev_info
+ DRM_DEV_INFO
|
- dev_err
+ DRM_DEV_ERROR
|
- dev_dbg
+ DRM_DEV_DEBUG
)

Signed-off-by: Aastha Gupta 
---
 drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 28 +++
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
index a188a39..ec677e6 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
@@ -143,8 +143,9 @@ static void s6e8aa0_dcs_write(struct s6e8aa0 *ctx, const 
void *data, size_t len)
 
ret = mipi_dsi_dcs_write_buffer(dsi, data, len);
if (ret < 0) {
-   dev_err(ctx->dev, "error %zd writing dcs seq: %*ph\n", ret,
-   (int)len, data);
+   DRM_DEV_ERROR(ctx->dev,
+ "error %zd writing dcs seq: %*ph\n", ret,
+ (int)len, data);
ctx->error = ret;
}
 }
@@ -159,7 +160,8 @@ static int s6e8aa0_dcs_read(struct s6e8aa0 *ctx, u8 cmd, 
void *data, size_t len)
 
ret = mipi_dsi_dcs_read(dsi, cmd, data, len);
if (ret < 0) {
-   dev_err(ctx->dev, "error %d reading dcs seq(%#x)\n", ret, cmd);
+   DRM_DEV_ERROR(ctx->dev,
+ "error %d reading dcs seq(%#x)\n", ret, cmd);
ctx->error = ret;
}
 
@@ -810,9 +812,9 @@ static void s6e8aa0_set_maximum_return_packet_size(struct 
s6e8aa0 *ctx,
 
ret = mipi_dsi_set_maximum_return_packet_size(dsi, size);
if (ret < 0) {
-   dev_err(ctx->dev,
-   "error %d setting maximum return packet size to %d\n",
-   ret, size);
+   DRM_DEV_ERROR(ctx->dev,
+ "error %d setting maximum return packet size to 
%d\n",
+ ret, size);
ctx->error = ret;
}
 }
@@ -824,19 +826,21 @@ static void s6e8aa0_read_mtp_id(struct s6e8aa0 *ctx)
 
ret = s6e8aa0_dcs_read(ctx, 0xd1, id, ARRAY_SIZE(id));
if (ret < ARRAY_SIZE(id) || id[0] == 0x00) {
-   dev_err(ctx->dev, "read id failed\n");
+   DRM_DEV_ERROR(ctx->dev, "read id failed\n");
ctx->error = -EIO;
return;
}
 
-   dev_info(ctx->dev, "ID: 0x%2x, 0x%2x, 0x%2x\n", id[0], id[1], id[2]);
+   DRM_DEV_INFO(ctx->dev,
+"ID: 0x%2x, 0x%2x, 0x%2x\n", id[0], id[1], id[2]);
 
for (i = 0; i < ARRAY_SIZE(s6e8aa0_variants); ++i) {
if (id[1] == s6e8aa0_variants[i].version)
break;
}
if (i >= ARRAY_SIZE(s6e8aa0_variants)) {
-   dev_err(ctx->dev, "unsupported display version %d\n", id[1]);
+   DRM_DEV_ERROR(ctx->dev,
+ "unsupported display version %d\n", id[1]);
ctx->error = -EINVAL;
return;
}
@@ -1003,14 +1007,14 @@ static int s6e8aa0_probe(struct mipi_dsi_device *dsi)
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
  ctx->supplies);
if (ret < 0) {
-   dev_err(dev, "failed to get regulators: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to get regulators: %d\n", ret);
return ret;
}
 
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
-   dev_err(dev, "cannot get reset-gpios %ld\n",
-   PTR_ERR(ctx->reset_gpio));
+   DRM_DEV_ERROR(dev, "cannot get reset-gpios %ld\n",
+ PTR_ERR(ctx->reset_gpio));
return PTR_ERR(ctx->reset_gpio);
}
 
-- 
2.7.4

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

Re: [PATCH v3 1/6] drm/rockchip/dsi: Define and use macros for PHY register addresses

[Sean Paul]

On Wed, Oct 25, 2017 at 11:50:58AM +0800, Nickey Yang wrote:
> Replace the hardcoded register address numerical values with macros to
> clarify the code.
> 
> Signed-off-by: Nickey Yang 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 129 
> ++---
>  1 file changed, 85 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index b15755b..95ce253 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -254,6 +254,28 @@
>  #define DW_MIPI_NEEDS_PHY_CFG_CLKBIT(0)
>  #define DW_MIPI_NEEDS_GRF_CLKBIT(1)
>  
> +#define PLL_BIAS_CUR_SEL_CAP_VCO_CONTROL 0x10
> +#define PLL_CP_CONTROL_PLL_LOCK_BYPASS   0x11
> +#define PLL_LPF_AND_CP_CONTROL   0x12
> +#define PLL_INPUT_DIVIDER_RATIO  0x17
> +#define PLL_LOOP_DIVIDER_RATIO   0x18
> +#define PLL_INPUT_AND_LOOP_DIVIDER_RATIOS_CONTROL0x19
> +#define BANDGAP_AND_BIAS_CONTROL 0x20
> +#define TERMINATION_RESISTER_CONTROL 0x21
> +#define AFE_BIAS_BANDGAP_ANALOG_PROGRAMMABILITY  0x22
> +#define HS_RX_CONTROL_OF_LANE_0  0x44
> +#define HS_TX_CLOCK_LANE_REQUEST_STATE_TIME_CONTROL  0x60
> +#define HS_TX_CLOCK_LANE_PREPARE_STATE_TIME_CONTROL  0x61
> +#define HS_TX_CLOCK_LANE_HS_ZERO_STATE_TIME_CONTROL  0x62
> +#define HS_TX_CLOCK_LANE_TRAIL_STATE_TIME_CONTROL0x63
> +#define HS_TX_CLOCK_LANE_EXIT_STATE_TIME_CONTROL 0x64
> +#define HS_TX_CLOCK_LANE_POST_TIME_CONTROL   0x65
> +#define HS_TX_DATA_LANE_REQUEST_STATE_TIME_CONTROL   0x70
> +#define HS_TX_DATA_LANE_PREPARE_STATE_TIME_CONTROL   0x71
> +#define HS_TX_DATA_LANE_HS_ZERO_STATE_TIME_CONTROL   0x72
> +#define HS_TX_DATA_LANE_TRAIL_STATE_TIME_CONTROL 0x73
> +#define HS_TX_DATA_LANE_EXIT_STATE_TIME_CONTROL  0x74
> +
>  enum {
>   BANDGAP_97_07,
>   BANDGAP_98_05,
> @@ -447,53 +469,72 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   return ret;
>   }
>  
> - dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
> -  VCO_RANGE_CON_SEL(vco) |
> -  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, 0x12, CP_PROGRAM_EN | LPF_PROGRAM_EN |
> -  LPF_RESISTORS_20_KOHM);
> -
> - dw_mipi_dsi_phy_write(dsi, 0x44, HSFREQRANGE_SEL(testdin));
> -
> - 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, 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);
> -
> - dw_mipi_dsi_phy_write(dsi, 0x22, LOW_PROGRAM_EN |
> -  BIASEXTR_SEL(BIASEXTR_127_7));
> - dw_mipi_dsi_phy_write(dsi, 0x22, HIGH_PROGRAM_EN |
> -  BANDGAP_SEL(BANDGAP_96_10));
> -
> - dw_mipi_dsi_phy_write(dsi, 0x20, POWER_CONTROL | INTERNAL_REG_CURRENT |
> -  BIAS_BLOCK_ON | BANDGAP_ON);
> -
> - dw_mipi_dsi_phy_write(dsi, 0x21, TER_RESISTOR_LOW | TER_CAL_DONE |
> -  SETRD_MAX | TER_RESISTORS_ON);
> - dw_mipi_dsi_phy_write(dsi, 0x21, TER_RESISTOR_HIGH | LEVEL_SHIFTERS_ON |
> -  SETRD_MAX | POWER_MANAGE |
> -  TER_RESISTORS_ON);
> -
> - dw_mipi_dsi_phy_write(dsi, 0x60, TLP_PROGRAM_EN | ns2bc(dsi, 500));
> - dw_mipi_dsi_phy_write(dsi, 0x61, THS_PRE_PROGRAM_EN | ns2ui(dsi, 40));
> - dw_mipi_dsi_phy_write(dsi, 0x62, THS_ZERO_PROGRAM_EN | ns2bc(dsi, 300));
> - dw_mipi_dsi_phy_write(dsi, 0x63, THS_PRE_PROGRAM_EN | ns2ui(dsi, 100));
> - dw_mipi_dsi_phy_write(dsi, 0x64, BIT(5) | ns2bc(dsi, 100));
> - dw_mipi_dsi_phy_write(dsi, 0x65, BIT(5) | (ns2bc(dsi, 60) + 7));
> -
> - dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | ns2bc(dsi, 500));
> - dw_mipi_dsi_phy_write(dsi, 0x71,
> + dw_mipi_dsi_phy_write(dsi, PLL_BIAS_CUR_SEL_CAP_VCO_CONTROL,
> +   BYPASS_VCO_RANGE |
> +   VCO_RANGE_CON_SEL(vco) |
> +   VCO_IN_CAP_CON_LOW |
> +   REF_BIAS_CUR_SEL);
> +
> + dw_mipi_dsi_phy_write(dsi, PLL_CP_CONTROL_PLL_LOCK_BYPASS,
> +   CP_CURRENT_3MA);
> + dw_mipi_dsi_phy_write(dsi, PLL_LPF_AND_CP_CONTROL,
> +   CP_PROGRAM_EN | LPF_PROGRAM_EN |
> +   LPF_RESISTORS_20_KOHM);
> +
> + 

[Bug 103401] X with radeon/amdgpu crashes under lightdm and sddm but not xdm and startx

[bugzilla-daemon]

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

Sergey Kondakov  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #8 from Sergey Kondakov  ---
I tried to get a trace via that Xgdb script but X stuck with black screen and
nothing in logs. Then I ran system update and suddenly lightdm and sddm started
working. So, that issue resolved itself or maybe was a result of
https://bugs.freedesktop.org/show_bug.cgi?id=99591 that was fixed just now in
openSUSE.

There are still those "IO_PAGE_FAULT" and powerplay's "Something is broken" but
they don't seem to manifest in noticeable manner yet.

-- 
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 103443] [CI] igt@kms_setmode@[clone-exclusive-crtc | invalid-clone-exclusive-crtc] - warn - no modes for connector 76

[bugzilla-daemon]

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

Petri Latvala  changed:

   What|Removed |Added

  Component|DRM/Intel   |IGT
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org

-- 
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: Unicode characters in commit messages?

[SF Markus Elfring]

>> Would you like to support Unicode characters there?
> 
> Multiple people have answered this question already and I have answered
> it multiple times.

I found the corresponding feedback not sufficient so far to reach
a final consensus.
Will this topic evolve any further?

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

Re: [Outreachy kernel] [PATCH v14 2/3] drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c

[Sean Paul]

On Tue, Oct 24, 2017 at 04:56:59PM +0100, Daniel Thompson wrote:
> On 24/10/17 16:38, Sean Paul wrote:
> > On Sat, Oct 21, 2017 at 05:27:33PM +0530, Meghana Madhyastha wrote:
> > > Rename tinydrm_of_find_backlight to of_find_backlight and move
> > > it to linux/backlight.c so that it can be used by other drivers.
> > > 
> > > Signed-off-by: Meghana Madhyastha 
> > > ---
> > > Changes in v14:
> > >   -s/backlight_get/of_find_backlight/
> > > 
> > >   drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 
> > > --
> > >   drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
> > >   drivers/video/backlight/backlight.c| 37 
> > > 
> > >   include/drm/tinydrm/tinydrm-helpers.h  |  2 --
> > >   include/linux/backlight.h  | 19 
> > >   5 files changed, 58 insertions(+), 43 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
> > > b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > > index a42dee6..cb1a01a 100644
> > > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> > > @@ -236,46 +236,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
> > > struct drm_framebuffer *fb,
> > >   }
> > >   EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
> > > -/**
> > > - * tinydrm_of_find_backlight - Find backlight device in device-tree
> > > - * @dev: Device
> > > - *
> > > - * This function looks for a DT node pointed to by a property named 
> > > 'backlight'
> > > - * and uses of_find_backlight_by_node() to get the backlight device.
> > > - * Additionally if the brightness property is zero, it is set to
> > > - * max_brightness.
> > > - *
> > > - * Returns:
> > > - * NULL if there's no backlight property.
> > > - * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight 
> > > device
> > > - * is found.
> > > - * If the backlight device is found, a pointer to the structure is 
> > > returned.
> > > - */
> > > -struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
> > > -{
> > > - struct backlight_device *backlight;
> > > - struct device_node *np;
> > > -
> > > - np = of_parse_phandle(dev->of_node, "backlight", 0);
> > > - if (!np)
> > > - return NULL;
> > > -
> > > - backlight = of_find_backlight_by_node(np);
> > > - of_node_put(np);
> > > -
> > > - if (!backlight)
> > > - return ERR_PTR(-EPROBE_DEFER);
> > > -
> > > - if (!backlight->props.brightness) {
> > > - backlight->props.brightness = backlight->props.max_brightness;
> > > - DRM_DEBUG_KMS("Backlight brightness set to %d\n",
> > > -   backlight->props.brightness);
> > > - }
> > > -
> > > - return backlight;
> > > -}
> > > -EXPORT_SYMBOL(tinydrm_of_find_backlight);
> > > -
> > >   #if IS_ENABLED(CONFIG_SPI)
> > >   /**
> > > diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
> > > b/drivers/gpu/drm/tinydrm/mi0283qt.c
> > > index 7fd2691..53ab5a0 100644
> > > --- a/drivers/gpu/drm/tinydrm/mi0283qt.c
> > > +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
> > > @@ -12,6 +12,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -188,7 +189,7 @@ static int mi0283qt_probe(struct spi_device *spi)
> > >   if (IS_ERR(mipi->regulator))
> > >   return PTR_ERR(mipi->regulator);
> > > - mipi->backlight = tinydrm_of_find_backlight(dev);
> > > + mipi->backlight = of_find_backlight(dev);
> > >   if (IS_ERR(mipi->backlight))
> > >   return PTR_ERR(mipi->backlight);
> > > diff --git a/drivers/video/backlight/backlight.c 
> > > b/drivers/video/backlight/backlight.c
> > > index 8049e76..76d46c3 100644
> > > --- a/drivers/video/backlight/backlight.c
> > > +++ b/drivers/video/backlight/backlight.c
> > > @@ -580,6 +580,43 @@ struct backlight_device 
> > > *of_find_backlight_by_node(struct device_node *node)
> > >   EXPORT_SYMBOL(of_find_backlight_by_node);
> > >   #endif
> > > +/**
> > > + * of_find_backlight - Get backlight device
> > > + * @dev: Device
> > > + *
> > > + * This function looks for a property named 'backlight' on the DT node
> > > + * connected to @dev and looks up the backlight device.
> > > + *
> > > + * Call backlight_put() to drop the reference on the backlight device.
> > > + *
> > > + * Returns:
> > > + * A pointer to the backlight device if found.
> > > + * Error pointer -EPROBE_DEFER if the DT property is set, but no 
> > > backlight
> > > + * device is found.
> > > + * NULL if there's no backlight property.
> > > + */
> > > +struct backlight_device *of_find_backlight(struct device *dev)
> > > +{
> > > + struct backlight_device *bd = NULL;
> > > + struct device_node *np;
> > > +
> > > + if (!dev)
> > > + return NULL;
> > > +
> > > + if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> > > + np = of_parse_phandle(dev->of_node, 

Re: drm/rcar-du: Adjust 14 checks for null pointers

[Dan Carpenter]

On Wed, Oct 25, 2017 at 08:44:38AM +0200, SF Markus Elfring wrote:
> >> The script “checkpatch.pl” pointed information out like the following.
> >>
> >> Comparison to NULL could be written !…
> >>
> >> Thus fix the affected source code places.
> >>
> > 
> > This one is fine
> 
> This kind of feedback is nice.
> 
> 
> > except for the commit message.
> 
> Would you like to support Unicode characters there?
> 

Multiple people have answered this question already and I have answered
it multiple times.

regards,
dan carpenter

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

Re: [PATCH] drm_hwcomposer: remove unnecessary external includes

[Sean Paul]

On Wed, Oct 25, 2017 at 10:21:14AM +0800, Chih-Wei Huang wrote:
> 2017-10-25 8:06 GMT+08:00 Rob Herring :
> > Linking to libraries will add necessary include paths, so we don't need to
> > list them explicitly.
> >
> > Still need libsync for sw_sync.h until this dependency is removed.
> >
> > Signed-off-by: Rob Herring 
> > ---
> >  Android.mk | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/Android.mk b/Android.mk
> > index 109e352f2a0e..8b11e375adde 100644
> > --- a/Android.mk
> > +++ b/Android.mk
> > @@ -48,11 +48,7 @@ LOCAL_STATIC_LIBRARIES := libdrmhwc_utils
> >
> >  LOCAL_C_INCLUDES := \
> > external/drm_gralloc \
> > -   external/libdrm \
> > -   external/libdrm/include/drm \
> > -   system/core/include/utils \
> > -   system/core/libsync \
> > -   system/core/libsync/include \
> > +   system/core/libsync
> >
> >  LOCAL_SRC_FILES := \
> > autolock.cpp \
> > --
> 
> Looks good to me
> Reviewed-and-tested-by: Chih-Wei Huang 

Applied, thanks for the patch & review.

Sean

> 
> -- 
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org
> ___
> 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 1/2] dma-buf: keep only not signaled fence in reservation_object_add_shared_replace

[Christian König]

Am 25.10.2017 um 08:42 schrieb Chunming Zhou:



On 2017年10月24日 21:55, Christian König wrote:

From: Christian König 

The amdgpu issue to also need signaled fences in the reservation objects
should be fixed by now.

Optimize the list by keeping only the not signaled yet fences around.

Signed-off-by: Christian König 
---
  drivers/dma-buf/reservation.c | 31 +--
  1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/dma-buf/reservation.c 
b/drivers/dma-buf/reservation.c

index b44d9d7db347..4ede77d1bb31 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -145,8 +145,8 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,

    struct reservation_object_list *fobj,
    struct dma_fence *fence)
  {
-    unsigned i;
  struct dma_fence *old_fence = NULL;
+    unsigned i, j, k;
    dma_fence_get(fence);
  @@ -162,9 +162,7 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,

   * references from the old struct are carried over to
   * the new.
   */
-    fobj->shared_count = old->shared_count;
-
-    for (i = 0; i < old->shared_count; ++i) {
+    for (i = 0, j = 0, k = old->shared_count; i < old->shared_count; 
++i) {

  struct dma_fence *check;
    check = rcu_dereference_protected(old->shared[i],
@@ -172,10 +170,14 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,

    if (!old_fence && check->context == fence->context) {
  old_fence = check;
-    RCU_INIT_POINTER(fobj->shared[i], fence);
-    } else
-    RCU_INIT_POINTER(fobj->shared[i], check);
+    RCU_INIT_POINTER(fobj->shared[j++], fence);
+    } else if (!dma_fence_is_signaled(check)) {
+    RCU_INIT_POINTER(fobj->shared[j++], check);
+    } else {
+    RCU_INIT_POINTER(fobj->shared[--k], check);
+    }
  }
+    fobj->shared_count = j;
  if (!old_fence) {
RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
Here there is a memory leak for signaled fence slots, since you 
re-order the slots, the j'th slot is storing signaled fence, there is 
no place to put it when you assign to new one.

you cam move it to end or put it here first.


Good point, thanks. Going to respin.

Regards,
Christian.



Regards,
David Zhou

  fobj->shared_count++;
@@ -192,10 +194,19 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,

  write_seqcount_end(>seq);
  preempt_enable();
  -    if (old)
-    kfree_rcu(old, rcu);
-
  dma_fence_put(old_fence);
+
+    if (!old)
+    return;
+
+    for (i = fobj->shared_count; i < old->shared_count; ++i) {
+    struct dma_fence *f;
+
+    f = rcu_dereference_protected(fobj->shared[i],
+  reservation_object_held(obj));
+    dma_fence_put(f);
+    }
+    kfree_rcu(old, rcu);
  }
    /**




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

Re: drm/rcar-du: Adjust 14 checks for null pointers

[SF Markus Elfring]

>> The script “checkpatch.pl” pointed information out like the following.
>>
>> Comparison to NULL could be written !…
>>
>> Thus fix the affected source code places.
>>
> 
> This one is fine

This kind of feedback is nice.


> except for the commit message.

Would you like to support Unicode characters there?

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

Re: [PATCH 1/2] dma-buf: keep only not signaled fence in reservation_object_add_shared_replace

[Chunming Zhou]

On 2017年10月24日 21:55, Christian König wrote:

From: Christian König 

The amdgpu issue to also need signaled fences in the reservation objects
should be fixed by now.

Optimize the list by keeping only the not signaled yet fences around.

Signed-off-by: Christian König 
---
  drivers/dma-buf/reservation.c | 31 +--
  1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index b44d9d7db347..4ede77d1bb31 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -145,8 +145,8 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,
  struct reservation_object_list *fobj,
  struct dma_fence *fence)
  {
-   unsigned i;
struct dma_fence *old_fence = NULL;
+   unsigned i, j, k;
  
  	dma_fence_get(fence);
  
@@ -162,9 +162,7 @@ reservation_object_add_shared_replace(struct reservation_object *obj,

 * references from the old struct are carried over to
 * the new.
 */
-   fobj->shared_count = old->shared_count;
-
-   for (i = 0; i < old->shared_count; ++i) {
+   for (i = 0, j = 0, k = old->shared_count; i < old->shared_count; ++i) {
struct dma_fence *check;
  
  		check = rcu_dereference_protected(old->shared[i],

@@ -172,10 +170,14 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,
  
  		if (!old_fence && check->context == fence->context) {

old_fence = check;
-   RCU_INIT_POINTER(fobj->shared[i], fence);
-   } else
-   RCU_INIT_POINTER(fobj->shared[i], check);
+   RCU_INIT_POINTER(fobj->shared[j++], fence);
+   } else if (!dma_fence_is_signaled(check)) {
+   RCU_INIT_POINTER(fobj->shared[j++], check);
+   } else {
+   RCU_INIT_POINTER(fobj->shared[--k], check);
+   }
}
+   fobj->shared_count = j;
if (!old_fence) {
RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
Here there is a memory leak for signaled fence slots, since you re-order 
the slots, the j'th slot is storing signaled fence, there is no place to 
put it when you assign to new one.

you cam move it to end or put it here first.

Regards,
David Zhou

fobj->shared_count++;
@@ -192,10 +194,19 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,
write_seqcount_end(>seq);
preempt_enable();
  
-	if (old)

-   kfree_rcu(old, rcu);
-
dma_fence_put(old_fence);
+
+   if (!old)
+   return;
+
+   for (i = fobj->shared_count; i < old->shared_count; ++i) {
+   struct dma_fence *f;
+
+   f = rcu_dereference_protected(fobj->shared[i],
+ reservation_object_held(obj));
+   dma_fence_put(f);
+   }
+   kfree_rcu(old, rcu);
  }
  
  /**


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

Re: Clarification for approaches around exception handling

[SF Markus Elfring]

> But anyways I guess other people sometimes disagree with me.

Am I one of them?   ;-)


> Unwinding is for when you allocate five things in a row.

This is a general issue.

I find that it is also needed in this function as usual.


> You have to undo four if the last allocation fails.

Concrete numbers might help to clarify another example.


> But say you have to take a lock part way through and drop it before
> the end of the function.  The lock/unlock is not part of the list
> of five resources that you want the function to take so it doesn't
> belong in the unwind code.

Such a view is useful to some degree.


> If you add the lock/unlock to the unwind code, then it makes things a
> bit tricky because then you have to do funny things like:
> 
> free_four:
>   free(four);
>   goto free_three:  <-- little bunny hop
> unlock:   <-- less useful label
>   unlock();
> free_three:
>   free_three();
> free_two:
>   free(two);
> free_one:
>   free(one);
> 
>   return ret;
> 
> It's better to just do the unlocking before the goto.

I would prefer to store such an action also only so often in the code
as it is really required.


> That way the lock and unlock are close together.

It might look nice occasionally.


>   if (!four) {
>   unlock();
>   ret = -EFAIL;
>   goto free_three;
>   }
> 
> Of course, having a big unlock label makes sense if you take a lock at
> the start of the function and need to drop it at the end.  But in this
> case we are taking a  lock then dropping it, and taking the next, then
> dropping it and so on.  It's a different situation.

Lock scopes can interfere with a preferred control flow, can't they?


I have got the impression that your detailed reply could have been
more appropriate for update suggestions around other software modules.

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

[PATCH 2/3] drm/fb: add support for not enabling fbcon on non-desktop displays

[Dave Airlie]

From: Dave Airlie 

We don't want fbcon to get used on non-desktop dislays,
don't pass them as enabled connectors to the fb helper setup.

This prevents my HMD from getting disorted fbcon, and from
affecting other displays console.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_fb_helper.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 116d1f1..0737400 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2033,6 +2033,9 @@ static bool drm_connector_enabled(struct drm_connector 
*connector, bool strict)
 {
bool enable;
 
+   if (connector->display_info.non_desktop)
+   return false;
+
if (strict)
enable = connector->status == connector_status_connected;
else
@@ -2052,7 +2055,8 @@ static void drm_enable_connectors(struct drm_fb_helper 
*fb_helper,
connector = fb_helper->connector_info[i]->connector;
enabled[i] = drm_connector_enabled(connector, true);
DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
- enabled[i] ? "yes" : "no");
+ connector->display_info.non_desktop ? "non 
desktop" : enabled[i] ? "yes" : "no");
+
any_enabled |= enabled[i];
}
 
-- 
2.9.5

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

[PATCH 3/3] drm/edid: quirk HTC vive headset as non-desktop.

[Dave Airlie]

From: Dave Airlie 

This uses the EDID info from my HTC Vive to mark it as
non-desktop.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1e24d5d9..2e8fb51 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -159,6 +159,9 @@ static const struct edid_quirk {
 
/* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
{ "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
+
+   /* HTC Vive VR Headset */
+   { "HVR", 0xaa01, EDID_QUIRK_NON_DESKTOP },
 };
 
 /*
-- 
2.9.5

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

[PATCH 1/3] drm: add connector info/property for non-desktop displays

[Dave Airlie]

From: Dave Airlie 

This adds the infrastructure needed to quirk displays
using edid and to mark them as non-desktop to denote
that userspace shouldn't display a standard desktop on them.

A non-desktop display is one which doesn't work like
a normal rectangular monitor or requires some transformation
of the output by the rendering process to make sense.

This is meant to cover head mounted devices like HTC Vive.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_connector.c | 13 +
 drivers/gpu/drm/drm_edid.c  |  8 ++--
 include/drm/drm_connector.h |  5 +
 include/drm/drm_mode_config.h   |  7 +++
 4 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc89..f9d3538 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -234,6 +234,10 @@ int drm_connector_init(struct drm_device *dev,
   config->link_status_property,
   0);
 
+   drm_object_attach_property(>base,
+  config->non_desktop_property,
+  0);
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, 
config->prop_crtc_id, 0);
}
@@ -811,6 +815,11 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
 
+   prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE, 
"non-desktop");
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.non_desktop_property = prop;
+
return 0;
 }
 
@@ -1194,6 +1203,10 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
if (edid)
size = EDID_LENGTH * (1 + edid->extensions);
 
+   drm_object_property_set_value(>base,
+ dev->mode_config.non_desktop_property,
+ connector->display_info.non_desktop);
+
ret = drm_property_replace_global_blob(dev,
   >edid_blob_ptr,
   size,
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 00ddabf..1e24d5d9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -82,6 +82,8 @@
 #define EDID_QUIRK_FORCE_6BPC  (1 << 10)
 /* Force 10bpc */
 #define EDID_QUIRK_FORCE_10BPC (1 << 11)
+/* Non desktop display (i.e. HMD) */
+#define EDID_QUIRK_NON_DESKTOP (1 << 12)
 
 struct detailed_mode_closure {
struct drm_connector *connector;
@@ -4393,7 +4395,7 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
 }
 
 static void drm_add_display_info(struct drm_connector *connector,
-struct edid *edid)
+struct edid *edid, u32 quirks)
 {
struct drm_display_info *info = >display_info;
 
@@ -4407,6 +4409,8 @@ static void drm_add_display_info(struct drm_connector 
*connector,
info->max_tmds_clock = 0;
info->dvi_dual = false;
 
+   info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
+
if (edid->revision < 3)
return;
 
@@ -4627,7 +4631,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
 * To avoid multiple parsing of same block, lets parse that map
 * from sink info, before parsing CEA modes.
 */
-   drm_add_display_info(connector, edid);
+   drm_add_display_info(connector, edid, quirks);
 
/*
 * EDID spec says modes should be preferred in this order:
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index b4285c40..7fcfc57 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -284,6 +284,11 @@ struct drm_display_info {
 * @hdmi: advance features of a HDMI sink.
 */
struct drm_hdmi_info hdmi;
+
+   /**
+* @non_desktop: Non desktop display (HMD).
+*/
+   bool non_desktop;
 };
 
 int drm_display_info_set_bus_formats(struct drm_display_info *info,
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 0b4ac2e..b21e827 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -728,6 +728,13 @@ struct drm_mode_config {
 */
struct drm_property *suggested_y_property;
 
+   /**
+* @non_desktop_property: Optional connector property with a hint
+* that device isn't a standard display, and the console/desktop,
+* should not be displayed on it.
+*/
+   struct drm_property *non_desktop_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
 
-- 
2.9.5

Re: [PATCH 2/2] drm/rcar-du: Adjust 14 checks for null pointers

[Dan Carpenter]

On Tue, Oct 24, 2017 at 06:02:30PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 24 Oct 2017 17:47:37 +0200
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> The script “checkpatch.pl” pointed information out like the following.
> 
> Comparison to NULL could be written !…
> 
> Thus fix the affected source code places.
> 

This one is fine except for the commit message.

regards,
dan carpenter

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

Re: [PATCH 1/2] drm/rcar-du: Use common error handling code in rcar_du_encoders_init()

[Dan Carpenter]

This is a subtle thing but my preference on this type of thing is the
way the original code is written.  I'm still slightly annoyed that
someone once made me rewrite a patch using the new style...  But anyways
I guess other people sometimes disagree with me.

Unwinding is for when you allocate five things in a row.  You have
to undo four if the last allocation fails.  But say you have to take a
lock part way through and drop it before the end of the function.  The
lock/unlock is not part of the list of five resources that you want the
function to take so it doesn't belong in the unwind code.

If you add the lock/unlock to the unwind code, then it makes things a
bit tricky because then you have to do funny things like:

free_four:
free(four);
goto free_three:  <-- little bunny hop
unlock:   <-- less useful label
unlock();
free_three:
free_three();
free_two:
free(two);
free_one:
free(one);

return ret;

It's better to just do the unlocking before the goto.  That way the
lock and unlock are close together.

if (!four) {
unlock();
ret = -EFAIL;
goto free_three;
}

Of course, having a big unlock label makes sense if you take a lock at
the start of the function and need to drop it at the end.  But in this
case we are taking a  lock then dropping it, and taking the next, then
dropping it and so on.  It's a different situation.

regards,
dan carpenter

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