[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

[bugzilla-daemon]

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

--- Comment #15 from Marek Olšák  ---
We can add "glsl_correct_derivatives_after_discard=true" to Mesa's drirc and
call it a day.

-- 
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 106164] dal_gpio_open_ex+0x34/0x180 [amdgpu]

[bugzilla-daemon]

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

Bug ID: 106164
   Summary: dal_gpio_open_ex+0x34/0x180 [amdgpu]
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: higu...@gmx.net

Created attachment 138965
  --> https://bugs.freedesktop.org/attachment.cgi?id=138965=edit
full dmesg log

With kernel 4.16.2 and mesa 18.0 i get the attach oops when booting on a Asus
RX480. With kernel 4.15.x i also had the same (or similar) oops.

Other than the kernel dmesg, i do not see any problem, even fan and cpu
temperature are reported by the sensors command

-- 
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: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Botello Ortega, Luis]

Hi all:

We tested GLK DMC 1.04 FW in last week of September 2017, using the latest 
drm-tip version for that time (4.14.0-rc2) and according to our results we 
could declare this FW as acceptable and healthy to be used with kernel version 
4.14 . 
However, we cannot guarantee quality and healthy of this FW if it is used in 
top of current drm-tip kernel (4.17-rc0).

Best Regards
Luis Botello


-Original Message-
From: Srivatsa, Anusha 
Sent: Friday, April 20, 2018 1:30 PM
To: Vivi, Rodrigo ; Jani Nikula 
; Botello Ortega, Luis 
; Martinez Monroy, Elio 

Cc: Ian W MORRISON ; airl...@linux.ie; Greg KH 
; intel-...@lists.freedesktop.org; 
linux-ker...@vger.kernel.org; sta...@vger.kernel.org; 
dri-devel@lists.freedesktop.org; Wajdeczko, Michal 
Subject: RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake



>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, April 20, 2018 11:04 AM
>To: Jani Nikula 
>Cc: Srivatsa, Anusha ; Ian W MORRISON 
>; airl...@linux.ie; Greg KH 
>; intel-...@lists.freedesktop.org; linux- 
>ker...@vger.kernel.org; sta...@vger.kernel.org; dri- 
>de...@lists.freedesktop.org; Wajdeczko, Michal 
>
>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for 
>Geminilake
>
>On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote:
>> On Mon, 16 Apr 2018, "Srivatsa, Anusha"  wrote:
>> >>-Original Message-
>> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >>Sent: Wednesday, April 11, 2018 5:27 AM
>> >>To: Ian W MORRISON 
>> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha 
>> >>; Wajdeczko, Michal 
>> >>; Greg KH ; 
>> >>airl...@linux.ie; joonas.lahti...@linux.intel.com; 
>> >>linux-ker...@vger.kernel.org; sta...@vger.kernel.org; 
>> >>intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org
>> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE 
>> >>for Geminilake
>> >>
>> >>On Wed, 11 Apr 2018, Ian W MORRISON  wrote:
>> >>> 
>> >>>
>> 
>>  NAK on indiscriminate Cc: stable. There are zero guarantees that 
>>  older kernels will work with whatever firmware you throw at them.
>> 
>> >>>
>> >>> I included 'Cc: stable' so the patch would get added to the v4.16 
>> >>> and
>> >>> v4.15 kernels which I have tested with the patch. I found that 
>> >>> earlier kernels didn't support the 'linux-firmware' package 
>> >>> required to get wifi working on Intel's new Gemini Lake NUC.
>> >>
>> >>You realize that this patch should have nothing to do with wifi?
>> >>
>> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please 
>> >>indicate the specific versions of stable it is appropriate for.
>> >
>> > Hi Jani,
>> >
>> > The stable kernel version is 4.12 and beyond.
>> > It is appropriate to add the CC: stable in my opinion
>>
>> Who tested the firmware with v4.12 and later? We only have the CI 
>> results against *current* drm-tip. We don't even know about v4.16.
>>
>
>I understand your concerns, but the problem was that our old process 
>was a bit
>(lot?) messed and there was the unreliable time until the firmware 
>really lands on linux-firmware.git. So MODULE_FIRMWARE call was only 
>added after firmware was really there on firmware repository but it wasn't 
>about the testing.
>
>In other words, the bump version patch was merged after tested, but 
>MODULE_FIRMWARE was left behind because firmware blob took a while to 
>get pulled into linux-firmware.git and we end up forgetting to add it there.
>
>In my opinion it should be safe to add the MODULE_FIRMWARE there based 
>on the tests from when the version was bumped.

Luis, Elio, can you guys confirm that this firmware is tested and healthy? And 
also, give a tested-by to this patch please?

Thanks,
Anusha 
>> I'm not going to ack and take responsibility for the stable backports 
>> unless someone actually comes forward with credible Tested-bys.
>>
>> BR,
>> Jani.
>>
>>
>> >
>> > Anusha
>> >>BR,
>> >>Jani.
>> >>
>> >>>
>> 
>>  PS. How is this a "RESEND"? I haven't seen this before.
>> 
>> >>>
>> >>> It is a 'RESEND' for that very reason. I initially sent the patch 
>> >>> to the same people as a similar patch
>> >>> (https://patchwork.kernel.org/patch/10143637/) however after 
>> >>> realising this omitted required addresses I added them and resent 
>> >>> the
>patch.
>> >>>
>> >>> Best regards,
>> >>> Ian
>> >>
>> >>--
>> >>Jani Nikula, Intel Open Source Technology Center
>>
>> --
>> Jani Nikula, Intel Open Source 

[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #30 from Marek Olšák  ---
This might fix it:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=d15fb766aa3c98ffbe16d050b2af4804e4b12c57

-- 
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 v2] drm/vc4: Add support for plane alpha

[Stefan Schake]

The HVS supports mixing fixed alpha with per-pixel alpha or
setting a fixed plane alpha in case there is no per-pixel information.
This allows us to support the generic DRM plane alpha property.

Signed-off-by: Stefan Schake 
---
v2: Non-opaque plane alpha can trigger the background blending issue
and we need to hint the CRTC that background fill might be required.

 drivers/gpu/drm/vc4/vc4_plane.c | 21 +
 drivers/gpu/drm/vc4/vc4_regs.h  |  1 +
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index c3a37a99e601..3483c05cc3d6 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -201,6 +201,7 @@ static void vc4_plane_reset(struct drm_plane *plane)
return;
 
plane->state = _state->base;
+   plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
vc4_state->base.plane = plane;
 }
 
@@ -467,6 +468,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
u32 ctl0_offset = vc4_state->dlist_count;
const struct hvs_format *format = 
vc4_get_hvs_format(fb->format->format);
int num_planes = drm_format_num_planes(format->drm);
+   bool mix_plane_alpha;
bool covers_screen;
u32 scl0, scl1, pitch0;
u32 lbm_size, tiling;
@@ -552,7 +554,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
/* Position Word 0: Image Positions and Alpha Value */
vc4_state->pos0_offset = vc4_state->dlist_count;
vc4_dlist_write(vc4_state,
-   VC4_SET_FIELD(0xff, SCALER_POS0_FIXED_ALPHA) |
+   VC4_SET_FIELD(state->alpha >> 8, 
SCALER_POS0_FIXED_ALPHA) |
VC4_SET_FIELD(vc4_state->crtc_x, SCALER_POS0_START_X) |
VC4_SET_FIELD(vc4_state->crtc_y, SCALER_POS0_START_Y));
 
@@ -565,6 +567,13 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
  SCALER_POS1_SCL_HEIGHT));
}
 
+   /* Don't waste cycles mixing with plane alpha if the set alpha
+* is opaque or there is no per-pixel alpha information.
+* In any case we use the alpha property value as the fixed alpha.
+*/
+   mix_plane_alpha = state->alpha != DRM_BLEND_ALPHA_OPAQUE &&
+ fb->format->has_alpha;
+
/* Position Word 2: Source Image Size, Alpha */
vc4_state->pos2_offset = vc4_state->dlist_count;
vc4_dlist_write(vc4_state,
@@ -572,6 +581,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
  SCALER_POS2_ALPHA_MODE_PIPELINE :
  SCALER_POS2_ALPHA_MODE_FIXED,
  SCALER_POS2_ALPHA_MODE) |
+   (mix_plane_alpha ? SCALER_POS2_ALPHA_MIX : 0) |
(fb->format->has_alpha ? SCALER_POS2_ALPHA_PREMULT : 0) 
|
VC4_SET_FIELD(vc4_state->src_w[0], SCALER_POS2_WIDTH) |
VC4_SET_FIELD(vc4_state->src_h[0], SCALER_POS2_HEIGHT));
@@ -653,10 +663,11 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
vc4_state->crtc_w == state->crtc->mode.hdisplay &&
vc4_state->crtc_h == state->crtc->mode.vdisplay;
/* Background fill might be necessary when the plane has per-pixel
-* alpha content and blends from the background or does not cover
-* the entire screen.
+* alpha content or a non-opaque plane alpha and could blend from the
+* background or does not cover the entire screen.
 */
-   vc4_state->needs_bg_fill = fb->format->has_alpha || !covers_screen;
+   vc4_state->needs_bg_fill = fb->format->has_alpha || !covers_screen ||
+  state->alpha != DRM_BLEND_ALPHA_OPAQUE;
 
return 0;
 }
@@ -916,5 +927,7 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
 
drm_plane_helper_add(plane, _plane_helper_funcs);
 
+   drm_plane_create_alpha_property(plane);
+
return plane;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index 4af3e29d076a..d1fb6fec46eb 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -945,6 +945,7 @@ enum hvs_pixel_format {
 #define SCALER_POS2_ALPHA_MODE_FIXED_NONZERO   2
 #define SCALER_POS2_ALPHA_MODE_FIXED_OVER_0x07 3
 #define SCALER_POS2_ALPHA_PREMULT  BIT(29)
+#define SCALER_POS2_ALPHA_MIX  BIT(28)
 
 #define SCALER_POS2_HEIGHT_MASKVC4_MASK(27, 16)
 #define SCALER_POS2_HEIGHT_SHIFT   16
-- 
2.14.1

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

Re: [PATCH] drm/vc4: Add support for plane alpha

[Stefan Schake]

On Sat, Apr 21, 2018 at 1:45 AM, Eric Anholt  wrote:
> Stefan Schake  writes:
>
>> The HVS supports mixing fixed alpha with per-pixel alpha or
>> setting a fixed plane alpha in case there is no per-pixel information.
>> This allows us to support the generic DRM plane alpha property.
>
> Don't we need to set needs_bg_fill based on alpha != OPAQUE, as well?
>
> Other than that, looks good to me.

I did forget about the whole background situation, and a quick test
shows you are right: anything less than opaque has the funky
repeating pattern artifact.

Thanks, I'll send a new version.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Add support for plane alpha

[Eric Anholt]

Stefan Schake  writes:

> The HVS supports mixing fixed alpha with per-pixel alpha or
> setting a fixed plane alpha in case there is no per-pixel information.
> This allows us to support the generic DRM plane alpha property.

Don't we need to set needs_bg_fill based on alpha != OPAQUE, as well?

Other than that, looks good to me.


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

Re: [PATCH 2/2] drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+

[Eric Anholt]

Daniel Vetter  writes:

> On Thu, Apr 19, 2018 at 12:20:35PM -0700, Eric Anholt wrote:
>> This driver will be used to support Mesa on the Broadcom 7268 and 7278
>> platforms.
>> 
>> V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's
>> complicated CL/shader validation scheme.  This massively changes the
>> GEM behavior, so I've forked off to a new driver.
>> 
>> Signed-off-by: Eric Anholt 
>
> Read through the entire thing, ignored the hw details, but dropped a few
> comments all over. With those addressed one way or another this has my
>
> Acked-by: Daniel Vetter 
>
> Can I call in a return favour for
> https://patchwork.freedesktop.org/series/41219/ ?

Done.

>> diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
>> index d3ab6abae838..f982558fc25d 100644
>> --- a/Documentation/gpu/drivers.rst
>> +++ b/Documentation/gpu/drivers.rst
>> @@ -10,6 +10,7 @@ GPU Driver Documentation
>> tegra
>> tinydrm
>> tve200
>> +   v3d
>> vc4
>> bridge/dw-hdmi
>> xen-front
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index bca3c32fb141..7314d66833fd 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -4795,6 +4795,15 @@ S:Maintained
>>  F:  drivers/gpu/drm/omapdrm/
>>  F:  Documentation/devicetree/bindings/display/ti/
>>  
>> +DRM DRIVERS FOR V3D
>> +M:  Eric Anholt 
>> +T:  git git://github.com/anholt/linux
>
> This one also official? If it's just for now I'd drop it ...

Sure.

>> +/* Pins the shmem pages, fills in the .pages and .sgt fields of the BO, and 
>> maps
>> + * it for DMA.
>> + */
>> +static int
>> +v3d_bo_get_pages(struct v3d_bo *bo)
>> +{
>> +struct drm_gem_object *obj = >base;
>> +struct drm_device *dev = obj->dev;
>> +int npages = obj->size >> PAGE_SHIFT;
>> +int ret = 0;
>> +
>> +mutex_lock(>lock);
>> +if (bo->pages_refcount++ != 0)
>> +goto unlock;
>> +
>> +if (!obj->import_attach) {
>> +bo->pages = drm_gem_get_pages(obj);
>> +if (IS_ERR(bo->pages)) {
>> +ret = PTR_ERR(bo->pages);
>> +goto unlock;
>> +}
>> +
>> +bo->sgt = drm_prime_pages_to_sg(bo->pages, npages);
>> +if (IS_ERR(bo->sgt)) {
>> +ret = PTR_ERR(bo->sgt);
>> +goto put_pages;
>> +}
>> +} else {
>> +bo->pages = kcalloc(npages, sizeof(*bo->pages), GFP_KERNEL);
>> +if (!bo->pages)
>> +goto put_pages;
>> +
>> +drm_prime_sg_to_page_addr_arrays(bo->sgt, bo->pages,
>> + NULL, npages);
>> +}
>> +
>> +/* Map the pages for use by the GPU. */
>> +dma_map_sg(dev->dev, bo->sgt->sgl,
>> +   bo->sgt->nents, DMA_BIDIRECTIONAL);
>
> For dma-buf you already get a mapped sgt, and the idea at least is to not
> noodle around in internals like drm_prime_sg_to_page_addr_arrays does ...
> That was just a hack Dave did to avoid rewriting all of ttm, which imo
> shouldn't be copied all over the place (but it happens).
>
> Since you immediately convert the page list back into a mapped sg table
> it's a bit silly.
>
> I guess longer-term we could switch the gem helpers to just use sg tables
> directly, instead of going through pages arrays. But core mm folks just
> got nasty on us doing that, so I'm not sure which direction we should go
> here longer-term.

I moved the map/unmap to the !import case.  We still need the pages
array for v3d_gem_fault().  If we have an alternative for that that
isn't a linear walk of the sg at fault time, I'd be up for that.

>> +int v3d_gem_fault(struct vm_fault *vmf)
>> +{
>> +struct vm_area_struct *vma = vmf->vma;
>> +struct drm_gem_object *obj = vma->vm_private_data;
>> +struct v3d_bo *bo = to_v3d_bo(obj);
>> +unsigned long pfn;
>> +pgoff_t pgoff;
>> +int ret;
>> +
>> +/* We don't use vmf->pgoff since that has the fake offset: */
>> +pgoff = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
>> +pfn = page_to_pfn(bo->pages[pgoff]);
>
> Freaked out for a bit, then noticed you're pinning everything. That makes
> the bo->pages_refcount a bit confusing since totally not needed.
>
> I guess if you do have longer-term plans to roll out a shrinker I'd put at
> least a FIXME here.

Yep, long-term shrinker plans.  Added a note to the kerneldoc about why
we don't shrink yet.

>> +int v3d_mmap(struct file *filp, struct vm_area_struct *vma)
>> +{
>> +int ret;
>> +
>> +ret = drm_gem_mmap(filp, vma);
>> +if (ret)
>> +return ret;
>> +
>> +v3d_set_mmap_vma_flags(vma);
>
> If it'd actually understand what these vma flag frobberies in most drivers
> do I might come up with an idea how we can avoid the copypaste. Oh well.
> Maybe a drm_gem_mmap_wc?

drm_gem_mmap seems to already be wc, just with different vma flags.  If
you ever figure 

[PATCH] drm/vc4: Add support for plane alpha

[Stefan Schake]

The HVS supports mixing fixed alpha with per-pixel alpha or
setting a fixed plane alpha in case there is no per-pixel information.
This allows us to support the generic DRM plane alpha property.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 14 +-
 drivers/gpu/drm/vc4/vc4_regs.h  |  1 +
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index c3a37a99e601..b06e0ec013c5 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -201,6 +201,7 @@ static void vc4_plane_reset(struct drm_plane *plane)
return;
 
plane->state = _state->base;
+   plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
vc4_state->base.plane = plane;
 }
 
@@ -467,6 +468,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
u32 ctl0_offset = vc4_state->dlist_count;
const struct hvs_format *format = 
vc4_get_hvs_format(fb->format->format);
int num_planes = drm_format_num_planes(format->drm);
+   bool mix_plane_alpha;
bool covers_screen;
u32 scl0, scl1, pitch0;
u32 lbm_size, tiling;
@@ -552,7 +554,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
/* Position Word 0: Image Positions and Alpha Value */
vc4_state->pos0_offset = vc4_state->dlist_count;
vc4_dlist_write(vc4_state,
-   VC4_SET_FIELD(0xff, SCALER_POS0_FIXED_ALPHA) |
+   VC4_SET_FIELD(state->alpha >> 8, 
SCALER_POS0_FIXED_ALPHA) |
VC4_SET_FIELD(vc4_state->crtc_x, SCALER_POS0_START_X) |
VC4_SET_FIELD(vc4_state->crtc_y, SCALER_POS0_START_Y));
 
@@ -565,6 +567,13 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
  SCALER_POS1_SCL_HEIGHT));
}
 
+   /* Don't waste cycles mixing with plane alpha if the set alpha
+* is opaque or there is no per-pixel alpha information.
+* In any case we use the alpha property value as the fixed alpha.
+*/
+   mix_plane_alpha = state->alpha != DRM_BLEND_ALPHA_OPAQUE &&
+ fb->format->has_alpha;
+
/* Position Word 2: Source Image Size, Alpha */
vc4_state->pos2_offset = vc4_state->dlist_count;
vc4_dlist_write(vc4_state,
@@ -572,6 +581,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
  SCALER_POS2_ALPHA_MODE_PIPELINE :
  SCALER_POS2_ALPHA_MODE_FIXED,
  SCALER_POS2_ALPHA_MODE) |
+   (mix_plane_alpha ? SCALER_POS2_ALPHA_MIX : 0) |
(fb->format->has_alpha ? SCALER_POS2_ALPHA_PREMULT : 0) 
|
VC4_SET_FIELD(vc4_state->src_w[0], SCALER_POS2_WIDTH) |
VC4_SET_FIELD(vc4_state->src_h[0], SCALER_POS2_HEIGHT));
@@ -916,5 +926,7 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
 
drm_plane_helper_add(plane, _plane_helper_funcs);
 
+   drm_plane_create_alpha_property(plane);
+
return plane;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index 4af3e29d076a..d1fb6fec46eb 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -945,6 +945,7 @@ enum hvs_pixel_format {
 #define SCALER_POS2_ALPHA_MODE_FIXED_NONZERO   2
 #define SCALER_POS2_ALPHA_MODE_FIXED_OVER_0x07 3
 #define SCALER_POS2_ALPHA_PREMULT  BIT(29)
+#define SCALER_POS2_ALPHA_MIX  BIT(28)
 
 #define SCALER_POS2_HEIGHT_MASKVC4_MASK(27, 16)
 #define SCALER_POS2_HEIGHT_SHIFT   16
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH] gpu: drm: i915: Change return type to vm_fault_t

[Rodrigo Vivi]

On Wed, Apr 18, 2018 at 08:46:44AM +0300, Jani Nikula wrote:
> On Tue, 17 Apr 2018, Souptick Joarder  wrote:
> > On 17-Apr-2018 9:45 PM, "Matthew Wilcox"  wrote:
> >>
> >> On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote:
> >> > Not exactly. The plan for these patches is to introduce new vm_fault_t
> > type
> >> > in vm_operations_struct fault handlers. It's now available in 4.17-rc1.
> > We will
> >> > push all the required drivers/filesystem changes through different
> > maintainers
> >> > to linus tree. Once everything is converted into vm_fault_t type then
> > Changing
> >> > it from a signed to an unsigned int causes GCC to warn about an
> > assignment
> >> > from an incompatible type -- int foo(void) is incompatible with
> >> > unsigned int foo(void).
> >> >
> >> > Please refer 1c8f422059ae ("mm: change return type to vm_fault_t") in
> > 4.17-rc1.
> >>
> >> I think this patch would be clearer if you did
> >>
> >> -   int ret;
> >> +   int err;
> >> +   vm_fault_t ret;
> >>
> >> Then it would be clearer to the maintainer that you're splitting apart the
> >> VM_FAULT and errno codes.
> >>
> >> Sorry for not catching this during initial review.
> >
> > Ok, I will make required changes and send v2. Sorry, even I missed this :)
> 
> I'm afraid Daniel is closer to the truth.

+1.

> My bad, sorry for the noise.

I opened this thread to add exactly question/noise ;).

So my recommendation for some next time is to make the intention clear
on the commit message itself from the begin.

> 
> BR,
> Jani.
> 
> 
> 
> >>
> >> > On Tue, Apr 17, 2018 at 8:59 PM, Jani Nikula
> >> >  wrote:
> >> > > On Tue, 17 Apr 2018, Souptick Joarder  wrote:
> >> > >> Use new return type vm_fault_t for fault handler. For
> >> > >> now, this is just documenting that the function returns
> >> > >> a VM_FAULT value rather than an errno. Once all instances
> >> > >> are converted, vm_fault_t will become a distinct type.
> >> > >>
> >> > >> Reference id -> 1c8f422059ae ("mm: change return type to
> >> > >> vm_fault_t")
> >> > >>
> >> > >> Signed-off-by: Souptick Joarder 
> >> > >> ---
> >> > >>  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
> >> > >>  drivers/gpu/drm/i915/i915_gem.c | 15 ---
> >> > >>  2 files changed, 10 insertions(+), 8 deletions(-)
> >> > >>
> >> > >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> >> > >> index a42deeb..95b0d50 100644
> >> > >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> > >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> > >> @@ -51,6 +51,7 @@
> >> > >>  #include 
> >> > >>  #include 
> >> > >>  #include 
> >> > >> +#include 
> >> > >>
> >> > >>  #include "i915_params.h"
> >> > >>  #include "i915_reg.h"
> >> > >> @@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct
> > drm_i915_private *dev_priv,
> >> > >>  unsigned int flags);
> >> > >>  int __must_check i915_gem_suspend(struct drm_i915_private
> > *dev_priv);
> >> > >>  void i915_gem_resume(struct drm_i915_private *dev_priv);
> >> > >> -int i915_gem_fault(struct vm_fault *vmf);
> >> > >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf);
> >> > >>  int i915_gem_object_wait(struct drm_i915_gem_object *obj,
> >> > >>unsigned int flags,
> >> > >>long timeout,
> >> > >> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> >> > >> index dd89abd..bdac690 100644
> >> > >> --- a/drivers/gpu/drm/i915/i915_gem.c
> >> > >> +++ b/drivers/gpu/drm/i915/i915_gem.c
> >> > >> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
> >> > >>   * The current feature set supported by i915_gem_fault() and thus
> > GTT mmaps
> >> > >>   * is exposed via I915_PARAM_MMAP_GTT_VERSION (see
> > i915_gem_mmap_gtt_version).
> >> > >>   */
> >> > >> -int i915_gem_fault(struct vm_fault *vmf)
> >> > >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> >> > >>  {
> >> > >>  #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
> >> > >>   struct vm_area_struct *area = vmf->vma;
> >> > >> @@ -1895,6 +1895,7 @@ int i915_gem_fault(struct vm_fault *vmf)
> >> > >>   pgoff_t page_offset;
> >> > >>   unsigned int flags;
> >> > >>   int ret;
> >> > >> + vm_fault_t retval;
> >> > >
> >> > > What's the point of changing the name? An unnecessary change.
> >> > >
> >> > > BR,
> >> > > Jani.
> >> > >
> >> > >>
> >> > >>   /* We don't use vmf->pgoff since that has the fake offset */
> >> > >>   page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
> >> > >> @@ -2000,7 +2001,7 @@ int i915_gem_fault(struct vm_fault *vmf)
> >> > >>* and so needs to be reported.
> >> > >>*/
> >> > >>   if (!i915_terminally_wedged(_priv->gpu_error)) {
> >> > >> - ret = VM_FAULT_SIGBUS;
> >> > >> + 

Re: [PATCH 8/9] drm/vc4: Always obey implicit sync

[Eric Anholt]

Daniel Vetter  writes:

> Same justification as for drm_gem_fb_prepare_fb.

Reviewed-by: Eric Anholt 


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

Re: [PATCH 7/9] drm/gem-fb-helper: Always do implicit sync

[Eric Anholt]

Daniel Vetter  writes:

> I've done a lot of history digging. The first signs of this
> optimization was introduced in i915:

I can't come up with any reason this would matter.  I almost came up
with "You're doing tearing X11 front buffer rendering, and you do a
modeset using the same fb, and so you block that modeset behind your
rendering."  Except that:

1) who cares
2) this helper is only for dma-bufs, not normal X11 rendering
3) your X11 driver should be doing pageflipping to be tear-free anyway,
   let's just fix that[1].

Reviewed-by: Eric Anholt 

[1] This is not actually me volunteering myself or anyone else to go fix
that.


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

Re: [PATCH 6/9] drm/atomic: better doc for implicit vs explicit fencing

[Eric Anholt]

Daniel Vetter  writes:

> Note that a pile of drivers don't seem to take implicit fencing into
> account, or at least don't call drm_atoimc_set_fence_for_plane().

 ^atomic

> Cc'ing relevant people, or at least some. Some drivers also look like
> they don't disable implicit fencing (e.g. amdgpu) because the explicit
> fences and implicit fences are handled by entirely independent code
> paths.
>
> I also wonder whether we shouldn't just make the recommended helpers
> the default ones, since a lot of drivers don't bother to handle the
> implicit fences at all it seems. The helpers won't blow up even for
> non-GEM drivers or GEM drivers which don't fill out the gem bo
> pointers in struct drm_framebuffer.
>
> Cc: Gerd Hoffmann 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Cc: Gustavo Padovan 
> Cc: Maarten Lankhorst 
> Cc: Sean Paul 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic.c | 8 
>  include/drm/drm_modeset_helper_vtables.h | 5 -
>  include/drm/drm_plane.h  | 7 ++-
>  3 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7d25c42f22db..ec77afbda0c3 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1492,6 +1492,14 @@ EXPORT_SYMBOL(drm_atomic_set_fb_for_plane);
>   * Otherwise, if _plane_state.fence is not set this function we just set 
> it
>   * with the received implicit fence. In both cases this function consumes a
>   * reference for @fence.
> + *
> + * This way explicit fencing can be used to overrule implicit fencing, which 
> is
> + * important to make explicit fencing use-cases work: One example is using 
> one
> + * buffer for 2 screens with different refresh rates. Implicit fencing will
> + * clamp rendering to the refresh rate of the slower screen, whereas explicit
> + * fence allows 2 independent render and display loops on a single buffer. 
> If a
> + * driver allows obeys both implicit and explicit fences for plane updates, 
> then
> + * it will break all the benefits of explicit fencing.
>   */

Thanks for explaining why we should care about explicit fencing for
display!  I'd been trying and failing to generate a usecase.

> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index d6da26d66a4b..1e2622e33208 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -80,7 +80,12 @@ struct drm_plane_state {
>* @fence:
>*
>* Optional fence to wait for before scanning out @fb. Do not write this
> -  * directly, use drm_atomic_set_fence_for_plane()
> +  * directly, use drm_atomic_set_fence_for_plane(). The core atomic code
> +  * will set this when userspace is using explicit fencing.

Optional suggestion:

 * Optional fence to wait for before scanning out @fb. The core
 * atomic code will set this when userspace is using explicit
 * fencing. Do not write this directly for a driver's implicit
 * fence, use drm_atomic_set_fence_for_plane() to ensure that
 * an explicit fence is preserved.

> +  *
> +  * Drivers should store any implicit fences in this from their

Maybe s/fences/fence/ to make it more obvious that you can only attach
one?

> +  * _plane_helper.prepare_fb callback. See drm_gem_fb_prepare_fb()
> +  * and drm_gem_fb_simple_display_pipe_prepare_fb() for suitable helpers.
>*/
>   struct dma_fence *fence;

Regardless,

Reviewed-by: Eric Anholt 


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

Re: [PATCH 5/9] drm/mxsfb: Use simple_display_pipe prepare_fb helper

[Eric Anholt]

Daniel Vetter  writes:

> Signed-off-by: Daniel Vetter 
> Cc: Marek Vasut 

4,5 are:

Reviewed-by: Eric Anholt 

It would be great to land this series up to here soon, as I was
surprised to see another new simple_display_pipe prepare implementation
in a driver I reviewed this week.


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

[Bug 105680] [CI] igt@kms_frontbuffer_tracking@* - fail - FBC disabled: mode too large for compression

[bugzilla-daemon]

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

Jose Roberto de Souza  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |jose.so...@intel.com
   |.org|

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

Re: [v2] drm/sun4i: add lvds mode_valid function

[Maxime Ripard]

On Fri, Apr 20, 2018 at 03:10:26PM +0200, Ondřej Jirman wrote:
> Hello,
> 
> On Thu, Apr 19, 2018 at 04:02:08PM +0200, Giulio Benetti wrote:
> > Hi everybody,
> > 
> > Il 19/04/2018 15:36, Chen-Yu Tsai ha scritto:
> > > On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman
> > >  wrote:
> > > > Hello Giulio,
> > > > 
> > > > this patch breaks LVDS output on A83T. Without it, modesetting works,
> > > > with it there's no output.
> > > > 
> > > > Some more info below...
> > > > 
> > > > On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote:
> > > > > mode_valid function is missing for lvds.
> > > > > 
> > > > > Add it making it pointed by encoder helper functions.
> > > > > 
> > > > > Signed-off-by: Giulio Benetti 
> > > > > ---
> > > > >   drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 
> > > > > ++
> > > > >   1 file changed, 55 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
> > > > > b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> > > > > index be3f14d..b4c 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> > > > > @@ -94,9 +94,64 @@ static void sun4i_lvds_encoder_disable(struct 
> > > > > drm_encoder *encoder)
> > > > >}
> > > > >   }
> > > > > 
> > > > > +static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct 
> > > > > drm_encoder *crtc,
> > > > > +   const struct 
> > > > > drm_display_mode *mode)
> > > > > +{
> > > > > + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc);
> > > > > + struct sun4i_tcon *tcon = lvds->tcon;
> > > > > + u32 hsync = mode->hsync_end - mode->hsync_start;
> > > > > + u32 vsync = mode->vsync_end - mode->vsync_start;
> > > > > + unsigned long rate = mode->clock * 1000;
> > > > > + long rounded_rate;
> > > > > +
> > > > > + DRM_DEBUG_DRIVER("Validating modes...\n");
> > > > > +
> > > > > + if (hsync < 1)
> > > > > + return MODE_HSYNC_NARROW;
> > > > > +
> > > > > + if (hsync > 0x3ff)
> > > > > + return MODE_HSYNC_WIDE;
> > > > > +
> > > > > + if ((mode->hdisplay < 1) || (mode->htotal < 1))
> > > > > + return MODE_H_ILLEGAL;
> > > > > +
> > > > > + if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
> > > > > + return MODE_BAD_HVALUE;
> > > > > +
> > > > > + DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
> > > > > +
> > > > > + if (vsync < 1)
> > > > > + return MODE_VSYNC_NARROW;
> > > > > +
> > > > > + if (vsync > 0x3ff)
> > > > > + return MODE_VSYNC_WIDE;
> > > > > +
> > > > > + if ((mode->vdisplay < 1) || (mode->vtotal < 1))
> > > > > + return MODE_V_ILLEGAL;
> > > > > +
> > > > > + if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
> > > > > + return MODE_BAD_VVALUE;
> > > > > +
> > > > > + DRM_DEBUG_DRIVER("Vertical parameters OK\n");
> > > > > +
> > > > > + tcon->dclk_min_div = 7;
> > > > > + tcon->dclk_max_div = 7;
> > > > 
> > > > Why would validation function change any state anywhere?
> > > > 
> > > > > + rounded_rate = clk_round_rate(tcon->dclk, rate);
> > > > 
> > > > The issue is here, on A83T TBS A711 tablet, I get...
> > > > 
> > > > sun4i-tcon 1c0c000.lcd-controller: XXX: hsync=20 hdisplay=1024 
> > > > htotal=1384
> > > >vsync=5 vdisplay=600 vtotal=640 rate=5200 rounded_rate=51857142
> > > > 
> > > > > + if (rounded_rate < rate)
> > > > > + return MODE_CLOCK_LOW;
> > > > > +
> > > > > + if (rounded_rate > rate)
> > > > > + return MODE_CLOCK_HIGH;
> > > > 
> > > > ... while the previous conditions require an exact match for some 
> > > > reason.
> > > > 
> > > > But HW works fine without an exact rate match. Why is exact match 
> > > > required here?
> > > 
> > > This thread might provide some more info, though we could never get an
> > > agreement.
> > > 
> > > https://patchwork.kernel.org/patch/9446385/
> > 
> > Thanks for pointing that Thread ChenYu.
> > So the only chance is to trim frequency according to encoder capabilities.
> > I agree to block when encoder can't provide frequency specified,
> > otherwise you could drive you panel at the near the lowest(highest)
> > frequency and get out of limits for a few without knowing it.
> 
> When I set the range of pixel clock frequencies on simple-panel connected
> to this encoder, the check still fails, so there's something not working
> there as expected. This check is only called once with a typical frequency.
> 
> I guess drm doesn't implement clock-frequency range on panels. But I haven't
> looked.

It does, but only omapdss is able to use it iirc. We could do it too,
but that would be way out of scope for a fix.

> I can set the exact frequency that the SoC can provide on the simple-panel,
> but that's a bit of a hack.

Yes. And 

Re: RFC for a render API to support adaptive sync and VRR

[Manasi Navare]

On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard  wrote:
> > Michel Dänzer  writes:
> >> Time-based presentation seems to be the right approach for preventing
> >> micro-stutter in games as well, Croteam developers have been researching
> >> this.
> >
> > Both the Vulkan GOOGLE_display_timing extension and X11 Present
> > extension offer the ability to specify the desired display time in
> > seconds.
> >
> > Similarly, I'd suggest that the min/max display refresh rate values be
> > advertised as time between frames rather than frames per second.

So there is a global min and max refresh rate as advertised by the monitor
range descriptor. That I guess can be exposed as a global range in terms of
min and max time between frames as a global property of the connector.

We dont need the per mode min and max refresh rate to be exposed right?

> >
> > I'd also encourage using a single unit for all of these values,
> > preferably nanoseconds. Absolute times should all be referenced to
> > CLOCK_MONOTONIC.
> 
> +1 on everything Keith said. I got somehow dragged in khr vk
> discussions around preventing micro-stuttering, and consensus seems to
> be that timestamps for scheduling frames is the way to go, most likely
> absolute ones (not everything is running Linux unfortunately, so can't
> go outright and claim it's guaranteed to be CLOCK_MONOTONIC).
> -Daniel

And yes I also got consensus from Mesa and media folks about using the
absolute timestamp for scheduling the frames and then the driver will
modify the vblank logic to "present no earlier than the timestamp"

Manasi

> -- 
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [[RFC]DPU PATCH 3/4] drm/panel: add Innolux TV123WAM eDP panel driver

[Sean Paul]

On Thu, Apr 19, 2018 at 11:26:07PM +0530, Sandeep Panda wrote:
> Add support for Innolux TV123WAM 12.3" panel which
> is an eDP panel.

It seems like you could just use the panel-simple driver, no? Given that this
driver doesn't have any power timing, that will probably work better since the
warranty won't be voided :)

Sean

> 
> Signed-off-by: Sandeep Panda 
> ---
>  drivers/gpu/drm/panel/panel-innolux-tv123wam.c | 293 
> +
>  1 file changed, 293 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-innolux-tv123wam.c
> 
> diff --git a/drivers/gpu/drm/panel/panel-innolux-tv123wam.c 
> b/drivers/gpu/drm/panel/panel-innolux-tv123wam.c
> new file mode 100644
> index 000..5632b02
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-innolux-tv123wam.c
> @@ -0,0 +1,293 @@
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct innolux_edp_2k_panel_desc {
> + const struct drm_display_mode *modes;
> + unsigned int num_modes;
> + u32 bpc;
> + u32 bus_flags;
> +};
> +
> +struct innolux_edp_2k_panel {
> + struct drm_panel base;
> + bool enabled;
> + bool prepared;
> + const struct innolux_edp_2k_panel_desc *desc;
> + struct regulator *supply;
> + struct gpio_desc *enable_gpio;
> + struct backlight_device *backlight;
> +};
> +
> +static const struct drm_display_mode innolux_edp_2k_mode = {
> + .clock = 206016,
> + .hdisplay = 2160,
> + .hsync_start = 2160 + 48,
> + .hsync_end = 2160 + 48 + 32,
> + .htotal = 2160 + 48 + 32 + 80,
> + .vdisplay = 1440,
> + .vsync_start = 1440 + 3,
> + .vsync_end = 1440 + 3 + 10,
> + .vtotal = 1440 + 3 + 10 + 27,
> + .vrefresh = 60,
> + .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> +};
> +
> +static const struct innolux_edp_2k_panel_desc innolux_edp_2k = {
> + .modes = _edp_2k_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
> +};
> +
> +static const struct of_device_id platform_of_match[] = {
> + {
> + .compatible = "innolux, edp_2k_panel",
> + .data = _edp_2k,
> + },
> +};
> +
> +static inline struct innolux_edp_2k_panel *
> +to_innolux_edp_2k_panel(struct drm_panel *panel)
> +{
> + return container_of(panel, struct innolux_edp_2k_panel, base);
> +}
> +
> +static int innolux_edp_2k_panel_disable(struct drm_panel *panel)
> +{
> + struct innolux_edp_2k_panel *pdata = to_innolux_edp_2k_panel(panel);
> +
> + if (!pdata->enabled)
> + return 0;
> +
> + if (pdata->backlight) {
> + pdata->backlight->props.power = FB_BLANK_POWERDOWN;
> + pdata->backlight->props.state |= BL_CORE_FBBLANK;
> + backlight_update_status(pdata->backlight);
> + }
> +
> + pdata->enabled = false;
> +
> + return 0;
> +}
> +
> +static int innolux_edp_2k_panel_unprepare(struct drm_panel *panel)
> +{
> + struct innolux_edp_2k_panel *pdata = to_innolux_edp_2k_panel(panel);
> +
> + if (!pdata->prepared)
> + return 0;
> +
> + if (pdata->enable_gpio)
> + gpiod_set_value_cansleep(pdata->enable_gpio, 0);
> +
> + regulator_disable(pdata->supply);
> +
> + pdata->prepared = false;
> +
> + return 0;
> +}
> +
> +static int innolux_edp_2k_panel_prepare(struct drm_panel *panel)
> +{
> + struct innolux_edp_2k_panel *pdata = to_innolux_edp_2k_panel(panel);
> + int ret;
> +
> + if (pdata->prepared)
> + return 0;
> +
> + ret = regulator_enable(pdata->supply);
> + if (ret < 0) {
> + dev_err(panel->dev, "failed to enable supply: %d\n", ret);
> + return ret;
> + }
> +
> + if (pdata->enable_gpio)
> + gpiod_set_value_cansleep(pdata->enable_gpio, 1);
> +
> + pdata->prepared = true;
> +
> + return 0;
> +}
> +
> +static int innolux_edp_2k_panel_enable(struct drm_panel *panel)
> +{
> + struct innolux_edp_2k_panel *pdata = to_innolux_edp_2k_panel(panel);
> +
> + if (pdata->enabled)
> + return 0;
> +
> + if (pdata->backlight) {
> + pdata->backlight->props.state &= ~BL_CORE_FBBLANK;
> + pdata->backlight->props.power = FB_BLANK_UNBLANK;
> + backlight_update_status(pdata->backlight);
> + }
> +
> + pdata->enabled = true;
> +
> + return 0;
> +}
> +
> +static 

Re: AMD graphics performance regression in 4.15 and later

[Felix Kuehling]

[+Philip]

On 2018-04-20 10:47 AM, Michel Dänzer wrote:
> On 2018-04-11 11:37 AM, Christian König wrote:
>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>>> 2018-04-09 11:42 GMT+02:00 Christian König
>>> :
 Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
> Hi Christian,
>
> Thanks for the info. FYI, I've also opened a Firefox bug for that at:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
> Feel free to comment since you have a better understanding of what's
> going on.
>
> One last question: right now I'm running 4.15.0 with the "offending"
> patch reverted. Is that safe to run or are there possible bad
> interactions with other changes.
 That should work without problems.

 But I just had another idea as well, if you want you could still test
 the
 new code path which will be using in 4.17.

>>> While Firefox may do some strange things is not about only Firefox.
>>>
>>> With your patches my EPYC box is unusable with  4.15++ kernels.
>>> The whole Desktop is acting weird.  This one is using
>>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU.
>>>
>>> Box is  2 * EPYC 7281 with 128 GB ECC RAM
>>>
>>> Also a 14C Xeon box with a HD7700 is broken same way.
>> The hardware is irrelevant for this. We need to know what software stack
>> you use on top of it.
>>
>> E.g. desktop environment/Mesa and DDX version etc...
>>
>>> Everything breaks in X .. scrolling , moving windows , flickering etc.
>>>
>>>
>>> reverting f4c809914a7c3e4a59cf543da6c2a15d0f75ee38 and
>>> 648bc3574716400acc06f99915815f80d9563783
>>> from an 4.15 kernel makes things work again.
>>>
>>>
 Backporting all the detection logic is to invasive, but you could
 just go
 into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the other
 code path.

 Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those.

>>> Well you really can't be serious about these suggestions ? Are you ?
>>>
>>> Telling peoples to #if 0 random code is not a solution.
>> That is for testing and not a permanent solution.
>>
>>> You broke existsing working userland with your patches and at least
>>> please fix that for 4.16.
>>>
>>> I can help testing code for 4.17/++ if you wish but that is
>>> *different* storry.
>> Please test Alex's amd-staging-drm-next branch from
>> git://people.freedesktop.org/~agd5f/linux.
> I think we're still missing something here.
>
> I'm currently running 4.16.2 + the DRM subsystem changes which are going
> into 4.17 (so I have the changes Christian is referring to) with a
> Kaveri APU, and I'm seeing similar symptoms as described by Jean-Marc.
> Some observations:
>
> Firefox, Thunderbird, or worst, gnome-shell, can freeze for up to on the
> order of a minute, during which the kernel is spending most of one
> core's cycles inside alloc_pages (__alloc_pages_nodemask to be more
> precise), called from ttm_alloc_new_pages.
Philip debugged a similar problem with a KFD memory stress test about
two weeks ago, where the kernel was seemingly stuck in an infinite loop
trying to allocate huge pages. I'm pasting his analysis for the record:

> [...] it uses huge_flags GFP_TRANSHUGE to call alloc_pages(), this
> seems a corner case inside __alloc_pages_slowpath(), it never exits
> but goes to retry path every time. It can reclaim pages and
> did_some_progress (as a result, no_progress_loops is reset to 0 every
> loop, never reach MAX_RECLAIM_RETRIES) but cannot finish huge page
> allocations under this specific memory pressure.  
As a workaround to unblock our release branch testing we removed
transparent huge page allocation from  ttm_get_pages. We're seeing this
as far back as 4.13 on our release branch.

If we're really talking about the same problem, I don't think it's
caused by recent page allocator changes, but rather exposed by recent
TTM changes.

Regards,
  Felix

>
> At least in the case of Firefox, this happens due to Mesa internal BO
> allocations for glTex(Sub)Image, so it's not obvious that Firefox is
> doing something wrong.
>
> I never noticed this before this week. Before, I was running 4.15.y +
> DRM subsystem changes from 4.16. Maybe something has changed in core
> code, trying harder to allocate huge pages.
>
>
> Maybe TTM should only try to use any huge pages that happen to be
> available, not spend any (/ "too much"?) additional effort trying to
> free up huge pages?
>
>

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

Re: [[RFC]DPU PATCH 1/4] drm/bridge: add support for sn65dsi86 bridge driver

[Sean Paul]

On Thu, Apr 19, 2018 at 11:26:05PM +0530, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
> 
> This chip can be controlled via either i2c interface or
> dsi interface. Currently in driver all the control registers
> are being accessed through i2c interface only.
> Also as of now HPD support has not been added to bridge
> chip driver.
> 
> Changes in v1:
>  - Split the dt-bindings and the driver support into separate patches
>(Andrzej Hajda).
>  - Use of gpiod APIs to parse and configure gpios instead of obsolete ones
>(Andrzej Hajda).
>  - Use macros to define the register offsets (Andrzej Hajda).
> 
> Changes in v2:
>  - Separate out edp panel specific HW resource handling from bridge
>driver and create a separate edp panel drivers to handle panel
>specific mode information and HW resources (Sean Paul).
>  - Replace pr_* APIs to DRM_* APIs to log error or debug information
>(Sean Paul).
>  - Remove some of the unnecessary structure/variable from driver (Sean
>Paul).
>  - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge"
>(Sean Paul / Rob Herring).
>  - Remove most of the hard-coding and modified the bridge init sequence
>based on current mode (Sean Paul).
>  - Remove the existing function to retrieve the EDID data and
>implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul).
>  - Remove the dummy irq handler implementation, will add back the
>proper irq handling later (Sean Paul).
>  - Capture the required enable gpios in a single array based on dt entry
>instead of having individual descriptor for each gpio (Sean Paul).
> 
> Changes in v3:
>  - Remove usage of irq_gpio and replace it as "interrupts" property (Rob
>Herring).
>  - Remove the unnecessary header file inclusions (Sean Paul).
>  - Rearrange the header files in alphabetical order (Sean Paul).
>  - Use regmap interface to perform i2c transactions.
>  - Update Copyright/License field and address other review comments
>(Jordan Crouse).
> 
> Signed-off-by: Sandeep Panda 
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 690 
> ++

What about Kconfig/Makefile?

>  1 file changed, 690 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> new file mode 100644
> index 000..a2a95f5
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -0,0 +1,690 @@
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */

Use SPDX license

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SN_BRIDGE_REVISION_ID 0x2
> +
> +/* Link Training specific registers */
> +#define SN_DEVICE_REV_REG0x08
> +#define SN_REFCLK_FREQ_REG   0x0A
> +#define SN_DSI_LANES_REG 0x10
> +#define SN_DSIA_CLK_FREQ_REG 0x12
> +#define SN_ENH_FRAME_REG 0x5A
> +#define SN_SSC_CONFIG_REG0x93
> +#define SN_DATARATE_CONFIG_REG   0x94
> +#define SN_PLL_ENABLE_REG0x0D
> +#define SN_SCRAMBLE_CONFIG_REG   0x95
> +#define SN_AUX_WDATA0_REG0x64
> +#define SN_AUX_ADDR_19_16_REG0x74
> +#define SN_AUX_ADDR_15_8_REG 0x75
> +#define SN_AUX_ADDR_7_0_REG  0x76
> +#define SN_AUX_LENGTH_REG0x77
> +#define SN_AUX_CMD_REG   0x78
> +#define SN_ML_TX_MODE_REG0x96
> +/* video config specific registers */
> +#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG0x20
> +#define SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG   0x21
> +#define SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG 0x24
> +#define SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG0x25
> +#define SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG 0x2C
> +#define SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG0x2D
> +#define SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG 0x30
> +#define SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG0x31
> +#define SN_CHA_HORIZONTAL_BACK_PORCH_REG 0x34
> +#define SN_CHA_VERTICAL_BACK_PORCH_REG   0x36
> +#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG

Re: [PATCH] drm/amdgpu: cleanup firmware requests v2

[Andres Rodriguez]

Ping.

On 2018-04-17 06:12 PM, Andres Rodriguez wrote:

Add a new function amdgpu_ucode_request_firmware() that encapsulates a
lot of the common behaviour we have around firmware requests.

This is the first step in my quest to get rid of the following annoying
messages when my polaris10 boots up:
[0.558537] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_pfp_2.bin failed with error -2
[0.558551] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_me_2.bin failed with error -2
[0.558562] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_ce_2.bin failed with error -2
[0.558580] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_mec_2.bin failed with error -2
[0.558619] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_mec2_2.bin failed with error -2

v2: make amdgpu_ucode_validate file scope only
 add kernel-doc for amdgpu_ucode_request_firmware()

Signed-off-by: Andres Rodriguez 
---

Sorry for the quick V2, noticed some docs might help and that
_validate() could be reduced in scope. Pasting my old message
again just in case.

Hey Christian,

Wanted to go through a cleanup of the ucode loading in amdgpu
to facilitate some of our heated discussions :)

For now, functionality should remain the same. Once _nowarn()
lands we can change amdgpu_ucode_request_firmware() with either:

Alternative A:
-   err = request_firmware(_fw, name, adev->dev);
+   err = request_firmware_nowarn(_fw, name, adev->dev);

Alternative B:
-   err = request_firmware(_fw, name, adev->dev);
+   if (optional)
+   err = request_firmware_nowarn(_fw, name, adev->dev);
+   else
+   err = request_firmware(_fw, name, adev->dev);

I prefer A, but I'm not opposed to B. I'll leave it up to you.

Regards,
Andres

  drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  14 +---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  16 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c  |  74 ---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h  |   4 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  16 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  16 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  16 +
  drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  15 +---
  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   5 +-
  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  19 ++---
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  30 ++--
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 112 +
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  39 +++---
  drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  |  17 +
  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  14 +---
  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  14 +---
  drivers/gpu/drm/amd/amdgpu/psp_v10_0.c |  18 +
  drivers/gpu/drm/amd/amdgpu/psp_v3_1.c  |  15 +---
  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   6 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   6 +-
  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |   7 +-
  drivers/gpu/drm/amd/amdgpu/si_dpm.c|  16 +
  22 files changed, 164 insertions(+), 325 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index a8a942c60ea2..347ab1710523 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -402,19 +402,9 @@ static int amdgpu_cgs_get_firmware_info(struct cgs_device 
*cgs_device,
return -EINVAL;
}
  
-			err = request_firmware(>pm.fw, fw_name, adev->dev);

-   if (err) {
-   DRM_ERROR("Failed to request firmware\n");
+   err = amdgpu_ucode_request_firmware(adev, >pm.fw, 
fw_name, false);
+   if (err)
return err;
-   }
-
-   err = amdgpu_ucode_validate(adev->pm.fw);
-   if (err) {
-   DRM_ERROR("Failed to load firmware \"%s\"", 
fw_name);
-   release_firmware(adev->pm.fw);
-   adev->pm.fw = NULL;
-   return err;
-   }
  
  			if (adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) {

ucode = 
>firmware.ucode[AMDGPU_UCODE_ID_SMC];
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index abc33464959e..967e14f14abc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1355,20 +1355,10 @@ static int amdgpu_device_parse_gpu_info_fw(struct 
amdgpu_device *adev)
}
  
  	snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_gpu_info.bin", chip_name);

-   err = request_firmware(>firmware.gpu_info_fw, fw_name, adev->dev);
-   if (err) {
-

[PATCH] drm/bridge: vga-dac: Fix edid memory leak

[Sean Paul]

edid should be freed once it's finished being used.

Fixes: 56fe8b6f4991 ("drm/bridge: Add RGB to VGA bridge support")
Cc: Rob Herring 
Cc: Sean Paul 
Cc: Maxime Ripard 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc:  # v4.9+
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/bridge/dumb-vga-dac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index 498d5948d1a8..9837c8d69e69 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -56,7 +56,9 @@ static int dumb_vga_get_modes(struct drm_connector *connector)
}
 
drm_mode_connector_update_edid_property(connector, edid);
-   return drm_add_edid_modes(connector, edid);
+   ret = drm_add_edid_modes(connector, edid);
+   kfree(edid);
+   return ret;
 
 fallback:
/*
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

--- Comment #3 from Joel Sass  ---
Created attachment 138959
  --> https://bugs.freedesktop.org/attachment.cgi?id=138959=edit
lshw output

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

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

--- Comment #2 from Joel Sass  ---
Created attachment 138958
  --> https://bugs.freedesktop.org/attachment.cgi?id=138958=edit
dmesg output

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

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

--- Comment #1 from Joel Sass  ---
Created attachment 138957
  --> https://bugs.freedesktop.org/attachment.cgi?id=138957=edit
Xorg.0.log

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

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

Bug ID: 106159
   Summary: When connecting or disconnecting a displayport to a DP
hub with 4.16.2+ kernel, hard freeze with frozen video
output
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sass.j...@gmail.com

Created attachment 138956
  --> https://bugs.freedesktop.org/attachment.cgi?id=138956=edit
dpkg -l |grep mesa

When connecting a displayport monitor to an active DP hub with working outputs,
my workstation experiences a hard freeze requiring a cold reboot. Network
services stop responding, including ping and SSH.

root@nope:~# uname -a
Linux nope 4.16.2+ #1 SMP Fri Apr 13 17:51:14 CEST 2018 x86_64 x86_64 x86_64
GNU/Linux

root@nope:~# lsmod |grep -i amdgpu
amdgpu   2695168  2
chash  16384  1 amdgpu
i2c_algo_bit   16384  1 amdgpu
gpu_sched  20480  1 amdgpu
ttm94208  1 amdgpu
drm_kms_helper143360  1 amdgpu
drm   348160  6 amdgpu,gpu_sched,ttm,drm_kms_helper

Mesa drivers from padoka PPA

-- 
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: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Srivatsa, Anusha]

>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, April 20, 2018 11:04 AM
>To: Jani Nikula 
>Cc: Srivatsa, Anusha ; Ian W MORRISON
>; airl...@linux.ie; Greg KH
>; intel-...@lists.freedesktop.org; linux-
>ker...@vger.kernel.org; sta...@vger.kernel.org; dri-
>de...@lists.freedesktop.org; Wajdeczko, Michal 
>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for
>Geminilake
>
>On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote:
>> On Mon, 16 Apr 2018, "Srivatsa, Anusha"  wrote:
>> >>-Original Message-
>> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >>Sent: Wednesday, April 11, 2018 5:27 AM
>> >>To: Ian W MORRISON 
>> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha
>> >>; Wajdeczko, Michal
>> >>; Greg KH ;
>> >>airl...@linux.ie; joonas.lahti...@linux.intel.com;
>> >>linux-ker...@vger.kernel.org; sta...@vger.kernel.org;
>> >>intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org
>> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE
>> >>for Geminilake
>> >>
>> >>On Wed, 11 Apr 2018, Ian W MORRISON  wrote:
>> >>> 
>> >>>
>> 
>>  NAK on indiscriminate Cc: stable. There are zero guarantees that
>>  older kernels will work with whatever firmware you throw at them.
>> 
>> >>>
>> >>> I included 'Cc: stable' so the patch would get added to the v4.16
>> >>> and
>> >>> v4.15 kernels which I have tested with the patch. I found that
>> >>> earlier kernels didn't support the 'linux-firmware' package
>> >>> required to get wifi working on Intel's new Gemini Lake NUC.
>> >>
>> >>You realize that this patch should have nothing to do with wifi?
>> >>
>> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please
>> >>indicate the specific versions of stable it is appropriate for.
>> >
>> > Hi Jani,
>> >
>> > The stable kernel version is 4.12 and beyond.
>> > It is appropriate to add the CC: stable in my opinion
>>
>> Who tested the firmware with v4.12 and later? We only have the CI
>> results against *current* drm-tip. We don't even know about v4.16.
>>
>
>I understand your concerns, but the problem was that our old process was a bit
>(lot?) messed and there was the unreliable time until the firmware really 
>lands on
>linux-firmware.git. So MODULE_FIRMWARE call was only added after firmware
>was really there on firmware repository but it wasn't about the testing.
>
>In other words, the bump version patch was merged after tested, but
>MODULE_FIRMWARE was left behind because firmware blob took a while to get
>pulled into linux-firmware.git and we end up forgetting to add it there.
>
>In my opinion it should be safe to add the MODULE_FIRMWARE there based on
>the tests from when the version was bumped.

Luis, Elio, can you guys confirm that this firmware is tested and healthy? And 
also, give a tested-by to this patch please?

Thanks,
Anusha 
>> I'm not going to ack and take responsibility for the stable backports
>> unless someone actually comes forward with credible Tested-bys.
>>
>> BR,
>> Jani.
>>
>>
>> >
>> > Anusha
>> >>BR,
>> >>Jani.
>> >>
>> >>>
>> 
>>  PS. How is this a "RESEND"? I haven't seen this before.
>> 
>> >>>
>> >>> It is a 'RESEND' for that very reason. I initially sent the patch
>> >>> to the same people as a similar patch
>> >>> (https://patchwork.kernel.org/patch/10143637/) however after
>> >>> realising this omitted required addresses I added them and resent the
>patch.
>> >>>
>> >>> Best regards,
>> >>> Ian
>> >>
>> >>--
>> >>Jani Nikula, Intel Open Source Technology Center
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

--- Comment #20 from bernhardu  ---
Got already commited in master branch:
https://cgit.freedesktop.org/mesa/mesa/commit/src/mesa/state_tracker/st_draw.c?id=f7542175178e724510c7918edfe09ba33c7a

But not yet in 17.3 or 18.0 branch.

-- 
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 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

bernhardu  changed:

   What|Removed |Added

 CC||bernha...@mailbox.org

--- Comment #19 from bernhardu  ---
*** Bug 106153 has been marked as a duplicate of this bug. ***

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

[Bug 106153] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

bernhardu  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from bernhardu  ---


*** This bug has been marked as a duplicate of bug 103234 ***

-- 
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 106153] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

--- Comment #2 from bernhardu  ---
Being able to reproduce it I built a set of mesa packages
with the patch from #103234.

By adding a fprintf before the return I can confirm that
this patch avoids the crash.

-- 
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: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Rodrigo Vivi]

On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote:
> On Mon, 16 Apr 2018, "Srivatsa, Anusha"  wrote:
> >>-Original Message-
> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> >>Sent: Wednesday, April 11, 2018 5:27 AM
> >>To: Ian W MORRISON 
> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha
> >>; Wajdeczko, Michal
> >>; Greg KH ;
> >>airl...@linux.ie; joonas.lahti...@linux.intel.com; 
> >>linux-ker...@vger.kernel.org;
> >>sta...@vger.kernel.org; intel-...@lists.freedesktop.org; dri-
> >>de...@lists.freedesktop.org
> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for
> >>Geminilake
> >>
> >>On Wed, 11 Apr 2018, Ian W MORRISON  wrote:
> >>> 
> >>>
> 
>  NAK on indiscriminate Cc: stable. There are zero guarantees that
>  older kernels will work with whatever firmware you throw at them.
> 
> >>>
> >>> I included 'Cc: stable' so the patch would get added to the v4.16 and
> >>> v4.15 kernels which I have tested with the patch. I found that earlier
> >>> kernels didn't support the 'linux-firmware' package required to get
> >>> wifi working on Intel's new Gemini Lake NUC.
> >>
> >>You realize that this patch should have nothing to do with wifi?
> >>
> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please indicate 
> >>the specific
> >>versions of stable it is appropriate for.
> >
> > Hi Jani,
> >
> > The stable kernel version is 4.12 and beyond.
> > It is appropriate to add the CC: stable in my opinion
> 
> Who tested the firmware with v4.12 and later? We only have the CI
> results against *current* drm-tip. We don't even know about v4.16.
> 

I understand your concerns, but the problem was that our old process
was a bit (lot?) messed and there was the unreliable time
until the firmware really lands on linux-firmware.git. So MODULE_FIRMWARE
call was only added after firmware was really there on firmware repository
but it wasn't about the testing.

In other words, the bump version patch was merged after tested, but
MODULE_FIRMWARE was left behind because firmware blob took a while to get
pulled into linux-firmware.git and we end up forgetting to add it there.

In my opinion it should be safe to add the MODULE_FIRMWARE there
based on the tests from when the version was bumped.

> I'm not going to ack and take responsibility for the stable backports
> unless someone actually comes forward with credible Tested-bys.
> 
> BR,
> Jani.
> 
> 
> >
> > Anusha
> >>BR,
> >>Jani.
> >>
> >>>
> 
>  PS. How is this a "RESEND"? I haven't seen this before.
> 
> >>>
> >>> It is a 'RESEND' for that very reason. I initially sent the patch to
> >>> the same people as a similar patch
> >>> (https://patchwork.kernel.org/patch/10143637/) however after realising
> >>> this omitted required addresses I added them and resent the patch.
> >>>
> >>> Best regards,
> >>> Ian
> >>
> >>--
> >>Jani Nikula, Intel Open Source Technology Center
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] drm/vmwgfx: Drop DRM_CONTROL_ALLOW

[Thomas Hellstrom]

On 04/20/2018 08:51 AM, Daniel Vetter wrote:

Control nodes are no more!

Signed-off-by: Daniel Vetter 
Cc: VMware Graphics 
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 70e1a8820a7c..97f37c3c16f2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -159,14 +159,14 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
  DRM_RENDER_ALLOW),
VMW_IOCTL_DEF(VMW_CURSOR_BYPASS,
  vmw_kms_cursor_bypass_ioctl,
- DRM_MASTER | DRM_CONTROL_ALLOW),
+ DRM_MASTER),
  
  	VMW_IOCTL_DEF(VMW_CONTROL_STREAM, vmw_overlay_ioctl,

- DRM_MASTER | DRM_CONTROL_ALLOW),
+ DRM_MASTER),
VMW_IOCTL_DEF(VMW_CLAIM_STREAM, vmw_stream_claim_ioctl,
- DRM_MASTER | DRM_CONTROL_ALLOW),
+ DRM_MASTER),
VMW_IOCTL_DEF(VMW_UNREF_STREAM, vmw_stream_unref_ioctl,
- DRM_MASTER | DRM_CONTROL_ALLOW),
+ DRM_MASTER),
  
  	VMW_IOCTL_DEF(VMW_CREATE_CONTEXT, vmw_context_define_ioctl,

  DRM_AUTH | DRM_RENDER_ALLOW),


Reviewed-by: Thomas Hellstrom 

I can queue this on the next -fixes pull.

/Thomas

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

[Bug 106153] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

--- Comment #1 from bernhardu  ---
A little addition:
Looks like I can reliably reproduce by just pressing alt+tab and holding it for
some seconds, while on the left the window previews are iterating through.

And it looks like the 3.5 core file is not coming from kind of a memory limit,
because in htop a such crashed process shows:
VIRT: 4452M
RES:   216M
SHR:   118M
And gcore produces a 3.8 GB file of it.

-- 
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/etnaviv: remove register logging

[Lucas Stach]

I'm not aware of any case where tracing GPU register manipulation at the
kernel level would have been useful. It only adds more indirections and
adds to the code size.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/Kconfig   |  8 --
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 51 ---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  5 
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c |  4 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  4 +--
 5 files changed, 5 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
index e5bfeca361bd..041a77e400d4 100644
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -22,11 +22,3 @@ config DRM_ETNAVIV_THERMAL
help
  Compile in support for thermal throttling.
  Say Y unless you want to risk burning your SoC.
-
-config DRM_ETNAVIV_REGISTER_LOGGING
-   bool "enable ETNAVIV register logging"
-   depends on DRM_ETNAVIV
-   help
- Compile in support for logging register reads/writes in a format
- that can be parsed by envytools demsm tool.  If enabled, register
- logging can be switched on via etnaviv.reglog=y module param.
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index ab50090d066c..0aa543d75953 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -25,57 +25,6 @@
 #include "etnaviv_mmu.h"
 #include "etnaviv_perfmon.h"
 
-#ifdef CONFIG_DRM_ETNAVIV_REGISTER_LOGGING
-static bool reglog;
-MODULE_PARM_DESC(reglog, "Enable register read/write logging");
-module_param(reglog, bool, 0600);
-#else
-#define reglog 0
-#endif
-
-void __iomem *etnaviv_ioremap(struct platform_device *pdev, const char *name,
-   const char *dbgname)
-{
-   struct resource *res;
-   void __iomem *ptr;
-
-   if (name)
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
-   else
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
-   ptr = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(ptr)) {
-   dev_err(>dev, "failed to ioremap %s: %ld\n", name,
-   PTR_ERR(ptr));
-   return ptr;
-   }
-
-   if (reglog)
-   dev_printk(KERN_DEBUG, >dev, "IO:region %s 0x%p %08zx\n",
-  dbgname, ptr, (size_t)resource_size(res));
-
-   return ptr;
-}
-
-void etnaviv_writel(u32 data, void __iomem *addr)
-{
-   if (reglog)
-   printk(KERN_DEBUG "IO:W %p %08x\n", addr, data);
-
-   writel(data, addr);
-}
-
-u32 etnaviv_readl(const void __iomem *addr)
-{
-   u32 val = readl(addr);
-
-   if (reglog)
-   printk(KERN_DEBUG "IO:R %p %08x\n", addr, val);
-
-   return val;
-}
-
 /*
  * DRM operations:
  */
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index ddb17ee565e9..56be51c13c49 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -101,11 +101,6 @@ void etnaviv_gem_describe_objects(struct 
etnaviv_drm_private *priv,
struct seq_file *m);
 #endif
 
-void __iomem *etnaviv_ioremap(struct platform_device *pdev, const char *name,
-   const char *dbgname);
-void etnaviv_writel(u32 data, void __iomem *addr);
-u32 etnaviv_readl(const void __iomem *addr);
-
 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
 #define VERB(fmt, ...) if (0) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 8a88799bf79b..08c587547f19 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1735,6 +1735,7 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
 {
struct device *dev = >dev;
struct etnaviv_gpu *gpu;
+   struct resource *res;
int err;
 
gpu = devm_kzalloc(dev, sizeof(*gpu), GFP_KERNEL);
@@ -1746,7 +1747,8 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
mutex_init(>fence_idr_lock);
 
/* Map registers: */
-   gpu->mmio = etnaviv_ioremap(pdev, NULL, dev_name(gpu->dev));
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   gpu->mmio = devm_ioremap_resource(>dev, res);
if (IS_ERR(gpu->mmio))
return PTR_ERR(gpu->mmio);
 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 3c3005501846..6052093d00b2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -161,12 +161,12 @@ struct etnaviv_gpu {
 
 static inline void gpu_write(struct etnaviv_gpu *gpu, u32 reg, u32 data)
 {
-   etnaviv_writel(data, gpu->mmio + reg);
+   writel(data, gpu->mmio + reg);
 }
 
 static inline u32 

[PATCH 1/2] drm/etnaviv: switch MMU page tables to writecombine memory

[Lucas Stach]

We are likely to write multiple page entries at once and already ensure
proper write buffer flushing before GPU submit, so this improves CPU
time usage in the submit path without any downsides.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c| 27 +--
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 74 +++---
 2 files changed, 51 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
index 4b9b11ca6f03..65121b93c78f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
@@ -47,7 +47,7 @@ static int __etnaviv_iommu_init(struct etnaviv_iommuv1_domain 
*etnaviv_domain)
u32 *p;
int i;
 
-   etnaviv_domain->base.bad_page_cpu = dma_alloc_coherent(
+   etnaviv_domain->base.bad_page_cpu = dma_alloc_writecombine(
etnaviv_domain->base.dev,
SZ_4K,

_domain->base.bad_page_dma,
@@ -60,13 +60,14 @@ static int __etnaviv_iommu_init(struct 
etnaviv_iommuv1_domain *etnaviv_domain)
*p++ = 0xdead55aa;
 
etnaviv_domain->pgtable_cpu =
-   dma_alloc_coherent(etnaviv_domain->base.dev, PT_SIZE,
-  _domain->pgtable_dma,
-  GFP_KERNEL);
+   dma_alloc_writecombine(etnaviv_domain->base.dev,
+  PT_SIZE,
+  _domain->pgtable_dma,
+  GFP_KERNEL);
if (!etnaviv_domain->pgtable_cpu) {
-   dma_free_coherent(etnaviv_domain->base.dev, SZ_4K,
- etnaviv_domain->base.bad_page_cpu,
- etnaviv_domain->base.bad_page_dma);
+   dma_free_writecombine(etnaviv_domain->base.dev, SZ_4K,
+ etnaviv_domain->base.bad_page_cpu,
+ etnaviv_domain->base.bad_page_dma);
return -ENOMEM;
}
 
@@ -81,13 +82,13 @@ static void etnaviv_iommuv1_domain_free(struct 
etnaviv_iommu_domain *domain)
struct etnaviv_iommuv1_domain *etnaviv_domain =
to_etnaviv_domain(domain);
 
-   dma_free_coherent(etnaviv_domain->base.dev, PT_SIZE,
- etnaviv_domain->pgtable_cpu,
- etnaviv_domain->pgtable_dma);
+   dma_free_writecombine(etnaviv_domain->base.dev, PT_SIZE,
+ etnaviv_domain->pgtable_cpu,
+ etnaviv_domain->pgtable_dma);
 
-   dma_free_coherent(etnaviv_domain->base.dev, SZ_4K,
- etnaviv_domain->base.bad_page_cpu,
- etnaviv_domain->base.bad_page_dma);
+   dma_free_writecombine(etnaviv_domain->base.dev, SZ_4K,
+ etnaviv_domain->base.bad_page_cpu,
+ etnaviv_domain->base.bad_page_dma);
 
kfree(etnaviv_domain);
 }
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
index 9752dbd5d28b..540962f24d0f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
@@ -104,7 +104,7 @@ static int etnaviv_iommuv2_init(struct 
etnaviv_iommuv2_domain *etnaviv_domain)
int ret, i, j;
 
/* allocate scratch page */
-   etnaviv_domain->base.bad_page_cpu = dma_alloc_coherent(
+   etnaviv_domain->base.bad_page_cpu = dma_alloc_writecombine(
etnaviv_domain->base.dev,
SZ_4K,

_domain->base.bad_page_dma,
@@ -117,19 +117,19 @@ static int etnaviv_iommuv2_init(struct 
etnaviv_iommuv2_domain *etnaviv_domain)
for (i = 0; i < SZ_4K / 4; i++)
*p++ = 0xdead55aa;
 
-   etnaviv_domain->pta_cpu = dma_alloc_coherent(etnaviv_domain->base.dev,
-SZ_4K,
-_domain->pta_dma,
-GFP_KERNEL);
+   etnaviv_domain->pta_cpu =
+   dma_alloc_writecombine(etnaviv_domain->base.dev,
+  SZ_4K, _domain->pta_dma,
+  GFP_KERNEL);
if (!etnaviv_domain->pta_cpu) {
ret = -ENOMEM;
goto fail_mem;
}
 
-   etnaviv_domain->mtlb_cpu = dma_alloc_coherent(etnaviv_domain->base.dev,
- SZ_4K,
- 

[PATCH 2/2] drm/etnaviv: mmuv2: allocate 2nd level page tables on demand

[Lucas Stach]

With etnaviv not being tied into the IOMMU framework anymore, the MMU
functions will only be called under sleeping locks. Thus we are able
to allocate the memory for the 2nd level page tables on demand without
having to deal with memory allocation in atomic context.

This speeds up driver intitialization on MMUv2 GPU cores, as we don't
need to preallocate all the page table memory and also reduces memory
consumption for most workloads, as most of them won't use the full
GPU virtual address space.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 59 +++---
 1 file changed, 30 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
index 540962f24d0f..c0d7e5244102 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
@@ -49,6 +49,7 @@ struct etnaviv_iommuv2_domain {
/* S(lave) TLB aka second level pagetable */
u32 *stlb_cpu[1024];
dma_addr_t stlb_dma[1024];
+   DECLARE_BITMAP(stlb_allocated, 1024);
 };
 
 static struct etnaviv_iommuv2_domain *
@@ -57,13 +58,35 @@ to_etnaviv_domain(struct etnaviv_iommu_domain *domain)
return container_of(domain, struct etnaviv_iommuv2_domain, base);
 }
 
+static int
+etnaviv_iommuv2_ensure_stlb(struct etnaviv_iommuv2_domain *etnaviv_domain,
+   int stlb)
+{
+   if (test_bit(stlb, etnaviv_domain->stlb_allocated))
+   return 0;
+
+   etnaviv_domain->stlb_cpu[stlb] =
+   dma_alloc_writecombine(etnaviv_domain->base.dev,
+  SZ_4K,
+  _domain->stlb_dma[stlb],
+  GFP_KERNEL);
+
+   if (!etnaviv_domain->stlb_cpu[stlb])
+   return -ENOMEM;
+
+   __set_bit(stlb, etnaviv_domain->stlb_allocated);
+   etnaviv_domain->mtlb_cpu[stlb] = etnaviv_domain->stlb_dma[stlb] |
+ MMUv2_PTE_PRESENT;
+   return 0;
+}
+
 static int etnaviv_iommuv2_map(struct etnaviv_iommu_domain *domain,
   unsigned long iova, phys_addr_t paddr,
   size_t size, int prot)
 {
struct etnaviv_iommuv2_domain *etnaviv_domain =
to_etnaviv_domain(domain);
-   int mtlb_entry, stlb_entry;
+   int mtlb_entry, stlb_entry, ret;
u32 entry = (u32)paddr | MMUv2_PTE_PRESENT;
 
if (size != SZ_4K)
@@ -75,6 +98,10 @@ static int etnaviv_iommuv2_map(struct etnaviv_iommu_domain 
*domain,
mtlb_entry = (iova & MMUv2_MTLB_MASK) >> MMUv2_MTLB_SHIFT;
stlb_entry = (iova & MMUv2_STLB_MASK) >> MMUv2_STLB_SHIFT;
 
+   ret = etnaviv_iommuv2_ensure_stlb(etnaviv_domain, mtlb_entry);
+   if (ret)
+   return ret;
+
etnaviv_domain->stlb_cpu[mtlb_entry][stlb_entry] = entry;
 
return 0;
@@ -101,7 +128,7 @@ static size_t etnaviv_iommuv2_unmap(struct 
etnaviv_iommu_domain *domain,
 static int etnaviv_iommuv2_init(struct etnaviv_iommuv2_domain *etnaviv_domain)
 {
u32 *p;
-   int ret, i, j;
+   int ret, i;
 
/* allocate scratch page */
etnaviv_domain->base.bad_page_cpu = dma_alloc_writecombine(
@@ -135,25 +162,6 @@ static int etnaviv_iommuv2_init(struct 
etnaviv_iommuv2_domain *etnaviv_domain)
goto fail_mem;
}
 
-   /* pre-populate STLB pages (may want to switch to on-demand later) */
-   for (i = 0; i < MMUv2_MAX_STLB_ENTRIES; i++) {
-   etnaviv_domain->stlb_cpu[i] =
-   dma_alloc_writecombine(etnaviv_domain->base.dev,
-  SZ_4K,
-  
_domain->stlb_dma[i],
-  GFP_KERNEL);
-   if (!etnaviv_domain->stlb_cpu[i]) {
-   ret = -ENOMEM;
-   goto fail_mem;
-   }
-   p = etnaviv_domain->stlb_cpu[i];
-   for (j = 0; j < SZ_4K / 4; j++)
-   *p++ = MMUv2_PTE_EXCEPTION;
-
-   etnaviv_domain->mtlb_cpu[i] = etnaviv_domain->stlb_dma[i] |
- MMUv2_PTE_PRESENT;
-   }
-
return 0;
 
 fail_mem:
@@ -172,13 +180,6 @@ static int etnaviv_iommuv2_init(struct 
etnaviv_iommuv2_domain *etnaviv_domain)
  etnaviv_domain->mtlb_cpu,
  etnaviv_domain->mtlb_dma);
 
-   for (i = 0; i < MMUv2_MAX_STLB_ENTRIES; i++) {
-   if (etnaviv_domain->stlb_cpu[i])
-   dma_free_writecombine(etnaviv_domain->base.dev, SZ_4K,
- etnaviv_domain->stlb_cpu[i],
- 

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

--- Comment #20 from Alex Deucher (alexdeuc...@gmail.com) ---
The revert is cc'ed to stable so it will show up in the 4.16 stable tree as
well.

-- 
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 v3 5/7] drm/i2c: tda9950: add CEC driver

[Hans Verkuil]

On 04/20/2018 05:31 PM, Russell King - ARM Linux wrote:
> Hi Hans,
> 
> Any comments?

I have been traveling and haven't had time to look at this. Next week will
be busy as well, but I expect to be able to look at it the week after that.

I remember from the previous series that I couldn't test it with my BeagleBone
Black board (the calibration gpio had to switch from in to out but it wasn't 
allowed
since it had an associated irq). That's still a problem?

I didn't see any changes in that area when I did a quick scan.

Regards,

Hans

> 
> Thanks.
> 
> On Mon, Apr 09, 2018 at 01:16:32PM +0100, Russell King wrote:
>> Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device,
>> but is also integrated into HDMI transceivers such as the TDA9989 and
>> TDA19989.
>>
>> The TDA9950 contains a command processor which handles retransmissions
>> and the low level bus protocol.  The driver just has to read and write
>> the messages, and handle error conditions.
>>
>> Signed-off-by: Russell King 
>> ---
>>  drivers/gpu/drm/i2c/Kconfig   |   5 +
>>  drivers/gpu/drm/i2c/Makefile  |   1 +
>>  drivers/gpu/drm/i2c/tda9950.c | 509 
>> ++
>>  include/linux/platform_data/tda9950.h |  16 ++
>>  4 files changed, 531 insertions(+)
>>  create mode 100644 drivers/gpu/drm/i2c/tda9950.c
>>  create mode 100644 include/linux/platform_data/tda9950.h
>>
>> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
>> index a6c92beb410a..3a232f5ff0a1 100644
>> --- a/drivers/gpu/drm/i2c/Kconfig
>> +++ b/drivers/gpu/drm/i2c/Kconfig
>> @@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X
>>  help
>>Support for NXP Semiconductors TDA998X HDMI encoders.
>>  
>> +config DRM_I2C_NXP_TDA9950
>> +tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
>> +select CEC_NOTIFIER
>> +select CEC_CORE
>> +
>>  endmenu
>> diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
>> index b20100c18ffb..a962f6f08568 100644
>> --- a/drivers/gpu/drm/i2c/Makefile
>> +++ b/drivers/gpu/drm/i2c/Makefile
>> @@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
>>  
>>  tda998x-y := tda998x_drv.o
>>  obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
>> +obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
>> diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
>> new file mode 100644
>> index ..3f7396caad48
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i2c/tda9950.c
>> @@ -0,0 +1,509 @@
>> +/*
>> + *  TDA9950 Consumer Electronics Control driver
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * The NXP TDA9950 implements the HDMI Consumer Electronics Control
>> + * interface.  The host interface is similar to a mailbox: the data
>> + * registers starting at REG_CDR0 are written to send a command to the
>> + * internal CPU, and replies are read from these registers.
>> + *
>> + * As the data registers represent a mailbox, they must be accessed
>> + * as a single I2C transaction.  See the TDA9950 data sheet for details.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +enum {
>> +REG_CSR = 0x00,
>> +CSR_BUSY = BIT(7),
>> +CSR_INT  = BIT(6),
>> +CSR_ERR  = BIT(5),
>> +
>> +REG_CER = 0x01,
>> +
>> +REG_CVR = 0x02,
>> +
>> +REG_CCR = 0x03,
>> +CCR_RESET = BIT(7),
>> +CCR_ON= BIT(6),
>> +
>> +REG_ACKH = 0x04,
>> +REG_ACKL = 0x05,
>> +
>> +REG_CCONR = 0x06,
>> +CCONR_ENABLE_ERROR = BIT(4),
>> +CCONR_RETRY_MASK = 7,
>> +
>> +REG_CDR0 = 0x07,
>> +
>> +CDR1_REQ = 0x00,
>> +CDR1_CNF = 0x01,
>> +CDR1_IND = 0x81,
>> +CDR1_ERR = 0x82,
>> +CDR1_IER = 0x83,
>> +
>> +CDR2_CNF_SUCCESS= 0x00,
>> +CDR2_CNF_OFF_STATE  = 0x80,
>> +CDR2_CNF_BAD_REQ= 0x81,
>> +CDR2_CNF_CEC_ACCESS = 0x82,
>> +CDR2_CNF_ARB_ERROR  = 0x83,
>> +CDR2_CNF_BAD_TIMING = 0x84,
>> +CDR2_CNF_NACK_ADDR  = 0x85,
>> +CDR2_CNF_NACK_DATA  = 0x86,
>> +};
>> +
>> +struct tda9950_priv {
>> +struct i2c_client *client;
>> +struct device *hdmi;
>> +struct cec_adapter *adap;
>> +struct tda9950_glue *glue;
>> +u16 addresses;
>> +struct cec_msg rx_msg;
>> +struct cec_notifier *notify;
>> +bool open;
>> +};
>> +
>> +static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, 
>> int cnt)
>> +{
>> +struct i2c_msg msg;
>> +u8 buf[cnt + 1];
>> +int ret;
>> +
>> +buf[0] = addr;
>> +memcpy(buf + 1, p, cnt);
>> +
>> +msg.addr = client->addr;
>> +msg.flags = 0;
>> +msg.len = cnt + 1;
>> +msg.buf = buf;
>> +
>> +dev_dbg(>dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
>> +
>> +ret = 

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #39 from MirceaKitsune  ---
Created attachment 138951
  --> https://bugs.freedesktop.org/attachment.cgi?id=138951=edit
journalctl --since yesterday

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #37 from MirceaKitsune  ---
I have just finished preforming the first new test.

First of all I must say I'm utterly amazed at the variability of this issue:
Last week when I played Xonotic with "r_shadows 2", the freeze occurred in just
a few seconds or minutes at most... today after a few openSUSE Tumbleweed
snapshots, I was able to play for over 60 minutes even with this option
enabled! It's clear that package updates are causing the lockup to vary
unpredictably.

In any case, I can confirm the SysRq keys also stop functioning after the
freeze: I tried REISUB for a few minutes, but there was no form of response.

I also kept both NumLock and CapsLock enabled during the game to better see how
they behave in a crash. 5 seconds after the freeze, they both turned off...
that is the very last noticeable activity of the system.

None the less I will attach the logs you suggested below, just in case they
still captured something. Please let me know exactly what you believe I should
try next, in as much detail as possible since I'm unfamiliar with the other
tests you hinted to in our last conversation (eg: apitrace).

-- 
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: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Fri, Apr 20, 2018 at 05:46:25AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > > num_resources) which does the handling common to all drivers.
> > > A structure that contains
> > > 
> > > {page,offset,len} + {dma_addr+dma_len}
> > > 
> > > is not a good container for storing
> > > 
> > > {virt addr, dma_addr, len}
> > > 
> > > no matter what interface you build arond it.
> > 
> > Why not? I mean at least for my use case we actually don't need the virtual
> > address.
> 
> If you don't need the virtual address you need scatterlist even list.
> 
> > What we need is {dma_addr+dma_len} in a consistent interface which can come
> > from both {page,offset,len} as well as {resource, len}.
> 
> Ok.
> 
> > What I actually don't need is separate handling for system memory and
> > resources, but that would we get exactly when we don't use sg_table.
> 
> At the very lowest level they will need to be handled differently for
> many architectures, the questions is at what point we'll do the
> branching out.

Having at least struct page also in that list with (dma_addr_t, lenght)
pairs has a bunch of benefits for drivers in unifying buffer handling
code. You just pass that one single list around, use the dma_addr_t side
for gpu access (generally bashing it into gpu ptes). And the struct page
(if present) for cpu access, using kmap or vm_insert_*. We generally
ignore virt, if we do need a full mapping then we construct a vmap for
that buffer of our own.

If (and that would be serious amounts of work all over the tree, with lots
of drivers) we come up with a new struct for gpu buffers, then I'd also
add "force page alignement for everything" to the requirements list.
That's another mismatch we have, since gpu buffer objects (and dma-buf)
are always full pages. That mismatch motived the addition of the
page-oriented sg iterators.

So maybe a list of (struct page *, dma_addr_t, num_pages) would suit best,
with struct page * being optional (if it's a resource, or something else
that the kernel core mm isn't aware of). But that only has benefits if we
really roll it out everywhere, in all the subsystems and drivers, since if
we don't we've made the struct pages ** <-> sgt conversion fun only worse
by adding a 3 representation of gpu buffer object backing storage.
-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 v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST

[Bartlomiej Zolnierkiewicz]

On Thursday, April 05, 2018 04:29:42 PM Mauro Carvalho Chehab wrote:
> This driver builds cleanly with COMPILE_TEST, and it is
> needed in order to allow building drivers/media omap2
> driver.
> 
> So, change the logic there to allow building it.
> 
> Signed-off-by: Mauro Carvalho Chehab 

This change has broken build on OF=n && COMPILE_TEST=y configs:

https://patchwork.kernel.org/patch/10352465/

[ This is not a problem when compiling for OMAP2 because it depends
  on ARM Multiplatform support which (indirectly) selects OF. ]

Also I would really prefer that people won't merge fbdev related
patches without my ACK and I see this patch in -next coming from
one of your trees..

> ---
>  drivers/video/fbdev/omap2/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/omap2/Kconfig 
> b/drivers/video/fbdev/omap2/Kconfig
> index 0921c4de8407..82008699d253 100644
> --- a/drivers/video/fbdev/omap2/Kconfig
> +++ b/drivers/video/fbdev/omap2/Kconfig
> @@ -1,4 +1,4 @@
> -if ARCH_OMAP2PLUS
> +if ARCH_OMAP2PLUS || COMPILE_TEST
>  
>  source "drivers/video/fbdev/omap2/omapfb/Kconfig"

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [Intel-gfx] [PATCH v5 1/2] drm: content-type property for HDMI connector

[Daniel Vetter]

On Fri, Apr 20, 2018 at 08:31:56AM +, Lisovskiy, Stanislav wrote:
> 
> 
> From: Daniel Vetter [daniel.vet...@ffwll.ch] on behalf of Daniel Vetter 
> [dan...@ffwll.ch]
> 
> > The property documentation to tie all the bits together (property, helper,
> > internals) is missing. It should be in
> 
> > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
> 
> > Probably want to start with an intro-paragraph for HDMI properties
> > (someone should document the broadcast prop too eventually).
> 
> > Pls also make sure the resulting docs look pretty and that it's all
> > nicely hyperlink:
> 
> >$ make htmldocs
> 
> Thank you for your feedback. The thing is that I actually looked into docs,
> but I think there should have been already some HDMI specific property 
> documentation,
> because this one is actually not a standard connector property, so I've added 
> it only to
> 
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#existing-kms-properties 
> table

This table is seriously deprecated, because it's unreadable and
unmaintainable. Quoting from the docs:

"Because this table is very unwieldy, do not add any new properties here.
Instead document them in a section above."

We haven't yet moved all the existing properties over to the new layout
(patches very much welcome, especially if you spot that an entire area
you're touching like HDMI properties isn't moved yet). But the old table
is very much not cool to add stuff to.

Sorry that I didn't notice this earlier, missed it in the diffstat.

> as optional.
> I think it might be a bit misleading, if I add that one to standard connector 
> properties,
> there are probably should be created some HDMI specific property chapter 
> then, as there
> are already plenty of HDMI specific ones(force audio, broadcast rgb, aspect 
> ratio).
> 
> Shouldn't it then go in a separate patch may be? Because this work is surely 
> needed, however
> goes a bit out of scope of this patch.

Don't make it worse by adding more unmaintainable and unreadable entries
to this table. That's the minimum. Moving all the standard hdmi properties
first would obviously be even better. That also makes reviewing easier,
since it's clearer what's there already, and how your new thing fits in.
-Daniel

> 
> Best Regards,
> 
> Lisovskiy Stanislav
> 
> > ---
> >  Documentation/gpu/kms-properties.csv |  1 +
> >  drivers/gpu/drm/drm_atomic.c | 17 ++
> >  drivers/gpu/drm/drm_connector.c  | 51 
> >  drivers/gpu/drm/drm_edid.c   |  2 ++
> >  include/drm/drm_connector.h  | 18 ++
> >  include/drm/drm_mode_config.h|  5 +++
> >  include/uapi/drm/drm_mode.h  |  7 
> >  7 files changed, 101 insertions(+)
> >
> > diff --git a/Documentation/gpu/kms-properties.csv 
> > b/Documentation/gpu/kms-properties.csv
> > index 6b28b014cb7d..a91c9211b8d6 100644
> > --- a/Documentation/gpu/kms-properties.csv
> > +++ b/Documentation/gpu/kms-properties.csv
> > @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
> > Values,Object attached,De
> >  ,Virtual GPU,“suggested X”,RANGE,"Min=0, 
> > Max=0x",Connector,property to suggest an X offset for a connector
> >  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to 
> > suggest an Y offset for a connector
> >  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
> > }",Connector,TDB
> > +,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"", 
> > ""Cinema"", ""Game"" }",Connector,TBD
> >  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", 
> > ""Limited 16:235"" }",Connector,"When this property is set to Limited 
> > 16:235 and CTM is set, the hardware will be programmed with the result of 
> > the multiplication of CTM by the limited range matrix to ensure the pixels 
> > normaly in the range 0..1.0 are remapped to the range 16/255..235/255."
> >  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
> >  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
> > etc.",Connector,TBD
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 7d25c42f22db..479499f5848e 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct 
> > drm_connector *connector,
> >   state->link_status = val;
> >   } else if (property == config->aspect_ratio_property) {
> >   state->picture_aspect_ratio = val;
> > + } else if (property == config->content_type_property) {
> > + /*
> > +  * Lowest two bits of content_type property control
> > +  * content_type, bit 2 controls itc bit.
> > +  * It was decided to have a single property called
> > +  * content_type, instead of 

[Bug 106153] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

Bug ID: 106153
   Summary: KWin crashed when Alt+Tab-ing through open windows
   Product: Mesa
   Version: 17.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bernha...@mailbox.org
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 138954
  --> https://bugs.freedesktop.org/attachment.cgi?id=138954=edit
More infos of KCrash/gdb and glxinfo.

This might be a duplicate of #102423 or #103234.
(But did not want to pollute these if they were unrelated.)

...
#4  0x7f78f8a4c793 in KCrash::defaultCrashHandler (sig=11) at ./src/kcra...
#5   ...
#6  si_emit_draw_packets (sctx=sctx@entry=0x5600dec29f30, info=info@entry=0x...
#7  0x7f78c278d2b0 in si_draw_vbo (ctx=0x5600dec29f30, info=0x5600dec6b1...
#8  0x7f78c24efd03 in tc_call_draw_vbo (pipe=, payload=0x...
#9  0x7f78c24eddff in tc_batch_execute (thread_index=0, job=0x5600dec6a8...
...
(gdb) up
#6  si_emit_draw_packets (sctx=sctx@entry=0x5600dec29f30, info=info@entry=0x...
713 index_max_size = (indexbuf->width0 - index_offset) /

At this point it looks like variable indexbuf is NULL.

"bt full" would suggest this too:
#7  0x7f78c278d2b0 in si_draw_vbo (ctx=0x5600dec29f30, info=0x5600dec6b1...
...
indexbuf = 0x0

So I cannot reproduce this and was hit just once.
But it could be related to the not so long Qt 5.10 update in Debian testing.
I took a core dump if there are more questions.
All debug symbols are available as far as I see.

Related could also be that the core file is of a size of 3.5 GB so that
might have led to the NULL pointer.
Attached is a file containing the more infos of KCrash/gdb and glxinfo.

-- 
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: [PATCHv3 3/8] drm/omap: add support for manually updated displays

[Daniel Stone]

Hi Tony!

On 20 April 2018 at 15:25, Tony Lindgren  wrote:
> * Daniel Stone  [180420 10:21]:
>> On 20 April 2018 at 08:09, Tomi Valkeinen  wrote:
>> > It's actually not quite clear to me how manual update displays work with
>> > DRM...
>> >
>> > As far as I see, we have essentially two cases: 1) single buffering,
>> > where the userspace must set an area in the fb dirty, which then
>> > triggers the update, 2) multi buffering, which doesn't need fb dirty,
>> > but just a page flip which triggers the update.
>> >
>> > In the 2) case (which I think is the optimal case which all the modern
>> > apps should use), there's no need for delayed work or any work, and the
>> > code flow should be very similar to the auto-update model.
>>
>> Correct. There's been talk (and I think patches?) of adding a
>> per-plane dirty property, so userspace can as an optimisation inform
>> the kernel of the area changed between frames. But short of that, a
>> pageflip needs to trigger a full-plane update, with no dirtyfb
>> required.
>
> For per-plane dirty property patches, which ones do you refer to?

Here's the latest iteration of that series:
https://lists.freedesktop.org/archives/dri-devel/2018-April/171900.html
<1522885748-67122-1-git-send-email-dra...@vmware.com>

> Then for xorg, there's my second attempt on fixing the command mode
> rotation at [0]. Not sure if that's enough for a fix?
>
> It seems not very efficient to me and I don't really know where
> the the per crtc dirty flag should be stored..

I try to deny all knowledge of X11 these days, I'm afraid.

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

Re: [PATCH v11 09/11] drm: Expose modes with aspect ratio, only if requested

[Ville Syrjälä]

On Fri, Apr 20, 2018 at 07:01:49PM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal 
> 
> We parse the EDID and add all the modes in the connector's modelist.
> This adds CEA modes with aspect ratio information too, regardless of
> whether user space requested this information or not.
> 
> This patch prunes the modes with aspect-ratio information, from a
> connector's modelist, if the user-space has not set the aspect ratio
> DRM client cap. However if such a mode is unique in the list, it is
> kept in the list, with aspect-ratio flags reset.
> 
> Cc: Ville Syrjala 
> Cc: Shashank Sharma 
> Cc: Jose Abreu 
> 
> Signed-off-by: Ankit Nautiyal 
> 
> V3: As suggested by Ville, modified the mechanism of pruning of modes
> with aspect-ratio, if the aspect-ratio is not supported. Instead
> of straight away pruning such a mode, the mode is retained with
> aspect ratio bits set to zero, provided it is unique.
> V4: rebase
> V5: Addressed review comments from Ville:
> -used a pointer to store last valid mode.
> -avoided, modifying of picture_aspect_ratio in kernel mode,
>  instead only flags bits of user mode are reset (if aspect-ratio
>  is not supported).
> V6: As suggested by Ville, corrected the mode pruning logic and
> elaborated the mode pruning logic and the assumptions taken.
> V7: rebase
> V8: rebase
> V9: rebase
> V10: rebase
> V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
>  logic to correctly identify and prune modes with aspect-ratio,
>  if aspect-ratio cap is not set.
> ---
>  drivers/gpu/drm/drm_connector.c | 56 
> +++--
>  1 file changed, 48 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b3cde89..865ee354 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1531,15 +1531,35 @@ static struct drm_encoder 
> *drm_connector_get_encoder(struct drm_connector *conne
>   return connector->encoder;
>  }
>  
> -static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
> -  const struct drm_file *file_priv)
> +static bool
> +drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
> +  const struct drm_display_mode *modelist,
> +  const struct drm_file *file_priv)
>  {
>   /*
>* If user-space hasn't configured the driver to expose the stereo 3D
>* modes, don't expose them.
>*/
> + struct drm_display_mode *mode_itr;
> +
>   if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
>   return false;
> + /*
> +  * If user-space hasn't configured the driver to expose the modes
> +  * with aspect-ratio, don't expose them. However if such a mode
> +  * is unique, let it be exposed, but reset the aspect-ratio flags
> +  * while preparing the list of user-modes.
> +  */
> + if (!file_priv->aspect_ratio_allowed &&
> + mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) {
> + list_for_each_entry(mode_itr, >head, head)
> + if (drm_mode_match(mode_itr, mode,
> +DRM_MODE_MATCH_TIMINGS |
> +DRM_MODE_MATCH_CLOCK |
> +DRM_MODE_MATCH_FLAGS |
> +DRM_MODE_MATCH_3D_FLAGS))
> + return false;
> + }
>  
>   return true;
>  }
> @@ -1550,7 +1570,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
> *data,
>   struct drm_mode_get_connector *out_resp = data;
>   struct drm_connector *connector;
>   struct drm_encoder *encoder;
> - struct drm_display_mode *mode;
> + struct drm_display_mode *mode, *tmp, modelist;
>   int mode_count = 0;
>   int encoders_count = 0;
>   int ret = 0;
> @@ -1605,23 +1625,37 @@ int drm_mode_getconnector(struct drm_device *dev, 
> void *data,
>   out_resp->subpixel = connector->display_info.subpixel_order;
>   out_resp->connection = connector->status;
>  
> + INIT_LIST_HEAD();

Why are we using a struct drm_display_mode to get a simple list_head?

> +
>   /* delayed so we get modes regardless of pre-fill_modes state */
>   list_for_each_entry(mode, >modes, head)
> - if (drm_mode_expose_to_userspace(mode, file_priv))
> + if (drm_mode_expose_to_userspace(mode, ,
> +  file_priv)) {
> + struct drm_display_mode *tmp_mode;
> +
> + tmp_mode = drm_mode_duplicate(dev, mode);

Duplicating every mode seems rather wasteful. I suppose we could
just add another list_head to struct 

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #38 from MirceaKitsune  ---
Created attachment 138950
  --> https://bugs.freedesktop.org/attachment.cgi?id=138950=edit
cat /var/log/messages

-- 
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 v11 06/11] drm: Add DRM client cap for aspect-ratio

[Ville Syrjälä]

On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal 
> 
> To enable aspect-ratio support in DRM, blindly exposing the aspect
> ratio information along with mode, can break things in existing
> user-spaces which have no intention or support to use this aspect
> ratio information.
> 
> To avoid this, a new drm client cap is required to enable a
> user-space to advertise if it supports modes with aspect-ratio. Based
> on this cap value, the kernel will take a call on exposing the aspect
> ratio info in modes or not.
> 
> This patch adds the client cap for aspect-ratio.
> 
> Cc: Ville Syrjala 
> Cc: Shashank Sharma 
> Signed-off-by: Ankit Nautiyal 
> 
> V3: rebase
> V4: As suggested by Marteen Lankhorst modified the commit message
> explaining the need to use the DRM cap for aspect-ratio. Also,
> tweaked the comment lines in the code for better understanding and
> clarity, as recommended by Shashank Sharma.
> V5: rebase
> V6: rebase
> V7: rebase
> V8: rebase
> V9: rebase
> V10: added comment explaining that no userspace breaks on aspect-ratio
>  mode bits.
> 
> Reviewed-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_ioctl.c | 9 +
>  include/drm/drm_file.h  | 8 
>  include/uapi/drm/drm.h  | 7 +++
>  3 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index af78291..39c8eab 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -325,6 +325,15 @@ drm_setclientcap(struct drm_device *dev, void *data, 
> struct drm_file *file_priv)
>   file_priv->atomic = req->value;
>   file_priv->universal_planes = req->value;
>   break;
> + case DRM_CLIENT_CAP_ASPECT_RATIO:
> + if (req->value > 1)
> + return -EINVAL;
> + /*
> +  * No Atomic userspace blows up on aspect ratio mode bits. Checked in
> +  * wayland/weston, xserver, and hardware-composer modeset paths.
> +  */

Bogus indentation.

Also where's the aspect_ratio_allowed handling for the atomic cap?
Or did we decide against it after all?

> + file_priv->aspect_ratio_allowed = req->value;
> + break;
>   default:
>   return -EINVAL;
>   }
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 5176c37..02b7dde 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -182,6 +182,14 @@ struct drm_file {
>   unsigned atomic:1;
>  
>   /**
> +  * @aspect_ratio_allowed:
> +  *
> +  * True, if client can handle picture aspect ratios, and has requested
> +  * to pass this information along with the mode.
> +  */
> + unsigned aspect_ratio_allowed:1;
> +
> + /**
>* @is_master:
>*
>* This client is the creator of @master. Protected by struct
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 6fdff59..9c660e1 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -680,6 +680,13 @@ struct drm_get_cap {
>   */
>  #define DRM_CLIENT_CAP_ATOMIC3
>  
> +/**
> + * DRM_CLIENT_CAP_ASPECT_RATIO
> + *
> + * If set to 1, the DRM core will provide aspect ratio information in modes.
> + */
> +#define DRM_CLIENT_CAP_ASPECT_RATIO4
> +
>  /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
>  struct drm_set_client_cap {
>   __u64 capability;
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: AMD graphics performance regression in 4.15 and later

[Michel Dänzer]

On 2018-04-11 11:37 AM, Christian König wrote:
> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>> 2018-04-09 11:42 GMT+02:00 Christian König
>> :
>>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
 Hi Christian,

 Thanks for the info. FYI, I've also opened a Firefox bug for that at:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
 Feel free to comment since you have a better understanding of what's
 going on.

 One last question: right now I'm running 4.15.0 with the "offending"
 patch reverted. Is that safe to run or are there possible bad
 interactions with other changes.
>>>
>>> That should work without problems.
>>>
>>> But I just had another idea as well, if you want you could still test
>>> the
>>> new code path which will be using in 4.17.
>>>
>> While Firefox may do some strange things is not about only Firefox.
>>
>> With your patches my EPYC box is unusable with  4.15++ kernels.
>> The whole Desktop is acting weird.  This one is using
>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU.
>>
>> Box is  2 * EPYC 7281 with 128 GB ECC RAM
>>
>> Also a 14C Xeon box with a HD7700 is broken same way.
> 
> The hardware is irrelevant for this. We need to know what software stack
> you use on top of it.
> 
> E.g. desktop environment/Mesa and DDX version etc...
> 
>>
>> Everything breaks in X .. scrolling , moving windows , flickering etc.
>>
>>
>> reverting f4c809914a7c3e4a59cf543da6c2a15d0f75ee38 and
>> 648bc3574716400acc06f99915815f80d9563783
>> from an 4.15 kernel makes things work again.
>>
>>
>>> Backporting all the detection logic is to invasive, but you could
>>> just go
>>> into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the other
>>> code path.
>>>
>>> Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those.
>>>
>> Well you really can't be serious about these suggestions ? Are you ?
>>
>> Telling peoples to #if 0 random code is not a solution.
> 
> That is for testing and not a permanent solution.
> 
>> You broke existsing working userland with your patches and at least
>> please fix that for 4.16.
>>
>> I can help testing code for 4.17/++ if you wish but that is
>> *different* storry.
> 
> Please test Alex's amd-staging-drm-next branch from
> git://people.freedesktop.org/~agd5f/linux.

I think we're still missing something here.

I'm currently running 4.16.2 + the DRM subsystem changes which are going
into 4.17 (so I have the changes Christian is referring to) with a
Kaveri APU, and I'm seeing similar symptoms as described by Jean-Marc.
Some observations:

Firefox, Thunderbird, or worst, gnome-shell, can freeze for up to on the
order of a minute, during which the kernel is spending most of one
core's cycles inside alloc_pages (__alloc_pages_nodemask to be more
precise), called from ttm_alloc_new_pages.

At least in the case of Firefox, this happens due to Mesa internal BO
allocations for glTex(Sub)Image, so it's not obvious that Firefox is
doing something wrong.

I never noticed this before this week. Before, I was running 4.15.y +
DRM subsystem changes from 4.16. Maybe something has changed in core
code, trying harder to allocate huge pages.


Maybe TTM should only try to use any huge pages that happen to be
available, not spend any (/ "too much"?) additional effort trying to
free up huge pages?


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

Re: [PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits

[Ville Syrjälä]

On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal 
> 
> This patch adds helper functions for determining if aspect-ratio is
> expected in user-mode and for allowing/disallowing the aspect-ratio,
> if its not expected.
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/drm_modes.c | 47 
> +
>  include/drm/drm_modes.h |  4 
>  2 files changed, 51 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index c395a24..d6133e8 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1759,3 +1759,50 @@ bool drm_mode_is_420(const struct drm_display_info 
> *display,
>   drm_mode_is_420_also(display, mode);
>  }
>  EXPORT_SYMBOL(drm_mode_is_420);
> +
> +/**
> + * drm_mode_aspect_ratio_allowed - checks if the aspect-ratio information
> + * is expected from the user-mode.
> + *
> + * If the user has set aspect-ratio cap, then the flag of the user-mode is
> + * allowed to contain aspect-ratio value.
> + * If the user does not set aspect-ratio cap, then the only value allowed in 
> the
> + * flags bits is aspect-ratio NONE.
> + *
> + * @file_priv: file private structure to get the user capabilities
> + * @umode: drm_mode_modeinfo struct, whose flag carry the aspect ratio
> + * information.
> + *
> + * Returns:
> + * true if the aspect-ratio info is allowed in the user-mode flags.
> + * false, otherwise.
> + */
> +bool
> +drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
> +   struct drm_mode_modeinfo *umode)
> +{
> + return file_priv->aspect_ratio_allowed || (umode->flags &
> + DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE;

Odd line split here. Makes this a bit hard to read.
I would split after the ||

> +}
> +EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed);

Do we actually need to export these? I don't think so.

But I might be wrong. It's a bit hard to see with the way
you split this patch with the actual users in a different patch.

> +
> +/**
> + * drm_mode_filter_aspect_ratio_flags - filters the aspect-ratio bits in the
> + * user-mode flags.
> + *
> + * Checks if the aspect-ratio information is allowed. Resets the aspect-ratio
> + * bits in the user-mode flags, if aspect-ratio info is not allowed.
> + *
> + * @file_priv: file private structure to get the user capabilities.
> + * @umode: drm_mode_modeinfo struct, whose flags' aspect-ratio bits needs to
> + * be filtered.
> + *
> + */
> +void
> +drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv,
> +struct drm_mode_modeinfo *umode)
> +{
> + if (!drm_mode_aspect_ratio_allowed(file_priv, umode))
> + umode->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +}
> +EXPORT_SYMBOL(drm_mode_filter_aspect_ratio_flags);
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 2f78b7e..e0b060d 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -461,6 +461,10 @@ bool drm_mode_is_420_also(const struct drm_display_info 
> *display,
> const struct drm_display_mode *mode);
>  bool drm_mode_is_420(const struct drm_display_info *display,
>const struct drm_display_mode *mode);
> +bool drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
> +struct drm_mode_modeinfo *umode);
> +void drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv,
> + struct drm_mode_modeinfo *umode);
>  
>  struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
> int hdisplay, int vdisplay, int vrefresh,
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

[Andrzej Hajda]

Hi Enric,


On 05.04.2018 11:49, Enric Balletbo i Serra wrote:
> From: "Kristian H. Kristensen" 
>
> To improve PSR exit latency, we speculatively start exiting when we
> receive input events. Occasionally, this may lead to false positives,
> but most of the time we get a head start on coming out of PSR. Depending
> on how userspace takes to produce a new frame in response to the event,
> this can completely hide the exit latency. In case of Chrome OS, we
> typically get the input notifier 50ms or more before the dirty_fb
> triggered exit.

This patch is quite controversial and require more attention/discussion
and probably changes.
The rest of the patches is OK, and all have r-b/t-b tags.
If you prefer I can merge all other patches, if you rebase patches 25-30
on top of patch 23, or I can only merge patches 01-23.
What do you prefer?

Regards
Andrzej

>
> Signed-off-by: Kristian H. Kristensen 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 
> ---
>
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 134 
> 
>  1 file changed, 134 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> index 9376f4396b6b..a107845ba97c 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> @@ -12,6 +12,8 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
> +
>  #include 
>  #include 
>  
> @@ -35,6 +37,9 @@ struct psr_drv {
>   enum psr_state  state;
>  
>   struct delayed_work flush_work;
> + struct work_struct  disable_work;
> +
> + struct input_handlerinput_handler;
>  
>   int (*set)(struct drm_encoder *encoder, bool enable);
>  };
> @@ -133,6 +138,18 @@ static void psr_flush_handler(struct work_struct *work)
>   mutex_unlock(>lock);
>  }
>  
> +static void psr_disable_handler(struct work_struct *work)
> +{
> + struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
> +
> + /* If the state has changed since we initiated the flush, do nothing */
> + mutex_lock(>lock);
> + if (psr->state == PSR_ENABLE)
> + psr_set_state_locked(psr, PSR_FLUSH);
> + mutex_unlock(>lock);
> + mod_delayed_work(system_wq, >flush_work, PSR_FLUSH_TIMEOUT_MS);
> +}
> +
>  /**
>   * rockchip_drm_psr_activate - activate PSR on the given pipe
>   * @encoder: encoder to obtain the PSR encoder
> @@ -173,6 +190,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder 
> *encoder)
>   psr->active = false;
>   mutex_unlock(>lock);
>   cancel_delayed_work_sync(>flush_work);
> + cancel_work_sync(>disable_work);
>  
>   return 0;
>  }
> @@ -226,6 +244,95 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
>  
> +static void psr_input_event(struct input_handle *handle,
> + unsigned int type, unsigned int code,
> + int value)
> +{
> + struct psr_drv *psr = handle->handler->private;
> +
> + schedule_work(>disable_work);
> +}
> +
> +static int psr_input_connect(struct input_handler *handler,
> +  struct input_dev *dev,
> +  const struct input_device_id *id)
> +{
> + struct input_handle *handle;
> + int error;
> +
> + handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
> + if (!handle)
> + return -ENOMEM;
> +
> + handle->dev = dev;
> + handle->handler = handler;
> + handle->name = "rockchip-psr";
> +
> + error = input_register_handle(handle);
> + if (error)
> + goto err2;
> +
> + error = input_open_device(handle);
> + if (error)
> + goto err1;
> +
> + return 0;
> +
> +err1:
> + input_unregister_handle(handle);
> +err2:
> + kfree(handle);
> + return error;
> +}
> +
> +static void psr_input_disconnect(struct input_handle *handle)
> +{
> + input_close_device(handle);
> + input_unregister_handle(handle);
> + kfree(handle);
> +}
> +
> +/* Same device ids as cpu-boost */
> +static const struct input_device_id psr_ids[] = {
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
> +  INPUT_DEVICE_ID_MATCH_ABSBIT,
> + .evbit = { BIT_MASK(EV_ABS) },
> + .absbit = { [BIT_WORD(ABS_MT_POSITION_X)] =
> + BIT_MASK(ABS_MT_POSITION_X) |
> + BIT_MASK(ABS_MT_POSITION_Y) },
> + }, /* multi-touch touchscreen */
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
> + .evbit = { BIT_MASK(EV_ABS) },
> + .absbit = { [BIT_WORD(ABS_X)] = BIT_MASK(ABS_X) }
> +
> + }, /* stylus or joystick device */
> 

[PATCH v11 02/11] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

[Nautiyal, Ankit K]

From: Ville Syrjälä 

Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.

This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 134069f..c35d3bc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3047,7 +3047,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks(to_match, hdmi_mode))
+   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return vic;
}
 
-- 
2.7.4

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

[PATCH v11 09/11] drm: Expose modes with aspect ratio, only if requested

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.

This patch prunes the modes with aspect-ratio information, from a
connector's modelist, if the user-space has not set the aspect ratio
DRM client cap. However if such a mode is unique in the list, it is
kept in the list, with aspect-ratio flags reset.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: Ankit Nautiyal 

V3: As suggested by Ville, modified the mechanism of pruning of modes
with aspect-ratio, if the aspect-ratio is not supported. Instead
of straight away pruning such a mode, the mode is retained with
aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
-used a pointer to store last valid mode.
-avoided, modifying of picture_aspect_ratio in kernel mode,
 instead only flags bits of user mode are reset (if aspect-ratio
 is not supported).
V6: As suggested by Ville, corrected the mode pruning logic and
elaborated the mode pruning logic and the assumptions taken.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
 logic to correctly identify and prune modes with aspect-ratio,
 if aspect-ratio cap is not set.
---
 drivers/gpu/drm/drm_connector.c | 56 +++--
 1 file changed, 48 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde89..865ee354 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1531,15 +1531,35 @@ static struct drm_encoder 
*drm_connector_get_encoder(struct drm_connector *conne
return connector->encoder;
 }
 
-static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
-const struct drm_file *file_priv)
+static bool
+drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
+const struct drm_display_mode *modelist,
+const struct drm_file *file_priv)
 {
/*
 * If user-space hasn't configured the driver to expose the stereo 3D
 * modes, don't expose them.
 */
+   struct drm_display_mode *mode_itr;
+
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes
+* with aspect-ratio, don't expose them. However if such a mode
+* is unique, let it be exposed, but reset the aspect-ratio flags
+* while preparing the list of user-modes.
+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) {
+   list_for_each_entry(mode_itr, >head, head)
+   if (drm_mode_match(mode_itr, mode,
+  DRM_MODE_MATCH_TIMINGS |
+  DRM_MODE_MATCH_CLOCK |
+  DRM_MODE_MATCH_FLAGS |
+  DRM_MODE_MATCH_3D_FLAGS))
+   return false;
+   }
 
return true;
 }
@@ -1550,7 +1570,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
struct drm_mode_get_connector *out_resp = data;
struct drm_connector *connector;
struct drm_encoder *encoder;
-   struct drm_display_mode *mode;
+   struct drm_display_mode *mode, *tmp, modelist;
int mode_count = 0;
int encoders_count = 0;
int ret = 0;
@@ -1605,23 +1625,37 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
out_resp->subpixel = connector->display_info.subpixel_order;
out_resp->connection = connector->status;
 
+   INIT_LIST_HEAD();
+
/* delayed so we get modes regardless of pre-fill_modes state */
list_for_each_entry(mode, >modes, head)
-   if (drm_mode_expose_to_userspace(mode, file_priv))
+   if (drm_mode_expose_to_userspace(mode, ,
+file_priv)) {
+   struct drm_display_mode *tmp_mode;
+
+   tmp_mode = drm_mode_duplicate(dev, mode);
+   list_add_tail(_mode->head, );
mode_count++;
+   }
 
/*
 * This ioctl is called twice, once to determine how much space is
 * needed, and the 2nd time to fill it.
+* The modes that need to be exposed to the user are maintained in the
+* 'modelist'. When the ioctl is 

[PATCH v11 04/11] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Nautiyal, Ankit K]

From: Ville Syrjälä 

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 29c88eb..d5757aa 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4840,6 +4840,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink)
 {
+   enum hdmi_picture_aspect picture_aspect;
int err;
 
if (!frame || !mode)
@@ -4882,13 +4883,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 * Populate picture aspect ratio from either
 * user input (if specified) or from the CEA mode list.
 */
-   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
-   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
-   frame->picture_aspect = mode->picture_aspect_ratio;
-   else if (frame->video_code > 0)
-   frame->picture_aspect = drm_get_cea_aspect_ratio(
-   frame->video_code);
+   picture_aspect = mode->picture_aspect_ratio;
+   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
+   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
 
+   /*
+* The infoframe can't convey anything but none, 4:3
+* and 16:9, so if the user has asked for anything else
+* we can only satisfy it by specifying the right VIC.
+*/
+   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
+   if (picture_aspect !=
+   drm_get_cea_aspect_ratio(frame->video_code))
+   return -EINVAL;
+   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   }
+
+   frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
 
-- 
2.7.4

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

[PATCH v11 05/11] video/hdmi: Reject illegal picture aspect ratios

[Nautiyal, Ankit K]

From: Ville Syrjälä 

AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Jose Abreu 
---
 drivers/video/hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 111a0ab..38716eb5 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -93,6 +93,9 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe 
*frame, void *buffer,
if (size < length)
return -ENOSPC;
 
+   if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
+   return -EINVAL;
+
memset(buffer, 0, size);
 
ptr[0] = frame->type;
-- 
2.7.4

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

Re: [PATCH] drm: udl: Destroy framebuffer only if it was initialized

[Sean Paul]

On Fri, Apr 20, 2018 at 01:50:01PM +0200, Emil Lundmark wrote:
> This fixes a NULL pointer dereference that can happen if the UDL
> driver is unloaded before the framebuffer is initialized. This can
> happen e.g. if the USB device is unplugged right after it was plugged
> in.
> 

JFYI, in future, if someone makes a suggestion on how to fix a bug, it's good
practice to add a Suggested-by tag to give credit.

Reviewed-by: Sean Paul 

> Signed-off-by: Emil Lundmark 
> ---
>  drivers/gpu/drm/udl/udl_fb.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index 2ebdc6d5a76e..5754e37f741b 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -426,9 +426,11 @@ static void udl_fbdev_destroy(struct drm_device *dev,
>  {
>   drm_fb_helper_unregister_fbi(>helper);
>   drm_fb_helper_fini(>helper);
> - drm_framebuffer_unregister_private(>ufb.base);
> - drm_framebuffer_cleanup(>ufb.base);
> - drm_gem_object_put_unlocked(>ufb.obj->base);
> + if (ufbdev->ufb.obj) {
> + drm_framebuffer_unregister_private(>ufb.base);
> + drm_framebuffer_cleanup(>ufb.base);
> + drm_gem_object_put_unlocked(>ufb.obj->base);
> + }
>  }
>  
>  int udl_fbdev_init(struct drm_device *dev)
> -- 
> 2.17.0.484.g0c8726318c-goog
> 

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

[PATCH v11 06/11] drm: Add DRM client cap for aspect-ratio

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
user-spaces which have no intention or support to use this aspect
ratio information.

To avoid this, a new drm client cap is required to enable a
user-space to advertise if it supports modes with aspect-ratio. Based
on this cap value, the kernel will take a call on exposing the aspect
ratio info in modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

V3: rebase
V4: As suggested by Marteen Lankhorst modified the commit message
explaining the need to use the DRM cap for aspect-ratio. Also,
tweaked the comment lines in the code for better understanding and
clarity, as recommended by Shashank Sharma.
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: added comment explaining that no userspace breaks on aspect-ratio
 mode bits.

Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_ioctl.c | 9 +
 include/drm/drm_file.h  | 8 
 include/uapi/drm/drm.h  | 7 +++
 3 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index af78291..39c8eab 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -325,6 +325,15 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_ASPECT_RATIO:
+   if (req->value > 1)
+   return -EINVAL;
+   /*
+* No Atomic userspace blows up on aspect ratio mode bits. Checked in
+* wayland/weston, xserver, and hardware-composer modeset paths.
+*/
+   file_priv->aspect_ratio_allowed = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 5176c37..02b7dde 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -182,6 +182,14 @@ struct drm_file {
unsigned atomic:1;
 
/**
+* @aspect_ratio_allowed:
+*
+* True, if client can handle picture aspect ratios, and has requested
+* to pass this information along with the mode.
+*/
+   unsigned aspect_ratio_allowed:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff59..9c660e1 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will provide aspect ratio information in modes.
+ */
+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.7.4

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

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #40 from Jean Delvare  ---
I believe there are 2 incarnations of this bug, with the same symptoms but
different root causes.

The first bug is affecting kernels v4.14 and v4.15, it is caused by 2 MB
allocations failing too verbosely when in fact 4 kB allocations worked just
fine as a fallback. That one is fixed in v4.16 by:

commit d0bc0c2a31c95002d37c3cc511ffdcab851b3256
Author: Christian König
Date:   Thu Jan 4 14:24:19 2018 +0100

swiotlb: suppress warning when __GFP_NOWARN is set

However kernel v4.16 also includes the following commit:

commit 0176adb004065d6815a8e67946752df4cd947c5b
Author: Christoph Hellwig
Date:   Tue Jan 9 22:15:30 2018 +0100

swiotlb: refactor coherent buffer allocation

which contains a bug producing exactly the same backtraces. That bug is caused
by an improper check of the result of dma_coherent_ok(), which was fixed 10
days ago with:

commit 9e7f06c8beee304ee21b791653fefcd713f48b9a
Author: Takashi Iwai
Date:   Tue Apr 10 19:05:13 2018 +0200

swiotlb: fix unexpected swiotlb_alloc_coherent failures

I backported this fix on top of v4.16.3 and the backtraces are gone. The commit
was tagged for stable inclusion so I expect it to be included in v4.16.

-- 
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 v11 11/11] drm: Add and handle new aspect ratios in DRM layer

[Nautiyal, Ankit K]

From: "Sharma, Shashank" 

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.

The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul  (V2)
Reviewed-by: Jose Abreu  (V2)

Cc: Ville Syrjala 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: rebase
V4: rebase
V5: corrected the macro name for an aspect ratio, in a switch case.
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 454f2ff..21cc84b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1656,6 +1656,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case HDMI_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1721,6 +1727,12 @@ int drm_mode_convert_umode(struct drm_device *dev,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 50bcf42..4b3a1bb 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -93,6 +93,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -102,6 +104,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 #define  DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
 DRM_MODE_FLAG_NHSYNC | \
-- 
2.7.4

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

[PATCH v11 01/11] drm/modes: Introduce drm_mode_match()

[Nautiyal, Ankit K]

From: Ville Syrjälä 

Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_modes.c | 134 ++--
 include/drm/drm_modes.h |   9 +++
 2 files changed, 112 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e82b61e..c395a24 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -939,17 +939,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
drm_device *dev,
 }
 EXPORT_SYMBOL(drm_mode_duplicate);
 
+static bool drm_mode_match_timings(const struct drm_display_mode *mode1,
+  const struct drm_display_mode *mode2)
+{
+   return mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan;
+}
+
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+   /*
+* do clock check convert to PICOS
+* so fb modes get matched the same
+*/
+   if (mode1->clock && mode2->clock)
+   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
+   else
+   return mode1->clock == mode2->clock;
+}
+
+static bool drm_mode_match_flags(const struct drm_display_mode *mode1,
+const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
+}
+
 /**
- * drm_mode_equal - test modes for equality
+ * drm_mode_match - test modes for (partial) equality
  * @mode1: first mode
  * @mode2: second mode
+ * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
  *
  * Check to see if @mode1 and @mode2 are equivalent.
  *
  * Returns:
- * True if the modes are equal, false otherwise.
+ * True if the modes are (partially) equal, false otherwise.
  */
-bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
drm_display_mode *mode2)
+bool drm_mode_match(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2,
+   unsigned int match_flags)
 {
if (!mode1 && !mode2)
return true;
@@ -957,15 +1008,48 @@ bool drm_mode_equal(const struct drm_display_mode 
*mode1, const struct drm_displ
if (!mode1 || !mode2)
return false;
 
-   /* do clock check convert to PICOS so fb modes get matched
-* the same */
-   if (mode1->clock && mode2->clock) {
-   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
-   return false;
-   } else if (mode1->clock != mode2->clock)
+   if (match_flags & DRM_MODE_MATCH_TIMINGS &&
+   !drm_mode_match_timings(mode1, mode2))
return false;
 
-   return drm_mode_equal_no_clocks(mode1, mode2);
+   if (match_flags & DRM_MODE_MATCH_CLOCK &&
+   !drm_mode_match_clock(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_FLAGS &&
+   !drm_mode_match_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_3D_FLAGS &&
+   !drm_mode_match_3d_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO &&
+   !drm_mode_match_aspect_ratio(mode1, mode2))
+   return false;
+
+   return true;
+}
+EXPORT_SYMBOL(drm_mode_match);
+
+/**
+ * drm_mode_equal - test modes for equality
+ * @mode1: first mode
+ * @mode2: second mode
+ *
+ * Check to see if @mode1 and @mode2 are equivalent.
+ *
+ * Returns:
+ * True if the modes are equal, false otherwise.
+ */
+bool drm_mode_equal(const struct drm_display_mode *mode1,
+   const struct drm_display_mode 

[PATCH v11 08/11] drm: Handle aspect ratio info in legacy and atomic modeset paths

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is not supported by the user.

Note: In case, a user-space asks for a video-mode blob, from the
getblob ioctl, the aspect-ratio bits in the video-mode blob are passed
to the user as it is, without any filtering. However, no such case is
present in most of the atomic user-spaces. Currently atomic path of
Xserver, Wayland/weston, Hardware-Composer are checked, and none of
them are using getblob ioctl to get the video-mode blob.

This patch:
1. passes the file_priv structure from the drm_mode_atomic_ioctl till
   the drm_mode_crtc_set_mode_prop, to get the user capability.
2. rejects the modes with aspect-ratio info, during modeset, if the
   user does not support aspect ratio.
3. does not load the aspect-ratio info in user-mode structure, if
   aspect ratio is not supported.

Signed-off-by: Ankit Nautiyal 

V3: Addressed review comments from Ville:
Do not corrupt the current crtc state by updating aspect-ratio on
the fly.
V4: rebase
V5: As suggested by Ville, rejected the modeset calls for modes with
aspect ratio, if the user does not set aspect-ratio cap.
V6: Used the helper functions for determining if aspect-ratio is
expected in the user-mode.
V7: rebase
V8: rebase
V9: rebase
v10: Modified the commit-message
---
 drivers/gpu/drm/drm_atomic.c| 34 +-
 drivers/gpu/drm/drm_atomic_helper.c |  6 +++---
 drivers/gpu/drm/drm_crtc.c  |  8 
 drivers/gpu/drm/drm_crtc_internal.h |  3 ++-
 drivers/gpu/drm/drm_mode_object.c   |  9 ++---
 include/drm/drm_atomic.h|  5 +++--
 6 files changed, 47 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3d9ae05..5acf49d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -368,6 +368,7 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
  * drm_atomic_set_mode_prop_for_crtc - set mode for CRTC
  * @state: the CRTC whose incoming state to update
  * @blob: pointer to blob property to use for mode
+ * @file_priv: file priv structure, to get the userspace capabilities
  *
  * Set a mode (originating from a blob property) on the desired CRTC state.
  * This function will take a reference on the blob property for the CRTC state,
@@ -378,7 +379,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
  * Zero on success, error code on failure. Cannot return -EDEADLK.
  */
 int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
-  struct drm_property_blob *blob)
+ struct drm_property_blob *blob,
+ struct drm_file *file_priv)
 {
if (blob == state->mode_blob)
return 0;
@@ -389,9 +391,21 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
memset(>mode, 0, sizeof(state->mode));
 
if (blob) {
-   if (blob->length != sizeof(struct drm_mode_modeinfo) ||
-   drm_mode_convert_umode(state->crtc->dev, >mode,
-  blob->data))
+   struct drm_mode_modeinfo *u_mode;
+
+   if (blob->length != sizeof(struct drm_mode_modeinfo))
+   return -EINVAL;
+
+   u_mode = (struct drm_mode_modeinfo *) blob->data;
+   if (!drm_mode_aspect_ratio_allowed(file_priv,
+  u_mode)) {
+   DRM_DEBUG_ATOMIC("Unexpected aspect-ratio flag bits\n");
+   return -EINVAL;
+   }
+
+   if (drm_mode_convert_umode(state->crtc->dev, >mode,
+  (const struct drm_mode_modeinfo *)
+  u_mode))
return -EINVAL;
 
state->mode_blob = drm_property_blob_get(blob);
@@ -471,6 +485,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
  * @state: the state object to update with the new property value
  * @property: the property to set
  * @val: the new property value
+ * @file_priv: the file private structure, to get the user capabilities
  *
  * This function handles generic/core properties and calls out to driver's
  * _crtc_funcs.atomic_set_property for driver properties. To ensure
@@ -482,7 +497,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
  */
 int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_crtc_state *state, struct drm_property *property,
-   uint64_t val)
+   uint64_t val, struct drm_file 

[PATCH v11 10/11] drm: Add aspect ratio parsing in DRM layer

[Nautiyal, Ankit K]

From: "Sharma, Shashank" 

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: modified the aspect-ratio check in drm_mode_equal as per new flags
provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
drm_fb_helper, while trying to find a common mode among connectors
for the target clone mode.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
---
 drivers/gpu/drm/drm_fb_helper.c | 12 ++--
 drivers/gpu/drm/drm_modes.c | 35 ++-
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0646b10..2ee1eaa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
for (j = 0; j < i; j++) {
if (!enabled[j])
continue;
-   if (!drm_mode_equal(modes[j], modes[i]))
+   if (!drm_mode_match(modes[j], modes[i],
+   DRM_MODE_MATCH_TIMINGS |
+   DRM_MODE_MATCH_CLOCK |
+   DRM_MODE_MATCH_FLAGS |
+   DRM_MODE_MATCH_3D_FLAGS))
can_clone = false;
}
}
@@ -2203,7 +2207,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
 
fb_helper_conn = fb_helper->connector_info[i];
list_for_each_entry(mode, _helper_conn->connector->modes, 
head) {
-   if (drm_mode_equal(mode, dmt_mode))
+   if (drm_mode_match(mode, dmt_mode,
+  DRM_MODE_MATCH_TIMINGS |
+  DRM_MODE_MATCH_CLOCK |
+  DRM_MODE_MATCH_FLAGS |
+  DRM_MODE_MATCH_3D_FLAGS))
modes[i] = mode;
}
if (!modes[i])
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d6133e8..454f2ff 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1049,7 +1049,8 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
  DRM_MODE_MATCH_TIMINGS |
  DRM_MODE_MATCH_CLOCK |
  DRM_MODE_MATCH_FLAGS |
- DRM_MODE_MATCH_3D_FLAGS);
+ DRM_MODE_MATCH_3D_FLAGS|
+ DRM_MODE_MATCH_ASPECT_RATIO);
 }
 EXPORT_SYMBOL(drm_mode_equal);
 
@@ -1647,6 +1648,20 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1693,6 +1708,24 @@ int drm_mode_convert_umode(struct drm_device *dev,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

--- Comment #19 from Kevin McCormack (wittyma...@yahoo.com) ---
Thanks for testing, Martin. This doesn't appear to be included in 4.16.3
looking at https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.16.3 and
Arch just bumped the kernel from 4.15 to 4.16.3 so I'm holding back updating. 

Are we likely to see this included in 4.16.4?

-- 
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 v11 00/11] Aspect ratio support in DRM layer

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.

The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out of which 2 patches were reverted due to lack of drm client
protection while loading the aspect information.

This patch series also includes 5 patches from Ville Syrjälä's series for
'Info-frame cleanup and fixes':
https://patchwork.freedesktop.org/series/33730/ which fixes the mode
matching mechanism via flags, and also ensures that no bogus aspect-ratios
are sent in the AVI infoframes.

This patch series, adds a DRM client option for aspect ratio, and loads
aspect ratio flags, only when the client sets this cap. 

To test this patch, the testdiplay IGT test is modified to have an option
to do a modeset with only aspect ratio modes.
Also, there is a userspace implementation in Wayland/weston layer:
https://patchwork.freedesktop.org/patch/188125/
(Which is already ACK'ed by wayland community.)

This, helps us in passing HDMI compliance test cases like 7-27, where the
test equipment applies a CEA mode, and expects the exact VIC in the AVI
infoframes.

Ankit Nautiyal (4):
  drm: Add DRM client cap for aspect-ratio
  drm: Add helper functions to handle aspect-ratio flag bits
  drm: Handle aspect ratio info in legacy and atomic modeset paths
  drm: Expose modes with aspect ratio, only if requested

Sharma, Shashank (2):
  drm: Add aspect ratio parsing in DRM layer
  drm: Add and handle new aspect ratios in DRM layer

Ville Syrjälä (5):
  drm/modes: Introduce drm_mode_match()
  drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
  drm/edid: Fix cea mode aspect ratio handling
  drm/edid: Don't send bogus aspect ratios in AVI infoframes
  video/hdmi: Reject illegal picture aspect ratios

 drivers/gpu/drm/drm_atomic.c|  34 --
 drivers/gpu/drm/drm_atomic_helper.c |   6 +-
 drivers/gpu/drm/drm_connector.c |  56 +++--
 drivers/gpu/drm/drm_crtc.c  |   8 ++
 drivers/gpu/drm/drm_crtc_internal.h |   3 +-
 drivers/gpu/drm/drm_edid.c  |  41 +--
 drivers/gpu/drm/drm_fb_helper.c |  12 +-
 drivers/gpu/drm/drm_ioctl.c |   9 ++
 drivers/gpu/drm/drm_mode_object.c   |   9 +-
 drivers/gpu/drm/drm_modes.c | 226 +++-
 drivers/video/hdmi.c|   3 +
 include/drm/drm_atomic.h|   5 +-
 include/drm/drm_file.h  |   8 ++
 include/drm/drm_modes.h |  13 +++
 include/uapi/drm/drm.h  |   7 ++
 include/uapi/drm/drm_mode.h |   6 +
 16 files changed, 377 insertions(+), 69 deletions(-)

-- 
2.7.4

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

[PATCH v11 03/11] drm/edid: Fix cea mode aspect ratio handling

[Nautiyal, Ankit K]

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c35d3bc..29c88eb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2930,11 +2930,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
 static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2948,7 +2952,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2965,11 +2969,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
  */
 u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2983,7 +2991,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3030,6 +3038,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
 static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3047,7 +3056,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
 
@@ -3064,6 +3073,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
  */
 static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3079,7 +3089,7 @@ static u8 drm_match_hdmi_mode(const struct 
drm_display_mode *to_match)
 
if 

Re: [PATCH 0/2] drm/exynos/mixer: fixes for interlaced mode

[Andrzej Hajda]

On 12.03.2018 08:12, Andrzej Hajda wrote:
> On 20.02.2018 07:45, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> On 02.02.2018 16:11, Andrzej Hajda wrote:
>>> Hi Inki, Tobias,
>>>
>>> This is reviewed/updated/tested Tobias's patch addressing page-faults
>>> in Video Processor in interlaced mode. Plus preliminary patch fixing Mixer
>>> interlaced mode.
>>>
>>> Regards
>>> Andrzej
>> Gentle ping.
> Ping.

Ping, almost three months passed.

Regards
Andrzej

>
> --
> Regards
> Andrzej
>
>> Regards
>> Andrzej
>>
>>> Andrzej Hajda (1):
>>>   drm/exynos/mixer: fix synchronization check in interlaced mode
>>>
>>> Tobias Jakobi (1):
>>>   drm/exynos: mixer: avoid Oops in vp_video_buffer()
>>>
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 22 +-
>>>  drivers/gpu/drm/exynos/regs-mixer.h   |  1 +
>>>  2 files changed, 18 insertions(+), 5 deletions(-)
>>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

[PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

This patch adds helper functions for determining if aspect-ratio is
expected in user-mode and for allowing/disallowing the aspect-ratio,
if its not expected.

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/drm_modes.c | 47 +
 include/drm/drm_modes.h |  4 
 2 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c395a24..d6133e8 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1759,3 +1759,50 @@ bool drm_mode_is_420(const struct drm_display_info 
*display,
drm_mode_is_420_also(display, mode);
 }
 EXPORT_SYMBOL(drm_mode_is_420);
+
+/**
+ * drm_mode_aspect_ratio_allowed - checks if the aspect-ratio information
+ * is expected from the user-mode.
+ *
+ * If the user has set aspect-ratio cap, then the flag of the user-mode is
+ * allowed to contain aspect-ratio value.
+ * If the user does not set aspect-ratio cap, then the only value allowed in 
the
+ * flags bits is aspect-ratio NONE.
+ *
+ * @file_priv: file private structure to get the user capabilities
+ * @umode: drm_mode_modeinfo struct, whose flag carry the aspect ratio
+ * information.
+ *
+ * Returns:
+ * true if the aspect-ratio info is allowed in the user-mode flags.
+ * false, otherwise.
+ */
+bool
+drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
+ struct drm_mode_modeinfo *umode)
+{
+   return file_priv->aspect_ratio_allowed || (umode->flags &
+   DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE;
+}
+EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed);
+
+/**
+ * drm_mode_filter_aspect_ratio_flags - filters the aspect-ratio bits in the
+ * user-mode flags.
+ *
+ * Checks if the aspect-ratio information is allowed. Resets the aspect-ratio
+ * bits in the user-mode flags, if aspect-ratio info is not allowed.
+ *
+ * @file_priv: file private structure to get the user capabilities.
+ * @umode: drm_mode_modeinfo struct, whose flags' aspect-ratio bits needs to
+ * be filtered.
+ *
+ */
+void
+drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv,
+  struct drm_mode_modeinfo *umode)
+{
+   if (!drm_mode_aspect_ratio_allowed(file_priv, umode))
+   umode->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+}
+EXPORT_SYMBOL(drm_mode_filter_aspect_ratio_flags);
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 2f78b7e..e0b060d 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -461,6 +461,10 @@ bool drm_mode_is_420_also(const struct drm_display_info 
*display,
  const struct drm_display_mode *mode);
 bool drm_mode_is_420(const struct drm_display_info *display,
 const struct drm_display_mode *mode);
+bool drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
+  struct drm_mode_modeinfo *umode);
+void drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv,
+   struct drm_mode_modeinfo *umode);
 
 struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
  int hdisplay, int vdisplay, int vrefresh,
-- 
2.7.4

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

[Bug 106073] RX480 gfx_v8_0_ring_test_ib [amdgpu]] *ERROR* amdgpu: IB test timed out.

[bugzilla-daemon]

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

Gabriel Rauter  changed:

   What|Removed |Added

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

--- Comment #1 from Gabriel Rauter  ---
Not sure what changed it, but I haven't seen the error anymore so I think this
can be closed for now.

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

[Bug 104439] intel_do_flush_locked failed: Invalid argument

[bugzilla-daemon]

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

--- Comment #11 from magiblot  ---
It has been working fine for me for quite a time with the 4.15 kernel as well.

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

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > num_resources) which does the handling common to all drivers.
> > A structure that contains
> > 
> > {page,offset,len} + {dma_addr+dma_len}
> > 
> > is not a good container for storing
> > 
> > {virt addr, dma_addr, len}
> > 
> > no matter what interface you build arond it.
> 
> Why not? I mean at least for my use case we actually don't need the virtual
> address.

If you don't need the virtual address you need scatterlist even list.

> What we need is {dma_addr+dma_len} in a consistent interface which can come
> from both {page,offset,len} as well as {resource, len}.

Ok.

> What I actually don't need is separate handling for system memory and
> resources, but that would we get exactly when we don't use sg_table.

At the very lowest level they will need to be handled differently for
many architectures, the questions is at what point we'll do the
branching out.

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

[PATCH v2] drm: Pass connector state to the bridge enable and disable handlers

[Laurent Pinchart]

To allow bridge drivers to access state data such as the active mode in
their enable and disable handlers, pass a pointer to the connector state
to those handlers. From there the CRTC state can be accessed through
conn_state->crtc->state.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sean Paul 
---
Changes since v1:

- Update the new thc63lvd1024 driver

I haven't CC'ed all the individual drivers maintainers, as doing so on
v1 seems to have exceeded the maximum number of recipients allowed by
the mailing list and prevented the mail from reaching the list.

---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  6 ++--
 drivers/gpu/drm/bridge/analogix-anx78xx.c  |  6 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16 +++
 drivers/gpu/drm/bridge/dumb-vga-dac.c  |  6 ++--
 drivers/gpu/drm/bridge/nxp-ptn3460.c   | 16 +++
 drivers/gpu/drm/bridge/panel.c | 12 +---
 drivers/gpu/drm/bridge/parade-ps8622.c | 12 +---
 drivers/gpu/drm/bridge/sii902x.c   |  6 ++--
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  6 ++--
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c  |  8 --
 drivers/gpu/drm/bridge/tc358767.c  | 12 +---
 drivers/gpu/drm/bridge/thc63lvd1024.c  |  6 ++--
 drivers/gpu/drm/drm_atomic_helper.c|  8 +++---
 drivers/gpu/drm/drm_bridge.c   | 32 ++
 drivers/gpu/drm/drm_crtc_helper.c  | 20 +++---
 drivers/gpu/drm/exynos/exynos_drm_mic.c| 16 ---
 drivers/gpu/drm/mediatek/mtk_hdmi.c| 12 +---
 drivers/gpu/drm/msm/dsi/dsi_manager.c  | 12 +---
 drivers/gpu/drm/msm/edp/edp_bridge.c   | 12 +---
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 12 +---
 drivers/gpu/drm/rcar-du/rcar_lvds.c|  6 ++--
 drivers/gpu/drm/sti/sti_dvo.c  |  9 --
 drivers/gpu/drm/sti/sti_hda.c  |  9 --
 drivers/gpu/drm/sti/sti_hdmi.c |  9 --
 include/drm/drm_bridge.h   | 25 +++--
 25 files changed, 190 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index efa29db5fc2b..7e8d4f10ad53 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -812,14 +812,16 @@ static struct adv7511 *bridge_to_adv7511(struct 
drm_bridge *bridge)
return container_of(bridge, struct adv7511, bridge);
 }
 
-static void adv7511_bridge_enable(struct drm_bridge *bridge)
+static void adv7511_bridge_enable(struct drm_bridge *bridge,
+ const struct drm_connector_state *conn_state)
 {
struct adv7511 *adv = bridge_to_adv7511(bridge);
 
adv7511_power_on(adv);
 }
 
-static void adv7511_bridge_disable(struct drm_bridge *bridge)
+static void adv7511_bridge_disable(struct drm_bridge *bridge,
+  const struct drm_connector_state *conn_state)
 {
struct adv7511 *adv = bridge_to_adv7511(bridge);
 
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index b49043866be6..73f1ed6c6d1f 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1072,7 +1072,8 @@ anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
 }
 
-static void anx78xx_bridge_disable(struct drm_bridge *bridge)
+static void anx78xx_bridge_disable(struct drm_bridge *bridge,
+  const struct drm_connector_state *conn_state)
 {
struct anx78xx *anx78xx = bridge_to_anx78xx(bridge);
 
@@ -1109,7 +1110,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge 
*bridge,
mutex_unlock(>lock);
 }
 
-static void anx78xx_bridge_enable(struct drm_bridge *bridge)
+static void anx78xx_bridge_enable(struct drm_bridge *bridge,
+ const struct drm_connector_state *conn_state)
 {
struct anx78xx *anx78xx = bridge_to_anx78xx(bridge);
int err;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5c52307146c7..217428b7e589 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1140,7 +1140,8 @@ static int analogix_dp_bridge_attach(struct drm_bridge 
*bridge)
return 0;
 }
 
-static void analogix_dp_bridge_pre_enable(struct drm_bridge *bridge)
+static void analogix_dp_bridge_pre_enable(struct drm_bridge *bridge,
+ const struct drm_connector_state 
*conn_state)
 {
struct analogix_dp_device *dp = 

[PATCH v4 2/2] drm/vc4: Add CTM registers to debugfs

[Stefan Schake]

Now that we set the OLED* registers to do CTM, it's helpful to have them
in the register dump.

Signed-off-by: Stefan Schake 
---
v4: new in the series.

 drivers/gpu/drm/vc4/vc4_hvs.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 2b62fc5b8d85..5d8c749c9749 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -58,6 +58,10 @@ static const struct {
HVS_REG(SCALER_DISPSTAT2),
HVS_REG(SCALER_DISPBASE2),
HVS_REG(SCALER_DISPALPHA2),
+   HVS_REG(SCALER_OLEDOFFS),
+   HVS_REG(SCALER_OLEDCOEF0),
+   HVS_REG(SCALER_OLEDCOEF1),
+   HVS_REG(SCALER_OLEDCOEF2),
 };
 
 void vc4_hvs_dump_state(struct drm_device *dev)
-- 
2.14.1

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

[PATCH v4 1/2] drm/vc4: Add CTM support

[Stefan Schake]

The hardware has a single block for applying a CTM prior to gamma lut.
It can be fed with pixels from one of our CRTC at a time and uses a
matrix with S0.9 scalars. Use private atomic state to reject attempts
from userland to apply CTM for more than one CRTC at a time and reject
matrices with scalars that we can't approximate without integer bits.

Signed-off-by: Stefan Schake 
Signed-off-by: Eric Anholt 
---
Eric, I removed your r-b since there were a bunch more changes.

v4: Handle CTM disabling in check
Don't use drm_atomic_get_private_obj_state in commit
Fix S31.32 -> S0.9 conversion
Squashed in Erics fixup series:
Don't take the CTM lock unless a CTM change is happening (Eric)
Lock across changes to the CTM (Eric)
Handle allocation failure in out CTM priv state (Eric)
Move CTM object init before FBDEV setup (Eric)
Clean up the CTM private object manager on unload (Eric)

v3: New in the series.

 drivers/gpu/drm/vc4/vc4_crtc.c |   5 +
 drivers/gpu/drm/vc4/vc4_drv.c  |   3 +
 drivers/gpu/drm/vc4/vc4_drv.h  |   4 +
 drivers/gpu/drm/vc4/vc4_kms.c  | 204 -
 4 files changed, 215 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 08fe8dd7d8df..83d3b7912fc2 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -1018,6 +1018,11 @@ static int vc4_crtc_bind(struct device *dev, struct 
device *master, void *data)
drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r));
drm_crtc_enable_color_mgmt(crtc, 0, false, crtc->gamma_size);
 
+   /* We support CTM, but only for one CRTC at a time. It's therefore
+* implemented as private driver state in vc4_kms, not here.
+*/
+   drm_crtc_enable_color_mgmt(crtc, 0, true, crtc->gamma_size);
+
/* Set up some arbitrary number of planes.  We're not limited
 * by a set number of physical registers, just the space in
 * the HVS (16k) and how small an plane can be (28 bytes).
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 94b99c90425a..52bfe0e9ddda 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -320,6 +320,7 @@ static void vc4_drm_unbind(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = platform_get_drvdata(pdev);
+   struct vc4_dev *vc4 = to_vc4_dev(drm);
 
drm_dev_unregister(drm);
 
@@ -327,6 +328,8 @@ static void vc4_drm_unbind(struct device *dev)
 
drm_mode_config_cleanup(drm);
 
+   drm_atomic_private_obj_fini(>ctm_manager);
+
drm_dev_unref(drm);
 }
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 4288615b66a2..22589d39083c 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "uapi/drm/vc4_drm.h"
 
@@ -193,6 +194,9 @@ struct vc4_dev {
} hangcheck;
 
struct semaphore async_modeset;
+
+   struct drm_modeset_lock ctm_state_lock;
+   struct drm_private_obj ctm_manager;
 };
 
 static inline struct vc4_dev *
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index e791e498a3dd..8a411e5f8776 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -23,6 +23,117 @@
 #include 
 #include 
 #include "vc4_drv.h"
+#include "vc4_regs.h"
+
+struct vc4_ctm_state {
+   struct drm_private_state base;
+   struct drm_color_ctm *ctm;
+   int fifo;
+};
+
+static struct vc4_ctm_state *to_vc4_ctm_state(struct drm_private_state *priv)
+{
+   return container_of(priv, struct vc4_ctm_state, base);
+}
+
+static struct vc4_ctm_state *vc4_get_ctm_state(struct drm_atomic_state *state,
+  struct drm_private_obj *manager)
+{
+   struct drm_device *dev = state->dev;
+   struct vc4_dev *vc4 = dev->dev_private;
+   struct drm_private_state *priv_state;
+   int ret;
+
+   ret = drm_modeset_lock(>ctm_state_lock, state->acquire_ctx);
+   if (ret)
+   return ERR_PTR(ret);
+
+   priv_state = drm_atomic_get_private_obj_state(state, manager);
+   if (IS_ERR(priv_state))
+   return ERR_CAST(priv_state);
+
+   return to_vc4_ctm_state(priv_state);
+}
+
+static struct drm_private_state *
+vc4_ctm_duplicate_state(struct drm_private_obj *obj)
+{
+   struct vc4_ctm_state *state;
+
+   state = kmemdup(obj->state, sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return NULL;
+
+   __drm_atomic_helper_private_obj_duplicate_state(obj, >base);
+
+   return >base;
+}
+
+static void vc4_ctm_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+   

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #88 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Great, thanks.(In reply to Ricardo Ribalda from comment #87)
> Hi Andrey
> 
> I have been running some manual tests (~30 boots) and it has been always ok.
> I did not have time to setup an automatic test machine.
> 
> You are more than welcome to close the ticket and I will update it with the
> results later.
> 
> Thanks for your help!

Great, thanks.

Andrey

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #87 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Hi Andrey

I have been running some manual tests (~30 boots) and it has been always ok. I
did not have time to setup an automatic test machine.

You are more than welcome to close the ticket and I will update it with the
results later.

Thanks for your help!

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #86 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Hi, any updates (In reply to Andrey Grodzovsky from comment #85)
> (In reply to Ricardo Ribalda from comment #84)
> > Hi Andrey
> > 
> > I have removed the GALLIUM_DDEBUG=flush  hack and performed around 10
> boots.
> > I have not been able to replicate the bug.
> > 
> > I am porting the patch to my current distro and will run the test there for
> > a couple of hours (hopefully tomorrow). But It looks pretty good!
> > 
> > Kudos!
> 
> Ping me once it's done.
> 
> Thanks.

Any updates ?

Andrey

-- 
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 104439] intel_do_flush_locked failed: Invalid argument

[bugzilla-daemon]

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

--- Comment #10 from Francesco Turco  ---
I can't reproduce this bug anymore with the Falkon 3.0.0 web browser and the
Linux 4.16.2 kernel.

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

Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc

[jacopo mondi]

Hi Peter,

On Fri, Apr 20, 2018 at 01:05:21PM +0200, Peter Rosin wrote:
> On 2018-04-20 12:18, Laurent Pinchart wrote:
> > Hello,
> >
> > On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
> >> Hi Peter,
> >> I've been a bit a pain in the arse for you recently, but please
> >> bear with me a bit more, and sorry for jumping late on the band wagon.
> >>
> >> On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
> >>> Hi!
> >>>
> >>> I naively thought that since there was support for both nxp,tda19988 (in
> >>> the tda998x driver) and the atmel-hlcdc, things would be a smooth ride.
> >>> But it wasn't, so I started looking around and realized I had to fix
> >>> things.
> >>>
> >>> In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
> >>> component, but now in v3 I fix things by making the tda998x driver
> >>> a bridge instead. This was after a suggestion from Boris Brezillion
>
> That should be Brezillon, sorry for being sloppy with the spelling.
>
> >>> (the atmel-hlcdc maintainer), so there was some risk of bias ... but
> >>> after comparing what was needed, I too find the bridge approach better.
> >>>
> >>> In addition to the above, our PCB interface between the SAMA5D3 and the
> >>> HDMI encoder is only using 16 bits, and this has to be described
> >>> somewhere, or the atmel-hlcdc driver have no chance of selecting the
> >>> correct output mode. Since I have similar problems with a ds90c185 lvds
> >>> encoder I added patches to override the atmel-hlcdc output format via
> >>> DT properties compatible with the media video-interface binding and
> >>> things start to play together.
> >>>
> >>> Since this series superseeds the bridge series [1], I have included the
> >>> leftover bindings patch for the ti,ds90c185 here.
> >>
> >> I feel like this series would look better if it would make use of the
> >> proposed bridge media bus format support I have recently sent out [1]
> >> (and which was not there when you first sent v1).
> >>
> >> I understand your fundamental problem here is that the bus format
> >> that should be reported by your bridge is different from the ones
> >> actually supported by the TDA19988 chip, as the wirings ground some
> >> of the input pins.
> >>
> >> Although this is defintely something that could be described in the
> >> bridge's own OF node with the 'bus_width' property, and what I would do,
> >> now that you have made a bridge out from the tda19988 driver, is:
> >>
> >> 1) Set the bridge accepted input bus_format parsing its pin
> >> configuration, or default it if that's not implemented yet.
> >> This will likely be rgb888. You can do that using the trivial
> >> support for bridge input image formats implemented by my series.
> >> 2) Specify in the bridge endpoint a 'bus_width' of <16>
> >> 3) In your atmel-hlcd get both the image format of the bridge (rgb888)
> >> and parse the remote endpoint property 'bus_width' and get the <16>
> >> value back.
> >
> > Parsing properties of remote nodes should be avoided as much as possible, as
> > they need to be interpreted in the context of the DT bindings related to the
> > compatible string applicable to that node. I'd rather have the bus_width
> > property in the local endpoint node.
>
> In addition to that, my view of this binding
>
>   endpoint {
>   bus-type = <0>;

bus-type is used by v4l2_fwnode helpers to decide which type of bus
they're dealing with iirc. Here it seems to me it has no added
value, also because in your bindings description "it shall be 0" and
it is not parsed anywhere in you code, but no big deal

>   bus-widht = <16>;
>   };
>
> is that it always means rgb565. See further below.
>
> >> 4) Set the correct format in the atmel hlcd driver to accommodate a
> >> bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565,
> >> or are there other possible combinations I am missing?)
> >>
> >> I would consider this better mostly because in this series you are
> >> creating a semantic for the whole DRM subsystem on the 'bus_width'
> >> property, where numerical values as '12', '16' etc are arbitrary tied
> >> to the selection of a media bus format. At least you should use a
> >> common set of defines [1] between the device tree and the driver,
> >> but this looks anyway fragile imho.
> >
> > This I agree with though. Combining the remote bus format with the local bus
> > width should fix the problem without having to parse remote properties.
>
> My thinking was that the binding with bus-type = <0> and bus-width = 
> would mean a parallel bus (type 0 means auto-detect and with a bus-width that
> auto-detect means a parallel bus) and the most natural/common interpretation
> of that bus-width. For bus widths of 12, 16, 18, 24, 30 etc I think that
> would be rgb444, rgb565, rgb666, rgb888, rgb101010 (or, I'm first so I get
> to define the default). If you have some other interpretation of a bus with
> that width, you'd need to extend the 

[Bug 104723] [CI] igt@[kms_3d|igt@kms_panel_fitting] - fail - Could not open data file "1080p-left.png": No such file or directoryReceived signal SIGSEGV.

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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 103924] [CI] igt@perf_pmu@other-* - fail - Test assertion failure function read_other - Failed assertion: fd >= 0

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

On 04/20/2018 10:19 AM, Daniel Vetter wrote:

On Wed, Apr 18, 2018 at 11:10:58AM +0100, Roger Pau Monné wrote:

On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote:

On 04/18/2018 10:35 AM, Roger Pau Monné wrote:

On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:

On 04/17/2018 11:57 PM, Dongwon Kim wrote:

On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:

On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:

3.2 Backend exports dma-buf to xen-front

In this case Dom0 pages are shared with DomU. As before, DomU can only write
to these pages, not any other page from Dom0, so it can be still considered
safe.
But, the following must be considered (highlighted in xen-front's Kernel
documentation):
   - If guest domain dies then pages/grants received from the backend cannot
     be claimed back - think of it as memory lost to Dom0 (won't be used for
any
     other guest)
   - Misbehaving guest may send too many requests to the backend exhausting
     its grant references and memory (consider this from security POV). As the
     backend runs in the trusted domain we also assume that it is trusted as
well,
     e.g. must take measures to prevent DDoS attacks.

I cannot parse the above sentence:

"As the backend runs in the trusted domain we also assume that it is
trusted as well, e.g. must take measures to prevent DDoS attacks."

What's the relation between being trusted and protecting from DoS
attacks?

I mean that we trust the backend that it can prevent Dom0
from crashing in case DomU's frontend misbehaves, e.g.
if the frontend sends too many memory requests etc.

In any case, all? PV protocols are implemented with the frontend
sharing pages to the backend, and I think there's a reason why this
model is used, and it should continue to be used.

This is the first use-case above. But there are real-world
use-cases (embedded in my case) when physically contiguous memory
needs to be shared, one of the possible ways to achieve this is
to share contiguous memory from Dom0 to DomU (the second use-case above)

Having to add logic in the backend to prevent such attacks means
that:

   - We need more code in the backend, which increases complexity and
 chances of bugs.
   - Such code/logic could be wrong, thus allowing DoS.

You can live without this code at all, but this is then up to
backend which may make Dom0 down because of DomU's frontend doing evil
things

IMO we should design protocols that do not allow such attacks instead
of having to defend against them.


4. xen-front/backend/xen-zcopy synchronization

4.1. As I already said in 2) all the inter VM communication happens between
xen-front and the backend, xen-zcopy is NOT involved in that.
When xen-front wants to destroy a display buffer (dumb/dma-buf) it issues a
XENDISPL_OP_DBUF_DESTROY command (opposite to XENDISPL_OP_DBUF_CREATE).
This call is synchronous, so xen-front expects that backend does free the
buffer pages on return.

4.2. Backend, on XENDISPL_OP_DBUF_DESTROY:
    - closes all dumb handles/fd's of the buffer according to [3]
    - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen-zcopy to make
sure
      the buffer is freed (think of it as it waits for dma-buf->release
callback)

So this zcopy thing keeps some kind of track of the memory usage? Why
can't the user-space backend keep track of the buffer usage?

Because there is no dma-buf UAPI which allows to track the buffer life cycle
(e.g. wait until dma-buf's .release callback is called)

    - replies to xen-front that the buffer can be destroyed.
This way deletion of the buffer happens synchronously on both Dom0 and DomU
sides. In case if DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE returns with time-out
error
(BTW, wait time is a parameter of this IOCTL), Xen will defer grant
reference
removal and will retry later until those are free.

Hope this helps understand how buffers are synchronously deleted in case
of xen-zcopy with a single protocol command.

I think the above logic can also be re-used by the hyper-dmabuf driver with
some additional work:

1. xen-zcopy can be split into 2 parts and extend:
1.1. Xen gntdev driver [4], [5] to allow creating dma-buf from grefs and
vise versa,

I don't know much about the dma-buf implementation in Linux, but
gntdev is a user-space device, and AFAICT user-space applications
don't have any notion of dma buffers. How are such buffers useful for
user-space? Why can't this just be called memory?

A dma-buf is seen by user-space as a file descriptor and you can
pass it to different drivers then. For example, you can share a buffer
used by a display driver for scanout with a GPU, to compose a picture
into it:
1. User-space (US) allocates a display buffer from display driver
2. US asks display driver to export the dma-buf which backs up that buffer,
US gets buffer's fd: dma_buf_fd
3. US asks GPU driver to import a buffer and provides it with dma_buf_fd
4. GPU renders contents into display 

Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc

[jacopo mondi]

Hi Laurent,

On Fri, Apr 20, 2018 at 01:18:13PM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
> > Hi Peter,
> > I've been a bit a pain in the arse for you recently, but please
> > bear with me a bit more, and sorry for jumping late on the band wagon.
> >
> > On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
> > > Hi!
> > >
> > > I naively thought that since there was support for both nxp,tda19988 (in
> > > the tda998x driver) and the atmel-hlcdc, things would be a smooth ride.
> > > But it wasn't, so I started looking around and realized I had to fix
> > > things.
> > >
> > > In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
> > > component, but now in v3 I fix things by making the tda998x driver
> > > a bridge instead. This was after a suggestion from Boris Brezillion
> > > (the atmel-hlcdc maintainer), so there was some risk of bias ... but
> > > after comparing what was needed, I too find the bridge approach better.
> > >
> > > In addition to the above, our PCB interface between the SAMA5D3 and the
> > > HDMI encoder is only using 16 bits, and this has to be described
> > > somewhere, or the atmel-hlcdc driver have no chance of selecting the
> > > correct output mode. Since I have similar problems with a ds90c185 lvds
> > > encoder I added patches to override the atmel-hlcdc output format via
> > > DT properties compatible with the media video-interface binding and
> > > things start to play together.
> > >
> > > Since this series superseeds the bridge series [1], I have included the
> > > leftover bindings patch for the ti,ds90c185 here.
> >
> > I feel like this series would look better if it would make use of the
> > proposed bridge media bus format support I have recently sent out [1]
> > (and which was not there when you first sent v1).
> >
> > I understand your fundamental problem here is that the bus format
> > that should be reported by your bridge is different from the ones
> > actually supported by the TDA19988 chip, as the wirings ground some
> > of the input pins.
> >
> > Although this is defintely something that could be described in the
> > bridge's own OF node with the 'bus_width' property, and what I would do,
> > now that you have made a bridge out from the tda19988 driver, is:
> >
> > 1) Set the bridge accepted input bus_format parsing its pin
> > configuration, or default it if that's not implemented yet.
> > This will likely be rgb888. You can do that using the trivial
> > support for bridge input image formats implemented by my series.
> > 2) Specify in the bridge endpoint a 'bus_width' of <16>
> > 3) In your atmel-hlcd get both the image format of the bridge (rgb888)
> > and parse the remote endpoint property 'bus_width' and get the <16>
> > value back.
>
> Parsing properties of remote nodes should be avoided as much as possible, as
> they need to be interpreted in the context of the DT bindings related to the
> compatible string applicable to that node. I'd rather have the bus_width
> property in the local endpoint node.

Right, I see...
Well, in Peter's case, the bus width, being a consequence of
wirings, can be described safely in both endpoints, right?

>
> > 4) Set the correct format in the atmel hlcd driver to accommodate a
> > bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565,
> > or are there other possible combinations I am missing?)
> >
> > I would consider this better mostly because in this series you are
> > creating a semantic for the whole DRM subsystem on the 'bus_width'
> > property, where numerical values as '12', '16' etc are arbitrary tied
> > to the selection of a media bus format. At least you should use a
> > common set of defines [1] between the device tree and the driver,
> > but this looks anyway fragile imho.
>
> This I agree with though. Combining the remote bus format with the local bus
> width should fix the problem without having to parse remote properties.
>
> > Have I maybe missed some parts of the problem you are trying to solve
> > here?
> >
> > Thank you
> >j
> >
> > [1] drm: bridge: Add support for static image formats
> > https://lwn.net/Articles/752296/
> > [2] include/uapi/linux/media-bus-format.h
> >
> > > Anyway, this series solves some real issues for my HW.
> > >
> > > Cheers,
> > > Peter
> > >
> > > Changes since v2   https://lkml.org/lkml/2018/4/17/385
> > > - patch 2/7 fixed spelling and added an example
> > > - patch 4/7 parse the DT up front and store the result indexed by encoder
> > > - old patch 5/6 and 6/6 dropped
> > > - patch 5-7/7 are new and makes the tda998x driver a drm_bridge
> > >
> > > Changes since v1   https://lkml.org/lkml/2018/4/9/294
> > > - added reviewed-by from Rob to patch 1/6
> > > - patch 2/6 changed so that the bus format override is in the endpoint
> > >   DT node, and follows the binding of media video-interfaces.
> > > - patch 3/6 is new, it adds drm_of_media_bus_fmt which parses above
> > > 

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christian König]

Am 20.04.2018 um 12:17 schrieb Christoph Hellwig:

On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:

Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into  dma-buf", but that doesn't render the interface a bad idea.

Completely agree on that.

What we need is an sg_alloc_table_from_resources(dev, resources,
num_resources) which does the handling common to all drivers.

A structure that contains

{page,offset,len} + {dma_addr+dma_len}

is not a good container for storing

{virt addr, dma_addr, len}

no matter what interface you build arond it.


Why not? I mean at least for my use case we actually don't need the 
virtual address.


What we need is {dma_addr+dma_len} in a consistent interface which can 
come from both {page,offset,len} as well as {resource, len}.


What I actually don't need is separate handling for system memory and 
resources, but that would we get exactly when we don't use sg_table.


Christian.


And that is discounting
all the problems around mapping coherent allocations for other devices,
or the iommu merging problem we are having another thread on.

So let's come up with a better high level interface first, and then
worrty about how to implement it in the low-level dma-mapping interface
second.  Especially given that my consolidation of the dma_map_ops
implementation is in full stream and there shoudn't be all that many
to bother with.

So first question:  Do you actually care about having multiple
pairs of the above, or instead of all chunks just deal with a single
of the above?  In that case we really should not need that many
new interfaces as dma_map_resource will be all you need anyway.


Christian.


-Daniel

---end quoted text---


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

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

[kbuild test robot]

Hi Peter,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.17-rc1 next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Peter-Rosin/Add-tda998x-HDMI-support-to-atmel-hlcdc/20180420-160131
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-a0-201815 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i2c/tda998x_drv.c: In function 'tda998x_probe':
>> drivers/gpu/drm/i2c/tda998x_drv.c:1859:16: error: 'struct drm_bridge' has no 
>> member named 'of_node'
 bridge->bridge.of_node = dev->of_node;
   ^

vim +1859 drivers/gpu/drm/i2c/tda998x_drv.c

  1838  
  1839  static int
  1840  tda998x_probe(struct i2c_client *client, const struct i2c_device_id *id)
  1841  {
  1842  struct device *dev = >dev;
  1843  struct tda998x_bridge *bridge;
  1844  int ret;
  1845  
  1846  if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
  1847  dev_warn(>dev, "adapter does not support 
I2C\n");
  1848  return -EIO;
  1849  }
  1850  
  1851  bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
  1852  if (!bridge)
  1853  return -ENOMEM;
  1854  
  1855  bridge->dev = dev;
  1856  dev_set_drvdata(dev, bridge);
  1857  
  1858  bridge->bridge.funcs = _bridge_funcs;
> 1859  bridge->bridge.of_node = dev->of_node;
  1860  drm_bridge_add(>bridge);
  1861  
  1862  ret = component_add(dev, _ops);
  1863  
  1864  if (ret)
  1865  drm_bridge_remove(>bridge);
  1866  
  1867  return ret;
  1868  }
  1869  

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


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

Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays

[Daniel Stone]

Hi Tomi,

On 20 April 2018 at 08:09, Tomi Valkeinen  wrote:
> It's actually not quite clear to me how manual update displays work with
> DRM...
>
> As far as I see, we have essentially two cases: 1) single buffering,
> where the userspace must set an area in the fb dirty, which then
> triggers the update, 2) multi buffering, which doesn't need fb dirty,
> but just a page flip which triggers the update.
>
> In the 2) case (which I think is the optimal case which all the modern
> apps should use), there's no need for delayed work or any work, and the
> code flow should be very similar to the auto-update model.

Correct. There's been talk (and I think patches?) of adding a
per-plane dirty property, so userspace can as an optimisation inform
the kernel of the area changed between frames. But short of that, a
pageflip needs to trigger a full-plane update, with no dirtyfb
required.

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

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Hans de Goede]

Hi,

On 20-04-18 09:27, Daniel Vetter wrote:

On Thu, Apr 19, 2018 at 03:43:19PM +0200, Hans de Goede wrote:

Hi,

On 05-04-18 15:26, Daniel Vetter wrote:

On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede  wrote:

Hi,


On 05-04-18 09:14, Daniel Vetter wrote:


On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goede wrote:


Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range
passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try
and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.

Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to
fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."

Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.

This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.

The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.

This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).

Signed-off-by: Hans de Goede 



I think this is worth a shot. The only explanation I can think of why the
GOP could get away with this and still follow the w/a is if it doesn't
have a 1:1 mapping between GGTT and stolen.



My guess is that the GOP does not care about the w/a because the w/a
states that the command-streamers sometimes do a spurious flush (write)
to the first page, and the command-streamers are not used until much
later, so the GOP is probably ignoring the w/a all together.

At least that is my theory.


Atm we do not know whether the GOP actually implements the wa or not.
That it doesn't care is just a conjecture, but we have no proof. On
previous platforms the 1:1 mapping did hold, but there's no
fundamental reason why it sitll does.


Right.


Atm we hardcode that
assumption in intel_alloc_initial_plane_obj by passing the base_aligned as
both the stolen_offset and the gtt_offset (but it's only the gtt_offset
really). And since we're not re-writing the ptes it's not noticeable.

I think to decide whether this is the right approach we should
double-check whether that 1:1 assumption really holds true: Either read
back the ggtt ptes and check their addresses (but iirc on some platforms
their write-only, readback doesn't work), or we also rewrite the ptes
again for preallocated stuff, like when binding a normal object into the
gtt. If either of these approaches confirms that those affected gen8+
machines still use the 1:1 mapping, then I'm happy to put my r-b on this
patch. If not, well then we at least know what to fix: We need to read out
the real stolen_offset, instead of making assumptions.



I'm happy to give this a try on one or more affected machines, I can e.g.
try this on both a skylake desktop and a cherry-trail based tablet.

But I'm clueless about the whole PTE stuff, so I'm going to need someone
to provide me with a patch following either approach. If readback of the
PTEs works on skylake / cherrytrail I guess that would be the best way.

Note to test this I'm currently booting the kernel with the machine's
UEFI vendor logo still being displayed when efifb kicks in. I've added:
"fbcon=vc:2-62" to the kernel commandline to make fbcon not bind to
VC0 / VC1, so that the framebuffer contents stays intact, combined with
the patch we are discussing now, this makes the vendor logo stay on
the screen all the way till GDM loads, which looks rather nice actually :)

And on shutdown we fall back to the original framebuffer and the vendor
logo is back again. I cannot see any corruption in the display at either
boot or shutdown time.


It shouldn't matter whether efifb takes over or not, it's still the
GOP's framebuffer we're taking over. Different content for sure, logo
is gone, but we only care about which pages we're using.

Wrt the code:
- (Re)binding happens by calling i915_vma_bind, if you put a call to
that at the end of the stolen_preallocated functions you should get
that. Ofc needs the logo still there so you can see it jump/get
mangled.
- GGTT PTEs for gen8+ are written 

Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc

[Laurent Pinchart]

Hello,

On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
> Hi Peter,
> I've been a bit a pain in the arse for you recently, but please
> bear with me a bit more, and sorry for jumping late on the band wagon.
> 
> On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
> > Hi!
> > 
> > I naively thought that since there was support for both nxp,tda19988 (in
> > the tda998x driver) and the atmel-hlcdc, things would be a smooth ride.
> > But it wasn't, so I started looking around and realized I had to fix
> > things.
> > 
> > In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
> > component, but now in v3 I fix things by making the tda998x driver
> > a bridge instead. This was after a suggestion from Boris Brezillion
> > (the atmel-hlcdc maintainer), so there was some risk of bias ... but
> > after comparing what was needed, I too find the bridge approach better.
> > 
> > In addition to the above, our PCB interface between the SAMA5D3 and the
> > HDMI encoder is only using 16 bits, and this has to be described
> > somewhere, or the atmel-hlcdc driver have no chance of selecting the
> > correct output mode. Since I have similar problems with a ds90c185 lvds
> > encoder I added patches to override the atmel-hlcdc output format via
> > DT properties compatible with the media video-interface binding and
> > things start to play together.
> > 
> > Since this series superseeds the bridge series [1], I have included the
> > leftover bindings patch for the ti,ds90c185 here.
> 
> I feel like this series would look better if it would make use of the
> proposed bridge media bus format support I have recently sent out [1]
> (and which was not there when you first sent v1).
> 
> I understand your fundamental problem here is that the bus format
> that should be reported by your bridge is different from the ones
> actually supported by the TDA19988 chip, as the wirings ground some
> of the input pins.
> 
> Although this is defintely something that could be described in the
> bridge's own OF node with the 'bus_width' property, and what I would do,
> now that you have made a bridge out from the tda19988 driver, is:
> 
> 1) Set the bridge accepted input bus_format parsing its pin
> configuration, or default it if that's not implemented yet.
> This will likely be rgb888. You can do that using the trivial
> support for bridge input image formats implemented by my series.
> 2) Specify in the bridge endpoint a 'bus_width' of <16>
> 3) In your atmel-hlcd get both the image format of the bridge (rgb888)
> and parse the remote endpoint property 'bus_width' and get the <16>
> value back.

Parsing properties of remote nodes should be avoided as much as possible, as 
they need to be interpreted in the context of the DT bindings related to the 
compatible string applicable to that node. I'd rather have the bus_width 
property in the local endpoint node.

> 4) Set the correct format in the atmel hlcd driver to accommodate a
> bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565,
> or are there other possible combinations I am missing?)
> 
> I would consider this better mostly because in this series you are
> creating a semantic for the whole DRM subsystem on the 'bus_width'
> property, where numerical values as '12', '16' etc are arbitrary tied
> to the selection of a media bus format. At least you should use a
> common set of defines [1] between the device tree and the driver,
> but this looks anyway fragile imho.

This I agree with though. Combining the remote bus format with the local bus 
width should fix the problem without having to parse remote properties.

> Have I maybe missed some parts of the problem you are trying to solve
> here?
> 
> Thank you
>j
> 
> [1] drm: bridge: Add support for static image formats
> https://lwn.net/Articles/752296/
> [2] include/uapi/linux/media-bus-format.h
> 
> > Anyway, this series solves some real issues for my HW.
> > 
> > Cheers,
> > Peter
> > 
> > Changes since v2   https://lkml.org/lkml/2018/4/17/385
> > - patch 2/7 fixed spelling and added an example
> > - patch 4/7 parse the DT up front and store the result indexed by encoder
> > - old patch 5/6 and 6/6 dropped
> > - patch 5-7/7 are new and makes the tda998x driver a drm_bridge
> > 
> > Changes since v1   https://lkml.org/lkml/2018/4/9/294
> > - added reviewed-by from Rob to patch 1/6
> > - patch 2/6 changed so that the bus format override is in the endpoint
> >   DT node, and follows the binding of media video-interfaces.
> > - patch 3/6 is new, it adds drm_of_media_bus_fmt which parses above
> >   media video-interface binding (partially).
> > - patch 4/6 now makes use of the above helper (and also fixes problems
> >   with the 3/5 patch from v1 when no override was specified).
> > - do not mention unrelated connector display_info details in the cover
> >   letter and commit messages.
> > 
> > [1]
> > "Bridge" series v2   https://lkml.org/lkml/2018/3/26/610
> > "Bridge" series v1 

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:
> > Yes there's a bit a layering violation insofar that drivers really
> > shouldn't each have their own copy of "how do I convert a piece of dma
> > memory into  dma-buf", but that doesn't render the interface a bad idea.
> 
> Completely agree on that.
> 
> What we need is an sg_alloc_table_from_resources(dev, resources,
> num_resources) which does the handling common to all drivers.

A structure that contains

{page,offset,len} + {dma_addr+dma_len}

is not a good container for storing

{virt addr, dma_addr, len}

no matter what interface you build arond it.  And that is discounting
all the problems around mapping coherent allocations for other devices,
or the iommu merging problem we are having another thread on.

So let's come up with a better high level interface first, and then
worrty about how to implement it in the low-level dma-mapping interface
second.  Especially given that my consolidation of the dma_map_ops
implementation is in full stream and there shoudn't be all that many
to bother with.

So first question:  Do you actually care about having multiple
pairs of the above, or instead of all chunks just deal with a single
of the above?  In that case we really should not need that many
new interfaces as dma_map_resource will be all you need anyway.

> 
> Christian.
> 
> > -Daniel
> 
---end quoted text---
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/virtio: fix vq wait_event condition

[Dave Airlie]

Reviewed-by: Dave Airlie 

On Fri., 20 Apr. 2018, 17:23 Gerd Hoffmann,  wrote:

> On Tue, Apr 03, 2018 at 11:59:04AM +0200, Gerd Hoffmann wrote:
> > Wait until we have enough space in the virt queue to actually queue up
> > our request.  Avoids the guest spinning in case we have a non-zero
> > amount of free entries but not enough for the request.
>
> Ping airlied, can you please either pick it up or review so I can commit
> myself?
>
> thanks,
>   Gerd
>
> > Cc: sta...@vger.kernel.org
> > Reported-by: Alain Magloire 
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> > index 48e4f1df6e..020070d483 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> > @@ -293,7 +293,7 @@ static int
> virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device *vgdev,
> >   ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC);
> >   if (ret == -ENOSPC) {
> >   spin_unlock(>ctrlq.qlock);
> > - wait_event(vgdev->ctrlq.ack_queue, vq->num_free);
> > + wait_event(vgdev->ctrlq.ack_queue, vq->num_free >= outcnt
> + incnt);
> >   spin_lock(>ctrlq.qlock);
> >   goto retry;
> >   } else {
> > @@ -368,7 +368,7 @@ static int virtio_gpu_queue_cursor(struct
> virtio_gpu_device *vgdev,
> >   ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC);
> >   if (ret == -ENOSPC) {
> >   spin_unlock(>cursorq.qlock);
> > - wait_event(vgdev->cursorq.ack_queue, vq->num_free);
> > + wait_event(vgdev->cursorq.ack_queue, vq->num_free >=
> outcnt);
> >   spin_lock(>cursorq.qlock);
> >   goto retry;
> >   } else {
> > --
> > 2.9.3
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

[Laurent Pinchart]

Hi Peter,

Thank you for the patch.

On Thursday, 19 April 2018 19:27:51 EEST Peter Rosin wrote:
> This makes this driver work with all(?) drivers that are not
> componentized and instead expect to connect to a panel/bridge. That
> said, the only one tested is atmel_hlcdc.
> 
> This hooks the relevant work function previously called by the encoder
> and the component also to the bridge, since the encoder goes away when
> connecting to the bridge interface of the driver and the equivalent of
> bind/unbind of the component is handled by bridge attach/detach.
> 
> The lifetime requirements of a bridge and a component are slightly
> different, which is the reason for struct tda998x_bridge.

Couldn't you move the allocation and initialization (tda998x_create) of the 
tda998x_priv structure to probe time ? I think you wouldn't need a separate 
structure in that case. Unless I'm mistaken there would be an added benefit of 
separating component and bridge initialization, resulting in the encoder not 
being initialized at all if the component isn't used. You wouldn't need to add 
a local_encoder parameter to the tda998x_init() function.

> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 157 ---
>  1 file changed, 137 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c index 9c78f7bde49c..012dee61d817 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -36,6 +36,14 @@ struct tda998x_audio_port {
>   u8 config;  /* AP value */
>  };
> 
> +struct tda998x_priv;
> +
> +struct tda998x_bridge {
> + struct tda998x_priv *priv;
> + struct device *dev;
> + struct drm_bridge bridge;
> +};
> +
>  struct tda998x_priv {
>   struct i2c_client *cec;
>   struct i2c_client *hdmi;
> @@ -63,6 +71,8 @@ struct tda998x_priv {
>   wait_queue_head_t edid_delay_waitq;
>   bool edid_delay_active;
> 
> + struct tda998x_bridge *bridge;
> + bool local_encoder;
>   struct drm_encoder encoder;
>   struct drm_connector connector;
> 
> @@ -75,6 +85,9 @@ struct tda998x_priv {
>  #define enc_to_tda998x_priv(x) \
>   container_of(x, struct tda998x_priv, encoder)
> 
> +#define bridge_to_tda998x_bridge(x) \
> + container_of(x, struct tda998x_bridge, bridge)
> +
>  /* The TDA9988 series of devices use a paged register scheme.. to simplify
>   * things we encode the page # in upper bits of the register #.  To read/
>   * write a given register, we need to make sure CURPAGE register is set
> @@ -842,7 +855,8 @@ static int tda998x_audio_hw_params(struct device *dev,
> void *data, struct hdmi_codec_daifmt *daifmt,
>  struct hdmi_codec_params *params)
>  {
> - struct tda998x_priv *priv = dev_get_drvdata(dev);
> + struct tda998x_bridge *bridge = dev_get_drvdata(dev);
> + struct tda998x_priv *priv = bridge->priv;
>   int i, ret;
>   struct tda998x_audio_params audio = {
>   .sample_width = params->sample_width,
> @@ -899,7 +913,8 @@ static int tda998x_audio_hw_params(struct device *dev,
> void *data,
> 
>  static void tda998x_audio_shutdown(struct device *dev, void *data)
>  {
> - struct tda998x_priv *priv = dev_get_drvdata(dev);
> + struct tda998x_bridge *bridge = dev_get_drvdata(dev);
> + struct tda998x_priv *priv = bridge->priv;
> 
>   mutex_lock(>audio_mutex);
> 
> @@ -912,7 +927,8 @@ static void tda998x_audio_shutdown(struct device *dev,
> void *data)
> 
>  int tda998x_audio_digital_mute(struct device *dev, void *data, bool enable)
> {
> - struct tda998x_priv *priv = dev_get_drvdata(dev);
> + struct tda998x_bridge *bridge = dev_get_drvdata(dev);
> + struct tda998x_priv *priv = bridge->priv;
> 
>   mutex_lock(>audio_mutex);
> 
> @@ -925,7 +941,8 @@ int tda998x_audio_digital_mute(struct device *dev, void
> *data, bool enable) static int tda998x_audio_get_eld(struct device *dev,
> void *data,
>uint8_t *buf, size_t len)
>  {
> - struct tda998x_priv *priv = dev_get_drvdata(dev);
> + struct tda998x_bridge *bridge = dev_get_drvdata(dev);
> + struct tda998x_priv *priv = bridge->priv;
> 
>   mutex_lock(>audio_mutex);
>   memcpy(buf, priv->connector.eld,
> @@ -1126,7 +1143,10 @@ tda998x_connector_best_encoder(struct drm_connector
> *connector) {
>   struct tda998x_priv *priv = conn_to_tda998x_priv(connector);
> 
> - return >encoder;
> + if (priv->local_encoder)
> + return >encoder;
> + else
> + return priv->bridge->bridge.encoder;
>  }
> 
>  static
> @@ -1140,6 +1160,7 @@ static int tda998x_connector_init(struct tda998x_priv
> *priv, struct drm_device *drm)
>  {
>   struct drm_connector *connector = >connector;
> + struct drm_encoder *encoder;
>   int ret;
> 
>   connector->interlace_allowed = 1;
> @@ -1156,7 

Re: [PATCH 1/8] drm/mediatek: Use regmap for register access

[Philipp Zabel]

Hi Matthias,

On Fri, 2018-04-20 at 11:41 +0200, Matthias Brugger wrote:
> Hi Philipp,
> 
> On 11/23/2017 09:54 AM, Philipp Zabel wrote:
> > Hi Matthias,
> > 
> > On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> > > The mmsys memory space is shared between the drm and the
> > > clk driver. Use regmap to access it.
> > > 
> > > Signed-off-by: Matthias Brugger 
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  4 ++--
> > >  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 30 
> > > +-
> > >  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  4 ++--
> > >  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 13 -
> > >  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  2 +-
> > >  5 files changed, 26 insertions(+), 27 deletions(-)
> > 
> > [...]
> 
> [...]
> > >   }
> > >  
> > >   value = mtk_ddp_sel_in(cur, next, );
> > >   if (value) {
> > > - reg = readl_relaxed(config_regs + addr) & ~value;
> > > - writel_relaxed(reg, config_regs + addr);
> > > + regmap_read(config_regs, addr, );
> > > + reg &= ~value;
> > > + regmap_write(config_regs, addr, reg);
> > 
> > regmap_update_bits(config_regs, addr, value, 0);
> > 
> > Reviewed-by: Philipp Zabel 
> > 
> 
> Thanks for having a look on that.
> 
> I'll update the next version with regmap_update_bits and leave your 
> Reviewed-by,
> hope that's ok.

Yes, that's fine.

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

Re: [PATCH v3 6/7] drm/i2c: tda998x: split encoder and component functions from the work

[Laurent Pinchart]

Hi Peter,

Thank you for the patch.

On Thursday, 19 April 2018 19:27:50 EEST Peter Rosin wrote:
> This enables reuse of the machinery for the case where a drm_bridge
> needs to do the same work via different interfaces.
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 46 
>  1 file changed, 36 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c index 8f6e013f2b87..9c78f7bde49c 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1163,9 +1163,8 @@ static int tda998x_connector_init(struct tda998x_priv
> *priv,
> 
>  /* DRM encoder functions */
> 
> -static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
> +static void tda998x_dpms(struct tda998x_priv *priv, int mode)

I'd split this function into tda998x_enable() and tda998x_disable(), as the 
DRM bridge API doesn't need to care about DPMS. The core of the driver would 
then be DPMS-free.

Apart from that the patch looks good to me.

>  {
> - struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
>   bool on;
> 
>   /* we only care about on or off: */
> @@ -1195,12 +1194,18 @@ static void tda998x_encoder_dpms(struct drm_encoder
> *encoder, int mode) }
>  }
> 
> -static void
> -tda998x_encoder_mode_set(struct drm_encoder *encoder,
> -  struct drm_display_mode *mode,
> -  struct drm_display_mode *adjusted_mode)
> +static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
>  {
>   struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
> +
> + tda998x_dpms(priv, mode);
> +}
> +
> +static void
> +tda998x_mode_set(struct tda998x_priv *priv,
> +  struct drm_display_mode *mode,
> +  struct drm_display_mode *adjusted_mode)
> +{
>   u16 ref_pix, ref_line, n_pix, n_line;
>   u16 hs_pix_s, hs_pix_e;
>   u16 vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
> @@ -1407,6 +1412,16 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> mutex_unlock(>audio_mutex);
>  }
> 
> +static void
> +tda998x_encoder_mode_set(struct drm_encoder *encoder,
> +  struct drm_display_mode *mode,
> +  struct drm_display_mode *adjusted_mode)
> +{
> + struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
> +
> + tda998x_mode_set(priv, mode, adjusted_mode);
> +}
> +
>  static void tda998x_destroy(struct tda998x_priv *priv)
>  {
>   /* disable all IRQs and free the IRQ handler */
> @@ -1653,11 +1668,10 @@ static void tda998x_set_config(struct tda998x_priv
> *priv, priv->audio_params = p->audio_params;
>  }
> 
> -static int tda998x_bind(struct device *dev, struct device *master, void
> *data)
> +static int tda998x_init(struct device *dev, struct drm_device *drm)
> {
>   struct tda998x_encoder_params *params = dev->platform_data;
>   struct i2c_client *client = to_i2c_client(dev);
> - struct drm_device *drm = data;
>   struct tda998x_priv *priv;
>   u32 crtcs = 0;
>   int ret;
> @@ -1705,8 +1719,7 @@ static int tda998x_bind(struct device *dev, struct
> device *master, void *data) return ret;
>  }
> 
> -static void tda998x_unbind(struct device *dev, struct device *master,
> -void *data)
> +static void tda998x_fini(struct device *dev)
>  {
>   struct tda998x_priv *priv = dev_get_drvdata(dev);
> 
> @@ -1715,6 +1728,19 @@ static void tda998x_unbind(struct device *dev, struct
> device *master, tda998x_destroy(priv);
>  }
> 
> +static int tda998x_bind(struct device *dev, struct device *master, void
> *data)
> +{
> + struct drm_device *drm = data;
> +
> + return tda998x_init(dev, drm);
> +}
> +
> +static void tda998x_unbind(struct device *dev, struct device *master,
> +void *data)
> +{
> + tda998x_fini(dev);
> +}
> +
>  static const struct component_ops tda998x_ops = {
>   .bind = tda998x_bind,
>   .unbind = tda998x_unbind,

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v3 5/7] drm/i2c: tda998x: find the drm_device via the drm_connector

[Laurent Pinchart]

Hi Peter,

Thank you for the patch.

On Thursday, 19 April 2018 19:27:49 EEST Peter Rosin wrote:
> This prepares for being a drm_bridge which will not register the
> encoder. That makes the connector the better choice.
> 
> Signed-off-by: Peter Rosin 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c index cd3f0873bbdd..8f6e013f2b87 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -630,7 +630,7 @@ static void tda998x_detect_work(struct work_struct
> *work) {
>   struct tda998x_priv *priv =
>   container_of(work, struct tda998x_priv, detect_work);
> - struct drm_device *dev = priv->encoder.dev;
> + struct drm_device *dev = priv->connector.dev;
> 
>   if (dev)
>   drm_kms_helper_hotplug_event(dev);


-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v9 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

[Andrzej Hajda]

On 18.04.2018 16:40, Jacopo Mondi wrote:
> As I have another series which is based on this one + Eagle board display
> support, I'm re-sending this one to fix the small issue I pointed out in my
> reply to v8.
>
> Simon: no changes to Eagle DTS series, so the last one sent is still the good
> one.
>
> DRM: I have collected several reviewed-by tags both on driver and bindings.
> Can I send out incremental patches on this series and consider this one to
> be ready to be collected?

Queued to drm-misc-next.

Regards
Andrzej


>
> Thanks
>j
>
> v8 -> v9:
> - Put 'remote' OF node after usage not just in error path during device
>   tree parsing routine
> - Add Rob's Reviewed-by tag to the device tree bindings documentation
>
> v7 -> b8:
> - Make 'vcc' supply mandatory
> - Use 'oe' property name to describe "OE" pin
> - Minor fixes as suggested by Laurent on bindings and driver
>
> v6 -> v7:
> - Use semi-standard names for powerdown and output enable GPIOs as suggested
>   by Rob and Vladimir
> - Use 'regulator_get()' not the optional version, and list only 'vcc' as
>   requested supply
> - Addressed Laurent's review comments and removed Eagle display enablement 
> patch
>   to be sent separately
>
> v5 -> v6:
> - Drop check for CONFIG_OF as it is a Kconfig dependency
> - Add Niklas Reviewed-by tags
> - List [3/3] depenencies below commit message to ease integration
>
> v4 -> v5:
> - Fix punctuation in bindings documentation
> - Add small statement to bindings document to clarify the chip has no
>   control bus
> - Print regulator name in enable/disable routines error path
> - Add Andrzej Reviewed-by tag
>
> v3 -> v4:
> - Rename permutations of "pdwn" to just "pdwn" everywhere in the series
> - Improve power enable/disable routines as suggested by Andrzej and Sergei
> - Change "pdwn" gpio initialization to use the logical output level
> - Change Kconfig description
>
> v2 -> v3:
> - Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific
> -- Rework bindings to describe multiple input/output ports
> -- Rename driver and remove "lvds-decoder" references
> -- Rework Eagle DTS to use new bindings
>
> v1 -> v2:
> - Drop support for THC63LVD1024
>
> Jacopo Mondi (2):
>   dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
>   drm: bridge: Add thc63lvd1024 LVDS decoder driver
>
>  .../bindings/display/bridge/thine,thc63lvd1024.txt |  60 ++
>  drivers/gpu/drm/bridge/Kconfig |   6 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/thc63lvd1024.c  | 205 
> +
>  4 files changed, 272 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
>
> --
> 2.7.4
>
>
>
>

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

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christian König]

Am 20.04.2018 um 09:13 schrieb Daniel Vetter:

On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:

On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:

We've broken that assumption in i915 years ago. Not struct page backed
gpu memory is very real.

Of course we'll never feed such a strange sg table to a driver which
doesn't understand it, but allowing sg_page == NULL works perfectly
fine. At least for gpu drivers.

For GPU drivers on x86 with no dma coherency problems, sure.  But not
all the world is x86.  We already have problems due to dmabugs use
of the awkward get_sgtable interface (see the common on
arm_dma_get_sgtable that I fully agree with), and doing this for memory
that doesn't have a struct page at all will make things even worse.

x86 dma isn't coherent either, if you're a GPU :-) Flushing gpu caches
tends to be too expensive, so there's pci-e support and chipset support to
forgo it. Plus drivers flushing caches themselves.

The dma_get_sgtable thing is indeed fun, right solution would probably be
to push the dma-buf export down into the dma layer. The comment for
arm_dma_get_sgtable is also not a realy concern, because dma-buf also
abstracts away the flushing (or well is supposed to), so there really
shouldn't be anyone calling the streaming apis on the returned sg table.
That's why dma-buf gives you an sg table that's mapped already.


If that's not acceptable then I guess we could go over the entire tree
and frob all the gpu related code to switch over to a new struct
sg_table_might_not_be_struct_page_backed, including all the other
functions we added over the past few years to iterate over sg tables.
But seems slightly silly, given that sg tables seem to do exactly what
we need.

It isn't silly.  We will have to do some surgery like that anyway
because the current APIs don't work.  So relax, sit back and come up
with an API that solves the existing issues and serves us well in
the future.

So we should just implement a copy of sg table for dma-buf, since I still
think it does exactly what we need for gpus?

Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into  dma-buf", but that doesn't render the interface a bad idea.


Completely agree on that.

What we need is an sg_alloc_table_from_resources(dev, resources, 
num_resources) which does the handling common to all drivers.


Christian.


-Daniel


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

Re: [PATCH 2/2] drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+

[Daniel Vetter]

On Thu, Apr 19, 2018 at 12:20:35PM -0700, Eric Anholt wrote:
> This driver will be used to support Mesa on the Broadcom 7268 and 7278
> platforms.
> 
> V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's
> complicated CL/shader validation scheme.  This massively changes the
> GEM behavior, so I've forked off to a new driver.
> 
> Signed-off-by: Eric Anholt 

Read through the entire thing, ignored the hw details, but dropped a few
comments all over. With those addressed one way or another this has my

Acked-by: Daniel Vetter 

Can I call in a return favour for
https://patchwork.freedesktop.org/series/41219/ ?

Cheers, Daniel

> ---
>  Documentation/gpu/drivers.rst  |   1 +
>  MAINTAINERS|   9 +
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/v3d/Kconfig|   9 +
>  drivers/gpu/drm/v3d/Makefile   |  18 +
>  drivers/gpu/drm/v3d/v3d_bo.c   | 392 +++
>  drivers/gpu/drm/v3d/v3d_debugfs.c  | 191 +++
>  drivers/gpu/drm/v3d/v3d_drv.c  | 371 ++
>  drivers/gpu/drm/v3d/v3d_drv.h  | 305 +++
>  drivers/gpu/drm/v3d/v3d_fence.c|  58 +++
>  drivers/gpu/drm/v3d/v3d_gem.c  | 671 +
>  drivers/gpu/drm/v3d/v3d_irq.c  | 211 
>  drivers/gpu/drm/v3d/v3d_mmu.c  | 122 +
>  drivers/gpu/drm/v3d/v3d_regs.h | 295 +++
>  drivers/gpu/drm/v3d/v3d_sched.c| 230 +
>  drivers/gpu/drm/v3d/v3d_trace.h|  82 +++
>  drivers/gpu/drm/v3d/v3d_trace_points.c |   9 +
>  include/uapi/drm/v3d_drm.h | 191 +++
>  19 files changed, 3168 insertions(+)
>  create mode 100644 drivers/gpu/drm/v3d/Kconfig
>  create mode 100644 drivers/gpu/drm/v3d/Makefile
>  create mode 100644 drivers/gpu/drm/v3d/v3d_bo.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_debugfs.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_drv.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_drv.h
>  create mode 100644 drivers/gpu/drm/v3d/v3d_fence.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_gem.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_irq.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_mmu.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_regs.h
>  create mode 100644 drivers/gpu/drm/v3d/v3d_sched.c
>  create mode 100644 drivers/gpu/drm/v3d/v3d_trace.h
>  create mode 100644 drivers/gpu/drm/v3d/v3d_trace_points.c
>  create mode 100644 include/uapi/drm/v3d_drm.h
> 
> diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
> index d3ab6abae838..f982558fc25d 100644
> --- a/Documentation/gpu/drivers.rst
> +++ b/Documentation/gpu/drivers.rst
> @@ -10,6 +10,7 @@ GPU Driver Documentation
> tegra
> tinydrm
> tve200
> +   v3d
> vc4
> bridge/dw-hdmi
> xen-front
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bca3c32fb141..7314d66833fd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4795,6 +4795,15 @@ S: Maintained
>  F:   drivers/gpu/drm/omapdrm/
>  F:   Documentation/devicetree/bindings/display/ti/
>  
> +DRM DRIVERS FOR V3D
> +M:   Eric Anholt 
> +T:   git git://github.com/anholt/linux

This one also official? If it's just for now I'd drop it ...

> +S:   Supported
> +F:   drivers/gpu/drm/v3d/
> +F:   include/uapi/drm/v3d_drm.h
> +F:   Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +
>  DRM DRIVERS FOR VC4
>  M:   Eric Anholt 
>  T:   git git://github.com/anholt/linux
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 757825ac60df..1c73a455fdb1 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -267,6 +267,8 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig"
>  
>  source "drivers/gpu/drm/imx/Kconfig"
>  
> +source "drivers/gpu/drm/v3d/Kconfig"
> +
>  source "drivers/gpu/drm/vc4/Kconfig"
>  
>  source "drivers/gpu/drm/etnaviv/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 9d66657ea117..7a401edd8761 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_DRM_MGA)   += mga/
>  obj-$(CONFIG_DRM_I810)   += i810/
>  obj-$(CONFIG_DRM_I915)   += i915/
>  obj-$(CONFIG_DRM_MGAG200) += mgag200/
> +obj-$(CONFIG_DRM_V3D)  += v3d/
>  obj-$(CONFIG_DRM_VC4)  += vc4/
>  obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
>  obj-$(CONFIG_DRM_SIS)   += sis/
> diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
> new file mode 100644
> index ..a0c0259355bd
> --- /dev/null
> +++ b/drivers/gpu/drm/v3d/Kconfig
> @@ -0,0 +1,9 @@
> +config DRM_V3D
> + tristate "Broadcom V3D 3.x and newer"
> + depends on ARCH_BCM || ARCH_BCMSTB || COMPILE_TEST
> + depends on DRM
> + depends on COMMON_CLK
> + select DRM_SCHED
> + help
> +   

Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc

[jacopo mondi]

Hi Peter,
I've been a bit a pain in the arse for you recently, but please
bear with me a bit more, and sorry for jumping late on the band wagon.

On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
> Hi!
>
> I naively thought that since there was support for both nxp,tda19988 (in
> the tda998x driver) and the atmel-hlcdc, things would be a smooth ride.
> But it wasn't, so I started looking around and realized I had to fix
> things.
>
> In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
> component, but now in v3 I fix things by making the tda998x driver
> a bridge instead. This was after a suggestion from Boris Brezillion
> (the atmel-hlcdc maintainer), so there was some risk of bias ... but
> after comparing what was needed, I too find the bridge approach better.
>
> In addition to the above, our PCB interface between the SAMA5D3 and the
> HDMI encoder is only using 16 bits, and this has to be described
> somewhere, or the atmel-hlcdc driver have no chance of selecting the
> correct output mode. Since I have similar problems with a ds90c185 lvds
> encoder I added patches to override the atmel-hlcdc output format via
> DT properties compatible with the media video-interface binding and
> things start to play together.
>
> Since this series superseeds the bridge series [1], I have included the
> leftover bindings patch for the ti,ds90c185 here.
>

I feel like this series would look better if it would make use of the
proposed bridge media bus format support I have recently sent out [1]
(and which was not there when you first sent v1).

I understand your fundamental problem here is that the bus format
that should be reported by your bridge is different from the ones
actually supported by the TDA19988 chip, as the wirings ground some
of the input pins.

Although this is defintely something that could be described in the
bridge's own OF node with the 'bus_width' property, and what I would do,
now that you have made a bridge out from the tda19988 driver, is:

1) Set the bridge accepted input bus_format parsing its pin
configuration, or default it if that's not implemented yet.
This will likely be rgb888. You can do that using the trivial
support for bridge input image formats implemented by my series.
2) Specify in the bridge endpoint a 'bus_width' of <16>
3) In your atmel-hlcd get both the image format of the bridge (rgb888)
and parse the remote endpoint property 'bus_width' and get the <16>
value back.
4) Set the correct format in the atmel hlcd driver to accommodate a
bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565,
or are there other possible combinations I am missing?)

I would consider this better mostly because in this series you are
creating a semantic for the whole DRM subsystem on the 'bus_width'
property, where numerical values as '12', '16' etc are arbitrary tied
to the selection of a media bus format. At least you should use a
common set of defines [1] between the device tree and the driver,
but this looks anyway fragile imho.

Have I maybe missed some parts of the problem you are trying to solve
here?

Thank you
   j

[1] drm: bridge: Add support for static image formats
https://lwn.net/Articles/752296/
[2] include/uapi/linux/media-bus-format.h
> Anyway, this series solves some real issues for my HW.
>
> Cheers,
> Peter
>
> Changes since v2   https://lkml.org/lkml/2018/4/17/385
> - patch 2/7 fixed spelling and added an example
> - patch 4/7 parse the DT up front and store the result indexed by encoder
> - old patch 5/6 and 6/6 dropped
> - patch 5-7/7 are new and makes the tda998x driver a drm_bridge
>
> Changes since v1   https://lkml.org/lkml/2018/4/9/294
> - added reviewed-by from Rob to patch 1/6
> - patch 2/6 changed so that the bus format override is in the endpoint
>   DT node, and follows the binding of media video-interfaces.
> - patch 3/6 is new, it adds drm_of_media_bus_fmt which parses above
>   media video-interface binding (partially).
> - patch 4/6 now makes use of the above helper (and also fixes problems
>   with the 3/5 patch from v1 when no override was specified).
> - do not mention unrelated connector display_info details in the cover
>   letter and commit messages.
>
> [1]
> "Bridge" series v2   https://lkml.org/lkml/2018/3/26/610
> "Bridge" series v1   https://lkml.org/lkml/2018/3/17/221
>
> Peter Rosin (7):
>   dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
>   dt-bindings: display: atmel: optional video-interface of endpoints
>   drm: of: introduce drm_of_media_bus_fmt
>   drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
>   drm/i2c: tda998x: find the drm_device via the drm_connector
>   drm/i2c: tda998x: split encoder and component functions from the work
>   drm/i2c: tda998x: register as a drm bridge
>
>  .../devicetree/bindings/display/atmel/hlcdc-dc.txt |  26 +++
>  .../bindings/display/bridge/lvds-transmitter.txt   |   8 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  

RE: [Intel-gfx] [PATCH v5 1/2] drm: content-type property for HDMI connector

[Lisovskiy, Stanislav]

From: Daniel Vetter [daniel.vet...@ffwll.ch] on behalf of Daniel Vetter 
[dan...@ffwll.ch]

> The property documentation to tie all the bits together (property, helper,
> internals) is missing. It should be in

> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties

> Probably want to start with an intro-paragraph for HDMI properties
> (someone should document the broadcast prop too eventually).

> Pls also make sure the resulting docs look pretty and that it's all
> nicely hyperlink:

>$ make htmldocs

Thank you for your feedback. The thing is that I actually looked into docs,
but I think there should have been already some HDMI specific property 
documentation,
because this one is actually not a standard connector property, so I've added 
it only to

https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#existing-kms-properties 
table
as optional.
I think it might be a bit misleading, if I add that one to standard connector 
properties,
there are probably should be created some HDMI specific property chapter then, 
as there
are already plenty of HDMI specific ones(force audio, broadcast rgb, aspect 
ratio).

Shouldn't it then go in a separate patch may be? Because this work is surely 
needed, however
goes a bit out of scope of this patch.

Best Regards,

Lisovskiy Stanislav

> ---
>  Documentation/gpu/kms-properties.csv |  1 +
>  drivers/gpu/drm/drm_atomic.c | 17 ++
>  drivers/gpu/drm/drm_connector.c  | 51 
>  drivers/gpu/drm/drm_edid.c   |  2 ++
>  include/drm/drm_connector.h  | 18 ++
>  include/drm/drm_mode_config.h|  5 +++
>  include/uapi/drm/drm_mode.h  |  7 
>  7 files changed, 101 insertions(+)
>
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 6b28b014cb7d..a91c9211b8d6 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
> Values,Object attached,De
>  ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property 
> to suggest an X offset for a connector
>  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest 
> an Y offset for a connector
>  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
> }",Connector,TDB
> +,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"", 
> ""Cinema"", ""Game"" }",Connector,TBD
>  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
> set, the hardware will be programmed with the result of the multiplication of 
> CTM by the limited range matrix to ensure the pixels normaly in the range 
> 0..1.0 are remapped to the range 16/255..235/255."
>  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
>  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
> etc.",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7d25c42f22db..479499f5848e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->link_status = val;
>   } else if (property == config->aspect_ratio_property) {
>   state->picture_aspect_ratio = val;
> + } else if (property == config->content_type_property) {
> + /*
> +  * Lowest two bits of content_type property control
> +  * content_type, bit 2 controls itc bit.
> +  * It was decided to have a single property called
> +  * content_type, instead of content_type and itc.
> +  */
> + state->content_type = val & 3;
> + state->it_content = val >> 2;
>   } else if (property == connector->scaling_mode_property) {
>   state->scaling_mode = val;
>   } else if (property == connector->content_protection_property) {
> @@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->link_status;
>   } else if (property == config->aspect_ratio_property) {
>   *val = state->picture_aspect_ratio;
> + } else if (property == config->content_type_property) {
> + /*
> +  * Lowest two bits of content_type property control
> +  * content_type, bit 2 controls itc bit.
> +  * It was decided to have a single property called
> +  * content_type, instead of content_type and itc.
> +  */
> + *val = state->content_type | (state->it_content << 2);
>   } else if (property == connector->scaling_mode_property) {
>   *val = 

Re: [PATCH v2 4/4] qxl: drop dummy functions

[Daniel Vetter]

On Fri, Apr 20, 2018 at 09:19:04AM +0200, Gerd Hoffmann wrote:
> These days drm core checks function pointers everywhere before calling
> them.  So we can drop a bunch of dummy functions now.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/qxl/qxl_display.c | 50 
> ---
>  1 file changed, 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 06ee00b486..af6e52af5f 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -456,13 +456,6 @@ qxl_framebuffer_init(struct drm_device *dev,
>   return 0;
>  }
>  
> -static bool qxl_crtc_mode_fixup(struct drm_crtc *crtc,
> -   const struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode)
> -{
> - return true;
> -}
> -
>  static void qxl_crtc_atomic_enable(struct drm_crtc *crtc,
>  struct drm_crtc_state *old_state)
>  {
> @@ -476,7 +469,6 @@ static void qxl_crtc_atomic_disable(struct drm_crtc *crtc,
>  }
>  
>  static const struct drm_crtc_helper_funcs qxl_crtc_helper_funcs = {
> - .mode_fixup = qxl_crtc_mode_fixup,
>   .atomic_flush = qxl_crtc_atomic_flush,
>   .atomic_enable = qxl_crtc_atomic_enable,
>   .atomic_disable = qxl_crtc_atomic_disable,
> @@ -620,12 +612,6 @@ static void qxl_primary_atomic_disable(struct drm_plane 
> *plane,
>   }
>  }
>  
> -static int qxl_plane_atomic_check(struct drm_plane *plane,
> -   struct drm_plane_state *state)
> -{
> - return 0;
> -}
> -
>  static void qxl_cursor_atomic_update(struct drm_plane *plane,
>struct drm_plane_state *old_state)
>  {
> @@ -831,7 +817,6 @@ static const uint32_t qxl_cursor_plane_formats[] = {
>  };
>  
>  static const struct drm_plane_helper_funcs qxl_cursor_helper_funcs = {
> - .atomic_check = qxl_plane_atomic_check,
>   .atomic_update = qxl_cursor_atomic_update,
>   .atomic_disable = qxl_cursor_atomic_disable,
>   .prepare_fb = qxl_plane_prepare_fb,
> @@ -956,28 +941,6 @@ static int qdev_crtc_init(struct drm_device *dev, int 
> crtc_id)
>   return r;
>  }
>  
> -static void qxl_enc_dpms(struct drm_encoder *encoder, int mode)
> -{
> - DRM_DEBUG("\n");
> -}
> -
> -static void qxl_enc_prepare(struct drm_encoder *encoder)
> -{
> - DRM_DEBUG("\n");
> -}
> -
> -static void qxl_enc_commit(struct drm_encoder *encoder)
> -{
> - DRM_DEBUG("\n");
> -}
> -
> -static void qxl_enc_mode_set(struct drm_encoder *encoder,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> - DRM_DEBUG("\n");
> -}
> -
>  static int qxl_conn_get_modes(struct drm_connector *connector)
>  {
>   unsigned pwidth = 1024;
> @@ -1023,10 +986,6 @@ static struct drm_encoder *qxl_best_encoder(struct 
> drm_connector *connector)
>  
>  
>  static const struct drm_encoder_helper_funcs qxl_enc_helper_funcs = {

Hm, I thought even the vtable itself is optional? We do have tons of if
(!funcs) checks all over the place at least.


> - .dpms = qxl_enc_dpms,
> - .prepare = qxl_enc_prepare,
> - .mode_set = qxl_enc_mode_set,
> - .commit = qxl_enc_commit,
>  };
>  
>  static const struct drm_connector_helper_funcs qxl_connector_helper_funcs = {
> @@ -1059,14 +1018,6 @@ static enum drm_connector_status qxl_conn_detect(
>: connector_status_disconnected;
>  }
>  
> -static int qxl_conn_set_property(struct drm_connector *connector,
> -struct drm_property *property,
> -uint64_t value)
> -{
> - DRM_DEBUG("\n");
> - return 0;
> -}
> -
>  static void qxl_conn_destroy(struct drm_connector *connector)
>  {
>   struct qxl_output *qxl_output =
> @@ -1081,7 +1032,6 @@ static const struct drm_connector_funcs 
> qxl_connector_funcs = {
>   .dpms = drm_helper_connector_dpms,
>   .detect = qxl_conn_detect,
>   .fill_modes = drm_helper_probe_single_connector_modes,
> - .set_property = qxl_conn_set_property,

This is a legacy callback anyway. I kinda wonder whether we should have a
bunch of WARN_ON checks for this, so that atomic drivers don't have these
hanging around anymore.

Anyway, patch looks pretty.

Reviewed-by: Daniel Vetter 
>   .destroy = qxl_conn_destroy,
>   .reset = drm_atomic_helper_connector_reset,
>   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> -- 
> 2.9.3
> 
> ___
> 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