Re: [Intel-gfx] [PATCH] drm/i915: Add plane alpha blending support, v2.
Quoting Maarten Lankhorst (2018-10-02 11:51:45)
> Op 23-08-18 om 00:57 schreef Matt Roper:
> > On Wed, Aug 15, 2018 at 12:34:05PM +0200, Maarten Lankhorst wrote:
> >> Add plane alpha blending support with the different blend modes.
> >> This has been tested on a icl to show the correct results,
> >> on earlier platforms small rounding errors cause issues. But this
> >> already happens case with fully transparant or fully opaque RGB
> >> fb's.
> >>
> >> The recommended HW workaround is to disable alpha blending when the
> >> plane alpha is 0 (transparant, hide plane) or 0xff (opaque, disable
> >> blending).
> >> This is easy to implement on any platform, so just do that.
> >>
> >> The tests for userspace are also available, and pass on gen11.
> >>
> >> Changes since v1:
> >> - Change mistaken < 0xff0 to 0xff00.
> >> - Only set PLANE_KEYMSK_ALPHA_ENABLE when plane alpha < 0xff00, ignore
> >> blend mode.
> >> - Rework disabling FBC when per pixel alpha is used.
> >>
> >> Signed-off-by: Maarten Lankhorst
> > One question and one minor suggestion inline below, but otherwise,
> >
> > Reviewed-by: Matt Roper
> >
> >> ---
> >> drivers/gpu/drm/i915/i915_drv.h | 2 +
> >> drivers/gpu/drm/i915/i915_reg.h | 2 +
> >> drivers/gpu/drm/i915/intel_display.c | 58 +++-
> >> drivers/gpu/drm/i915/intel_fbc.c | 8
> >> drivers/gpu/drm/i915/intel_sprite.c | 23 ++-
> >> 5 files changed, 73 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 3fa56b960ef2..29f75da5fa8c 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -545,6 +545,8 @@ struct intel_fbc {
> >> int adjusted_y;
> >>
> >> int y;
> >> +
> >> +uint16_t pixel_blend_mode;
> >> } plane;
> >>
> >> struct {
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index 0c9f03dda569..93a1d87cdeb2 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -6561,8 +6561,10 @@ enum {
> >> #define _PLANE_KEYVAL_2_A 0x70294
> >> #define _PLANE_KEYMSK_1_A 0x70198
> >> #define _PLANE_KEYMSK_2_A 0x70298
> >> +#define PLANE_KEYMSK_ALPHA_ENABLE (1 << 31)
> >> #define _PLANE_KEYMAX_1_A 0x701a0
> >> #define _PLANE_KEYMAX_2_A 0x702a0
> >> +#define PLANE_KEYMAX_ALPHA_SHIFT 24
> >> #define _PLANE_AUX_DIST_1_A 0x701c0
> >> #define _PLANE_AUX_DIST_2_A 0x702c0
> >> #define _PLANE_AUX_OFFSET_1_A 0x701c4
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index a0345e7d3c2b..aedad3674b0d 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -3167,6 +3167,12 @@ int skl_check_plane_surface(const struct
> >> intel_crtc_state *crtc_state,
> >> return -EINVAL;
> >> }
> >>
> >> +/* HW only has 8 bits pixel precision, disable plane if invisible */
> >> +if (!(plane_state->base.alpha >> 8)) {
> >> +plane_state->base.visible = false;
> >> +return 0;
> >> +}
> >> +
> >> if (!plane_state->base.visible)
> >> return 0;
> >>
> >> @@ -3512,30 +3518,39 @@ static u32 skl_plane_ctl_format(uint32_t
> >> pixel_format)
> >> return 0;
> >> }
> >>
> >> -/*
> >> - * XXX: For ARBG/ABGR formats we default to expecting scanout buffers
> >> - * to be already pre-multiplied. We need to add a knob (or a different
> >> - * DRM_FORMAT) for user-space to configure that.
> >> - */
> >> -static u32 skl_plane_ctl_alpha(uint32_t pixel_format)
> >> +static u32 skl_plane_ctl_alpha(const struct intel_plane_state
> >> *plane_state)
> >> {
> >> -switch (pixel_format) {
> >> -case DRM_FORMAT_ABGR:
> >> -case DRM_FORMAT_ARGB:
> >> +if (!plane_state->base.fb->format->has_alpha)
> >> +return PLANE_CTL_ALPHA_DISABLE;
> >> +
> >> +switch (plane_state->base.pixel_blend_mode) {
> >> +case DRM_MODE_BLEND_PIXEL_NONE:
> >> +return PLANE_CTL_ALPHA_DISABLE;
> >> +case DRM_MODE_BLEND_PREMULTI:
> >> return PLANE_CTL_ALPHA_SW_PREMULTIPLY;
> >> +case DRM_MODE_BLEND_COVERAGE:
> >> +return PLANE_CTL_ALPHA_HW_PREMULTIPLY;
> >> default:
> >> -return PLANE_CTL_ALPHA_DISABLE;
> >> +MISSING_CASE(plane_state->base.pixel_blend_mode);
> >> +return 0;
> > Maybe just add the MISSING_CASE line before the current return? The
> > macro still expands to 0, so leaving that makes it slightly more clear
> > what the default fallback is. Same for the glk_ function below.
> >
> >> }
> >> }
> >>
> >> -static
Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote: > These are the approaches which could have been taken to handle > this scenario - > > * Replace vm_insert_page with vmf_insert_page and then write few >extra lines of code to convert VM_FAULT_CODE to errno which >makes driver users more complex ( also the reverse mapping errno to >VM_FAULT_CODE have been cleaned up as part of vm_fault_t migration , >not preferred to introduce anything similar again) > > * Maintain both vm_insert_page and vmf_insert_page and use it in >respective places. But it won't gurantee that vm_insert_page will >never be used in #PF context. > > * Introduce a similar API like vm_insert_page, convert all non #PF >consumer to use it and finally remove vm_insert_page by converting >it to vmf_insert_page. > > And the 3rd approach was taken by introducing vm_insert_kmem_page(). > > In short, vmf_insert_page will be used in page fault handlers > context and vm_insert_kmem_page will be used to map kernel > memory to user vma outside page fault handlers context. As far as I can tell, vm_insert_kmem_page() is line-for-line identical with vm_insert_page(). Seriously, here's a diff I just did: -static int insert_page(struct vm_area_struct *vma, unsigned long addr, - struct page *page, pgprot_t prot) +static int insert_kmem_page(struct vm_area_struct *vma, unsigned long addr, + struct page *page, pgprot_t prot) - /* Ok, finally just insert the thing.. */ -int vm_insert_page(struct vm_area_struct *vma, unsigned long addr, +int vm_insert_kmem_page(struct vm_area_struct *vma, unsigned long addr, - return insert_page(vma, addr, page, vma->vm_page_prot); + return insert_kmem_page(vma, addr, page, vma->vm_page_prot); -EXPORT_SYMBOL(vm_insert_page); +EXPORT_SYMBOL(vm_insert_kmem_page); What on earth are you trying to do? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] video: fbdev: omapfb: lcd_ams_delta: use GPIO lookup table
Now as Amstrad Delta board - the only user of this driver - provides
GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and
use the table to locate required GPIO pins.
Declare static variables for storing GPIO descriptors and replace
gpio_ function calls with their gpiod_ equivalents. Move GPIO lookup
to the driver probe function so device initialization can be deferred
instead of aborted if a GPIO pin is not yet available.
Pin naming used by the driver should be followed while respective GPIO
lookup table is initialized by a board init code.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Linus Walleij
---
Changelog:
v4:
- added Reviewed-by: Linus Walleij
- resubmitted as a standalone patch for inclusion via fbdev tree again
v3:
- rebased on top of v4.19-rc1 with all dependencies mentioned in v2
changelog satisfied
v2/v2:
- resubmitted in a series as [PATCH v2 1/3 v2] for inclusion via omap
tree
v2:
- removed problematic error code conversion no longer needed if used on
top of commit d08605a64e67 ("ARM: OMAP1: ams-delta: move late devices
back to init_machine") and commit 8853daf3b4ac ("gpiolib: Defer on
non-DT find_chip_by_name() failure") already in linux-next
- resubmitted as a standalone patch for inclusion via fbdev tree
Ininally submitted in a series as [PATCH 4/6]
drivers/video/fbdev/omap/lcd_ams_delta.c | 55 +---
1 file changed, 22 insertions(+), 33 deletions(-)
diff --git a/drivers/video/fbdev/omap/lcd_ams_delta.c
b/drivers/video/fbdev/omap/lcd_ams_delta.c
index e8c748a0dfe2..cddbd00cbf9f 100644
--- a/drivers/video/fbdev/omap/lcd_ams_delta.c
+++ b/drivers/video/fbdev/omap/lcd_ams_delta.c
@@ -24,11 +24,10 @@
#include
#include
#include
+#include
#include
-#include
#include
-#include
#include "omapfb.h"
@@ -41,6 +40,8 @@
/* LCD class device section */
static int ams_delta_lcd;
+static struct gpio_desc *gpiod_vblen;
+static struct gpio_desc *gpiod_ndisp;
static int ams_delta_lcd_set_power(struct lcd_device *dev, int power)
{
@@ -99,41 +100,17 @@ static struct lcd_ops ams_delta_lcd_ops = {
/* omapfb panel section */
-static const struct gpio _gpios[] = {
- {
- .gpio = AMS_DELTA_GPIO_PIN_LCD_VBLEN,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = "lcd_vblen",
- },
- {
- .gpio = AMS_DELTA_GPIO_PIN_LCD_NDISP,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = "lcd_ndisp",
- },
-};
-
-static int ams_delta_panel_init(struct lcd_panel *panel,
- struct omapfb_device *fbdev)
-{
- return gpio_request_array(_gpios, ARRAY_SIZE(_gpios));
-}
-
-static void ams_delta_panel_cleanup(struct lcd_panel *panel)
-{
- gpio_free_array(_gpios, ARRAY_SIZE(_gpios));
-}
-
static int ams_delta_panel_enable(struct lcd_panel *panel)
{
- gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_NDISP, 1);
- gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_VBLEN, 1);
+ gpiod_set_value(gpiod_ndisp, 1);
+ gpiod_set_value(gpiod_vblen, 1);
return 0;
}
static void ams_delta_panel_disable(struct lcd_panel *panel)
{
- gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_VBLEN, 0);
- gpio_set_value(AMS_DELTA_GPIO_PIN_LCD_NDISP, 0);
+ gpiod_set_value(gpiod_vblen, 0);
+ gpiod_set_value(gpiod_ndisp, 0);
}
static struct lcd_panel ams_delta_panel = {
@@ -154,8 +131,6 @@ static struct lcd_panel ams_delta_panel = {
.pcd= 0,
.acb= 37,
- .init = ams_delta_panel_init,
- .cleanup= ams_delta_panel_cleanup,
.enable = ams_delta_panel_enable,
.disable= ams_delta_panel_disable,
};
@@ -166,9 +141,23 @@ static struct lcd_panel ams_delta_panel = {
static int ams_delta_panel_probe(struct platform_device *pdev)
{
struct lcd_device *lcd_device = NULL;
-#ifdef CONFIG_LCD_CLASS_DEVICE
int ret;
+ gpiod_vblen = devm_gpiod_get(&pdev->dev, "vblen", GPIOD_OUT_LOW);
+ if (IS_ERR(gpiod_vblen)) {
+ ret = PTR_ERR(gpiod_vblen);
+ dev_err(&pdev->dev, "VBLEN GPIO request failed (%d)\n", ret);
+ return ret;
+ }
+
+ gpiod_ndisp = devm_gpiod_get(&pdev->dev, "ndisp", GPIOD_OUT_LOW);
+ if (IS_ERR(gpiod_ndisp)) {
+ ret = PTR_ERR(gpiod_ndisp);
+ dev_err(&pdev->dev, "NDISP GPIO request failed (%d)\n", ret);
+ return ret;
+ }
+
+#ifdef CONFIG_LCD_CLASS_DEVICE
lcd_device = lcd_device_register("omapfb", &pdev->dev, NULL,
&ams_delta_lcd_ops);
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: arcfb: mark expected switch fall-through
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 115017 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva
---
drivers/video/fbdev/arcfb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
index 7e87d0d..a48741a 100644
--- a/drivers/video/fbdev/arcfb.c
+++ b/drivers/video/fbdev/arcfb.c
@@ -419,6 +419,8 @@ static int arcfb_ioctl(struct fb_info *info,
schedule();
finish_wait(&arcfb_waitq, &wait);
}
+ /* fall through */
+
case FBIO_GETCONTROL2:
{
unsigned char ctl2;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/exynos: decon: Make pixel blend mode configurable
Currently blend mode is set accordingly to pixel format.
Add pixel blend mode property and make that configurable.
Decon hardware doesn't support premultiplied mode,
chose coverage as default.
Tested on TM2 with Exynos 5433 CPU, on top of exynos-drm-next
using modetest.
Signed-off-by: Christoph Manszewski
---
Currently, the driver exposes the "premultiplied" option for
pixel blend mode property, and handles it as "coverage".
This is due to the fact, that "premultiplied" mode is mandatory
and is used as default. The question is - how to correctly deal with
hardare that doesn't support premultiplied mode?
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 29 ++-
drivers/gpu/drm/exynos/regs-decon5433.h | 1 +
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index dff540160199..15609c9f2fda 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -84,12 +84,13 @@ static const enum drm_plane_type
decon_win_types[WINDOWS_NR] = {
[CURSON_WIN] = DRM_PLANE_TYPE_CURSOR,
};
+
static const unsigned int capabilities[WINDOWS_NR] = {
EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
};
static inline void decon_set_bits(struct decon_context *ctx, u32 reg, u32 mask,
@@ -276,6 +277,24 @@ static void decon_win_set_bldmod(struct decon_context
*ctx, unsigned int win,
unsigned int alpha = state->base.alpha;
u32 win_alpha = alpha >> 8;
u32 val = 0;
+ unsigned int pixel_alpha;
+
+ if (fb->format->has_alpha)
+ pixel_alpha = state->base.pixel_blend_mode;
+ else
+ pixel_alpha = DRM_MODE_BLEND_PIXEL_NONE;
+
+ switch (pixel_alpha) {
+ case DRM_MODE_BLEND_PIXEL_NONE:
+ break;
+ case DRM_MODE_BLEND_COVERAGE:
+ default:
+ val |= WINCONx_ALPHA_SEL_F;
+ val |= WINCONx_BLD_PIX_F;
+ val |= WINCONx_ALPHA_MUL_F;
+ break;
+ }
+ decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_BLEND_MODE_MASK, val);
if (alpha != DRM_BLEND_ALPHA_OPAQUE) {
val = VIDOSD_Wx_ALPHA_R_F(win_alpha) |
VIDOSD_Wx_ALPHA_G_F(win_alpha) |
@@ -335,7 +354,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx,
unsigned int win,
val |= WINCONx_BURSTLEN_8WORD;
}
- writel(val, ctx->addr + DECON_WINCONx(win));
+ decon_set_bits(ctx, DECON_WINCONx(win), ~WINCONx_BLEND_MODE_MASK, val);
}
static void decon_shadow_protect(struct decon_context *ctx, bool protect)
diff --git a/drivers/gpu/drm/exynos/regs-decon5433.h
b/drivers/gpu/drm/exynos/regs-decon5433.h
index f42d8f0adf5d..17b7324922c1 100644
--- a/drivers/gpu/drm/exynos/regs-decon5433.h
+++ b/drivers/gpu/drm/exynos/regs-decon5433.h
@@ -117,6 +117,7 @@
#define WINCONx_BPPMODE_16BPP_A(0xe << 2)
#define WINCONx_ALPHA_SEL_F(1 << 1)
#define WINCONx_ENWIN_F(1 << 0)
+#define WINCONx_BLEND_MODE_MASK(0xc2)
/* SHADOWCON */
#define SHADOWCON_PROTECT_MASK GENMASK(14, 10)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] mm: Introduce new function vm_insert_kmem_page
vm_insert_kmem_page is similar to vm_insert_page and will
be used by drivers to map kernel (kmalloc/vmalloc/pages)
allocated memory to user vma.
Going forward, the plan is to restrict future drivers not
to use vm_insert_page ( *it will generate new errno to
VM_FAULT_CODE mapping code for new drivers which were already
cleaned up for existing drivers*) in #PF (page fault handler)
context but to make use of vmf_insert_page which returns
VMF_FAULT_CODE and that is not possible until both vm_insert_page
and vmf_insert_page API exists.
But there are some consumers of vm_insert_page which use it
outside #PF context. straight forward conversion of vm_insert_page
to vmf_insert_page won't work there as those function calls expects
errno not vm_fault_t in return.
These are the approaches which could have been taken to handle
this scenario -
* Replace vm_insert_page with vmf_insert_page and then write few
extra lines of code to convert VM_FAULT_CODE to errno which
makes driver users more complex ( also the reverse mapping errno to
VM_FAULT_CODE have been cleaned up as part of vm_fault_t migration ,
not preferred to introduce anything similar again)
* Maintain both vm_insert_page and vmf_insert_page and use it in
respective places. But it won't gurantee that vm_insert_page will
never be used in #PF context.
* Introduce a similar API like vm_insert_page, convert all non #PF
consumer to use it and finally remove vm_insert_page by converting
it to vmf_insert_page.
And the 3rd approach was taken by introducing vm_insert_kmem_page().
In short, vmf_insert_page will be used in page fault handlers
context and vm_insert_kmem_page will be used to map kernel
memory to user vma outside page fault handlers context.
Few drivers are converted to use vm_insert_kmem_page(). This will
allow both to review the api and that it serves it purpose. other
consumers of vm_insert_page (*used in non #PF context*) will be
replaced by vm_insert_kmem_page, but in separate patches.
Signed-off-by: Souptick Joarder
---
v2: Few non #PF consumers of vm_insert_page are converted
to use vm_insert_kmem_page in patch v2.
Updated the change log.
arch/arm/mm/dma-mapping.c | 2 +-
drivers/auxdisplay/cfag12864bfb.c | 2 +-
drivers/auxdisplay/ht16k33.c| 2 +-
drivers/firewire/core-iso.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
include/linux/mm.h | 2 +
kernel/kcov.c | 4 +-
mm/memory.c | 69 +
mm/nommu.c | 7 +++
mm/vmalloc.c| 2 +-
10 files changed, 86 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6656647..58d7971 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1598,7 +1598,7 @@ static int __arm_iommu_mmap_attrs(struct device *dev,
struct vm_area_struct *vma
pages += off;
do {
- int ret = vm_insert_page(vma, uaddr, *pages++);
+ int ret = vm_insert_kmem_page(vma, uaddr, *pages++);
if (ret) {
pr_err("Remapping memory failed: %d\n", ret);
return ret;
diff --git a/drivers/auxdisplay/cfag12864bfb.c
b/drivers/auxdisplay/cfag12864bfb.c
index 40c8a55..82fd627 100644
--- a/drivers/auxdisplay/cfag12864bfb.c
+++ b/drivers/auxdisplay/cfag12864bfb.c
@@ -52,7 +52,7 @@
static int cfag12864bfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
- return vm_insert_page(vma, vma->vm_start,
+ return vm_insert_kmem_page(vma, vma->vm_start,
virt_to_page(cfag12864b_buffer));
}
diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
index a43276c..64de30b 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -224,7 +224,7 @@ static int ht16k33_mmap(struct fb_info *info, struct
vm_area_struct *vma)
{
struct ht16k33_priv *priv = info->par;
- return vm_insert_page(vma, vma->vm_start,
+ return vm_insert_kmem_page(vma, vma->vm_start,
virt_to_page(priv->fbdev.buffer));
}
diff --git a/drivers/firewire/core-iso.c b/drivers/firewire/core-iso.c
index 051327a..5f1548d 100644
--- a/drivers/firewire/core-iso.c
+++ b/drivers/firewire/core-iso.c
@@ -112,7 +112,7 @@ int fw_iso_buffer_map_vma(struct fw_iso_buffer *buffer,
uaddr = vma->vm_start;
for (i = 0; i < buffer->page_count; i++) {
- err = vm_insert_page(vma, uaddr, buffer->pages[i]);
+ err = vm_insert_kmem_page(vma, uaddr, buffer->pages[i]);
if (err)
return err;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index a8db758..57eb7af 100644
--- a/drivers/gpu/
[PATCH 1/2] drm/exynos: decon: Make plane alpha configurable
The decon hardware supports variable plane alpha. Currently planes
are opaque, make this configurable.
Tested on TM2 with Exynos 5433 CPU, on top of exynos-drm-next.
Signed-off-by: Christoph Manszewski
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 30 +++
drivers/gpu/drm/exynos/regs-decon5433.h | 4
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 94529aa82339..dff540160199 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -84,6 +84,14 @@ static const enum drm_plane_type decon_win_types[WINDOWS_NR]
= {
[CURSON_WIN] = DRM_PLANE_TYPE_CURSOR,
};
+static const unsigned int capabilities[WINDOWS_NR] = {
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
+};
+
static inline void decon_set_bits(struct decon_context *ctx, u32 reg, u32 mask,
u32 val)
{
@@ -259,6 +267,24 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
}
+static void decon_win_set_bldmod(struct decon_context *ctx, unsigned int win,
+struct drm_framebuffer *fb)
+{
+ struct exynos_drm_plane plane = ctx->planes[win];
+ struct exynos_drm_plane_state *state =
+ to_exynos_plane_state(plane.base.state);
+ unsigned int alpha = state->base.alpha;
+ u32 win_alpha = alpha >> 8;
+ u32 val = 0;
+
+ if (alpha != DRM_BLEND_ALPHA_OPAQUE) {
+ val = VIDOSD_Wx_ALPHA_R_F(win_alpha) |
VIDOSD_Wx_ALPHA_G_F(win_alpha) |
+ VIDOSD_Wx_ALPHA_B_F(win_alpha);
+ decon_set_bits(ctx, DECON_VIDOSDxC(win), 0xff, val);
+ decon_set_bits(ctx, DECON_BLENDCON, BLEND_NEW, BLEND_NEW);
+ }
+}
+
static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
struct drm_framebuffer *fb)
{
@@ -267,6 +293,8 @@ static void decon_win_set_pixfmt(struct decon_context *ctx,
unsigned int win,
val = readl(ctx->addr + DECON_WINCONx(win));
val &= WINCONx_ENWIN_F;
+ decon_win_set_bldmod(ctx, win, fb);
+
switch (fb->format->format) {
case DRM_FORMAT_XRGB1555:
val |= WINCONx_BPPMODE_16BPP_I1555;
@@ -288,6 +316,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx,
unsigned int win,
val |= WINCONx_BPPMODE_32BPP_A;
val |= WINCONx_WSWP_F | WINCONx_BLD_PIX_F | WINCONx_ALPHA_SEL_F;
val |= WINCONx_BURSTLEN_16WORD;
+ val |= WINCONx_ALPHA_MUL_F;
break;
}
@@ -561,6 +590,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
ctx->configs[win].num_pixel_formats = ARRAY_SIZE(decon_formats);
ctx->configs[win].zpos = win - ctx->first_win;
ctx->configs[win].type = decon_win_types[win];
+ ctx->configs[win].capabilities = capabilities[win];
ret = exynos_plane_init(drm_dev, &ctx->planes[win], win,
&ctx->configs[win]);
diff --git a/drivers/gpu/drm/exynos/regs-decon5433.h
b/drivers/gpu/drm/exynos/regs-decon5433.h
index 19ad9e47945e..f42d8f0adf5d 100644
--- a/drivers/gpu/drm/exynos/regs-decon5433.h
+++ b/drivers/gpu/drm/exynos/regs-decon5433.h
@@ -104,6 +104,7 @@
#define WINCONx_BURSTLEN_16WORD(0x0 << 10)
#define WINCONx_BURSTLEN_8WORD (0x1 << 10)
#define WINCONx_BURSTLEN_4WORD (0x2 << 10)
+#define WINCONx_ALPHA_MUL_F(1 << 7)
#define WINCONx_BLD_PIX_F (1 << 6)
#define WINCONx_BPPMODE_MASK (0xf << 2)
#define WINCONx_BPPMODE_16BPP_565 (0x5 << 2)
@@ -206,4 +207,7 @@
#define CRCCTRL_CRCEN (0x1 << 0)
#define CRCCTRL_MASK (0x7)
+/* BLENDCON */
+#define BLEND_NEW (1 << 0)
+
#endif /* EXYNOS_REGS_DECON5433_H */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
Hi Souptick,
On Wed, Oct 3, 2018 at 8:55 PM Souptick Joarder wrote:
>
> vm_insert_kmem_page is similar to vm_insert_page and will
> be used by drivers to map kernel (kmalloc/vmalloc/pages)
> allocated memory to user vma.
>
> Going forward, the plan is to restrict future drivers not
> to use vm_insert_page ( *it will generate new errno to
> VM_FAULT_CODE mapping code for new drivers which were already
> cleaned up for existing drivers*) in #PF (page fault handler)
> context but to make use of vmf_insert_page which returns
> VMF_FAULT_CODE and that is not possible until both vm_insert_page
> and vmf_insert_page API exists.
>
> But there are some consumers of vm_insert_page which use it
> outside #PF context. straight forward conversion of vm_insert_page
> to vmf_insert_page won't work there as those function calls expects
> errno not vm_fault_t in return.
>
> These are the approaches which could have been taken to handle
> this scenario -
>
> * Replace vm_insert_page with vmf_insert_page and then write few
>extra lines of code to convert VM_FAULT_CODE to errno which
>makes driver users more complex ( also the reverse mapping errno to
>VM_FAULT_CODE have been cleaned up as part of vm_fault_t migration ,
>not preferred to introduce anything similar again)
>
> * Maintain both vm_insert_page and vmf_insert_page and use it in
>respective places. But it won't gurantee that vm_insert_page will
>never be used in #PF context.
>
> * Introduce a similar API like vm_insert_page, convert all non #PF
>consumer to use it and finally remove vm_insert_page by converting
>it to vmf_insert_page.
>
> And the 3rd approach was taken by introducing vm_insert_kmem_page().
This looks better than the previous one of adding non-trivial code to
each driver, thank you!
A couple of comments below.
>
> In short, vmf_insert_page will be used in page fault handlers
> context and vm_insert_kmem_page will be used to map kernel
> memory to user vma outside page fault handlers context.
>
> Few drivers are converted to use vm_insert_kmem_page(). This will
> allow both to review the api and that it serves it purpose. other
> consumers of vm_insert_page (*used in non #PF context*) will be
> replaced by vm_insert_kmem_page, but in separate patches.
>
other -> Other
Also, as far as I can see, there are only a few vm_insert_page users
remaining. With the new function, they should be trivial to convert,
no? Therefore, could we do them all in one go, possibly in a patch
series?
Or, maybe, even better: wait until you remove the vm_* functions and
simply reuse vm_insert_page for this -- that way you don't need a new
name and you don't have to change any of the last users (I mean the
drivers using it outside the page fault handlers).
> Signed-off-by: Souptick Joarder
> ---
> v2: Few non #PF consumers of vm_insert_page are converted
> to use vm_insert_kmem_page in patch v2.
>
> Updated the change log.
>
> arch/arm/mm/dma-mapping.c | 2 +-
> drivers/auxdisplay/cfag12864bfb.c | 2 +-
> drivers/auxdisplay/ht16k33.c| 2 +-
> drivers/firewire/core-iso.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
> include/linux/mm.h | 2 +
> kernel/kcov.c | 4 +-
> mm/memory.c | 69
> +
> mm/nommu.c | 7 +++
> mm/vmalloc.c| 2 +-
> 10 files changed, 86 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 6656647..58d7971 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1598,7 +1598,7 @@ static int __arm_iommu_mmap_attrs(struct device *dev,
> struct vm_area_struct *vma
> pages += off;
>
> do {
> - int ret = vm_insert_page(vma, uaddr, *pages++);
> + int ret = vm_insert_kmem_page(vma, uaddr, *pages++);
> if (ret) {
> pr_err("Remapping memory failed: %d\n", ret);
> return ret;
> diff --git a/drivers/auxdisplay/cfag12864bfb.c
> b/drivers/auxdisplay/cfag12864bfb.c
> index 40c8a55..82fd627 100644
> --- a/drivers/auxdisplay/cfag12864bfb.c
> +++ b/drivers/auxdisplay/cfag12864bfb.c
> @@ -52,7 +52,7 @@
>
> static int cfag12864bfb_mmap(struct fb_info *info, struct vm_area_struct
> *vma)
> {
> - return vm_insert_page(vma, vma->vm_start,
> + return vm_insert_kmem_page(vma, vma->vm_start,
> virt_to_page(cfag12864b_buffer));
> }
>
> diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
> index a43276c..64de30b 100644
> --- a/drivers/auxdisplay/ht16k33.c
> +++ b/drivers/auxdisplay/ht16k33.c
> @@ -224,7 +224,7 @@ static int ht16k33_mmap(struct fb_info *info, struct
> vm_area_struct *vma)
> {
> struct ht16k33_priv *priv = inf
[PATCH 0/2] drm/exynos: decon: Add properties
Hello, This patch series adds two new configurable properties to exynos5433_drm_decon. Patch 1 add window alpha property. Patch 2 add pixel blend mode property. Regards, Chris Christoph Manszewski (2): drm/exynos: decon: Make plane alpha configurable drm/exynos: decon: Make pixel blend mode configurable drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 51 ++- drivers/gpu/drm/exynos/regs-decon5433.h | 5 +++ 2 files changed, 55 insertions(+), 1 deletion(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
On Wed, Oct 03, 2018 at 11:14:45PM +0100, Russell King - ARM Linux wrote: > On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote: > > On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote: > > > These are the approaches which could have been taken to handle > > > this scenario - > > > > > > * Replace vm_insert_page with vmf_insert_page and then write few > > >extra lines of code to convert VM_FAULT_CODE to errno which > > >makes driver users more complex ( also the reverse mapping errno to > > >VM_FAULT_CODE have been cleaned up as part of vm_fault_t migration , > > >not preferred to introduce anything similar again) > > > > > > * Maintain both vm_insert_page and vmf_insert_page and use it in > > >respective places. But it won't gurantee that vm_insert_page will > > >never be used in #PF context. > > > > > > * Introduce a similar API like vm_insert_page, convert all non #PF > > >consumer to use it and finally remove vm_insert_page by converting > > >it to vmf_insert_page. > > > > > > And the 3rd approach was taken by introducing vm_insert_kmem_page(). > > > > > > In short, vmf_insert_page will be used in page fault handlers > > > context and vm_insert_kmem_page will be used to map kernel > > > memory to user vma outside page fault handlers context. > > > > As far as I can tell, vm_insert_kmem_page() is line-for-line identical > > with vm_insert_page(). Seriously, here's a diff I just did: [...] > > What on earth are you trying to do? > > Reading the commit log, it seems that the intention is to split out > vm_insert_page() used outside of page-fault handling with the use > within page-fault handling, so that different return codes can be > used. Right, but we already did that. We now have vmf_insert_page() which returns a VM_FAULT_* code and vm_insert_page() which returns an errno. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef
On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
>
> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
> >
> > On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
> > >
> > >
> > > Den 02.10.2018 22.58, skrev Arnd Bergmann:
> > > > The variable is now referenced unconditionally, but still
> > > > declared in an #ifdef:
> > > >
> > > > drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
> > > > drivers/gpu/drm/imx/imx-drm-core.c:264:6: error: 'legacyfb_depth'
> > > > undeclared (first use in this function); did you mean 'lockdep_depth'?
> > > >
> > > > Remove the #ifdef so it can always be accessed.
> > > >
> > > > Fixes: f53705fd9803 ("drm/imx: Use drm_fbdev_generic_setup()")
> > > > Signed-off-by: Arnd Bergmann
> > > > ---
> > >
> > > I've already applied the previous one you sent:
> > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=064b06bbf117f8b5e64a5143e970d5a1cf602fd6
> > >
> > > Not sure when it reaches linux-next now that we are past rc6.
> >
> > Only once we're past -rc1.
>
> Can we revert f53705fd9803 in linux-next then to prevent the regression from
> making it into 4.20?
Probably simpler to cherry pick the fix from drm-misc-next to
drm-misc-next-fixes. Noralf, can you pls do that?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] drm: Add connector property to limit max bpc
On Wed, Oct 03, 2018 at 03:24:40PM -0700, Radhakrishna Sripada wrote:
> On Mon, Oct 01, 2018 at 09:23:38AM +0200, Daniel Vetter wrote:
> > On Mon, Sep 24, 2018 at 02:08:14PM -0700, Radhakrishna Sripada wrote:
> > > At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> > > level shifters etc. To workaround them we may need to drive the output
> > > at a lower bpc. Currently the user space does not have a way to limit
> > > the bpc. The default bpc to be programmed is decided by the driver and
> > > is run against connector limitations.
> > >
> > > Creating a new connector property "max bpc" in order to limit the bpc.
> > > xrandr can make use of this connector property to make sure that bpc does
> > > not exceed the configured value. This property can be used by userspace to
> > > set the bpc.
> > >
> > > V2: Initialize max_bpc to satisfy kms_properties
> > > V3: Move the property to drm_connector
> > > V4: Split drm and i915 components(Ville)
> > > V5: Make the property per connector(Ville)
> > > V6: Compare the requested bpc to connector bpc(Daniel)
> > > Move the attach_property function to core(Ville)
> > > V7: Fix checkpatch warnings
> > > V8: Simplify the connector check code(Ville)
> > > V9: Const display_info(Ville)
> > > V10: Fix CI issues.
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Daniel Vetter
> > > Cc: Kishore Kadiyala
> > > Cc: Rodrigo Vivi
> > > Cc: Manasi Navare
> > > Cc: Stanislav Lisovskiy
> > > Cc: Sunpeng Li
> > > Signed-off-by: Radhakrishna Sripada
> >
> > Skimming this, I think it looks good now at a high-level.
> >
> > What's missing is now kernel-doc for these new prorties, needs to be added
> > here:
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
> >
> > With that I'm happy with the high-level design:
> >
> > Acked-by: Daniel Vetter
> >
> > No full review since I didn't look at the igt side for this. Userspace I
> > think is ok, since it's just another connector prop.
> kms_properties would test this newly added property as part of the connector
> properties.
> Do you suggest me to add a new subtest to try checking the different values
> for the
> newly added property?
kms_properties most definitely doesn't do any kind of functional testing
here. Which means it's not validated in an automatic way.
So yes, we most definitely want a real testcase here. Coming up with a
proper validation strategy here is going to be somewhat challenging
though.
Thanks, Daniel
>
> --Radhakrishna Sripada
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_atomic.c| 5 +
> > > drivers/gpu/drm/drm_atomic_helper.c | 4
> > > drivers/gpu/drm/drm_atomic_uapi.c | 4
> > > drivers/gpu/drm/drm_connector.c | 33
> > > +
> > > include/drm/drm_connector.h | 20
> > > 5 files changed, 66 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 2870ae205237..f328bcca84a8 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct
> > > drm_connector *connector,
> > > {
> > > struct drm_crtc_state *crtc_state;
> > > struct drm_writeback_job *writeback_job = state->writeback_job;
> > > + const struct drm_display_info *info = &connector->display_info;
> > >
> > > if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
> > > !writeback_job)
> > > return 0;
> > > @@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct
> > > drm_connector *connector,
> > > return -EINVAL;
> > > }
> > >
> > > + state->max_bpc = info->bpc ? info->bpc : 8;
> > > + if (connector->max_bpc_property)
> > > + state->max_bpc = min(state->max_bpc, state->max_requested_bpc);
> > > +
> > > return 0;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index e49b22381048..75aeca35f6d9 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -639,6 +639,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->max_requested_bpc !=
> > > + new_connector_state->max_requested_bpc)
> > > + new_crtc_state->connectors_changed = true;
> > > }
> > >
> > > if (funcs->atomic_check)
> > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > index d5b7f315098c..86ac33922b09 100644
> > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >
Re: [PATCH v2] drm: fb-helper: Reject all pixel format changing requests
On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> drm fbdev emulation doesn't support changing the pixel format at all,
> so reject all pixel format changing requests.
For next time around: Please keep the note here why we need this and what
the impact is. Otherwise it's not immediately clear why we should backport
this patch to all stable kernels.
I'll gather a few acks and then apply.
-Daniel
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eugeniy Paltsev
> ---
> Changes v1->v2:
> * Reject all pixel format changing request, not just the invalid ones.
>
> drivers/gpu/drm/drm_fb_helper.c | 91
> -
> 1 file changed, 26 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 16ec93b75dbf..48598d7f673f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1580,6 +1580,25 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned
> int cmd,
> }
> EXPORT_SYMBOL(drm_fb_helper_ioctl);
>
> +static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo *var_1,
> + const struct fb_var_screeninfo *var_2)
> +{
> + return var_1->bits_per_pixel == var_2->bits_per_pixel &&
> +var_1->grayscale == var_2->grayscale &&
> +var_1->red.offset == var_2->red.offset &&
> +var_1->red.length == var_2->red.length &&
> +var_1->red.msb_right == var_2->red.msb_right &&
> +var_1->green.offset == var_2->green.offset &&
> +var_1->green.length == var_2->green.length &&
> +var_1->green.msb_right == var_2->green.msb_right &&
> +var_1->blue.offset == var_2->blue.offset &&
> +var_1->blue.length == var_2->blue.length &&
> +var_1->blue.msb_right == var_2->blue.msb_right &&
> +var_1->transp.offset == var_2->transp.offset &&
> +var_1->transp.length == var_2->transp.length &&
> +var_1->transp.msb_right == var_2->transp.msb_right;
> +}
> +
> /**
> * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
> * @var: screeninfo to check
> @@ -1590,7 +1609,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> {
> struct drm_fb_helper *fb_helper = info->par;
> struct drm_framebuffer *fb = fb_helper->fb;
> - int depth;
>
> if (var->pixclock != 0 || in_dbg_master())
> return -EINVAL;
> @@ -1610,72 +1628,15 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> return -EINVAL;
> }
>
> - switch (var->bits_per_pixel) {
> - case 16:
> - depth = (var->green.length == 6) ? 16 : 15;
> - break;
> - case 32:
> - depth = (var->transp.length > 0) ? 32 : 24;
> - break;
> - default:
> - depth = var->bits_per_pixel;
> - break;
> - }
> -
> - switch (depth) {
> - case 8:
> - var->red.offset = 0;
> - var->green.offset = 0;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 15:
> - var->red.offset = 10;
> - var->green.offset = 5;
> - var->blue.offset = 0;
> - var->red.length = 5;
> - var->green.length = 5;
> - var->blue.length = 5;
> - var->transp.length = 1;
> - var->transp.offset = 15;
> - break;
> - case 16:
> - var->red.offset = 11;
> - var->green.offset = 5;
> - var->blue.offset = 0;
> - var->red.length = 5;
> - var->green.length = 6;
> - var->blue.length = 5;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 24:
> - var->red.offset = 16;
> - var->green.offset = 8;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 32:
> - var->red.offset = 16;
> - var->green.offset = 8;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 8;
> - var->transp.offset = 24;
> - break;
> - default:
> + /*
> + * drm fbdev emulation doesn't support changing the pixel format at all,
> + * so reject all pixel format changing requests.
> + */
> + if (!drm_fb_pixel_format_equal(var, &info->var)) {
> +
[PULL] drm-misc-fixes
drm-misc-fixes-2018-10-04: drm-misc-fixes for v4.19-rc7: - Fix use-after-free in drm_mode_create_lease_ioctl() - Fix crash in fbdev error path. The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38: Linux 4.19-rc6 (2018-09-30 07:15:35 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-10-04 for you to fetch changes up to 4d4c2d89913e2d891bd6a34b12050a2576e60525: drm/cma-helper: Fix crash in fbdev error path (2018-10-02 13:03:34 +0200) drm-misc-fixes for v4.19-rc7: - Fix use-after-free in drm_mode_create_lease_ioctl() - Fix crash in fbdev error path. Jann Horn (1): drm: fix use-after-free read in drm_mode_create_lease_ioctl() Noralf Trønnes (1): drm/cma-helper: Fix crash in fbdev error path drivers/gpu/drm/drm_client.c| 35 ++- drivers/gpu/drm/drm_fb_cma_helper.c | 4 +++- drivers/gpu/drm/drm_fb_helper.c | 4 +++- drivers/gpu/drm/drm_lease.c | 6 +++--- include/drm/drm_client.h| 5 +++-- 5 files changed, 38 insertions(+), 16 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/meson: fix max mode_config height/width
The mode_config max_width/max_height determines the maximum framebuffer
size the pixel reader can handle. But the values were set thinking they
were determining the maximum screen dimensions.
This patch changes the values to the maximum height/width the CANVAS block
can handle rounded to some coherent values.
Fixes: a41e82e6c457 ("drm/meson: Add support for components")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index d344312..2e29968 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -243,8 +243,8 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
goto free_drm;
drm_mode_config_init(drm);
- drm->mode_config.max_width = 3840;
- drm->mode_config.max_height = 2160;
+ drm->mode_config.max_width = 16384;
+ drm->mode_config.max_height = 8192;
drm->mode_config.funcs = &meson_mode_config_funcs;
/* Hardware Initialization */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] cec/adv/omap: fixes and new status flags
From: Hans Verkuil The first patch adds new status flags to indicate when a pending message is aborted because the CEC adapter is unconfigured, and when a transmit times out (this indicates a driver bug). The second and third patch fix a minor issue with the adv HDMI receivers: if the EDID goes away, then the physical address also becomes invalid. The fourth patch fixes a race condition in the omap4 CEC driver that causes a transmit time out. The final patch drops the code in the omap4 CEC driver that attempts to set the number of retransmits: those register bits are read-only, so the code is pointless. There are no dependencies between these patches, although the first and fourth patch relate to the same problem. With the new transmit TIMEOUT status I hope that it will be easier to catch driver bugs like that earlier since this bug remained hidden for too long. Regards, Hans Hans Verkuil (5): cec: add new tx/rx status bits to detect aborts/timeouts adv7604: when the EDID is cleared, unconfigure CEC as well adv7842: when the EDID is cleared, unconfigure CEC as well omapdrm/dss/hdmi4_cec.c: clear TX FIFO before transmit_done omapdrm/dss/hdmi4_cec.c: don't set the retransmit count .../media/uapi/cec/cec-ioc-receive.rst| 25 ++- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 38 +-- drivers/media/cec/cec-adap.c | 66 +-- drivers/media/i2c/adv7604.c | 4 +- drivers/media/i2c/adv7842.c | 4 +- include/uapi/linux/cec.h | 3 + 6 files changed, 67 insertions(+), 73 deletions(-) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] adv7842: when the EDID is cleared, unconfigure CEC as well
From: Hans Verkuil
When there is no EDID the CEC adapter should be unconfigured as
well. So call cec_phys_addr_invalidate() when this happens.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7842.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 4f8fbdd00e35..71fe56565f75 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -786,8 +786,10 @@ static int edid_write_hdmi_segment(struct v4l2_subdev *sd,
u8 port)
/* Disable I2C access to internal EDID ram from HDMI DDC ports */
rep_write_and_or(sd, 0x77, 0xf3, 0x00);
- if (!state->hdmi_edid.present)
+ if (!state->hdmi_edid.present) {
+ cec_phys_addr_invalidate(state->cec_adap);
return 0;
+ }
pa = cec_get_edid_phys_addr(edid, 256, &spa_loc);
err = cec_phys_addr_validate(pa, &pa, NULL);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] omapdrm/dss/hdmi4_cec.c: clear TX FIFO before transmit_done
From: Hans Verkuil
The TX FIFO has to be cleared if the transmit failed due to e.g.
a NACK condition, otherwise the hardware will keep trying to
transmit the message.
An attempt was made to do this, but it was done after the call to
cec_transmit_done, which can cause a race condition since the call
to cec_transmit_done can cause a new transmit to be issued, and
then attempting to clear the TX FIFO will actually clear the new
transmit instead of the old transmit and the new transmit simply
never happens.
By clearing the FIFO before transmit_done is called this race
is fixed.
Note that there is no reason to clear the FIFO if the transmit
was successful, so the attempt to clear the FIFO in that case
was dropped.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 35 -
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
index 340383150fb9..dee66a5101b5 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
@@ -106,6 +106,22 @@ static void hdmi_cec_received_msg(struct hdmi_core_data
*core)
}
}
+static bool hdmi_cec_clear_tx_fifo(struct cec_adapter *adap)
+{
+ struct hdmi_core_data *core = cec_get_drvdata(adap);
+ int retry = HDMI_CORE_CEC_RETRY;
+ int temp;
+
+ REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, 0x1, 7, 7);
+ while (retry) {
+ temp = hdmi_read_reg(core->base, HDMI_CEC_DBG_3);
+ if (FLD_GET(temp, 7, 7) == 0)
+ break;
+ retry--;
+ }
+ return retry != 0;
+}
+
void hdmi4_cec_irq(struct hdmi_core_data *core)
{
u32 stat0 = hdmi_read_reg(core->base, HDMI_CEC_INT_STATUS_0);
@@ -117,36 +133,19 @@ void hdmi4_cec_irq(struct hdmi_core_data *core)
if (stat0 & 0x20) {
cec_transmit_done(core->adap, CEC_TX_STATUS_OK,
0, 0, 0, 0);
- REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, 0x1, 7, 7);
} else if (stat1 & 0x02) {
u32 dbg3 = hdmi_read_reg(core->base, HDMI_CEC_DBG_3);
+ hdmi_cec_clear_tx_fifo(core->adap);
cec_transmit_done(core->adap,
CEC_TX_STATUS_NACK |
CEC_TX_STATUS_MAX_RETRIES,
0, (dbg3 >> 4) & 7, 0, 0);
- REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, 0x1, 7, 7);
}
if (stat0 & 0x02)
hdmi_cec_received_msg(core);
}
-static bool hdmi_cec_clear_tx_fifo(struct cec_adapter *adap)
-{
- struct hdmi_core_data *core = cec_get_drvdata(adap);
- int retry = HDMI_CORE_CEC_RETRY;
- int temp;
-
- REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, 0x1, 7, 7);
- while (retry) {
- temp = hdmi_read_reg(core->base, HDMI_CEC_DBG_3);
- if (FLD_GET(temp, 7, 7) == 0)
- break;
- retry--;
- }
- return retry != 0;
-}
-
static bool hdmi_cec_clear_rx_fifo(struct cec_adapter *adap)
{
struct hdmi_core_data *core = cec_get_drvdata(adap);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] adv7604: when the EDID is cleared, unconfigure CEC as well
From: Hans Verkuil
When there is no EDID the CEC adapter should be unconfigured as
well. So call cec_phys_addr_invalidate() when this happens.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7604.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 668be2bca57a..3376d5cb05d5 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2284,8 +2284,10 @@ static int adv76xx_set_edid(struct v4l2_subdev *sd,
struct v4l2_edid *edid)
state->aspect_ratio.numerator = 16;
state->aspect_ratio.denominator = 9;
- if (!state->edid.present)
+ if (!state->edid.present) {
state->edid.blocks = 0;
+ cec_phys_addr_invalidate(state->cec_adap);
+ }
v4l2_dbg(2, debug, sd, "%s: clear EDID pad %d, edid.present =
0x%x\n",
__func__, edid->pad, state->edid.present);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] cec: add new tx/rx status bits to detect aborts/timeouts
From: Hans Verkuil
If the HDMI cable is disconnected or the CEC adapter is manually
unconfigured, then all pending transmits and wait-for-replies are
aborted. Signal this with new status bits (CEC_RX/TX_STATUS_ABORTED).
If due to (usually) a driver bug a transmit never ends (i.e. the
transmit_done was never called by the driver), then when this times
out the message is marked with CEC_TX_STATUS_TIMEOUT.
This should not happen and is an indication of a driver bug.
Without a separate status bit for this it was impossible to detect
this from userspace.
The 'transmit timed out' kernel message is now a warning, so this
should be more prominent in the kernel log as well.
Signed-off-by: Hans Verkuil
---
.../media/uapi/cec/cec-ioc-receive.rst| 25 ++-
drivers/media/cec/cec-adap.c | 66 +--
include/uapi/linux/cec.h | 3 +
3 files changed, 44 insertions(+), 50 deletions(-)
diff --git a/Documentation/media/uapi/cec/cec-ioc-receive.rst
b/Documentation/media/uapi/cec/cec-ioc-receive.rst
index e964074cd15b..b25e48afaa08 100644
--- a/Documentation/media/uapi/cec/cec-ioc-receive.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-receive.rst
@@ -16,10 +16,10 @@ CEC_RECEIVE, CEC_TRANSMIT - Receive or transmit a CEC
message
Synopsis
-.. c:function:: int ioctl( int fd, CEC_RECEIVE, struct cec_msg *argp )
+.. c:function:: int ioctl( int fd, CEC_RECEIVE, struct cec_msg \*argp )
:name: CEC_RECEIVE
-.. c:function:: int ioctl( int fd, CEC_TRANSMIT, struct cec_msg *argp )
+.. c:function:: int ioctl( int fd, CEC_TRANSMIT, struct cec_msg \*argp )
:name: CEC_TRANSMIT
Arguments
@@ -272,6 +272,19 @@ View On' messages from initiator 0xf ('Unregistered') to
destination 0 ('TV').
- The transmit failed after one or more retries. This status bit is
mutually exclusive with :ref:`CEC_TX_STATUS_OK `.
Other bits can still be set to explain which failures were seen.
+* .. _`CEC-TX-STATUS-ABORTED`:
+
+ - ``CEC_TX_STATUS_ABORTED``
+ - 0x40
+ - The transmit was aborted due to an HDMI disconnect, or the adapter
+was unconfigured, or a transmit was interrupted, or the driver
+ returned an error when attempting to start a transmit.
+* .. _`CEC-TX-STATUS-TIMEOUT`:
+
+ - ``CEC_TX_STATUS_TIMEOUT``
+ - 0x80
+ - The transmit timed out. This should not normally happen and this
+ indicates a driver problem.
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
@@ -300,6 +313,14 @@ View On' messages from initiator 0xf ('Unregistered') to
destination 0 ('TV').
- The message was received successfully but the reply was
``CEC_MSG_FEATURE_ABORT``. This status is only set if this message
was the reply to an earlier transmitted message.
+* .. _`CEC-RX-STATUS-ABORTED`:
+
+ - ``CEC_RX_STATUS_ABORTED``
+ - 0x08
+ - The wait for a reply to an earlier transmitted message was aborted
+because the HDMI cable was disconnected, the adapter was unconfigured
+ or the :ref:`CEC_TRANSMIT ` that waited for a
+ reply was interrupted.
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 030b2602faf0..2ebb53fd4800 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -341,7 +341,7 @@ static void cec_data_completed(struct cec_data *data)
*
* This function is called with adap->lock held.
*/
-static void cec_data_cancel(struct cec_data *data)
+static void cec_data_cancel(struct cec_data *data, u8 tx_status)
{
/*
* It's either the current transmit, or it is a pending
@@ -356,13 +356,11 @@ static void cec_data_cancel(struct cec_data *data)
}
if (data->msg.tx_status & CEC_TX_STATUS_OK) {
- /* Mark the canceled RX as a timeout */
data->msg.rx_ts = ktime_get_ns();
- data->msg.rx_status = CEC_RX_STATUS_TIMEOUT;
+ data->msg.rx_status = CEC_RX_STATUS_ABORTED;
} else {
- /* Mark the canceled TX as an error */
data->msg.tx_ts = ktime_get_ns();
- data->msg.tx_status |= CEC_TX_STATUS_ERROR |
+ data->msg.tx_status |= tx_status |
CEC_TX_STATUS_MAX_RETRIES;
data->msg.tx_error_cnt++;
data->attempts = 0;
@@ -390,15 +388,15 @@ static void cec_flush(struct cec_adapter *adap)
while (!list_empty(&adap->transmit_queue)) {
data = list_first_entry(&adap->transmit_queue,
struct cec_data, list);
- cec_data_cancel(data);
+ cec_data_cancel(data, CEC_TX_STATUS_ABORTED);
}
if (adap->transmitting)
- cec_data_cancel(adap->transmitting);
+ cec_data_cancel(adap->transmitting, CEC_TX_STATUS_ABORTED);
/* Cancel the pending timeout work. */
[PATCH 5/5] omapdrm/dss/hdmi4_cec.c: don't set the retransmit count
From: Hans Verkuil The HDMI_CEC_DBG_3 register does have a retransmit count, but you can't write to it, those bits are read-only. So drop the attempt to set the retransmit count, since it doesn't work. Signed-off-by: Hans Verkuil --- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c index dee66a5101b5..00407f1995a8 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c @@ -280,9 +280,6 @@ static int hdmi_cec_adap_transmit(struct cec_adapter *adap, u8 attempts, hdmi_write_reg(core->base, HDMI_CEC_INT_STATUS_1, HDMI_CEC_RETRANSMIT_CNT_INT_MASK); - /* Set the retry count */ - REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, attempts - 1, 6, 4); - /* Set the initiator addresses */ hdmi_write_reg(core->base, HDMI_CEC_TX_INIT, cec_msg_initiator(msg)); -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v4 0/4] msm/drm: a6xx DCVS series
This patch series starts off with a bug fixes in devfreq code, followed by refactoring the devfreq code needed for supporting different chipsets, and ends with adding devfreq support for A6xx. v2, v3: Addressed review comments from Jordan Crouse. v4: Patches raised against Rob's msm-next. Fixed a bug caught in downstream testing. Note: Scaling works best with these two fixes https://patchwork.freedesktop.org/patch/253992/ https://patchwork.freedesktop.org/patch/253458/ Sharat Masetty (4): drm/msm: suspend devfreq on init drm/msm/a6xx: Add gmu_read64() register read op drm/msm: re-factor devfreq code drm/msm/a6xx: Add devfreq support for a6xx drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 + drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 38 + drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 12 ++ drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27 + drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 3 ++- drivers/gpu/drm/msm/msm_gpu.c | 45 +-- drivers/gpu/drm/msm/msm_gpu.h | 5 +++- 7 files changed, 118 insertions(+), 28 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v4 2/4] drm/msm/a6xx: Add gmu_read64() register read op
Add a simple function to read 64 registers in the GMU domain
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index ad3bc5a..f34630c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -98,6 +98,16 @@ static inline void gmu_rmw(struct a6xx_gmu *gmu, u32 reg,
u32 mask, u32 or)
gmu_write(gmu, reg, val | or);
}
+static inline u64 gmu_read64(struct a6xx_gmu *gmu, u32 lo, u32 hi)
+{
+ u64 val;
+
+ val = (u64) msm_readl(gmu->mmio + (lo << 2));
+ val |= ((u64) msm_readl(gmu->mmio + (hi << 2)) << 32);
+
+ return val;
+}
+
#define gmu_poll_timeout(gmu, addr, val, cond, interval, timeout) \
readl_poll_timeout((gmu)->mmio + ((addr) << 2), val, cond, \
interval, timeout)
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v4 4/4] drm/msm/a6xx: Add devfreq support for a6xx
Implement routines to estimate GPU busy time and fetching the
current frequency for the polling interval. This is required by
the devfreq framework which recommends a frequency change if needed.
The driver code then tries to set this new frequency on the GPU by
sending an Out Of Band(OOB) request to the GMU.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 38 +++
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 3 ++-
4 files changed, 65 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 613d639..5b65873 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -61,7 +61,7 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
}
-static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
+static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
{
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
@@ -78,7 +78,37 @@ static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
a6xx_gmu_set_oob(gmu, GMU_OOB_DCVS_SET);
a6xx_gmu_clear_oob(gmu, GMU_OOB_DCVS_SET);
- return gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
+ ret = gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
+ if (ret)
+ dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
+
+ gmu->freq = gmu->gpu_freqs[index];
+}
+
+void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
+ u32 perf_index = 0;
+
+ if (freq == gmu->freq)
+ return;
+
+ for (perf_index = 0; perf_index < gmu->nr_gpu_freqs - 1; perf_index++)
+ if (freq == gmu->gpu_freqs[perf_index])
+ break;
+
+ __a6xx_gmu_set_freq(gmu, perf_index);
+}
+
+unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
+
+ return gmu->freq;
}
static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
@@ -637,7 +667,7 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
ret = a6xx_hfi_start(gmu, GMU_COLD_BOOT);
/* Set the GPU back to the highest power frequency */
- a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
+ __a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
out:
if (ret)
@@ -676,7 +706,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
ret = a6xx_hfi_start(gmu, status);
/* Set the GPU to the highest power frequency */
- a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
+ __a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
out:
/* Make sure to turn off the boot OOB request on error */
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index f34630c..35f765a 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -74,6 +74,8 @@ struct a6xx_gmu {
unsigned long gmu_freqs[4];
u32 cx_arc_votes[4];
+ unsigned long freq;
+
struct a6xx_hfi_queue queues[2];
struct tasklet_struct hfi_tasklet;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 5f36b8d..e4ac95f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -7,6 +7,8 @@
#include "a6xx_gpu.h"
#include "a6xx_gmu.xml.h"
+#include
+
static inline bool _a6xx_check_idle(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -682,6 +684,8 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
gpu->needs_hw_init = true;
+ msm_gpu_resume_devfreq(gpu);
+
return ret;
}
@@ -690,6 +694,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ devfreq_suspend_device(gpu->devfreq.devfreq);
+
/*
* Make sure the GMU is idle before continuing (because some transitions
* may use VBIF
@@ -753,6 +759,24 @@ static void a6xx_destroy(struct msm_gpu *gpu)
kfree(a6xx_gpu);
}
+static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ u64 busy_cycles;
+ unsigned long busy_time;
+
+ busy_cycles = gmu_read64(&a6xx_gpu->gmu,
+ REG_A6XX_GMU_CX_GMU_POWER_COUNTER_XOCLK_0_L,
+
[v4 1/4] drm/msm: suspend devfreq on init
Devfreq turns on and starts recommending power level as soon as it is initialized. The GPU is still not powered on by the time the devfreq init happens and this leads to problems on GPU's where register access is needed to get/set power levels. So we start suspended and only restart devfreq when GPU is powered on. Signed-off-by: Sharat Masetty --- drivers/gpu/drm/msm/msm_gpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index 46e6b82..3378a9d 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -105,6 +105,8 @@ static void msm_devfreq_init(struct msm_gpu *gpu) dev_err(&gpu->pdev->dev, "Couldn't initialize GPU devfreq\n"); gpu->devfreq.devfreq = NULL; } + + devfreq_suspend_device(gpu->devfreq.devfreq); } static int enable_pwrrail(struct msm_gpu *gpu) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v4 3/4] drm/msm: re-factor devfreq code
The devfreq framework requires the drivers to provide busy time estimations.
The GPU driver relies on the hardware performance counteres for the busy time
estimations, but different hardware revisions have counters which can be
sourced from different clocks. So the busy time estimation will be target
dependent. Additionally on targets where the clocks are completely controlled
by the on chip microcontroller, fetching and setting the current GPU frequency
will be different. This patch aims to embrace these differences by re-factoring
the devfreq code a bit.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 +
drivers/gpu/drm/msm/msm_gpu.c | 43 ---
drivers/gpu/drm/msm/msm_gpu.h | 5 +++-
3 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 6a68493..40b4f8a 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1436,12 +1436,20 @@ static struct msm_ringbuffer *a5xx_active_ring(struct
msm_gpu *gpu)
return a5xx_gpu->cur_ring;
}
-static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t *value)
+static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
{
- *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
- REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+ u64 busy_cycles;
+ unsigned long busy_time;
- return 0;
+ busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
+ REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+
+ busy_time = (busy_cycles - gpu->devfreq.busy_cycles) /
+ (clk_get_rate(gpu->core_clk) / 100);
+
+ gpu->devfreq.busy_cycles = busy_cycles;
+
+ return busy_time;
}
static const struct adreno_gpu_funcs funcs = {
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 3378a9d..11aac83 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -41,7 +41,11 @@ static int msm_devfreq_target(struct device *dev, unsigned
long *freq,
if (IS_ERR(opp))
return PTR_ERR(opp);
- clk_set_rate(gpu->core_clk, *freq);
+ if (gpu->funcs->gpu_set_freq)
+ gpu->funcs->gpu_set_freq(gpu, (u64)*freq);
+ else
+ clk_set_rate(gpu->core_clk, *freq);
+
dev_pm_opp_put(opp);
return 0;
@@ -51,16 +55,14 @@ static int msm_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *status)
{
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
- u64 cycles;
- u32 freq = ((u32) status->current_frequency) / 100;
ktime_t time;
- status->current_frequency = (unsigned long) clk_get_rate(gpu->core_clk);
- gpu->funcs->gpu_busy(gpu, &cycles);
-
- status->busy_time = ((u32) (cycles - gpu->devfreq.busy_cycles)) / freq;
+ if (gpu->funcs->gpu_get_freq)
+ status->current_frequency = gpu->funcs->gpu_get_freq(gpu);
+ else
+ status->current_frequency = clk_get_rate(gpu->core_clk);
- gpu->devfreq.busy_cycles = cycles;
+ status->busy_time = gpu->funcs->gpu_busy(gpu);
time = ktime_get();
status->total_time = ktime_us_delta(time, gpu->devfreq.time);
@@ -73,7 +75,10 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
unsigned long *freq)
{
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
- *freq = (unsigned long) clk_get_rate(gpu->core_clk);
+ if (gpu->funcs->gpu_get_freq)
+ *freq = gpu->funcs->gpu_get_freq(gpu);
+ else
+ *freq = clk_get_rate(gpu->core_clk);
return 0;
}
@@ -88,7 +93,7 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
unsigned long *freq)
static void msm_devfreq_init(struct msm_gpu *gpu)
{
/* We need target support to do devfreq */
- if (!gpu->funcs->gpu_busy || !gpu->core_clk)
+ if (!gpu->funcs->gpu_busy)
return;
msm_devfreq_profile.initial_freq = gpu->fast_rate;
@@ -186,6 +191,14 @@ static int disable_axi(struct msm_gpu *gpu)
return 0;
}
+void msm_gpu_resume_devfreq(struct msm_gpu *gpu)
+{
+ gpu->devfreq.busy_cycles = 0;
+ gpu->devfreq.time = ktime_get();
+
+ devfreq_resume_device(gpu->devfreq.devfreq);
+}
+
int msm_gpu_pm_resume(struct msm_gpu *gpu)
{
int ret;
@@ -204,12 +217,7 @@ int msm_gpu_pm_resume(struct msm_gpu *gpu)
if (ret)
return ret;
- if (gpu->devfreq.devfreq) {
- gpu->devfreq.busy_cycles = 0;
- gpu->devfreq.time = ktime_get();
-
- devfreq_resume_device(gpu->devfreq.devfreq);
- }
+ msm_gpu_resume_devfreq(gpu);
gpu->needs_hw_init = true;
@@ -222,8 +230,7 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
Re: [PATCH] drm/meson: fix max mode_config height/width
On Thu, Oct 04, 2018 at 10:42:43AM +0200, Neil Armstrong wrote:
> The mode_config max_width/max_height determines the maximum framebuffer
> size the pixel reader can handle. But the values were set thinking they
> were determining the maximum screen dimensions.
>
> This patch changes the values to the maximum height/width the CANVAS block
> can handle rounded to some coherent values.
>
> Fixes: a41e82e6c457 ("drm/meson: Add support for components")
> Signed-off-by: Neil Armstrong
It's both. Grep for all the callers of ->fill_modes and you'll see that
this limit is also used to filter max screen sizes.
If you want to change this, then I think we need a new
mode_config.fb_max_width/height, which if non-zero, would extend the limit
for fbs.
There's also the problem that if you extend this for fbs, then there's no
check anymore in the atomic_commit paths (or legacy modeset), so that
needs to be addressed somehow too.
Bunch of igt to make sure we're not missing anything would be sweet on
top, e.g. e.g. trying to set a mode over the limit and making sure it
fails.
Cheers, Daniel
> ---
> drivers/gpu/drm/meson/meson_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index d344312..2e29968 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -243,8 +243,8 @@ static int meson_drv_bind_master(struct device *dev, bool
> has_components)
> goto free_drm;
>
> drm_mode_config_init(drm);
> - drm->mode_config.max_width = 3840;
> - drm->mode_config.max_height = 2160;
> + drm->mode_config.max_width = 16384;
> + drm->mode_config.max_height = 8192;
> drm->mode_config.funcs = &meson_mode_config_funcs;
>
> /* Hardware Initialization */
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: fb-helper: Reject all pixel format changing requests
On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> drm fbdev emulation doesn't support changing the pixel format at all,
> so reject all pixel format changing requests.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eugeniy Paltsev
> ---
> Changes v1->v2:
> * Reject all pixel format changing request, not just the invalid ones.
>
> drivers/gpu/drm/drm_fb_helper.c | 91
> -
> 1 file changed, 26 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 16ec93b75dbf..48598d7f673f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1580,6 +1580,25 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned
> int cmd,
> }
> EXPORT_SYMBOL(drm_fb_helper_ioctl);
>
> +static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo *var_1,
> + const struct fb_var_screeninfo *var_2)
> +{
> + return var_1->bits_per_pixel == var_2->bits_per_pixel &&
> +var_1->grayscale == var_2->grayscale &&
> +var_1->red.offset == var_2->red.offset &&
> +var_1->red.length == var_2->red.length &&
> +var_1->red.msb_right == var_2->red.msb_right &&
> +var_1->green.offset == var_2->green.offset &&
> +var_1->green.length == var_2->green.length &&
> +var_1->green.msb_right == var_2->green.msb_right &&
> +var_1->blue.offset == var_2->blue.offset &&
> +var_1->blue.length == var_2->blue.length &&
> +var_1->blue.msb_right == var_2->blue.msb_right &&
> +var_1->transp.offset == var_2->transp.offset &&
> +var_1->transp.length == var_2->transp.length &&
> +var_1->transp.msb_right == var_2->transp.msb_right;
> +}
Could have shortened a bit with memcmp() but this works too.
Reviewed-by: Ville Syrjälä
I suppose we really should be doing the same for most of the rest of
var_screeninfo as we don't allow changing the timings/etc. either.
> +
> /**
> * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
> * @var: screeninfo to check
> @@ -1590,7 +1609,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> {
> struct drm_fb_helper *fb_helper = info->par;
> struct drm_framebuffer *fb = fb_helper->fb;
> - int depth;
>
> if (var->pixclock != 0 || in_dbg_master())
> return -EINVAL;
> @@ -1610,72 +1628,15 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> return -EINVAL;
> }
>
> - switch (var->bits_per_pixel) {
> - case 16:
> - depth = (var->green.length == 6) ? 16 : 15;
> - break;
> - case 32:
> - depth = (var->transp.length > 0) ? 32 : 24;
> - break;
> - default:
> - depth = var->bits_per_pixel;
> - break;
> - }
> -
> - switch (depth) {
> - case 8:
> - var->red.offset = 0;
> - var->green.offset = 0;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 15:
> - var->red.offset = 10;
> - var->green.offset = 5;
> - var->blue.offset = 0;
> - var->red.length = 5;
> - var->green.length = 5;
> - var->blue.length = 5;
> - var->transp.length = 1;
> - var->transp.offset = 15;
> - break;
> - case 16:
> - var->red.offset = 11;
> - var->green.offset = 5;
> - var->blue.offset = 0;
> - var->red.length = 5;
> - var->green.length = 6;
> - var->blue.length = 5;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 24:
> - var->red.offset = 16;
> - var->green.offset = 8;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 32:
> - var->red.offset = 16;
> - var->green.offset = 8;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 8;
> - var->transp.offset = 24;
> - break;
> - default:
> + /*
> + * drm fbdev emulation doesn't support changing the pixel format at all,
> + * so reject all pixel format changing requests.
> + */
> + if (!drm_fb_pixel_format_equal(var, &info->var)) {
> +
[PATCH] dim: Add range-diff convenience wrapper
range-diff is awesome, but the interface is a bit silly. Add a bunch
of shortcuts, inspired by what git diff does.
Signed-off-by: Daniel Vetter
---
dim | 13 +
dim.rst | 8
2 files changed, 21 insertions(+)
diff --git a/dim b/dim
index 12c80e2051b6..c4663aca6b5c 100755
--- a/dim
+++ b/dim
@@ -475,6 +475,19 @@ function dim_retip
git rebase --onto $new_upstream $upstream $branch "$@"
}
+function dim_range_diff
+{
+ local branch
+
+ branch=${1:-@\{1\}}
+
+ if [[ $branch != "" && $(git rev-parse $branch | wc -l) -eq 1 ]] ; then
+ git range-diff $branch...HEAD
+ else
+ git range-diff "$@"
+ fi
+}
+
# update for-linux-next and for-linux-next-fixes branches
function update_linux_next # branch next next-fixes fixes
{
diff --git a/dim.rst b/dim.rst
index b149fa39445e..9e41133aeb8d 100644
--- a/dim.rst
+++ b/dim.rst
@@ -95,6 +95,14 @@ retip [*branch*] [*git-rebase option* ...]
Rebase the given local branch, current branch by default, onto drm-tip. Options
after the branch will be passed to **git-rebase**.
+range-diff [ *commit-ish* | *git-range-diff options* ]
+--
+
+Convenience wrapper around the git range-diff command which automatically
+compares against HEAD if you only specify a commit-ish. In all other cases
+forwards to git range-diff. Defaults to @{1}, which is very useful for
reviewing
+rebases.
+
COMMANDS FOR COMMITTERS AND MAINTAINERS
===
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: fb-helper: Reject all pixel format changing requests
On Thu, Oct 04, 2018 at 01:34:22PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> > drm fbdev emulation doesn't support changing the pixel format at all,
> > so reject all pixel format changing requests.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Eugeniy Paltsev
> > ---
> > Changes v1->v2:
> > * Reject all pixel format changing request, not just the invalid ones.
> >
> > drivers/gpu/drm/drm_fb_helper.c | 91
> > -
> > 1 file changed, 26 insertions(+), 65 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 16ec93b75dbf..48598d7f673f 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1580,6 +1580,25 @@ int drm_fb_helper_ioctl(struct fb_info *info,
> > unsigned int cmd,
> > }
> > EXPORT_SYMBOL(drm_fb_helper_ioctl);
> >
> > +static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo
> > *var_1,
> > + const struct fb_var_screeninfo *var_2)
> > +{
> > + return var_1->bits_per_pixel == var_2->bits_per_pixel &&
> > + var_1->grayscale == var_2->grayscale &&
> > + var_1->red.offset == var_2->red.offset &&
> > + var_1->red.length == var_2->red.length &&
> > + var_1->red.msb_right == var_2->red.msb_right &&
> > + var_1->green.offset == var_2->green.offset &&
> > + var_1->green.length == var_2->green.length &&
> > + var_1->green.msb_right == var_2->green.msb_right &&
> > + var_1->blue.offset == var_2->blue.offset &&
> > + var_1->blue.length == var_2->blue.length &&
> > + var_1->blue.msb_right == var_2->blue.msb_right &&
> > + var_1->transp.offset == var_2->transp.offset &&
> > + var_1->transp.length == var_2->transp.length &&
> > + var_1->transp.msb_right == var_2->transp.msb_right;
> > +}
>
> Could have shortened a bit with memcmp() but this works too.
I'm always vary of memcmp with structs that might have padding and stuff.
> Reviewed-by: Ville Syrjälä
>
> I suppose we really should be doing the same for most of the rest of
> var_screeninfo as we don't allow changing the timings/etc. either.
Timing at least doens't have an immediate correctness impact of userspace
rendering the wrong format :-)
Thanks for review&patch, applied to drm-misc-fixes.
-Daniel
>
> > +
> > /**
> > * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
> > * @var: screeninfo to check
> > @@ -1590,7 +1609,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> > *var,
> > {
> > struct drm_fb_helper *fb_helper = info->par;
> > struct drm_framebuffer *fb = fb_helper->fb;
> > - int depth;
> >
> > if (var->pixclock != 0 || in_dbg_master())
> > return -EINVAL;
> > @@ -1610,72 +1628,15 @@ int drm_fb_helper_check_var(struct
> > fb_var_screeninfo *var,
> > return -EINVAL;
> > }
> >
> > - switch (var->bits_per_pixel) {
> > - case 16:
> > - depth = (var->green.length == 6) ? 16 : 15;
> > - break;
> > - case 32:
> > - depth = (var->transp.length > 0) ? 32 : 24;
> > - break;
> > - default:
> > - depth = var->bits_per_pixel;
> > - break;
> > - }
> > -
> > - switch (depth) {
> > - case 8:
> > - var->red.offset = 0;
> > - var->green.offset = 0;
> > - var->blue.offset = 0;
> > - var->red.length = 8;
> > - var->green.length = 8;
> > - var->blue.length = 8;
> > - var->transp.length = 0;
> > - var->transp.offset = 0;
> > - break;
> > - case 15:
> > - var->red.offset = 10;
> > - var->green.offset = 5;
> > - var->blue.offset = 0;
> > - var->red.length = 5;
> > - var->green.length = 5;
> > - var->blue.length = 5;
> > - var->transp.length = 1;
> > - var->transp.offset = 15;
> > - break;
> > - case 16:
> > - var->red.offset = 11;
> > - var->green.offset = 5;
> > - var->blue.offset = 0;
> > - var->red.length = 5;
> > - var->green.length = 6;
> > - var->blue.length = 5;
> > - var->transp.length = 0;
> > - var->transp.offset = 0;
> > - break;
> > - case 24:
> > - var->red.offset = 16;
> > - var->green.offset = 8;
> > - var->blue.offset = 0;
> > - var->red.length = 8;
> > - var->green.length = 8;
> > - var->blue.length = 8;
> > - var->transp.length = 0;
> > - var->transp.offset = 0;
> > - break;
> > - case 32:
> > - var->red.offset = 16;
> > - var->green.offset = 8;
> > - var->blue.offset = 0;
> > - var->red.length = 8;
> > - var->
[PATCH] dim: Add range-diff convenience wrapper
range-diff is awesome, but the interface is a bit silly. Add a bunch
of shortcuts, inspired by what git diff does.
v2: Add it to the developer commmands list. With this dim range-diff
is useable on any git repo, not just a dim managed one.
Signed-off-by: Daniel Vetter
---
dim | 14 ++
dim.rst | 8
2 files changed, 22 insertions(+)
diff --git a/dim b/dim
index 12c80e2051b6..f8079aa2dc4d 100755
--- a/dim
+++ b/dim
@@ -475,6 +475,19 @@ function dim_retip
git rebase --onto $new_upstream $upstream $branch "$@"
}
+function dim_range_diff
+{
+ local branch
+
+ branch=${1:-@\{1\}}
+
+ if [[ $branch != "" && $(git rev-parse $branch | wc -l) -eq 1 ]] ; then
+ git range-diff $branch...HEAD
+ else
+ git range-diff "$@"
+ fi
+}
+
# update for-linux-next and for-linux-next-fixes branches
function update_linux_next # branch next next-fixes fixes
{
@@ -2188,6 +2201,7 @@ function list_developer_commands
"cite"
"fixes"
"retip"
+ "range-diff"
"sparse"
"tc"
# help commands
diff --git a/dim.rst b/dim.rst
index b149fa39445e..9e41133aeb8d 100644
--- a/dim.rst
+++ b/dim.rst
@@ -95,6 +95,14 @@ retip [*branch*] [*git-rebase option* ...]
Rebase the given local branch, current branch by default, onto drm-tip. Options
after the branch will be passed to **git-rebase**.
+range-diff [ *commit-ish* | *git-range-diff options* ]
+--
+
+Convenience wrapper around the git range-diff command which automatically
+compares against HEAD if you only specify a commit-ish. In all other cases
+forwards to git range-diff. Defaults to @{1}, which is very useful for
reviewing
+rebases.
+
COMMANDS FOR COMMITTERS AND MAINTAINERS
===
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: fb-helper: Reject all pixel format changing requests
On Thu, Oct 04, 2018 at 12:49:38PM +0200, Daniel Vetter wrote:
> On Thu, Oct 04, 2018 at 01:34:22PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> > > drm fbdev emulation doesn't support changing the pixel format at all,
> > > so reject all pixel format changing requests.
> > >
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Eugeniy Paltsev
> > > ---
> > > Changes v1->v2:
> > > * Reject all pixel format changing request, not just the invalid ones.
> > >
> > > drivers/gpu/drm/drm_fb_helper.c | 91
> > > -
> > > 1 file changed, 26 insertions(+), 65 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 16ec93b75dbf..48598d7f673f 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -1580,6 +1580,25 @@ int drm_fb_helper_ioctl(struct fb_info *info,
> > > unsigned int cmd,
> > > }
> > > EXPORT_SYMBOL(drm_fb_helper_ioctl);
> > >
> > > +static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo
> > > *var_1,
> > > + const struct fb_var_screeninfo *var_2)
> > > +{
> > > + return var_1->bits_per_pixel == var_2->bits_per_pixel &&
> > > +var_1->grayscale == var_2->grayscale &&
> > > +var_1->red.offset == var_2->red.offset &&
> > > +var_1->red.length == var_2->red.length &&
> > > +var_1->red.msb_right == var_2->red.msb_right &&
> > > +var_1->green.offset == var_2->green.offset &&
> > > +var_1->green.length == var_2->green.length &&
> > > +var_1->green.msb_right == var_2->green.msb_right &&
> > > +var_1->blue.offset == var_2->blue.offset &&
> > > +var_1->blue.length == var_2->blue.length &&
> > > +var_1->blue.msb_right == var_2->blue.msb_right &&
> > > +var_1->transp.offset == var_2->transp.offset &&
> > > +var_1->transp.length == var_2->transp.length &&
> > > +var_1->transp.msb_right == var_2->transp.msb_right;
> > > +}
> >
> > Could have shortened a bit with memcmp() but this works too.
>
> I'm always vary of memcmp with structs that might have padding and stuff.
These are uabi so padding would be rather bad.
>
> > Reviewed-by: Ville Syrjälä
> >
> > I suppose we really should be doing the same for most of the rest of
> > var_screeninfo as we don't allow changing the timings/etc. either.
>
> Timing at least doens't have an immediate correctness impact of userspace
> rendering the wrong format :-)
>
> Thanks for review&patch, applied to drm-misc-fixes.
> -Daniel
>
> >
> > > +
> > > /**
> > > * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
> > > * @var: screeninfo to check
> > > @@ -1590,7 +1609,6 @@ int drm_fb_helper_check_var(struct
> > > fb_var_screeninfo *var,
> > > {
> > > struct drm_fb_helper *fb_helper = info->par;
> > > struct drm_framebuffer *fb = fb_helper->fb;
> > > - int depth;
> > >
> > > if (var->pixclock != 0 || in_dbg_master())
> > > return -EINVAL;
> > > @@ -1610,72 +1628,15 @@ int drm_fb_helper_check_var(struct
> > > fb_var_screeninfo *var,
> > > return -EINVAL;
> > > }
> > >
> > > - switch (var->bits_per_pixel) {
> > > - case 16:
> > > - depth = (var->green.length == 6) ? 16 : 15;
> > > - break;
> > > - case 32:
> > > - depth = (var->transp.length > 0) ? 32 : 24;
> > > - break;
> > > - default:
> > > - depth = var->bits_per_pixel;
> > > - break;
> > > - }
> > > -
> > > - switch (depth) {
> > > - case 8:
> > > - var->red.offset = 0;
> > > - var->green.offset = 0;
> > > - var->blue.offset = 0;
> > > - var->red.length = 8;
> > > - var->green.length = 8;
> > > - var->blue.length = 8;
> > > - var->transp.length = 0;
> > > - var->transp.offset = 0;
> > > - break;
> > > - case 15:
> > > - var->red.offset = 10;
> > > - var->green.offset = 5;
> > > - var->blue.offset = 0;
> > > - var->red.length = 5;
> > > - var->green.length = 5;
> > > - var->blue.length = 5;
> > > - var->transp.length = 1;
> > > - var->transp.offset = 15;
> > > - break;
> > > - case 16:
> > > - var->red.offset = 11;
> > > - var->green.offset = 5;
> > > - var->blue.offset = 0;
> > > - var->red.length = 5;
> > > - var->green.length = 6;
> > > - var->blue.length = 5;
> > > - var->transp.length = 0;
> > > - var->transp.offset = 0;
> > > - break;
> > > - case 24:
> > > - var->red.offset = 16;
> > > - var->green.offset = 8;
> > > - var->blue.offset = 0;
> > > - var->red.length = 8;
> > > - var->green.length = 8;
> > > - var->blue.length = 8;
> > > - var->transp.length = 0;
> > > - var->tran
[Bug 108130] [CI][DRMTIP] igt@* - timeout - Unknown subtest
https://bugs.freedesktop.org/show_bug.cgi?id=108130 Petri Latvala changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Petri Latvala --- Commit 48432b44832c382f5001238524c9f888f34a8f24 removes the harmless but misleading message when a timeout happens and all subtests are already executed. -- 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 v10 1/2] drm: Introduce new DRM_FORMAT_XYUV
On Wed, 2018-10-03 at 08:07 +, Alexandru-Cosmin Gheorghe wrote:
> On Wed, Oct 03, 2018 at 06:39:00AM +, Lisovskiy, Stanislav wrote:
> > On Tue, 2018-10-02 at 15:28 +, Alexandru-Cosmin Gheorghe wrote:
> > > Hi,
> > >
> > > On Tue, Oct 02, 2018 at 02:15:42PM +0300, Stanislav Lisovskiy
> > > wrote:
> > > > v5: This is YUV444 packed format same as AYUV, but without
> > > > alpha,
> > > > as supported by i915.
> > > >
> > > > v6: Removed unneeded initializer for new XYUV format.
> > > >
> > > > v7: Added is_yuv field initialization according to latest
> > > > drm_fourcc format structure initialization changes.
> > > >
> > > > v8: Edited commit message to be more clear about skl+, renamed
> > > > PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this
> > > > format
> > > > doesn't support per-pixel alpha. Fixed minor code issues.
> > > >
> > > > v9: Moved DRM format check to proper place in
> > > > intel_framebuffer_init.
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy > > > om>
> > >
> > > Reviewed-by: Alexandru Gheorghe > > m>
> > >
> > > I'm planning of sending a new version with my series[1], do you
> > > think
> > > this patch will get merged soon, or is there anything else that
> > > needs
> > > to be done.
> > >
> > > [1] https://lists.freedesktop.org/archives/dri-devel/2018-
> > > August/186963.html
> >
> > Hi,
> >
> > I had to implement IGT test case and xf86-video-intel support for
> > this
> > new format(in order to check that it works with gstreamer as we
> > have
> > userspace requirement for this change), so currently I guess all
> > the
> > requirements are met. I might need to do some
> > minor changes in those patches though, once I get some feedback.
>
> A bit offtopic do we need userspace for adding a new fourcc as well,
> I thought those are extempted from "must have userspace rule".
Well, at least in my case I was asked to do that.
Interesting task though :)
Currently I check with GStreamer, so that video works both in textured
and sprite format.
BTW, I have changed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV so that it
is compliant with your change. As I understood we've agreed to have it
called that way instead of DRM_FORMAT_XYUV. Are you ok with that?
I will then send a new patch for IGT, xf86-video-intel and drm today.
> >
> > >
> > > > ---
> > > > drivers/gpu/drm/drm_fourcc.c | 1 +
> > > > include/uapi/drm/drm_fourcc.h | 1 +
> > > > 2 files changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_fourcc.c
> > > > b/drivers/gpu/drm/drm_fourcc.c
> > > > index be1d6aaef651..60752d0be9d8 100644
> > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > > @@ -190,6 +190,7 @@ const struct drm_format_info
> > > > *__drm_format_info(u32 format)
> > > > { .format = DRM_FORMAT_UYVY,.d
> > > > epth
> > > > = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub =
> > > > 1,
> > > > .is_yuv = true },
> > > > { .format = DRM_FORMAT_VYUY,.d
> > > > epth
> > > > = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub =
> > > > 1,
> > > > .is_yuv = true },
> > > > { .format = DRM_FORMAT_AYUV,.d
> > > > epth
> > > > = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub =
> > > > 1,
> > > > .has_alpha = true, .is_yuv = true },
> > > > + { .format = DRM_FORMAT_XYUV,.d
> > > > epth
> > > > = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub =
> > > > 1,
> > > > .is_yuv = true },
> > > > };
> > > >
> > > > unsigned int i;
> > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > b/include/uapi/drm/drm_fourcc.h
> > > > index 139632b87181..88d2e491f40c 100644
> > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > @@ -151,6 +151,7 @@ extern "C" {
> > > > #define DRM_FORMAT_VYUYfourcc_code('V', 'Y',
> > > > 'U',
> > > > 'Y') /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > > >
> > > > #define DRM_FORMAT_AYUVfourcc_code('A', 'Y',
> > > > 'U',
> > > > 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > > > +#define DRM_FORMAT_XYUVfourcc_code('X', 'Y',
> > > > 'U',
> > > > 'V') /* [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
> > > >
> > > > /*
> > > > * 2 plane RGB + A
> > > > --
> > > > 2.17.1
> > > >
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > >
> >
> > --
> > Best Regards,
> >
> > Lisovskiy Stanislav
>
>
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] drm: Introduce new DRM_FORMAT_XYUV
On Thu, Oct 04, 2018 at 12:04:57PM +, Lisovskiy, Stanislav wrote:
> On Wed, 2018-10-03 at 08:07 +, Alexandru-Cosmin Gheorghe wrote:
> > On Wed, Oct 03, 2018 at 06:39:00AM +, Lisovskiy, Stanislav wrote:
> > > On Tue, 2018-10-02 at 15:28 +, Alexandru-Cosmin Gheorghe wrote:
> > > > Hi,
> > > >
> > > > On Tue, Oct 02, 2018 at 02:15:42PM +0300, Stanislav Lisovskiy
> > > > wrote:
> > > > > v5: This is YUV444 packed format same as AYUV, but without
> > > > > alpha,
> > > > > as supported by i915.
> > > > >
> > > > > v6: Removed unneeded initializer for new XYUV format.
> > > > >
> > > > > v7: Added is_yuv field initialization according to latest
> > > > > drm_fourcc format structure initialization changes.
> > > > >
> > > > > v8: Edited commit message to be more clear about skl+, renamed
> > > > > PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this
> > > > > format
> > > > > doesn't support per-pixel alpha. Fixed minor code issues.
> > > > >
> > > > > v9: Moved DRM format check to proper place in
> > > > > intel_framebuffer_init.
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy > > > > om>
> > > >
> > > > Reviewed-by: Alexandru Gheorghe > > > m>
> > > >
> > > > I'm planning of sending a new version with my series[1], do you
> > > > think
> > > > this patch will get merged soon, or is there anything else that
> > > > needs
> > > > to be done.
> > > >
> > > > [1] https://lists.freedesktop.org/archives/dri-devel/2018-
> > > > August/186963.html
> > >
> > > Hi,
> > >
> > > I had to implement IGT test case and xf86-video-intel support for
> > > this
> > > new format(in order to check that it works with gstreamer as we
> > > have
> > > userspace requirement for this change), so currently I guess all
> > > the
> > > requirements are met. I might need to do some
> > > minor changes in those patches though, once I get some feedback.
> >
> > A bit offtopic do we need userspace for adding a new fourcc as well,
> > I thought those are extempted from "must have userspace rule".
>
> Well, at least in my case I was asked to do that.
> Interesting task though :)
> Currently I check with GStreamer, so that video works both in textured
> and sprite format.
> BTW, I have changed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV so that it
> is compliant with your change. As I understood we've agreed to have it
> called that way instead of DRM_FORMAT_XYUV. Are you ok with that?
>
Yes DRM_FORMAT_XYUV, it's fine by me.
Thanks.
> I will then send a new patch for IGT, xf86-video-intel and drm today.
>
> > >
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/drm_fourcc.c | 1 +
> > > > > include/uapi/drm/drm_fourcc.h | 1 +
> > > > > 2 files changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_fourcc.c
> > > > > b/drivers/gpu/drm/drm_fourcc.c
> > > > > index be1d6aaef651..60752d0be9d8 100644
> > > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > > > @@ -190,6 +190,7 @@ const struct drm_format_info
> > > > > *__drm_format_info(u32 format)
> > > > > { .format = DRM_FORMAT_UYVY,.d
> > > > > epth
> > > > > = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub =
> > > > > 1,
> > > > > .is_yuv = true },
> > > > > { .format = DRM_FORMAT_VYUY,.d
> > > > > epth
> > > > > = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub =
> > > > > 1,
> > > > > .is_yuv = true },
> > > > > { .format = DRM_FORMAT_AYUV,.d
> > > > > epth
> > > > > = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub =
> > > > > 1,
> > > > > .has_alpha = true, .is_yuv = true },
> > > > > + { .format = DRM_FORMAT_XYUV,.d
> > > > > epth
> > > > > = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub =
> > > > > 1,
> > > > > .is_yuv = true },
> > > > > };
> > > > >
> > > > > unsigned int i;
> > > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > > b/include/uapi/drm/drm_fourcc.h
> > > > > index 139632b87181..88d2e491f40c 100644
> > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > @@ -151,6 +151,7 @@ extern "C" {
> > > > > #define DRM_FORMAT_VYUY fourcc_code('V', 'Y',
> > > > > 'U',
> > > > > 'Y') /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > > > >
> > > > > #define DRM_FORMAT_AYUV fourcc_code('A', 'Y',
> > > > > 'U',
> > > > > 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > > > > +#define DRM_FORMAT_XYUV fourcc_code('X', 'Y',
> > > > > 'U',
> > > > > 'V') /* [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
> > > > >
> > > > > /*
> > > > > * 2 plane RGB + A
> > > > > --
> > > > > 2.17.1
> > > > >
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > >
> > >
Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
On Thu, Oct 04, 2018 at 05:45:13PM +0530, Souptick Joarder wrote: > On Thu, Oct 4, 2018 at 3:45 AM Russell King - ARM Linux > wrote: > > > > On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote: > > > On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote: > > > > These are the approaches which could have been taken to handle > > > > this scenario - > > > > > > > > * Replace vm_insert_page with vmf_insert_page and then write few > > > >extra lines of code to convert VM_FAULT_CODE to errno which > > > >makes driver users more complex ( also the reverse mapping errno to > > > >VM_FAULT_CODE have been cleaned up as part of vm_fault_t migration , > > > >not preferred to introduce anything similar again) > > > > > > > > * Maintain both vm_insert_page and vmf_insert_page and use it in > > > >respective places. But it won't gurantee that vm_insert_page will > > > >never be used in #PF context. > > > > > > > > * Introduce a similar API like vm_insert_page, convert all non #PF > > > >consumer to use it and finally remove vm_insert_page by converting > > > >it to vmf_insert_page. > > > > > > > > And the 3rd approach was taken by introducing vm_insert_kmem_page(). > > > > > > > > In short, vmf_insert_page will be used in page fault handlers > > > > context and vm_insert_kmem_page will be used to map kernel > > > > memory to user vma outside page fault handlers context. > > > > > > As far as I can tell, vm_insert_kmem_page() is line-for-line identical > > > with vm_insert_page(). Seriously, here's a diff I just did: > > > > > > -static int insert_page(struct vm_area_struct *vma, unsigned long addr, > > > - struct page *page, pgprot_t prot) > > > +static int insert_kmem_page(struct vm_area_struct *vma, unsigned long > > > addr, > > > + struct page *page, pgprot_t prot) > > > - /* Ok, finally just insert the thing.. */ > > > -int vm_insert_page(struct vm_area_struct *vma, unsigned long addr, > > > +int vm_insert_kmem_page(struct vm_area_struct *vma, unsigned long addr, > > > - return insert_page(vma, addr, page, vma->vm_page_prot); > > > + return insert_kmem_page(vma, addr, page, vma->vm_page_prot); > > > -EXPORT_SYMBOL(vm_insert_page); > > > +EXPORT_SYMBOL(vm_insert_kmem_page); > > > > > > What on earth are you trying to do? > > > > > Reading the commit log, it seems that the intention is to split out > > vm_insert_page() used outside of page-fault handling with the use > > within page-fault handling, so that different return codes can be > > used. > > > > I don't see that justifies the code duplication - can't > > vm_insert_page() and vm_insert_kmem_page() use the same mechanics > > to do their job, and just translate the error code from the most- > > specific to the least-specific error code? Do we really need two > > copies of the same code just to return different error codes. > > Sorry about it. > can I take below approach in a patch series -> > > create a wrapper function vm_insert_kmem_page using vm_insert_page. > Convert all the non #PF users to use it. > Then make vm_insert_page static and convert inline vmf_insert_page to caller. I'm confused, what are you trying to do? It seems that we already have: vm_insert_page() - returns an errno vmf_insert_page() - returns a VM_FAULT_* code From what I _think_ you're saying, you're trying to provide vm_insert_kmem_page() as a direct replacement for the existing vm_insert_page(), and then make vm_insert_page() behave as per vmf_insert_page(), so we end up with: vm_insert_kmem_page() - returns an errno vm_insert_page() - returns a VM_FAULT_* code vmf_insert_page() - returns a VM_FAULT_* code and is identical to vm_insert_page() Given that the documentation for vm_insert_page() says: * Usually this function is called from f_op->mmap() handler * under mm->mmap_sem write-lock, so it can change vma->vm_flags. * Caller must set VM_MIXEDMAP on vma if it wants to call this * function from other places, for example from page-fault handler. this says that the "usual" use method for vm_insert_page() is _outside_ of page fault handling - if it is used _inside_ page fault handling, then it states that additional fixups are required on the VMA. So I don't get why your patch commentry seems to be saying that users of vm_insert_page() outside of page fault handling all need to be patched - isn't this the use case that this function is defined to be handling? If you're going to be changing the semantics, doesn't this create a flag day where we could get new users of vm_insert_page() using the _existing_ semantics merged after you've changed its semantics (eg, the return code)? Maybe I don't understand fully what you're trying to achieve here. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___
[PATCH 3/8] dma-buf: test shared slot allocation when mutex debugging is active
Set shared_max to the number of shared fences right before we release
the lock.
This way every attempt to add a shared fence without previously
reserving a slot will cause an error.
Signed-off-by: Christian König
---
include/linux/reservation.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 5ddb0e143721..2f0ffca35780 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -214,6 +214,11 @@ reservation_object_trylock(struct reservation_object *obj)
static inline void
reservation_object_unlock(struct reservation_object *obj)
{
+#ifdef CONFIG_DEBUG_MUTEXES
+ /* Test shared fence slot reservation */
+ if (obj->fence)
+ obj->fence->shared_max = obj->fence->shared_count;
+#endif
ww_mutex_unlock(&obj->lock);
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] dma-buf: remove shared fence staging in reservation object
No need for that any more. Just replace the list when there isn't enough
room any more for the additional fence.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c | 178 ++
include/linux/reservation.h | 4 -
2 files changed, 58 insertions(+), 124 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 6c95f61a32e7..5825fc336a13 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -68,105 +68,23 @@ EXPORT_SYMBOL(reservation_seqcount_string);
*/
int reservation_object_reserve_shared(struct reservation_object *obj)
{
- struct reservation_object_list *fobj, *old;
- u32 max;
+ struct reservation_object_list *old, *new;
+ unsigned int i, j, k, max;
old = reservation_object_get_list(obj);
if (old && old->shared_max) {
- if (old->shared_count < old->shared_max) {
- /* perform an in-place update */
- kfree(obj->staged);
- obj->staged = NULL;
+ if (old->shared_count < old->shared_max)
return 0;
- } else
+ else
max = old->shared_max * 2;
- } else
- max = 4;
-
- /*
-* resize obj->staged or allocate if it doesn't exist,
-* noop if already correct size
-*/
- fobj = krealloc(obj->staged, offsetof(typeof(*fobj), shared[max]),
- GFP_KERNEL);
- if (!fobj)
- return -ENOMEM;
-
- obj->staged = fobj;
- fobj->shared_max = max;
- return 0;
-}
-EXPORT_SYMBOL(reservation_object_reserve_shared);
-
-static void
-reservation_object_add_shared_inplace(struct reservation_object *obj,
- struct reservation_object_list *fobj,
- struct dma_fence *fence)
-{
- struct dma_fence *signaled = NULL;
- u32 i, signaled_idx;
-
- dma_fence_get(fence);
-
- preempt_disable();
- write_seqcount_begin(&obj->seq);
-
- for (i = 0; i < fobj->shared_count; ++i) {
- struct dma_fence *old_fence;
-
- old_fence = rcu_dereference_protected(fobj->shared[i],
- reservation_object_held(obj));
-
- if (old_fence->context == fence->context) {
- /* memory barrier is added by write_seqcount_begin */
- RCU_INIT_POINTER(fobj->shared[i], fence);
- write_seqcount_end(&obj->seq);
- preempt_enable();
-
- dma_fence_put(old_fence);
- return;
- }
-
- if (!signaled && dma_fence_is_signaled(old_fence)) {
- signaled = old_fence;
- signaled_idx = i;
- }
- }
-
- /*
-* memory barrier is added by write_seqcount_begin,
-* fobj->shared_count is protected by this lock too
-*/
- if (signaled) {
- RCU_INIT_POINTER(fobj->shared[signaled_idx], fence);
} else {
- BUG_ON(fobj->shared_count >= fobj->shared_max);
- RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
- fobj->shared_count++;
+ max = 4;
}
- write_seqcount_end(&obj->seq);
- preempt_enable();
-
- dma_fence_put(signaled);
-}
-
-static void
-reservation_object_add_shared_replace(struct reservation_object *obj,
- struct reservation_object_list *old,
- struct reservation_object_list *fobj,
- struct dma_fence *fence)
-{
- unsigned i, j, k;
-
- dma_fence_get(fence);
-
- if (!old) {
- RCU_INIT_POINTER(fobj->shared[0], fence);
- fobj->shared_count = 1;
- goto done;
- }
+ new = kmalloc(offsetof(typeof(*new), shared[max]), GFP_KERNEL);
+ if (!new)
+ return -ENOMEM;
/*
* no need to bump fence refcounts, rcu_read access
@@ -174,46 +92,45 @@ reservation_object_add_shared_replace(struct
reservation_object *obj,
* references from the old struct are carried over to
* the new.
*/
- for (i = 0, j = 0, k = fobj->shared_max; i < old->shared_count; ++i) {
- struct dma_fence *check;
+ for (i = 0, j = 0, k = max; i < (old ? old->shared_count : 0); ++i) {
+ struct dma_fence *fence;
- check = rcu_dereference_protected(old->shared[i],
- reservation_object_held(obj));
-
- if (check->context == fence->context ||
- dma_fence_is_signaled(check))
- RCU_INIT_POI
[PATCH 2/8] dma-buf: allow reserving more than one shared fence slot
Let's support simultaneous submissions to multiple engines.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c| 13 -
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 2 +-
drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
drivers/gpu/drm/qxl/qxl_release.c| 2 +-
drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 4 ++--
drivers/gpu/drm/v3d/v3d_gem.c| 2 +-
drivers/gpu/drm/vc4/vc4_gem.c| 2 +-
drivers/gpu/drm/vgem/vgem_fence.c| 2 +-
include/linux/reservation.h | 3 ++-
16 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 5825fc336a13..5fb4fd461908 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -56,9 +56,10 @@ const char reservation_seqcount_string[] =
"reservation_seqcount";
EXPORT_SYMBOL(reservation_seqcount_string);
/**
- * reservation_object_reserve_shared - Reserve space to add a shared
- * fence to a reservation_object.
+ * reservation_object_reserve_shared - Reserve space to add shared fences to
+ * a reservation_object.
* @obj: reservation object
+ * @num_fences: number of fences we want to add
*
* Should be called before reservation_object_add_shared_fence(). Must
* be called with obj->lock held.
@@ -66,7 +67,8 @@ EXPORT_SYMBOL(reservation_seqcount_string);
* RETURNS
* Zero for success, or -errno
*/
-int reservation_object_reserve_shared(struct reservation_object *obj)
+int reservation_object_reserve_shared(struct reservation_object *obj,
+ unsigned int num_fences)
{
struct reservation_object_list *old, *new;
unsigned int i, j, k, max;
@@ -74,10 +76,11 @@ int reservation_object_reserve_shared(struct
reservation_object *obj)
old = reservation_object_get_list(obj);
if (old && old->shared_max) {
- if (old->shared_count < old->shared_max)
+ if ((old->shared_count + num_fences) <= old->shared_max)
return 0;
else
- max = old->shared_max * 2;
+ max = max(old->shared_count + num_fences,
+ old->shared_max * 2);
} else {
max = 4;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 8836186eb5ef..3243da67db9e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -955,7 +955,7 @@ static int amdgpu_cs_vm_handling(struct amdgpu_cs_parser *p)
if (r)
return r;
- r = reservation_object_reserve_shared(vm->root.base.bo->tbo.resv);
+ r = reservation_object_reserve_shared(vm->root.base.bo->tbo.resv, 1);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 904014dc5915..cf768acb51dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -640,7 +640,7 @@ int amdgpu_bo_backup_to_shadow(struct amdgpu_device *adev,
bo_addr = amdgpu_bo_gpu_offset(bo);
shadow_addr = amdgpu_bo_gpu_offset(bo->shadow);
- r = reservation_object_reserve_shared(bo->tbo.resv);
+ r = reservation_object_reserve_shared(bo->tbo.resv, 1);
if (r)
goto err;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 6904d794d60a..bdce05183edb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -772,7 +772,7 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device *adev,
ring = container_of(vm->entity.rq->sched, struct amdgpu_ring, sched);
- r = reservation_object_reserve_shared(bo->tbo.resv);
+ r = reservation_object_reserve_shared(bo->tbo.resv, 1);
if (r)
return r;
@@ -1839,7 +1839,7 @@ static int amdgpu_vm_bo_update_mapping(struct
amdgpu_device *adev,
if (r)
goto error_free;
- r = reservation_object_reserve_shared(vm->root.base.bo->tbo.resv);
+ r = reservation_object_reserve_shared(vm->root.base.bo->tbo.resv, 1);
if (r)
goto error_free;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 983e67f19e45..30875f8f2933 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm
[PATCH 4/8] drm/ttm: allow reserving more than one shared slot v2
Let's support simultaneous submissions to multiple engines.
v2: rename the field to num_shared and fix up all users
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 7 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
drivers/gpu/drm/qxl/qxl_release.c| 2 +-
drivers/gpu/drm/radeon/radeon_cs.c | 4 ++--
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_vm.c | 4 ++--
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 12 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 10 +-
include/drm/ttm/ttm_execbuf_util.h | 4 ++--
14 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index df0a059565f9..d0bc0312430c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -536,7 +536,7 @@ static void add_kgd_mem_to_kfd_bo_list(struct kgd_mem *mem,
struct amdgpu_bo *bo = mem->bo;
INIT_LIST_HEAD(&entry->head);
- entry->shared = true;
+ entry->num_shared = 1;
entry->bo = &bo->tbo;
mutex_lock(&process_info->lock);
if (userptr)
@@ -677,7 +677,7 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
ctx->kfd_bo.priority = 0;
ctx->kfd_bo.tv.bo = &bo->tbo;
- ctx->kfd_bo.tv.shared = true;
+ ctx->kfd_bo.tv.num_shared = 1;
ctx->kfd_bo.user_pages = NULL;
list_add(&ctx->kfd_bo.tv.head, &ctx->list);
@@ -741,7 +741,7 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
ctx->kfd_bo.priority = 0;
ctx->kfd_bo.tv.bo = &bo->tbo;
- ctx->kfd_bo.tv.shared = true;
+ ctx->kfd_bo.tv.num_shared = 1;
ctx->kfd_bo.user_pages = NULL;
list_add(&ctx->kfd_bo.tv.head, &ctx->list);
@@ -1808,7 +1808,7 @@ static int validate_invalid_user_pages(struct
amdkfd_process_info *process_info)
validate_list.head) {
list_add_tail(&mem->resv_list.head, &resv_list);
mem->resv_list.bo = mem->validate_list.bo;
- mem->resv_list.shared = mem->validate_list.shared;
+ mem->resv_list.num_shared = mem->validate_list.num_shared;
}
/* Reserve all BOs and page tables for validation */
@@ -2027,7 +2027,7 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
list_add_tail(&mem->resv_list.head, &ctx.list);
mem->resv_list.bo = mem->validate_list.bo;
- mem->resv_list.shared = mem->validate_list.shared;
+ mem->resv_list.num_shared = mem->validate_list.num_shared;
}
ret = ttm_eu_reserve_buffers(&ctx.ticket, &ctx.list,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index 14d2982a47cc..b75d30ee80c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -118,7 +118,7 @@ int amdgpu_bo_list_create(struct amdgpu_device *adev,
struct drm_file *filp,
entry->priority = min(info[i].bo_priority,
AMDGPU_BO_LIST_MAX_PRIORITY);
entry->tv.bo = &bo->tbo;
- entry->tv.shared = !bo->prime_shared_count;
+ entry->tv.num_shared = !bo->prime_shared_count;
if (bo->preferred_domains == AMDGPU_GEM_DOMAIN_GDS)
list->gds_obj = bo;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 3243da67db9e..4476398e5b26 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -50,7 +50,7 @@ static int amdgpu_cs_user_fence_chunk(struct amdgpu_cs_parser
*p,
bo = amdgpu_bo_ref(gem_to_amdgpu_bo(gobj));
p->uf_entry.priority = 0;
p->uf_entry.tv.bo = &bo->tbo;
- p->uf_entry.tv.shared = true;
+ p->uf_entry.tv.num_shared = 1;
p->uf_entry.user_pages = NULL;
drm_gem_object_put_unlocked(gobj);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 7b3d1ebda9df..f4f00217546e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -169,7 +169,7 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
INIT_LIST_HEAD(&duplicates);
tv.bo = &bo->tbo;
- tv.shared = true;
+ tv.num_shared = 1;
list_add(&tv.head,
[PATCH 7/8] drm/amdgpu: always reserve one more shared slot for pipelined BO moves
This allows us to drop the extra reserve in TTM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index ba406bd1b08f..8edf75c76475 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -50,7 +50,8 @@ static int amdgpu_cs_user_fence_chunk(struct amdgpu_cs_parser
*p,
bo = amdgpu_bo_ref(gem_to_amdgpu_bo(gobj));
p->uf_entry.priority = 0;
p->uf_entry.tv.bo = &bo->tbo;
- p->uf_entry.tv.num_shared = 1;
+ /* One for TTM and one for the CS job */
+ p->uf_entry.tv.num_shared = 2;
p->uf_entry.user_pages = NULL;
drm_gem_object_put_unlocked(gobj);
@@ -598,8 +599,9 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
return r;
}
+ /* One for TTM and one for the CS job */
amdgpu_bo_list_for_each_entry(e, p->bo_list)
- e->tv.num_shared = 1;
+ e->tv.num_shared = 2;
amdgpu_bo_list_get_list(p->bo_list, &p->validated);
if (p->bo_list->first_userptr != p->bo_list->num_entries)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 1b39b0144698..8c46acf893cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -616,8 +616,8 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
{
entry->priority = 0;
entry->tv.bo = &vm->root.base.bo->tbo;
- /* One for the VM updates and one for the CS job */
- entry->tv.num_shared = 2;
+ /* One for the VM updates, one for TTM and one for the CS job */
+ entry->tv.num_shared = 3;
entry->user_pages = NULL;
list_add(&entry->tv.head, validated);
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/ttm: drop the extra reservation for pipelined BO moves
The driver is now responsible to allocate enough shared slots.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 83b4657ffb10..7bdfc1e8236d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -858,12 +858,11 @@ EXPORT_SYMBOL(ttm_bo_mem_put);
/**
* Add the last move fence to the BO and reserve a new shared slot.
*/
-static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo,
-struct ttm_mem_type_manager *man,
-struct ttm_mem_reg *mem)
+static void ttm_bo_add_move_fence(struct ttm_buffer_object *bo,
+ struct ttm_mem_type_manager *man,
+ struct ttm_mem_reg *mem)
{
struct dma_fence *fence;
- int ret;
spin_lock(&man->move_lock);
fence = dma_fence_get(man->move);
@@ -871,16 +870,9 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object
*bo,
if (fence) {
reservation_object_add_shared_fence(bo->resv, fence);
-
- ret = reservation_object_reserve_shared(bo->resv, 1);
- if (unlikely(ret))
- return ret;
-
dma_fence_put(bo->moving);
bo->moving = fence;
}
-
- return 0;
}
/**
@@ -908,7 +900,8 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object
*bo,
return ret;
} while (1);
mem->mem_type = mem_type;
- return ttm_bo_add_move_fence(bo, man, mem);
+ ttm_bo_add_move_fence(bo, man, mem);
+ return 0;
}
static uint32_t ttm_bo_select_caching(struct ttm_mem_type_manager *man,
@@ -977,10 +970,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
bool has_erestartsys = false;
int i, ret;
- ret = reservation_object_reserve_shared(bo->resv, 1);
- if (unlikely(ret))
- return ret;
-
mem->mm_node = NULL;
for (i = 0; i < placement->num_placement; ++i) {
const struct ttm_place *place = &placement->placement[i];
@@ -1016,11 +1005,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
return ret;
if (mem->mm_node) {
- ret = ttm_bo_add_move_fence(bo, man, mem);
- if (unlikely(ret)) {
- (*man->func->put_node)(man, mem);
- return ret;
- }
+ ttm_bo_add_move_fence(bo, man, mem);
break;
}
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/amdgpu: fix using shared fence for exported BOs v2
It is perfectly possible that the BO list is created before the BO is
exported. While at it cleanup setting shared to one instead of true.
v2: add comment and simplify logic
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 13 +++--
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index b75d30ee80c6..5c79da8e1150 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -118,7 +118,6 @@ int amdgpu_bo_list_create(struct amdgpu_device *adev,
struct drm_file *filp,
entry->priority = min(info[i].bo_priority,
AMDGPU_BO_LIST_MAX_PRIORITY);
entry->tv.bo = &bo->tbo;
- entry->tv.num_shared = !bo->prime_shared_count;
if (bo->preferred_domains == AMDGPU_GEM_DOMAIN_GDS)
list->gds_obj = bo;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4476398e5b26..b8de56d1a866 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -598,6 +598,9 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
return r;
}
+ amdgpu_bo_list_for_each_entry(e, p->bo_list)
+ e->tv.num_shared = 1;
+
amdgpu_bo_list_get_list(p->bo_list, &p->validated);
if (p->bo_list->first_userptr != p->bo_list->num_entries)
p->mn = amdgpu_mn_get(p->adev, AMDGPU_MN_TYPE_GFX);
@@ -717,8 +720,14 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
gws = p->bo_list->gws_obj;
oa = p->bo_list->oa_obj;
- amdgpu_bo_list_for_each_entry(e, p->bo_list)
- e->bo_va = amdgpu_vm_bo_find(vm, ttm_to_amdgpu_bo(e->tv.bo));
+ amdgpu_bo_list_for_each_entry(e, p->bo_list) {
+ struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
+
+ /* Make sure we use the exclusive slot for shared BOs */
+ if (bo->prime_shared_count)
+ e->tv.num_shared = 0;
+ e->bo_va = amdgpu_vm_bo_find(vm, bo);
+ }
if (gds) {
p->job->gds_base = amdgpu_bo_gpu_offset(gds) >> PAGE_SHIFT;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/amdgpu: always reserve two slots for the VM
And drop the now superflous extra reservations.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 ++-
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index b8de56d1a866..ba406bd1b08f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -964,10 +964,6 @@ static int amdgpu_cs_vm_handling(struct amdgpu_cs_parser
*p)
if (r)
return r;
- r = reservation_object_reserve_shared(vm->root.base.bo->tbo.resv, 1);
- if (r)
- return r;
-
p->job->vm_pd_addr = amdgpu_gmc_pd_addr(vm->root.base.bo);
if (amdgpu_vm_debug) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 218527bb0156..1b39b0144698 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -616,7 +616,8 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
{
entry->priority = 0;
entry->tv.bo = &vm->root.base.bo->tbo;
- entry->tv.num_shared = 1;
+ /* One for the VM updates and one for the CS job */
+ entry->tv.num_shared = 2;
entry->user_pages = NULL;
list_add(&entry->tv.head, validated);
}
@@ -772,10 +773,6 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device *adev,
ring = container_of(vm->entity.rq->sched, struct amdgpu_ring, sched);
- r = reservation_object_reserve_shared(bo->tbo.resv, 1);
- if (r)
- return r;
-
r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
if (r)
goto error;
@@ -1839,10 +1836,6 @@ static int amdgpu_vm_bo_update_mapping(struct
amdgpu_device *adev,
if (r)
goto error_free;
- r = reservation_object_reserve_shared(vm->root.base.bo->tbo.resv, 1);
- if (r)
- goto error_free;
-
r = amdgpu_vm_update_ptes(¶ms, start, last + 1, addr, flags);
if (r)
goto error_free;
@@ -3023,6 +3016,10 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
if (r)
goto error_free_root;
+ r = reservation_object_reserve_shared(root->tbo.resv, 1);
+ if (r)
+ goto error_unreserve;
+
r = amdgpu_vm_clear_bo(adev, vm, root,
adev->vm_manager.root_level,
vm->pte_support_ats);
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/5] [libdrm] addr cs chunk for syncobj timeline
On Wed, 19 Sep 2018 at 10:31, Chunming Zhou wrote: > > Signed-off-by: Chunming Zhou > --- > include/drm/amdgpu_drm.h | 10 ++ > 1 file changed, 10 insertions(+) > For this and 1/5 - see include/drm/README and git log for examples how files in include/drm should be updated. I'll pull merge some patches in a few moments so make sure you've got latest master first. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests: Test mapping different caching types on etnaviv
[adding etnaviv@ for bigger exposure] Hi Guido, On Fri, 14 Sep 2018 at 13:06, Guido Günther wrote: > > This makes it simple to test if all cache types are mappable. > > Signed-off-by: Guido Günther > --- > Prompted by > > https://lists.freedesktop.org/archives/etnaviv/2018-September/001946.html > > tests/etnaviv/etnaviv_bo_cache_test.c | 26 ++ > 1 file changed, 26 insertions(+) > Patch looks spot on, sadly my etnaviv knowledge is a bit limited. Ideally one of the etna devs will double-check it, but from my POV Acked-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/2] modeprint: use libutil to lookup strings
On Wed, 5 Sep 2018 at 19:01, Stefan Agner wrote: > > Use libutil to lookup connector type names and state. This also > makes sure that the latest connector type addition "DPI" gets > printed correctly. > > Signed-off-by: Stefan Agner For the series: Reviewed-by: Emil Velikov Will do some sanity check and push in a moment. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-fixes
Hi Dave, Here comes -fixes for drm-next. One compiler warning fix and adding back a removed max stride check, nothing end user visible. Regards, Joonas PS. Travelling next week, so I'll skip PR unless there's something big. --- drm-intel-next-fixes-2018-10-04: Compiler warning fix and adding back a removed max stride check for sprite planes. The following changes since commit 87c2ee740c07f1edae9eec8bc45cb9b32a68f323: Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-09-28 09:48:40 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2018-10-04 for you to fetch changes up to 98a9bce38b3d93082353fda561abb73a4d7b8d94: drm/i915: Avoid compiler warning for maybe unused gu_misc_iir (2018-10-01 11:58:17 +0300) Compiler warning fix and adding back a removed max stride check for sprite planes. Chris Wilson (1): drm/i915: Avoid compiler warning for maybe unused gu_misc_iir Ville Syrjälä (1): drm/i915: Check fb stride against plane max stride drivers/gpu/drm/i915/i915_irq.c | 33 - drivers/gpu/drm/i915/intel_display.c | 14 ++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_sprite.c | 22 ++ 4 files changed, 49 insertions(+), 21 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests: Test mapping different caching types on etnaviv
Am Donnerstag, den 04.10.2018, 14:20 +0100 schrieb Emil Velikov: > [adding etnaviv@ for bigger exposure] > > Hi Guido, > > > On Fri, 14 Sep 2018 at 13:06, Guido Günther wrote: > > > > This makes it simple to test if all cache types are mappable. > > > > > > Signed-off-by: Guido Günther > > --- > > Prompted by > > > > https://lists.freedesktop.org/archives/etnaviv/2018-September/001946.html > > > > tests/etnaviv/etnaviv_bo_cache_test.c | 26 ++ > > 1 file changed, 26 insertions(+) > > > > Patch looks spot on, sadly my etnaviv knowledge is a bit limited. > > Ideally one of the etna devs will double-check it, but from my POV > > Acked-by: Emil Velikov Nope, this test has nothing to do with the BO cache, which is a userspace buffer cache layer, while the caching modes map to how CPU accesses to the buffer mmap space are treated by the hardware. So if we want to keep this test, it needs to be split into a separate test. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: fix bogus fence complete check in timeout handler
The GPU hardware fences and the job out-fences are on different timelines so it's wrong to compare them. Fix this by only looking at the out-fence. Fixes: 2c83a726d6fb (drm/etnaviv: bring back progress check in job timeout handler) Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c b/drivers/gpu/drm/etnaviv/etnaviv_sched.c index 69e9b431bf1f..e5a9fae31ab7 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c @@ -93,7 +93,7 @@ static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job) * If the GPU managed to complete this jobs fence, the timout is * spurious. Bail out. */ - if (fence_completed(gpu, submit->out_fence->seqno)) + if (dma_fence_is_signaled(submit->out_fence)) return; /* -- 2.19.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] android: make symbols hidden by default
On Thu, 20 Sep 2018 at 13:25, Eric Engestrom wrote: > > On Wednesday, 2018-09-19 23:05:48 -0700, Lucas De Marchi wrote: > > Signed-off-by: Lucas De Marchi > > Reviewed-by: Eric Engestrom > > But it'd be good to have a confirmation from Rob that it actually works: > Cc: Rob Herring > Yes it does. Older Androids can use GCC which is new enough. While latest ones exclusively use clang which also has the flag. Reviewed-by: Emil Velikov Will push that in a moment. Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests/util: Add support for sun4i-drm driver
On Sat, 22 Sep 2018 at 14:28, Ezequiel Garcia wrote: > > This is the DRM driver for all Allwinner (sunxi) platforms. > > Signed-off-by: Ezequiel Garcia Reviewed-by: Emil Velikov Will push this in a moment. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v4] libdrm: headers: Sync with drm-next
On Mon, 1 Oct 2018 at 16:09, Ayan Kumar Halder wrote: > > Generated using make headers_install from the drm-next > tree - git://anongit.freedesktop.org/drm/drm > branch - drm-next > commit - 2dc7bad71cd310dc94d1c9907909324dd2b0618f > > The changes were as follows :- > > core: (drm.h, drm_fourcc.h, drm_mode.h) > - Added client capabilities for ASPECT_RATIO and WRITEBACK_CONNECTORS > - Added Arm AFBC modifiers > - Added BROADCOM's SAND and UIF modifiers > - Added Qualcomm's modifiers > - Added some picture aspect ratio and content type options > - Added some drm mode flags > - Added writeback connector id > > amdgpu: > - Added GEM domain mask > - Added some GEM flags > - Added some hardware ip flags > - Added chunk id and IB fence. > - Added some query ids > > i915: > -Added an IOCTL (I915_PARAM_MMAP_GTT_COHERENT) > > qxl: > - Minor changes > > tegra: > - Added some comments about struct drm_tegra* members > - Modified DRM_IOCTL_TEGRA_CLOSE_CHANNEL > > vc4: > - Added some members for 'struct drm_vc4_submit_cl' > > Changes in v2: > - Mentioned 'libdrm' in the commit header. > > Changes in v3: > - Removed the changes to radeon_drm.h, sis_drm.h and via_drm.h as > suggested by > Emil Velikov > > Changes in v4: > - Removed the changes to vmwgfx_drm.h as it caused a build break ie > 'make check' failed. > > Change-Id: I018a06f65bf4a6a68400ab252b9cd05d041299b3 > Signed-off-by: Ayan Kumar halder > Reviewed-by: Emil Velikov With all the corner-cases sorted, merged to master. Thanks for the patience. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux
On Sun, 30 Sep 2018 at 18:31, Thomas Hellstrom wrote: > > Hi, Emil, > > On 09/05/2018 03:53 PM, Emil Velikov wrote: > > On 5 September 2018 at 14:20, Thomas Hellstrom > > wrote: > > > >>> In that case, please give me 24h to do a libdrm release before pushing. > >>> I had to push some workarounds for the sandboxing mentioned earlier :-\ > >>> > >>> Thanks > >>> Emil > >> > >> Ouch, I just pushed the patch, but feel free to cut the release just before > >> that commit. > >> > > That doesn't quite work. Barring any objections I'll: revert, release, > > reapply. > > > > -Emil > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > What happened here? I can't really see my commit nor a revert nor a > release in libdrm. > Coming back from holidays+XDC. I' m doing a release in a moment and will pick your patch just after that. Hmm you said you pushed the patch, yet it's not in master ... Not sure what happened there. Either way - it'll be there shortly. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef
Den 04.10.2018 09.48, skrev Daniel Vetter:
On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
Den 02.10.2018 22.58, skrev Arnd Bergmann:
The variable is now referenced unconditionally, but still
declared in an #ifdef:
drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
drivers/gpu/drm/imx/imx-drm-core.c:264:6: error: 'legacyfb_depth' undeclared
(first use in this function); did you mean 'lockdep_depth'?
Remove the #ifdef so it can always be accessed.
Fixes: f53705fd9803 ("drm/imx: Use drm_fbdev_generic_setup()")
Signed-off-by: Arnd Bergmann
---
I've already applied the previous one you sent:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=064b06bbf117f8b5e64a5143e970d5a1cf602fd6
Not sure when it reaches linux-next now that we are past rc6.
Only once we're past -rc1.
Can we revert f53705fd9803 in linux-next then to prevent the regression from
making it into 4.20?
Probably simpler to cherry pick the fix from drm-misc-next to
drm-misc-next-fixes. Noralf, can you pls do that?
Would this be the correct procudure:
dim update-branches
dim create-workdir drm-misc-next-fixes
CONFIG_DRM_FBDEV_EMULATION=n
git cherry-pick 064b06bbf117f8b5e64a5143e970d5a1cf602fd6
dim push-branch drm-misc-next-fixes
I read that cherry picking creates a new commit with a new hash.
But since you ask me to do this, I assume git will handle this when
branches are merged?
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v4 4/4] drm/msm/a6xx: Add devfreq support for a6xx
On Thu, Oct 04, 2018 at 03:11:43PM +0530, Sharat Masetty wrote:
> Implement routines to estimate GPU busy time and fetching the
> current frequency for the polling interval. This is required by
> the devfreq framework which recommends a frequency change if needed.
> The driver code then tries to set this new frequency on the GPU by
> sending an Out Of Band(OOB) request to the GMU.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 38
> +++
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 ++
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27 +
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 3 ++-
> 4 files changed, 65 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 613d639..5b65873 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -61,7 +61,7 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
> A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
> }
>
> -static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> +static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> {
> gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
>
> @@ -78,7 +78,37 @@ static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
> index)
> a6xx_gmu_set_oob(gmu, GMU_OOB_DCVS_SET);
> a6xx_gmu_clear_oob(gmu, GMU_OOB_DCVS_SET);
>
> - return gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
> + ret = gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
> + if (ret)
> + dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
> +
> + gmu->freq = gmu->gpu_freqs[index];
> +}
> +
> +void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> + struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
> + u32 perf_index = 0;
> +
> + if (freq == gmu->freq)
> + return;
> +
> + for (perf_index = 0; perf_index < gmu->nr_gpu_freqs - 1; perf_index++)
> + if (freq == gmu->gpu_freqs[perf_index])
> + break;
> +
> + __a6xx_gmu_set_freq(gmu, perf_index);
> +}
> +
> +unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> + struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
> +
> + return gmu->freq;
> }
>
> static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
> @@ -637,7 +667,7 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
> ret = a6xx_hfi_start(gmu, GMU_COLD_BOOT);
>
> /* Set the GPU back to the highest power frequency */
> - a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
> + __a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
>
> out:
> if (ret)
> @@ -676,7 +706,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> ret = a6xx_hfi_start(gmu, status);
>
> /* Set the GPU to the highest power frequency */
> - a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
> + __a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
>
> out:
> /* Make sure to turn off the boot OOB request on error */
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> index f34630c..35f765a 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> @@ -74,6 +74,8 @@ struct a6xx_gmu {
> unsigned long gmu_freqs[4];
> u32 cx_arc_votes[4];
>
> + unsigned long freq;
> +
> struct a6xx_hfi_queue queues[2];
>
> struct tasklet_struct hfi_tasklet;
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 5f36b8d..e4ac95f 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -7,6 +7,8 @@
> #include "a6xx_gpu.h"
> #include "a6xx_gmu.xml.h"
>
> +#include
> +
> static inline bool _a6xx_check_idle(struct msm_gpu *gpu)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> @@ -682,6 +684,8 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
>
> gpu->needs_hw_init = true;
>
> + msm_gpu_resume_devfreq(gpu);
> +
> return ret;
> }
>
> @@ -690,6 +694,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
>
> + devfreq_suspend_device(gpu->devfreq.devfreq);
> +
> /*
>* Make sure the GMU is idle before continuing (because some transitions
>* may use VBIF
> @@ -753,6 +759,24 @@ static void a6xx_destroy(struct msm_gpu *gpu)
> kfree(a6xx_gpu);
> }
>
> +static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu)
Re: [PATCH libdrm] tests: Test mapping different caching types on etnaviv
Hi, On Thu, Oct 04, 2018 at 03:43:11PM +0200, Lucas Stach wrote: > Am Donnerstag, den 04.10.2018, 14:20 +0100 schrieb Emil Velikov: > > [adding etnaviv@ for bigger exposure] > > > > Hi Guido, > > > > > On Fri, 14 Sep 2018 at 13:06, Guido Günther wrote: > > > > > > This makes it simple to test if all cache types are mappable. > > > > > > > > Signed-off-by: Guido Günther > > > --- > > > Prompted by > > > > > > > > > https://lists.freedesktop.org/archives/etnaviv/2018-September/001946.html > > > > > > tests/etnaviv/etnaviv_bo_cache_test.c | 26 ++ > > > 1 file changed, 26 insertions(+) > > > > > > > Patch looks spot on, sadly my etnaviv knowledge is a bit limited. > > > > Ideally one of the etna devs will double-check it, but from my POV > > > Acked-by: Emil Velikov > > Nope, this test has nothing to do with the BO cache, which is a > userspace buffer cache layer, while the caching modes map to how CPU > accesses to the buffer mmap space are treated by the hardware. > > So if we want to keep this test, it needs to be split into a separate > test. After sending this I also realized that it would might be better suited for igt-gpu-tools. Would it fit in there? If so'd rework it and add it there. Cheers, -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef
On Thu, Oct 4, 2018 at 4:43 PM Noralf Trønnes wrote:
> Den 04.10.2018 09.48, skrev Daniel Vetter:
> > On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
> >> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
> >>> On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
>
> Den 02.10.2018 22.58, skrev Arnd Bergmann:
> > The variable is now referenced unconditionally, but still
> > declared in an #ifdef:
> >
> > drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
> > drivers/gpu/drm/imx/imx-drm-core.c:264:6: error: 'legacyfb_depth'
> > undeclared (first use in this function); did you mean 'lockdep_depth'?
> >
> > Remove the #ifdef so it can always be accessed.
> >
> > Fixes: f53705fd9803 ("drm/imx: Use drm_fbdev_generic_setup()")
> > Signed-off-by: Arnd Bergmann
> > ---
> I've already applied the previous one you sent:
> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=064b06bbf117f8b5e64a5143e970d5a1cf602fd6
>
> Not sure when it reaches linux-next now that we are past rc6.
> >>> Only once we're past -rc1.
> >> Can we revert f53705fd9803 in linux-next then to prevent the regression
> >> from
> >> making it into 4.20?
> > Probably simpler to cherry pick the fix from drm-misc-next to
> > drm-misc-next-fixes. Noralf, can you pls do that?
>
> Would this be the correct procudure:
>
> dim update-branches
> dim create-workdir drm-misc-next-fixes
>
> CONFIG_DRM_FBDEV_EMULATION=n
>
> git cherry-pick 064b06bbf117f8b5e64a5143e970d5a1cf602fd6
>
> dim push-branch drm-misc-next-fixes
>
> I read that cherry picking creates a new commit with a new hash.
> But since you ask me to do this, I assume git will handle this when
> branches are merged?
The git history will show both commit IDs, which is a bit ugly but
ok if it's rare enough. There is a chance for creating a conflict if the
backport changes context, or one branch contains extra changes
that touch the same lines, but usually this is not a problem.
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: fix max mode_config height/width
On 04/10/2018 12:09, Daniel Vetter wrote:
> On Thu, Oct 04, 2018 at 10:42:43AM +0200, Neil Armstrong wrote:
>> The mode_config max_width/max_height determines the maximum framebuffer
>> size the pixel reader can handle. But the values were set thinking they
>> were determining the maximum screen dimensions.
>>
>> This patch changes the values to the maximum height/width the CANVAS block
>> can handle rounded to some coherent values.
>>
>> Fixes: a41e82e6c457 ("drm/meson: Add support for components")
>> Signed-off-by: Neil Armstrong
>
> It's both. Grep for all the callers of ->fill_modes and you'll see that
> this limit is also used to filter max screen sizes.
>
> If you want to change this, then I think we need a new
> mode_config.fb_max_width/height, which if non-zero, would extend the limit
> for fbs.
>
> There's also the problem that if you extend this for fbs, then there's no
> check anymore in the atomic_commit paths (or legacy modeset), so that
> needs to be addressed somehow too.
What about adding optionals mode_config.fb_max_width/height and update
drm_internal_framebuffer_create() to use these if non-0 or fallback
to the mode_config max_width/max_height.
Neil
>
> Bunch of igt to make sure we're not missing anything would be sweet on
> top, e.g. e.g. trying to set a mode over the limit and making sure it
> fails.
>
> Cheers, Daniel
>
>> ---
>> drivers/gpu/drm/meson/meson_drv.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_drv.c
>> b/drivers/gpu/drm/meson/meson_drv.c
>> index d344312..2e29968 100644
>> --- a/drivers/gpu/drm/meson/meson_drv.c
>> +++ b/drivers/gpu/drm/meson/meson_drv.c
>> @@ -243,8 +243,8 @@ static int meson_drv_bind_master(struct device *dev,
>> bool has_components)
>> goto free_drm;
>>
>> drm_mode_config_init(drm);
>> -drm->mode_config.max_width = 3840;
>> -drm->mode_config.max_height = 2160;
>> +drm->mode_config.max_width = 16384;
>> +drm->mode_config.max_height = 8192;
>> drm->mode_config.funcs = &meson_mode_config_funcs;
>>
>> /* Hardware Initialization */
>> --
>> 2.7.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
[ANNOUNCE] libdrm 2.4.95
This release adds a fallback for realpath() which was blocked by the web-browser sand-boxing. While the browsers are fixed-up they seem to have little incentive to roll bugfix releases :-\ -Emil Ayan Kumar Halder (1): libdrm: headers: Sync with drm-next Christian König (4): tests/amdgpu: add unaligned VM test amdgpu: remove invalid check in amdgpu_bo_alloc test/amdgpu: add proper error handling v2 test/amdgpu: add GDS, GWS and OA tests Daniel Stone (1): CI: Capture test logs as GitLab artifacts Daniel Vetter (1): Add basic CONTRIBUTING file Emil Velikov (9): xf86drm: fallback to normal path when realpath fails intel: annotate the intel genx helpers as private automake: set NM before running the tests *-symbols-check: error out when using unset variables gitlab-ci: pass the correct toggles to configure Bump to version 2.4.95 Revert "Bump to version 2.4.95" intel: include i915_pciids.h in the tarball Bump to version 2.4.95 Eric Engestrom (10): add gitlab-ci builds of libdrm xf86drm: merge get_normal_pci_path() into get_real_pci_path() xf86drm: rename "real_path" to "pci_path" gitlab-ci: use templates to deduplicate the build commands headers/README: fix/add link to drm-next intel: add missing drm_public exports nouveau: add missing drm_public exports radeon: add missing drm_public exports omap: fix symbol annotations freedreno: add missing drm_public Ezequiel Garcia (1): tests/util: Add support for sun4i-drm driver Junwei Zhang (1): amdgpu: add error return value for finding bo by cpu mapping (v2) Lucas De Marchi (19): intel: add generic functions to check PCI ID intel: make gen11 use generic gen macro intel: make gen10 use generic gen macro intel: make gen9 use generic gen macro intel: get gen once for gen >= 9 intel: annotate public functions libkms: annotate public functions nouveau: annotate public functions amdgpu: annotate public functions libdrm: annotate public functions etnaviv: annotate public functions freedreno: annotate public functions omap: annotate public functions radeon: annotate public functions tegra: annotate public functions exynos: annotate public functions meson: make symbols hidden by default autotools: make symbols hidden by default android: make symbols hidden by default Michel Dänzer (1): amdgpu-symbol-check: Add amdgpu_find_bo_by_cpu_mapping Qiang Yu (2): amdgpu: add amdgpu_bo_inc_ref() function. amdgpu: amdgpu_bo_inc_ref don't return dummy int Rob Clark (2): freedreno: fix spelling typo freedreno: move ring_cache behind fd_bo_del() Stefan Agner (2): modeprint: use libutil to lookup strings modeprint: print encoder type Tom Anderson (1): Fix build with -std=c11 git tag: libdrm-2.4.95 https://dri.freedesktop.org/libdrm/libdrm-2.4.95.tar.bz2 MD5: 41b9ed196a27f5dc7fb88412b704e9fd libdrm-2.4.95.tar.bz2 SHA1: fd7c1002001ef1aa1b6094eb2b78f1031e233bb3 libdrm-2.4.95.tar.bz2 SHA256: ef772a51b4bed97a2c243194d9a98da97319e0dbdf800d07773b025aacc895c6 libdrm-2.4.95.tar.bz2 SHA512: 9bf8178a871bb059471f58f236c8362245e08877b732b2c8366d402e8066c9a74707e4ec3bf680fca12303f1319875edc98ae8e31bc9826f172798f47197e631 libdrm-2.4.95.tar.bz2 PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.95.tar.bz2.sig https://dri.freedesktop.org/libdrm/libdrm-2.4.95.tar.gz MD5: dc673e34a5355ad2121f405b1f816be7 libdrm-2.4.95.tar.gz SHA1: 247db3eeed0a86670c20cbbe1177870d32349fa7 libdrm-2.4.95.tar.gz SHA256: f0685d8b6ec173d964cd3a5bc98c5fcd89836505c42278863b78cebacae6f7e6 libdrm-2.4.95.tar.gz SHA512: 034169b5c531a94a7f6284da172d489dc43bf0c8b6025bb5bde1602c159c883c42cd972cce3f009b0c9c35fc137231a4f94b94ca590f8ae3c104764f4f64ab3f libdrm-2.4.95.tar.gz PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.95.tar.gz.sig ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-4.19
Hi Dave, Just two small fixes for 4.19: - Fix an ordering issue in DC with respect to atomic flips that could result in a crash - Fix incorrect use of process->mm in KFD The following changes since commit d8938c981f58ee344687b7910a611ac345960045: Merge branch 'drm-tda9950-fixes' of git://git.armlinux.org.uk/~rmk/linux-arm into drm-fixes (2018-10-04 10:32:14 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.19 for you to fetch changes up to 11b29c9e25788d0afb2ddb67bcd89424bd25f2f7: drm/amdkfd: Fix incorrect use of process->mm (2018-10-04 11:37:25 -0400) Felix Kuehling (1): drm/amdkfd: Fix incorrect use of process->mm Shirish S (1): drm/amd/display: Signal hw_done() after waiting for flip_done() .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 37 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 -- 2 files changed, 37 insertions(+), 10 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97810] Boot Kernel Panic RX460 (polaris11)
https://bugs.freedesktop.org/show_bug.cgi?id=97810 Michel Dänzer changed: What|Removed |Added Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org | Component|Driver/AMDgpu |DRM/AMDgpu Resolution|--- |FIXED Product|xorg|DRI Status|NEW |RESOLVED --- Comment #2 from Michel Dänzer --- Assuming this is fixed in current kernels. -- 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 91831] Corrupted video output with 32bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=91831 Michel Dänzer changed: What|Removed |Added QA Contact|xorg-t...@lists.x.org | Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org Resolution|--- |FIXED Product|xorg|DRI Status|NEW |RESOLVED Version|git |unspecified Component|Driver/AMDgpu |DRM/AMDgpu --- Comment #3 from Michel Dänzer --- This is fixed since kernel 4.11. -- 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 v2] drm/scheduler: remove timeout work_struct from drm_sched_job
Hi Christian,
On Thu, Sep 27, 2018 at 12:55 AM Nayan Deshmukh
wrote:
>
> Hi Christian,
>
>
> On Wed, Sep 26, 2018, 10:13 AM Christian König
> wrote:
>>
>> Am 26.09.2018 um 09:39 schrieb Lucas Stach:
>> > Hi Nayan,
>> >
>> > Am Mittwoch, den 26.09.2018, 02:09 +0900 schrieb Nayan Deshmukh:
>> >> having a delayed work item per job is redundant as we only need one
>> >> per scheduler to track the time out the currently executing job.
>> >>
>> >> v2: the first element of the ring mirror list is the currently
>> >> executing job so we don't need a additional variable for it
>> >>
>> >> Signed-off-by: Nayan Deshmukh
>> >> Suggested-by: Christian König
>> >> ---
>> >> drivers/gpu/drm/scheduler/sched_main.c | 31
>> >> ---
>> >> include/drm/gpu_scheduler.h| 6 +++---
>> >> 2 files changed, 19 insertions(+), 18 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>> >> b/drivers/gpu/drm/scheduler/sched_main.c
>> >> index 9ca741f3a0bc..4e8505d51795 100644
>> >> --- a/drivers/gpu/drm/scheduler/sched_main.c
>> >> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>> >> @@ -197,19 +197,15 @@ static void drm_sched_job_finish(struct work_struct
>> >> *work)
>> >> * manages to find this job as the next job in the list, the fence
>> >> * signaled check below will prevent the timeout to be restarted.
>> >> */
>> >> -cancel_delayed_work_sync(&s_job->work_tdr);
>> >> +cancel_delayed_work_sync(&sched->work_tdr);
>> >>
>> >> spin_lock(&sched->job_list_lock);
>> >> -/* queue TDR for next job */
>> >> -if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
>> >> -!list_is_last(&s_job->node, &sched->ring_mirror_list)) {
>> >> -struct drm_sched_job *next = list_next_entry(s_job, node);
>> >> -
>> >> -if (!dma_fence_is_signaled(&next->s_fence->finished))
>> >> -schedule_delayed_work(&next->work_tdr,
>> >> sched->timeout);
>> >> -}
>> >> /* remove job from ring_mirror_list */
>> >> list_del(&s_job->node);
>> >> +/* queue TDR for next job */
>> >> +if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
>> >> +!list_empty(&sched->ring_mirror_list))
>> >> +schedule_delayed_work(&sched->work_tdr, sched->timeout);
>> >> spin_unlock(&sched->job_list_lock);
>> >>
>> >> dma_fence_put(&s_job->s_fence->finished);
>> >> @@ -236,16 +232,21 @@ static void drm_sched_job_begin(struct
>> >> drm_sched_job *s_job)
>> >> if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
>> >> list_first_entry_or_null(&sched->ring_mirror_list,
>> >> struct drm_sched_job, node) == s_job)
>> >> -schedule_delayed_work(&s_job->work_tdr, sched->timeout);
>> >> +schedule_delayed_work(&sched->work_tdr, sched->timeout);
>> >> spin_unlock(&sched->job_list_lock);
>> >> }
>> >>
>> >> static void drm_sched_job_timedout(struct work_struct *work)
>> >> {
>> >> -struct drm_sched_job *job = container_of(work, struct drm_sched_job,
>> >> - work_tdr.work);
>> >> +struct drm_gpu_scheduler *sched;
>> >> +struct drm_sched_job *job;
>> >> +
>> >> +sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
>> >> +job = list_first_entry_or_null(&sched->ring_mirror_list,
>> >> + struct drm_sched_job, node);
>> >>
>> >> -job->sched->ops->timedout_job(job);
>> >> +if (job)
>> >> +job->sched->ops->timedout_job(job);
>> > I don't think this is fully robust. Jobs are only removed from the
>> > ring_mirror_list once the job_finish worker has run. If execution of
>> > this worker is delayed for any reason (though it's really unlikely for
>> > a delay as long as the job timeout to happen) you are blaming the wrong
>> > job here.
>> >
>> > So I think what you need to to is find the first job in the ring mirror
>> > list with an unsignaled finish fence to robustly find the stuck job.
>>
>> Yeah, that is a known problem I've pointed out as well.
>>
>> The issue is we have bug reports that this happened before the patch,
>> but I'm not 100% sure how.
>>
>> My suggestion is to move a good part of the logic from
>> drm_sched_hw_job_reset() and drm_sched_job_recovery() into
>> drm_sched_job_timedout().
>>
>> E.g. we first call dma_fence_remove_callback() for each job and actually
>> check the return value if the fence was already signaled.
>>
We can move this part to drm_sched_job_timedout().
>> If we find a signaled fence we abort and add the callback back to the
>> ones where we removed it.
>>
I was not able to find the abort part. In drm_sched_hw_job_reset() we
don't take a action if the parent fence was already signaled.
We cannot shift a lot from drm_sched_job_recovery() to
drm_sched_job_timedout(). The only part that seems shiftable is the
one where we cancel the guilty job.
Regards,
Nayan
>> Nayan do y
[Bug 104531] Cannot turn monitor off over DP cable
https://bugs.freedesktop.org/show_bug.cgi?id=104531 Michel Dänzer changed: What|Removed |Added QA Contact|xorg-t...@lists.x.org | Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org Product|xorg|DRI Component|Driver/AMDgpu |DRM/AMDgpu Version|git |unspecified --- Comment #5 from Michel Dänzer --- I suspect amdgpu_connector_dp_detect might need similar logic as amdgpu_connector_dvi/vga_detect related to amdgpu_connector->detected_by_load . -- 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 105744] randomly flashing screen with RX 580
https://bugs.freedesktop.org/show_bug.cgi?id=105744 Michel Dänzer changed: What|Removed |Added Product|xorg|DRI Component|Driver/AMDgpu |DRM/AMDgpu QA Contact|xorg-t...@lists.x.org | Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org --- Comment #8 from Michel Dänzer --- Is this still happening with current kernels? Still only with DC? -- 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 103791] Tearing after screen wakeup/on
https://bugs.freedesktop.org/show_bug.cgi?id=103791 Michel Dänzer changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |xorg-driver-...@lists.x.org |.org| QA Contact||xorg-t...@lists.x.org Component|DRM/AMDgpu |Driver/AMDgpu Version|XOrg git|git Product|DRI |xorg -- 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 libdrm] libdrm: Allow dynamic drm majors on linux
Hi, Emil, On 10/04/2018 04:12 PM, Emil Velikov wrote: > On Sun, 30 Sep 2018 at 18:31, Thomas Hellstrom wrote: >> Hi, Emil, >> >> On 09/05/2018 03:53 PM, Emil Velikov wrote: >>> On 5 September 2018 at 14:20, Thomas Hellstrom >>> wrote: >>> > In that case, please give me 24h to do a libdrm release before pushing. > I had to push some workarounds for the sandboxing mentioned earlier :-\ > > Thanks > Emil Ouch, I just pushed the patch, but feel free to cut the release just before that commit. >>> That doesn't quite work. Barring any objections I'll: revert, release, >>> reapply. >>> >>> -Emil >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cthellstrom%40vmware.com%7C01a5434f4ae94d41e02108d62a042d8b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636742594763251508&sdata=f4pVmMl%2B2GfI8HIR4GriTD1Ed2eHyEdAttMbcFoavp0%3D&reserved=0 >> What happened here? I can't really see my commit nor a revert nor a >> release in libdrm. >> > Coming back from holidays+XDC. I' m doing a release in a moment and > will pick your patch just after that. > > Hmm you said you pushed the patch, yet it's not in master ... Not sure > what happened there. > Either way - it'll be there shortly. Yes, that's strange. I'm offsite too so I can't check the system from which I pushed it. But anyway, I'll push it later today if you haven't already. Thanks, Thomas > > Thanks > Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 4.19-rc7
On Thu, Oct 04, 2018 at 02:55:42PM +1000, Dave Airlie wrote: > Hi Greg, > > Nothing too much happening at this point, > > 3 i915 fixes: > compressed error handling zlib fix > compiler warning cleanup > and a minor code cleanup > > 2 tda9950: > Two fixes for the HDMI CEC > > 1 exynos: > A fix required for IOMMU interaction. > > Thanks, > Dave. > > drm-fixes-2018-10-04: > drm exynos, tda9950 and intel fixes > The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38: > > Linux 4.19-rc6 (2018-09-30 07:15:35 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-10-04 Now merged, thanks. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/18] drm/atomic-helper: Unexport drm_atomic_helper_best_encoder
Hi Daniel,
On Wednesday, 3 October 2018 12:08:38 EEST Daniel Vetter wrote:
> On Tue, Oct 02, 2018 at 04:53:12PM +0300, Laurent Pinchart wrote:
> > On Tuesday, 2 October 2018 16:35:10 EEST Daniel Vetter wrote:
> > > It's the default. The exported version was kinda a transition state,
> > > before we made this the default.
> > >
> > > To stop new atomic drivers from using it (instead of just relying on
> > > the default) let's unexport it.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Gustavo Padovan
> > > Cc: Maarten Lankhorst
> > > Cc: Sean Paul
> > > Cc: David Airlie
> > > Cc: VMware Graphics
> > > Cc: Sinclair Yeh
> > > Cc: Thomas Hellstrom
> > > Cc: Archit Taneja
> > > Cc: Neil Armstrong
> > > Cc: Laurent Pinchart
> > > Cc: Hans Verkuil
> > > Cc: Daniel Vetter
> > > Cc: Russell King
> > > Cc: Jernej Skrabec
> > > Cc: Jani Nikula
> > > Cc: Pierre-Hugues Husson
> > > Cc: Fabio Estevam
> > > ---
> > >
> > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 -
> > > drivers/gpu/drm/drm_atomic_helper.c | 24 +++
> > > drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 -
> > > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 -
> > > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 -
> > > include/drm/drm_atomic_helper.h | 2 --
> > > 6 files changed, 7 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > > ac37c50d6c4b..5ac979d3450b 100644
> > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >
> > [snip]
> >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c index f92b7cf4cbd7..8c93f33fe92f
> > > 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -92,6 +92,13 @@ drm_atomic_helper_plane_changed(struct
> > > drm_atomic_state
> > > *state, }
> > >
> > > }
> > >
> > > +static struct drm_encoder *
> > > +drm_atomic_helper_best_encoder(struct drm_connector *connector)
> > > +{
> > > + WARN_ON(connector->encoder_ids[1]);
> >
> > As you're removing the documentation, I would add a comment here to
> > explain the WARN_ON. Something along the lines of "For connectors that
> > support multiple encoders, the .atomic_best_encoder() or .atomic_encoder()
> > operation must be implemented".
> >
> > You could also rename the function to make it more explicit that it's a
> > default for the single encoder case.
>
> So pick_single_encoder_for_connector()?
Works for me.
> I think that would avoid the need for a comment.
I'd still keep the comment, it won't hurt, and you have it already :-)
> r-b: you with that fixed up?
With the comment and function renamed,
Reviewed-by: Laurent Pinchart
> > > + return drm_encoder_find(connector->dev, NULL,
> > > connector->encoder_ids[0]);
> > > +}
> > > +
> > >
> > > static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > >
> > > bool disable_conflicting_encoders)
> > >
> > > {
> > >
> > > @@ -3376,23 +3383,6 @@ int drm_atomic_helper_page_flip_target(struct
> > > drm_crtc *crtc, }
> > >
> > > EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
> > >
> > > -/**
> > > - * drm_atomic_helper_best_encoder - Helper for
> > > - * &drm_connector_helper_funcs.best_encoder callback
> > > - * @connector: Connector control structure
> > > - *
> > > - * This is a &drm_connector_helper_funcs.best_encoder callback helper
> > > for
> > > - * connectors that support exactly 1 encoder, statically determined at
> > > driver - * init time.
> > > - */
> > > -struct drm_encoder *
> > > -drm_atomic_helper_best_encoder(struct drm_connector *connector)
> > > -{
> > > - WARN_ON(connector->encoder_ids[1]);
> > > - return drm_encoder_find(connector->dev, NULL,
> > > connector->encoder_ids[0]);
> > > -}
> > > -EXPORT_SYMBOL(drm_atomic_helper_best_encoder);
> > > -
> > >
> > > /**
> > >
> > > * DOC: atomic state reset and initialization
> > > *
> >
> > [snip]
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/i915: Use the correct crtc when sanitizing plane mapping
On Wed, Oct 03, 2018 at 06:12:42PM +0200, Daniel Vetter wrote:
> On Wed, Oct 03, 2018 at 05:50:17PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > When we decide that a plane is attached to the wrong pipe we try
> > to turn off said plane. However we are passing around the crtc we
> > think that the plane is supposed to be using rather than the crtc
> > it is currently using. That doesn't work all that well because
> > we may have to do vblank waits etc. and the other pipe might
> > not even be enabled here. So let's pass the plane's current crtc to
> > intel_plane_disable_noatomic() so that it can its job correctly.
> >
> > To do that semi-cleanly we also have to change the plane readout
> > to record the plane's visibility into the bitmasks of the crtc
> > where the plane is currently enabled rather than to the crtc
> > we want to use for the plane.
> >
> > One caveat here is that our active_planes bitmask will get confused
> > if both planes are enabled on the same pipe. Fortunately we can use
> > plane_mask to reconstruct active_planes sufficiently since
> > plane_mask still has the same meaning (is the plane visible?)
> > during readout. We also have to do the same during the initial
> > plane readout as the second plane could clear the active_planes
> > bit the first plane had already set.
> >
> > v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel)
> > Add Daniel's proposed comment to better document why we do this
> > Drop the redundant intel_set_plane_visible() call
> >
> > Cc: sta...@vger.kernel.org # fcba862e8428 drm/i915: Have
> > plane->get_hw_state() return the current pipe
> > Cc: sta...@vger.kernel.org
> > Cc: Dennis
> > Cc: Daniel Vetter
> > Tested-by: Dennis
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637
> > Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout")
> > Signed-off-by: Ville Syrjälä
>
> I have the illusion of understanding this stuff now.
>
> Reviewed-by: Daniel Vetter
>
> But let's see whether testers and CI agree :-)
Seems to be reasonably happy :)
Picked up another tested-by from the bug report
Tested-by: Peter Nowee
and pushed the series to dinq. Thanks to everyone involved.
> -Daniel
>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 78
> > +---
> > 1 file changed, 46 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d2828159f6c8..f0d004641b0d 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2764,20 +2764,33 @@ intel_set_plane_visible(struct intel_crtc_state
> > *crtc_state,
> >
> > plane_state->base.visible = visible;
> >
> > - /* FIXME pre-g4x don't work like this */
> > - if (visible) {
> > + if (visible)
> > crtc_state->base.plane_mask |= drm_plane_mask(&plane->base);
> > - crtc_state->active_planes |= BIT(plane->id);
> > - } else {
> > + else
> > crtc_state->base.plane_mask &= ~drm_plane_mask(&plane->base);
> > - crtc_state->active_planes &= ~BIT(plane->id);
> > - }
> >
> > DRM_DEBUG_KMS("%s active planes 0x%x\n",
> > crtc_state->base.crtc->name,
> > crtc_state->active_planes);
> > }
> >
> > +static void fixup_active_planes(struct intel_crtc_state *crtc_state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> > + struct drm_plane *plane;
> > +
> > + /*
> > +* Active_planes aliases if multiple "primary" or cursor planes
> > +* have been used on the same (or wrong) pipe. plane_mask uses
> > +* unique ids, hence we can use that to reconstruct active_planes.
> > +*/
> > + crtc_state->active_planes = 0;
> > +
> > + drm_for_each_plane_mask(plane, &dev_priv->drm,
> > + crtc_state->base.plane_mask)
> > + crtc_state->active_planes |= BIT(to_intel_plane(plane)->id);
> > +}
> > +
> > static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
> > struct intel_plane *plane)
> > {
> > @@ -2787,6 +2800,7 @@ static void intel_plane_disable_noatomic(struct
> > intel_crtc *crtc,
> > to_intel_plane_state(plane->base.state);
> >
> > intel_set_plane_visible(crtc_state, plane_state, false);
> > + fixup_active_planes(crtc_state);
> >
> > if (plane->id == PLANE_PRIMARY)
> > intel_pre_disable_primary_noatomic(&crtc->base);
> > @@ -2805,7 +2819,6 @@ intel_find_initial_plane_obj(struct intel_crtc
> > *intel_crtc,
> > struct drm_i915_gem_object *obj;
> > struct drm_plane *primary = intel_crtc->base.primary;
> > struct drm_plane_state *plane_state = primary->state;
> > - struct drm_crtc_state *crtc_state = intel_crtc->base.state;
> > struct intel_plane *intel_plane = to_intel_plane(primary);
> > str
Re: [PATCH v2] drm/scheduler: remove timeout work_struct from drm_sched_job
Am 04.10.2018 um 18:32 schrieb Nayan Deshmukh:
Hi Christian,
On Thu, Sep 27, 2018 at 12:55 AM Nayan Deshmukh
wrote:
Hi Christian,
On Wed, Sep 26, 2018, 10:13 AM Christian König
wrote:
Am 26.09.2018 um 09:39 schrieb Lucas Stach:
Hi Nayan,
Am Mittwoch, den 26.09.2018, 02:09 +0900 schrieb Nayan Deshmukh:
having a delayed work item per job is redundant as we only need one
per scheduler to track the time out the currently executing job.
v2: the first element of the ring mirror list is the currently
executing job so we don't need a additional variable for it
Signed-off-by: Nayan Deshmukh
Suggested-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 31 ---
include/drm/gpu_scheduler.h| 6 +++---
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 9ca741f3a0bc..4e8505d51795 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -197,19 +197,15 @@ static void drm_sched_job_finish(struct work_struct *work)
* manages to find this job as the next job in the list, the fence
* signaled check below will prevent the timeout to be restarted.
*/
-cancel_delayed_work_sync(&s_job->work_tdr);
+cancel_delayed_work_sync(&sched->work_tdr);
spin_lock(&sched->job_list_lock);
-/* queue TDR for next job */
-if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
-!list_is_last(&s_job->node, &sched->ring_mirror_list)) {
-struct drm_sched_job *next = list_next_entry(s_job, node);
-
-if (!dma_fence_is_signaled(&next->s_fence->finished))
-schedule_delayed_work(&next->work_tdr, sched->timeout);
-}
/* remove job from ring_mirror_list */
list_del(&s_job->node);
+/* queue TDR for next job */
+if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
+!list_empty(&sched->ring_mirror_list))
+schedule_delayed_work(&sched->work_tdr, sched->timeout);
spin_unlock(&sched->job_list_lock);
dma_fence_put(&s_job->s_fence->finished);
@@ -236,16 +232,21 @@ static void drm_sched_job_begin(struct drm_sched_job
*s_job)
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
list_first_entry_or_null(&sched->ring_mirror_list,
struct drm_sched_job, node) == s_job)
-schedule_delayed_work(&s_job->work_tdr, sched->timeout);
+schedule_delayed_work(&sched->work_tdr, sched->timeout);
spin_unlock(&sched->job_list_lock);
}
static void drm_sched_job_timedout(struct work_struct *work)
{
-struct drm_sched_job *job = container_of(work, struct drm_sched_job,
- work_tdr.work);
+struct drm_gpu_scheduler *sched;
+struct drm_sched_job *job;
+
+sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
+job = list_first_entry_or_null(&sched->ring_mirror_list,
+ struct drm_sched_job, node);
-job->sched->ops->timedout_job(job);
+if (job)
+job->sched->ops->timedout_job(job);
I don't think this is fully robust. Jobs are only removed from the
ring_mirror_list once the job_finish worker has run. If execution of
this worker is delayed for any reason (though it's really unlikely for
a delay as long as the job timeout to happen) you are blaming the wrong
job here.
So I think what you need to to is find the first job in the ring mirror
list with an unsignaled finish fence to robustly find the stuck job.
Yeah, that is a known problem I've pointed out as well.
The issue is we have bug reports that this happened before the patch,
but I'm not 100% sure how.
My suggestion is to move a good part of the logic from
drm_sched_hw_job_reset() and drm_sched_job_recovery() into
drm_sched_job_timedout().
E.g. we first call dma_fence_remove_callback() for each job and actually
check the return value if the fence was already signaled.
We can move this part to drm_sched_job_timedout().
If we find a signaled fence we abort and add the callback back to the
ones where we removed it.
I was not able to find the abort part. In drm_sched_hw_job_reset() we
don't take a action if the parent fence was already signaled.
That is a bug a swell.
We cannot shift a lot from drm_sched_job_recovery() to
drm_sched_job_timedout(). The only part that seems shiftable is the
one where we cancel the guilty job.
Actually I wanted to completely rework that part since it is rather
unreliable as well.
Considering how buggy all of that is and how important it is to get it
right I think I will rather do it myself.
Regards,
Christian.
Regards,
Nayan
Nayan do you want to take care of this or should I take a look?
I can take care of it.
Regards,
Nayan
Regards,
Christian.
Regards,
Lucas
}
/**
@@ -315,7 +316,7 @@ void drm_sched_job_recovery(s
[Bug 106374] feature request: allow increasing maxium GPU power consumption like implemented in Wattman on Windows
https://bugs.freedesktop.org/show_bug.cgi?id=106374 --- Comment #4 from Hugo Sánchez --- I am having the same issue. That is a big problem cause GPU cannot reach its max power. A RX Vega 64 for example can consume around 300w with OC and the 220w is causing frame drops in the case of games. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][drm-next] drm/vmwgfx: remove redundant return ret statement
From: Colin Ian King
The return statement is redundant as there is a return statement
immediately before it so we have dead code that can be removed.
Also remove the unused declaration of ret.
Detected by CoverityScan, CID#1473793 ("Structurally dead code")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 5a6b70ba137a..260650bb5560 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -1738,7 +1738,6 @@ static int vmw_cmd_check_define_gmrfb(struct vmw_private
*dev_priv,
void *buf)
{
struct vmw_buffer_object *vmw_bo;
- int ret;
struct {
uint32_t header;
@@ -1748,7 +1747,6 @@ static int vmw_cmd_check_define_gmrfb(struct vmw_private
*dev_priv,
return vmw_translate_guest_ptr(dev_priv, sw_context,
&cmd->body.ptr,
&vmw_bo);
- return ret;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201275] Power consumption RX460 idle raised from 7 W to 13 W
https://bugzilla.kernel.org/show_bug.cgi?id=201275 --- Comment #8 from quirin.blae...@freenet.de --- 4.18.12 Bug still present, removing 93b100ddda3be284be160e9ccba28c7f8f21ab73 solves this problem for now. -- 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 201275] Power consumption RX560 idle raised from 7 W to 13 W
https://bugzilla.kernel.org/show_bug.cgi?id=201275 quirin.blae...@freenet.de changed: What|Removed |Added Summary|Power consumption RX460 |Power consumption RX560 |idle raised from 7 W to 13 |idle raised from 7 W to 13 |W |W -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: fix max mode_config height/width
On Thu, Oct 4, 2018 at 5:05 PM Neil Armstrong wrote:
>
> On 04/10/2018 12:09, Daniel Vetter wrote:
> > On Thu, Oct 04, 2018 at 10:42:43AM +0200, Neil Armstrong wrote:
> >> The mode_config max_width/max_height determines the maximum framebuffer
> >> size the pixel reader can handle. But the values were set thinking they
> >> were determining the maximum screen dimensions.
> >>
> >> This patch changes the values to the maximum height/width the CANVAS block
> >> can handle rounded to some coherent values.
> >>
> >> Fixes: a41e82e6c457 ("drm/meson: Add support for components")
> >> Signed-off-by: Neil Armstrong
> >
> > It's both. Grep for all the callers of ->fill_modes and you'll see that
> > this limit is also used to filter max screen sizes.
> >
> > If you want to change this, then I think we need a new
> > mode_config.fb_max_width/height, which if non-zero, would extend the limit
> > for fbs.
> >
> > There's also the problem that if you extend this for fbs, then there's no
> > check anymore in the atomic_commit paths (or legacy modeset), so that
> > needs to be addressed somehow too.
>
> What about adding optionals mode_config.fb_max_width/height and update
> drm_internal_framebuffer_create() to use these if non-0 or fallback
> to the mode_config max_width/max_height.
That's what I meant. Except you also need to then fix the gap you've
opened in atomic_check, and validate the mode size against
mode_config.max_width/height.
-Daniel
>
> Neil
>
> >
> > Bunch of igt to make sure we're not missing anything would be sweet on
> > top, e.g. e.g. trying to set a mode over the limit and making sure it
> > fails.
> >
> > Cheers, Daniel
> >
> >> ---
> >> drivers/gpu/drm/meson/meson_drv.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> >> b/drivers/gpu/drm/meson/meson_drv.c
> >> index d344312..2e29968 100644
> >> --- a/drivers/gpu/drm/meson/meson_drv.c
> >> +++ b/drivers/gpu/drm/meson/meson_drv.c
> >> @@ -243,8 +243,8 @@ static int meson_drv_bind_master(struct device *dev,
> >> bool has_components)
> >> goto free_drm;
> >>
> >> drm_mode_config_init(drm);
> >> -drm->mode_config.max_width = 3840;
> >> -drm->mode_config.max_height = 2160;
> >> +drm->mode_config.max_width = 16384;
> >> +drm->mode_config.max_height = 8192;
> >> drm->mode_config.funcs = &meson_mode_config_funcs;
> >>
> >> /* Hardware Initialization */
> >> --
> >> 2.7.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
--
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: [Intel-gfx] [PATCH 02/18] drm/atomic-helper: Unexport drm_atomic_helper_best_encoder
On Tue, Oct 02, 2018 at 03:35:10PM +0200, Daniel Vetter wrote:
> It's the default. The exported version was kinda a transition state,
> before we made this the default.
>
> To stop new atomic drivers from using it (instead of just relying on
> the default) let's unexport it.
>
> Signed-off-by: Daniel Vetter
> Cc: Gustavo Padovan
> Cc: Maarten Lankhorst
> Cc: Sean Paul
> Cc: David Airlie
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Archit Taneja
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Hans Verkuil
> Cc: Daniel Vetter
> Cc: Russell King
> Cc: Jernej Skrabec
> Cc: Jani Nikula
> Cc: Pierre-Hugues Husson
> Cc: Fabio Estevam
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 -
> drivers/gpu/drm/drm_atomic_helper.c | 24 +++
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 -
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 -
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 -
> include/drm/drm_atomic_helper.h | 2 --
> 6 files changed, 7 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index ac37c50d6c4b..5ac979d3450b 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1957,7 +1957,6 @@ static const struct drm_connector_funcs
> dw_hdmi_connector_funcs = {
>
> static const struct drm_connector_helper_funcs
> dw_hdmi_connector_helper_funcs = {
> .get_modes = dw_hdmi_connector_get_modes,
> - .best_encoder = drm_atomic_helper_best_encoder,
> };
>
> static int dw_hdmi_bridge_attach(struct drm_bridge *bridge)
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index f92b7cf4cbd7..8c93f33fe92f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -92,6 +92,13 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
> *state,
> }
> }
>
> +static struct drm_encoder *
> +drm_atomic_helper_best_encoder(struct drm_connector *connector)
> +{
> + WARN_ON(connector->encoder_ids[1]);
> + return drm_encoder_find(connector->dev, NULL,
> connector->encoder_ids[0]);
> +}
> +
> static int handle_conflicting_encoders(struct drm_atomic_state *state,
> bool disable_conflicting_encoders)
> {
> @@ -3376,23 +3383,6 @@ int drm_atomic_helper_page_flip_target(struct drm_crtc
> *crtc,
> }
> EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
>
> -/**
> - * drm_atomic_helper_best_encoder - Helper for
> - * &drm_connector_helper_funcs.best_encoder callback
> - * @connector: Connector control structure
> - *
> - * This is a &drm_connector_helper_funcs.best_encoder callback helper for
> - * connectors that support exactly 1 encoder, statically determined at driver
> - * init time.
> - */
> -struct drm_encoder *
> -drm_atomic_helper_best_encoder(struct drm_connector *connector)
> -{
> - WARN_ON(connector->encoder_ids[1]);
> - return drm_encoder_find(connector->dev, NULL,
> connector->encoder_ids[0]);
> -}
> -EXPORT_SYMBOL(drm_atomic_helper_best_encoder);
> -
> /**
> * DOC: atomic state reset and initialization
> *
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> index 723578117191..4b5378495eea 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> @@ -274,7 +274,6 @@ static const struct drm_connector_funcs
> vmw_legacy_connector_funcs = {
>
> static const struct
> drm_connector_helper_funcs vmw_ldu_connector_helper_funcs = {
> - .best_encoder = drm_atomic_helper_best_encoder,
> };
Seems like you can remove this entirely, as well as the helper funcs
registration call? Same goes for a few other drivers.
Sean
>
> /*
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> index ad0de7f0cd60..4c68ad6f3605 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> @@ -389,7 +389,6 @@ static const struct drm_connector_funcs
> vmw_sou_connector_funcs = {
>
> static const struct
> drm_connector_helper_funcs vmw_sou_connector_helper_funcs = {
> - .best_encoder = drm_atomic_helper_best_encoder,
> };
>
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> index f30e839f7bfd..e28bb08114a5 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> @@ -1037,7 +1037,6 @@ static const struct drm_connector_funcs
> vmw_stdu_connector_funcs = {
>
> static const struct
> drm_connector_helper_funcs vmw_stdu_connector_helper_funcs = {
> - .best_encoder = drm_atomic_helper_best_encoder,
> };
>
>
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 657af7b39379..e60c4f0f8827 100644
> --- a/include/drm/drm_atomic_help
Re: [PATCH v9 2/2] dt-bindings: Add Truly NT35597 panel driver bindings
If you want DT bindings reviewed, you have to cc the DT list. (Or wait
for Sean Paul to ping me on IRC)
On Fri, Sep 28, 2018 at 7:39 PM Abhinav Kumar wrote:
>
> Add the device tree bindings for Truly NT35597 panel driver. This panel
> driver supports both single DSI and dual DSI.
By driver, you means drives panel timing signals or a Linux driver?
The former is okay, the latter is not.
>
> However, this patch series supports only dual DSI.
>
> Changes in v9:
> - None
>
> Reviewed-by: Linus Walleij
> Reviewed-by: Sean Paul
> Signed-off-by: Abhinav Kumar
> ---
> .../devicetree/bindings/display/truly,nt35597.txt | 60
> ++
> 1 file changed, 60 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/truly,nt35597.txt
>
> diff --git a/Documentation/devicetree/bindings/display/truly,nt35597.txt
> b/Documentation/devicetree/bindings/display/truly,nt35597.txt
> new file mode 100644
> index 000..46b29eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/truly,nt35597.txt
> @@ -0,0 +1,60 @@
> +Truly model NT35597 DSI display driver
> +
> +The Truly NT35597 is a generic display driver, currently only configured
> +for use in the 2K display on the Qualcomm SDM845.
So this is for *all* SDM845 based boards?
> +
> +Required properties:
> +- compatible: should be "truly,nt35597-2K-display"
> +- vdda-supply: phandle of the regulator that provides the supply voltage
> + Power IC supply
> +- vdispp-supply: phandle of the regulator that provides the supply voltage
> + for positive LCD bias
> +- vdispn-supply: phandle of the regulator that provides the supply voltage
> + for negative LCD bias
> +- reset-gpios: phandle of gpio for reset line
> + This should be 8mA, gpio can be configured using mux, pinctrl,
> pinctrl-names
> + (active low)
> +- mode-gpios: phandle of the gpio for choosing the mode of the display
> + for single DSI or Dual DSI
> + (active high)
active high doesn't really make sense for this.
> + This should be low for dual DSI and high for single DSI mode
> +- ports: This device has two video ports driven by two DSIs. Their
> connections
> + are modelled using the OF graph bindings specified in
modeled
> + Documentation/devicetree/bindings/graph.txt.
> + - port@0: DSI input port driven by master DSI
> + - port@1: DSI input port driven by secondary DSI
> +
> +Example:
> +
> + dsi@ae94000 {
> + panel@0 {
> + compatible = "truly,nt35597-2K-display";
> + reg = <0>;
> + vdda-supply = <&pm8998_l14>;
> + vdispp-supply = <&lab_regulator>;
> + vdispn-supply = <&ibb_regulator>;
> + pinctrl-names = "default", "suspend";
> + pinctrl-0 = <&dpu_dsi_active>;
> + pinctrl-1 = <&dpu_dsi_suspend>;
> +
> + reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
> + mode-gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + panel1_in: endpoint {
> + remote-endpoint = <&dsi1_out>;
> + };
> + };
> + };
> + };
> + };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 02/18] drm/atomic-helper: Unexport drm_atomic_helper_best_encoder
On Thu, Oct 04, 2018 at 02:33:24PM -0400, Sean Paul wrote:
> On Tue, Oct 02, 2018 at 03:35:10PM +0200, Daniel Vetter wrote:
> > It's the default. The exported version was kinda a transition state,
> > before we made this the default.
> >
> > To stop new atomic drivers from using it (instead of just relying on
> > the default) let's unexport it.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Gustavo Padovan
> > Cc: Maarten Lankhorst
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: VMware Graphics
> > Cc: Sinclair Yeh
> > Cc: Thomas Hellstrom
> > Cc: Archit Taneja
> > Cc: Neil Armstrong
> > Cc: Laurent Pinchart
> > Cc: Hans Verkuil
> > Cc: Daniel Vetter
> > Cc: Russell King
> > Cc: Jernej Skrabec
> > Cc: Jani Nikula
> > Cc: Pierre-Hugues Husson
> > Cc: Fabio Estevam
> > ---
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 -
> > drivers/gpu/drm/drm_atomic_helper.c | 24 +++
> > drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 -
> > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 -
> > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 -
> > include/drm/drm_atomic_helper.h | 2 --
> > 6 files changed, 7 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index ac37c50d6c4b..5ac979d3450b 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1957,7 +1957,6 @@ static const struct drm_connector_funcs
> > dw_hdmi_connector_funcs = {
> >
> > static const struct drm_connector_helper_funcs
> > dw_hdmi_connector_helper_funcs = {
> > .get_modes = dw_hdmi_connector_get_modes,
> > - .best_encoder = drm_atomic_helper_best_encoder,
> > };
> >
> > static int dw_hdmi_bridge_attach(struct drm_bridge *bridge)
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index f92b7cf4cbd7..8c93f33fe92f 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -92,6 +92,13 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
> > *state,
> > }
> > }
> >
> > +static struct drm_encoder *
> > +drm_atomic_helper_best_encoder(struct drm_connector *connector)
> > +{
> > + WARN_ON(connector->encoder_ids[1]);
> > + return drm_encoder_find(connector->dev, NULL,
> > connector->encoder_ids[0]);
> > +}
> > +
> > static int handle_conflicting_encoders(struct drm_atomic_state *state,
> >bool disable_conflicting_encoders)
> > {
> > @@ -3376,23 +3383,6 @@ int drm_atomic_helper_page_flip_target(struct
> > drm_crtc *crtc,
> > }
> > EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
> >
> > -/**
> > - * drm_atomic_helper_best_encoder - Helper for
> > - * &drm_connector_helper_funcs.best_encoder callback
> > - * @connector: Connector control structure
> > - *
> > - * This is a &drm_connector_helper_funcs.best_encoder callback helper for
> > - * connectors that support exactly 1 encoder, statically determined at
> > driver
> > - * init time.
> > - */
> > -struct drm_encoder *
> > -drm_atomic_helper_best_encoder(struct drm_connector *connector)
> > -{
> > - WARN_ON(connector->encoder_ids[1]);
> > - return drm_encoder_find(connector->dev, NULL,
> > connector->encoder_ids[0]);
> > -}
> > -EXPORT_SYMBOL(drm_atomic_helper_best_encoder);
> > -
> > /**
> > * DOC: atomic state reset and initialization
> > *
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> > index 723578117191..4b5378495eea 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> > @@ -274,7 +274,6 @@ static const struct drm_connector_funcs
> > vmw_legacy_connector_funcs = {
> >
> > static const struct
> > drm_connector_helper_funcs vmw_ldu_connector_helper_funcs = {
> > - .best_encoder = drm_atomic_helper_best_encoder,
> > };
>
> Seems like you can remove this entirely, as well as the helper funcs
> registration call? Same goes for a few other drivers.
Needs a huge audit, at least in the past we've had cases where everything
started oopsing because helpers didn't check carefully whether the vtable
pointer was NULL or not.
Heck even this patch here blew up on amdgpu at first.
So good idea, but maybe not in this patch here :-)
-Daniel
> > /*
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > index ad0de7f0cd60..4c68ad6f3605 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > @@ -389,7 +389,6 @@ static const struct drm_connector_funcs
> > vmw_sou_connector_funcs = {
> >
> > static const struct
> > drm_connector_helper_funcs vmw_sou_connector_helper_funcs = {
> > - .best_encoder = drm_atomic_helper_best_encoder,
> > };
> >
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> > b/d
Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef
On Thu, Oct 04, 2018 at 05:04:21PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 4, 2018 at 4:43 PM Noralf Trønnes wrote:
> > Den 04.10.2018 09.48, skrev Daniel Vetter:
> > > On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
> > >> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
> > >>> On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
> >
> > Den 02.10.2018 22.58, skrev Arnd Bergmann:
> > > The variable is now referenced unconditionally, but still
> > > declared in an #ifdef:
> > >
> > > drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
> > > drivers/gpu/drm/imx/imx-drm-core.c:264:6: error: 'legacyfb_depth'
> > > undeclared (first use in this function); did you mean 'lockdep_depth'?
> > >
> > > Remove the #ifdef so it can always be accessed.
> > >
> > > Fixes: f53705fd9803 ("drm/imx: Use drm_fbdev_generic_setup()")
> > > Signed-off-by: Arnd Bergmann
> > > ---
> > I've already applied the previous one you sent:
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=064b06bbf117f8b5e64a5143e970d5a1cf602fd6
> >
> > Not sure when it reaches linux-next now that we are past rc6.
> > >>> Only once we're past -rc1.
> > >> Can we revert f53705fd9803 in linux-next then to prevent the regression
> > >> from
> > >> making it into 4.20?
> > > Probably simpler to cherry pick the fix from drm-misc-next to
> > > drm-misc-next-fixes. Noralf, can you pls do that?
> >
> > Would this be the correct procudure:
> >
> > dim update-branches
> > dim create-workdir drm-misc-next-fixes
> >
> > CONFIG_DRM_FBDEV_EMULATION=n
> >
> > git cherry-pick 064b06bbf117f8b5e64a5143e970d5a1cf602fd6
> >
> > dim push-branch drm-misc-next-fixes
> >
> > I read that cherry picking creates a new commit with a new hash.
> > But since you ask me to do this, I assume git will handle this when
> > branches are merged?
>
> The git history will show both commit IDs, which is a bit ugly but
> ok if it's rare enough. There is a chance for creating a conflict if the
> backport changes context, or one branch contains extra changes
> that touch the same lines, but usually this is not a problem.
+1, and your recipe looks good too. drm-intel works entirely on these
cherry-picks, and we've done it a few times in drm-misc too. Having to
cherry-pick is one of the downsides of group maintainership, since you
really can't rebase trees at will. Definitely not the -next queue.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/2] dt-bindings: Add Truly NT35597 panel driver bindings
Hi Rob
Thanks for the review. Will copy the DT list in the next patchset.
Some comments inline.
Thanks
Abhinav
On 2018-10-04 12:01, Rob Herring wrote:
If you want DT bindings reviewed, you have to cc the DT list. (Or wait
for Sean Paul to ping me on IRC)
On Fri, Sep 28, 2018 at 7:39 PM Abhinav Kumar
wrote:
Add the device tree bindings for Truly NT35597 panel driver. This
panel
driver supports both single DSI and dual DSI.
By driver, you means drives panel timing signals or a Linux driver?
The former is okay, the latter is not.
Yes, I mean it driver panel timing signals.
However, this patch series supports only dual DSI.
Changes in v9:
- None
Reviewed-by: Linus Walleij
Reviewed-by: Sean Paul
Signed-off-by: Abhinav Kumar
---
.../devicetree/bindings/display/truly,nt35597.txt | 60
++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/truly,nt35597.txt
diff --git
a/Documentation/devicetree/bindings/display/truly,nt35597.txt
b/Documentation/devicetree/bindings/display/truly,nt35597.txt
new file mode 100644
index 000..46b29eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/truly,nt35597.txt
@@ -0,0 +1,60 @@
+Truly model NT35597 DSI display driver
+
+The Truly NT35597 is a generic display driver, currently only
configured
+for use in the 2K display on the Qualcomm SDM845.
So this is for *all* SDM845 based boards?
This is for SDM845 MTP board. Let me mention that as well.
+
+Required properties:
+- compatible: should be "truly,nt35597-2K-display"
+- vdda-supply: phandle of the regulator that provides the supply
voltage
+ Power IC supply
+- vdispp-supply: phandle of the regulator that provides the supply
voltage
+ for positive LCD bias
+- vdispn-supply: phandle of the regulator that provides the supply
voltage
+ for negative LCD bias
+- reset-gpios: phandle of gpio for reset line
+ This should be 8mA, gpio can be configured using mux, pinctrl,
pinctrl-names
+ (active low)
+- mode-gpios: phandle of the gpio for choosing the mode of the
display
+ for single DSI or Dual DSI
+ (active high)
active high doesn't really make sense for this.
Alright, will remove this.
+ This should be low for dual DSI and high for single DSI mode
+- ports: This device has two video ports driven by two DSIs. Their
connections
+ are modelled using the OF graph bindings specified in
modeled
+ Documentation/devicetree/bindings/graph.txt.
+ - port@0: DSI input port driven by master DSI
+ - port@1: DSI input port driven by secondary DSI
+
+Example:
+
+ dsi@ae94000 {
+ panel@0 {
+ compatible = "truly,nt35597-2K-display";
+ reg = <0>;
+ vdda-supply = <&pm8998_l14>;
+ vdispp-supply = <&lab_regulator>;
+ vdispn-supply = <&ibb_regulator>;
+ pinctrl-names = "default", "suspend";
+ pinctrl-0 = <&dpu_dsi_active>;
+ pinctrl-1 = <&dpu_dsi_suspend>;
+
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
+ mode-gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ panel0_in: endpoint {
+ remote-endpoint =
<&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ panel1_in: endpoint {
+ remote-endpoint =
<&dsi1_out>;
+ };
+ };
+ };
+ };
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer
Hi, On Wed, Oct 03, 2018 at 04:24:57PM +0200, Giulio Benetti wrote: > At the moment, the check of tcon->panel to be valid is wrong. IS_ERR() > has been used, but that macro doesn't check if tcon->panel pointer is > null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO). > > Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as > condition to check if it's a pointer not null. > > Signed-off-by: Giulio Benetti The commit log should be improved. The issue isn't really with the IS_ERR macro as you suggest, but that what is returned by of_drm_find_panel, and thus stored in tcon->panel. is not an error pointer in the first place but a NULL pointer on error. So the check doesn't check for the proper thing. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if null
On Wed, Oct 03, 2018 at 04:24:58PM +0200, Giulio Benetti wrote: > If using tcon with VGA, We don't have support for VGA at the moment. Or are you talking about using a VGA bridge? > tcon->panel will be null(0), this will cause segmentation fault when > trying to dereference tcon->panel->connector. It's not a segmentation fault, but a null pointer dereference. And that case will also happen with bridges. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 04/18] drm/vmwgfx: Remove confused comment from vmw_du_connector_atomic_set_property
On Tue, Oct 02, 2018 at 04:36:31PM +, Thomas Hellstrom wrote:
> On 10/02/2018 05:15 PM, Ville Syrjälä wrote:
> > On Tue, Oct 02, 2018 at 03:35:12PM +0200, Daniel Vetter wrote:
> >> The core _does_ the call to drm_atomic_commit for you. That's pretty
> >> much the entire point of having the fancy new atomic_set/get_prop
> >> callbacks.
> >>
> >> Signed-off-by: Daniel Vetter
> >> Cc: VMware Graphics
> >> Cc: Sinclair Yeh
> >> Cc: Thomas Hellstrom
> >> ---
> >> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
> >> 1 file changed, 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> >> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> >> index 292e48feba83..049bd50eea87 100644
> >> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> >> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> >> @@ -2311,12 +2311,6 @@ vmw_du_connector_atomic_set_property(struct
> >> drm_connector *connector,
> >>
> >>if (property == dev_priv->implicit_placement_property) {
> >>vcs->is_implicit = val;
> >> -
> >> - /*
> >> - * We should really be doing a drm_atomic_commit() to
> >> - * commit the new state, but since this doesn't cause
> >> - * an immedate state change, this is probably ok
> >> - */
> >>du->is_implicit = vcs->is_implicit;
> > Maybe the comment is referring to delaying the du->is_implicit
> > assignment to commit time? Otherwise a TEST_ONLY/failed commit
> > will clobber this.
>
> The is_implicit property is made read-only in a vmwgfx recent commit.
> Not sure exactly where it ended up, though. (-fixes, -next or -limbo).
> Need to take a look.
I guess -limbo, since my tree contains both drm-fixes and drm-next. Or at
least they didn't make it to Dave yet.
-Daniel
>
>
> >
> > Hmm. There's both .set_property() and .atomic_set_property()
> > in there. I wonder what that's about.
>
> Probably a leftover. I take it .set_property() is not needed when we
> have .atomic_set_property()?
>
> /Thomas
>
> >
> >>} else {
> >>return -EINVAL;
> >> --
> >> 2.19.0.rc2
> >>
> >> ___
> >> Intel-gfx mailing list
> >> intel-...@lists.freedesktop.org
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fintel-gfx&data=02%7C01%7Cthellstrom%40vmware.com%7C8376824afaaa4e7ebd6808d6287a0a88%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636740901969428557&sdata=JDQsTWKhvZAyUnW76dNMFGm0nzJIJjNrSSJYtDuqDlg%3D&reserved=0
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][drm-next] drm/vmwgfx: remove redundant return ret statement
Good catch.
Reviewed-by: Sinclair Yeh
On Thu, Oct 04, 2018 at 06:49:53PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The return statement is redundant as there is a return statement
> immediately before it so we have dead code that can be removed.
> Also remove the unused declaration of ret.
>
> Detected by CoverityScan, CID#1473793 ("Structurally dead code")
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 5a6b70ba137a..260650bb5560 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -1738,7 +1738,6 @@ static int vmw_cmd_check_define_gmrfb(struct
> vmw_private *dev_priv,
> void *buf)
> {
> struct vmw_buffer_object *vmw_bo;
> - int ret;
>
> struct {
> uint32_t header;
> @@ -1748,7 +1747,6 @@ static int vmw_cmd_check_define_gmrfb(struct
> vmw_private *dev_priv,
> return vmw_translate_guest_ptr(dev_priv, sw_context,
> &cmd->body.ptr,
> &vmw_bo);
> - return ret;
> }
>
>
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201275] Power consumption RX560 idle raised from 7 W to 13 W
https://bugzilla.kernel.org/show_bug.cgi?id=201275 --- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) --- I don't think this is a bug. The problem is, prior to that patch, the display component was requesting minimum clocks that were 10x too low. This saved power, but led to display problems on some systems because the clocks were too low to sustain the display requirements. -- 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 01/21] drm/amdgpu: Remove default best_encoder hook from DC
For atomic driver this is the default, no need to reimplement it. We
still need to keep the copypasta for not-atomic drivers though, since
no one polished the legacy crtc helpers as much as the atomic ones.
v2: amdgpu uses ->best_encoder internally, give it a local copy. It
might be a good idea to merge the connector and encoder into one
amdgpu_dm_sink structure, that might match DC internals better. At
least for non-DPMST outputs. Kudos to Ville for spotting this.
v3: Rebase onto a487411a6481 ("drm/amd/display: Use DRM helper for
best_encoder").
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Andrey Grodzovsky
Cc: Tony Cheng
Cc: "Leo (Sunpeng) Li"
Cc: Shirish S
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6a2342d72742..107e70658238 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3189,7 +3189,6 @@ amdgpu_dm_connector_helper_funcs = {
*/
.get_modes = get_modes,
.mode_valid = amdgpu_dm_connector_mode_valid,
- .best_encoder = drm_atomic_helper_best_encoder
};
static void dm_crtc_helper_disable(struct drm_crtc *crtc)
@@ -3592,14 +3591,17 @@ static int to_drm_connector_type(enum signal_type st)
}
}
+static struct drm_encoder *amdgpu_dm_connector_to_encoder(struct drm_connector
*connector)
+{
+ return drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[0]);
+}
+
static void amdgpu_dm_get_native_mode(struct drm_connector *connector)
{
- const struct drm_connector_helper_funcs *helper =
- connector->helper_private;
struct drm_encoder *encoder;
struct amdgpu_encoder *amdgpu_encoder;
- encoder = helper->best_encoder(connector);
+ encoder = amdgpu_dm_connector_to_encoder(connector);
if (encoder == NULL)
return;
@@ -3726,14 +3728,12 @@ static void amdgpu_dm_connector_ddc_get_modes(struct
drm_connector *connector,
static int amdgpu_dm_connector_get_modes(struct drm_connector *connector)
{
- const struct drm_connector_helper_funcs *helper =
- connector->helper_private;
struct amdgpu_dm_connector *amdgpu_dm_connector =
to_amdgpu_dm_connector(connector);
struct drm_encoder *encoder;
struct edid *edid = amdgpu_dm_connector->edid;
- encoder = helper->best_encoder(connector);
+ encoder = amdgpu_dm_connector_to_encoder(connector);
if (!edid || !drm_edid_is_valid(edid)) {
amdgpu_dm_connector->num_modes =
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/21] drm/vmwgfx: Remove confused comment from vmw_du_connector_atomic_set_property
The core _does_ the call to drm_atomic_commit for you. That's pretty
much the entire point of having the fancy new atomic_set/get_prop
callbacks.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 91ad45b22fee..a50fb0360317 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2303,12 +2303,6 @@ vmw_du_connector_atomic_set_property(struct
drm_connector *connector,
if (property == dev_priv->implicit_placement_property) {
vcs->is_implicit = val;
-
- /*
-* We should really be doing a drm_atomic_commit() to
-* commit the new state, but since this doesn't cause
-* an immedate state change, this is probably ok
-*/
du->is_implicit = vcs->is_implicit;
} else {
return -EINVAL;
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/21] drm/atomic-helper: Unexport drm_atomic_helper_best_encoder
It's the default. The exported version was kinda a transition state,
before we made this the default.
To stop new atomic drivers from using it (instead of just relying on
the default) let's unexport it.
v2: rename the default implementation to a more fitting name and add a
comment (Laurent)
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Cc: Archit Taneja
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Hans Verkuil
Cc: Daniel Vetter
Cc: Russell King
Cc: Jernej Skrabec
Cc: Jani Nikula
Cc: Pierre-Hugues Husson
Cc: Fabio Estevam
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 -
drivers/gpu/drm/drm_atomic_helper.c | 32 +--
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 -
include/drm/drm_atomic_helper.h | 2 --
6 files changed, 13 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ac37c50d6c4b..5ac979d3450b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1957,7 +1957,6 @@ static const struct drm_connector_funcs
dw_hdmi_connector_funcs = {
static const struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs
= {
.get_modes = dw_hdmi_connector_get_modes,
- .best_encoder = drm_atomic_helper_best_encoder,
};
static int dw_hdmi_bridge_attach(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index f92b7cf4cbd7..3be6c93be0f0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -92,6 +92,17 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
*state,
}
}
+/*
+ * For connectors that support multiple encoders, either the
+ * .atomic_best_encoder() or .best_encoder() operation must be implemented.
+ */
+static struct drm_encoder *
+pick_single_encoder_for_connector(struct drm_connector *connector)
+{
+ WARN_ON(connector->encoder_ids[1]);
+ return drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[0]);
+}
+
static int handle_conflicting_encoders(struct drm_atomic_state *state,
bool disable_conflicting_encoders)
{
@@ -119,7 +130,7 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
- new_encoder = drm_atomic_helper_best_encoder(connector);
+ new_encoder =
pick_single_encoder_for_connector(connector);
if (new_encoder) {
if (encoder_mask & drm_encoder_mask(new_encoder)) {
@@ -316,7 +327,7 @@ update_connector_routing(struct drm_atomic_state *state,
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
- new_encoder = drm_atomic_helper_best_encoder(connector);
+ new_encoder = pick_single_encoder_for_connector(connector);
if (!new_encoder) {
DRM_DEBUG_ATOMIC("No suitable encoder found for
[CONNECTOR:%d:%s]\n",
@@ -3376,23 +3387,6 @@ int drm_atomic_helper_page_flip_target(struct drm_crtc
*crtc,
}
EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
-/**
- * drm_atomic_helper_best_encoder - Helper for
- * &drm_connector_helper_funcs.best_encoder callback
- * @connector: Connector control structure
- *
- * This is a &drm_connector_helper_funcs.best_encoder callback helper for
- * connectors that support exactly 1 encoder, statically determined at driver
- * init time.
- */
-struct drm_encoder *
-drm_atomic_helper_best_encoder(struct drm_connector *connector)
-{
- WARN_ON(connector->encoder_ids[1]);
- return drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[0]);
-}
-EXPORT_SYMBOL(drm_atomic_helper_best_encoder);
-
/**
* DOC: atomic state reset and initialization
*
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 723578117191..4b5378495eea 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -274,7 +274,6 @@ static const struct drm_connector_funcs
vmw_legacy_connector_funcs = {
static const struct
drm_connector_helper_funcs vmw_ldu_connector_helper_funcs = {
- .best_encoder = drm_atomic_helper_best_encoder,
};
/*
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 53316b1bda3d..333418dc259f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -389,7 +389,6 @@ static const struct drm_connector_funcs
vm
[PATCH 09/21] drm/atmel: Drop transitional hooks
These do absolutely nothing for atomic drivers.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 9e34bce089d0..96f4082671fe 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -364,9 +364,7 @@ static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc
*crtc,
static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
.mode_valid = atmel_hlcdc_crtc_mode_valid,
- .mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
- .mode_set_base = drm_helper_crtc_mode_set_base,
.atomic_check = atmel_hlcdc_crtc_atomic_check,
.atomic_begin = atmel_hlcdc_crtc_atomic_begin,
.atomic_flush = atmel_hlcdc_crtc_atomic_flush,
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/21] drm/vmwgfx: Add FIXME comments for customer page_flip handlers
The idea behind allowing drivers to override legacy ioctls (instead of using the generic implementations unconditionally) is to handle bugs in old driver-specific userspace. Like e.g. vmw_kms_set_config does, to work around some vmwgfx userspace not clearing its ioctl structs properly. But you can't use it to augment semantics and put in additional checks, since from a correctly working userspace's pov there should not be any difference in behaviour between the legacy and the atomic paths. vmwgfx seems to be doing some strange things in its page_flip handlers. Since I'm not an expert of this codebase just wrap some FIXME comments around the potentially problematic code. Signed-off-by: Daniel Vetter Cc: VMware Graphics Cc: Sinclair Yeh Cc: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 ++ drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c index 333418dc259f..0bdf785f2aad 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c @@ -326,6 +326,7 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc, struct vmw_private *dev_priv = vmw_priv(crtc->dev); int ret; + /* FIMXE: This check needs to be moved into ->atomic_check code. */ if (!vmw_kms_crtc_flippable(dev_priv, crtc)) return -EINVAL; @@ -335,6 +336,7 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc, return ret; } + /* FIMXE: This code needs to be moved into ->atomic_commit callbacks. */ if (vmw_crtc_to_du(crtc)->is_implicit) vmw_kms_update_implicit_fb(dev_priv, crtc); diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c index c3e435f444c1..b8f4be159f91 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c @@ -501,6 +501,7 @@ static int vmw_stdu_crtc_page_flip(struct drm_crtc *crtc, struct vmw_screen_target_display_unit *stdu = vmw_crtc_to_stdu(crtc); int ret; + /* FIMXE: This check needs to be moved into ->atomic_check code. */ if (!stdu->defined || !vmw_kms_crtc_flippable(dev_priv, crtc)) return -EINVAL; -- 2.19.0.rc2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/21] drm/vmwgfx: Don't look at state->allow_modeset
That's purely for the uapi layer to implement the ALLOW_MODESET flag.
Drivers should instead look at the state, e.g. through
drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove
the confusing comment, since checking allow_modeset is at best a micro
optimization.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index dca04d4246ea..91ad45b22fee 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1681,14 +1681,6 @@ vmw_kms_atomic_check_modeset(struct drm_device *dev,
if (ret)
return ret;
- if (!state->allow_modeset)
- return ret;
-
- /*
-* Legacy path do not set allow_modeset properly like
-* @drm_atomic_helper_update_plane, This will result in unnecessary call
-* to vmw_kms_check_topology. So extra set of check.
-*/
for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (drm_atomic_crtc_needs_modeset(crtc_state))
need_modeset = true;
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/21] atomic helper cleanup, take 2
Hi all, Resend mostly unchanged, except a few patches tacked on a the end. Main goal here is to get intel-gfx-ci to approve this, since last time around patchwork didn't parse what I've done :-) Still a bunch of unreviewed stuff, so feedback highly welcome. Cheers, Daniel Daniel Vetter (20): drm/amdgpu: Remove default best_encoder hook from DC drm/atomic-helper: Unexport drm_atomic_helper_best_encoder drm: Extract drm_atomic_state_helper.[hc] drm/vmwgfx: Don't look at state->allow_modeset drm/vmwgfx: Remove confused comment from vmw_du_connector_atomic_set_property drm/atomic: Improve docs for drm_atomic_state->allow_modeset drm/vmwgfx: Add FIXME comments for customer page_flip handlers drm/arcpgu: Drop transitional hooks drm/atmel: Drop transitional hooks drm/arcpgu: Use drm_atomic_helper_shutdown drm/msm: Use drm_atomic_helper_shutdown drm/sti: Use drm_atomic_helper_shutdown drm/vc4: Use drm_atomic_helper_shutdown drm/zte: Use drm_atomic_helper_shutdown drm: Remove transitional helpers drm: Unexport drm_plane_helper_check_update drm: Unexport primary plane helpers drm/doc: fix drm_driver_legacy_fb_format drm/todo: Add some cleanup tasks drm/doc: kerneldoc for quirk_addfb_prefer_xbgr_30bpp Thomas Hellstrom (1): drm/vmwgfx: Fix vmw_du_cursor_plane_atomic_check Documentation/gpu/drm-kms-helpers.rst | 19 +- Documentation/gpu/todo.rst| 10 + drivers/gpu/drm/Makefile | 3 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +- drivers/gpu/drm/arc/arcpgu_crtc.c | 3 - drivers/gpu/drm/arc/arcpgu_drv.c | 1 + .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 - drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 - drivers/gpu/drm/drm_atomic_helper.c | 598 + drivers/gpu/drm/drm_atomic_state_helper.c | 601 ++ drivers/gpu/drm/drm_crtc_helper.c | 115 drivers/gpu/drm/drm_fourcc.c | 6 +- drivers/gpu/drm/drm_plane_helper.c| 331 +- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 - drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 1 - drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 1 - drivers/gpu/drm/msm/msm_drv.c | 1 + drivers/gpu/drm/sti/sti_cursor.c | 1 - drivers/gpu/drm/sti/sti_drv.c | 6 +- drivers/gpu/drm/sti/sti_gdp.c | 1 - drivers/gpu/drm/sti/sti_hqvdp.c | 1 - drivers/gpu/drm/vc4/vc4_drv.c | 3 + drivers/gpu/drm/vc4/vc4_plane.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 38 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +- drivers/gpu/drm/zte/zx_drm_drv.c | 1 + drivers/gpu/drm/zte/zx_plane.c| 1 - include/drm/drm_atomic.h | 10 +- include/drm/drm_atomic_helper.h | 46 +- include/drm/drm_atomic_state_helper.h | 80 +++ include/drm/drm_crtc_helper.h | 6 - include/drm/drm_mode_config.h | 7 + include/drm/drm_plane_helper.h| 35 - 35 files changed, 793 insertions(+), 1159 deletions(-) create mode 100644 drivers/gpu/drm/drm_atomic_state_helper.c create mode 100644 include/drm/drm_atomic_state_helper.h -- 2.19.0.rc2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/21] drm/atomic: Improve docs for drm_atomic_state->allow_modeset
Motivated by vmwgfx digging around in core uapi bits it shouldn't dig
around in.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d6adebcd6ea4..c09ecaf43825 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -254,7 +254,6 @@ struct __drm_private_objs_state {
* struct drm_atomic_state - the global state object for atomic updates
* @ref: count of all references to this state (will not be freed until zero)
* @dev: parent DRM device
- * @allow_modeset: allow full modeset
* @legacy_cursor_update: hint to enforce legacy cursor IOCTL semantics
* @async_update: hint for asynchronous plane update
* @planes: pointer to array of structures with per-plane data
@@ -273,6 +272,15 @@ struct drm_atomic_state {
struct kref ref;
struct drm_device *dev;
+
+ /**
+* @allow_modeset:
+*
+* Allow full modeset. This is used by the ATOMIC IOCTL handler to
+* implement the DRM_MODE_ATOMIC_ALLOW_MODESET flag. Drivers should
+* never consult this flag, instead looking at the output of
+* drm_atomic_crtc_needs_modeset().
+*/
bool allow_modeset : 1;
bool legacy_cursor_update : 1;
bool async_update : 1;
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/21] drm: Extract drm_atomic_state_helper.[hc]
We already have a separate overview doc for this, makes sense to
untangle it from the overall atomic helpers.
v2: Rebase
v3: Rebase more.
Acked-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 19 +-
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_atomic_helper.c | 566
drivers/gpu/drm/drm_atomic_state_helper.c | 601 ++
include/drm/drm_atomic_helper.h | 44 +-
include/drm/drm_atomic_state_helper.h | 80 +++
6 files changed, 698 insertions(+), 615 deletions(-)
create mode 100644 drivers/gpu/drm/drm_atomic_state_helper.c
create mode 100644 include/drm/drm_atomic_state_helper.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index f9cfcdcdf024..4b4dc236ef6f 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -59,19 +59,28 @@ Implementing Asynchronous Atomic Commit
.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
:doc: implementing nonblocking commit
+Helper Functions Reference
+--
+
+.. kernel-doc:: include/drm/drm_atomic_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+ :export:
+
Atomic State Reset and Initialization
-
-.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c
:doc: atomic state reset and initialization
-Helper Functions Reference
---
+Atomic State Helper Reference
+-
-.. kernel-doc:: include/drm/drm_atomic_helper.h
+.. kernel-doc:: include/drm/drm_atomic_state_helper.h
:internal:
-.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c
:export:
Simple KMS Helper Reference
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index bc6a16a3c36e..576ba985e138 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -36,7 +36,8 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
- drm_scdc_helper.o drm_gem_framebuffer_helper.o
+ drm_scdc_helper.o drm_gem_framebuffer_helper.o \
+ drm_atomic_state_helper.o
drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 3be6c93be0f0..8019e380586c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3386,569 +3386,3 @@ int drm_atomic_helper_page_flip_target(struct drm_crtc
*crtc,
return ret;
}
EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
-
-/**
- * DOC: atomic state reset and initialization
- *
- * Both the drm core and the atomic helpers assume that there is always the
full
- * and correct atomic software state for all connectors, CRTCs and planes
- * available. Which is a bit a problem on driver load and also after system
- * suspend. One way to solve this is to have a hardware state read-out
- * infrastructure which reconstructs the full software state (e.g. the i915
- * driver).
- *
- * The simpler solution is to just reset the software state to everything off,
- * which is easiest to do by calling drm_mode_config_reset(). To facilitate
this
- * the atomic helpers provide default reset implementations for all hooks.
- *
- * On the upside the precise state tracking of atomic simplifies system suspend
- * and resume a lot. For drivers using drm_mode_config_reset() a complete
recipe
- * is implemented in drm_atomic_helper_suspend() and
drm_atomic_helper_resume().
- * For other drivers the building blocks are split out, see the documentation
- * for these functions.
- */
-
-/**
- * drm_atomic_helper_crtc_reset - default &drm_crtc_funcs.reset hook for CRTCs
- * @crtc: drm CRTC
- *
- * Resets the atomic state for @crtc by freeing the state pointer (which might
- * be NULL, e.g. at driver load time) and allocating a new empty state object.
- */
-void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc)
-{
- if (crtc->state)
- __drm_atomic_helper_crtc_destroy_state(crtc->state);
-
- kfree(crtc->state);
- crtc->state = kzalloc(sizeof(*crtc->state), GFP_KERNEL);
-
- if (crtc->state)
- crtc->state->crtc = crtc;
-}
-EXPORT_SYMBOL(drm_atomic_helper_crtc_reset);
-
-/**
- * __drm_atomic_helper_crtc_duplicate_state - copy atomic CRTC state
- * @crtc: CRTC object
- * @state: atomic CRTC state
- *
- * Copies atomic state from a CRTC's current state and resets inferred values.
- * Th
[PATCH 12/21] drm/sti: Use drm_atomic_helper_shutdown
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
The sti cleanup code seems supremely confused:
- In the load error path it calls drm_mode_config_cleanup before it
stops various kms services like poll worker or fbdev emulation.
That's going to oops.
- The actual unload code doesn't even bother with the cleanup and just
leaks.
Try to fix this while at it.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Benjamin Gaignard
Cc: Vincent Abriou
---
drivers/gpu/drm/sti/sti_cursor.c | 1 -
drivers/gpu/drm/sti/sti_drv.c| 6 +++---
drivers/gpu/drm/sti/sti_gdp.c| 1 -
drivers/gpu/drm/sti/sti_hqvdp.c | 1 -
4 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index 57b870e1e696..bc908453ffb3 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -332,7 +332,6 @@ static void sti_cursor_destroy(struct drm_plane *drm_plane)
{
DRM_DEBUG_DRIVER("\n");
- drm_plane_helper_disable(drm_plane, NULL);
drm_plane_cleanup(drm_plane);
}
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 6dced8abcf16..ac54e0f9caea 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -206,6 +206,8 @@ static void sti_cleanup(struct drm_device *ddev)
struct sti_private *private = ddev->dev_private;
drm_kms_helper_poll_fini(ddev);
+ drm_atomic_helper_shutdown(ddev);
+ drm_mode_config_cleanup(ddev);
component_unbind_all(ddev->dev, ddev);
kfree(private);
ddev->dev_private = NULL;
@@ -230,7 +232,7 @@ static int sti_bind(struct device *dev)
ret = drm_dev_register(ddev, 0);
if (ret)
- goto err_register;
+ goto err_cleanup;
drm_mode_config_reset(ddev);
@@ -238,8 +240,6 @@ static int sti_bind(struct device *dev)
return 0;
-err_register:
- drm_mode_config_cleanup(ddev);
err_cleanup:
sti_cleanup(ddev);
err_drm_dev_put:
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index c32de6cbf061..3c19614d3f75 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -883,7 +883,6 @@ static void sti_gdp_destroy(struct drm_plane *drm_plane)
{
DRM_DEBUG_DRIVER("\n");
- drm_plane_helper_disable(drm_plane, NULL);
drm_plane_cleanup(drm_plane);
}
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 03ac3b4a4469..23565f52dd71 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1260,7 +1260,6 @@ static void sti_hqvdp_destroy(struct drm_plane *drm_plane)
{
DRM_DEBUG_DRIVER("\n");
- drm_plane_helper_disable(drm_plane, NULL);
drm_plane_cleanup(drm_plane);
}
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/21] drm/arcpgu: Drop transitional hooks
These do absolutely nothing for atomic drivers.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 965cda48dc13..26cb2800f3ad 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -158,8 +158,6 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
.mode_valid = arc_pgu_crtc_mode_valid,
- .mode_set = drm_helper_crtc_mode_set,
- .mode_set_base = drm_helper_crtc_mode_set_base,
.mode_set_nofb = arc_pgu_crtc_mode_set_nofb,
.atomic_begin = arc_pgu_crtc_atomic_begin,
.atomic_enable = arc_pgu_crtc_atomic_enable,
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/21] drm/vc4: Use drm_atomic_helper_shutdown
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
v2: Rebase.
Reviewed-by: Ville Syrjälä
Acked-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_drv.c | 3 +++
drivers/gpu/drm/vc4/vc4_plane.c | 1 -
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 1f1780ccdbdf..f6f5cd80c04d 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include "uapi/drm/vc4_drm.h"
#include "vc4_drv.h"
@@ -308,6 +309,8 @@ static void vc4_drm_unbind(struct device *dev)
drm_dev_unregister(drm);
+ drm_atomic_helper_shutdown(drm);
+
drm_mode_config_cleanup(drm);
drm_atomic_private_obj_fini(&vc4->ctm_manager);
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 9dc3fcbd290b..d04b3c3246ba 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -903,7 +903,6 @@ static const struct drm_plane_helper_funcs
vc4_plane_helper_funcs = {
static void vc4_plane_destroy(struct drm_plane *plane)
{
- drm_plane_helper_disable(plane, NULL);
drm_plane_cleanup(plane);
}
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/21] drm/zte: Use drm_atomic_helper_shutdown
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Shawn Guo
---
drivers/gpu/drm/zte/zx_drm_drv.c | 1 +
drivers/gpu/drm/zte/zx_plane.c | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 5b6f1eda52e0..f5ea32ae8600 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -124,6 +124,7 @@ static void zx_drm_unbind(struct device *dev)
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
+ drm_atomic_helper_shutdown(drm);
drm_mode_config_cleanup(drm);
component_unbind_all(dev, drm);
dev_set_drvdata(dev, NULL);
diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index ae8c53b4b261..83d236fd893c 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -446,7 +446,6 @@ static const struct drm_plane_helper_funcs
zx_gl_plane_helper_funcs = {
static void zx_plane_destroy(struct drm_plane *plane)
{
- drm_plane_helper_disable(plane, NULL);
drm_plane_cleanup(plane);
}
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
