Re: [PATCH v6 3/5] drm/vc4: Set up the DSI host at pdev probe time, not component bind.

[Archit Taneja]

On 08/16/2017 05:17 AM, Eric Anholt wrote:

We need the following things to happen in sequence:

DSI host creation
DSI device creation in the panel driver (needs DSI host)
DSI device attach from panel to host.
DSI drm_panel_add()
DSI encoder creation
DSI encoder's DRM panel/bridge attach

Unless we allow device creation while the host isn't up yet, we need
to break the -EPROBE_DEFER deadlock between the panel driver looking
up the host and the host driver looking up the panel.  We can do so by
moving the DSI host creation outside of the component bind loop, and
the panel/bridge lookup/attach into the component bind process.


Reviewed-by: Archit Taneja 



Signed-off-by: Eric Anholt 
---
  drivers/gpu/drm/vc4/vc4_dsi.c | 97 +--
  1 file changed, 57 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 2516cd3a1d87..ec1d646b3151 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -33,6 +33,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -504,7 +505,6 @@ struct vc4_dsi {
struct mipi_dsi_host dsi_host;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
-   bool is_panel_bridge;
  
  	void __iomem *regs;
  
@@ -1289,7 +1289,6 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host,

   struct mipi_dsi_device *device)
  {
struct vc4_dsi *dsi = host_to_dsi(host);
-   int ret = 0;
  
  	dsi->lanes = device->lanes;

dsi->channel = device->channel;
@@ -1324,34 +1323,12 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host 
*host,
return 0;
}
  
-	dsi->bridge = of_drm_find_bridge(device->dev.of_node);

-   if (!dsi->bridge) {
-   struct drm_panel *panel =
-   of_drm_find_panel(device->dev.of_node);
-
-   dsi->bridge = drm_panel_bridge_add(panel,
-  DRM_MODE_CONNECTOR_DSI);
-   if (IS_ERR(dsi->bridge)) {
-   ret = PTR_ERR(dsi->bridge);
-   dsi->bridge = NULL;
-   return ret;
-   }
-   dsi->is_panel_bridge = true;
-   }
-
-   return drm_bridge_attach(dsi->encoder, dsi->bridge, NULL);
+   return 0;
  }
  
  static int vc4_dsi_host_detach(struct mipi_dsi_host *host,

   struct mipi_dsi_device *device)
  {
-   struct vc4_dsi *dsi = host_to_dsi(host);
-
-   if (dsi->is_panel_bridge) {
-   drm_panel_bridge_remove(dsi->bridge);
-   dsi->bridge = NULL;
-   }
-
return 0;
  }
  
@@ -1493,16 +1470,13 @@ static int vc4_dsi_bind(struct device *dev, struct device *master, void *data)

struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = dev_get_drvdata(master);
struct vc4_dev *vc4 = to_vc4_dev(drm);
-   struct vc4_dsi *dsi;
+   struct vc4_dsi *dsi = dev_get_drvdata(dev);
struct vc4_dsi_encoder *vc4_dsi_encoder;
+   struct drm_panel *panel;
const struct of_device_id *match;
dma_cap_mask_t dma_mask;
int ret;
  
-	dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);

-   if (!dsi)
-   return -ENOMEM;
-
match = of_match_device(vc4_dsi_dt_match, dev);
if (!match)
return -ENODEV;
@@ -1517,7 +1491,6 @@ static int vc4_dsi_bind(struct device *dev, struct device 
*master, void *data)
vc4_dsi_encoder->dsi = dsi;
dsi->encoder = _dsi_encoder->base.base;
  
-	dsi->pdev = pdev;

dsi->regs = vc4_ioremap_regs(pdev, 0);
if (IS_ERR(dsi->regs))
return PTR_ERR(dsi->regs);
@@ -1598,6 +1571,18 @@ static int vc4_dsi_bind(struct device *dev, struct 
device *master, void *data)
return ret;
}
  
+	ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,

+ , >bridge);
+   if (ret)
+   return ret;
+
+   if (panel) {
+   dsi->bridge = devm_drm_panel_bridge_add(dev, panel,
+   DRM_MODE_CONNECTOR_DSI);
+   if (IS_ERR(dsi->bridge))
+   return PTR_ERR(dsi->bridge);
+   }
+
/* The esc clock rate is supposed to always be 100Mhz. */
ret = clk_set_rate(dsi->escape_clock, 100 * 100);
if (ret) {
@@ -1616,12 +1601,11 @@ static int vc4_dsi_bind(struct device *dev, struct 
device *master, void *data)
 DRM_MODE_ENCODER_DSI, NULL);
drm_encoder_helper_add(dsi->encoder, _dsi_encoder_helper_funcs);
  
-	dsi->dsi_host.ops = _dsi_host_ops;

-   dsi->dsi_host.dev = dev;
-
-   mipi_dsi_host_register(>dsi_host);
-
-   dev_set_drvdata(dev, dsi);
+   

Re: [PATCH libdrm v2 2/2] android: amdgpu: fix build break

[Chih-Wei Huang]

Ping. Is there any other concern to merge the fix?

2017-07-27 16:20 GMT+08:00 Chih-Wei Huang :
> Define two macros to avoid building errors.
>
> Fixes: 7e6bf88cac (amdgpu: move asic id table to a separate file)
>
> Signed-off-by: Chih-Wei Huang 
> ---
>  amdgpu/Android.mk | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
> index bf0611b..88d3765 100644
> --- a/amdgpu/Android.mk
> +++ b/amdgpu/Android.mk
> @@ -10,5 +10,11 @@ LOCAL_SHARED_LIBRARIES := libdrm
>
>  LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
>
> +LOCAL_CFLAGS := \
> +   -DAMDGPU_ASIC_ID_TABLE=\"/system/etc/hwdata/amdgpu.ids\" \
> +   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(shell egrep -ci 
> '^[0-9a-f]{4},.*[0-9a-f]+,' $(LIBDRM_TOP)/data/amdgpu.ids)
> +
> +LOCAL_REQUIRED_MODULES := amdgpu.ids
> +
>  include $(LIBDRM_COMMON_MK)
>  include $(BUILD_SHARED_LIBRARY)
> --



-- 
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

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #25 from Michel Dänzer  ---
(In reply to Ethan Hsieh from comment #24)
> The tearing issue which I saw when running glxgear with default window size
> is same as the corruption shown in Timo's video.

That's corruption, not tearing.

> The photo and video I uploaded were taken when running glxgear with full
> screen.

That's tearing, not corruption.

They're two separate issues that need to be tracked separately.

-- 
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 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #24 from Ethan Hsieh  ---
The tearing issue which I saw when running glxgear with default window size is
same as the corruption shown in Timo's video.
The photo and video I uploaded were taken when running glxgear with full
screen.

-- 
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 102247] Mesa failing to compile

[bugzilla-daemon]

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

--- Comment #4 from Michel Dänzer  ---
BTW, -DLLVM_LINK_LLVM_DYLIB=ON should avoid this bug as well.

-- 
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 102247] Mesa failing to compile

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer  ---
That's a different, pre-existing issue. To avoid it, build LLVM with either
-DLLVM_LINK_LLVM_DYLIB=ON or -DLLVM_APPEND_VC_REV=OFF.

-- 
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: [linux-sunxi] [PATCH 01/13] dt-bindings: update the binding for Allwinner H3 DE2 support

[Jernej Škrabec]

Hi,

Dne četrtek, 10. avgust 2017 ob 02:21:21 CEST je Rob Herring napisal(a):
> On Wed, Aug 02, 2017 at 09:06:26PM +0200, Jernej Škrabec wrote:
> > Hi,
> > 
> > Dne sreda, 02. avgust 2017 ob 07:02:39 CEST je icen...@aosc.io napisal(a):
> > > 在 2017-08-02 12:53，Jernej Škrabec 写道：
> > > 
> > > > Hi Icenowy,
> > > > 
> > > > Dne torek, 01. avgust 2017 ob 15:12:52 CEST je Icenowy Zheng
> > > > 
> > > > napisal(a):
> > > >> Allwinner H3 features a "Display Engine 2.0".
> > > >> 
> > > >> Add device tree bindings for the following parts:
> > > >> - H3 TCONs
> > > >> - H3 Mixers
> > > >> - H3 Display engine
> > > >> 
> > > >> Signed-off-by: Icenowy Zheng 
> > > >> ---
> > > >> 
> > > >>  .../bindings/display/sunxi/sun4i-drm.txt   | 25
> > > >> 
> > > >> ++ 1 file changed, 21 insertions(+), 4
> > > >> deletions(-)
> > > >> 
> > > >> diff --git
> > > >> a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > >> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > > >> 2ee6ff0ef98e..92512953943e 100644
> > > >> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > >> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > >> 
> > > >> @@ -87,18 +87,17 @@ Required properties:
> > > >> * allwinner,sun6i-a31-tcon
> > > >> * allwinner,sun6i-a31s-tcon
> > > >> * allwinner,sun8i-a33-tcon
> > > >> 
> > > >> +   * allwinner,sun8i-h3-tcon
> > > >> 
> > > >> * allwinner,sun8i-v3s-tcon
> > > >>   
> > > >>   - reg: base address and size of memory-mapped region
> > > >>   - interrupts: interrupt associated to this IP
> > > >>   
> > > >>   - clocks: phandles to the clocks feeding the TCON. Three are 
needed:
> > > >> - 'ahb': the interface clocks
> > > >> 
> > > >> -   - 'tcon-ch0': The clock driving the TCON channel 0
> > > >> 
> > > >>   - resets: phandles to the reset controllers driving the encoder
> > > >>   
> > > >> - "lcd": the reset line for the TCON channel 0
> > > >>   
> > > >>   - clock-names: the clock names mentioned above
> > > >>   - reset-names: the reset names mentioned above
> > > >> 
> > > >> - - clock-output-names: Name of the pixel clock created
> > > >> 
> > > >>  - ports: A ports node with endpoint definitions as defined in
> > > >>  
> > > >>Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > > >> 
> > > >> @@ -112,7 +111,23 @@ Required properties:
> > > >>channel the endpoint is associated to. If that property is not
> > > >>present, the endpoint number will be used as the channel number.
> > > >> 
> > > >> -On SoCs other than the A33 and V3s, there is one more clock
> > > >> required:
> > > >> +For the following compatibles:
> > > >> +   * allwinner,sun5i-a13-tcon
> > > >> +   * allwinner,sun6i-a31-tcon
> > > >> +   * allwinner,sun6i-a31s-tcon
> > > >> +   * allwinner,sun8i-a33-tcon
> > > >> +   * allwinner,sun8i-v3s-tcon
> > > >> +there is one more clock and one more property required:
> > > >> + - clocks:
> > > >> +   - 'tcon-ch0': The clock driving the TCON channel 0
> > > >> + - clock-output-names: Name of the pixel clock created
> > > >> +
> > > >> +For the following compatibles:
> > > >> +   * allwinner,sun5i-a13-tcon
> > > >> +   * allwinner,sun6i-a31-tcon
> > > >> +   * allwinner,sun6i-a31s-tcon
> > > >> +   * allwinner,sun8i-h3-tcon
> > > >> 
> > > >> +there is one more clock required:
> > > >> - 'tcon-ch1': The clock driving the TCON channel 1
> > > >>  
> > > >>  DRC
> > > >> 
> > > >> @@ -207,6 +222,8 @@ supported.
> > > >> 
> > > >>  Required properties:
> > > >>- compatible: value must be one of:
> > > >>  * allwinner,sun8i-v3s-de2-mixer
> > > >> 
> > > >> +* allwinner,sun8i-h3-de2-mixer0
> > > >> +* allwinner,sun8i-h3-de2-mixer1
> > > > 
> > > > About that, I concur with Maxime here, plane number properties would
> > > > be
> > > > better. If we don't do this now, we will never have it.
> > > 
> > > But I still prefer different compatibles, as the capabilities are
> > > already
> > > proven to be different between mixer0 and mixer1, and furtherly we
> > > cannot
> > > promise Allwinner won't add more functions only available at mixer0.
> > > 
> > > Then we will be trapped into a situation that we describe more and more
> > > functions via properties, but they should be encoded into the
> > > compatible.
> > 
> > It is either multiple compatibles or multiple properties. I prefer the
> > later, but it is up to maintainers to decide.
> 
> It's not the same. A compatible can imply an infinite number of
> properties. I'm fine with properties too, but with only 2 instances I
> don't think it makes much sense.

Actually, there are more combinations since different SoCs have also different 
capabilities regarding mixer0 or mixer1.

For example, mixer0 on H3 has different capabilities than mixer0 on A83T (max. 
plane size and number and type of planes, etc.).

Best regards,
Jernej

Re: [patch net-next 0/3] net/sched: Improve getting objects by indexes

[Christian König]

Am 16.08.2017 um 04:12 schrieb Chris Mi:

Using current TC code, it is very slow to insert a lot of rules.

In order to improve the rules update rate in TC,
we introduced the following two changes:
 1) changed cls_flower to use IDR to manage the filters.
 2) changed all act_xxx modules to use IDR instead of
a small hash table

But IDR has a limitation that it uses int. TC handle uses u32.
To make sure there is no regression, we also changed IDR to use
unsigned long. All clients of IDR are changed to use new IDR API.


WOW, wait a second. The idr change is touching a lot of drivers and to 
be honest doesn't looks correct at all.


Just look at the first chunk of your modification:

@@ -998,8 +999,9 @@ int bsg_register_queue(struct request_queue *q, struct 
device *parent,
  
  	mutex_lock(_mutex);
  
-	ret = idr_alloc(_minor_idr, bcd, 0, BSG_MAX_DEVS, GFP_KERNEL);

-   if (ret < 0) {
+   ret = idr_alloc(_minor_idr, bcd, _index, 0, BSG_MAX_DEVS,
+   GFP_KERNEL);
+   if (ret) {
if (ret == -ENOSPC) {
printk(KERN_ERR "bsg: too many bsg devices\n");
ret = -EINVAL;
The condition "if (ret)" will now always be true after the first 
allocation and so we always run into the error handling after that.


I've never read the bsg code before, but that's certainly not correct. 
And that incorrect pattern repeats over and over again in this code.


Apart from that why the heck do you want to allocate more than 1<<31 
handles?


Regards,
Christian.



Chris Mi (3):
   idr: Use unsigned long instead of int
   net/sched: Change cls_flower to use IDR
   net/sched: Change act_api and act_xxx modules to use IDR

  block/bsg.c |   8 +-
  block/genhd.c   |  12 +-
  drivers/atm/nicstar.c   |  11 +-
  drivers/block/drbd/drbd_main.c  |  31 +--
  drivers/block/drbd/drbd_nl.c|  22 ++-
  drivers/block/drbd/drbd_proc.c  |   3 +-
  drivers/block/drbd/drbd_receiver.c  |  15 +-
  drivers/block/drbd/drbd_state.c |  34 ++--
  drivers/block/drbd/drbd_worker.c|   6 +-
  drivers/block/loop.c|  17 +-
  drivers/block/nbd.c |  20 +-
  drivers/block/zram/zram_drv.c   |   9 +-
  drivers/char/tpm/tpm-chip.c |  10 +-
  drivers/char/tpm/tpm.h  |   2 +-
  drivers/dca/dca-sysfs.c |   9 +-
  drivers/firewire/core-cdev.c|  18 +-
  drivers/firewire/core-device.c  |  15 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c |   8 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |   9 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c |   6 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |   2 +-
  drivers/gpu/drm/drm_auth.c  |   9 +-
  drivers/gpu/drm/drm_connector.c |  10 +-
  drivers/gpu/drm/drm_context.c   |  20 +-
  drivers/gpu/drm/drm_dp_aux_dev.c|  11 +-
  drivers/gpu/drm/drm_drv.c   |   6 +-
  drivers/gpu/drm/drm_gem.c   |  19 +-
  drivers/gpu/drm/drm_info.c  |   2 +-
  drivers/gpu/drm/drm_mode_object.c   |  11 +-
  drivers/gpu/drm/drm_syncobj.c   |  18 +-
  drivers/gpu/drm/exynos/exynos_drm_ipp.c |  25 ++-
  drivers/gpu/drm/i915/gvt/display.c  |   2 +-
  drivers/gpu/drm/i915/gvt/kvmgt.c|   2 +-
  drivers/gpu/drm/i915/gvt/vgpu.c |   9 +-
  drivers/gpu/drm/i915/i915_debugfs.c |   6 +-
  drivers/gpu/drm/i915/i915_gem_context.c |   9 +-
  drivers/gpu/drm/qxl/qxl_cmd.c   |   8 +-
  drivers/gpu/drm/qxl/qxl_release.c   |  14 +-
  drivers/gpu/drm/sis/sis_mm.c|   8 +-
  drivers/gpu/drm/tegra/drm.c |  10 +-
  drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c|   3 +-
  drivers/gpu/drm/vgem/vgem_fence.c   |  12 +-
  drivers/gpu/drm/via/via_mm.c|   8 +-
  drivers/gpu/drm/virtio/virtgpu_kms.c|   5 +-
  drivers/gpu/drm/virtio/virtgpu_vq.c |   5 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c|   9 +-
  drivers/i2c/i2c-core-base.c |  19 +-
  drivers/infiniband/core/cm.c|   8 +-
  drivers/infiniband/core/cma.c   |  12 +-
  drivers/infiniband/core/rdma_core.c |   9 +-
  drivers/infiniband/core/sa_query.c  |  23 +--
  drivers/infiniband/core/ucm.c   |   7 +-
  drivers/infiniband/core/ucma.c  |  14 +-
  drivers/infiniband/hw/cxgb3/iwch.c  |   4 +-
  drivers/infiniband/hw/cxgb3/iwch.h  |   4 +-
  

Re: [patch net-next 0/3] net/sched: Improve getting objects by indexes

[Chris Wilson]

Quoting Christian König (2017-08-16 08:49:07)
> Am 16.08.2017 um 04:12 schrieb Chris Mi:
> > Using current TC code, it is very slow to insert a lot of rules.
> >
> > In order to improve the rules update rate in TC,
> > we introduced the following two changes:
> >  1) changed cls_flower to use IDR to manage the filters.
> >  2) changed all act_xxx modules to use IDR instead of
> > a small hash table
> >
> > But IDR has a limitation that it uses int. TC handle uses u32.
> > To make sure there is no regression, we also changed IDR to use
> > unsigned long. All clients of IDR are changed to use new IDR API.
> 
> WOW, wait a second. The idr change is touching a lot of drivers and to 
> be honest doesn't looks correct at all.
> 
> Just look at the first chunk of your modification:
> > @@ -998,8 +999,9 @@ int bsg_register_queue(struct request_queue *q, struct 
> > device *parent,
> >   
> >   mutex_lock(_mutex);
> >   
> > - ret = idr_alloc(_minor_idr, bcd, 0, BSG_MAX_DEVS, GFP_KERNEL);
> > - if (ret < 0) {
> > + ret = idr_alloc(_minor_idr, bcd, _index, 0, BSG_MAX_DEVS,
> > + GFP_KERNEL);
> > + if (ret) {
> >   if (ret == -ENOSPC) {
> >   printk(KERN_ERR "bsg: too many bsg devices\n");
> >   ret = -EINVAL;
> The condition "if (ret)" will now always be true after the first 
> allocation and so we always run into the error handling after that.

ret is now purely the error code, so it doesn't look that suspicious.

> I've never read the bsg code before, but that's certainly not correct. 
> And that incorrect pattern repeats over and over again in this code.
> 
> Apart from that why the heck do you want to allocate more than 1<<31 
> handles?

And more to the point, arbitrarily changing the maximum to ULONG_MAX
where the ABI only supports U32_MAX is dangerous. Unless you do the
analysis otherwise, you have to replace all the end=0 with end=INT_MAX
to maintain existing behaviour.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Eric Anholt]

Noralf Trønnes  writes:

> Den 16.08.2017 22.39, skrev Laurent Pinchart:
>> Hi Noralf,
>>
>> On Wednesday 16 Aug 2017 21:52:02 Noralf Trønnes wrote:
>>> Den 16.08.2017 19.24, skrev Eric Anholt:
 Noralf Trønnes  writes:
> This library provides helpers for drivers that don't subclass
> drm_framebuffer and are backed by drm_gem_object. The code is
> taken from drm_fb_cma_helper.
>
> Signed-off-by: Noralf Trønnes 
> Reviewed-by: Daniel Vetter 
> ---
> +/**
> + * drm_gem_fb_destroy - Free GEM backed framebuffer
> + * @fb: DRM framebuffer
> + *
> + * Frees a GEM backed framebuffer with it's backing buffer(s) and the
> structure
 grammar nit: "its"

 Other than that,

 Reviewed-by: Eric Anholt 
>>> Thanks, applied to drm-misc.
>> The patches were posted on Sunday. If you don't give at least a week to
>> reviewers, I don't think they will keep bothering. I certainly won't.
>
> Hi Laurent,
>
> I actually didn't think there was much interest in this patchset since
> the first version of the patcheset was sent 31/7. Daniel gave me his rb
> if I fixed the docs a week ago. Instead of applying it directly I sent
> a new version to give Eric a chance to look at it since he showed
> interest in an rfc. So when I got his rb, I just applied.
>
> All that being said, I do appreciate reviews since that improves the work.
> I will adapt to waiting a week if that's what's expected.
>
> Sorry about the let down.

For what it's worth, I think the speed of merging was entirely
appropriate in this case.  It had been a week since the previous
version, that got no replies except for danvet's.  You're effectively
just moving code and renaming some functions, and danvet and I had both
replied positively.

As far as concerns about whether everyone gets to give their feedback
go, my stance is: The great thing about git is that you can make changes
to code even after a patch goes in.


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

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Laurent Pinchart]

Hi Noralf,

On Wednesday 16 Aug 2017 23:31:23 Noralf Trønnes wrote:
> Den 16.08.2017 23.13, skrev Daniel Vetter:
> > On Wed, Aug 16, 2017 at 11:11 PM, Laurent Pinchart wrote:
> >> On Wednesday 16 Aug 2017 23:06:30 Daniel Vetter wrote:
> >>> Perhaps pinged Laurent on irc since he's written/reviewed a bunch of cma
> >>> patches. Aside: Being on irc would be good, makes it quicker to
> >>> discuss stuff like this if you're around.
> >> 
> >> Please, let's not expect developers to be available to discuss patches on
> >> IRC in the middle of the night ;-)
> > 
> > I never expect that, which is why there's an "if you're around" in my
> > statement. But people are in all kinds of strange TZ, work this as a
> > hobby or just have a unusual sleeping patter, so I stopped making any
> > kind of assumptions about when someone's around and when not. And
> > since Noralf just replied, he might have been around (or maybe not,
> > which isn't a problem either).
> 
> My way of working doesn't fit very well to participating on irc. I work
> on drm for an hour and then need to take a break for one or two hours due
> to an illness I have. So the offline nature of email is best suited for me.

Everybody can decide how best to handle communication, but please know that 
you're not expected to reply on the spot on IRC. I often take several hours 
away from IRC during my work time to concentrate on other tasks.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Laurent Pinchart]

Hi Noralf,

On Wednesday 16 Aug 2017 23:24:50 Noralf Trønnes wrote:
> Den 16.08.2017 23.08, skrev Laurent Pinchart:
> > On Wednesday 16 Aug 2017 23:03:36 Noralf Trønnes wrote:
> >> Den 16.08.2017 22.39, skrev Laurent Pinchart:
> >>> On Wednesday 16 Aug 2017 21:52:02 Noralf Trønnes wrote:
>  Den 16.08.2017 19.24, skrev Eric Anholt:
> > Noralf Trønnes  writes:
> >> This library provides helpers for drivers that don't subclass
> >> drm_framebuffer and are backed by drm_gem_object. The code is
> >> taken from drm_fb_cma_helper.
> >> 
> >> Signed-off-by: Noralf Trønnes 
> >> Reviewed-by: Daniel Vetter 
> >> ---
> >> +/**
> >> + * drm_gem_fb_destroy - Free GEM backed framebuffer
> >> + * @fb: DRM framebuffer
> >> + *
> >> + * Frees a GEM backed framebuffer with it's backing buffer(s) and
> >> the structure
> > 
> > grammar nit: "its"
> > 
> > Other than that,
> > 
> > Reviewed-by: Eric Anholt 
>  
>  Thanks, applied to drm-misc.
> >>> 
> >>> The patches were posted on Sunday. If you don't give at least a week to
> >>> reviewers, I don't think they will keep bothering. I certainly won't.
> >> 
> >> Hi Laurent,
> >> 
> >> I actually didn't think there was much interest in this patchset since
> >> the first version of the patcheset was sent 31/7. Daniel gave me his rb
> >> if I fixed the docs a week ago. Instead of applying it directly I sent
> >> a new version to give Eric a chance to look at it since he showed
> >> interest in an rfc. So when I got his rb, I just applied.
> >> 
> >> All that being said, I do appreciate reviews since that improves the
> >> work. I will adapt to waiting a week if that's what's expected.
> > 
> > There are always exceptions, or at least borderline cases, but I think
> > that one week is a reasonable delay in the general case. If you're at v8
> > and your series has been acked by 10 people already it can be a different
> > story. Or if you're fixing a security issue that has to get in a late -rc
> > before the final kernel is released. Or lots of other cases probably.
> > 
> >> Sorry about the let down.
> > 
> > It's OK, I know it wasn't on purpose :-) Your reply is definitely
> > appreciated.
> > 
> > Could you post a follow-up patch to fix the few issues I mentioned (at
> > least the ones you agree with of course) ?
> 
> Yes, I'll do that.
> 
> I suck at writing documentation, so when I need documentation for say
> an argument, I copy it from another function with the same argument.
> Not always pretty obviously, so I rely on help from reviewers to ensure
> proper english. Daniel has helped me many times to flesh out the docs.

I know the feeling, it takes me at least 10 times longer to write 
documentation than to write code :-/ I try to comfort myself by thinking that 
I'm quick at writing code, not slow at writing documentation, but that doesn't 
always work :-)

I have found, however, than when you start writing a large block of 
documentation, after some time it speeds up. When your brain switches to 
documentation mode words come out faster. You could try filling up kerneldoc 
comments in one go at the end of the development (or, even better, at the 
start) and see how that works out for you.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Noralf Trønnes]

Den 16.08.2017 23.13, skrev Daniel Vetter:

On Wed, Aug 16, 2017 at 11:11 PM, Laurent Pinchart
 wrote:

On Wednesday 16 Aug 2017 23:06:30 Daniel Vetter wrote:

Perhaps pinged Laurent on irc since he's written/reviewed a bunch of cma
patches. Aside: Being on irc would be good, makes it quicker to
discuss stuff like this if you're around.

Please, let's not expect developers to be available to discuss patches on IRC
in the middle of the night ;-)

I never expect that, which is why there's an "if you're around" in my
statement. But people are in all kinds of strange TZ, work this as a
hobby or just have a unusual sleeping patter, so I stopped making any
kind of assumptions about when someone's around and when not. And
since Noralf just replied, he might have been around (or maybe not,
which isn't a problem either).


My way of working doesn't fit very well to participating on irc. I work
on drm for an hour and then need to take a break for one or two hours due
to an illness I have. So the offline nature of email is best suited for me.

Noralf.

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

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Noralf Trønnes]

Den 16.08.2017 23.08, skrev Laurent Pinchart:

Hi Noralf,

On Wednesday 16 Aug 2017 23:03:36 Noralf Trønnes wrote:

Den 16.08.2017 22.39, skrev Laurent Pinchart:

On Wednesday 16 Aug 2017 21:52:02 Noralf Trønnes wrote:

Den 16.08.2017 19.24, skrev Eric Anholt:

Noralf Trønnes  writes:

This library provides helpers for drivers that don't subclass
drm_framebuffer and are backed by drm_gem_object. The code is
taken from drm_fb_cma_helper.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
+/**
+ * drm_gem_fb_destroy - Free GEM backed framebuffer
+ * @fb: DRM framebuffer
+ *
+ * Frees a GEM backed framebuffer with it's backing buffer(s) and the
structure

grammar nit: "its"

Other than that,

Reviewed-by: Eric Anholt 

Thanks, applied to drm-misc.

The patches were posted on Sunday. If you don't give at least a week to
reviewers, I don't think they will keep bothering. I certainly won't.

Hi Laurent,

I actually didn't think there was much interest in this patchset since
the first version of the patcheset was sent 31/7. Daniel gave me his rb
if I fixed the docs a week ago. Instead of applying it directly I sent
a new version to give Eric a chance to look at it since he showed
interest in an rfc. So when I got his rb, I just applied.

All that being said, I do appreciate reviews since that improves the work.
I will adapt to waiting a week if that's what's expected.

There are always exceptions, or at least borderline cases, but I think that
one week is a reasonable delay in the general case. If you're at v8 and your
series has been acked by 10 people already it can be a different story. Or if
you're fixing a security issue that has to get in a late -rc before the final
kernel is released. Or lots of other cases probably.


Sorry about the let down.

It's OK, I know it wasn't on purpose :-) Your reply is definitely appreciated.

Could you post a follow-up patch to fix the few issues I mentioned (at least
the ones you agree with of course) ?



Yes, I'll do that.

I suck at writing documentation, so when I need documentation for say
an argument, I copy it from another function with the same argument.
Not always pretty obviously, so I rely on help from reviewers to ensure
proper english. Daniel has helped me many times to flesh out the docs.

Noralf.

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

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Daniel Vetter]

On Wed, Aug 16, 2017 at 11:11 PM, Laurent Pinchart
 wrote:
> On Wednesday 16 Aug 2017 23:06:30 Daniel Vetter wrote:
>> Perhaps pinged Laurent on irc since he's written/reviewed a bunch of cma
>> patches. Aside: Being on irc would be good, makes it quicker to
>> discuss stuff like this if you're around.
>
> Please, let's not expect developers to be available to discuss patches on IRC
> in the middle of the night ;-)

I never expect that, which is why there's an "if you're around" in my
statement. But people are in all kinds of strange TZ, work this as a
hobby or just have a unusual sleeping patter, so I stopped making any
kind of assumptions about when someone's around and when not. And
since Noralf just replied, he might have been around (or maybe not,
which isn't a problem either).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Laurent Pinchart]

Hi Daniel,

On Wednesday 16 Aug 2017 23:06:30 Daniel Vetter wrote:
> On Wed, Aug 16, 2017 at 11:03 PM, Noralf Trønnes  wrote:
> > Den 16.08.2017 22.39, skrev Laurent Pinchart:
> >> On Wednesday 16 Aug 2017 21:52:02 Noralf Trønnes wrote:
> >>> Den 16.08.2017 19.24, skrev Eric Anholt:
>  Noralf Trønnes  writes:
> > This library provides helpers for drivers that don't subclass
> > drm_framebuffer and are backed by drm_gem_object. The code is
> > taken from drm_fb_cma_helper.
> > 
> > Signed-off-by: Noralf Trønnes 
> > Reviewed-by: Daniel Vetter 
> > ---
> > +/**
> > + * drm_gem_fb_destroy - Free GEM backed framebuffer
> > + * @fb: DRM framebuffer
> > + *
> > + * Frees a GEM backed framebuffer with it's backing buffer(s) and the
> > structure
>  
>  grammar nit: "its"
>  
>  Other than that,
>  
>  Reviewed-by: Eric Anholt 
> >>> 
> >>> Thanks, applied to drm-misc.
> >> 
> >> The patches were posted on Sunday. If you don't give at least a week to
> >> reviewers, I don't think they will keep bothering. I certainly won't.
> > 
> > Hi Laurent,
> > 
> > I actually didn't think there was much interest in this patchset since
> > the first version of the patcheset was sent 31/7. Daniel gave me his rb
> > if I fixed the docs a week ago. Instead of applying it directly I sent
> > a new version to give Eric a chance to look at it since he showed
> > interest in an rfc. So when I got his rb, I just applied.
> > 
> > All that being said, I do appreciate reviews since that improves the work.
> > I will adapt to waiting a week if that's what's expected.
> > 
> > Sorry about the let down.
> 
> I think a follow up patch to address the review would be good.
> 
> On the "how long to wait for review" question we just discussed this a
> bit on irc, and I kinda would have merged it probably too.

I think we've had a similar discussion before (but possibly in private, I'm 
not sure), and I believe that one week is a reasonable delay. That being said 
I understand what happened here, and I too get impatient to merge patches when 
I believe they're almost ready and just need one final ack.

> Perhaps pinged Laurent on irc since he's written/reviewed a bunch of cma
> patches. Aside: Being on irc would be good, makes it quicker to
> discuss stuff like this if you're around.

Please, let's not expect developers to be available to discuss patches on IRC 
in the middle of the night ;-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Laurent Pinchart]

Hi Noralf,

On Wednesday 16 Aug 2017 23:03:36 Noralf Trønnes wrote:
> Den 16.08.2017 22.39, skrev Laurent Pinchart:
> > On Wednesday 16 Aug 2017 21:52:02 Noralf Trønnes wrote:
> >> Den 16.08.2017 19.24, skrev Eric Anholt:
> >>> Noralf Trønnes  writes:
>  This library provides helpers for drivers that don't subclass
>  drm_framebuffer and are backed by drm_gem_object. The code is
>  taken from drm_fb_cma_helper.
>  
>  Signed-off-by: Noralf Trønnes 
>  Reviewed-by: Daniel Vetter 
>  ---
>  +/**
>  + * drm_gem_fb_destroy - Free GEM backed framebuffer
>  + * @fb: DRM framebuffer
>  + *
>  + * Frees a GEM backed framebuffer with it's backing buffer(s) and the
>  structure
> >>> 
> >>> grammar nit: "its"
> >>> 
> >>> Other than that,
> >>> 
> >>> Reviewed-by: Eric Anholt 
> >> 
> >> Thanks, applied to drm-misc.
> > 
> > The patches were posted on Sunday. If you don't give at least a week to
> > reviewers, I don't think they will keep bothering. I certainly won't.
> 
> Hi Laurent,
> 
> I actually didn't think there was much interest in this patchset since
> the first version of the patcheset was sent 31/7. Daniel gave me his rb
> if I fixed the docs a week ago. Instead of applying it directly I sent
> a new version to give Eric a chance to look at it since he showed
> interest in an rfc. So when I got his rb, I just applied.
> 
> All that being said, I do appreciate reviews since that improves the work.
> I will adapt to waiting a week if that's what's expected.

There are always exceptions, or at least borderline cases, but I think that 
one week is a reasonable delay in the general case. If you're at v8 and your 
series has been acked by 10 people already it can be a different story. Or if 
you're fixing a security issue that has to get in a late -rc before the final 
kernel is released. Or lots of other cases probably.

> Sorry about the let down.

It's OK, I know it wasn't on purpose :-) Your reply is definitely appreciated.

Could you post a follow-up patch to fix the few issues I mentioned (at least 
the ones you agree with of course) ?

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Daniel Vetter]

On Wed, Aug 16, 2017 at 11:03 PM, Noralf Trønnes  wrote:
>
> Den 16.08.2017 22.39, skrev Laurent Pinchart:
>>
>> Hi Noralf,
>>
>> On Wednesday 16 Aug 2017 21:52:02 Noralf Trønnes wrote:
>>>
>>> Den 16.08.2017 19.24, skrev Eric Anholt:

 Noralf Trønnes  writes:
>
> This library provides helpers for drivers that don't subclass
> drm_framebuffer and are backed by drm_gem_object. The code is
> taken from drm_fb_cma_helper.
>
> Signed-off-by: Noralf Trønnes 
> Reviewed-by: Daniel Vetter 
> ---
> +/**
> + * drm_gem_fb_destroy - Free GEM backed framebuffer
> + * @fb: DRM framebuffer
> + *
> + * Frees a GEM backed framebuffer with it's backing buffer(s) and the
> structure

 grammar nit: "its"

 Other than that,

 Reviewed-by: Eric Anholt 
>>>
>>> Thanks, applied to drm-misc.
>>
>> The patches were posted on Sunday. If you don't give at least a week to
>> reviewers, I don't think they will keep bothering. I certainly won't.
>
>
> Hi Laurent,
>
> I actually didn't think there was much interest in this patchset since
> the first version of the patcheset was sent 31/7. Daniel gave me his rb
> if I fixed the docs a week ago. Instead of applying it directly I sent
> a new version to give Eric a chance to look at it since he showed
> interest in an rfc. So when I got his rb, I just applied.
>
> All that being said, I do appreciate reviews since that improves the work.
> I will adapt to waiting a week if that's what's expected.
>
> Sorry about the let down.

I think a follow up patch to address the review would be good.

On the "how long to wait for review" question we just discussed this a
bit on irc, and I kinda would have merged it probably too. Perhaps
pinged Laurent on irc since he's written/reviewed a bunch of cma
patches. Aside: Being on irc would be good, makes it quicker to
discuss stuff like this if you're around.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Noralf Trønnes]

Den 16.08.2017 22.39, skrev Laurent Pinchart:

Hi Noralf,

On Wednesday 16 Aug 2017 21:52:02 Noralf Trønnes wrote:

Den 16.08.2017 19.24, skrev Eric Anholt:

Noralf Trønnes  writes:

This library provides helpers for drivers that don't subclass
drm_framebuffer and are backed by drm_gem_object. The code is
taken from drm_fb_cma_helper.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
+/**
+ * drm_gem_fb_destroy - Free GEM backed framebuffer
+ * @fb: DRM framebuffer
+ *
+ * Frees a GEM backed framebuffer with it's backing buffer(s) and the
structure

grammar nit: "its"

Other than that,

Reviewed-by: Eric Anholt 

Thanks, applied to drm-misc.

The patches were posted on Sunday. If you don't give at least a week to
reviewers, I don't think they will keep bothering. I certainly won't.


Hi Laurent,

I actually didn't think there was much interest in this patchset since
the first version of the patcheset was sent 31/7. Daniel gave me his rb
if I fixed the docs a week ago. Instead of applying it directly I sent
a new version to give Eric a chance to look at it since he showed
interest in an rfc. So when I got his rb, I just applied.

All that being said, I do appreciate reviews since that improves the work.
I will adapt to waiting a week if that's what's expected.

Sorry about the let down.

Noralf.

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

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Laurent Pinchart]

Hi Noralf,

One additional comment.

On Wednesday 16 Aug 2017 23:37:54 Laurent Pinchart wrote:
> On Sunday 13 Aug 2017 15:31:44 Noralf Trønnes wrote:
> > This library provides helpers for drivers that don't subclass
> > drm_framebuffer and are backed by drm_gem_object. The code is
> > taken from drm_fb_cma_helper.
> > 
> > Signed-off-by: Noralf Trønnes 
> > Reviewed-by: Daniel Vetter 
> > ---
> > 
> >  Documentation/gpu/drm-kms-helpers.rst|   9 +
> >  drivers/gpu/drm/Makefile |   2 +-
> >  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 283 +
> >  include/drm/drm_framebuffer.h|   7 +
> >  include/drm/drm_gem_framebuffer_helper.h |  37 
> >  5 files changed, 337 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/drm_gem_framebuffer_helper.c
> >  create mode 100644 include/drm/drm_gem_framebuffer_helper.h
> 
> [snip]
> 
> > diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > b/drivers/gpu/drm/drm_gem_framebuffer_helper.c new file mode 100644
> > index 000..068a630
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > @@ -0,0 +1,283 @@
> 
> [snip]
> 
> > +/**
> > + * DOC: overview
> > + *
> > + * This library provides helpers for drivers that don't subclass
> > + * _framebuffer and and use _gem_object for their backing
> > storage.
> 
> s/and and/and/
> 
> > + *
> > + * Drivers without additional needs to validate framebuffers can simply
> > use
> > + * drm_gem_fb_create() and everything is wired up automatically. But all
> > + * parts can be used individually.
> 
> A sentence should not start by "but". How about "Other drivers can use all
> parts independently." ?
> 
> > + */

We now have the GEM CMA helpers, the GEM FB helpers and the FB CMA helper. It 
starts getting very confusing for driver authors. The overview documentation 
should explain how they all interact and which helpers a driver can/should use 
in the different cases.

[snip]

-- 
Regards,

Laurent Pinchart

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

[Bug 102247] Mesa failing to compile

[bugzilla-daemon]

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

--- Comment #2 from Chris Rankin  ---
No, I now get:

configure: error: Could not find llvm shared libraries:
   Please make sure you have built llvm with the
--enable-shared option
   and that your llvm libraries are installed in
/home/chris/Programs/local-llvm/lib
   If you have installed your llvm libraries to a different
directory you
   can use the --with-llvm-prefix= configure flag to
specify this directory.
   NOTE: Mesa is attempting to use llvm shared libraries by
default.
   If you do not want to build with llvm shared libraries
and instead want to
   use llvm static libraries then add
--disable-llvm-shared-libs to your configure
   invocation and rebuild.

For some reason, I think Mesa is expecting my LLVM installation to contain
libLLVMTarget.so rather than libLLVM.so.

-- 
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 01/22] drm: Add GEM backed framebuffer library

[Laurent Pinchart]

Hi Noralf,

On Wednesday 16 Aug 2017 21:52:02 Noralf Trønnes wrote:
> Den 16.08.2017 19.24, skrev Eric Anholt:
> > Noralf Trønnes  writes:
> >> This library provides helpers for drivers that don't subclass
> >> drm_framebuffer and are backed by drm_gem_object. The code is
> >> taken from drm_fb_cma_helper.
> >> 
> >> Signed-off-by: Noralf Trønnes 
> >> Reviewed-by: Daniel Vetter 
> >> ---
> >> +/**
> >> + * drm_gem_fb_destroy - Free GEM backed framebuffer
> >> + * @fb: DRM framebuffer
> >> + *
> >> + * Frees a GEM backed framebuffer with it's backing buffer(s) and the
> >> structure
> > grammar nit: "its"
> > 
> > Other than that,
> > 
> > Reviewed-by: Eric Anholt 
> 
> Thanks, applied to drm-misc.

The patches were posted on Sunday. If you don't give at least a week to 
reviewers, I don't think they will keep bothering. I certainly won't.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Laurent Pinchart]

Ni Noralf,

Thank you for the patch.

On Sunday 13 Aug 2017 15:31:44 Noralf Trønnes wrote:
> This library provides helpers for drivers that don't subclass
> drm_framebuffer and are backed by drm_gem_object. The code is
> taken from drm_fb_cma_helper.
> 
> Signed-off-by: Noralf Trønnes 
> Reviewed-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms-helpers.rst|   9 +
>  drivers/gpu/drm/Makefile |   2 +-
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 283 
>  include/drm/drm_framebuffer.h|   7 +
>  include/drm/drm_gem_framebuffer_helper.h |  37 
>  5 files changed, 337 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_gem_framebuffer_helper.c
>  create mode 100644 include/drm/drm_gem_framebuffer_helper.h

[snip]

> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c new file mode 100644
> index 000..068a630
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -0,0 +1,283 @@

[snip]

> +/**
> + * DOC: overview
> + *
> + * This library provides helpers for drivers that don't subclass
> + * _framebuffer and and use _gem_object for their backing storage.

s/and and/and/

> + *
> + * Drivers without additional needs to validate framebuffers can simply use
> + * drm_gem_fb_create() and everything is wired up automatically. But all
> + * parts can be used individually.

A sentence should not start by "but". How about "Other drivers can use all 
parts independently." ?

> + */
> +
> +/**
> + * drm_gem_fb_get_obj() - Get GEM object for framebuffer
> + * @fb: The framebuffer
> + * @plane: Which plane
> + *
> + * Returns the GEM object for given framebuffer.

You might want to mention that no reference is taken on the GEM object.

> + */
> +struct drm_gem_object *drm_gem_fb_get_obj(struct drm_framebuffer *fb,
> +   unsigned int plane)
> +{
> + if (plane >= 4)
> + return NULL;
> +
> + return fb->obj[plane];
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_fb_get_obj);
> +
> +static struct drm_framebuffer *
> +drm_gem_fb_alloc(struct drm_device *dev,
> +  const struct drm_mode_fb_cmd2 *mode_cmd,
> +  struct drm_gem_object **obj, unsigned int num_planes,
> +  const struct drm_framebuffer_funcs *funcs)
> +{
> + struct drm_framebuffer *fb;
> + int ret, i;

i is never negative, you can make it an unsigned int.

> +
> + fb = kzalloc(sizeof(*fb), GFP_KERNEL);
> + if (!fb)
> + return ERR_PTR(-ENOMEM);
> +
> + drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
> +
> + for (i = 0; i < num_planes; i++)
> + fb->obj[i] = obj[i];
> +
> + ret = drm_framebuffer_init(dev, fb, funcs);
> + if (ret) {
> + DRM_DEV_ERROR(dev->dev, "Failed to init framebuffer: %d\n",
> +   ret);
> + kfree(fb);
> + return ERR_PTR(ret);
> + }
> +
> + return fb;
> +}
> +
> +/**
> + * drm_gem_fb_destroy - Free GEM backed framebuffer
> + * @fb: DRM framebuffer
> + *
> + * Frees a GEM backed framebuffer with it's backing buffer(s) and the

s/it's/its/

> structure
> + * itself. Drivers can use this as their _framebuffer_funcs->destroy
> + * callback.
> + */
> +void drm_gem_fb_destroy(struct drm_framebuffer *fb)
> +{
> + int i;

i is never negative, you can make it an unsigned int.

> +
> + for (i = 0; i < 4; i++)
> + drm_gem_object_put_unlocked(fb->obj[i]);
> +
> + drm_framebuffer_cleanup(fb);
> + kfree(fb);
> +}
> +EXPORT_SYMBOL(drm_gem_fb_destroy);
> +
> +/**
> + * drm_gem_fb_create_handle - Create handle for GEM backed framebuffer
> + * @fb: DRM framebuffer
> + * @file: drm file

Why does the fb have a DRM and the file a drm ? :-) I would pick one and stick 
to it for the whole file.

> + * @handle: handle created
> + *
> + * Drivers can use this as their _framebuffer_funcs->create_handle
> + * callback.
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_gem_fb_create_handle(struct drm_framebuffer *fb, struct drm_file
> *file,
> +  unsigned int *handle)
> +{
> + return drm_gem_handle_create(file, fb->obj[0], handle);
> +}
> +EXPORT_SYMBOL(drm_gem_fb_create_handle);
> +
> +/**
> + * drm_gem_fb_create_with_funcs() - helper function for the
> + *  _mode_config_funcs.fb_create
> + *  callback
> + * @dev: DRM device
> + * @file: drm file for the ioctl call
> + * @mode_cmd: metadata from the userspace fb creation request

This looks like data to me, not metadata (data about the data). Same for the 
next function.

> + * @funcs: vtable to be used for the new framebuffer object
> + *
> + * This can be used to set _framebuffer_funcs for drivers that need the
> + * _framebuffer_funcs.dirty 

[pull] amdgpu drm-fixes-4.13

[Alex Deucher]

Hi Dave,

Just one fix for high CPU usage with fence synchronization.

The following changes since commit 46828dc77961d9286e55671c4dd3b6c9effadf1a:

  Merge branch 'linux-4.13' of git://github.com/skeggsb/linux into drm-fixes 
(2017-08-10 11:45:04 +1000)

are available in the git repository at:

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

for you to fetch changes up to 7a7c286d07f9c704e8fd11dd960bf421cc67b66b:

  drm/amdgpu: save list length when fence is signaled (2017-08-15 14:10:01 
-0400)


Chunming Zhou (1):
  drm/amdgpu: save list length when fence is signaled

 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][drm-next] drm/tinydrm: make function st7586_pipe_enable static

[Noralf Trønnes]

Den 16.08.2017 17.46, skrev David Lechner:

On 08/16/2017 04:23 AM, Colin King wrote:

From: Colin Ian King 

The function st7586_pipe_enable  is local to the source
and does not need to be in global scope, so make it static.

Cleans up sparse warning:
symbol 'st7586_pipe_enable' was not declared. Should it be static?

Signed-off-by: Colin Ian King 
---


Acked-By: David Lechner 


Thanks, applied to drm-misc.

Noralf.

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

Re: [PATCH v3 02/22] drm/fb-cma-helper: Use drm_gem_framebuffer_helper

[Noralf Trønnes]

Den 16.08.2017 19.33, skrev Eric Anholt:

Noralf Trønnes  writes:


Use the new drm_gem_framebuffer_helper who's code was copied
from this helper.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/drm_fb_cma_helper.c | 181 ++--
  1 file changed, 30 insertions(+), 151 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index ade319d..e1befee 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -250,12 +143,14 @@ EXPORT_SYMBOL_GPL(drm_fb_cma_create);
  struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct drm_framebuffer *fb,
  unsigned int plane)
  {
-   struct drm_fb_cma *fb_cma = to_fb_cma(fb);
+   struct drm_gem_object *gem;
  
-	if (plane >= 4)

+   gem = drm_gem_fb_get_obj(fb, plane);
+   if (!gem)
return NULL;
  
-	return fb_cma->obj[plane];

+   return to_drm_gem_cma_obj(gem);
+
  }

Stray whitespace.  Other than that,

Reviewed-by: Eric Anholt 

Feel free to push vc4 and pl111 with this patch.


Thanks Eric, this patch, vc4 and pl111 applied to drm-misc.

Noralf.

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

[Bug 102253] Request for freedesktop.org account

[bugzilla-daemon]

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

--- Comment #3 from Daniel Vetter  ---
Ack.

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

[pull] radeon and amdgpu drm-next-4.14

[Alex Deucher]

Hi Dave,

More features for 4.14.  Nothing too major here.  I have a few more additional
patches for large page support in vega10 among other things, but they require
some resevation object patches from drm-misc-next, so I'll send that request
once you've pulled the latest drm-misc-next.  Highlights:
- Fixes for ACP audio on stoney
- SR-IOV fixes for vega10
- various powerplay fixes
- lots of code clean up

The following changes since commit 09ef2378dc42339f3871584dc26d27da220277cb:

  Merge tag 'drm-misc-next-2017-08-08' of 
git://anongit.freedesktop.org/git/drm-misc into drm-next (2017-08-10 10:47:33 
+1000)

are available in the git repository at:

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

for you to fetch changes up to 37899a5254917e17418bbb23086d55e38faaa659:

  drm/amdgpu/gfx7: fix function name (2017-08-15 14:46:23 -0400)


Alex Deucher (10):
  drm/amdgpu: make wb 256bit function names consistent
  drm/amdgpu: drop old ip definitions for gfxhub and mmhub
  drm/amdgpu/sdma4: drop unused register header
  drm/amdgpu/sdma4: set wptr shadow atomically (v2)
  drm/amdgpu/sdma4: drop hdp flush from wptr shadow update
  drm/amdgpu/sdma4: drop allocation of poll_mem_offs
  drm/amdgpu/sdma4: move wptr polling setup
  drm/amdgpu: use 256 bit buffers for all wb allocations (v2)
  drm/amd/powerplay: add CZ profile support
  drm/amdgpu/gfx7: fix function name

Christian König (8):
  drm/amdgpu: cleanup kptr handling
  drm/amdgpu: consistent use u64_to_user_ptr
  drm/amdgpu: move some defines around
  drm/amdgpu: shadow and mn list are mutually exclusive
  drm/amdgpu: improve amdgpu_bo_create_kernel
  drm/amdgpu: add amdgpu_bo_create_reserved
  drm/amdgpu: use amdgpu_bo_create_kernel more often
  drm/amdgpu: use amdgpu_bo_free_kernel more often

Cihangir Akturk (2):
  drm/amdgpu: switch to drm_*{get,put} helpers
  drm/radeon: switch to drm_*{get,put} helpers

Dan Carpenter (1):
  drm/amdgpu: Uninitialized variable in amdgpu_ttm_backend_bind()

Evan Quan (5):
  drm/amdgpu: update vega10 golden setting
  drm/amd/powerplay: updated vega10 fan control
  drm/amd/powerplay: update didt configs
  drm/amdgpu: fix missing endian-safe guard
  drm/amdgpu: jt_size was wrongly counted twice

Felix Kuehling (1):
  drm/amdgpu: Fix KFD initialization for multi-GPU systems

Frank Min (8):
  drm/amdgpu: Clear vce ring wptr for SRIOV
  drm/amdgpu: Enable uvd and vce gpu re-init for SRIOV gpu reset
  drm/amdgpu/vce4: Remove vce interrupt enable related code for sriov
  drm/amdgpu: Skip uvd and vce ring test for SRIOV
  drm/amdgpu: According hardware design revert vce and uvd doorbell 
assignment
  drm/amdgpu/vce4: optimize vce 4.0 init table sequence for SRIOV
  drm/amdgpu/uvd7: optimize uvd initialization sequence for SRIOV
  drm/amdgpu/sdma4: Enable sdma poll mem addr on vega10 for SRIOV

Hawking Zhang (1):
  drm/amdgpu: ignore digest_size when loading sdma fw for raven

Huang Rui (1):
  drm/amdgpu: set gfx_v9_0_ip_funcs as static

Jean Delvare (5):
  drm/amdgpu: Fix undue fallthroughs in golden registers initialization
  drm/amdgpu: Fix dce_v6_0_disable_dce warning
  drm/amdgpu: Fix amdgpu_pm_acpi_event_handler warning
  drm/radeon: Make radeon_atif_handler static
  drm/amdgpu: Make amdgpu_atif_handler static

Junwei Zhang (1):
  drm/amd/powerplay: add vclk/dclkSoftMin support for raven

Kent Russell (4):
  drm/amdgpu: Fix stolen typo
  drm/radeon: Fix stolen typo
  drm/amdgpu: Fix preferred typo
  drm/radeon: Fix preferred typo

Leo Liu (1):
  drm/amdgpu: disable vcn power control for now

Rex Zhu (7):
  drm/amd/powerplay: delete PCC error message in smu7_hwmgr.c
  drm/amd/powerplay: fix force dpm level failed on CZ
  drm/amd/powerplay: fix set highest mclk level failed on Vega10
  drm/amd/powerplay: fix PSI not enabled by kmd
  drm/amd/powerplay: fix coccinelle warnings in vega10_hwmgr.c
  drm/amd/powerplay: refine dmesg info under powerplay.
  drm/amd/powerplay: fix coding style in hwmgr.c

Trigger Huang (1):
  drm/amdgpu: don't finish the ring if not initialized

Vijendar Mukunda (2):
  drm/amd/amdgpu: Added a quirk for Stoney platform
  drm/amd/amdgpu: Disabling Power Gating for Stoney platform

Xiangliang.Yu (1):
  drm/amdgpu/dce_virtual: remove error message for vega10

Yong Zhao (3):
  drm/amdgpu: Add support for filling a buffer with 64 bit value
  drm/amdgpu: Add a parameter to amdgpu_bo_create()
  drm/amdgpu: Support IOMMU on Raven

 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 100 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c|  72 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c |  40 ++--
 

Re: [PATCH v2 00/19] drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy

[Noralf Trønnes]

Den 16.08.2017 09.49, skrev Daniel Vetter:

On Tue, Aug 15, 2017 at 10:58:21PM +0200, Noralf Trønnes wrote:

Den 06.08.2017 17.40, skrev Noralf Trønnes:

This is a follow up with the patches that haven't been reviewed.
First version:
https://lists.freedesktop.org/archives/dri-devel/2017-July/148101.html

Changes since version 1
---
- Exynos can also use drm_gem_dumb_map_offset() (Emil Velikov)
- Remove drm_gem_cma_dumb_map_offset() (Philipp Zabel)

Noralf.

Noralf Trønnes (19):
drm/kirin: Use .dumb_map_offset and .dumb_destroy defaults
drm/meson: Use .dumb_map_offset and .dumb_destroy defaults
drm/mxsfb: Use .dumb_map_offset and .dumb_destroy defaults

I'd appreciate if someone could ack the remaining cma specific patches
to get the function out of the way:

[v2,01/19] drm/kirin: Use .dumb_map_offset and .dumb_destroy defaults
[v2,02/19] drm/meson: Use .dumb_map_offset and .dumb_destroy defaults
[v2,03/19] drm/mxsfb: Use .dumb_map_offset and .dumb_destroy defaults
[v2,19/19] drm/gem-cma-helper: Remove drm_gem_cma_dumb_map_offset()

I did a bit more and looked at all the patches which don't have a reply
from a maintainer yet. I've found a few more things to delete I think, but
the patches are all

Reviewed-by: Daniel Vetter 

as-is. Feel free to do the additional removing (assuming I didn't miss
anything) if you have time, but no worries if not.

Great work!


Thanks Daniel, I've applied all but armada. I'll respin it with the
dma-buf check added to drm_gem_dumb_map_offset().

Noralf.


Cheers, Daniel


Noralf.


drm/sti: Use .dumb_map_offset and .dumb_destroy defaults
drm/gma500: Use .dumb_map_offset and .dumb_destroy defaults
drm/tegra: Use .dumb_map_offset and .dumb_destroy defaults
drm/cirrus: Use the drm_driver.dumb_destroy default
drm/udl: Use the drm_driver.dumb_destroy default
drm/qxl: Use the drm_driver.dumb_destroy default
drm/ast: Use the drm_driver.dumb_destroy default
drm/i915: Use the drm_driver.dumb_destroy default
drm/msm: Use the drm_driver.dumb_destroy default
drm/exynos: Use .dumb_map_offset and .dumb_destroy defaults
drm/mgag200: Use the drm_driver.dumb_destroy default
drm/radeon: Use the drm_driver.dumb_destroy default
drm/bochs: Use the drm_driver.dumb_destroy default
drm/armada: Use the drm_driver.dumb_destroy default
drm/virtio: Use the drm_driver.dumb_destroy default
drm/gem-cma-helper: Remove drm_gem_cma_dumb_map_offset()

   drivers/gpu/drm/armada/armada_drv.c |  1 -
   drivers/gpu/drm/armada/armada_gem.c |  6 -
   drivers/gpu/drm/armada/armada_gem.h |  2 --
   drivers/gpu/drm/ast/ast_drv.c   |  1 -
   drivers/gpu/drm/bochs/bochs_drv.c   |  1 -
   drivers/gpu/drm/cirrus/cirrus_drv.c |  1 -
   drivers/gpu/drm/drm_gem_cma_helper.c| 35 
-
   drivers/gpu/drm/exynos/exynos_drm_drv.c |  2 --
   drivers/gpu/drm/exynos/exynos_drm_gem.c | 30 ++---
   drivers/gpu/drm/exynos/exynos_drm_gem.h |  5 
   drivers/gpu/drm/gma500/gem.c| 30 -
   drivers/gpu/drm/gma500/psb_drv.c|  2 --
   drivers/gpu/drm/gma500/psb_drv.h|  2 --
   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  2 --
   drivers/gpu/drm/i915/i915_drv.c |  1 -
   drivers/gpu/drm/meson/meson_drv.c   |  2 --
   drivers/gpu/drm/mgag200/mgag200_drv.c   |  1 -
   drivers/gpu/drm/msm/msm_drv.c   |  1 -
   drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 --
   drivers/gpu/drm/qxl/qxl_drv.c   |  1 -
   drivers/gpu/drm/radeon/radeon_drv.c |  1 -
   drivers/gpu/drm/sti/sti_drv.c   |  2 --
   drivers/gpu/drm/tegra/drm.c |  2 --
   drivers/gpu/drm/tegra/gem.c | 21 ---
   drivers/gpu/drm/tegra/gem.h |  2 --
   drivers/gpu/drm/udl/udl_drv.c   |  1 -
   drivers/gpu/drm/virtio/virtgpu_drv.c|  1 -
   drivers/gpu/drm/virtio/virtgpu_drv.h|  3 ---
   drivers/gpu/drm/virtio/virtgpu_gem.c|  7 -
   include/drm/drm_gem_cma_helper.h|  5 
   30 files changed, 2 insertions(+), 171 deletions(-)


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


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

Re: [PATCH] drm/amd/display: put commit when -ERESTARTSYS received

[Harry Wentland]

On 2017-08-16 01:22 PM, Daniel Vetter wrote:
> On Wed, Aug 16, 2017 at 7:12 PM, Alex Deucher  wrote:
>> On Wed, Aug 16, 2017 at 10:22 AM, Jerry Zuo  wrote:
>>> During page flip atomic_check and atomic_commit can return
>>> -ERESTARTSYS to restart the ioctl. When this happens we fail to
>>> put the commit object leading to a memory leak.
>>>
>>> Signed-off-by: Jerry Zuo 
>>
>> The subject should be:
>> drm/atomic: put commit when -ERESTARTSYS received
>> Since the change is in the core atomic code.
> 
> Do we have an igt testcase to exercise this? This is the kind of error
> case handling igt really is made for, and igt has ready-made helpers
> to interrupt ioctls. I think Maarten was even working on such a
> testcase, adding him.

I'm not aware of an IGT test for this. We triggered this scenario when
running mode changes while glxgears is running. We observed no
user-visible issue, only a memory leak. Is IGT able to capture those
(semi-)reliably?

I agree that it would be great to have an IGT test for these corner cases.

Harry

> -Daniel
> >>
>> Alex
>>
>>> ---
>>>  drivers/gpu/drm/drm_atomic.c | 25 +++--
>>>  1 file changed, 23 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index f32506a7c1d6..f2f623dacf90 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -1642,14 +1642,35 @@ int drm_atomic_nonblocking_commit(struct 
>>> drm_atomic_state *state)
>>>  {
>>> struct drm_mode_config *config = >dev->mode_config;
>>> int ret;
>>> +   int i;
>>> +   struct drm_crtc *crtc;
>>> +   struct drm_crtc_state *crtc_state;
>>>
>>> ret = drm_atomic_check_only(state);
>>> -   if (ret)
>>> +   if (ret) {
>>> +   if (ret == -ERESTARTSYS)
>>> +   goto fail;
>>> +
>>> return ret;
>>> +   }
>>>
>>> DRM_DEBUG_ATOMIC("commiting %p nonblocking\n", state);
>>>
>>> -   return config->funcs->atomic_commit(state->dev, state, true);
>>> +   ret = config->funcs->atomic_commit(state->dev, state, true);
>>> +   if (ret == -ERESTARTSYS)
>>> +   goto fail;
>>> +
>>> +   return ret;
>>> +
>>> +   /* cleanup commit object if commit fails with ERESTARTSYS */
>>> +fail:
>>> +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>>> +   if (state->crtcs[i].commit) {
>>> +   drm_crtc_commit_put(state->crtcs[i].commit);
>>> +   }
>>> +   }
>>> +
>>> +   return ret;
>>>  }
>>>  EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
>>>
>>> --
>>> 2.11.0
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 02/22] drm/fb-cma-helper: Use drm_gem_framebuffer_helper

[Eric Anholt]

Noralf Trønnes  writes:

> Use the new drm_gem_framebuffer_helper who's code was copied
> from this helper.
>
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_fb_cma_helper.c | 181 
> ++--
>  1 file changed, 30 insertions(+), 151 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index ade319d..e1befee 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c

> @@ -250,12 +143,14 @@ EXPORT_SYMBOL_GPL(drm_fb_cma_create);
>  struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct drm_framebuffer *fb,
> unsigned int plane)
>  {
> - struct drm_fb_cma *fb_cma = to_fb_cma(fb);
> + struct drm_gem_object *gem;
>  
> - if (plane >= 4)
> + gem = drm_gem_fb_get_obj(fb, plane);
> + if (!gem)
>   return NULL;
>  
> - return fb_cma->obj[plane];
> + return to_drm_gem_cma_obj(gem);
> +
>  }

Stray whitespace.  Other than that,

Reviewed-by: Eric Anholt 

Feel free to push vc4 and pl111 with this patch.


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

Re: [PATCH v3 22/22] drm/fb-cma-helper: Remove unused functions

[Eric Anholt]

Noralf Trønnes  writes:

> The cma drivers use the drm_gem_framebuffer_helper functions now,
> so remove drm_fb_cma_destroy, drm_fb_cma_create_handle,
> drm_fb_cma_create_with_funcs, drm_fb_cma_create and
> drm_fb_cma_prepare_fb.
>
> Signed-off-by: Noralf Trønnes 

Reviewed-by: Eric Anholt 


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

Re: [PATCH v3 13/22] drm/pl111: Use drm_gem_fb_create() and drm_gem_fb_prepare_fb()

[Eric Anholt]

Noralf Trønnes  writes:

> drm_fb_cma_create() and drm_fb_cma_prepare_fb() are just wrappers now,
> use drm_gem_fb_create() and drm_gem_fb_prepare_fb() directly.

Reviewed-by: Eric Anholt 


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

Re: [PATCH v3 20/22] drm/vc4: Use drm_gem_fb_create()

[Eric Anholt]

Noralf Trønnes  writes:

> drm_fb_cma_create() is just a wrapper around drm_gem_fb_create() now,
> so use the function directly.

Reviewed-by: Eric Anholt 

Looks like I should be using the default helper in place of
vc4_prepare_fb(), too.


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

Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

[Eric Anholt]

Noralf Trønnes  writes:

> This library provides helpers for drivers that don't subclass
> drm_framebuffer and are backed by drm_gem_object. The code is
> taken from drm_fb_cma_helper.
>
> Signed-off-by: Noralf Trønnes 
> Reviewed-by: Daniel Vetter 
> ---

> +/**
> + * drm_gem_fb_destroy - Free GEM backed framebuffer
> + * @fb: DRM framebuffer
> + *
> + * Frees a GEM backed framebuffer with it's backing buffer(s) and the 
> structure

grammar nit: "its"

Other than that,

Reviewed-by: Eric Anholt 


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

Re: [PATCH 0/9] drm/syncobj: Add full-featured wait support (v2)

[Christian König]

[SNIP]

See a wait_queue is a callback mechanism anyway, so you are
wrapping a callback mechanism inside another callback
mechanism and that makes not really much sense.


Fair enough.  There is one little snag though:  We need to wait on
sync objects and fences at the same time in order for WAIT_ANY |
WAIT_FOR_SUBMIT to work. I see two options here:

 1) Convert dma-fence to use waitqueue instead of its callback
mechanism and add a wait_queue_any.  A quick grep for
dma_fence_add_callback says that this would affect four drivers.


The more I think about it, the less sense using waitqueues makes.  The 
fundamental problem here is that the event we are waiting on is 
actually the concatenation of two events: submit and signal.  Since we 
are waiting on several of these pairs of concatenated events 
simultaneously, the only two options we have are to either combine 
them into one event (the proxy approach) or to implement a wait which 
is capable of handling both at the same time.  I don't see a way to do 
the latter with wait queues.


Agree completely.

Essentially we would need to enable wait_event_* to wait for multiple 
events and then convert all the fence callback stuff to wait_event 
structures.


But that is certainly outside the scope of this patchset, so feel free 
to go ahead with the approach of waiting manually (but please without 
the bugs).


Well if you got a student/interim with free time that would certainly be 
a nice cleanup task to start on kernel work.


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

Re: [PATCH v2 07/19] drm/cirrus: Use the drm_driver.dumb_destroy default

[Daniel Vetter]

On Wed, Aug 16, 2017 at 3:41 PM, Noralf Trønnes  wrote:
>
> Den 16.08.2017 09.38, skrev Daniel Vetter:
>>
>> On Sun, Aug 06, 2017 at 05:40:56PM +0200, Noralf Trønnes wrote:
>>>
>>> drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
>>> so no need to set it.
>>>
>>> Cc: Dave Airlie 
>>> Cc: Gerd Hoffmann 
>>> Signed-off-by: Noralf Trønnes 
>>> ---
>>>   drivers/gpu/drm/cirrus/cirrus_drv.c | 1 -
>>>   1 file changed, 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
>>> b/drivers/gpu/drm/cirrus/cirrus_drv.c
>>> index 910c300..69c4e35 100644
>>> --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
>>> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
>>> @@ -142,7 +142,6 @@ static struct drm_driver driver = {
>>> .gem_free_object_unlocked = cirrus_gem_free_object,
>>> .dumb_create = cirrus_dumb_create,
>>> .dumb_map_offset = cirrus_dumb_mmap_offset,
>>
>> I think the cirrus mmap_offset could be replaced too, it's just written
>> slightly differently from what I can tell with the separate helper
>> function.
>
>
> Emil asked about the same, but cirrus uses ttm_buffer_object.vma_node
> to get the offset and not drm_gem_object.vma_node.
> He couldn't answer whether they're the same vma_node or not.

Indeed I misread them all, this is using ttm. In reality we could
replace it all with the gem mmap stuff, but that also means we need to
changed drm_driver->fops->mmap to drm_gem_mmap. Across all drivers
this would delete impressive amounts of code, but quite a bit of work
too. The only drivers which probably should keep the ttm way of mmap
are those who's ttm_bo_driver->very_access is not implemented through
drm_vma_node_verify_access().
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Try to document legacy DPMS uapi a bit better

[Daniel Vetter]

On Wed, Aug 16, 2017 at 4:49 PM, Laurent Pinchart
 wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Tuesday 15 Aug 2017 16:55:19 Daniel Vetter wrote:
>> Laurent asked for this.
>
> While this is true, I'm not sure it makes a proper commit message :-)
>
>> Cc: Laurent Pinchart 
>> Signed-off-by: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/drm_connector.c | 19 +++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index ba9f36cef68c..b458eb488128 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -720,6 +720,25 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>>   *   callback. For atomic drivers the remapping to the "ACTIVE" property is
>>   *   implemented in the DRM core.  This is the only standard connector
>>   *   property that userspace can change.
>> + *
>> + *   WARNING:
>> + *
>> + *   For userspace also running on legacy drivers the "DPMS" semantics are
>> + *   a lot more complicated.
>
> What is "userspace also running on legacy drivers" ? Is that userspace that is
> atomic-aware and have different codes paths for atomic and non-atomic drivers,
> or userspace that uses the legacy API regardless of the driver ? I assume you
> mean the latter, in which case I would write it as "userspace using the legacy
> non-atomic API with atomic drivers".

Legacy DPMS on atomic drivers has well-defined semantics. Legacy DPMS
on legacy drivers is much worse, which is what this WARNING describes.
The intro para only defines how DPMS works for atomic drivers.

I'm not exactly sure how I can make this clearer, please give a
proposal. I thought it's pretty obvious that this is all about legacy
drivers, but somehow you read the entire thing as applying to atomic
drivers.

>> First, userspace cannot rely on the "DPMS"
>> + *   value returned by the GETCONNECTOR actually reflecting reality,
>> + *   because many drivers fail to update it. For atomic drivers this is
>> + *   taken care of in drm_atomic_helper_update_legacy_modeset_state().
>
> Are you talking about atomic drivers not using
> drm_atomic_helper_update_legacy_modeset_state() (directly or indirectly
> through the atomic commit helpers) ? Are there many of those ? They should be
> fixed, I don't think we should consider this as the normal behaviour. I'd
> rather explain how the connector DPMS interacts with the connector CRTC_ID and
> the CRTC ACTIVE properties when the drivers get it right, and then possibly
> add a warning that some drivers don't implement it correctly.

Again this is about legacy drivers.

> I think "reflecting reality" is also vague. What do you mean by reality ? The
> fact the the DPMS property should reflect whether the connector is linked to
> an active CRTC (as explained in the existing DPMS property documentation) ?

The reality of the non-atomic drivers we still ship. Where is the
"existing DPMS property documentation" btw? This here should be
everything, and it makes it clear DPMS is not very well linked to
anything.

>> + *   The second issue is that the DPMS state is only relevant when the
>> + *   connector is connected to a CRTC. In atomic the DRM core enforces that
>> + *   "ACTIVE" is off in such a case, no such checks exists for "DPMS".
>
> What is "such a case" ? A connector not connected to a CRTC ?

Yes. I guess I can hammer this home by repetition :-)

>> + *   Finally, when enabling an output using the legacy SETCONFIG ioctl then
>> + *   "DPMS" is forced to ON. But see above, that might not be reflected in
>> + *   the software value.
>> + *
>> + *   Summarizing: Only set "DPMS" when the connector is known to be
>> + *   enabled, assume that a successful SETCONFIG call also set "DPMS" to
>> + *   on, and never read back the value of "DPMS" because it can be
>> + *   incorrect.
>
> The need to summarize two paragraphs in a third one indicates to me that the
> documentation is confusing.

The idea is to give userspace writers guidelines what they should do
with DPMS. Should I make clearer what the audience of that summary is,
or is there no value in that?
-Daniel

>
>>   * PATH:
>>   *   Connector path property to identify how this sink is physically
>>   *   connected. Used by DP MST. This should be set by calling
>
> --
> Regards,
>
> Laurent Pinchart
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102247] Mesa failing to compile

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer  ---
https://patchwork.freedesktop.org/patch/171990/ should fix this.

-- 
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: Try to document legacy DPMS uapi a bit better

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Tuesday 15 Aug 2017 16:55:19 Daniel Vetter wrote:
> Laurent asked for this.

While this is true, I'm not sure it makes a proper commit message :-)

> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_connector.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c
> b/drivers/gpu/drm/drm_connector.c index ba9f36cef68c..b458eb488128 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -720,6 +720,25 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>   *   callback. For atomic drivers the remapping to the "ACTIVE" property is
>   *   implemented in the DRM core.  This is the only standard connector
>   *   property that userspace can change.
> + *
> + *   WARNING:
> + *
> + *   For userspace also running on legacy drivers the "DPMS" semantics are
> + *   a lot more complicated.

What is "userspace also running on legacy drivers" ? Is that userspace that is 
atomic-aware and have different codes paths for atomic and non-atomic drivers, 
or userspace that uses the legacy API regardless of the driver ? I assume you 
mean the latter, in which case I would write it as "userspace using the legacy 
non-atomic API with atomic drivers".

> First, userspace cannot rely on the "DPMS"
> + *   value returned by the GETCONNECTOR actually reflecting reality,
> + *   because many drivers fail to update it. For atomic drivers this is
> + *   taken care of in drm_atomic_helper_update_legacy_modeset_state().

Are you talking about atomic drivers not using 
drm_atomic_helper_update_legacy_modeset_state() (directly or indirectly 
through the atomic commit helpers) ? Are there many of those ? They should be 
fixed, I don't think we should consider this as the normal behaviour. I'd 
rather explain how the connector DPMS interacts with the connector CRTC_ID and 
the CRTC ACTIVE properties when the drivers get it right, and then possibly 
add a warning that some drivers don't implement it correctly.

I think "reflecting reality" is also vague. What do you mean by reality ? The 
fact the the DPMS property should reflect whether the connector is linked to 
an active CRTC (as explained in the existing DPMS property documentation) ?

> + *   The second issue is that the DPMS state is only relevant when the
> + *   connector is connected to a CRTC. In atomic the DRM core enforces that
> + *   "ACTIVE" is off in such a case, no such checks exists for "DPMS".

What is "such a case" ? A connector not connected to a CRTC ?

> + *   Finally, when enabling an output using the legacy SETCONFIG ioctl then
> + *   "DPMS" is forced to ON. But see above, that might not be reflected in
> + *   the software value.
> + *
> + *   Summarizing: Only set "DPMS" when the connector is known to be
> + *   enabled, assume that a successful SETCONFIG call also set "DPMS" to
> + *   on, and never read back the value of "DPMS" because it can be
> + *   incorrect.

The need to summarize two paragraphs in a third one indicates to me that the 
documentation is confusing.

>   * PATH:
>   *   Connector path property to identify how this sink is physically
>   *   connected. Used by DP MST. This should be set by calling

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/omap: remove no-op cleanup code

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Wednesday 16 Aug 2017 12:11:25 Tomi Valkeinen wrote:
> The driver sets crtc and plane rotation properties back to 0 degrees in
> dev_lastclose() using drm_object_property_set_value().
> drm_object_property_set_value() doesn't do anything with atomic drivers,
> and a recent change added WARN_ON() when atomic driver calls the
> function.
> 
> So remove the code.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 33 -
>  1 file changed, 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index 17f13efcfebd..46ee0f25262e
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -464,44 +464,11 @@ static int dev_open(struct drm_device *dev, struct
> drm_file *file) */
>  static void dev_lastclose(struct drm_device *dev)
>  {
> - int i;
> -
> - /* we don't support vga_switcheroo.. so just make sure the fbdev
> -  * mode is active
> -  */
>   struct omap_drm_private *priv = dev->dev_private;
>   int ret;
> 
>   DBG("lastclose: dev=%p", dev);
> 
> - /* need to restore default rotation state.. not sure
> -  * if there is a cleaner way to restore properties to
> -  * default state?  Maybe a flag that properties should
> -  * automatically be restored to default state on
> -  * lastclose?
> -  */
> - for (i = 0; i < priv->num_crtcs; i++) {
> - struct drm_crtc *crtc = priv->crtcs[i];
> -
> - if (!crtc->primary->rotation_property)
> - continue;
> -
> - drm_object_property_set_value(>base,
> -   crtc->primary-
>rotation_property,
> -   DRM_MODE_ROTATE_0);
> - }
> -
> - for (i = 0; i < priv->num_planes; i++) {
> - struct drm_plane *plane = priv->planes[i];
> -
> - if (!plane->rotation_property)
> - continue;
> -
> - drm_object_property_set_value(>base,
> -   plane->rotation_property,
> -   DRM_MODE_ROTATE_0);
> - }
> -
>   if (priv->fbdev) {
>   ret = drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
>   if (ret)

-- 
Regards,

Laurent Pinchart

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

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #23 from Michel Dänzer  ---
Looks like there are two separate issues here — the corruption shown in Timo's
video in the original bug description, and the tearing shown in Ethan's video
and photo. They need to be tracked separately.

-- 
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 100577] DC + TearFree display lock

[bugzilla-daemon]

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

Andy Furniss  changed:

   What|Removed |Added

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

--- Comment #17 from Andy Furniss  ---
Testing with amd-staging-drm-next, which doesn't peg memclk high I can't
reproduce this anymore.

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

Re: [PATCHv2] drm: omapdrm: Register omapdrm platform device in omapdss driver

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Wednesday 16 Aug 2017 12:49:01 Tomi Valkeinen wrote:
> From: Laurent Pinchart 
> 
> The omapdrm platform device is a virtual device created for the sole
> purpose of handling the omapdss/omapdrm driver split. It should
> eventually be removed. As a first step to ease refactoring move its
> registration from platform code to driver code.
> 
> The omapdrm driver name must be changed internally to avoid probing both
> the device registered in platform code and the device registered in the
> omapdss driver, as that would otherwise break bisection.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Tomi Valkeinen 
> Signed-off-by: Tomi Valkeinen 

This looks good to me, so

Reviewed-by: Laurent Pinchart 

I trust that you have tested the patch with module unloading given that was 
how you found the original issue :-)

> ---
> 
> I reworked this patch to create the platform device dynamically.
> 
>  drivers/gpu/drm/omapdrm/dss/core.c | 10 ++
>  drivers/gpu/drm/omapdrm/omap_drv.c |  8 +++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/core.c
> b/drivers/gpu/drm/omapdrm/dss/core.c index 4dabe32c7098..6b3247c4f857
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/core.c
> +++ b/drivers/gpu/drm/omapdrm/dss/core.c
> @@ -103,6 +103,8 @@ static void (*dss_output_drv_unreg_funcs[])(void) = {
>   dss_uninit_platform_driver,
>  };
> 
> +static struct platform_device *omap_drm_device;
> +
>  static int __init omap_dss_init(void)
>  {
>   int r;
> @@ -118,6 +120,12 @@ static int __init omap_dss_init(void)
>   goto err_reg;
>   }
> 
> + omap_drm_device = platform_device_register_simple("omapdrm_", 0, NULL, 
0);
> + if (IS_ERR(omap_drm_device)) {
> + r = PTR_ERR(omap_drm_device);
> + goto err_reg;
> + }
> +
>   return 0;
> 
>  err_reg:
> @@ -135,6 +143,8 @@ static void __exit omap_dss_exit(void)
>  {
>   int i;
> 
> + platform_device_unregister(omap_drm_device);
> +
>   for (i = 0; i < ARRAY_SIZE(dss_output_drv_unreg_funcs); ++i)
>   dss_output_drv_unreg_funcs[i]();
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index 10e24ca928f2..2b990daf0052
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -575,6 +575,12 @@ static int pdev_probe(struct platform_device *pdev)
>   if (omapdss_is_initialized() == false)
>   return -EPROBE_DEFER;
> 
> + ret = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
> + if (ret) {
> + dev_err(>dev, "Failed to set the DMA mask\n");
> + return ret;
> + }
> +
>   omap_crtc_pre_init();
> 
>   ret = omap_connect_dssdevs();
> @@ -762,7 +768,7 @@ static SIMPLE_DEV_PM_OPS(omapdrm_pm_ops,
> omap_drm_suspend, omap_drm_resume);
> 
>  static struct platform_driver pdev = {
>   .driver = {
> - .name = DRIVER_NAME,
> + .name = "omapdrm_",
>   .pm = _pm_ops,
>   },
>   .probe = pdev_probe,

-- 
Regards,

Laurent Pinchart

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

[Bug 102253] Request for freedesktop.org account

[bugzilla-daemon]

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

Linus Walleij  changed:

   What|Removed |Added

 Attachment #133546|0   |1
is obsolete||

--- Comment #1 from Linus Walleij  ---
Created attachment 133547
  --> https://bugs.freedesktop.org/attachment.cgi?id=133547=edit
Public SSH key, RSA plain text

-- 
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 102253] Request for freedesktop.org account

[bugzilla-daemon]

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

Bug ID: 102253
   Summary: Request for freedesktop.org account
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: linus.wall...@linaro.org

Created attachment 133546
  --> https://bugs.freedesktop.org/attachment.cgi?id=133546=edit
Public SSH key, RSA

Requesting a freedesktop.org account for myself to work on dri-misc.
Name: Linus Walleij
Mail linus.wall...@linaro.org
Account name: linusw

-- 
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/bridge/sii8620: add remote control support

[Andrzej Hajda]

On 03.08.2017 10:28, Hans Verkuil wrote:
> Hi Maciej,
>
> Unfortunately I do not have the MHL spec, but I was wondering what the
> relationship between RCP and CEC is. CEC has remote control support as
> well, so is RCP that subset of the CEC specification or is it completely
> separate?

We also do not have MHL specs. From my research it looks like MHL
consortium was mainly focused on supporting different input devices -
remote control, mice, keyboard, touchscreen, game controller, etc. In
public data sheets of some chips Lattice/Silicon Image (main MHL chip
producer) suggest they do not support CEC pass-through via MHL[1].
On the other side superMHL extends RCP with support for multiple devices
[2], so for me it looks like RCP wants to be an alternative to CEC.
But all this is just my interpretation of info found on the Net.

[1]:
http://www.latticesemi.com/~/media/LatticeSemi/Documents/DataSheets/ASSP/SiI-DS-1128_Public.pdf?document_id=51627
[2]: https://en.wikipedia.org/wiki/Mobile_High-Definition_Link#superMHL

Regards
Andrzej

>
> I'm CC-ing Sean Young and the linux-media mailinglist as well since Sean
> maintains the rc subsystem. Which you probably should use, but I'm not the
> expert on that.
>
> Regards,
>
>   Hans
>
> On 08/03/17 09:44, Maciej Purski wrote:
>> MHL specification defines Remote Control Protocol(RCP) to
>> send input events between MHL devices.
>> The driver now recognizes RCP messages and reacts to them
>> by reporting key events to input subsystem, allowing
>> a user to control a device using TV remote control.
>>
>> Signed-off-by: Maciej Purski 
>> ---
>>  drivers/gpu/drm/bridge/sil-sii8620.c | 188 
>> ++-
>>  include/drm/bridge/mhl.h |   4 +
>>  2 files changed, 187 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>> index 2d51a22..7e75f2f 100644
>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -58,6 +59,7 @@ enum sii8620_mt_state {
>>  struct sii8620 {
>>  struct drm_bridge bridge;
>>  struct device *dev;
>> +struct input_dev *rcp_input_dev;
>>  struct clk *clk_xtal;
>>  struct gpio_desc *gpio_reset;
>>  struct gpio_desc *gpio_int;
>> @@ -106,6 +108,82 @@ struct sii8620_mt_msg {
>>  sii8620_cb continuation;
>>  };
>>  
>> +static struct {
>> +u16 key;
>> +u16 extra_key;
>> +bool autorepeat;
>> +}  rcp_keymap[] = {
>> +[0x00] = { KEY_SELECT },
>> +[0x01] = { KEY_UP, 0, true },
>> +[0x02] = { KEY_DOWN, 0, true },
>> +[0x03] = { KEY_LEFT, 0, true },
>> +[0x04] = { KEY_RIGHT, 0, true },
>> +
>> +[0x05] = { KEY_RIGHT, KEY_UP, true },
>> +[0x06] = { KEY_RIGHT, KEY_DOWN, true },
>> +[0x07] = { KEY_LEFT,  KEY_UP, true },
>> +[0x08] = { KEY_LEFT,  KEY_DOWN, true },
>> +
>> +[0x09] = { KEY_MENU },
>> +[0x0A] = { KEY_UNKNOWN },
>> +[0x0B] = { KEY_UNKNOWN },
>> +[0x0C] = { KEY_BOOKMARKS },
>> +[0x0D] = { KEY_EXIT },
>> +
>> +[0x20] = { KEY_NUMERIC_0 },
>> +[0x21] = { KEY_NUMERIC_1 },
>> +[0x22] = { KEY_NUMERIC_2 },
>> +[0x23] = { KEY_NUMERIC_3 },
>> +[0x24] = { KEY_NUMERIC_4 },
>> +[0x25] = { KEY_NUMERIC_5 },
>> +[0x26] = { KEY_NUMERIC_6 },
>> +[0x27] = { KEY_NUMERIC_7 },
>> +[0x28] = { KEY_NUMERIC_8 },
>> +[0x29] = { KEY_NUMERIC_9 },
>> +
>> +[0x2A] = { KEY_DOT },
>> +[0x2B] = { KEY_ENTER },
>> +[0x2C] = { KEY_CLEAR },
>> +
>> +[0x30] = { KEY_CHANNELUP, 0, true },
>> +[0x31] = { KEY_CHANNELDOWN, 0, true },
>> +
>> +[0x33] = { KEY_SOUND },
>> +[0x35] = { KEY_PROGRAM }, /* Show Information */
>> +
>> +[0x37] = { KEY_PAGEUP, 0, true },
>> +[0x38] = { KEY_PAGEDOWN, 0, true },
>> +
>> +[0x41] = { KEY_VOLUMEUP, 0, true },
>> +[0x42] = { KEY_VOLUMEDOWN, 0, true },
>> +[0x43] = { KEY_MUTE },
>> +[0x44] = { KEY_PLAY },
>> +[0x45] = { KEY_STOP },
>> +[0x46] = { KEY_PLAYPAUSE }, /* Pause */
>> +[0x47] = { KEY_RECORD },
>> +[0x48] = { KEY_REWIND, 0, true },
>> +[0x49] = { KEY_FASTFORWARD, 0, true },
>> +[0x4A] = { KEY_EJECTCD },
>> +[0x4B] = { KEY_NEXTSONG, 0, true }, /* Forward */
>> +[0x4C] = { KEY_PREVIOUSSONG, 0, true }, /* Backward */
>> +
>> +[0x60] = { KEY_PLAYPAUSE }, /* Play */
>> +[0x61] = { KEY_PLAYPAUSE }, /* Pause the Play */
>> +[0x62] = { KEY_RECORD },
>> +[0x63] = { KEY_PAUSE },
>> +[0x64] = { KEY_STOP },
>> +[0x65] = { KEY_MUTE },
>> +[0x66] = { KEY_MUTE }, /* Restore Mute */
>> +
>> +[0x71] = { KEY_F1 },
>> +[0x72] = { KEY_F2 },
>> +[0x73] = { KEY_F3 },
>> +[0x74] = { KEY_F4 },
>> +[0x75] = { KEY_F5 },
>> +
>> +[0x7E] = { KEY_VENDOR },
>> +};
>> +
>>  static const u8 sii8620_i2c_page[] = {
>>  

[PATCH v2] drm/bridge/sii8620: add remote control support

[Maciej Purski]

MHL specification defines Remote Control Protocol(RCP) to
send input events between MHL devices.
The driver now recognizes RCP messages and reacts to them
by reporting key events to input subsystem, allowing
a user to control a device using TV remote control.

Changes in v2:
- use RC subsystem (including CEC keymap)
- RC device initialized in attach drm_bridge callback and
  removed in detach callback. This is necessary, because RC_CORE,
  which is needed during rc_dev init, is loaded after sii8620.
  DRM bridge is binded later which solves the problem.
- add RC_CORE dependency

Signed-off-by: Maciej Purski 
---
 drivers/gpu/drm/bridge/Kconfig   |  2 +-
 drivers/gpu/drm/bridge/sil-sii8620.c | 99 ++--
 include/drm/bridge/mhl.h |  4 ++
 3 files changed, 99 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0..6ef901c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -71,7 +71,7 @@ config DRM_PARADE_PS8622
 
 config DRM_SIL_SII8620
tristate "Silicon Image SII8620 HDMI/MHL bridge"
-   depends on OF
+   depends on OF && RC_CORE
select DRM_KMS_HELPER
help
  Silicon Image SII8620 HDMI/MHL bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 2d51a22..413806b 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 
+#include 
+
 #include "sil-sii8620.h"
 
 #define SII8620_BURST_BUF_LEN 288
@@ -58,6 +60,7 @@ enum sii8620_mt_state {
 struct sii8620 {
struct drm_bridge bridge;
struct device *dev;
+   struct rc_dev *rc_dev;
struct clk *clk_xtal;
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_int;
@@ -431,6 +434,16 @@ static void sii8620_mt_rap(struct sii8620 *ctx, u8 code)
sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RAP, code);
 }
 
+static void sii8620_mt_rcpk(struct sii8620 *ctx, u8 code)
+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPK, code);
+}
+
+static void sii8620_mt_rcpe(struct sii8620 *ctx, u8 code)
+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPE, code);
+}
+
 static void sii8620_mt_read_devcap_send(struct sii8620 *ctx,
struct sii8620_mt_msg *msg)
 {
@@ -1753,6 +1766,25 @@ static void sii8620_send_features(struct sii8620 *ctx)
sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
 }
 
+static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
+{
+   bool pressed = !(scancode & MHL_RCP_KEY_RELEASED_MASK);
+
+   scancode &= MHL_RCP_KEY_ID_MASK;
+
+   if (!ctx->rc_dev) {
+   dev_dbg(ctx->dev, "RCP input device not initialized\n");
+   return false;
+   }
+
+   if (pressed)
+   rc_keydown(ctx->rc_dev, RC_TYPE_CEC, scancode, 0);
+   else
+   rc_keyup(ctx->rc_dev);
+
+   return true;
+}
+
 static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
 {
u8 ints[MHL_INT_SIZE];
@@ -1804,19 +1836,25 @@ static void sii8620_msc_mt_done(struct sii8620 *ctx)
 
 static void sii8620_msc_mr_msc_msg(struct sii8620 *ctx)
 {
-   struct sii8620_mt_msg *msg = sii8620_msc_msg_first(ctx);
+   struct sii8620_mt_msg *msg;
u8 buf[2];
 
-   if (!msg)
-   return;
-
sii8620_read_buf(ctx, REG_MSC_MR_MSC_MSG_RCVD_1ST_DATA, buf, 2);
 
switch (buf[0]) {
case MHL_MSC_MSG_RAPK:
+   msg = sii8620_msc_msg_first(ctx);
+   if (!msg)
+   return;
msg->ret = buf[1];
ctx->mt_state = MT_STATE_DONE;
break;
+   case MHL_MSC_MSG_RCP:
+   if (!sii8620_rcp_consume(ctx, buf[1]))
+   sii8620_mt_rcpe(ctx,
+   MHL_RCPE_STATUS_INEFFECTIVE_KEY_CODE);
+   sii8620_mt_rcpk(ctx, buf[1]);
+   break;
default:
dev_err(ctx->dev, "%s message type %d,%d not supported",
__func__, buf[0], buf[1]);
@@ -2102,11 +2140,60 @@ static void sii8620_cable_in(struct sii8620 *ctx)
enable_irq(to_i2c_client(ctx->dev)->irq);
 }
 
+static void sii8620_init_rcp_input_dev(struct sii8620 *ctx)
+{
+   struct rc_dev *rc_dev;
+   int ret;
+
+   rc_dev = rc_allocate_device(RC_DRIVER_SCANCODE);
+   if (!rc_dev) {
+   dev_err(ctx->dev, "Failed to allocate RC device\n");
+   ctx->error = -ENOMEM;
+   }
+
+   rc_dev->input_phys = "sii8620/input0";
+   rc_dev->input_id.bustype = BUS_VIRTUAL;
+   rc_dev->map_name = RC_MAP_CEC;
+   rc_dev->allowed_protocols = RC_BIT_CEC;
+   rc_dev->driver_name = "sii8620";
+   rc_dev->input_name = "sii8620";
+
+   ret = rc_register_device(rc_dev);
+
+  

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #22 from Ethan Hsieh  ---
Created attachment 133543
  --> https://bugs.freedesktop.org/attachment.cgi?id=133543=edit
tearing on 5916&5917 (photo)

-- 
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 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #21 from Ethan Hsieh  ---
Created attachment 133542
  --> https://bugs.freedesktop.org/attachment.cgi?id=133542=edit
tearing on 5916&5917 (video)

-- 
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 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #20 from Ethan Hsieh  ---
amdgpu.dpm=0 doesn't really work.
There are some issues when loading amdgpu driver with dpm=0.
It leads to using Intel as OpenGL renderer (glxinfo) instead of AMD.
Error Message: Xorg.0.log:[ 24.261] (II) UnloadModule: "amdgpu"
I got two patches from AMD to fix the issue.
After applying patches, tearing issue is back.

Here are some new findings:
The issue can be reproudced on 5916&5917.
But, I only see the issue on 5916 when running glxgears with fullscreen.
When unplugging power adapter and running glxgear with default window size, the
issue on 5917 is gone.

Test Environment:
Device 1 (5916):
a. Graphics Cards: Intel [8086:5916] + AMD [1002:6900]
b. Kernel: 4.4.0-45
Device 2 (5917):
a. Graphics Cards: Intel [8086:5917] + AMD [1002:6900]
b. Kernel: 4.4.0-73

Test Result:
1. AC Mode: (Power Adapter)
Device 1 (5916):
$ DRI_PRIME=1 glxgear: PASS
$ DRI_PRIME=1 glxgear -fullscreen: tearing
Device 2 (5917):
$ DRI_PRIME=1 glxgear: tearing
$ DRI_PRIME=1 glxgear -fullscreen: tearing

2. DC Mode: (Battery)
Device 1 (5916):
$ DRI_PRIME=1 glxgear: PASS
$ DRI_PRIME=1 glxgear -fullscreen: tearing
Device 2 (5917):
$ DRI_PRIME=1 glxgear: PASS
$ DRI_PRIME=1 glxgear -fullscreen: tearing

-- 
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 101832] [regression][bisect] sddm fails to start after f50aa21456d82c8cb6fbaa565835f1acc1720a5d

[bugzilla-daemon]

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

Bernhard Rosenkraenzer  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Drivers/Gallium/swr
 CC||b...@lindev.ch

--- Comment #8 from Bernhard Rosenkraenzer  ---
This is unrelated to the radeonsi driver -- the exact same commit causes a
similar crash here on a laptop with an Intel and Nouveau GPU.

(EE) Backtrace:
(EE) 0: /usr/libexec/Xorg (xorg_backtrace+0x33) [0x56095d]
(EE) 1: /usr/libexec/Xorg (0x40+0x164414) [0x564414]
(EE) 2: /lib64/libpthread.so.0 (0x3547e0+0xfb70) [0x3547e0fb70]
(EE) 3: /lib64/libc.so.6 (0x3547a0+0x113131) [0x3547b13131]
(EE) 4: /usr/lib64/dri/nouveau_dri.so (0x7f8127608000+0xa74c4e)
[0x7f812807cc4e]
(EE) 5: /usr/lib64/dri/nouveau_dri.so (0x7f8127608000+0xa752e1)
[0x7f812807d2e1]
(EE) 6: /usr/lib64/dri/nouveau_dri.so (0x7f8127608000+0x77ff0) [0x7f812767fff0]
(EE) 7: /lib64/ld-linux-x86-64.so.2 (0x354760+0xc0c9) [0x354760c0c9]
(EE) 8: /lib64/ld-linux-x86-64.so.2 (0x354760+0xc1d0) [0x354760c1d0]
(EE) 9: /lib64/ld-linux-x86-64.so.2 (0x354760+0xf6dc) [0x354760f6dc]
(EE) 10: /lib64/libc.so.6 (_dl_catch_error+0x72) [0x3547aee17b]
(EE) 11: /lib64/ld-linux-x86-64.so.2 (0x354760+0xedc1) [0x354760edc1]
(EE) 12: /lib64/libdl.so.2 (0x354820+0x1006) [0x3548201006]
(EE) 13: /lib64/libc.so.6 (_dl_catch_error+0x72) [0x3547aee17b]
(EE) 14: /lib64/libdl.so.2 (0x354820+0x1505) [0x3548201505]
(EE) 15: /lib64/libdl.so.2 (dlopen+0x35) [0x3548201043]
(EE) 16: /usr/lib64/libgbm.so.1 (0x7f81285af000+0x4ab4) [0x7f81285b3ab4]
(EE) 17: /usr/lib64/libgbm.so.1 (0x7f81285af000+0x4bf4) [0x7f81285b3bf4]
(EE) 18: /usr/lib64/libgbm.so.1 (0x7f81285af000+0x52a8) [0x7f81285b42a8]
(EE) 19: /usr/lib64/libgbm.so.1 (0x7f81285af000+0x2e1b) [0x7f81285b1e1b]
(EE) 20: /usr/lib64/libgbm.so.1 (gbm_create_device+0x39) [0x7f81285b1e89]
(EE) 21: /usr/lib64/xorg/modules/libglamoregl.so (glamor_egl_init+0x80)
[0x7f8128630ca0]
(EE) 22: /usr/lib64/xorg/modules/drivers/modesetting_drv.so
(0x7f812a2ca000+0x7d72) [0x7f812a2d1d72]
(EE) 23: /usr/libexec/Xorg (InitOutput+0x1660) [0x46be93]
(EE) 24: /usr/libexec/Xorg (0x40+0x20de1) [0x420de1]
(EE) 25: /lib64/libc.so.6 (__libc_start_main+0x15a) [0x3547a21de3]
(EE) 26: /usr/libexec/Xorg (_start+0x2a) [0x420aba]
(EE)
(EE) Segmentation fault at address 0x0

-- 
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 102247] Mesa failing to compile

[bugzilla-daemon]

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

Bug ID: 102247
   Summary: Mesa failing to compile
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ranki...@googlemail.com
QA Contact: dri-devel@lists.freedesktop.org

Building on Fedora 26, and configuring Mesa as:

CFLAGS='-O2 -g -gdwarf-2' ./autogen.sh --prefix=/home/chris/Programs/local-mesa
--libdir=/home/chris/Programs/local-mesa/lib64
--with-vdpau-libdir=/home/chris/Programs/local-mesa/lib64/vdpau
--with-gallium-drivers=radeonsi,swrast --with-egl-platforms=drm,x11
--with-llvm-prefix=/home/chris/Programs/local-llvm --enable-llvm-shared-libs
--with-dri-drivers= --enable-texture-float --enable-64-bit --enable-nine
--enable-omx

However, the build fails with:

  CXXLDgallium_dri.la
/home/chris/Programs/local-llvm/lib/libLLVMSupport.a(Process.cpp.o): In
function `llvm::sys::Process::FileDescriptorHasColors(int)':
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x67):
undefined reference to `setupterm'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x90):
undefined reference to `tigetnum'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x99):
undefined reference to `set_curterm'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0xa1):
undefined reference to `del_curterm'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:964: gallium_dri.la] Error 1
make[4]: Leaving directory '/home/chris/Programs/mesa/src/gallium/targets/dri'
make[3]: *** [Makefile:601: all-recursive] Error 1
make[3]: Leaving directory '/home/chris/Programs/mesa/src/gallium'
make[2]: *** [Makefile:853: all-recursive] Error 1
make[2]: Leaving directory '/home/chris/Programs/mesa/src'
make[1]: *** [Makefile:644: all] Error 2
make[1]: Leaving directory '/home/chris/Programs/mesa/src'
make: *** [Makefile:649: all-recursive] Error 1

I've tried updating my local LLVM installation twice, to no avail.

The missing symbols seem to be from libncurses.

-- 
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 102244] [powerplay] Can't overclock GPU memory

[bugzilla-daemon]

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

--- Comment #2 from clau...@thinkeasy.cz ---
Created attachment 133540
  --> https://bugs.freedesktop.org/attachment.cgi?id=133540=edit
`lspci -vvv` output.

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

[Bug 102244] [powerplay] Can't overclock GPU memory

[bugzilla-daemon]

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

--- Comment #1 from clau...@thinkeasy.cz ---
Created attachment 133539
  --> https://bugs.freedesktop.org/attachment.cgi?id=133539=edit
`lspci` output

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

[Bug 102244] [powerplay] Can't overclock GPU memory

[bugzilla-daemon]

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

Bug ID: 102244
   Summary: [powerplay] Can't overclock GPU memory
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: clau...@thinkeasy.cz

Created attachment 133538
  --> https://bugs.freedesktop.org/attachment.cgi?id=133538=edit
Complete `dmesg` output.

OS: Ubuntu Server 17.04, Linux 4.10.0
GPU: ASUS ROG Strix Radeon RX 570 4G Gaming

Performing a memory overclock using the following command:

echo 1 > /sys/class/drm/card1/device/pp_mclk_od

fails with the following output in dmesg:

VDDCI is larger than max VDDCI in VDDCI Voltage Table!

 failed to send message 18a ret is 255

 failed to send pre message 145 ret is 255

This issue seems to be related (but I'm not entirely sure) to this issue:
https://bugs.freedesktop.org/show_bug.cgi?id=100443

Complete `dmesg` output is attached.

-- 
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

[PATCHv2] drm: omapdrm: Register omapdrm platform device in omapdss driver

[Tomi Valkeinen]

From: Laurent Pinchart 

The omapdrm platform device is a virtual device created for the sole
purpose of handling the omapdss/omapdrm driver split. It should
eventually be removed. As a first step to ease refactoring move its
registration from platform code to driver code.

The omapdrm driver name must be changed internally to avoid probing both
the device registered in platform code and the device registered in the
omapdss driver, as that would otherwise break bisection.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen 
Signed-off-by: Tomi Valkeinen 
---

I reworked this patch to create the platform device dynamically.

 drivers/gpu/drm/omapdrm/dss/core.c | 10 ++
 drivers/gpu/drm/omapdrm/omap_drv.c |  8 +++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index 4dabe32c7098..6b3247c4f857 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -103,6 +103,8 @@ static void (*dss_output_drv_unreg_funcs[])(void) = {
dss_uninit_platform_driver,
 };
 
+static struct platform_device *omap_drm_device;
+
 static int __init omap_dss_init(void)
 {
int r;
@@ -118,6 +120,12 @@ static int __init omap_dss_init(void)
goto err_reg;
}
 
+   omap_drm_device = platform_device_register_simple("omapdrm_", 0, NULL, 
0);
+   if (IS_ERR(omap_drm_device)) {
+   r = PTR_ERR(omap_drm_device);
+   goto err_reg;
+   }
+
return 0;
 
 err_reg:
@@ -135,6 +143,8 @@ static void __exit omap_dss_exit(void)
 {
int i;
 
+   platform_device_unregister(omap_drm_device);
+
for (i = 0; i < ARRAY_SIZE(dss_output_drv_unreg_funcs); ++i)
dss_output_drv_unreg_funcs[i]();
 
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 10e24ca928f2..2b990daf0052 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -575,6 +575,12 @@ static int pdev_probe(struct platform_device *pdev)
if (omapdss_is_initialized() == false)
return -EPROBE_DEFER;
 
+   ret = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
+   if (ret) {
+   dev_err(>dev, "Failed to set the DMA mask\n");
+   return ret;
+   }
+
omap_crtc_pre_init();
 
ret = omap_connect_dssdevs();
@@ -762,7 +768,7 @@ static SIMPLE_DEV_PM_OPS(omapdrm_pm_ops, omap_drm_suspend, 
omap_drm_resume);
 
 static struct platform_driver pdev = {
.driver = {
-   .name = DRIVER_NAME,
+   .name = "omapdrm_",
.pm = _pm_ops,
},
.probe = pdev_probe,
-- 
2.7.4


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


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

Re: [PATCH 1/1] drm/ttm: Fix accounting error when fail to get pages for pool

[Liu, Monk]

Reviewed-by: Monk Liu 


From: amd-gfx  on behalf of 
Xiangliang.Yu 
Sent: Wednesday, August 16, 2017 3:20:46 PM
To: a...@linux-foundation.org; labb...@redhat.com; 
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Yu, Xiangliang
Subject: [PATCH 1/1] drm/ttm: Fix accounting error when fail to get pages for 
pool

When fail to get needed page for pool, need to put allocated pages
into pool. But current code has a miscalculation of allocated pages,
correct it.

Signed-off-by: Xiangliang.Yu 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index eeddc1e..8715998 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -615,7 +615,7 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool 
*pool,
 } else {
 pr_err("Failed to fill pool (%p)\n", pool);
 /* If we have any pages left put them to the pool. */
-   list_for_each_entry(p, >list, lru) {
+   list_for_each_entry(p, _pages, lru) {
 ++cpages;
 }
 list_splice(_pages, >list);
--
2.7.4

___
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

Re: [PATCH 1/1] drm/ttm: Fix accounting error when fail to get pages for pool

[Christian König]

CC stable?

Reviewed-by: Christian König 

Am 16.08.2017 um 09:25 schrieb Liu, Monk:


Reviewed-by: Monk Liu 


*From:* amd-gfx  on behalf of 
Xiangliang.Yu 

*Sent:* Wednesday, August 16, 2017 3:20:46 PM
*To:* a...@linux-foundation.org; labb...@redhat.com; 
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org

*Cc:* Yu, Xiangliang
*Subject:* [PATCH 1/1] drm/ttm: Fix accounting error when fail to get 
pages for pool

When fail to get needed page for pool, need to put allocated pages
into pool. But current code has a miscalculation of allocated pages,
correct it.

Signed-off-by: Xiangliang.Yu 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c

index eeddc1e..8715998 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -615,7 +615,7 @@ static void ttm_page_pool_fill_locked(struct 
ttm_page_pool *pool,

 } else {
 pr_err("Failed to fill pool (%p)\n", pool);
 /* If we have any pages left put them to the 
pool. */

-   list_for_each_entry(p, >list, lru) {
+   list_for_each_entry(p, _pages, lru) {
 ++cpages;
 }
 list_splice(_pages, >list);
--
2.7.4

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


___
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

Re: [PATCH v2 18/19] drm/virtio: Use the drm_driver.dumb_destroy default

[Daniel Vetter]

On Sun, Aug 06, 2017 at 05:41:07PM +0200, Noralf Trønnes wrote:
> virtio_gpu_mode_dumb_destroy() is the same as drm_gem_dumb_destroy()
> which is the drm_driver.dumb_destroy default, so no need to set it.
> 
> Cc: David Airlie 
> Cc: Gerd Hoffmann 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.c | 1 -
>  drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ---
>  drivers/gpu/drm/virtio/virtgpu_gem.c | 7 ---
>  3 files changed, 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
> b/drivers/gpu/drm/virtio/virtgpu_drv.c
> index 63d35c7..49a3d8d 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -122,7 +122,6 @@ static struct drm_driver driver = {
>  
>   .dumb_create = virtio_gpu_mode_dumb_create,
>   .dumb_map_offset = virtio_gpu_mode_dumb_mmap,

Like cirrus (they're all copypasted from each another) the map_offset
one could be replaced by the generic one too.
-Daniel

> - .dumb_destroy = virtio_gpu_mode_dumb_destroy,
>  
>  #if defined(CONFIG_DEBUG_FS)
>   .debugfs_init = virtio_gpu_debugfs_init,
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 3a66abb..da2fb58 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -236,9 +236,6 @@ struct virtio_gpu_object *virtio_gpu_alloc_object(struct 
> drm_device *dev,
>  int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
>   struct drm_device *dev,
>   struct drm_mode_create_dumb *args);
> -int virtio_gpu_mode_dumb_destroy(struct drm_file *file_priv,
> -  struct drm_device *dev,
> -  uint32_t handle);
>  int virtio_gpu_mode_dumb_mmap(struct drm_file *file_priv,
> struct drm_device *dev,
> uint32_t handle, uint64_t *offset_p);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c 
> b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index cc025d8..72ad7b1 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -118,13 +118,6 @@ int virtio_gpu_mode_dumb_create(struct drm_file 
> *file_priv,
>   return ret;
>  }
>  
> -int virtio_gpu_mode_dumb_destroy(struct drm_file *file_priv,
> -  struct drm_device *dev,
> -  uint32_t handle)
> -{
> - return drm_gem_handle_delete(file_priv, handle);
> -}
> -
>  int virtio_gpu_mode_dumb_mmap(struct drm_file *file_priv,
> struct drm_device *dev,
> uint32_t handle, uint64_t *offset_p)
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 17/19] drm/armada: Use the drm_driver.dumb_destroy default

[Daniel Vetter]

On Sun, Aug 06, 2017 at 05:41:06PM +0200, Noralf Trønnes wrote:
> armada_gem_dumb_destroy() is the same as drm_gem_dumb_destroy()
> which is the drm_driver.dumb_destroy default, so no need to set it.
> 
> Cc: Russell King 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/armada/armada_drv.c | 1 -
>  drivers/gpu/drm/armada/armada_gem.c | 6 --
>  drivers/gpu/drm/armada/armada_gem.h | 2 --
>  3 files changed, 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 0b3227c..8a37b9a 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -71,7 +71,6 @@ static struct drm_driver armada_drm_driver = {
>   .gem_prime_import   = armada_gem_prime_import,
>   .dumb_create= armada_gem_dumb_create,
>   .dumb_map_offset= armada_gem_dumb_map_offset,

Looking at this I noticed how we reject the mapping of imported dma-bufs
in the dumb ioctl. I think that's a pretty good idea to do in generic code
(it is an invalid use-case). If we'd put that check into the core helpers,
we could also switch the armada dumb_map_offset to the generic one.
-Daniel

> - .dumb_destroy   = armada_gem_dumb_destroy,
>   .gem_vm_ops = _gem_vm_ops,
>   .major  = 1,
>   .minor  = 0,
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index a76ca21..9d69132 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -300,12 +300,6 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
> struct drm_device *dev,
>   return ret;
>  }
>  
> -int armada_gem_dumb_destroy(struct drm_file *file, struct drm_device *dev,
> - uint32_t handle)
> -{
> - return drm_gem_handle_delete(file, handle);
> -}
> -
>  /* Private driver gem ioctls */
>  int armada_gem_create_ioctl(struct drm_device *dev, void *data,
>   struct drm_file *file)
> diff --git a/drivers/gpu/drm/armada/armada_gem.h 
> b/drivers/gpu/drm/armada/armada_gem.h
> index 6e524e0..78d5690 100644
> --- a/drivers/gpu/drm/armada/armada_gem.h
> +++ b/drivers/gpu/drm/armada/armada_gem.h
> @@ -37,8 +37,6 @@ int armada_gem_dumb_create(struct drm_file *, struct 
> drm_device *,
>   struct drm_mode_create_dumb *);
>  int armada_gem_dumb_map_offset(struct drm_file *, struct drm_device *,
>   uint32_t, uint64_t *);
> -int armada_gem_dumb_destroy(struct drm_file *, struct drm_device *,
> - uint32_t);
>  struct dma_buf *armada_gem_prime_export(struct drm_device *dev,
>   struct drm_gem_object *obj, int flags);
>  struct drm_gem_object *armada_gem_prime_import(struct drm_device *,
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 14/19] drm/mgag200: Use the drm_driver.dumb_destroy default

[Daniel Vetter]

On Sun, Aug 06, 2017 at 05:41:03PM +0200, Noralf Trønnes wrote:
> drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
> so no need to set it.
> 
> Cc: Dave Airlie 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/mgag200/mgag200_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
> b/drivers/gpu/drm/mgag200/mgag200_drv.c
> index 4189160..74cdde2 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> @@ -102,7 +102,6 @@ static struct drm_driver driver = {
>   .gem_free_object_unlocked = mgag200_gem_free_object,
>   .dumb_create = mgag200_dumb_create,
>   .dumb_map_offset = mgag200_dumb_mmap_offset,

Like with cirrus and qxl and ast, this could be removed too.
-Daniel

> - .dumb_destroy = drm_gem_dumb_destroy,
>  };
>  
>  static struct pci_driver mgag200_pci_driver = {
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 07/19] drm/cirrus: Use the drm_driver.dumb_destroy default

[Daniel Vetter]

On Sun, Aug 06, 2017 at 05:40:56PM +0200, Noralf Trønnes wrote:
> drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
> so no need to set it.
> 
> Cc: Dave Airlie 
> Cc: Gerd Hoffmann 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/cirrus/cirrus_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
> b/drivers/gpu/drm/cirrus/cirrus_drv.c
> index 910c300..69c4e35 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
> @@ -142,7 +142,6 @@ static struct drm_driver driver = {
>   .gem_free_object_unlocked = cirrus_gem_free_object,
>   .dumb_create = cirrus_dumb_create,
>   .dumb_map_offset = cirrus_dumb_mmap_offset,

I think the cirrus mmap_offset could be replaced too, it's just written
slightly differently from what I can tell with the separate helper
function.
-Daniel

> - .dumb_destroy = drm_gem_dumb_destroy,
>  };
>  
>  static const struct dev_pm_ops cirrus_pm_ops = {
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch net-next 0/3] net/sched: Improve getting objects by indexes

[Chris Mi]

Using current TC code, it is very slow to insert a lot of rules.

In order to improve the rules update rate in TC,
we introduced the following two changes:
1) changed cls_flower to use IDR to manage the filters.
2) changed all act_xxx modules to use IDR instead of
   a small hash table

But IDR has a limitation that it uses int. TC handle uses u32.
To make sure there is no regression, we also changed IDR to use
unsigned long. All clients of IDR are changed to use new IDR API.

Chris Mi (3):
  idr: Use unsigned long instead of int
  net/sched: Change cls_flower to use IDR
  net/sched: Change act_api and act_xxx modules to use IDR

 block/bsg.c |   8 +-
 block/genhd.c   |  12 +-
 drivers/atm/nicstar.c   |  11 +-
 drivers/block/drbd/drbd_main.c  |  31 +--
 drivers/block/drbd/drbd_nl.c|  22 ++-
 drivers/block/drbd/drbd_proc.c  |   3 +-
 drivers/block/drbd/drbd_receiver.c  |  15 +-
 drivers/block/drbd/drbd_state.c |  34 ++--
 drivers/block/drbd/drbd_worker.c|   6 +-
 drivers/block/loop.c|  17 +-
 drivers/block/nbd.c |  20 +-
 drivers/block/zram/zram_drv.c   |   9 +-
 drivers/char/tpm/tpm-chip.c |  10 +-
 drivers/char/tpm/tpm.h  |   2 +-
 drivers/dca/dca-sysfs.c |   9 +-
 drivers/firewire/core-cdev.c|  18 +-
 drivers/firewire/core-device.c  |  15 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |   9 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |   2 +-
 drivers/gpu/drm/drm_auth.c  |   9 +-
 drivers/gpu/drm/drm_connector.c |  10 +-
 drivers/gpu/drm/drm_context.c   |  20 +-
 drivers/gpu/drm/drm_dp_aux_dev.c|  11 +-
 drivers/gpu/drm/drm_drv.c   |   6 +-
 drivers/gpu/drm/drm_gem.c   |  19 +-
 drivers/gpu/drm/drm_info.c  |   2 +-
 drivers/gpu/drm/drm_mode_object.c   |  11 +-
 drivers/gpu/drm/drm_syncobj.c   |  18 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |  25 ++-
 drivers/gpu/drm/i915/gvt/display.c  |   2 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c|   2 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |   9 +-
 drivers/gpu/drm/i915/i915_debugfs.c |   6 +-
 drivers/gpu/drm/i915/i915_gem_context.c |   9 +-
 drivers/gpu/drm/qxl/qxl_cmd.c   |   8 +-
 drivers/gpu/drm/qxl/qxl_release.c   |  14 +-
 drivers/gpu/drm/sis/sis_mm.c|   8 +-
 drivers/gpu/drm/tegra/drm.c |  10 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c|   3 +-
 drivers/gpu/drm/vgem/vgem_fence.c   |  12 +-
 drivers/gpu/drm/via/via_mm.c|   8 +-
 drivers/gpu/drm/virtio/virtgpu_kms.c|   5 +-
 drivers/gpu/drm/virtio/virtgpu_vq.c |   5 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c|   9 +-
 drivers/i2c/i2c-core-base.c |  19 +-
 drivers/infiniband/core/cm.c|   8 +-
 drivers/infiniband/core/cma.c   |  12 +-
 drivers/infiniband/core/rdma_core.c |   9 +-
 drivers/infiniband/core/sa_query.c  |  23 +--
 drivers/infiniband/core/ucm.c   |   7 +-
 drivers/infiniband/core/ucma.c  |  14 +-
 drivers/infiniband/hw/cxgb3/iwch.c  |   4 +-
 drivers/infiniband/hw/cxgb3/iwch.h  |   4 +-
 drivers/infiniband/hw/cxgb4/device.c|  18 +-
 drivers/infiniband/hw/cxgb4/iw_cxgb4.h  |   4 +-
 drivers/infiniband/hw/hfi1/init.c   |   9 +-
 drivers/infiniband/hw/hfi1/vnic_main.c  |   6 +-
 drivers/infiniband/hw/mlx4/cm.c |  13 +-
 drivers/infiniband/hw/ocrdma/ocrdma_main.c  |   7 +-
 drivers/infiniband/hw/qib/qib_init.c|   9 +-
 drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c |  10 +-
 drivers/iommu/intel-svm.c   |   9 +-
 drivers/md/dm.c |  13 +-
 drivers/memstick/core/memstick.c|  10 +-
 drivers/memstick/core/ms_block.c|   9 +-
 drivers/memstick/core/mspro_block.c |  12 +-
 drivers/mfd/rtsx_pcr.c  |   9 +-
 drivers/misc/c2port/core.c  |   7 +-
 drivers/misc/cxl/context.c  |   8 +-
 drivers/misc/cxl/main.c |  15 +-
 drivers/misc/mei/main.c |   8 +-
 drivers/misc/mic/scif/scif_api.c|  11 +-
 drivers/misc/mic/scif/scif_ports.c

[patch net-next 2/3] net/sched: Change cls_flower to use IDR

[Chris Mi]

Currently, all filters with the same priority are linked in a doubly
linked list. Every filter should have a unique handle. To make the
handle unique, we need to iterate the list every time to see if the
handle exists or not when inserting a new filter. It is time-consuming.
For example, it takes about 5m3.169s to insert 64K rules.

This patch changes cls_flower to use IDR. With this patch, it
takes about 0m1.127s to insert 64K rules. The improvement is huge.

But please note that in this testing, all filters share the same action.
If every filter has a unique action, that is another bottleneck.
Follow-up patch in this patchset addresses that.

Signed-off-by: Chris Mi 
Signed-off-by: Jiri Pirko 
---
 net/sched/cls_flower.c | 55 +-
 1 file changed, 23 insertions(+), 32 deletions(-)

diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 052e902..071f0ef 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -68,7 +68,6 @@ struct cls_fl_head {
struct rhashtable ht;
struct fl_flow_mask mask;
struct flow_dissector dissector;
-   u32 hgen;
bool mask_assigned;
struct list_head filters;
struct rhashtable_params ht_params;
@@ -76,6 +75,7 @@ struct cls_fl_head {
struct work_struct work;
struct rcu_head rcu;
};
+   struct idr handle_idr;
 };
 
 struct cls_fl_filter {
@@ -210,6 +210,7 @@ static int fl_init(struct tcf_proto *tp)
 
INIT_LIST_HEAD_RCU(>filters);
rcu_assign_pointer(tp->root, head);
+   idr_init(>handle_idr);
 
return 0;
 }
@@ -295,6 +296,9 @@ static void fl_hw_update_stats(struct tcf_proto *tp, struct 
cls_fl_filter *f)
 
 static void __fl_delete(struct tcf_proto *tp, struct cls_fl_filter *f)
 {
+   struct cls_fl_head *head = rtnl_dereference(tp->root);
+
+   idr_remove(>handle_idr, f->handle);
list_del_rcu(>list);
if (!tc_skip_hw(f->flags))
fl_hw_destroy_filter(tp, f);
@@ -327,6 +331,7 @@ static void fl_destroy(struct tcf_proto *tp)
 
list_for_each_entry_safe(f, next, >filters, list)
__fl_delete(tp, f);
+   idr_destroy(>handle_idr);
 
__module_get(THIS_MODULE);
call_rcu(>rcu, fl_destroy_rcu);
@@ -335,12 +340,8 @@ static void fl_destroy(struct tcf_proto *tp)
 static void *fl_get(struct tcf_proto *tp, u32 handle)
 {
struct cls_fl_head *head = rtnl_dereference(tp->root);
-   struct cls_fl_filter *f;
 
-   list_for_each_entry(f, >filters, list)
-   if (f->handle == handle)
-   return f;
-   return NULL;
+   return idr_find(>handle_idr, handle);
 }
 
 static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
@@ -859,27 +860,6 @@ static int fl_set_parms(struct net *net, struct tcf_proto 
*tp,
return 0;
 }
 
-static u32 fl_grab_new_handle(struct tcf_proto *tp,
- struct cls_fl_head *head)
-{
-   unsigned int i = 0x8000;
-   u32 handle;
-
-   do {
-   if (++head->hgen == 0x7FFF)
-   head->hgen = 1;
-   } while (--i > 0 && fl_get(tp, head->hgen));
-
-   if (unlikely(i == 0)) {
-   pr_err("Insufficient number of handles\n");
-   handle = 0;
-   } else {
-   handle = head->hgen;
-   }
-
-   return handle;
-}
-
 static int fl_change(struct net *net, struct sk_buff *in_skb,
 struct tcf_proto *tp, unsigned long base,
 u32 handle, struct nlattr **tca,
@@ -890,6 +870,7 @@ static int fl_change(struct net *net, struct sk_buff 
*in_skb,
struct cls_fl_filter *fnew;
struct nlattr **tb;
struct fl_flow_mask mask = {};
+   unsigned long idr_index;
int err;
 
if (!tca[TCA_OPTIONS])
@@ -920,13 +901,21 @@ static int fl_change(struct net *net, struct sk_buff 
*in_skb,
goto errout;
 
if (!handle) {
-   handle = fl_grab_new_handle(tp, head);
-   if (!handle) {
-   err = -EINVAL;
+   err = idr_alloc(>handle_idr, fnew, _index,
+   1, 0x8000, GFP_KERNEL);
+   if (err)
goto errout;
-   }
+   fnew->handle = idr_index;
+   }
+
+   /* user specifies a handle and it doesn't exist */
+   if (handle && !fold) {
+   err = idr_alloc(>handle_idr, fnew, _index,
+   handle, handle + 1, GFP_KERNEL);
+   if (err)
+   goto errout;
+   fnew->handle = idr_index;
}
-   fnew->handle = handle;
 
if (tb[TCA_FLOWER_FLAGS]) {
fnew->flags = nla_get_u32(tb[TCA_FLOWER_FLAGS]);
@@ -980,6 +969,8 @@ static int fl_change(struct net *net, struct sk_buff 
*in_skb,
 

[Bug 196635] amdgpu clinfo hangs with SI

[bugzilla-daemon]

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

--- Comment #10 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Janpieter Sollie from comment #9)
> It won't be easy to point to the problem: in 4.10, it hit a triple fault and
> then crashed with dpm enabled. do you want a bisection from that one(see
> 194899) to the current status or do I need to do something else?

Hmm, I guess I misread the bug description as meaning it worked properly
before. If that's not the case, there's probably no point in bisecting.

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