Re: [PATCH 0/6] drm: msm: A5XX zap shader

[Archit Taneja]

On 04/13/2017 02:45 AM, Jordan Crouse wrote:

Hey Rob -

Here is the stack of stuff to add the zap shader for msm-next. I left
the code broken out as the first two changes are merged into the device
specific tree and the third one has been seen before so this should
hopefully cut down on confusion.

The following patches are basically the changes that Bjorn requested and a bit
more clean up to rely on the device tree less as is our current plan of action.

I am not at all oppposed to squashing these into one big change or two moderate
changes if it makes life easier.


For the series:

Tested-by: Archit Taneja 

Thanks,
Archit



Jordan Crouse (6):
  drm/msm: Add a quick and dirty PIL loader
  drm/msm: gpu: Use the zap shader on 5XX if we can
  drm/msm: Improve the zap shader
  drm/msm: Create a child device for the zap shader
  drm/msm: Move zap shader firmware name to the device table
  drm/msm: Document the zap-shader subnode for the GPU

 .../devicetree/bindings/display/msm/gpu.txt|  13 ++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c  | 249 -
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h  |   2 +
 drivers/gpu/drm/msm/adreno/adreno_device.c |   1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|   1 +
 5 files changed, 264 insertions(+), 2 deletions(-)



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

[Bug 100681] F1 2015 glitches (letters mainly)

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer  ---
Might be fixed with LLVM r300791.

-- 
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 195465] AMD Hybrid graphic dont work, R7 M260/M265 (Topaz)

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer (mic...@daenzer.net) ---
What exactly is the problem? The only suspicious thing in dmesg is the below,
which indicates that the GPU's power management might not be working perfectly:

[   20.346154] cant't get the mac of 5 
[   20.348337] [ powerplay ] VBIOS did not find boot engine clock value
in dependency table. Using Memory DPM level 0!

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

[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer  ---
It's unlikely that this is caused by the bisected commit. You'll need to test
longer before declaring a commit as good.

-- 
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 3/3] drm/panel: add backlight dependency for sitronix-st7789v

[Hoegeun Kwon]

On 04/20/2017 03:03 AM, Arnd Bergmann wrote:

Without the dependency, we run into a link error:

drivers/gpu/drm/panel/panel-sitronix-st7789v.o: In function `st7789v_probe':
panel-sitronix-st7789v.c:(.text.st7789v_probe+0xc0): undefined reference to 
`of_find_backlight_by_node'

Fixes: 7142afb3a186 ("drm/panel: Add driver for sitronix ST7789V LCD 
controller")
Signed-off-by: Arnd Bergmann 


Reviewed-by: Hoegeun Kwon 

Best regards,
Hoegeun


---
  drivers/gpu/drm/panel/Kconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6eb9774284df..04d068177e16 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -101,6 +101,7 @@ config DRM_PANEL_SHARP_LS043T1LE01
  config DRM_PANEL_SITRONIX_ST7789V
tristate "Sitronix ST7789V panel"
depends on OF && SPI
+   depends on BACKLIGHT_CLASS_DEVICE
help
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels


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

Re: [PATCH 2/3] drm/panel: S6E3HA2 needs backlight code

[Hoegeun Kwon]

Hi Arnd,

Thanks for your patch.

On 04/20/2017 02:59 AM, Arnd Bergmann wrote:

The new S6E3HA2 driver fails to link when backlight is disabled:

ERROR: "backlight_device_register" 
[drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined!
ERROR: "backlight_device_unregister" 
[drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined!

This adds a Kconfig dependency like we have it for some other panel drivers.

Fixes: ed29f9426d9b ("drm/panel: Add support for S6E3HA2 panel driver on TM2 
board")
Signed-off-by: Arnd Bergmann 


Reviewed-by: Hoegeun Kwon 

Best regards,
Hoegeun

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

[PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Logan Gunthorpe]

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.html

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sinclair Yeh 
---

Changes since v1:

- Added the missing tegra driver (noticed by kbuild robot)
- Rebased off of drm-intel-next to get the i915 selftest that is new
- Fixed nits Sinclair pointed out.

 drivers/dma-buf/dma-buf.c  | 16 
 drivers/gpu/drm/armada/armada_gem.c|  8 
 drivers/gpu/drm/drm_prime.c|  8 
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
 drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
 drivers/gpu/drm/tegra/gem.c|  8 
 drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
 drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
 drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
 drivers/staging/android/ion/ion.c  |  8 
 include/linux/dma-buf.h| 22 +++---
 14 files changed, 61 insertions(+), 61 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f72aaac..512bdbc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
  || !exp_info->ops->map_dma_buf
  || !exp_info->ops->unmap_dma_buf
  || !exp_info->ops->release
- || !exp_info->ops->kmap_atomic
- || !exp_info->ops->kmap
+ || !exp_info->ops->map_atomic
+ || !exp_info->ops->map
  || !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
@@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned 
long page_num)
 {
WARN_ON(!dmabuf);

-   return dmabuf->ops->kmap_atomic(dmabuf, page_num);
+   return dmabuf->ops->map_atomic(dmabuf, page_num);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);

@@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned 
long page_num,
 {
WARN_ON(!dmabuf);

-   if (dmabuf->ops->kunmap_atomic)
-   dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
+   if (dmabuf->ops->unmap_atomic)
+   dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);

@@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
page_num)
 {
WARN_ON(!dmabuf);

-   return dmabuf->ops->kmap(dmabuf, page_num);
+   return dmabuf->ops->map(dmabuf, page_num);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kmap);

@@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
page_num,
 {
WARN_ON(!dmabuf);

-   if (dmabuf->ops->kunmap)
-   dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
+   if (dmabuf->ops->unmap)
+   dmabuf->ops->unmap(dmabuf, page_num, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kunmap);

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 1597458..d6c2a5d 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -529,10 +529,10 @@ static const struct dma_buf_ops 
armada_gem_prime_dmabuf_ops = {
.map_dma_buf= armada_gem_prime_map_dma_buf,
.unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
.release= drm_gem_dmabuf_release,
-   .kmap_atomic= armada_gem_dmabuf_no_kmap,
-   .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
-   .kmap   = armada_gem_dmabuf_no_kmap,
-   .kunmap = armada_gem_dmabuf_no_kunmap,
+   .map_atomic = armada_gem_dmabuf_no_kmap,
+   .unmap_atomic   = armada_gem_dmabuf_no_kunmap,
+   .map= armada_gem_dmabuf_no_kmap,
+   .unmap  = armada_gem_dmabuf_no_kunmap,
.mmap   = armada_gem_dmabuf_mmap,
 };

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9fb65b7..954eb84 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -403,10 +403,10 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
=  {
.map_dma_buf = 

Re: [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Laura Abbott]

On 04/19/2017 12:36 PM, Logan Gunthorpe wrote:

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.html

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sinclair Yeh 
---

Changes since v1:

- Added the missing tegra driver (noticed by kbuild robot)
- Rebased off of drm-intel-next to get the i915 selftest that is new
- Fixed nits Sinclair pointed out.

  drivers/dma-buf/dma-buf.c  | 16 
  drivers/gpu/drm/armada/armada_gem.c|  8 
  drivers/gpu/drm/drm_prime.c|  8 
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
  drivers/gpu/drm/tegra/gem.c|  8 
  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
  drivers/staging/android/ion/ion.c  |  8 
  include/linux/dma-buf.h| 22 +++---
  14 files changed, 61 insertions(+), 61 deletions(-)



For Ion,

Acked-by: Laura Abbott 

I did some major Ion refactoring but I don't think this
will conflict.

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

[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #26 from Zachary Michaels  ---
Also note that forcing VGT_STREAMOUT_SYNC, VGT_STREAMOUT_RESET, or VGT_FLUSH to
be emitted on each call to si_draw_vbo (via si_emit_cache_flush) also appears
to work around the issue, though this has not been as thoroughly tested.

-- 
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 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #25 from Zachary Michaels  ---
These settings reproduce consistently on my W600 test machine:
./thrash -w 1920 -h 1080 -c 3 -t 1000 -m 10

-- 
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 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #24 from Zachary Michaels  ---
Hi! There is a stress test here that we have been using to reproduce this
issue: https://github.com/Oblong/thrasher

Enabling debug tracing works around the issue. Specifically, when si_draw_vbo
calls si_trace_emit, the problem goes away.

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

Re: [PATCH 2/2] drm/panel: simple: add support for NLT NL192108AC18-02D

[Rob Herring]

On Wed, Apr 12, 2017 at 07:15:26PM +0200, Lucas Stach wrote:
> This adds support for the NLT Technologies NL192108AC18-02D
> 15.6" LVDS FullHD TFT LCD panel, which can be supported
> by the simple panel driver.
> 
> Timings are taken from the preliminary datasheet, as a final
> one is not yet available.
> 
> Signed-off-by: Lucas Stach 
> ---
>  .../display/panel/nlt,nl192108ac18-02d.txt |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 29 
> ++
>  2 files changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt 
> b/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
> new file mode 100644
> index ..edc34fbd2131
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
> @@ -0,0 +1,7 @@
> +NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "nlt,nl192108ac18-02d"

Please define the power supply. Is power-supply used or are there 
multiple supplies?

> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] dt-bindings: add vendor prefix for NLT Technologies, Ltd.

[Rob Herring]

On Wed, Apr 12, 2017 at 07:15:25PM +0200, Lucas Stach wrote:
> NLT technologies is the former NEC display business, but changed its
> name to NLT Technologies when forming a joint venture with
> Shenzhen AVIC OPTOELECTRONICS, Ltd.
> 
> Signed-off-by: Lucas Stach 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [PATCH] [media] sti: hdmi: improve MEDIA_CEC_NOTIFIER dependency

[Hans Verkuil]

Hi Arnd,

On 19/04/17 18:59, Arnd Bergmann wrote:
> When the media subsystem is built as a loadable module, a built-in
> DRM driver cannot use the cec notifiers:
> 
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_remove':
> sti_hdmi.c:(.text.sti_hdmi_remove+0x28): undefined reference to 
> `cec_notifier_set_phys_addr'
> sti_hdmi.c:(.text.sti_hdmi_remove+0x50): undefined reference to 
> `cec_notifier_put'
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_connector_get_modes':
> sti_hdmi.c:(.text.sti_hdmi_connector_get_modes+0x84): undefined reference to 
> `cec_notifier_set_phys_addr_from_edid'
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_probe':
> sti_hdmi.c:(.text.sti_hdmi_probe+0x1a8): undefined reference to 
> `cec_notifier_get'
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_connector_detect':
> sti_hdmi.c:(.text.sti_hdmi_connector_detect+0x68): undefined reference to 
> `cec_notifier_set_phys_addr'
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_disable':
> sti_hdmi.c:(.text.sti_hdmi_disable+0xec): undefined reference to 
> `cec_notifier_set_phys_addr'
> 
> This adds a Kconfig dependency to enforce the HDMI driver to also
> be a loadable module in this case.

I've marked this patch and the exynos_hdmi patch as 'Obsoleted' in patchwork:
today several CEC Kconfig cleanup patches were merged that invalidate these
two patches. I expect they'll turn up soon in -next.

Regards,

Hans

> 
> Fixes: bca55958ea87 ("[media] sti: hdmi: add CEC notifier support")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/sti/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> index acd72865feac..adac4c3e142e 100644
> --- a/drivers/gpu/drm/sti/Kconfig
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -1,6 +1,7 @@
>  config DRM_STI
>   tristate "DRM Support for STMicroelectronics SoC stiH4xx Series"
>   depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
> + depends on (MEDIA_SUPPORT && MEDIA_CEC_NOTIFIER) || !MEDIA_CEC_NOTIFIER
>   select RESET_CONTROLLER
>   select DRM_KMS_HELPER
>   select DRM_GEM_CMA_HELPER
> 

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

Re: [PATCH v2] kernel: drm/vmwgfx: limit the number of mip levels in vmw_gb_surface_define_ioctl()

[Sinclair Yeh]

Thanks Vladis!

Reviewed-by: Sinclair Yeh 

On Thu, Apr 06, 2017 at 02:33:40PM +0200, Vladis Dronov wrote:
> The 'req->mip_levels' parameter in vmw_gb_surface_define_ioctl() is
> a user-controlled 'uint32_t' value which is used as a loop count limit.
> This can lead to a kernel lockup and DoS. Add check for 'req->mip_levels'.
> 
> References:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1437431=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=D9ZabTkAbhTqB-puuJ1a4SnWKUIGw0oXestkhJG6dCQ=6PZxBQ8MQjy-uc5pd6vyZg3D5yrG0jlSPi5pPE0oFK4=
>  
> Signed-off-by: Vladis Dronov 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index b445ce9..e0d7ff9 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -1281,6 +1281,9 @@ int vmw_gb_surface_define_ioctl(struct drm_device *dev, 
> void *data,
>   if (req->multisample_count != 0)
>   return -EINVAL;
>  
> + if (req->mip_levels > DRM_VMW_MAX_MIP_LEVELS)
> + return -EINVAL;
> +
>   if (unlikely(vmw_user_surface_size == 0))
>   vmw_user_surface_size = ttm_round_pot(sizeof(*user_srf)) +
>   128;
> -- 
> 2.9.3
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/omap: displays: panel-dpi: add backlight dependency

[Arnd Bergmann]

On Wed, Apr 19, 2017 at 10:21 PM, Laurent Pinchart
 wrote:
>>
>> This adds a dependency like we have for the other panel drivers.
>
> I believe the dependency should be made optional. DPI panels that don't need
> backlight control should be supported by a kernel that has backlight support
> compiled out.

That would be nice in principle, but I fear this would cause additional
problems.

> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -162,7 +162,7 @@ struct generic_bl_info {
> void (*kick_battery)(void);
>  };
>
> -#ifdef CONFIG_OF
> +#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
>  struct backlight_device *of_find_backlight_by_node(struct device_node *node);
>  #else
>  static inline struct backlight_device *
>
>
> We might need to create stubs for backlight_force_update() and
> backlight_device_set_brightness() too.
>

With BACKLIGHT_CLASS_DEVICE=m, you still get a link error when the user is
in a built-in driver. Using 'depends on' usually solves this (except for drivers
that cannot be modules).

There are three possible workarounds for this that I can think of:

- Use 'depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n'
  in each driver that implements optional backlight support. We do
this elsewhere, but
  it's confusing and easy to get wrong.

- use IS_REACHABLE() instead of IS_ENABLED() when testing for
  backlight support. This will always result in a kernel that builds cleanly,
  but can be surprising for users when backlight support is a module that
  gets loaded at boot, but it is still not used.

- Make BACKLIGHT_CLASS_DEVICE a 'bool' symbol instead, and force the
  core API code to always be built-in or completely disabled. This makes
  it really easy to use, at the expense of a larger kernel image for those that
  currently use a loadable module.

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

Re: [PATCH 1/3] drm/omap: displays: panel-dpi: add backlight dependency

[Laurent Pinchart]

Hi Arnd,

Thank you for the patch.

On Wednesday 19 Apr 2017 19:59:17 Arnd Bergmann wrote:
> The panel driver gained support for backlight but fails to link now
> when that is disabled:
> 
> drivers/gpu/drm/omapdrm/displays/panel-dpi.o: In function
> `panel_dpi_probe_of': panel-dpi.c:(.text.panel_dpi_probe_of+0xe8):
> undefined reference to `of_find_backlight_by_node'
> 
> This adds a dependency like we have for the other panel drivers.

I believe the dependency should be made optional. DPI panels that don't need 
backlight control should be supported by a kernel that has backlight support 
compiled out. How about something like

From 07a98ab23b2080c79abbf8b5e7479123c50e6be7 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart 
Date: Wed, 19 Apr 2017 23:13:43 +0300
Subject: [PATCH] backlight: Define API stub when backlight support is disabled

The of_find_backlight_by_node() function has a stubbed when CONFIG_OF is
disabled, but drivers that use backlights optionally will still fail to
link if backlight support is disabled. Fix it by defining the stub when
CONFIG_BACKLIGHT_CLASS_DEVICE is disabled.

Signed-off-by: Laurent Pinchart 
---
 include/linux/backlight.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f2fd61ef4fb..fae0b189f7b4 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -162,7 +162,7 @@ struct generic_bl_info {
void (*kick_battery)(void);
 };
 
-#ifdef CONFIG_OF
+#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
 struct backlight_device *of_find_backlight_by_node(struct device_node *node);
 #else
 static inline struct backlight_device *


We might need to create stubs for backlight_force_update() and 
backlight_device_set_brightness() too.

> Fixes: 39135a305a0f ("drm/omap: displays: panel-dpi: Support for handling
> backlight devices")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/omapdrm/displays/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/displays/Kconfig
> b/drivers/gpu/drm/omapdrm/displays/Kconfig index c226da145fb3..a349cb61961e
> 100644
> --- a/drivers/gpu/drm/omapdrm/displays/Kconfig
> +++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
> @@ -35,6 +35,7 @@ config DRM_OMAP_CONNECTOR_ANALOG_TV
> 
>  config DRM_OMAP_PANEL_DPI
>   tristate "Generic DPI panel"
> + depends on BACKLIGHT_CLASS_DEVICE
>   help
> Driver for generic DPI panels.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

[Daniel Vetter]

On Wed, Apr 19, 2017 at 7:55 PM, Eric Anholt  wrote:
> Daniel Vetter  writes:
>> On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt  wrote:
>>> The FBDEV initialization would throw an error in dmesg, when we just
>>> want to silently not initialize fbdev on a V3D-only VC4 instance.
>>>
>>> Signed-off-by: Eric Anholt 
>>
>> Hm, this shouldn't be an error really, you might want to hotplug more
>> connectors later on. What exactly complains?
>
> drm_fb_helper_init() throws an error if the passed in connector count is
> 0, so drm_fb_cma_helper() printks an error.

Oh, _that_ thing. The error in there is correct, but (almost) everyone
gets this parameter wrong. This isn't the max number of connectors the
fb helper will light up, but just the max number of connectors _per_
crtc when driving in hw clone mode. There's two problems with that:
- fb helpers don't support hw clone mode, we select 1:1 crtcs for each
active connector
- I mentioned that everyone gets this wrong?

If you're moderately bored it'd be great to nuke the max_connector
argument from drm_fb_helper_init, and hard-code it to 1 (with a big
comment explaining that this needs to be changed, probably with
dynamic reallocation, once someone gets around to implementing hw
clone mode).

If you're less bored, just hardcode this to 1 in vc4 and done. Plus a
TODO.rst entry would be great in that case.
-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: [rfc repost] drm sync objects - a new beginning (make ickle happier?)

[Dave Airlie]

On 20 April 2017 at 04:42, Dave Airlie  wrote:
> On 19 April 2017 at 22:07, Christian König  wrote:
>> Am 13.04.2017 um 03:41 schrieb Dave Airlie:
>>>
>>> Okay I've taken Chris's suggestions to heart and reworked things
>>> around a sem_file to see how they might look.
>>>
>>> This means the drm_syncobj are currently only useful for semaphores,
>>> the flags field could be used in future to use it for other things,
>>> and we can reintroduce some of the API then if needed.
>>>
>>> This refactors sync_file first to add some basic rcu wrappers
>>> about the fence pointer, as this point never updates this should
>>> all be fine unlocked.
>>>
>>> It then creates the sem_file with a mutex, and uses that to
>>> track the semaphores with reduced fops and the replace and
>>> get APIs.
>>>
>>> Then it reworks the drm stuff on top, and fixes amdgpu bug
>>> with old_fence.
>>>
>>> Let's see if anyone prefers one approach over the other.
>>
>>
>> Yeah, I clearly prefer keeping only one object type for synchronization in
>> the kernel.
>>
>> As I wrote in the other mail the argument of using the sync file for
>> semaphores was to be able to use it as in fence with the atomic mode setting
>> as well.
>>
>> That a wait consumes a previous signal should be a specific behavior of the
>> operation and not the property of the object.
>>
>> In other words I'm fine with using the sync_file in a 1:1 fashion with
>> Vulkan, but for the atomic API we probably want 1:N to be able to flip a
>> rendering result on multiple CRTCs at the same time.
>
> Well ideally atomic modesetting should be moved to using syncobjects
> as an option.
>
> I'd rather sync_files were limited in scope to interaction with non-drm 
> drivers,
> and possibly interprocess operations, consuming fd's is bad and merging 
> doesn't
> really fix that.
>
> I'm starting to narrow down to what I think the sync_obj needs to do, and I'm
> contemplating a bit more something like the following:
>
> a) no file backing, a simple kref object that gets tracked in an idr
> (like a gem object).
> This object can have an optional fence attached to it. If there is no
> fence, it's unsignalled,
> if there is a fence it's signalled.

This should say, if there's a fence, the status of the fence.
Thanks to Andres for pointing it out, it is 5am.

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

Re: [PATCH] drm/etnaviv: add thermal dependency

[Andy Shevchenko]

On Wed, Apr 19, 2017 at 9:11 PM, Arnd Bergmann  wrote:
> When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is
> built-in, we get a link error:
>
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
> etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34): undefined reference to 
> `thermal_of_cooling_device_register'
> etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0xe0): undefined reference to 
> `thermal_cooling_device_unregister'
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_unbind':
> etnaviv_gpu.c:(.text.etnaviv_gpu_unbind+0xf0): undefined reference to 
> `thermal_cooling_device_unregister'
>
> This adds a Kconfig dependency to prevent etnaviv from being built-in
> with CONFIG_THERMAL=m, while still allowing the valid configurations.
> Unfortunately, simply adding the dependency here breaks Kconfig through
> a dependency loop involving lots of symbols all the way until ACPI_VIDEO,
> which is the only video driver that explicitly selects 'THERMAL'. Turning
> this into a 'depends on' addresses the problem.
> For completeness, I'm also removing the redundant 'select THERMAL'
> from INTEL_MENLOW, so no other driver uses that statement.
>

For PDx86 part:

Acked-by: Andy Shevchenko 

> Fixes: bcdfb5e56dc5 ("drm/etnaviv: add etnaviv cooling device")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/acpi/Kconfig| 2 +-
>  drivers/gpu/drm/etnaviv/Kconfig | 1 +
>  drivers/platform/x86/Kconfig| 1 -
>  3 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 03cc4e74096b..252399efa8b3 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -184,7 +184,7 @@ config ACPI_VIDEO
> tristate "Video"
> depends on X86 && BACKLIGHT_CLASS_DEVICE
> depends on INPUT
> -   select THERMAL
> +   depends on THERMAL
> help
>   This driver implements the ACPI Extensions For Display Adapters
>   for integrated graphics devices on motherboard, as specified in
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index 71cee4e9fefb..1d6c744e7924 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -3,6 +3,7 @@ config DRM_ETNAVIV
> tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
> depends on DRM
> depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST)
> +   depends on THERMAL || THERMAL=n
> depends on MMU
> select SHMEM
> select SYNC_FILE
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index e229ea317b9c..76ced87efde5 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -544,7 +544,6 @@ config SENSORS_HDAPS
>  config INTEL_MENLOW
> tristate "Thermal Management driver for Intel menlow platform"
> depends on ACPI_THERMAL
> -   select THERMAL
> ---help---
>   ACPI thermal management enhancement driver on
>   Intel Menlow platform.
> --
> 2.9.0
>



-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

[bugzilla-daemon]

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

--- Comment #1 from hiwatari.se...@gmail.com ---
Created attachment 130926
  --> https://bugs.freedesktop.org/attachment.cgi?id=130926=edit
Short video showing the issue

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

[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

[bugzilla-daemon]

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

Bug ID: 100726
   Summary: [REGRESSION][BISECTED] Severe flickering with an R9
290
   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: hiwatari.se...@gmail.com

As of the commit:
d8d1721cfb3162abbda078d67a928792d6552b84 : A series of fixup patches meant
to fix the usage of DMA on stack, plus one warning fixup

My R9 290 produces heavy flickering artifacts in 1 of 3 or 4 cases when
starting Linux.
I am using the amdgpu kernel module, and have not tested this with radeon.
When the bug occurs, the system is completely unusable.

Since the occurence of this bug is not really deterministic, bisecting it was
not that easy. I hope I didn't make any mistake.

-- 
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: [rfc repost] drm sync objects - a new beginning (make ickle happier?)

[Dave Airlie]

On 19 April 2017 at 22:07, Christian König  wrote:
> Am 13.04.2017 um 03:41 schrieb Dave Airlie:
>>
>> Okay I've taken Chris's suggestions to heart and reworked things
>> around a sem_file to see how they might look.
>>
>> This means the drm_syncobj are currently only useful for semaphores,
>> the flags field could be used in future to use it for other things,
>> and we can reintroduce some of the API then if needed.
>>
>> This refactors sync_file first to add some basic rcu wrappers
>> about the fence pointer, as this point never updates this should
>> all be fine unlocked.
>>
>> It then creates the sem_file with a mutex, and uses that to
>> track the semaphores with reduced fops and the replace and
>> get APIs.
>>
>> Then it reworks the drm stuff on top, and fixes amdgpu bug
>> with old_fence.
>>
>> Let's see if anyone prefers one approach over the other.
>
>
> Yeah, I clearly prefer keeping only one object type for synchronization in
> the kernel.
>
> As I wrote in the other mail the argument of using the sync file for
> semaphores was to be able to use it as in fence with the atomic mode setting
> as well.
>
> That a wait consumes a previous signal should be a specific behavior of the
> operation and not the property of the object.
>
> In other words I'm fine with using the sync_file in a 1:1 fashion with
> Vulkan, but for the atomic API we probably want 1:N to be able to flip a
> rendering result on multiple CRTCs at the same time.

Well ideally atomic modesetting should be moved to using syncobjects
as an option.

I'd rather sync_files were limited in scope to interaction with non-drm drivers,
and possibly interprocess operations, consuming fd's is bad and merging doesn't
really fix that.

I'm starting to narrow down to what I think the sync_obj needs to do, and I'm
contemplating a bit more something like the following:

a) no file backing, a simple kref object that gets tracked in an idr
(like a gem object).
This object can have an optional fence attached to it. If there is no
fence, it's unsignalled,
if there is a fence it's signalled. We should provide an interface to
wait on multiple of
these objects that can support Vulkan fence waiting api. We should use
these objects
in command submission interfaces to provide Vulkan fence and semaphore APIs.
These objects will never be grouped or have multiple fences in them.
From a kernel
API we can have multiple waiters and shouldn't enforce the Vulkan semaphore 1:1
at this level, userspace can just create it's own semantics on top.
Open:
These objects are created in advance and then filled in by command
submission ioctls,
or do we want the option for a command submission ioctl to return a
newly created one
of these?

b) sharing of sync objects.
By default we provide a sync_obj->fd conversion, this fd is opaque and
can be passed
between processes to implement things like Vulkan semaphore passing.

c) interoperation with sync_file.
We should provide a mechanism to move a group of sync objects into a sync_file,
so it can be passed into sync_file APIs. We should provide a mechanism
to map a sync_file
into a group of sync objects. This will be a possible 1:n conversion.
Open:
Does the sync_file->syncobj operation create sync objects? or do we
need to pass in a preallocated group?
Does the sync_file->syncobj or syncobj->sync_file operations have any
side effects? I'm tending towards not,
(i.e. no signalling or anything else).

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

Re: [PATCH v2 4/5] nouveau_hwmon: Add support for auto_point attributes

[Ilia Mirkin]

On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
 wrote:
> This patch creates a special group attributes for attrs like "*auto_point*".
> We check if we have support for them, and if we do, we gather them all in
> an attribute_group's structure which is the parameter regarding special groups
> of hwmon_device_register_with_info.
> ---
>  drivers/gpu/drm/nouveau/nouveau_hwmon.c | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
> b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> index 538bf67..655ae11 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> @@ -359,6 +359,23 @@ nouveau_hwmon_get_power1_crit(struct nouveau_drm *drm)
> return iccsense->power_w_crit;
>  }
>
> +static struct attribute *pwm_fan_sensor_attrs[] = {

static const struct. Below as well.

> +   _dev_attr_pwm1_min.dev_attr.attr,
> +   _dev_attr_pwm1_max.dev_attr.attr,
> +   NULL
> +};
> +ATTRIBUTE_GROUPS(pwm_fan_sensor);
> +
> +static struct attribute *temp1_auto_point_sensor_attrs[] = {
> +   _dev_attr_temp1_auto_point1_pwm.dev_attr.attr,
> +   _dev_attr_temp1_auto_point1_temp.dev_attr.attr,
> +   _dev_attr_temp1_auto_point1_temp_hyst.dev_attr.attr,
> +   NULL
> +};
> +ATTRIBUTE_GROUPS(temp1_auto_point_sensor);
> +
> +#define N_ATTR_GROUPS   3
> +
>  static const u32 nouveau_config_chip[] = {
> HWMON_C_UPDATE_INTERVAL,
> 0
> @@ -789,17 +806,27 @@ nouveau_hwmon_init(struct drm_device *dev)
>  #if defined(CONFIG_HWMON) || (defined(MODULE) && 
> defined(CONFIG_HWMON_MODULE))
> struct nouveau_drm *drm = nouveau_drm(dev);
> struct nvkm_therm *therm = nvxx_therm(>client.device);
> +   const struct attribute_group *special_groups[N_ATTR_GROUPS];
> struct nouveau_hwmon *hwmon;
> struct device *hwmon_dev;
> int ret = 0;
> +   int i = 0;
>
> hwmon = drm->hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
> if (!hwmon)
> return -ENOMEM;
> hwmon->dev = dev;
>
> +   if (therm && therm->attr_get && therm->attr_set) {
> +   if (nvkm_therm_temp_get(therm) >= 0)
> +   special_groups[i++] = _auto_point_sensor_group;
> +   if (therm->fan_get && therm->fan_get(therm) >= 0)
> +   special_groups[i++] = _fan_sensor_group;
> +   }
> +
> +   special_groups[i] = 0;
> hwmon_dev = hwmon_device_register_with_info(dev->dev, "nouveau", dev,
> -   _chip_info, NULL);
> +   _chip_info, special_groups);
> if (IS_ERR(hwmon_dev)) {
> ret = PTR_ERR(hwmon_dev);
> NV_ERROR(drm, "Unable to register hwmon device: %d\n", ret);
> --
> 2.1.4
>
> ___
> 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

[PATCH] gpu: host1x: select IOMMU_IOVA

[Arnd Bergmann]

When IOMMU_IOVA is not built-in but host1x is, we get a link error:

drivers/gpu/host1x/dev.o: In function `host1x_remove':
dev.c:(.text.host1x_remove+0x50): undefined reference to `put_iova_domain'
drivers/gpu/host1x/dev.o: In function `host1x_probe':
dev.c:(.text.host1x_probe+0x31c): undefined reference to `init_iova_domain'
dev.c:(.text.host1x_probe+0x38c): undefined reference to `put_iova_domain'
drivers/gpu/host1x/cdma.o: In function `host1x_cdma_init':
cdma.c:(.text.host1x_cdma_init+0x238): undefined reference to `alloc_iova'
cdma.c:(.text.host1x_cdma_init+0x2c0): undefined reference to `__free_iova'
drivers/gpu/host1x/cdma.o: In function `host1x_cdma_deinit':
cdma.c:(.text.host1x_cdma_deinit+0xb0): undefined reference to `free_iova'

This adds the same select statement that we have for drm_tegra.

Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/host1x/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
index b2fd029d67b3..91916326957f 100644
--- a/drivers/gpu/host1x/Kconfig
+++ b/drivers/gpu/host1x/Kconfig
@@ -1,6 +1,7 @@
 config TEGRA_HOST1X
tristate "NVIDIA Tegra host1x driver"
depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
+   select IOMMU_IOVA if IOMMU_SUPPORT
help
  Driver for the NVIDIA Tegra host1x hardware.
 
-- 
2.9.0

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

[PATCH] [RFC] gpu: host1x: shut up warning about DMA API misuse

[Arnd Bergmann]

When dma_addr_t and phys_addr_t are not the same size, we get a warning
from the dma_alloc_wc function:

drivers/gpu/host1x/cdma.c: In function 'host1x_pushbuffer_init':
drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of 'dma_alloc_wc' 
from incompatible pointer type [-Werror=incompatible-pointer-types]
   pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
^
In file included from drivers/gpu/host1x/cdma.c:22:0:
include/linux/dma-mapping.h:761:37: note: expected 'dma_addr_t * {aka long long 
unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
 static noinline_if_stackbloat void *dma_alloc_wc(struct device *dev, size_t 
size,
 ^~~~
drivers/gpu/host1x/cdma.c:113:48: error: passing argument 3 of 'dma_alloc_wc' 
from incompatible pointer type [-Werror=incompatible-pointer-types]
   pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
^
In file included from drivers/gpu/host1x/cdma.c:22:0:
include/linux/dma-mapping.h:761:37: note: expected 'dma_addr_t * {aka long long 
unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
 static noinline_if_stackbloat void *dma_alloc_wc(struct device *dev, size_t 
size,
 ^~~~

The problem here is that dma_alloc_wc() returns a pointer to a dma_addr_t
that may already be translated by an IOMMU, but the driver passes this
into iommu_map() as a physical address. This works by accident only when
the IOMMU does not get registered with the DMA API and there is a 1:1
mapping between physical addresses as seen by the CPU and the device.

The fundamental problem here is the lack of a generic API to do what the
driver wants: allocating CPU-visible memory for use by a device through
user-defined IOMMU settings. Neither the dma-mapping API nor the IOMMU
API can do this by itself, and combining the two is not well-defined.

This patch addresses the type mismatch by adding a third pointer into the
push_buffer structure: in addition to the address as seen from the CPU
and the address inside of the local IOMMU domain, the pb->alloc pointer
is the token returned by dma_alloc_wc(), and this is what we later need
to pass into dma_free_wc().

The address we pass into iommu_map() however is the physical address
computed from virt_to_phys(), assuming that the pointer we have here
is part of the linear mapping (which is also questionable, e.g. when we
have a non-coherent device on ARM32 this may be false). Also, when
the DMA API uses the IOMMU to allocate the pointer for the default
domain, we end up with two IOMMU mappings for the same physical address.

Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/host1x/cdma.c | 26 ++
 drivers/gpu/host1x/cdma.h |  1 +
 2 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 28541b280739..286edeca7ba1 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -59,7 +59,7 @@ static void host1x_pushbuffer_destroy(struct push_buffer *pb)
free_iova(>iova, iova_pfn(>iova, pb->dma));
}
 
-   dma_free_wc(host1x->dev, pb->alloc_size, pb->mapped, pb->phys);
+   dma_free_wc(host1x->dev, pb->alloc_size, pb->mapped, pb->alloc);
 
pb->mapped = NULL;
pb->phys = 0;
@@ -81,20 +81,21 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
pb->size = HOST1X_PUSHBUFFER_SLOTS * 8;
 
size = pb->size + 4;
+   if (host1x->domain)
+   size = iova_align(>iova, size);
 
/* initialize buffer pointers */
pb->fence = pb->size - 8;
pb->pos = 0;
 
-   if (host1x->domain) {
-   unsigned long shift;
+   pb->mapped = dma_alloc_wc(host1x->dev, size, >alloc, GFP_KERNEL);
+   if (!pb->mapped)
+   return -ENOMEM;
 
-   size = iova_align(>iova, size);
+   pb->phys = virt_to_phys(pb->mapped);
 
-   pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
- GFP_KERNEL);
-   if (!pb->mapped)
-   return -ENOMEM;
+   if (host1x->domain) {
+   unsigned long shift;
 
shift = iova_shift(>iova);
alloc = alloc_iova(>iova, size >> shift,
@@ -109,13 +110,6 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
IOMMU_READ);
if (err)
goto iommu_free_iova;
-   } else {
-   pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
- GFP_KERNEL);
-   if (!pb->mapped)
-   return -ENOMEM;
-
-   pb->dma = pb->phys;
}
 
pb->alloc_size = 

Re: X.org EVoC Ideas

[Dylan Baker]

Quoting Rob Clark (2017-04-18 11:27:14)
> On Tue, Apr 18, 2017 at 1:32 PM, Emil Velikov  
> wrote:
> > On 18 April 2017 at 16:48, Rob Clark  wrote:
> >> On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia
> >>  wrote:
> >>> Hi there
> >>>
> >>> I am Raghav Jajodia, an Engineering student from India. While going 
> >>> through
> >>> the X.org foundation, I felt that X.org is a great community for new Open
> >>> Source developers. I am deeply interested in being a part of the 
> >>> community.
> >>> Although, while going through the GSoC and EVoC Ideas, I found that all 
> >>> the
> >>> ideas revolve around C, C++, QT or Compilers.
> >>>
> >>> Working extensively on Web, Moile and Desktop applications, I have gained
> >>> good experience with Python, JS, PHP, Ruby etc. But I do not have any
> >>> experience with C/C++.
> >>>
> >>> So, is not possible for a student to participate in EVoC if he doesn't 
> >>> have
> >>> any experience with Open source softwares built on C/C++. Are there any
> >>> project ideas using languages apart from C/C++ that a student can work on
> >>> for EVoC 17/18?
> >>
> >> Hi, the only requirement regarding programming languages is that
> >> "Applicants know their target programming language."..  there isn't
> >> any requirement otherwise, but I think the fast majority are largely
> >> C/C++.  There are bits of python here and there (piglit, for example..
> >> possibly others that I don't know of).
> >>
> >> From a quick look all of the suggested projects involve C and/or C++.
> >> But that doesn't mean a candidate couldn't suggest a different project
> >> that is not on the list.
> >>
> > FWIW the python in piglit is fine, while the one in Mesa is in a dire shape.

I tend to agree, the only thing that might be useful (and I'd want to see a
proposal of what and how because it would need to be really good) is to overhaul
the piglit summary html tool to be not so awful. Someone with a good grasp of
javascript could probably make that webpage not a 25mb monstrosity that actually
loaded in a reasonable amount of time.

> 
> I didn't realize there where TODO's for py involved in mesa build..
> maybe we should add some to the SummerOfCodeIdeas wiki page[1]
> 
> /me would add convert nir_intrinsic.h + multiple #includes to .py
> generating .c and .h if there was such a topic..  maybe not enough for
> a EVoC/GSoC project on it's own but perhaps if combined w/ some other
> work needed on mesa's python..

The only large one I'm aware is to convert the mapi/glapi generators to use the
khronos XML and not the handwritten XML we use currently. It's been on my radar,
but I haven't really gotten started on it. Presumably sub-requirements of that
would be to use mako instead of `print`s and to be at least close to python3
ready (i.e., a complete rewrite). There's also what has been described as a
fairly simple C project to rip out a level of abstraction in that subsystem.

There's also a bunch of smaller projects to convert the other generators to be
python2/3 hybrid ready (since python 2 is *finally* starting to get the boot in
distros), and to use mako (where applicable). Some of these are really awful,
some of them are pretty good.

Dylan

> 
> BR,
> -R
> 
> [1] https://www.x.org/wiki/SummerOfCodeIdeas/
> 
> 
> > That said, I believe Rob summarised it perfectly:
> > Take a look around and feel free to propose something if the ones
> > listed do not interest you.
> >
> > Regards,
> > Emil
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Re: [Nouveau] [PATCH v2 2/5] nouveau_hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string

[Ilia Mirkin]

On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
 wrote:
> +static char *input_label = "GPU core";

This needs to be static const char input_label[] = "GPU core";

or at least static const char *const input_label = "GPU core";

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

Re: [Nouveau] [PATCH v2 1/5] nouveau_hwmon: Add config for all sensors and their settings

[Oscar Salvador]

Got it, I'll make a v3 with that line in all patches.

Thanks!

On 19 April 2017 at 20:11, Ilia Mirkin  wrote:
> All kernel patches must have a Signed-off-by: $user. See
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
>
> On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
>  wrote:
>> This is a preparation for the next patches. It just adds the sensors with
>> their possible configurable settings and then fills the struct 
>> hwmon_channel_info
>> with all this information.
>> ---
>>  drivers/gpu/drm/nouveau/nouveau_hwmon.c | 72 
>> +
>>  1 file changed, 72 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
>> b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
>> index 23b1670..24b40c5 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
>> @@ -692,6 +692,78 @@ static const struct attribute_group 
>> hwmon_power_attrgroup = {
>>  static const struct attribute_group hwmon_power_caps_attrgroup = {
>> .attrs = hwmon_power_caps_attributes,
>>  };
>> +
>> +static const u32 nouveau_config_chip[] = {
>> +   HWMON_C_UPDATE_INTERVAL,
>> +   0
>> +};
>> +
>> +static const u32 nouveau_config_in[] = {
>> +   HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
>> +   0
>> +};
>> +
>> +static const u32 nouveau_config_temp[] = {
>> +   HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
>> +   HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
>> +   HWMON_T_EMERGENCY_HYST,
>> +   0
>> +};
>> +
>> +static const u32 nouveau_config_fan[] = {
>> +   HWMON_F_INPUT,
>> +   0
>> +};
>> +
>> +static const u32 nouveau_config_pwm[] = {
>> +   HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
>> +   0
>> +};
>> +
>> +static const u32 nouveau_config_power[] = {
>> +   HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
>> +   0
>> +};
>> +
>> +static const struct hwmon_channel_info nouveau_chip = {
>> +   .type = hwmon_chip,
>> +   .config = nouveau_config_chip,
>> +};
>> +
>> +static const struct hwmon_channel_info nouveau_temp = {
>> +   .type = hwmon_temp,
>> +   .config = nouveau_config_temp,
>> +};
>> +
>> +static const struct hwmon_channel_info nouveau_fan = {
>> +   .type = hwmon_fan,
>> +   .config = nouveau_config_fan,
>> +};
>> +
>> +static const struct hwmon_channel_info nouveau_in = {
>> +   .type = hwmon_in,
>> +   .config = nouveau_config_in,
>> +};
>> +
>> +static const struct hwmon_channel_info nouveau_pwm = {
>> +   .type = hwmon_pwm,
>> +   .config = nouveau_config_pwm,
>> +};
>> +
>> +static const struct hwmon_channel_info nouveau_power = {
>> +   .type = hwmon_power,
>> +   .config = nouveau_config_power,
>> +};
>> +
>> +static const struct hwmon_channel_info *nouveau_info[] = {
>> +   _chip,
>> +   _temp,
>> +   _fan,
>> +   _in,
>> +   _pwm,
>> +   _power,
>> +   NULL
>> +};
>>  #endif
>>
>>  int
>> --
>> 2.1.4
>>
>> ___
>> Nouveau mailing list
>> nouv...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/etnaviv: add thermal dependency

[Arnd Bergmann]

When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is
built-in, we get a link error:

drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34): undefined reference to 
`thermal_of_cooling_device_register'
etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0xe0): undefined reference to 
`thermal_cooling_device_unregister'
drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_unbind':
etnaviv_gpu.c:(.text.etnaviv_gpu_unbind+0xf0): undefined reference to 
`thermal_cooling_device_unregister'

This adds a Kconfig dependency to prevent etnaviv from being built-in
with CONFIG_THERMAL=m, while still allowing the valid configurations.
Unfortunately, simply adding the dependency here breaks Kconfig through
a dependency loop involving lots of symbols all the way until ACPI_VIDEO,
which is the only video driver that explicitly selects 'THERMAL'. Turning
this into a 'depends on' addresses the problem.
For completeness, I'm also removing the redundant 'select THERMAL'
from INTEL_MENLOW, so no other driver uses that statement.

Fixes: bcdfb5e56dc5 ("drm/etnaviv: add etnaviv cooling device")
Signed-off-by: Arnd Bergmann 
---
 drivers/acpi/Kconfig| 2 +-
 drivers/gpu/drm/etnaviv/Kconfig | 1 +
 drivers/platform/x86/Kconfig| 1 -
 3 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 03cc4e74096b..252399efa8b3 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -184,7 +184,7 @@ config ACPI_VIDEO
tristate "Video"
depends on X86 && BACKLIGHT_CLASS_DEVICE
depends on INPUT
-   select THERMAL
+   depends on THERMAL
help
  This driver implements the ACPI Extensions For Display Adapters
  for integrated graphics devices on motherboard, as specified in
diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
index 71cee4e9fefb..1d6c744e7924 100644
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -3,6 +3,7 @@ config DRM_ETNAVIV
tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
depends on DRM
depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST)
+   depends on THERMAL || THERMAL=n
depends on MMU
select SHMEM
select SYNC_FILE
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index e229ea317b9c..76ced87efde5 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -544,7 +544,6 @@ config SENSORS_HDAPS
 config INTEL_MENLOW
tristate "Thermal Management driver for Intel menlow platform"
depends on ACPI_THERMAL
-   select THERMAL
---help---
  ACPI thermal management enhancement driver on
  Intel Menlow platform.
-- 
2.9.0

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

Re: [Nouveau] [PATCH v2 1/5] nouveau_hwmon: Add config for all sensors and their settings

[Ilia Mirkin]

All kernel patches must have a Signed-off-by: $user. See
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
 wrote:
> This is a preparation for the next patches. It just adds the sensors with
> their possible configurable settings and then fills the struct 
> hwmon_channel_info
> with all this information.
> ---
>  drivers/gpu/drm/nouveau/nouveau_hwmon.c | 72 
> +
>  1 file changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
> b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> index 23b1670..24b40c5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> @@ -692,6 +692,78 @@ static const struct attribute_group 
> hwmon_power_attrgroup = {
>  static const struct attribute_group hwmon_power_caps_attrgroup = {
> .attrs = hwmon_power_caps_attributes,
>  };
> +
> +static const u32 nouveau_config_chip[] = {
> +   HWMON_C_UPDATE_INTERVAL,
> +   0
> +};
> +
> +static const u32 nouveau_config_in[] = {
> +   HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
> +   0
> +};
> +
> +static const u32 nouveau_config_temp[] = {
> +   HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> +   HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
> +   HWMON_T_EMERGENCY_HYST,
> +   0
> +};
> +
> +static const u32 nouveau_config_fan[] = {
> +   HWMON_F_INPUT,
> +   0
> +};
> +
> +static const u32 nouveau_config_pwm[] = {
> +   HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
> +   0
> +};
> +
> +static const u32 nouveau_config_power[] = {
> +   HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
> +   0
> +};
> +
> +static const struct hwmon_channel_info nouveau_chip = {
> +   .type = hwmon_chip,
> +   .config = nouveau_config_chip,
> +};
> +
> +static const struct hwmon_channel_info nouveau_temp = {
> +   .type = hwmon_temp,
> +   .config = nouveau_config_temp,
> +};
> +
> +static const struct hwmon_channel_info nouveau_fan = {
> +   .type = hwmon_fan,
> +   .config = nouveau_config_fan,
> +};
> +
> +static const struct hwmon_channel_info nouveau_in = {
> +   .type = hwmon_in,
> +   .config = nouveau_config_in,
> +};
> +
> +static const struct hwmon_channel_info nouveau_pwm = {
> +   .type = hwmon_pwm,
> +   .config = nouveau_config_pwm,
> +};
> +
> +static const struct hwmon_channel_info nouveau_power = {
> +   .type = hwmon_power,
> +   .config = nouveau_config_power,
> +};
> +
> +static const struct hwmon_channel_info *nouveau_info[] = {
> +   _chip,
> +   _temp,
> +   _fan,
> +   _in,
> +   _pwm,
> +   _power,
> +   NULL
> +};
>  #endif
>
>  int
> --
> 2.1.4
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/panel: add backlight dependency for sitronix-st7789v

[Arnd Bergmann]

Without the dependency, we run into a link error:

drivers/gpu/drm/panel/panel-sitronix-st7789v.o: In function `st7789v_probe':
panel-sitronix-st7789v.c:(.text.st7789v_probe+0xc0): undefined reference to 
`of_find_backlight_by_node'

Fixes: 7142afb3a186 ("drm/panel: Add driver for sitronix ST7789V LCD 
controller")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/panel/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6eb9774284df..04d068177e16 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -101,6 +101,7 @@ config DRM_PANEL_SHARP_LS043T1LE01
 config DRM_PANEL_SITRONIX_ST7789V
tristate "Sitronix ST7789V panel"
depends on OF && SPI
+   depends on BACKLIGHT_CLASS_DEVICE
help
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
-- 
2.9.0

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

[PATCH 2/3] drm/panel: S6E3HA2 needs backlight code

[Arnd Bergmann]

The new S6E3HA2 driver fails to link when backlight is disabled:

ERROR: "backlight_device_register" 
[drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined!
ERROR: "backlight_device_unregister" 
[drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined!

This adds a Kconfig dependency like we have it for some other panel drivers.

Fixes: ed29f9426d9b ("drm/panel: Add support for S6E3HA2 panel driver on TM2 
board")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/panel/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a9903303..6eb9774284df 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -66,6 +66,7 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
tristate "Samsung S6E3HA2 DSI video mode panel"
depends on OF
depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
select VIDEOMODE_HELPERS
 
 config DRM_PANEL_SAMSUNG_S6E8AA0
-- 
2.9.0

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

[PATCH 1/3] drm/omap: displays: panel-dpi: add backlight dependency

[Arnd Bergmann]

The panel driver gained support for backlight but fails to link now
when that is disabled:

drivers/gpu/drm/omapdrm/displays/panel-dpi.o: In function `panel_dpi_probe_of':
panel-dpi.c:(.text.panel_dpi_probe_of+0xe8): undefined reference to 
`of_find_backlight_by_node'

This adds a dependency like we have for the other panel drivers.

Fixes: 39135a305a0f ("drm/omap: displays: panel-dpi: Support for handling 
backlight devices")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/omapdrm/displays/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/Kconfig 
b/drivers/gpu/drm/omapdrm/displays/Kconfig
index c226da145fb3..a349cb61961e 100644
--- a/drivers/gpu/drm/omapdrm/displays/Kconfig
+++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
@@ -35,6 +35,7 @@ config DRM_OMAP_CONNECTOR_ANALOG_TV
 
 config DRM_OMAP_PANEL_DPI
tristate "Generic DPI panel"
+   depends on BACKLIGHT_CLASS_DEVICE
help
  Driver for generic DPI panels.
 
-- 
2.9.0

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

Re: [PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

[Eric Anholt]

Daniel Vetter  writes:

> On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt  wrote:
>> The FBDEV initialization would throw an error in dmesg, when we just
>> want to silently not initialize fbdev on a V3D-only VC4 instance.
>>
>> Signed-off-by: Eric Anholt 
>
> Hm, this shouldn't be an error really, you might want to hotplug more
> connectors later on. What exactly complains?

drm_fb_helper_init() throws an error if the passed in connector count is
0, so drm_fb_cma_helper() printks an error.


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

[Bug 195465] AMD Hybrid graphic dont work, R7 M260/M265 (Topaz)

[bugzilla-daemon]

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

--- Comment #2 from Hugo Andrade (hugo.s...@gmail.com) ---
Created attachment 255929
  --> https://bugzilla.kernel.org/attachment.cgi?id=255929=edit
lshw

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

[Bug 195465] AMD Hybrid graphic dont work, R7 M260/M265 (Topaz)

[bugzilla-daemon]

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

--- Comment #1 from Hugo Andrade (hugo.s...@gmail.com) ---
Created attachment 255927
  --> https://bugzilla.kernel.org/attachment.cgi?id=255927=edit
Lspci

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

Re: [rfc repost] drm sync objects - a new beginning (make ickle happier?)

[James Jones]

On 04/19/2017 05:07 AM, Christian König wrote:

Am 13.04.2017 um 03:41 schrieb Dave Airlie:

Okay I've taken Chris's suggestions to heart and reworked things
around a sem_file to see how they might look.

This means the drm_syncobj are currently only useful for semaphores,
the flags field could be used in future to use it for other things,
and we can reintroduce some of the API then if needed.

This refactors sync_file first to add some basic rcu wrappers
about the fence pointer, as this point never updates this should
all be fine unlocked.

It then creates the sem_file with a mutex, and uses that to
track the semaphores with reduced fops and the replace and
get APIs.

Then it reworks the drm stuff on top, and fixes amdgpu bug
with old_fence.

Let's see if anyone prefers one approach over the other.


Yeah, I clearly prefer keeping only one object type for synchronization
in the kernel.

As I wrote in the other mail the argument of using the sync file for
semaphores was to be able to use it as in fence with the atomic mode
setting as well.


This may introduce incompatibilities in userspace though, as the 
response to Dave's original series' pointed out.  For example, the 
Vulkan extensions that allow importing sync files expect them to behave 
as sync files currently do, not as these new objects do.  Introducing 
the new behavior would invalidate language in those specifications, 
causing problems with the very use case I suspect these changes are 
trying to address.  Those specs are not finalized, so it could be fixed, 
but I think that highlights the general concern.



That a wait consumes a previous signal should be a specific behavior of
the operation and not the property of the object.

In other words I'm fine with using the sync_file in a 1:1 fashion with
Vulkan, but for the atomic API we probably want 1:N to be able to flip a
rendering result on multiple CRTCs at the same time.


Agreed, this usage seems valuable too.  Sem files still have a fence in 
them, and that doesn't seem like an implementation detail that needs to 
be hidden from userspace.  Vulkan solved this very issue by letting 
applications directly extract the sync_file fd from a Vulkan semaphore 
so they could use it with native operations that specifically require a 
sync file, via the experimental external semaphore extensions.  Perhaps 
there could be a sem file -> sync file conversion operation with 
semantics similar to a Vulkan semaphore -> sync file export operation? 
Note the Vulkan semantics for this are in churn, so it might be worth 
holding off a bit on adding that interface if this is the path you use, 
but it shouldn't need to block this series from my high-level read.


Thanks,
-James


Regards,
Christian.



Dave.
___
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

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

[Bug 195465] New: AMD Hybrid graphic dont work, R7 M260/M265 (Topaz)

[bugzilla-daemon]

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

Bug ID: 195465
   Summary: AMD Hybrid graphic dont work, R7 M260/M265 (Topaz)
   Product: Drivers
   Version: 2.5
Kernel Version: 4.9.0-2-amd64
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: hugo.s...@gmail.com
Regression: No

Created attachment 255925
  --> https://bugzilla.kernel.org/attachment.cgi?id=255925=edit
dmesg

I had a Dell Notebook Inspiron 5548, and since I bought it, I can't run the amd
drive property. I upgrade my kernel to 4.9 version, and even I upgrade, the
problem still the same.

In attach I send the dmesg, lsci and lshw.

If anyone can help me, I would be very grateful



Linux 4.9.0-2-amd64 #1 SMP Debian 4.9.18-1 (2017-03-30) x86_64 GNU/Linux

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

[PATCH] [media] sti: hdmi: improve MEDIA_CEC_NOTIFIER dependency

[Arnd Bergmann]

When the media subsystem is built as a loadable module, a built-in
DRM driver cannot use the cec notifiers:

drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_remove':
sti_hdmi.c:(.text.sti_hdmi_remove+0x28): undefined reference to 
`cec_notifier_set_phys_addr'
sti_hdmi.c:(.text.sti_hdmi_remove+0x50): undefined reference to 
`cec_notifier_put'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_connector_get_modes':
sti_hdmi.c:(.text.sti_hdmi_connector_get_modes+0x84): undefined reference to 
`cec_notifier_set_phys_addr_from_edid'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_probe':
sti_hdmi.c:(.text.sti_hdmi_probe+0x1a8): undefined reference to 
`cec_notifier_get'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_connector_detect':
sti_hdmi.c:(.text.sti_hdmi_connector_detect+0x68): undefined reference to 
`cec_notifier_set_phys_addr'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_disable':
sti_hdmi.c:(.text.sti_hdmi_disable+0xec): undefined reference to 
`cec_notifier_set_phys_addr'

This adds a Kconfig dependency to enforce the HDMI driver to also
be a loadable module in this case.

Fixes: bca55958ea87 ("[media] sti: hdmi: add CEC notifier support")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/sti/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index acd72865feac..adac4c3e142e 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,6 +1,7 @@
 config DRM_STI
tristate "DRM Support for STMicroelectronics SoC stiH4xx Series"
depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
+   depends on (MEDIA_SUPPORT && MEDIA_CEC_NOTIFIER) || !MEDIA_CEC_NOTIFIER
select RESET_CONTROLLER
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
-- 
2.9.0

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

[PATCH] [media] exynos_hdmi: improve MEDIA_CEC_NOTIFIER dependency

[Arnd Bergmann]

When the media subsystem is built as a loadable module, a built-in
DRM driver cannot use the cec notifiers:

drivers/gpu/drm/exynos/exynos_hdmi.o: In function `hdmi_get_modes':
exynos_hdmi.c:(.text.hdmi_get_modes+0x80): undefined reference to 
`cec_notifier_set_phys_addr_from_edid'
drivers/gpu/drm/exynos/exynos_hdmi.o: In function `hdmi_remove':
exynos_hdmi.c:(.text.hdmi_remove+0x24): undefined reference to 
`cec_notifier_set_phys_addr'
exynos_hdmi.c:(.text.hdmi_remove+0x38): undefined reference to 
`cec_notifier_put'

This adds a Kconfig dependency to enforce the HDMI driver to also
be a loadable module in this case.

Fixes: 278c811c5d05 ("[media] exynos_hdmi: add CEC notifier support")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/exynos/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d185347c64c..65ba292f8e40 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,6 +1,7 @@
 config DRM_EXYNOS
tristate "DRM Support for Samsung SoC EXYNOS Series"
depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM)
+   depends on (MEDIA_SUPPORT && MEDIA_CEC_NOTIFIER) || !MEDIA_CEC_NOTIFIER
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
help
-- 
2.9.0

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

Re: [PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Sinclair Yeh]

Minor nits, otherwise the vmwgfx part,
  Reviewed-by: Sinclair Yeh 

On Tue, Apr 18, 2017 at 06:17:00PM -0600, Logan Gunthorpe wrote:
> Seeing the kunmap_atomic dma_buf_op shares the same name with a macro
s^

> in higmem.h, the former can be aliased if any dma-buf user includes
   h^
> that header.
> 
> I'm personally trying to include highmem.h inside scatterlist.h and this
> breaks the dma-buf code proper.
> 
> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
> 
> To maintain consistency I've renamed all four of kmap* and kunmap* to be
> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_target-2Ddevel_msg15070.html=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=QP_jolGTC4ofBnHRnAs0tFIXHnVWaTT0AdMyCL9SM64=un2hxBL1283iOTtJeJnvyyvtAu1d5Imyh5Q7AzljrfQ=
>  
> 
> Signed-off-by: Logan Gunthorpe 
> ---
>  drivers/dma-buf/dma-buf.c  | 16 
>  drivers/gpu/drm/armada/armada_gem.c|  8 
>  drivers/gpu/drm/drm_prime.c|  8 
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>  drivers/gpu/drm/tegra/gem.c|  4 ++--
>  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>  drivers/staging/android/ion/ion.c  |  8 
>  include/linux/dma-buf.h| 22 +++---
>  13 files changed, 55 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0007b79..7cc2bfe 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
> || !exp_info->ops->map_dma_buf
> || !exp_info->ops->unmap_dma_buf
> || !exp_info->ops->release
> -   || !exp_info->ops->kmap_atomic
> -   || !exp_info->ops->kmap
> +   || !exp_info->ops->map_atomic
> +   || !exp_info->ops->map
> || !exp_info->ops->mmap)) {
>   return ERR_PTR(-EINVAL);
>   }
> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num)
>  {
>   WARN_ON(!dmabuf);
>  
> - return dmabuf->ops->kmap_atomic(dmabuf, page_num);
> + return dmabuf->ops->map_atomic(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>  
> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num,
>  {
>   WARN_ON(!dmabuf);
>  
> - if (dmabuf->ops->kunmap_atomic)
> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap_atomic)
> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>  
> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
> page_num)
>  {
>   WARN_ON(!dmabuf);
>  
> - return dmabuf->ops->kmap(dmabuf, page_num);
> + return dmabuf->ops->map(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap);
>  
> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
> page_num,
>  {
>   WARN_ON(!dmabuf);
>  
> - if (dmabuf->ops->kunmap)
> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap)
> + dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap);
>  
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index 1597458..d6c2a5d 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -529,10 +529,10 @@ static const struct dma_buf_ops 
> armada_gem_prime_dmabuf_ops = {
>   .map_dma_buf= armada_gem_prime_map_dma_buf,
>   .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
>   .release= drm_gem_dmabuf_release,
> - .kmap_atomic= armada_gem_dmabuf_no_kmap,
> - .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
> - .kmap   = armada_gem_dmabuf_no_kmap,
> - .kunmap = armada_gem_dmabuf_no_kunmap,
> + .map_atomic = armada_gem_dmabuf_no_kmap,
> + .unmap_atomic   = armada_gem_dmabuf_no_kunmap,
> + .map= armada_gem_dmabuf_no_kmap,
> + .unmap  = armada_gem_dmabuf_no_kunmap,
>   .mmap   = armada_gem_dmabuf_mmap,
>  };
>  
> diff --git 

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

[bugzilla-daemon]

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

--- Comment #49 from russianneuroman...@ya.ru ---
By the way, seems like issue is much easier to reproduce with Steam desktop
notifications. Try to download something small, and it will show "download
completed" notification, or ask someone to send message to you via integrated
chat. From my latest three freezes I see that few (usually two-three)
notifications should be enough to reproduce this freeze.

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

[PATCH] drm/cec: Add CEC over Aux register definitions

[clinton . a . taylor]

From: Clint Taylor 

Adding DPCD register definitions from the DP 1.3 specification for CEC
over AUX support.

Signed-off-by: Clint Taylor 
---
 include/drm/drm_dp_helper.h |   59 +++
 1 file changed, 59 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c0bd0d7..d188aff 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -603,6 +603,9 @@
 #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0   0x2003   /* 1.2 */
 
 #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1   0x2004   /* 1.2 */
+# define RX_GTC_MSTR_REQ_STATUS_CHANGE  (1 << 0)
+# define LOCK_ACQUISITION_REQUEST   (1 << 1)
+# define CEC_IRQ(1 << 2)
 
 #define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005   /* 1.2 */
 
@@ -636,6 +639,62 @@
 # define DP_VSC_EXT_CEA_SDP_SUPPORTED  (1 << 6)  /* DP 1.4 */
 # define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7)  /* DP 1.4 */
 
+/* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
+#define CEC_TUNNELING_CAPABILITY0x3000
+# define CEC_TUNNELING_CAPABLE   (1 << 0)
+# define CEC_SNOOPING_CAPABLE(1 << 1)
+# define CEC_MULTIPLE_LA_CAPABLE (1 << 2)
+
+#define CEC_TUNNELING_CONTROL   0x3001
+# define CEC_TUNNELING_ENABLE(1 << 0)
+# define CEC_SNOOPING_ENABLE (1 << 1)
+
+#define CEC_RX_MESSAGE_INFO 0x3002
+# define CEC_RX_MESSAGE_LEN_MASK (0xf << 0)
+# define CEC_RX_MESSAGE_LEN_SHIFT0
+# define CEC_RX_MESSAGE_HPD_STATE(1 << 4)
+# define CEC_RX_MESSAGE_HPD_LOST (1 << 5)
+# define CEC_RX_MESSAGE_ACKED(1 << 6)
+# define CEC_RX_MESSAGE_ENDED(1 << 7)
+
+#define CEC_TX_MESSAGE_INFO 0x3003
+# define CEC_TX_MESSAGE_LEN_MASK (0xf << 0)
+# define CEC_TX_MESSAGE_LEN_SHIFT0
+# define CEC_TX_RETRY_COUNT_MASK (0x7 << 4)
+# define CEC_TX_RETRY_COUNT_SHIFT4
+# define CEC_TX_MESSAGE_SEND (1 << 7)
+
+#define CEC_TUNNELING_IRQ_FLAGS 0x3004
+# define CEC_RX_MESSAGE_INFO_VALID   (1 << 0)
+# define CEC_RX_MESSAGE_OVERFLOW (1 << 1)
+# define CEC_TX_MESSAGE_SENT (1 << 4)
+# define CEC_TX_LINE_ERROR   (1 << 5)
+# define CEC_TX_ADDRESS_NACK_ERROR   (1 << 6)
+# define CEC_TX_DATA_NACK_ERROR  (1 << 7)
+
+#define CEC_LOGICAL_ADDRESS_MASK0x300E /* 0x300F word */
+# define CEC_LOGICAL_ADDRESS_0   (1 << 0)
+# define CEC_LOGICAL_ADDRESS_1   (1 << 1)
+# define CEC_LOGICAL_ADDRESS_2   (1 << 2)
+# define CEC_LOGICAL_ADDRESS_3   (1 << 3)
+# define CEC_LOGICAL_ADDRESS_4   (1 << 4)
+# define CEC_LOGICAL_ADDRESS_5   (1 << 5)
+# define CEC_LOGICAL_ADDRESS_6   (1 << 6)
+# define CEC_LOGICAL_ADDRESS_7   (1 << 7)
+#define CEC_LOGICAL_ADDRESS_MASK_2  0x300F /* 0x300E word */
+# define CEC_LOGICAL_ADDRESS_8   (1 << 0)
+# define CEC_LOGICAL_ADDRESS_9   (1 << 1)
+# define CEC_LOGICAL_ADDRESS_10  (1 << 2)
+# define CEC_LOGICAL_ADDRESS_11  (1 << 3)
+# define CEC_LOGICAL_ADDRESS_12  (1 << 4)
+# define CEC_LOGICAL_ADDRESS_13  (1 << 5)
+# define CEC_LOGICAL_ADDRESS_14  (1 << 6)
+# define CEC_LOGICAL_ADDRESS_15  (1 << 7)
+
+#define CEC_RX_MESSAGE_BUFFER   0x3010
+#define CEC_TX_MESSAGE_BUFFER   0x3020
+#define CEC_MESSAGE_BUFFER_LENGTH 0x10
+
 /* DP 1.2 Sideband message defines */
 /* peer device type - DP 1.2a Table 2-92 */
 #define DP_PEER_DEVICE_NONE0x0
-- 
1.7.9.5

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

drm-tip/drm-tip boot: 114 boots: 3 failed, 109 passed with 2 offline (v4.11-rc7-1959-g3ae84ad0eb45)

[kernelci . org bot]

drm-tip/drm-tip boot: 114 boots: 3 failed, 109 passed with 2 offline 
(v4.11-rc7-1959-g3ae84ad0eb45)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1959-g3ae84ad0eb45/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1959-g3ae84ad0eb45/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc7-1959-g3ae84ad0eb45
Git Commit: 3ae84ad0eb452ff6f94e87dc229b0032c68068d8
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 16 unique boards, 8 SoC families, 25 builds out of 207

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

allmodconfig+CONFIG_OF=n:
minnowboard-max: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/11] drm: parse ycbcr420 vcb block

[Sharma, Shashank]

Regards

Shashank


On 4/8/2017 11:13 PM, Emil Velikov wrote:

Hi Shashank,

On 7 April 2017 at 17:39, Shashank Sharma  wrote:


+   u64 hdmi_420_cap_map = connector->display_info.hdmi.ycbcr420_vcb_map;

 for (i = 0; i < len; i++) {
 struct drm_display_mode *mode;
 mode = drm_display_mode_from_vic_index(connector, db, len, i);
 if (mode) {
+   /*
+* ycbcr420 capability block contains a bitmap which
+* gives the index of such CEA modes in VDB, which can
+* support ycbcr420 sampling output also.
+* For example, if the bit 0 in bitmap is set,
+* first mode in VDB can support ycbcr420 output too.
+*/
+   if (hdmi_420_cap_map & (1 << i))

Since map is u64 you really want to use something like (1ull << i)
here. Otherwise you'll get a 32 bit value, regardless of i.

Thanks Emil, this was a good catch.



+   for (count = 0; count < map_len; count++)
+   map = (db[2 + count] << 8 * count) | map;
+

The above issue is applicable here as well. With a small nitpick the
whole thing will read

map |= (u64)db[2 + count] << (8 * count);

Agree, thanks.



--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -136,6 +136,7 @@ struct drm_scdc {
  struct drm_hdmi_info {
 /** @scdc: sink's scdc support and capabilities */
 struct drm_scdc scdc;
+   u64 ycbcr420_vcb_map;

As pointed by the kbuild robot - you really want to document the field.

Agree, will handle this in next patch set.

Regards,
Emil


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

Re: [PATCH 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Sharma, Shashank]

Regards

Shashank


On 4/10/2017 3:17 PM, Andrzej Hajda wrote:

On 07.04.2017 18:39, Shashank Sharma wrote:

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

Signed-off-by: Shashank Sharma 

Finally I have chances to look at the specs and I am not sure if this
solution fully reflects the specs and is scalable. According to specs
VIC set to 0 in AVIF means "Video Format not documented in CTA-861", ie
it is described by vendor specific data block and vendor specific
infoframe, maybe something else(???).

It says "Video Format not documented in CEA-861 (means this version)"

I suppose ideally during EDID read
there should be recorded info for every mode if it was defined by vendor
extension, or not. This info could be later used by drivers to configure
AVIF and VSIF accordingly.
I don't think this has to do anything with it, we are simply checking if 
the monitor is HDMI 2.0 capable,
coz if it is, it would be complaint to CEA-861-F and it would understand 
the VIC>64. If not && VIC>64, we will send
VIC as 0, coz this VIC is defined in CEA-861-F spec. So I don't see the 
confusion.


You are welcome to suggest, how can we make it more scalable, or improve 
on it. We can always send revised patch set :-)


- Shashank


Anyway as a short-term initial solution it could work.
So:
Reviewed-by: Andrzej Hajda 

  --
Regards
Andrzej


---
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
  drivers/gpu/drm/drm_edid.c| 12 +++-
  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
  drivers/gpu/drm/tegra/sor.c   |  2 +-
  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
  include/drm/drm_edid.h|  3 ++-
  21 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index daf003d..5dc3e95 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
  
-	err = drm_hdmi_avi_infoframe_from_display_mode(, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 3a72967..b70f077 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
  
-	err = drm_hdmi_avi_infoframe_from_display_mode(, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git 

Re: [PATCH 07/11] drm: set output colorspace in AVI infoframe

[Sharma, Shashank]

Regards

Shashank


On 4/12/2017 3:19 PM, Jose Abreu wrote:

Hi Shashank,


On 07-04-2017 17:39, Shashank Sharma wrote:

HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.

As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI infoframes.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c | 40 
  include/drm/drm_edid.h |  5 +
  2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 828b781..a02d35b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4734,6 +4734,46 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
  EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
  
  /**

+ * drm_hdmi_avi_infoframe_set_colorspace() - fill an HDMI AVI infoframe with
+ * colorspace data of the output type
+ *
+ * @frame: HDMI AVI infoframe
+ * @mode: DRM display mode
+ * @hdmi_output: HDMI output colorspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output)
+{
+   switch (hdmi_output) {
+   case DRM_HDMI_OUTPUT_YCBCR444:
+   frame->colorspace = HDMI_COLORSPACE_YUV444;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR422:
+   frame->colorspace = HDMI_COLORSPACE_YUV422;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR420:
+   frame->colorspace = HDMI_COLORSPACE_YUV420;
+   frame->pixel_repeat = 0;

Why only 4:2:0 is set with pixel repetition off? Is this per spec?
Yes, the HDMI 2.0/CEA-861-F mandates the source to turn off pixel 
repetition for YCBCR420 output.

+   break;
+   case DRM_HDMI_OUTPUT_DEFAULT_RGB:
+   frame->colorspace = HDMI_COLORSPACE_RGB;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR_HQ:
+   case DRM_HDMI_OUTPUT_YCBCR_LQ:
+   case DRM_HDMI_OUTPUT_INVALID:

Maybe default to RGB here? I don't know if spec says anything
about sending empty colorspace field.
Actually, by default the enum value for RGB is 0, that's why we were not 
setting this field at all, as there was only RGB output.
case HQ/LQ indicate that user wanted to have YCBCR output (but it should 
have never reached this point), so I am not sure if its

good idea to default to RGB, or is it :) ? lets hear from others too.

- Shashank

Best regards,
Jose Miguel Abreu


+   DRM_ERROR("Invalid HDMI output type\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_set_colorspace);
+
+/**
   * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
   *quantization range information
   * @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index a4d174e7..8980366 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -329,6 +329,7 @@ struct cea_sad {
  struct drm_encoder;
  struct drm_connector;
  struct drm_display_mode;
+enum drm_hdmi_output_type;
  
  void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);

  int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -351,6 +352,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2);
  int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output);
+int
  drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe 
*frame,
const struct drm_display_mode 
*mode);
  void


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

Re: [PATCH 06/11] drm: create hdmi output property

[Sharma, Shashank]

Hello Jose,

Sorry for delay in response, I was on vacation.
Please find my comments inline.

Regards
Shashank
On 4/12/2017 3:28 PM, Jose Abreu wrote:

Hi Shashank,


On 07-04-2017 17:39, Shashank Sharma wrote:

HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
  - RGB
  - YCBCR 444
  - YCBCR 422
  - YCBCR 420

This patch adds a drm property, using which, a userspace
can specify its preference, for the HDMI output type.
The output type enums are similar to the mentioned outputs
above. To handle various subsampling of YCBCR output types,
this property allows two special cases:
  - DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output, with highest
subsampling rate by the source/sink, which can be typically:
  - ycbcr444
  - ycbcr422
  - ycbcr420
  - DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with lowest
subsampling rate supported by source/sink, which can be:
  - ycbcr420
  - ycbcr422
  - ycbcr444

Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.

The HQ/LQ properties are a nice idea

Courtesy Ville :)

but where are you parsing
them (because in patch 07/11 you reject these properties)? Also,
you need to make sure that source and sink supports the color space.
Yes, and that's why its handling is kept in the core driver. If you see 
my I915 patches, I have parsed and handled the HQ and LQ properties in
intel_hdmi_compute_ycbcr_config function. I am rejecting the HQ/LQ in 
07/11, coz by the time we want to set AVI_IF the driver should have picked
the highest/lowest YCBCR mode, and now we should have a definite one out 
of 444,422 or 420.


Do you think it would be a good idea to find the HQ/LQ YCBCR output in 
DRM layer ? In that case it would be difficult if source supports these 
outputs


- Shashank

Best regards,
Jose Miguel Abreu


Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_atomic.c|  2 ++
  drivers/gpu/drm/drm_atomic_helper.c |  4 
  drivers/gpu/drm/drm_connector.c | 31 +++
  include/drm/drm_connector.h | 14 ++
  include/drm/drm_mode_config.h   |  5 +
  5 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f32506a..6ef34dc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1123,6 +1123,8 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 */
if (state->link_status != DRM_LINK_STATUS_GOOD)
state->link_status = val;
+   } else if (property == config->hdmi_output_property) {
+   state->hdmi_output = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8be9719..fcba3c0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -567,6 +567,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->hdmi_output !=
+   new_connector_state->hdmi_output)
+   new_crtc_state->connectors_changed = true;
}
  
  		if (funcs->atomic_check)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9f84761..10201b1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -227,6 +227,11 @@ int drm_connector_init(struct drm_device *dev,
  config->edid_property,
  0);
  
+	if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)

+   drm_object_attach_property(>base,
+  config->hdmi_output_property,
+  0);
+
drm_object_attach_property(>base,
  config->dpms_property, 0);
  
@@ -617,6 +622,25 @@ static const struct drm_prop_enum_list drm_link_status_enum_list[] = {

  };
  DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
  
+static const struct drm_prop_enum_list drm_hdmi_output_enum_list[] = {

+   { DRM_HDMI_OUTPUT_DEFAULT_RGB, "output_rgb" },
+   { DRM_HDMI_OUTPUT_YCBCR422, "output_ycbcr422" },
+   { 

Re: [PATCH v4.1 01/9] drm/atomic: Handle aspect ratio and scaling mode in core, v2.

[Daniel Vetter]

On Thu, Apr 13, 2017 at 11:15:37AM +0200, Maarten Lankhorst wrote:
> This is required to for i915 to convert connector properties to atomic.
> 
> Changes since v1:
> - Add docbook info. (danvet)
> - Change picture_aspect_ratio to enum hdmi_picture_aspect.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: dri-devel@lists.freedesktop.org
> Acked-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_atomic.c |  8 
>  include/drm/drm_connector.h  | 16 
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 30229ab719c0..25ea6f797a54 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1123,6 +1123,10 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>*/
>   if (state->link_status != DRM_LINK_STATUS_GOOD)
>   state->link_status = val;
> + } else if (property == config->aspect_ratio_property) {
> + state->picture_aspect_ratio = val;
> + } else if (property == config->scaling_mode_property) {
> + state->scaling_mode = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1199,6 +1203,10 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->tv.hue;
>   } else if (property == config->link_status_property) {
>   *val = state->link_status;
> + } else if (property == config->aspect_ratio_property) {
> + *val = state->picture_aspect_ratio;
> + } else if (property == config->scaling_mode_property) {
> + *val = state->scaling_mode;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 4eeda120e46d..5b50bc2db6fb 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -25,6 +25,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -326,6 +327,21 @@ struct drm_connector_state {
>   struct drm_atomic_state *state;
>  
>   struct drm_tv_connector_state tv;
> +
> + /**
> +  * @picture_aspect_ratio: Connector property to control the
> +  * HDMI infoframe aspect ratio setting.
> +  *
> +  * The DRM_MODE_PICTURE_ASPECT_* values much match the

I think the above will upset sphinx and spew a warning, you need
ASPECT_\* or something like that. Or just spell them out and enumerate
them all. Fixed either way this is

Reviewed-by: Daniel Vetter 

> +  * values for  hdmi_picture_aspect
> +  */
> + enum hdmi_picture_aspect picture_aspect_ratio;
> +
> + /**
> +  * @scaling_mode: Connector property to control the
> +  * upscaling, mostly used for built-in panels.
> +  */
> + unsigned int scaling_mode;
>  };
>  
>  /**
> -- 
> 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

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

[bugzilla-daemon]

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

--- Comment #48 from russianneuroman...@ya.ru ---
Issue is still reproducible with Linux 4.11rc7 and Mesa 17.2-git.

-- 
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 100591] [AMD APU A9-9410] Kernel hang when using graphics acceleration

[bugzilla-daemon]

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

--- Comment #7 from Alex Deucher  ---
https://patchwork.kernel.org/patch/9669611/

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

Re: [PATCH] drm: i915: Avoid format string expansion from engine names

[Jani Nikula]

On Tue, 11 Apr 2017, Kees Cook  wrote:
> While highly unlikely, this makes sure that the string built from
> engine names won't be processed as a format string.
>
> Signed-off-by: Kees Cook 

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

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/intel_hangcheck.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index f05971f5586f..be3550cec8e4 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -407,7 +407,7 @@ static void hangcheck_declare_hang(struct 
> drm_i915_private *i915,
>"%s, ", engine->name);
>   msg[len-2] = '\0';
>  
> - return i915_handle_error(i915, hung, msg);
> + return i915_handle_error(i915, hung, "%s", msg);
>  }
>  
>  /*
> -- 
> 2.7.4

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

Re: [PATCH 1/6] drm: Add writeback connector type

[Brian Starkey]

On Wed, Apr 19, 2017 at 01:34:34PM +0200, Boris Brezillon wrote:

On Wed, 19 Apr 2017 10:51:23 +0100
Brian Starkey  wrote:


[snip]


Could you expand a bit on how you think planes fit better?


Just had the impression that the writeback feature was conceptually
closer to a plane object (which is attached buffers and expose ways to
specify which portion of the buffer should be used, provides way to
atomically switch 2 buffers, ...).


Yeah sort-of, except that SRC_X/Y/W/H doesn't mean the same for an
"output" plane as an "input" plane (and CRTC_X/Y/W/H similarly,
probably other properties too).

In atomic land, the swapping of buffers is really just the swapping of
object IDs via properties - I don't think planes actually have
anything special in terms of buffer handling, except for all the
legacy state handling cruft.




It is
something we've previously talked about internally, but so far I'm not
convinced :-)


Okay, as I said, I don't know all the history, hence my questions ;-).



I think that history was here in our office rather than on the list
anyway.



>By doing that, we would also get rid of these fake connector/encoder
>objects as well as the fake modes we are returning in
>connector->get_modes().

What makes the connector/encoder fake? They represent a real piece of
hardware just the same as a drm_plane would.


Well, that's probably subject to interpretation, but I don't consider
these writeback encoders/connectors as real encoders/connectors. They
are definitely real HW blocks, but not what we usually consider as an
encoder/connector.



This is true



I don't mind dropping the mode list and letting userspace just make
up whatever timing it wants - it'd need to do the same if writeback
was a plane - but in some respects giving it a list of modes the same
way we normally do seems nicer for userspace.

>
>As far as I can tell, the VC4 and Atmel HLCDC IP should fit pretty well
>in this model, not sure about the mali-dp though.
>
>Brian, did you consider this approach, and if you did, can you detail
>why you decided to expose this feature as a connector?
>
>Daniel (or anyone else), please step in if you think this is a stupid
>idea :-).

Ville originally suggested using a connector, which Eric followed up
by saying that's what he was thinking of for VC4 writeback too[1].


Thanks for the pointer.


That was my initial reason for focussing on a connector-based
approach.

I prefer connector over plane conceptually because it keeps with the
established data flow: planes are sources, connectors are sinks.


Okay, it's a valid point.



In some respects the plane _object_ looks like it would fit - it has a
pixel format list and an FB_ID. But everything else would be acting
the exact opposite to a normal plane, and I think there's a bunch of
baked-in assumptions in the kernel and userspace around CRTCs always
having at least one connector.


Yep, but writeback connectors are already different enough to not be
considered as regular connectors, so userspace programs will have to
handle them differently anyway (pass a framebuffer and pixel format to
it before adding them to the display pipeline).

Anyway, I see this approach has already been suggested in [1], and you
all agreed that the writeback feature should be exposed as a connector,
so I'll just stop here :-).

Thanks for taking the time to explain the rationale behind this
decision.



No problem, now is the right time to be discussing the decision before
we merge something wrong.

Are you happy enough with the connector approach then? Any concerns
with going ahead with it?

Cheers,
-Brian

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

Re: [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list

[Laurent Pinchart]

Hi Daniel,

On Wednesday 19 Apr 2017 10:36:55 Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote:
> > Most of the items have been taken care of by a clean up series. Remove
> > the completed items and add a few new ones.
> > 
> > Signed-off-by: Laura Abbott 
> > ---
> > 
> >  drivers/staging/android/TODO | 21 -
> >  1 file changed, 4 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> > index 8f3ac37..5f14247 100644
> > --- a/drivers/staging/android/TODO
> > +++ b/drivers/staging/android/TODO
> > 
> > @@ -7,23 +7,10 @@ TODO:
> >  ion/
> > 
> > - - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel
> > internal -   interface on top of dma-buf. flush_for_device needs to be
> > added to dma-buf -   first.
> > - - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in
> > some -   vendor trees. Should be replaced with an ioctl on the dma-buf to
> > expose the -   begin/end_cpu_access hooks to userspace.
> > - - Clarify the tricks ion plays with explicitly managing coherency behind
> > the -   dma api's back (this is absolutely needed for high-perf gpu
> > drivers): Add an -   explicit coherency management mode to
> > flush_for_device to be used by drivers -   which want to manage caches
> > themselves and which indicates whether cpu caches -   need flushing.
> > - - With those removed there's probably no use for ION_IOC_IMPORT anymore
> > either -   since ion would just be the central allocator for shared
> > buffers. - - Add dt-binding to expose cma regions as ion heaps, with the
> > rule that any -   such cma regions must already be used by some device
> > for dma. I.e. ion only -   exposes existing cma regions and doesn't
> > reserve unecessarily memory when -   booting a system which doesn't use
> > ion.
> > + - Add dt-bindings for remaining heaps (chunk and carveout heaps). This
> > would +   involve putting appropriate bindings in a memory node for Ion
> > to find. + - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
> > + - Better test framework (integration with VGEM was suggested)
> 
> Found another one: Integrate the ion kernel-doc into
> Documenation/gpu/ion.rst and link it up within Documenation/gpu/index.rst.

If ion is a generic-purpose allocator, should its documentation really reside 
in Documentation/gpu/ ?

> There's a lot of api and overview stuff already around, would be great to
> make this more accessible.
> 
> But I wouldn't put this as a de-staging blocker, just an idea.
> 
> On the series: Acked-by: Daniel Vetter 
> 
> No full review since a bunch of stuff I'm not too familiar with, but I
> like where this is going.
> -Daniel
> 
> >  Please send patches to Greg Kroah-Hartman  and Cc:
> >  Arve Hjønnevåg  and Riley Andrews
> >  

-- 
Regards,

Laurent Pinchart

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

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings (v4.11-rc7-1959-g3ae84ad0eb45)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings 
(v4.11-rc7-1959-g3ae84ad0eb45)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1959-g3ae84ad0eb45/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc7-1959-g3ae84ad0eb45
Git Commit: 3ae84ad0eb452ff6f94e87dc229b0032c68068d8
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1342:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 
bytes is larger than 2048 bytes [-Wframe-larger-than=]



Detailed per-defconfig build reports:


acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


allmodconfig (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches


allmodconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches


allmodconfig+CONFIG_OF=n (x86) — PASS, 0 errors, 0 warnings, 0 section 
mismatches


allnoconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


allnoconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches


allnoconfig (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches


allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches


am200epdkit_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


ar7_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches


aspeed_g4_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


aspeed_g5_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Gerd Hoffmann]

  Hi,

> > >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
> > >> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
> > >> native endian packed colour values.  
> > > 
> > > Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get
> > > DRM_FORMAT_XRGB (only DRM_IOCTL_MODE_ADDFB2 allows userspace specify
> > > fourcc formats directly).  
> > 
> > Right, and since all major Xorg drivers use DRM_IOCTL_MODE_ADDFB,
> > they're effectively using DRM_FORMAT_XRGB as native endianness as well.
> 
> I sincerely hope this doesn't actually force us into a place where we
> have XRGB (and ARGB?) as native-endian, but the other format
> codes - since being used explicitly - must be kept as little-endian
> because they were used like that honouring the documentation we have
> atm.

My expectation is that the other formats are (almost) unused in
practice.  cairo for example supports XRGB + ARGB (native
endian) only from all depth/bpp 24/32 formats.

IIRC there was a brief discussion how we should handle endianness in
qemu stdvga / bochsdrm.ko before we've added the new (virtual) hardware
register to switch endianness.  The idea to simply run with fixed
endianness (framebuffer is always little endian) was shot down quickly
with the argument that this isn't going to fly due to lack of support
for XRGB in non-native byte order in the whole graphics stack.

> It's starting to resemble the wl_shm format codes problem we have
> on Wayland for BE.
> 
> Has this now turned into a question of what the kernel drivers do
> with the DRM pixel format codes?
> 
> Hmm, I suppose that has been the question all along...

Yep, basically.  I have the impression that drivers are either consider
those formats being native endian or simply don't care because they are
never used in systems with bigendian (-capable) cpus.

Anyone aware of anything else?

Guess I'll go prepare a new version of the patch, declaring all rgb
formats as native endian and putting a bunch of points from this thread
into the commit message.

cheers,
  Gerd

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

Re: [rfc repost] drm sync objects - a new beginning (make ickle happier?)

[Christian König]

Am 13.04.2017 um 03:41 schrieb Dave Airlie:

Okay I've taken Chris's suggestions to heart and reworked things
around a sem_file to see how they might look.

This means the drm_syncobj are currently only useful for semaphores,
the flags field could be used in future to use it for other things,
and we can reintroduce some of the API then if needed.

This refactors sync_file first to add some basic rcu wrappers
about the fence pointer, as this point never updates this should
all be fine unlocked.

It then creates the sem_file with a mutex, and uses that to
track the semaphores with reduced fops and the replace and
get APIs.

Then it reworks the drm stuff on top, and fixes amdgpu bug
with old_fence.

Let's see if anyone prefers one approach over the other.


Yeah, I clearly prefer keeping only one object type for synchronization 
in the kernel.


As I wrote in the other mail the argument of using the sync file for 
semaphores was to be able to use it as in fence with the atomic mode 
setting as well.


That a wait consumes a previous signal should be a specific behavior of 
the operation and not the property of the object.


In other words I'm fine with using the sync_file in a 1:1 fashion with 
Vulkan, but for the atomic API we probably want 1:N to be able to flip a 
rendering result on multiple CRTCs at the same time.


Regards,
Christian.



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



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

[Bug 100712] ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770

[bugzilla-daemon]

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

--- Comment #5 from Julien Isorce  ---
(In reply to Michel Dänzer from comment #4)
> (In reply to Julien Isorce from comment #0)
> > In kernel radeon_object.c::radeon_bo_list_validate, once "bytes_moved >
> > bytes_moved_threshold" is reached (this is the case for 850 bo in the same
> > list_for_each_entry loop), I can see that radeon_ib_schedule emits a fence
> > that it takes more than the radeon.lockup_timeout to be signaled.
> 
> radeon_ib_schedule is called for submitting the command stream from
> userspace, not for any BO moves directly, right?
> 
> How did you determine that this hang is directly related to bytes_moved /
> bytes_moved_threshold? Maybe it's only indirectly related, e.g. due to the
> threshold preventing a BO from being moved to VRAM despite userspace's
> preference.
> 

I added a trace and the fence that is not signaled on time is always the one
emited by radeon_ib_schedule after that the bytes_moved_threshold is reached.
But you are right it could be only indirectly related.

Here is the sequence I have:

ioctl_radeon_cs
  radeon_bo_list_validate
bytes_moved > bytes_moved_threshold(=1024*1024ull)
800 bo are not moved from gtt to vram because of that.
  radeon_cs_ib_vm_chunk
radeon_ib_schedule(rdev, >ib, NULL, true);
  radeon_fence_emit on ring 0
  r600_mmio_hdp_flush
/ioctl_radeon_cs

Then anything calling ttm_bo_wait will block more than the
radeon.lockup_timeout because the above fence is not signaled on time.
Could it be that something is not flushed properly ? (ref:
https://patchwork.kernel.org/patch/5807141/ ? tlb_flush ?) 

Are you saying that some bos are required to be moved from gtt to vram in order
for this fence to be signaled ?

As you can see above it happens when vram_usage >= half_vram so
radeon_bo_get_threshold_for_moves returns 1024*1024, which explains why only 1
or 2 bos can be moved from gtt to vram in that case and why all others are
forced to stay in gtt.

In the same run of radeon_bo_list_validate there are many calls to
ttm_bo_validate with both domain and current_domain as VRAM, this is the case
for around 400 bo. Maybe this cause delay for this fence to be signaled,
providing vram usage is high too.

> 
> > Also it seems the fence is signaled by swapper after more than 10 seconds
> > but it is too late. I requires to reduce the "15" param above to 4 to see
> > that.
> 
> How does "swapper" (what is that exactly?) signal the fence?

My wording was wrong sorry, I should have said "the first entity noticing that
the fence is signaled" by calling radeon_fence_activity. swapper is the name
for process 0 (idle). I change drm logging to print process name and id:
(current->comm, current->pid)

> 
> It might be worth looking into why this happens, though. If domain ==
> current_domain == RADEON_GEM_DOMAIN_VRAM, I wouldn't expect ttm_bo_validate
> to trigger a blit.

I will check though I think I get just confused by a previous trace.

-- 
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 3/7] sync_file: split out fence_file base class from sync_file.

[Christian König]

Am 13.04.2017 um 03:41 schrieb Dave Airlie:

From: Dave Airlie 

This just splits out a common base object to be shared
between sync_file and sem_files.


I don't think I like that approach.

A good argument of using sync_file instead of self coding it was to be 
able to be able to use the resulting fd with the atomic mode setting IOCTLs.


That advantage will completely vanish if we introduce a new fd type.

Regards,
Christian.


Signed-off-by: Dave Airlie 
---
  drivers/dma-buf/sync_file.c  | 49 +++-
  drivers/gpu/drm/drm_atomic.c |  4 ++--
  include/linux/sync_file.h| 17 ++-
  3 files changed, 44 insertions(+), 26 deletions(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 9b7ad7e..2342d8b 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -28,17 +28,28 @@
  
  static const struct file_operations sync_file_fops;
  
+static int fence_file_init(struct fence_file *fence_file,

+  const struct file_operations *fops)
+{
+   fence_file->file = anon_inode_getfile("fence_file", fops,
+fence_file, 0);
+   if (IS_ERR(fence_file->file))
+   return PTR_ERR(fence_file->file);
+   return 0;
+}
+
  static struct sync_file *sync_file_alloc(void)
  {
struct sync_file *sync_file;
+   int ret;
  
  	sync_file = kzalloc(sizeof(*sync_file), GFP_KERNEL);

if (!sync_file)
return NULL;
  
-	sync_file->file = anon_inode_getfile("sync_file", _file_fops,

-sync_file, 0);
-   if (IS_ERR(sync_file->file))
+   ret = fence_file_init(_file->base,
+ _file_fops);
+   if (ret)
goto err;
  
  	init_waitqueue_head(_file->wq);

@@ -67,7 +78,7 @@ static void fence_check_cb_func(struct dma_fence *f, struct 
dma_fence_cb *cb)
   *
   * Creates a sync_file containg @fence. This function acquires and additional
   * reference of @fence for the newly-created _file, if it succeeds. The
- * sync_file can be released with fput(sync_file->file). Returns the
+ * sync_file can be released with fput(sync_file->base.file). Returns the
   * sync_file or NULL in case of error.
   */
  struct sync_file *sync_file_create(struct dma_fence *fence)
@@ -78,7 +89,7 @@ struct sync_file *sync_file_create(struct dma_fence *fence)
if (!sync_file)
return NULL;
  
-	RCU_INIT_POINTER(sync_file->fence, dma_fence_get(fence));

+   RCU_INIT_POINTER(sync_file->base.fence, dma_fence_get(fence));
  
  	snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",

 fence->ops->get_driver_name(fence),
@@ -122,8 +133,8 @@ struct dma_fence *sync_file_get_fence(int fd)
if (!sync_file)
return NULL;
  
-	fence = dma_fence_get(rcu_dereference_protected(sync_file->fence, 1));

-   fput(sync_file->file);
+   fence = dma_fence_get(rcu_dereference_protected(sync_file->base.fence, 
1));
+   fput(sync_file->base.file);
  
  	return fence;

  }
@@ -141,7 +152,7 @@ static int sync_file_set_fence(struct sync_file *sync_file,
 * we own the reference of the dma_fence_array creation.
 */
if (num_fences == 1) {
-   RCU_INIT_POINTER(sync_file->fence, fences[0]);
+   RCU_INIT_POINTER(sync_file->base.fence, fences[0]);
kfree(fences);
} else {
array = dma_fence_array_create(num_fences, fences,
@@ -150,7 +161,7 @@ static int sync_file_set_fence(struct sync_file *sync_file,
if (!array)
return -ENOMEM;
  
-		RCU_INIT_POINTER(sync_file->fence, >base);

+   RCU_INIT_POINTER(sync_file->base.fence, >base);
}
  
  	return 0;

@@ -159,7 +170,7 @@ static int sync_file_set_fence(struct sync_file *sync_file,
  static struct dma_fence **get_fences(struct sync_file *sync_file,
 int *num_fences)
  {
-   struct dma_fence *fence = rcu_dereference_protected(sync_file->fence, 
1);
+   struct dma_fence *fence = 
rcu_dereference_protected(sync_file->base.fence, 1);
if (dma_fence_is_array(fence)) {
struct dma_fence_array *array = to_dma_fence_array(fence);
  
@@ -168,7 +179,7 @@ static struct dma_fence **get_fences(struct sync_file *sync_file,

}
  
  	*num_fences = 1;

-   return _file->fence;
+   return _file->base.fence;
  }
  
  static void add_fence(struct dma_fence **fences,

@@ -271,7 +282,7 @@ static struct sync_file *sync_file_merge(const char *name, 
struct sync_file *a,
return sync_file;
  
  err:

-   fput(sync_file->file);
+   fput(sync_file->base.file);
return NULL;
  
  }

@@ -281,7 +292,7 @@ static int sync_file_release(struct inode *inode, struct 
file *file)
struct sync_file 

drm-tip/drm-tip boot: 86 boots: 3 failed, 81 passed with 2 offline (v4.11-rc7-1958-g05040c47d415)

[kernelci . org bot]

drm-tip/drm-tip boot: 86 boots: 3 failed, 81 passed with 2 offline 
(v4.11-rc7-1958-g05040c47d415)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1958-g05040c47d415/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1958-g05040c47d415/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc7-1958-g05040c47d415
Git Commit: 05040c47d415b1621c0d64e40c0062890b854c9f
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 14 unique boards, 7 SoC families, 24 builds out of 207

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

allmodconfig+CONFIG_OF=n:
minnowboard-max: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] drm: Add writeback connector type

[Boris Brezillon]

On Wed, 19 Apr 2017 10:51:23 +0100
Brian Starkey  wrote:

> On Tue, Apr 18, 2017 at 09:57:17PM +0200, Boris Brezillon wrote:
> >Hi Brian,
> >
> >On Tue, 18 Apr 2017 18:34:43 +0100
> >Brian Starkey  wrote:
> >  
> >> >> @@ -214,6 +214,19 @@ struct drm_connector_state {
> >> >> struct drm_encoder *best_encoder;
> >> >>
> >> >> struct drm_atomic_state *state;
> >> >> +
> >> >> +   /**
> >> >> +* @writeback_job: Writeback job for writeback connectors
> >> >> +*
> >> >> +* Holds the framebuffer for a writeback connector. As the 
> >> >> writeback
> >> >> +* completion may be asynchronous to the normal commit cycle, 
> >> >> the
> >> >> +* writeback job lifetime is managed separately from the normal 
> >> >> atomic
> >> >> +* state by this object.
> >> >> +*
> >> >> +* See also: drm_writeback_queue_job() and
> >> >> +* drm_writeback_signal_completion()
> >> >> +*/
> >> >> +   struct drm_writeback_job *writeback_job;  
> >> >
> >> >Maybe I'm wrong, but is feels weird to have the writeback_job field
> >> >directly embedded in drm_connector_state, while drm_writeback_connector
> >> >inherits from drm_connector.
> >> >
> >> >IMO, either you decide to directly put the drm_writeback_connector's
> >> >job_xxx fields in drm_connector and keep the drm_connector_state as is,
> >> >or you create a drm_writeback_connector_state which inherits from
> >> >drm_connector_state and embeds the writeback_job field.  
> >>
> >> I did spend a decent amount of time looking at tracking the writeback
> >> state along with the normal connector state. I couldn't come up with
> >> anything I liked.
> >>
> >> As the comment mentions, one of the problems is that you have to make
> >> sure the relevant parts of the connector_state stay around until the
> >> writeback is finished. That means you've got to block before
> >> "swap_state()" until the previous writeback is done, and that
> >> effectively limits your frame rate to refresh/2.
> >>
> >> The Mali-DP HW doesn't have that limitation - we can queue up a new
> >> commit while the current writeback is ongoing. For that reason I
> >> didn't want to impose such a limitation in the framework.
> >>
> >> In v1 I allowed that by making the Mali-DP driver hold its own
> >> references to the relevant bits of the state for as long as it needed
> >> them. In v3 I moved most of that code back to the core (in part
> >> because Gustavo didn't like me signalling the DRM-"owned" fence from
> >> my driver code directly). I think the new approach of "queue_job()"
> >> and "signal_job()" reduces the amount of tricky code in drivers, and
> >> is generally more clear (also familiar, when compared to vsync
> >> events).
> >>
> >> I'm certain there's other ways to do it (refcount atomic states?), but
> >> it seemed like a biggish overhaul to achieve what would basically be
> >> the same thing.
> >>
> >> I was expecting each driver supporting writeback to have its own
> >> different requirements around writeback lifetime/duration. For example
> >> I think VC4 specifically came up, in that its writeback could take
> >> several frames, whereas on Mali-DP we either finish within the frame
> >> or we fail.
> >>
> >> Letting the driver manage its writeback_job lifetime seemed like a
> >> reasonable way to handle all that, with the documentation stating the
> >> only behaviour which is guaranteed to work on all drivers:
> >>
> >>* Userspace should wait for this fence to signal before making 
> >> another
> >>* commit affecting any of the same CRTCs, Planes or Connectors.
> >>* **Failure to do so will result in undefined behaviour.**
> >>* For this reason it is strongly recommended that all userspace
> >>* applications making use of writeback connectors *always* retrieve 
> >> an
> >>* out-fence for the commit and use it appropriately.
> >>
> >>
> >>
> >> ... so all of that is why the _job fields don't live in a *_state
> >> structure directly, and instead have to live in the separately-managed
> >> structure pointed to by ->writeback_job.
> >>
> >> Now, I did look at creating drm_writeback_connector_state, but as it
> >> would only be holding the job pointer (see above) it didn't seem worth
> >> scattering around the
> >>
> >> if (conn_state->connector->connector_type ==
> >> DRM_MODE_CONNECTOR_WRITEBACK)
> >>
> >> checks everywhere before up-casting - {clear,reset,duplicate}_state(),
> >> prepare_signalling(), complete_signalling(), etc. It just touched a
> >> lot of code for the sake of an extra pointer field in each connector
> >> state.
> >>
> >> I can easily revisit that part if you like.  
> >
> >I think there's a misunderstanding. I was just suggesting to be
> >consistent in the inheritance vs 'one object to handle everything'
> >approach.  
> 
> doh.. right yeah I misread. Sorry for the tangent. :-)
> 

[Bug 96296] clpeak causes a GPU hang

[bugzilla-daemon]

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

--- Comment #7 from ricardo.riba...@gmail.com ---
Created attachment 130914
  --> https://bugs.freedesktop.org/attachment.cgi?id=130914=edit
AMD PALM (DRM 2.49.0 / 4.10.0-qtec-standard, LLVM 4.0.1 + MESA 17.0.3

-- 
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 96296] clpeak causes a GPU hang

[bugzilla-daemon]

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

--- Comment #6 from ricardo.riba...@gmail.com ---
Using llvm 4.0.1 and the latest git commit from libclc (
17648cd846390e294feafef21c32c7106eac1e24 ):

I am getting a cpu endless loop with clpeak, fixable with ctrl+c.

Other samples, such as Matrix Multiply work fine.

CLOVER_DEBUG=llvm,asm,clc CLOVER_OUTPUT=clover.out clpeak >dump 2>dump.err

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

drm-tip/drm-tip boot: 16 boots: 2 failed, 14 passed (v4.11-rc7-1957-g06b36a78fe41)

[kernelci . org bot]

drm-tip/drm-tip boot: 16 boots: 2 failed, 14 passed 
(v4.11-rc7-1957-g06b36a78fe41)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1957-g06b36a78fe41/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1957-g06b36a78fe41/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc7-1957-g06b36a78fe41
Git Commit: 06b36a78fe41d6a39f6e2d3fb6083d11ccd402f5
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 9 unique boards, 3 SoC families, 10 builds out of 207

Boot Failures Detected:

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] drm: Add writeback connector type

[Brian Starkey]

On Tue, Apr 18, 2017 at 09:57:17PM +0200, Boris Brezillon wrote:

Hi Brian,

On Tue, 18 Apr 2017 18:34:43 +0100
Brian Starkey  wrote:


>> @@ -214,6 +214,19 @@ struct drm_connector_state {
>>struct drm_encoder *best_encoder;
>>
>>struct drm_atomic_state *state;
>> +
>> +  /**
>> +   * @writeback_job: Writeback job for writeback connectors
>> +   *
>> +   * Holds the framebuffer for a writeback connector. As the writeback
>> +   * completion may be asynchronous to the normal commit cycle, the
>> +   * writeback job lifetime is managed separately from the normal atomic
>> +   * state by this object.
>> +   *
>> +   * See also: drm_writeback_queue_job() and
>> +   * drm_writeback_signal_completion()
>> +   */
>> +  struct drm_writeback_job *writeback_job;
>
>Maybe I'm wrong, but is feels weird to have the writeback_job field
>directly embedded in drm_connector_state, while drm_writeback_connector
>inherits from drm_connector.
>
>IMO, either you decide to directly put the drm_writeback_connector's
>job_xxx fields in drm_connector and keep the drm_connector_state as is,
>or you create a drm_writeback_connector_state which inherits from
>drm_connector_state and embeds the writeback_job field.

I did spend a decent amount of time looking at tracking the writeback
state along with the normal connector state. I couldn't come up with
anything I liked.

As the comment mentions, one of the problems is that you have to make
sure the relevant parts of the connector_state stay around until the
writeback is finished. That means you've got to block before
"swap_state()" until the previous writeback is done, and that
effectively limits your frame rate to refresh/2.

The Mali-DP HW doesn't have that limitation - we can queue up a new
commit while the current writeback is ongoing. For that reason I
didn't want to impose such a limitation in the framework.

In v1 I allowed that by making the Mali-DP driver hold its own
references to the relevant bits of the state for as long as it needed
them. In v3 I moved most of that code back to the core (in part
because Gustavo didn't like me signalling the DRM-"owned" fence from
my driver code directly). I think the new approach of "queue_job()"
and "signal_job()" reduces the amount of tricky code in drivers, and
is generally more clear (also familiar, when compared to vsync
events).

I'm certain there's other ways to do it (refcount atomic states?), but
it seemed like a biggish overhaul to achieve what would basically be
the same thing.

I was expecting each driver supporting writeback to have its own
different requirements around writeback lifetime/duration. For example
I think VC4 specifically came up, in that its writeback could take
several frames, whereas on Mali-DP we either finish within the frame
or we fail.

Letting the driver manage its writeback_job lifetime seemed like a
reasonable way to handle all that, with the documentation stating the
only behaviour which is guaranteed to work on all drivers:

   * Userspace should wait for this fence to signal before making another
   * commit affecting any of the same CRTCs, Planes or Connectors.
   * **Failure to do so will result in undefined behaviour.**
   * For this reason it is strongly recommended that all userspace
   * applications making use of writeback connectors *always* retrieve an
   * out-fence for the commit and use it appropriately.



... so all of that is why the _job fields don't live in a *_state
structure directly, and instead have to live in the separately-managed
structure pointed to by ->writeback_job.

Now, I did look at creating drm_writeback_connector_state, but as it
would only be holding the job pointer (see above) it didn't seem worth
scattering around the

if (conn_state->connector->connector_type ==
DRM_MODE_CONNECTOR_WRITEBACK)

checks everywhere before up-casting - {clear,reset,duplicate}_state(),
prepare_signalling(), complete_signalling(), etc. It just touched a
lot of code for the sake of an extra pointer field in each connector
state.

I can easily revisit that part if you like.


I think there's a misunderstanding. I was just suggesting to be
consistent in the inheritance vs 'one object to handle everything'
approach.


doh.. right yeah I misread. Sorry for the tangent. :-)



I'm perfectly fine with embedding the writeback_job pointer directly in
drm_connector_state, but then it would IMO make more sense to do the
same for the drm_connector object (embed drm_writeback_connector fields
into drm_connector instead of making drm_writeback_connector inherit
from drm_connector).



I agree that it's inconsistent. I guess I did it out of pragmatism -
there's quite a lot of new fields in drm_writeback_connector, and the
code needed to support it was comparatively small. On the other hand
there's only one additional field in drm_connector_state and the code
required to subclass 

Re: [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list

[Daniel Vetter]

On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote:
> Most of the items have been taken care of by a clean up series. Remove
> the completed items and add a few new ones.
> 
> Signed-off-by: Laura Abbott 
> ---
>  drivers/staging/android/TODO | 21 -
>  1 file changed, 4 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> index 8f3ac37..5f14247 100644
> --- a/drivers/staging/android/TODO
> +++ b/drivers/staging/android/TODO
> @@ -7,23 +7,10 @@ TODO:
>  
>  
>  ion/
> - - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel 
> internal
> -   interface on top of dma-buf. flush_for_device needs to be added to dma-buf
> -   first.
> - - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in some
> -   vendor trees. Should be replaced with an ioctl on the dma-buf to expose 
> the
> -   begin/end_cpu_access hooks to userspace.
> - - Clarify the tricks ion plays with explicitly managing coherency behind the
> -   dma api's back (this is absolutely needed for high-perf gpu drivers): Add 
> an
> -   explicit coherency management mode to flush_for_device to be used by 
> drivers
> -   which want to manage caches themselves and which indicates whether cpu 
> caches
> -   need flushing.
> - - With those removed there's probably no use for ION_IOC_IMPORT anymore 
> either
> -   since ion would just be the central allocator for shared buffers.
> - - Add dt-binding to expose cma regions as ion heaps, with the rule that any
> -   such cma regions must already be used by some device for dma. I.e. ion 
> only
> -   exposes existing cma regions and doesn't reserve unecessarily memory when
> -   booting a system which doesn't use ion.
> + - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
> +   involve putting appropriate bindings in a memory node for Ion to find.
> + - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
> + - Better test framework (integration with VGEM was suggested)

Found another one: Integrate the ion kernel-doc into
Documenation/gpu/ion.rst and link it up within Documenation/gpu/index.rst.
There's a lot of api and overview stuff already around, would be great to
make this more accessible.

But I wouldn't put this as a de-staging blocker, just an idea.

On the series: Acked-by: Daniel Vetter 

No full review since a bunch of stuff I'm not too familiar with, but I
like where this is going.
-Daniel

>  
>  Please send patches to Greg Kroah-Hartman  and Cc:
>  Arve Hjønnevåg  and Riley Andrews 
> -- 
> 2.7.4
> 
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig

-- 
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: [Linaro-mm-sig] [PATCHv4 10/12] staging: android: ion: Remove ion_handle and ion_client

[Daniel Vetter]

On Tue, Apr 18, 2017 at 11:27:12AM -0700, Laura Abbott wrote:
> ion_handle was introduced as an abstraction to represent a reference to
> a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
> emerged as the preferred standard for use in the kernel. This has made
> the ion_handle an unnecessary abstraction and prone to race
> conditions. ion_client is also now only used internally. We have enough
> mechanisms for race conditions and leaks already so just drop ion_handle
> and ion_client. This also includes ripping out most of the debugfs
> infrastructure since much of that was tied to clients and handles.
> The debugfs infrastructure was prone to give confusing data (orphaned
> allocations) so it can be replaced with something better if people
> actually want it.
> 
> Signed-off-by: Laura Abbott 

Yeah I think improving the dma-buf debugfs stuff (maybe with an allocator
callback to dump additional data) is the better option.

Acked-by: Daniel Vetter 
> ---
>  drivers/staging/android/ion/ion-ioctl.c |  53 +--
>  drivers/staging/android/ion/ion.c   | 701 
> ++--
>  drivers/staging/android/ion/ion.h   |  77 +---
>  drivers/staging/android/uapi/ion.h  |  25 +-
>  4 files changed, 51 insertions(+), 805 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion-ioctl.c 
> b/drivers/staging/android/ion/ion-ioctl.c
> index 4e7bf16..76427e4 100644
> --- a/drivers/staging/android/ion/ion-ioctl.c
> +++ b/drivers/staging/android/ion/ion-ioctl.c
> @@ -21,9 +21,7 @@
>  #include "ion.h"
>  
>  union ion_ioctl_arg {
> - struct ion_fd_data fd;
>   struct ion_allocation_data allocation;
> - struct ion_handle_data handle;
>   struct ion_heap_query query;
>  };
>  
> @@ -48,8 +46,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
> ion_ioctl_arg *arg)
>  static unsigned int ion_ioctl_dir(unsigned int cmd)
>  {
>   switch (cmd) {
> - case ION_IOC_FREE:
> - return _IOC_WRITE;
>   default:
>   return _IOC_DIR(cmd);
>   }
> @@ -57,8 +53,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
>  
>  long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>  {
> - struct ion_client *client = filp->private_data;
> - struct ion_handle *cleanup_handle = NULL;
>   int ret = 0;
>   unsigned int dir;
>   union ion_ioctl_arg data;
> @@ -86,61 +80,28 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
> unsigned long arg)
>   switch (cmd) {
>   case ION_IOC_ALLOC:
>   {
> - struct ion_handle *handle;
> + int fd;
>  
> - handle = ion_alloc(client, data.allocation.len,
> + fd = ion_alloc(data.allocation.len,
>   data.allocation.heap_id_mask,
>   data.allocation.flags);
> - if (IS_ERR(handle))
> - return PTR_ERR(handle);
> + if (fd < 0)
> + return fd;
>  
> - data.allocation.handle = handle->id;
> + data.allocation.fd = fd;
>  
> - cleanup_handle = handle;
> - break;
> - }
> - case ION_IOC_FREE:
> - {
> - struct ion_handle *handle;
> -
> - mutex_lock(>lock);
> - handle = ion_handle_get_by_id_nolock(client,
> -  data.handle.handle);
> - if (IS_ERR(handle)) {
> - mutex_unlock(>lock);
> - return PTR_ERR(handle);
> - }
> - ion_free_nolock(client, handle);
> - ion_handle_put_nolock(handle);
> - mutex_unlock(>lock);
> - break;
> - }
> - case ION_IOC_SHARE:
> - {
> - struct ion_handle *handle;
> -
> - handle = ion_handle_get_by_id(client, data.handle.handle);
> - if (IS_ERR(handle))
> - return PTR_ERR(handle);
> - data.fd.fd = ion_share_dma_buf_fd(client, handle);
> - ion_handle_put(handle);
> - if (data.fd.fd < 0)
> - ret = data.fd.fd;
>   break;
>   }
>   case ION_IOC_HEAP_QUERY:
> - ret = ion_query_heaps(client, );
> + ret = ion_query_heaps();
>   break;
>   default:
>   return -ENOTTY;
>   }
>  
>   if (dir & _IOC_READ) {
> - if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd))) {
> - if (cleanup_handle)
> - ion_free(client, cleanup_handle);
> + if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd)))
>   return -EFAULT;
> - }
>   }
>   return ret;
>  }
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 

Re: [Linaro-mm-sig] [PATCHv4 05/12] staging: android: ion: Break the ABI in the name of forward progress

[Daniel Vetter]

On Tue, Apr 18, 2017 at 11:27:07AM -0700, Laura Abbott wrote:
> Several of the Ion ioctls were designed in such a way that they
> necessitate compat ioctls. We're breaking a bunch of other ABIs and
> cleaning stuff up anyway so let's follow the ioctl guidelines and clean
> things up while everyone is busy converting things over anyway. As part
> of this, also remove the useless alignment field from the allocation
> structure.
> 
> Signed-off-by: Laura Abbott 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/staging/android/ion/Makefile |   3 -
>  drivers/staging/android/ion/compat_ion.c | 152 
> ---
>  drivers/staging/android/ion/compat_ion.h |  29 --
>  drivers/staging/android/ion/ion-ioctl.c  |   1 -
>  drivers/staging/android/ion/ion.c|   5 +-
>  drivers/staging/android/uapi/ion.h   |  19 ++--
>  6 files changed, 11 insertions(+), 198 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/compat_ion.c
>  delete mode 100644 drivers/staging/android/ion/compat_ion.h
> 
> diff --git a/drivers/staging/android/ion/Makefile 
> b/drivers/staging/android/ion/Makefile
> index 66d0c4a..a892afa 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -2,6 +2,3 @@ obj-$(CONFIG_ION) +=  ion.o ion-ioctl.o ion_heap.o \
>   ion_page_pool.o ion_system_heap.o \
>   ion_carveout_heap.o ion_chunk_heap.o
>  obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
> -ifdef CONFIG_COMPAT
> -obj-$(CONFIG_ION) += compat_ion.o
> -endif
> diff --git a/drivers/staging/android/ion/compat_ion.c 
> b/drivers/staging/android/ion/compat_ion.c
> deleted file mode 100644
> index 5037ddd..000
> --- a/drivers/staging/android/ion/compat_ion.c
> +++ /dev/null
> @@ -1,152 +0,0 @@
> -/*
> - * drivers/staging/android/ion/compat_ion.c
> - *
> - * Copyright (C) 2013 Google, Inc.
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - */
> -
> -#include 
> -#include 
> -#include 
> -
> -#include "ion.h"
> -#include "compat_ion.h"
> -
> -/* See drivers/staging/android/uapi/ion.h for the definition of these 
> structs */
> -struct compat_ion_allocation_data {
> - compat_size_t len;
> - compat_size_t align;
> - compat_uint_t heap_id_mask;
> - compat_uint_t flags;
> - compat_int_t handle;
> -};
> -
> -struct compat_ion_handle_data {
> - compat_int_t handle;
> -};
> -
> -#define COMPAT_ION_IOC_ALLOC _IOWR(ION_IOC_MAGIC, 0, \
> -   struct compat_ion_allocation_data)
> -#define COMPAT_ION_IOC_FREE  _IOWR(ION_IOC_MAGIC, 1, \
> -   struct compat_ion_handle_data)
> -
> -static int compat_get_ion_allocation_data(
> - struct compat_ion_allocation_data __user *data32,
> - struct ion_allocation_data __user *data)
> -{
> - compat_size_t s;
> - compat_uint_t u;
> - compat_int_t i;
> - int err;
> -
> - err = get_user(s, >len);
> - err |= put_user(s, >len);
> - err |= get_user(s, >align);
> - err |= put_user(s, >align);
> - err |= get_user(u, >heap_id_mask);
> - err |= put_user(u, >heap_id_mask);
> - err |= get_user(u, >flags);
> - err |= put_user(u, >flags);
> - err |= get_user(i, >handle);
> - err |= put_user(i, >handle);
> -
> - return err;
> -}
> -
> -static int compat_get_ion_handle_data(
> - struct compat_ion_handle_data __user *data32,
> - struct ion_handle_data __user *data)
> -{
> - compat_int_t i;
> - int err;
> -
> - err = get_user(i, >handle);
> - err |= put_user(i, >handle);
> -
> - return err;
> -}
> -
> -static int compat_put_ion_allocation_data(
> - struct compat_ion_allocation_data __user *data32,
> - struct ion_allocation_data __user *data)
> -{
> - compat_size_t s;
> - compat_uint_t u;
> - compat_int_t i;
> - int err;
> -
> - err = get_user(s, >len);
> - err |= put_user(s, >len);
> - err |= get_user(s, >align);
> - err |= put_user(s, >align);
> - err |= get_user(u, >heap_id_mask);
> - err |= put_user(u, >heap_id_mask);
> - err |= get_user(u, >flags);
> - err |= put_user(u, >flags);
> - err |= get_user(i, >handle);
> - err |= put_user(i, >handle);
> -
> - return err;
> -}
> -
> -long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> -{
> - long ret;
> -
> - if 

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings (v4.11-rc7-1958-g05040c47d415)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings 
(v4.11-rc7-1958-g05040c47d415)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1958-g05040c47d415/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc7-1958-g05040c47d415
Git Commit: 05040c47d415b1621c0d64e40c0062890b854c9f
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1342:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 
bytes is larger than 2048 bytes [-Wframe-larger-than=]



Detailed per-defconfig build reports:


acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


allmodconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches


allmodconfig (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches


allmodconfig+CONFIG_OF=n (x86) — PASS, 0 errors, 0 warnings, 0 section 
mismatches


allnoconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches


allnoconfig (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches


allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches


allnoconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


am200epdkit_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


ar7_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches


aspeed_g4_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


aspeed_g5_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc7-1957-g06b36a78fe41)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 
warnings (v4.11-rc7-1957-g06b36a78fe41)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1957-g06b36a78fe41/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc7-1957-g06b36a78fe41
Git Commit: 06b36a78fe41d6a39f6e2d3fb6083d11ccd402f5
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failures Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: FAIL
defconfig: FAIL
defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL
defconfig+CONFIG_KASAN=y: FAIL
defconfig+CONFIG_LKDTM=y: FAIL
defconfig+CONFIG_OF_UNITTEST=y: FAIL
defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: FAIL
multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_LKDTM=y: FAIL
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL
multi_v7_defconfig+CONFIG_SMP=n: FAIL
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL
tegra_defconfig: FAIL

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: FAIL
allmodconfig+CONFIG_OF=n: FAIL

Errors and Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: 1 error
defconfig: 1 error
defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error
defconfig+CONFIG_KASAN=y: 1 error, 4 warnings
defconfig+CONFIG_LKDTM=y: 1 error
defconfig+CONFIG_OF_UNITTEST=y: 1 error
defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 
error, 4 warnings
tegra_defconfig: 1 error

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: 1 error
allmodconfig+CONFIG_OF=n: 1 error
defconfig+CONFIG_KASAN=y: 5 warnings

Errors summary:

 20  drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2750:31: error: 
'nv137_chipset' undeclared (first use in this function)

Warnings summary:

  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1342:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 
bytes is larger than 2048 bytes [-Wframe-larger-than=]



Detailed per-defconfig build reports:


acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

[Bug 100591] [AMD APU A9-9410] Kernel hang when using graphics acceleration

[bugzilla-daemon]

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

--- Comment #6 from splitt  ---
Same hang here, same CPU : booting with kernel parameter amd_iommu=off solved
the problem.
For more details, please search for stoney patch disable ATS.

++

-- 
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: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Pekka Paalanen]

On Wed, 19 Apr 2017 10:01:47 +0900
Michel Dänzer  wrote:

> On 18/04/17 07:14 PM, Gerd Hoffmann wrote:
> >   Hi,
> >   
> >>> Quite true that this proves nothing. However one should note that
> >>> fbcon -> fbdev works,  
> >>
> >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
> >> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
> >> native endian packed colour values.  
> > 
> > Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get
> > DRM_FORMAT_XRGB (only DRM_IOCTL_MODE_ADDFB2 allows userspace specify
> > fourcc formats directly).  
> 
> Right, and since all major Xorg drivers use DRM_IOCTL_MODE_ADDFB,
> they're effectively using DRM_FORMAT_XRGB as native endianness as well.

I sincerely hope this doesn't actually force us into a place where we
have XRGB (and ARGB?) as native-endian, but the other format
codes - since being used explicitly - must be kept as little-endian
because they were used like that honouring the documentation we have
atm. It's starting to resemble the wl_shm format codes problem we have
on Wayland for BE.

Has this now turned into a question of what the kernel drivers do
with the DRM pixel format codes?

Hmm, I suppose that has been the question all along... userspace uses
whatever formats that look right, new kernel drivers come along and fix
themselves to work with whatever userspace uses? And the people who get
it wrong are the ones who only ever test on LE and trust the docs...


Thanks,
pq


pgpU_7mHyvzm8.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

[bugzilla-daemon]

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

--- Comment #8 from omegap...@startmail.com ---
For anyone else having this issue, looking through the xrandr output allows you
to make a workaround, for me:

===

xrandr --output DisplayPort-0 --right-of DVI-1

===

is enough to get the correct layout (just one window seems to be consistently
moved to the secondary monitor on top of this, probably as its maximised).

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