Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi Gerd,
On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann wrote:
> Also note that using a shadow framebuffer allows to decouple fbcon
> updates and scanout framebuffer updates. Can be used to speed up
> things without depending on the 2d blitter.
Assuming accesses to the shadow frame buffer are faster than accesses
to the scanout frame buffer. While this is true on modern hardware,
this is not the case on all hardware. Especially if the shadow frame
buffer has a higher depth (XRGB) than the scanout frame buffer
(e.g. Cn)...
The funny thing is that the systems we are interested in, once used
to be known for their graphics capabilities and/or performance...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On 1/18/22 07:11, Gerd Hoffmann wrote:
> On Mon, Jan 17, 2022 at 02:29:47PM +0100, Geert Uytterhoeven wrote:
>> Hi Gerd,
>>
>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann wrote:
b) to include new drivers (for old hardware) if they arrive (probably
happens rarely but there can be).
I know of at least one driver which won't be able to support DRM
>>>
>>> Hmm? I seriously doubt that. There is always the option to use a
>>> shadow framebuffer, then convert from standard drm formats to whatever
>>> esoteric pixel format your hardware expects.
>>>
>>> Been there, done that. Have a look at the cirrus driver. The physical
>>> hardware was designed in the early 90-ies, almost 30 years ago. These
>>> days it exists in virtual form only (qemu emulates it). Thanks to the
>>> drm driver it runs wayland just fine even though it has a bunch of
>>> constrains dictated by the hardware design.
>>
>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB)
>> modes only. The Cirrus fbdev driver also supports mochrome and 256
>> color modes.
>>
>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.
>
> Adding that to the cirrus driver shouldn't be hard. I'm wondering
> whenever there are any userspace apps which would actually use that
> though.
The discussion is not about userspace apps.
It's about the case, that if existing fbdev drivers should be converted to
DRM, then they are currently required to run in TrueColor. Some of those
cards/drivers
don't support TrueColor (which is problem #1), and even if they do, then
only with their existing 2D bitblt acceleration they are somewhat
performance-wise
useable as framebuffer console (problem #2).
So, if DRM would natively support other formats, then it's not hard to
convert them to DRM.
Helge
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On 1/18/22 07:29, Gerd Hoffmann wrote: >> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM >> is >> currently unaccelerated and bound to Truecolour modes only, > > Yes. Adding support for formats beside argb to the drm fbcon > emulation shouldn't be that much of a problem though. Really? Assuming a graphic card which runs with only 256 colors framebuffer is easily supported by DRM, and you can use fbcon without using lots of memcpy()? > Acceleration is harder. The scroll acceleration had issues nobody > addressed for years, and on modern hardware it is simply not used, which > is probably the reason nobody stepped up fixing things and it ended up > being dropped. The DRM layer doesn't use scroll acceleration. More than 30 other existing fbdev drivers use it. > Bringing it back is much more work than just reverting the commits removing > it. Reverting those commits have no effect on DRM's usage of fbcon. But reverting those commits bring back scroll acceleration for all others. I'm trying to find out which patches did apparently fixed such issues for the REDRAW case. If you have a pointer it would be helpful. > Also note that using a shadow framebuffer allows to decouple fbcon > updates and scanout framebuffer updates. Can be used to speed up > things without depending on the 2d blitter. Not on older hardware. Helge
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Mon, 17 Jan 2022 19:47:39 +0100 Sven Schnelle wrote: > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > a dmesg with 919 lines one the text console took about 2s to display. In > x11, i measure 22ms. This might be unfair because encoding might be > different, but i cannot confirm the 'memcpy' is faster than hardware > blitting' point. I think if that would be the case, no-one would care > about 2D acceleration. I think that is an extremely unfair comparison, because a graphical terminal app is not going to render every line of text streamed to it. It probably renders only the final view alone if you simply run 'dmesg', skipping the first 800-900 lines completely. Maybe fbcon should do the same when presented with a flood of text, but I don't know how or why it works like it works. I assume in your two second test you actually see some scrolling (animation) rather than the final view? Or does it take 2 seconds just to update one screenful? I doubt your fbcon and terminal window had height of 919 lines? Thanks, pq pgp46JFfJQeNZ.pgp Description: OpenPGP digital signature
Re: [PATCH 3/4] drm/i915: add gtt misalignment test
On 2022-01-11 at 18:02:37 +, Robert Beckett wrote:
> add test to check handling of misaligned offsets and sizes
Bob, This needs the rebase. I have rebased the other three patches of
the series..
Meanwhile i will review the changes.
Ram.
>
> Signed-off-by: Robert Beckett
> ---
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 130 ++
> 1 file changed, 130 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index fea031b4ec4f..28de0b333835 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -22,10 +22,12 @@
> *
> */
>
> +#include "gt/intel_gtt.h"
> #include
> #include
>
> #include "gem/i915_gem_context.h"
> +#include "gem/i915_gem_region.h"
> #include "gem/selftests/mock_context.h"
> #include "gt/intel_context.h"
> #include "gt/intel_gpu_commands.h"
> @@ -1066,6 +1068,120 @@ static int shrink_boom(struct i915_address_space *vm,
> return err;
> }
>
> +static int misaligned_case(struct i915_address_space *vm, struct
> intel_memory_region *mr,
> +u64 addr, u64 size, unsigned long flags)
> +{
> + struct drm_i915_gem_object *obj;
> + struct i915_vma *vma;
> + int err = 0;
> + u64 expected_vma_size, expected_node_size;
> +
> + obj = i915_gem_object_create_region(mr, size, 0, 0);
> + if (IS_ERR(obj))
> + return PTR_ERR(obj);
> +
> + vma = i915_vma_instance(obj, vm, NULL);
> + if (IS_ERR(vma)) {
> + err = PTR_ERR(vma);
> + goto err_put;
> + }
> +
> + err = i915_vma_pin(vma, 0, 0, addr | flags);
> + if (err)
> + goto err_put;
> + i915_vma_unpin(vma);
> +
> + if (!drm_mm_node_allocated(&vma->node)) {
> + err = -EINVAL;
> + goto err_put;
> + }
> +
> + if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
> + err = -EINVAL;
> + goto err_put;
> + }
> +
> + expected_vma_size = round_up(size, 1 << (ffs(vma->page_sizes.gtt) - 1));
> + expected_node_size = expected_vma_size;
> +
> + if (IS_DG2(vm->i915) && i915_gem_object_is_lmem(obj)) {
> + /* dg2 should expand lmem node to 2MB */
> + expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
> + expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
> + }
> +
> + if (vma->size != expected_vma_size || vma->node.size !=
> expected_node_size) {
> + err = i915_vma_unbind(vma);
> + err = -EBADSLT;
> + goto err_put;
> + }
> +
> + err = i915_vma_unbind(vma);
> + if (err)
> + goto err_put;
> +
> + GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
> +
> +err_put:
> + i915_gem_object_put(obj);
> + cleanup_freed_objects(vm->i915);
> + return err;
> +}
> +
> +static int misaligned_pin(struct i915_address_space *vm,
> + u64 hole_start, u64 hole_end,
> + unsigned long end_time)
> +{
> + struct intel_memory_region *mr;
> + enum intel_region_id id;
> + unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
> + int err = 0;
> + u64 hole_size = hole_end - hole_start;
> +
> + if (i915_is_ggtt(vm))
> + flags |= PIN_GLOBAL;
> +
> + for_each_memory_region(mr, vm->i915, id) {
> + u64 min_alignment = i915_vm_min_alignment(vm, id);
> + u64 size = min_alignment;
> + u64 addr = round_up(hole_start + (hole_size / 2),
> min_alignment);
> +
> + /* we can't test < 4k alignment due to flags being encoded in
> lower bits */
> + if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
> + err = misaligned_case(vm, mr, addr + (min_alignment /
> 2), size, flags);
> + /* misaligned should error with -EINVAL*/
> + if (!err)
> + err = -EBADSLT;
> + if (err != -EINVAL)
> + return err;
> + }
> +
> + /* test for vma->size expansion to min page size */
> + err = misaligned_case(vm, mr, addr, PAGE_SIZE, flags);
> + if (min_alignment > hole_size) {
> + if (!err)
> + err = -EBADSLT;
> + else if (err == -ENOSPC)
> + err = 0;
> + }
> + if (err)
> + return err;
> +
> + /* test for intermediate size not expanding vma->size for large
> alignments */
> + err = misaligned_case(vm, mr, addr, size / 2, flags);
> + if (min_alignment > hole_size) {
> + if (!err)
> + err = -EBADSLT;
> + else if (err == -ENOSPC)
> + err = 0;
> + }
> +
[RFC PATCH v4 0/3] Add support modifiers for drivers whose planes only support linear layout
Some drivers whose planes only support linear layout fb do not support format modifiers. These drivers should support modifiers, however the DRM core should handle this rather than open-coding in every driver. In this patch series, these drivers expose format modifiers based on the following suggestion[1]. On Thu, Nov 18, 2021 at 01:02:11PM +, Daniel Stone wrote: > I think the best way forward here is: > - add a new mode_config.cannot_support_modifiers flag, and enable > this in radeon (plus any other drivers in the same boat) > - change drm_universal_plane_init() to advertise the LINEAR modifier > when NULL is passed as the modifier list (including installing a > default .format_mod_supported hook) > - remove the mode_config.allow_fb_modifiers hook and always > advertise modifier support, unless > mode_config.cannot_support_modifiers is set [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20190509054518.10781-1-e...@igel.co.jp/#24602575 v4: * modify documentation for fb_modifiers_not_supported flag in kerneldoc v3: https://www.spinics.net/lists/dri-devel/msg329102.html * change the order as follows: 1. add fb_modifiers_not_supported flag 2. add default modifiers 3. remove allow_fb_modifiers flag * add a conditional disable in amdgpu_dm_plane_init() v2: https://www.spinics.net/lists/dri-devel/msg328939.html * rebase to the latest master branch (5.16.0+) + "drm/plane: Make format_mod_supported truly optional" patch [2] [2] https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3 v1: https://www.spinics.net/lists/dri-devel/msg327352.html * The initial patch set Tomohito Esaki (3): drm: introduce fb_modifiers_not_supported flag in mode_config drm: add support modifiers for drivers whose planes only support linear layout drm: remove allow_fb_modifiers drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++--- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 ++ drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 ++ drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 + drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 ++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++ drivers/gpu/drm/drm_framebuffer.c | 6 ++--- drivers/gpu/drm/drm_ioctl.c | 2 +- drivers/gpu/drm/drm_plane.c | 22 +-- drivers/gpu/drm/nouveau/nouveau_display.c | 6 +++-- drivers/gpu/drm/radeon/radeon_display.c | 2 ++ .../gpu/drm/selftests/test-drm_framebuffer.c | 1 - include/drm/drm_mode_config.h | 18 +-- include/drm/drm_plane.h | 3 +++ 14 files changed, 43 insertions(+), 33 deletions(-) -- 2.25.1
[RFC PATCH v4 1/3] drm: introduce fb_modifiers_not_supported flag in mode_config
If only linear modifier is advertised, since there are many drivers that
only linear supported, the DRM core should handle this rather than
open-coding in every driver. However, there are legacy drivers such as
radeon that do not support modifiers but infer the actual layout of the
underlying buffer. Therefore, a new flag fb_modifiers_not_supported is
introduced for these legacy drivers, and allow_fb_modifiers is replaced
with this new flag.
Signed-off-by: Tomohito Esaki
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 ++
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 ++
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 ++
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
drivers/gpu/drm/drm_framebuffer.c | 6 +++---
drivers/gpu/drm/drm_ioctl.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 6 --
drivers/gpu/drm/radeon/radeon_display.c | 2 ++
include/drm/drm_mode_config.h | 10 ++
11 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 82011e75ed85..edbb30d47b8c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -954,7 +954,7 @@ static int amdgpu_display_verify_sizes(struct
amdgpu_framebuffer *rfb)
int ret;
unsigned int i, block_width, block_height, block_size_log2;
- if (!rfb->base.dev->mode_config.allow_fb_modifiers)
+ if (rfb->base.dev->mode_config.fb_modifiers_not_supported)
return 0;
for (i = 0; i < format_info->num_planes; ++i) {
@@ -1141,7 +1141,7 @@ int amdgpu_display_framebuffer_init(struct drm_device
*dev,
if (ret)
return ret;
- if (!dev->mode_config.allow_fb_modifiers) {
+ if (dev->mode_config.fb_modifiers_not_supported) {
drm_WARN_ONCE(dev, adev->family >= AMDGPU_FAMILY_AI,
"GFX9+ requires FB check based on format
modifier\n");
ret = check_tiling_flags_gfx6(rfb);
@@ -1149,7 +1149,7 @@ int amdgpu_display_framebuffer_init(struct drm_device
*dev,
return ret;
}
- if (dev->mode_config.allow_fb_modifiers &&
+ if (!dev->mode_config.fb_modifiers_not_supported &&
!(rfb->base.flags & DRM_MODE_FB_MODIFIERS)) {
ret = convert_tiling_flags_to_modifier(rfb);
if (ret) {
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index d1570a462a51..fb61c0814115 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2798,6 +2798,8 @@ static int dce_v10_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
+ adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
+
adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
r = amdgpu_display_modeset_create_props(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 18a7b3bd633b..17942a11366d 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2916,6 +2916,8 @@ static int dce_v11_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
+ adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
+
adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
r = amdgpu_display_modeset_create_props(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index c7803dc2b2d5..2ec99ec8e1a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2674,6 +2674,7 @@ static int dce_v6_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.max_height = 16384;
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
+ adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
r = amdgpu_display_modeset_create_props(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 8318ee8339f1..de11fbe5aba2 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -2695,6 +2695,8 @@ static int dce_v8_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
+ adev_to_drm(adev)->mode
[RFC PATCH v4 2/3] drm: add support modifiers for drivers whose planes only support linear layout
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers.
Signed-off-by: Tomohito Esaki
---
drivers/gpu/drm/drm_plane.c | 15 ---
include/drm/drm_plane.h | 3 +++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index deeec60a3315..5aa7e241971e 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -237,6 +237,10 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
const char *name, va_list ap)
{
struct drm_mode_config *config = &dev->mode_config;
+ const uint64_t default_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+ };
unsigned int format_modifier_count = 0;
int ret;
@@ -277,6 +281,11 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
format_modifier_count++;
+ } else {
+ if (!dev->mode_config.fb_modifiers_not_supported) {
+ format_modifiers = default_modifiers;
+ format_modifier_count = 1;
+ }
}
/* autoset the cap and check for consistency across all planes */
@@ -341,7 +350,7 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
drm_object_attach_property(&plane->base, config->prop_src_h, 0);
}
- if (config->allow_fb_modifiers)
+ if (format_modifier_count)
create_in_format_blob(dev, plane);
return 0;
@@ -368,8 +377,8 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
* drm_universal_plane_init() to let the DRM managed resource infrastructure
* take care of cleanup and deallocation.
*
- * Drivers supporting modifiers must set @format_modifiers on all their planes,
- * even those that only support DRM_FORMAT_MOD_LINEAR.
+ * For drivers supporting modifiers, all planes will advertise
+ * DRM_FORMAT_MOD_LINEAR support, if @format_modifiers is not set.
*
* Returns:
* Zero on success, error code on failure.
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 0c1102dc4d88..cad641b1f797 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -803,6 +803,9 @@ void *__drmm_universal_plane_alloc(struct drm_device *dev,
*
* The @drm_plane_funcs.destroy hook must be NULL.
*
+ * For drivers supporting modifiers, all planes will advertise
+ * DRM_FORMAT_MOD_LINEAR support, if @format_modifiers is not set.
+ *
* Returns:
* Pointer to new plane, or ERR_PTR on failure.
*/
--
2.25.1
[RFC PATCH v4 3/3] drm: remove allow_fb_modifiers
The allow_fb_modifiers flag is unnecessary since it has been replaced
with cannot_support_modifiers flag.
Signed-off-by: Tomohito Esaki
---
drivers/gpu/drm/drm_plane.c | 9 -
drivers/gpu/drm/selftests/test-drm_framebuffer.c | 1 -
include/drm/drm_mode_config.h| 16
3 files changed, 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 5aa7e241971e..89a3d044ab59 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -288,15 +288,6 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
}
}
- /* autoset the cap and check for consistency across all planes */
- if (format_modifier_count) {
- drm_WARN_ON(dev, !config->allow_fb_modifiers &&
- !list_empty(&config->plane_list));
- config->allow_fb_modifiers = true;
- } else {
- drm_WARN_ON(dev, config->allow_fb_modifiers);
- }
-
plane->modifier_count = format_modifier_count;
plane->modifiers = kmalloc_array(format_modifier_count,
sizeof(format_modifiers[0]),
diff --git a/drivers/gpu/drm/selftests/test-drm_framebuffer.c
b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
index 61b44d3a6a61..f6d66285c5fc 100644
--- a/drivers/gpu/drm/selftests/test-drm_framebuffer.c
+++ b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
@@ -323,7 +323,6 @@ static struct drm_device mock_drm_device = {
.max_width = MAX_WIDTH,
.min_height = MIN_HEIGHT,
.max_height = MAX_HEIGHT,
- .allow_fb_modifiers = true,
.funcs = &mock_config_funcs,
},
};
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index b73af96e2c96..c41df5932a6b 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -917,22 +917,6 @@ struct drm_mode_config {
*/
bool async_page_flip;
- /**
-* @allow_fb_modifiers:
-*
-* Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
-* Note that drivers should not set this directly, it is automatically
-* set in drm_universal_plane_init().
-*
-* IMPORTANT:
-*
-* If this is set the driver must fill out the full implicit modifier
-* information in their &drm_mode_config_funcs.fb_create hook for legacy
-* userspace which does not set modifiers. Otherwise the GETFB2 ioctl is
-* broken for modifier aware userspace.
-*/
- bool allow_fb_modifiers;
-
/**
* @fb_modifiers_not_supported:
*
--
2.25.1
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Mon, 17 Jan 2022, Helge Deller wrote: > On 1/17/22 22:40, Jani Nikula wrote: >> On Mon, 17 Jan 2022, Thomas Zimmermann wrote: >>> Seems like few people read linux-fbdev these days. >> >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel >> also? > > Doesn't seem like much traffic - which IMHO is OK for such a tree with > mostly just maintenance patches. > >> Do we still need a separate linux-fbdev mailing list at all? > > Yes. I want to have it seperate of dri-devel. > Actually I'd prefer to drop dri-devel from the list where patches > for fbdev are sent... Disagreed. If anything, this thread shows we can't have fbdev and drm in silos of their own. Also, if the patches continue to get merged through drm-misc, they need to be sent to dri-devel. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi Jani,
On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula wrote:
> On Mon, 17 Jan 2022, Helge Deller wrote:
> > On 1/17/22 22:40, Jani Nikula wrote:
> >> On Mon, 17 Jan 2022, Thomas Zimmermann wrote:
> >>> Seems like few people read linux-fbdev these days.
> >>
> >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> >> also?
> >
> > Doesn't seem like much traffic - which IMHO is OK for such a tree with
> > mostly just maintenance patches.
> >
> >> Do we still need a separate linux-fbdev mailing list at all?
> >
> > Yes. I want to have it seperate of dri-devel.
> > Actually I'd prefer to drop dri-devel from the list where patches
> > for fbdev are sent...
>
> Disagreed. If anything, this thread shows we can't have fbdev and drm in
> silos of their own.
Unless DRM drops fbdev support. Isn't that the long-term plan anyway?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hello Daniel, On 1/17/22 16:00, Daniel Vetter wrote: > On Mon, Jan 17, 2022 at 1:16 PM Helge Deller wrote: >> On 1/17/22 11:02, Daniel Vetter wrote: >>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller wrote: The fbdev layer is orphaned, but seems to need some care. So I'd like to step up as new maintainer. Signed-off-by: Helge Deller diff --git a/MAINTAINERS b/MAINTAINERS index 5d0cd537803a..ce47dbc467cc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html F: arch/x86/math-emu/ FRAMEBUFFER LAYER -L: dri-devel@lists.freedesktop.org +M: Helge Deller L: linux-fb...@vger.kernel.org -S: Orphan >>> >>> Maybe don't rush maintainer changes in over the w/e without even bothering >>> to get any input from the people who've been maintaining it before. >>> >>> Because the status isn't entirely correct, fbdev core code and fbcon and >>> all that has been maintained, but in bugfixes only mode. And there's very >>> solid&important reasons to keep merging these patches through a drm tree, >>> because that's where all the driver development happens, and hence also >>> all the testing (e.g. the drm test suite has some fbdev tests - the only >>> automated ones that exist to my knowledge - and we run them in CI). So >>> moving that into an obscure new tree which isn't even in linux-next yet is >>> no good at all. >>> >>> Now fbdev driver bugfixes is indeed practically orphaned and I very much >>> welcome anyone stepping up for that, but the simplest approach there would >>> be to just get drm-misc commit rights and push the oddball bugfix in there >>> directly. But also if you want to do your own pull requests to Linus for >>> that I don't care and there's really no interference I think, so >>> whatever floats. >>> >>> But any code that is relevant for drm drivers really needs to go in through >>> drm trees, nothing else makes much sense. >>> >>> I guess you're first action as newly minted fbdev maintainer is going to be >>> to >>> clean up the confusion you just created. >> >> Most of my machines depend on a working fbdev layer since drm isn't (and >> probably >> -due to technical requirements of DRM- won't be) available for those. >> So, since the fbdev drivers were marked orphaned, I decided to step up as >> maintainer. >> >> I see your point that at least the fbdev core code and fbcon are shared >> between DRM and fbdev. >> For me it's really not important to drive any patches through a seperate >> tree, so >> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the >> way, >> adding my tree to for-next was on my todo list...) >> >> What's important for me though is, to keep fbdev actively maintained, which >> means: >> a) to get fixes which were posted to fbdev mailing list applied if they are >> useful & correct, > > Yeah it'd be great if we have that, for a while Bart took care of > these, but had to step down again. drm-misc is maintained with the dim > scrip suite, which comes with docs and bash completion and everything. > Good starting pointer is here: > > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html > > Process for getting commit rights is documented here: > > https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc > > But there's a pile more. I think once we've set that up and got it > going we can look at the bigger items. Some of them are fairly > low-hanging fruit, but the past 5+ years absolutely no one bothered to > step up and sort them out. Other problem areas in fbdev are extremely > hard to fix properly, without only doing minimal security-fixes only > support, so fair warning there. I think a good starting point would be > to read the patches and discussions for some of the things you've > reverted in your tree. > > Anyway I hope this gets you started, and hopefully after a minor > detour: Welcome to dri-devel, we're happy to take any help we can get, > there's lots to do! Thanks for this info, Daniel! After reading those docs I've decided not to join dri-devel and keep my existing linux-fbdev tree at: https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git The linux-fbdev is a low-volume mailing list with mostly small bug fixes or enhancements for the fbdev drivers. Those patches usually don't affect DRM. I'm expecting that non-trivial changes which may affect fbdev will be sent to the linux-fbdev mailing list, same way as I will of course send any patches which might affect DRM to dri-devel. My git tree is wired up to the for-next pull chain, so in any way we would notice merge conflicts (which I believe will not happen). Cheers, Helge >> b) to include new drivers (for old hardware) if they arrive (probably >> happens rarely but there can be). >>I know of at least one driver which won't be able to su
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On 1/18/22 09:38, Jani Nikula wrote: > On Mon, 17 Jan 2022, Helge Deller wrote: >> On 1/17/22 22:40, Jani Nikula wrote: >>> On Mon, 17 Jan 2022, Thomas Zimmermann wrote: Seems like few people read linux-fbdev these days. >>> >>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel >>> also? >> >> Doesn't seem like much traffic - which IMHO is OK for such a tree with >> mostly just maintenance patches. >> >>> Do we still need a separate linux-fbdev mailing list at all? >> >> Yes. I want to have it seperate of dri-devel. >> Actually I'd prefer to drop dri-devel from the list where patches >> for fbdev are sent... > > Disagreed. If anything, this thread shows we can't have fbdev and drm in > silos of their own. Patches to fbdev usually don't affect DRM. Patches which affect DRM needs to through to dri-devel. In addition this would take the burden of the dri-developers to receive unrelated fbdev driver updates and patches. > Also, if the patches continue to get merged through drm-misc, they need > to be sent to dri-devel. Helge
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On 2022-01-17 19:47, Sven Schnelle wrote: > >> * There's no new development in fbdev and there are no new >>drivers. Everyone works on DRM, which is better in most >>regards. The consequence is that userspace is slowly loosing the >> ability to use fbdev. > > That might be caused by the fact that no new drivers are accepted for > fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last > year which was rejected for inclusion into fbdev[1]. > > Based on your recommendation i re-wrote the whole thing in DRM. This > works but has several drawbacks: > > - no modesetting. With fbdev, i can nicely switch resolutions with > fbset. That doesn't work, and i've been told that this is not supported[2] > > - It is *much* slower than fbset with hardware blitting. I would have to > dig out the numbers, but it's in the ratio of 1:15. The nice thing > with fbdev blitting is that i get an array of pixels and the > foreground/background colors all of these these pixels should have. > With the help of the hardware blitting, i can write 32 pixels at once > with every 32-bit transfer. > > With DRM, the closest i could find was DRM_FORMAT_C8, which means one > byte per pixel. So i can put 4 pixels into one 32-bit transfer. > > fbdev also clears the lines with hardware blitting, which is much > faster than clearing it with memcpy. > > Based on your recommendation i also verified that pci coalescing is > enabled. > > These numbers are with DRM's unnatural scrolling behaviour - it seems > to scroll several (text)lines at once if it takes to much time. I > guess if DRM would scroll line by line it would be even slower. > > If DRM would add those things - hardware clearing of memory regions, > hw blitting for text with a FG/BG color and modesetting i wouldn't > care about fbdev at all. But right now, it's working way faster for me. A DRM driver can implement the same fbdev acceleration hooks as an fbdev driver. (Most DRM drivers never bothered because the HW is more complex than traditional 2D accelerators, and can't safely be used under all circumstances where fbdev acceleration hooks could get called from. That's not an issue for a traditional 2D accelerator driver though) -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: [Intel-gfx] [PATCH v7 4/6] drm/i915: Use vma resources for async unbinding
Hi,
On Mon, 2022-01-17 at 21:07 +, Robert Beckett wrote:
>
>
> On 10/01/2022 17:22, Thomas Hellström wrote:
> > Implement async (non-blocking) unbinding by not syncing the vma
> > before
> > calling unbind on the vma_resource.
> > Add the resulting unbind fence to the object's dma_resv from where
> > it is
> > picked up by the ttm migration code.
> > Ideally these unbind fences should be coalesced with the migration
> > blit
> > fence to avoid stalling the migration blit waiting for unbind, as
> > they
> > can certainly go on in parallel, but since we don't yet have a
> > reasonable data structure to use to coalesce fences and attach the
> > resulting fence to a timeline, we defer that for now.
> >
> > Note that with async unbinding, even while the unbind waits for the
> > preceding bind to complete before unbinding, the vma itself might
> > have been
> > destroyed in the process, clearing the vma pages. Therefore we can
> > only allow async unbinding if we have a refcounted sg-list and keep
> > a
> > refcount on that for the vma resource pages to stay intact until
> > binding occurs. If this condition is not met, a request for an
> > async
> > unbind is diverted to a sync unbind.
> >
> > v2:
> > - Use a separate kmem_cache for vma resources for now to isolate
> > their
> > memory allocation and aid debugging.
> > - Move the check for vm closed to the actual unbinding thread.
> > Regardless
> > of whether the vm is closed, we need the unbind fence to
> > properly wait
> > for capture.
> > - Clear vma_res::vm on unbind and update its documentation.
> > v4:
> > - Take cache coloring into account when searching for vma resources
> > pending unbind. (Matthew Auld)
> > v5:
> > - Fix timeout and error check in
> > i915_vma_resource_bind_dep_await().
> > - Avoid taking a reference on the object for async binding if
> > async unbind capable.
> > - Fix braces around a single-line if statement.
> > v6:
> > - Fix up the cache coloring adjustment. (Kernel test robot
> > )
> > - Don't allow async unbinding if the vma_res pages are not the same
> > as
> > the object pages. (Matthew Auld)
> > v7:
> > - s/unsigned long/u64/ in a number of places (Matthew Auld)
> >
> > Signed-off-by: Thomas Hellström
> > Reviewed-by: Matthew Auld
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +-
> > drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_gtt.c | 4 +
> > drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_gem.c | 12 +-
> > drivers/gpu/drm/i915/i915_module.c | 3 +
> > drivers/gpu/drm/i915/i915_vma.c | 205 +--
> > drivers/gpu/drm/i915/i915_vma.h | 3 +-
> > drivers/gpu/drm/i915/i915_vma_resource.c | 354
> > +--
> > drivers/gpu/drm/i915/i915_vma_resource.h | 48 +++
> > 11 files changed, 579 insertions(+), 67 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> > index 8653855d808b..1de306c03aaf 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> > @@ -142,7 +142,16 @@ int i915_ttm_move_notify(struct
> > ttm_buffer_object *bo)
> > struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> > int ret;
> >
> > - ret = i915_gem_object_unbind(obj,
> > I915_GEM_OBJECT_UNBIND_ACTIVE);
> > + /*
> > + * Note: The async unbinding here will actually transform
> > the
> > + * blocking wait for unbind into a wait before finally
> > submitting
> > + * evict / migration blit and thus stall the migration
> > timeline
> > + * which may not be good for overall throughput. We should
> > make
> > + * sure we await the unbind fences *after* the migration
> > blit
> > + * instead of *before* as we currently do.
> > + */
> > + ret = i915_gem_object_unbind(obj,
> > I915_GEM_OBJECT_UNBIND_ACTIVE |
> > + I915_GEM_OBJECT_UNBIND_ASYNC);
> > if (ret)
> > return ret;
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > index e49b6250c4b7..a1b2761bc16e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > @@ -142,7 +142,7 @@ void i915_ggtt_suspend_vm(struct
> > i915_address_space *vm)
> > continue;
> >
> > if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
> > {
> > - __i915_vma_evict(vma);
> > + __i915_vma_evict(vma, false);
> > drm_mm_remove_node(&vma->node);
> > }
> > }
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
> > b/drivers/gpu/drm/i915/gt/i
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On 1/18/22 09:41, Helge Deller wrote: > Hello Daniel, > > On 1/17/22 16:00, Daniel Vetter wrote: >> On Mon, Jan 17, 2022 at 1:16 PM Helge Deller wrote: >>> On 1/17/22 11:02, Daniel Vetter wrote: On Fri, Jan 14, 2022 at 7:18 PM Helge Deller wrote: > > The fbdev layer is orphaned, but seems to need some care. > So I'd like to step up as new maintainer. > > Signed-off-by: Helge Deller > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5d0cd537803a..ce47dbc467cc 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7583,11 +7583,12 @@ W: > http://floatingpoint.sourceforge.net/emulator/index.html > F: arch/x86/math-emu/ > > FRAMEBUFFER LAYER > -L: dri-devel@lists.freedesktop.org > +M: Helge Deller > L: linux-fb...@vger.kernel.org > -S: Orphan Maybe don't rush maintainer changes in over the w/e without even bothering to get any input from the people who've been maintaining it before. Because the status isn't entirely correct, fbdev core code and fbcon and all that has been maintained, but in bugfixes only mode. And there's very solid&important reasons to keep merging these patches through a drm tree, because that's where all the driver development happens, and hence also all the testing (e.g. the drm test suite has some fbdev tests - the only automated ones that exist to my knowledge - and we run them in CI). So moving that into an obscure new tree which isn't even in linux-next yet is no good at all. Now fbdev driver bugfixes is indeed practically orphaned and I very much welcome anyone stepping up for that, but the simplest approach there would be to just get drm-misc commit rights and push the oddball bugfix in there directly. But also if you want to do your own pull requests to Linus for that I don't care and there's really no interference I think, so whatever floats. But any code that is relevant for drm drivers really needs to go in through drm trees, nothing else makes much sense. I guess you're first action as newly minted fbdev maintainer is going to be to clean up the confusion you just created. >>> >>> Most of my machines depend on a working fbdev layer since drm isn't (and >>> probably >>> -due to technical requirements of DRM- won't be) available for those. >>> So, since the fbdev drivers were marked orphaned, I decided to step up as >>> maintainer. >>> >>> I see your point that at least the fbdev core code and fbcon are shared >>> between DRM and fbdev. >>> For me it's really not important to drive any patches through a seperate >>> tree, so >>> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the >>> way, >>> adding my tree to for-next was on my todo list...) >>> >>> What's important for me though is, to keep fbdev actively maintained, which >>> means: >>> a) to get fixes which were posted to fbdev mailing list applied if they are >>> useful & correct, >> >> Yeah it'd be great if we have that, for a while Bart took care of >> these, but had to step down again. drm-misc is maintained with the dim >> scrip suite, which comes with docs and bash completion and everything. >> Good starting pointer is here: >> >> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html >> >> Process for getting commit rights is documented here: >> >> https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc >> >> But there's a pile more. I think once we've set that up and got it >> going we can look at the bigger items. Some of them are fairly >> low-hanging fruit, but the past 5+ years absolutely no one bothered to >> step up and sort them out. Other problem areas in fbdev are extremely >> hard to fix properly, without only doing minimal security-fixes only >> support, so fair warning there. I think a good starting point would be >> to read the patches and discussions for some of the things you've >> reverted in your tree. >> >> Anyway I hope this gets you started, and hopefully after a minor >> detour: Welcome to dri-devel, we're happy to take any help we can get, >> there's lots to do! > > Thanks for this info, Daniel! > > After reading those docs I've decided not to join dri-devel and keep > my existing linux-fbdev tree at: > > https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > > The linux-fbdev is a low-volume mailing list with mostly small bug fixes > or enhancements for the fbdev drivers. Those patches usually don't affect DRM. > > I'm expecting that non-trivial changes which may affect fbdev will be sent to > the > linux-fbdev mailing list, same way as I will of course send any patches which > might affect DRM to dri-devel. > > My git tree is wired up to the for-next pull chain, so in any way we would > notice > merge conflicts (which I believe will not happen). To make it more clear:
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote: > On 1/18/22 07:29, Gerd Hoffmann wrote: > >> Please correct me if I'm wrong, but text-console emulation/scrolling on > >> DRM is > >> currently unaccelerated and bound to Truecolour modes only, > > > > Yes. Adding support for formats beside argb to the drm fbcon > > emulation shouldn't be that much of a problem though. > > Really? Assuming a graphic card which runs with only 256 colors framebuffer > is easily supported by DRM, and you can use fbcon without using lots of > memcpy()? Driver: programming a fixed color cube palette, then use RGB332. fbcon/fbdev emulation: RGB332 support must be added I think. But both argb888 and rgb565 are supported today, so it should not be hard to find the places where you have to add some code to handle RGB332 too. > > Acceleration is harder. The scroll acceleration had issues nobody > > addressed for years, and on modern hardware it is simply not used, which > > is probably the reason nobody stepped up fixing things and it ended up > > being dropped. > > The DRM layer doesn't use scroll acceleration. > More than 30 other existing fbdev drivers use it. Yes. The world shifted from 2d acceleration to 3d acceleration. Modern hardware simply has no classic blitter any more. Which is a problem when it comes to keeping scroll acceleration alive, it is already a very niche use case and it will only become worse ... > > Bringing it back is much more work than just reverting the commits removing > > it. > > Reverting those commits have no effect on DRM's usage of fbcon. > But reverting those commits bring back scroll acceleration for all others. > I'm trying to find out which patches did apparently fixed such issues > for the REDRAW case. If you have a pointer it would be helpful. IIRC the code had a bunch of races and syzkaller flagged problems. I didn't follow very closely though. take care, Gerd
[PATCH v4 1/4] drm/bridge: anx7625: send DPCD command to downstream
From: Xin Ji
Send DPCD command to downstream before anx7625 power down,
let downstream monitor enter into standby mode.
Signed-off-by: Xin Ji
Signed-off-by: Hsin-Yi Wang
---
v3->v4:
Use common DP_AUX_NATIVE_READ/WRITE
Previously in:
https://patchwork.kernel.org/project/dri-devel/patch/1f36f8bf0a48fb2bba17bacec23700e58c1d407d.1641891874.git@analogixsemi.com/
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 42 +++
drivers/gpu/drm/bridge/analogix/anx7625.h | 2 --
2 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 76662fce4ce61d..17b23940549a42 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -129,6 +129,23 @@ static int anx7625_reg_write(struct anx7625_data *ctx,
return ret;
}
+static int anx7625_reg_block_write(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
+{
+ int ret;
+ struct device *dev = &client->dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_write_i2c_block_data(client, reg_addr, len, buf);
+ if (ret < 0)
+ dev_err(dev, "write i2c block failed id=%x\n:%x",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
static int anx7625_write_or(struct anx7625_data *ctx,
struct i2c_client *client,
u8 offset, u8 mask)
@@ -214,8 +231,8 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
return 0;
}
-static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
-u32 address, u8 len, u8 *buf)
+static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx, u8 op,
+ u32 address, u8 len, u8 *buf)
{
struct device *dev = &ctx->client->dev;
int ret;
@@ -231,8 +248,7 @@ static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
addrm = (address >> 8) & 0xFF;
addrh = (address >> 16) & 0xFF;
- cmd = DPCD_CMD(len, DPCD_READ);
- cmd = ((len - 1) << 4) | 0x09;
+ cmd = DPCD_CMD(len, op);
/* Set command and length */
ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
@@ -246,6 +262,9 @@ static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
AP_AUX_ADDR_19_16, addrh);
+ if (op == DP_AUX_NATIVE_WRITE)
+ ret |= anx7625_reg_block_write(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_BUFF_START, len, buf);
/* Enable aux access */
ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
@@ -255,14 +274,17 @@ static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
return -EIO;
}
- usleep_range(2000, 2100);
-
ret = wait_aux_op_finish(ctx);
if (ret) {
dev_err(dev, "aux IO error: wait aux op finish.\n");
return ret;
}
+ /* Write done */
+ if (op == DP_AUX_NATIVE_WRITE)
+ return 0;
+
+ /* Read done, read out dpcd data */
ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
AP_AUX_BUFF_START, len, buf);
if (ret < 0) {
@@ -845,7 +867,7 @@ static int anx7625_hdcp_enable(struct anx7625_data *ctx)
}
/* Read downstream capability */
- anx7625_aux_dpcd_read(ctx, 0x68028, 1, &bcap);
+ anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_READ, 0x68028, 1, &bcap);
if (!(bcap & 0x01)) {
pr_warn("downstream not support HDCP 1.4, cap(%x).\n", bcap);
return 0;
@@ -918,6 +940,7 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
{
struct device *dev = &ctx->client->dev;
int ret;
+ u8 data;
DRM_DEV_DEBUG_DRIVER(dev, "stop dp output\n");
@@ -929,6 +952,11 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client, 0x08, 0x7f);
ret |= anx7625_video_mute_control(ctx, 1);
+
+ dev_dbg(dev, "notify downstream enter into standby\n");
+ /* Downstream monitor enter into standby mode */
+ data = 2;
+ ret |= anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1,
&data);
if (ret < 0)
DRM_DEV_ERROR(dev, "IO error : mute video fail\n");
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
b/drivers/gpu/drm/bridge/analogix/anx7625.h
index 56165f5b254c14..64a8ab56529404 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.h
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
@@ -242,8 +242,6 @@
#define AP_AUX_COMMAND 0x27 /* com+len */
#define
[PATCH v4 2/4] drm/bridge: anx7625: Convert to use devm_kzalloc
Use devm_kzalloc instead of kzalloc and drop kfree(). Let the memory
handled by driver detach.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Xin Ji
---
v2->v3: remove kfree() in anx7625_i2c_remove().
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 17b23940549a42..b7e3373994b480 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -2515,7 +2515,7 @@ static int anx7625_i2c_probe(struct i2c_client *client,
return -ENODEV;
}
- platform = kzalloc(sizeof(*platform), GFP_KERNEL);
+ platform = devm_kzalloc(dev, sizeof(*platform), GFP_KERNEL);
if (!platform) {
DRM_DEV_ERROR(dev, "fail to allocate driver data\n");
return -ENOMEM;
@@ -2527,7 +2527,7 @@ static int anx7625_i2c_probe(struct i2c_client *client,
if (ret) {
if (ret != -EPROBE_DEFER)
DRM_DEV_ERROR(dev, "fail to parse DT : %d\n", ret);
- goto free_platform;
+ return ret;
}
platform->client = client;
@@ -2552,7 +2552,7 @@ static int anx7625_i2c_probe(struct i2c_client *client,
if (!platform->hdcp_workqueue) {
dev_err(dev, "fail to create work queue\n");
ret = -ENOMEM;
- goto free_platform;
+ return ret;
}
platform->pdata.intp_irq = client->irq;
@@ -2637,9 +2637,6 @@ static int anx7625_i2c_probe(struct i2c_client *client,
if (platform->hdcp_workqueue)
destroy_workqueue(platform->hdcp_workqueue);
-free_platform:
- kfree(platform);
-
return ret;
}
@@ -2666,7 +2663,6 @@ static int anx7625_i2c_remove(struct i2c_client *client)
if (platform->pdata.audio_en)
anx7625_unregister_audio(platform);
- kfree(platform);
return 0;
}
--
2.34.1.703.g22d0c6ccf7-goog
[PATCH v4 3/4] drm/bridge: anx7625: Support reading edid through aux channel
Support reading edid through aux channel if panel is connected to aux
bus. Extend anx7625_aux_dpcd_trans() to implement aux transfer function:
1. panel is populated in devm_of_dp_aux_populate_ep_devices(), so move
anx7625_parse_dt() after.
2. Use pm runtime autosuspend since aux transfer function is called
multiple times when reading edid.
3. No-op if aux transfer length is 0.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Xin Ji
---
v3->v4:
rebase to latest drm-misc-next
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 120 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 1 +
2 files changed, 103 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index b7e3373994b480..50b9c98277f0d7 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -231,19 +232,23 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
return 0;
}
-static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx, u8 op,
- u32 address, u8 len, u8 *buf)
+static int anx7625_aux_trans(struct anx7625_data *ctx, u8 op, u32 address,
+u8 len, u8 *buf)
{
struct device *dev = &ctx->client->dev;
int ret;
u8 addrh, addrm, addrl;
u8 cmd;
+ bool is_write = !(op & DP_AUX_I2C_READ);
- if (len > MAX_DPCD_BUFFER_SIZE) {
+ if (len > DP_AUX_MAX_PAYLOAD_BYTES) {
dev_err(dev, "exceed aux buffer len.\n");
return -EINVAL;
}
+ if (!len)
+ return len;
+
addrl = address & 0xFF;
addrm = (address >> 8) & 0xFF;
addrh = (address >> 16) & 0xFF;
@@ -262,7 +267,7 @@ static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx,
u8 op,
ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
AP_AUX_ADDR_19_16, addrh);
- if (op == DP_AUX_NATIVE_WRITE)
+ if (is_write)
ret |= anx7625_reg_block_write(ctx, ctx->i2c.rx_p0_client,
AP_AUX_BUFF_START, len, buf);
/* Enable aux access */
@@ -275,14 +280,14 @@ static int anx7625_aux_dpcd_trans(struct anx7625_data
*ctx, u8 op,
}
ret = wait_aux_op_finish(ctx);
- if (ret) {
+ if (ret < 0) {
dev_err(dev, "aux IO error: wait aux op finish.\n");
return ret;
}
/* Write done */
- if (op == DP_AUX_NATIVE_WRITE)
- return 0;
+ if (is_write)
+ return len;
/* Read done, read out dpcd data */
ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
@@ -292,7 +297,7 @@ static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx,
u8 op,
return -EIO;
}
- return 0;
+ return len;
}
static int anx7625_video_mute_control(struct anx7625_data *ctx,
@@ -867,7 +872,7 @@ static int anx7625_hdcp_enable(struct anx7625_data *ctx)
}
/* Read downstream capability */
- anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_READ, 0x68028, 1, &bcap);
+ anx7625_aux_trans(ctx, DP_AUX_NATIVE_READ, 0x68028, 1, &bcap);
if (!(bcap & 0x01)) {
pr_warn("downstream not support HDCP 1.4, cap(%x).\n", bcap);
return 0;
@@ -956,7 +961,7 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
dev_dbg(dev, "notify downstream enter into standby\n");
/* Downstream monitor enter into standby mode */
data = 2;
- ret |= anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1,
&data);
+ ret |= anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1, &data);
if (ret < 0)
DRM_DEV_ERROR(dev, "IO error : mute video fail\n");
@@ -1655,11 +1660,56 @@ static int anx7625_parse_dt(struct device *dev,
return 0;
}
+static bool anx7625_of_panel_on_aux_bus(struct device *dev)
+{
+ struct device_node *bus, *panel;
+
+ bus = of_get_child_by_name(dev->of_node, "aux-bus");
+ if (!bus)
+ return false;
+
+ panel = of_get_child_by_name(bus, "panel");
+ of_node_put(bus);
+ if (!panel)
+ return false;
+ of_node_put(panel);
+
+ return true;
+}
+
static inline struct anx7625_data *bridge_to_anx7625(struct drm_bridge *bridge)
{
return container_of(bridge, struct anx7625_data, bridge);
}
+static ssize_t anx7625_aux_transfer(struct drm_dp_aux *aux,
+struct drm_dp_aux_msg *msg)
+{
+ struct anx7625_data *ctx = container_of(aux, struct anx7625_data, aux);
+ struct device *dev = &ctx->client->dev;
+ u8 request = msg->request & ~DP_AUX_I2C_MOT;
+ int ret = 0;
+
+ pm_runtime_get_sync(d
[PATCH v4 4/4] dt-bindings: drm/bridge: anx7625: Add aux-bus node
List panel under aux-bus node if it's connected to anx7625's aux bus.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Xin Ji
---
.../display/bridge/analogix,anx7625.yaml| 17 +
1 file changed, 17 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 1d3e88daca041a..0d38d6fe39830f 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -83,6 +83,9 @@ properties:
type: boolean
description: let the driver enable audio HDMI codec function or not.
+ aux-bus:
+$ref: /schemas/display/dp-aux-bus.yaml#
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -167,5 +170,19 @@ examples:
};
};
};
+
+aux-bus {
+panel {
+compatible = "innolux,n125hce-gn1";
+power-supply = <&pp3300_disp_x>;
+backlight = <&backlight_lcd0>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <&anx7625_out>;
+};
+};
+};
+};
};
};
--
2.34.1.703.g22d0c6ccf7-goog
Re: [PATCH] phy: dphy: Correct clk_pre parameter
Hi,
On 18.01.2022 03:59, Liu Ying wrote:
The D-PHY specification (v1.2) explicitly mentions that the T-CLK-PRE
parameter's unit is Unit Interval(UI) and the minimum value is 8. Also,
kernel doc of the 'clk_pre' member of struct phy_configure_opts_mipi_dphy
mentions that it should be in UI. However, the dphy core driver wrongly
sets 'clk_pre' to 8000, which seems to hint that it's in picoseconds.
And, the kernel doc of the 'clk_pre' member wrongly says the minimum value
is '8 UI', instead of 8.
So, let's fix both the dphy core driver and the kernel doc of the 'clk_pre'
member to correctly reflect the T-CLK-PRE parameter's unit and the minimum
value according to the D-PHY specification.
I'm assuming that all impacted custom drivers shall program values in
TxByteClkHS cycles into hardware for the T-CLK-PRE parameter. The D-PHY
specification mentions that the frequency of TxByteClkHS is exactly 1/8
the High-Speed(HS) bit rate(each HS bit consumes one UI). So, relevant
custom driver code is changed to program those values as
DIV_ROUND_UP(cfg->clk_pre, MIPI_DPHY_UI_PER_TXBYTECLKHS_PERIOD), then.
Note that I've only tested the patch with RM67191 DSI panel on i.MX8mq EVK.
Help is needed to test with other i.MX8mq, Meson and Rockchip platforms,
as I don't have the hardwares.
Fixes: 2ed869990e14 ("phy: Add MIPI D-PHY configuration options")
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Cc: David Airlie
Cc: Daniel Vetter
Cc: Kishon Vijay Abraham I
Cc: Vinod Koul
Cc: Kevin Hilman
Cc: Jerome Brunet
Cc: Martin Blumenstingl
Cc: Heiko Stuebner
Cc: Maxime Ripard
Cc: Guido Günther
Tested-by: Liu Ying # RM67191 DSI panel on i.MX8mq EVK
Signed-off-by: Liu Ying
---
drivers/gpu/drm/bridge/nwl-dsi.c | 7 ++-
drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c| 3 ++-
drivers/phy/phy-core-mipi-dphy.c | 4 ++--
drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c | 3 ++-
include/linux/phy/phy-mipi-dphy.h| 4 +++-
5 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index a7389a0facfb..f1fdcdf763ee 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -196,12 +196,9 @@ static u32 ps2bc(struct nwl_dsi *dsi, unsigned long long
ps)
/*
* ui2bc - UI time periods to byte clock cycles
*/
-static u32 ui2bc(struct nwl_dsi *dsi, unsigned long long ui)
+static u32 ui2bc(struct nwl_dsi *dsi, unsigned int ui)
{
- u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
-
- return DIV64_U64_ROUND_UP(ui * dsi->lanes,
- dsi->mode.clock * 1000 * bpp);
+ return DIV_ROUND_UP(ui, MIPI_DPHY_UI_PER_TXBYTECLKHS_PERIOD);
I have some doubts here. According to specs:
UI - duration of any HS state on the Clock Lane,
TxByteClkHS - exactly 1/8 the High-Speed(HS) bit rate
I'd like to emphasize "BIT RATE" above (not clock rate).
In such case I would expect that ui2bc would take into account number of
lanes:
byte clock cycles = div_round_up(ui * dsi->lanes, 8)
So in case of one lane we need 8 ticks to get byte, and in case of 4
lanes 2 ticks are enough.
Am I correct, or I've missed sth?
}
/*
diff --git a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
index cd2332bf0e31..8a818cdb7606 100644
--- a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
+++ b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
@@ -250,7 +250,8 @@ static int phy_meson_axg_mipi_dphy_power_on(struct phy *phy)
(DIV_ROUND_UP(priv->config.clk_zero, temp) << 16) |
(DIV_ROUND_UP(priv->config.clk_prepare, temp) << 24));
regmap_write(priv->regmap, MIPI_DSI_CLK_TIM1,
-DIV_ROUND_UP(priv->config.clk_pre, temp));
+DIV_ROUND_UP(priv->config.clk_pre,
+ MIPI_DPHY_UI_PER_TXBYTECLKHS_PERIOD));
regmap_write(priv->regmap, MIPI_DSI_HS_TIM,
DIV_ROUND_UP(priv->config.hs_exit, temp) |
diff --git a/drivers/phy/phy-core-mipi-dphy.c b/drivers/phy/phy-core-mipi-dphy.c
index 288c9c67aa74..ccb4045685cd 100644
--- a/drivers/phy/phy-core-mipi-dphy.c
+++ b/drivers/phy/phy-core-mipi-dphy.c
@@ -36,7 +36,7 @@ int phy_mipi_dphy_get_default_config(unsigned long
pixel_clock,
cfg->clk_miss = 0;
cfg->clk_post = 6 + 52 * ui;
- cfg->clk_pre = 8000;
+ cfg->clk_pre = 8;
cfg->clk_prepare = 38000;
cfg->clk_settle = 95000;
cfg->clk_term_en = 0;
@@ -97,7 +97,7 @@ int phy_mipi_dphy_config_validate(struct
phy_configure_opts_mipi_dphy *cfg)
if (cfg->clk_post < (6 + 52 * ui))
return -EINVAL;
- if (cfg->clk_pre < 8000)
+ if (cfg->clk_pre < 8)
return -EINVAL;
if (cfg->clk_prepare < 38000 || cfg->clk
Re: [PATCH v3 1/3] drm/bridge: anx7625: Convert to use devm_kzalloc
On Mon, Jan 17, 2022 at 6:04 PM Hsin-Yi Wang wrote:
>
> hi Robert,
>
> The second patch depends on "drm/bridge: anx7625: send DPCD command to
> downstream"
> (https://patchwork.kernel.org/project/dri-devel/patch/1f36f8bf0a48fb2bba17bacec23700e58c1d407d.1641891874.git@analogixsemi.com/).
> But I'm waiting for Xin Ji's response for that patch.
>
Hi Robert,
I've rebased to the latest drm-misc-next and sent v4:
https://lore.kernel.org/lkml/20220118092002.4267-1-hsi...@chromium.org/T/#t
I also discussed with Xin Ji about the dependent patch and included it
in the series.
Thanks.
> Thanks
>
> On Mon, Jan 17, 2022 at 5:40 PM Robert Foss wrote:
> >
> > Hey Hsin-Yi,
> >
> >
> > On Thu, 13 Jan 2022 at 09:29, Hsin-Yi Wang wrote:
> > >
> > > Use devm_kzalloc instead of kzalloc and drop kfree(). Let the memory
> > > handled by driver detach.
> > >
> > > Signed-off-by: Hsin-Yi Wang
> > > Reviewed-by: Xin Ji
> > > ---
> > > v2->v3: remove kfree() in anx7625_i2c_remove().
> > > ---
> > > drivers/gpu/drm/bridge/analogix/anx7625.c | 10 +++---
> > > 1 file changed, 3 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > index 0b858c78abe8b6..d3661c78770a8f 100644
> > > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > @@ -2515,7 +2515,7 @@ static int anx7625_i2c_probe(struct i2c_client
> > > *client,
> > > return -ENODEV;
> > > }
> > >
> > > - platform = kzalloc(sizeof(*platform), GFP_KERNEL);
> > > + platform = devm_kzalloc(dev, sizeof(*platform), GFP_KERNEL);
> > > if (!platform) {
> > > DRM_DEV_ERROR(dev, "fail to allocate driver data\n");
> > > return -ENOMEM;
> > > @@ -2527,7 +2527,7 @@ static int anx7625_i2c_probe(struct i2c_client
> > > *client,
> > > if (ret) {
> > > if (ret != -EPROBE_DEFER)
> > > DRM_DEV_ERROR(dev, "fail to parse DT : %d\n",
> > > ret);
> > > - goto free_platform;
> > > + return ret;
> > > }
> > >
> > > platform->client = client;
> > > @@ -2552,7 +2552,7 @@ static int anx7625_i2c_probe(struct i2c_client
> > > *client,
> > > if (!platform->hdcp_workqueue) {
> > > dev_err(dev, "fail to create work queue\n");
> > > ret = -ENOMEM;
> > > - goto free_platform;
> > > + return ret;
> > > }
> > >
> > > platform->pdata.intp_irq = client->irq;
> > > @@ -2637,9 +2637,6 @@ static int anx7625_i2c_probe(struct i2c_client
> > > *client,
> > > if (platform->hdcp_workqueue)
> > > destroy_workqueue(platform->hdcp_workqueue);
> > >
> > > -free_platform:
> > > - kfree(platform);
> > > -
> > > return ret;
> > > }
> > >
> > > @@ -2666,7 +2663,6 @@ static int anx7625_i2c_remove(struct i2c_client
> > > *client)
> > > if (platform->pdata.audio_en)
> > > anx7625_unregister_audio(platform);
> > >
> > > - kfree(platform);
> > > return 0;
> > > }
> > >
> >
> > I just had a look at applying this series, but it fails to apply on
> > drm-misc-next today.
> >
> > Could you send a v4 that applies cleanly, and I'll try to be quick
> > about applying it.
> >
> >
> > Rob.
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On 1/18/22 09:54, Helge Deller wrote: > On 1/18/22 09:38, Jani Nikula wrote: >> On Mon, 17 Jan 2022, Helge Deller wrote: >>> On 1/17/22 22:40, Jani Nikula wrote: On Mon, 17 Jan 2022, Thomas Zimmermann wrote: > Seems like few people read linux-fbdev these days. How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel also? >>> >>> Doesn't seem like much traffic - which IMHO is OK for such a tree with >>> mostly just maintenance patches. >>> Do we still need a separate linux-fbdev mailing list at all? >>> >>> Yes. I want to have it seperate of dri-devel. >>> Actually I'd prefer to drop dri-devel from the list where patches >>> for fbdev are sent... >> >> Disagreed. If anything, this thread shows we can't have fbdev and drm in >> silos of their own. > > Patches to fbdev usually don't affect DRM. Patches for fbdev drivers don't usually affect DRM but that's not the case for patches to fbdev core and fbcon as you and others mentioned. > Patches which affect DRM needs to through to dri-devel. And how would people know which ones need to go through dri-devel ? Are you planning to add another entry to MAINTAINERS for fbdev core/fbcon ? > In addition this would take the burden of the dri-developers to receive > unrelated fbdev driver updates and patches. > In my opinion having fbdev patches in the dri-devel mailing list isn't a big burden, but rather getting people to review and push say patches. Since you are volunteering for the latter, that should improve things. I still fail to see the benefit of doing that split, same for having a separate fbdev tree. Using drm-misc only have advantages, among other things providing redundancy in cases that a maintainer isn't available for a period of time. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH AUTOSEL 5.15 123/188] drm/tegra: dc: rgb: Allow changing PLLD rate on Tegra30+
18.01.2022 05:30, Sasha Levin пишет: > From: Dmitry Osipenko > > [ Upstream commit 0c921b6d4ba06bc899fd84d3ce1c1afd3d00bc1c ] > > Asus Transformer TF700T is a Tegra30 tablet device which uses RGB->DSI > bridge that requires a precise clock rate in order to operate properly. > Tegra30 has a dedicated PLL for each display controller, hence the PLL > rate can be changed freely. Allow PLL rate changes on Tegra30+ for RGB > output. Configure the clock rate before display controller is enabled > since DC itself may be running off this PLL and it's not okay to change > the rate of the active PLL that doesn't support dynamic frequency > switching since hardware will hang. > > Tested-by: Maxim Schwalm #TF700T > Signed-off-by: Dmitry Osipenko > Signed-off-by: Thierry Reding > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/tegra/dc.c | 27 > drivers/gpu/drm/tegra/dc.h | 1 + > drivers/gpu/drm/tegra/rgb.c | 49 +++-- > 3 files changed, 65 insertions(+), 12 deletions(-) Hi, This patch shouldn't be ported to any stable kernel because h/w that needs this patch was just merged to the 5.17.
Re: [PATCH AUTOSEL 5.15 123/188] drm/tegra: dc: rgb: Allow changing PLLD rate on Tegra30+
18.01.2022 12:37, Dmitry Osipenko пишет: > 18.01.2022 05:30, Sasha Levin пишет: >> From: Dmitry Osipenko >> >> [ Upstream commit 0c921b6d4ba06bc899fd84d3ce1c1afd3d00bc1c ] >> >> Asus Transformer TF700T is a Tegra30 tablet device which uses RGB->DSI >> bridge that requires a precise clock rate in order to operate properly. >> Tegra30 has a dedicated PLL for each display controller, hence the PLL >> rate can be changed freely. Allow PLL rate changes on Tegra30+ for RGB >> output. Configure the clock rate before display controller is enabled >> since DC itself may be running off this PLL and it's not okay to change >> the rate of the active PLL that doesn't support dynamic frequency >> switching since hardware will hang. >> >> Tested-by: Maxim Schwalm #TF700T >> Signed-off-by: Dmitry Osipenko >> Signed-off-by: Thierry Reding >> Signed-off-by: Sasha Levin >> --- >> drivers/gpu/drm/tegra/dc.c | 27 >> drivers/gpu/drm/tegra/dc.h | 1 + >> drivers/gpu/drm/tegra/rgb.c | 49 +++-- >> 3 files changed, 65 insertions(+), 12 deletions(-) > > Hi, > > This patch shouldn't be ported to any stable kernel because h/w that > needs this patch was just merged to the 5.17. * support of h/w that needs..
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi Javier,
On Tue, Jan 18, 2022 at 10:33 AM Javier Martinez Canillas
wrote:
> On 1/18/22 09:54, Helge Deller wrote:
> > On 1/18/22 09:38, Jani Nikula wrote:
> >> On Mon, 17 Jan 2022, Helge Deller wrote:
> >>> On 1/17/22 22:40, Jani Nikula wrote:
> On Mon, 17 Jan 2022, Thomas Zimmermann wrote:
> > Seems like few people read linux-fbdev these days.
>
> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> also?
> >>>
> >>> Doesn't seem like much traffic - which IMHO is OK for such a tree with
> >>> mostly just maintenance patches.
> >>>
> Do we still need a separate linux-fbdev mailing list at all?
> >>>
> >>> Yes. I want to have it seperate of dri-devel.
> >>> Actually I'd prefer to drop dri-devel from the list where patches
> >>> for fbdev are sent...
> >>
> >> Disagreed. If anything, this thread shows we can't have fbdev and drm in
> >> silos of their own.
> >
> > Patches to fbdev usually don't affect DRM.
>
> Patches for fbdev drivers don't usually affect DRM but that's not the
> case for patches to fbdev core and fbcon as you and others mentioned.
>
> > Patches which affect DRM needs to through to dri-devel.
>
> And how would people know which ones need to go through dri-devel ? Are
> you planning to add another entry to MAINTAINERS for fbdev core/fbcon ?
Those are nicely contained in drivers/video/fbdev/core/, so an entry
in MAINTAINERS listing both linux-fbdev and dri-devel would do.
> > In addition this would take the burden of the dri-developers to receive
> > unrelated fbdev driver updates and patches.
>
> In my opinion having fbdev patches in the dri-devel mailing list isn't
> a big burden, but rather getting people to review and push say patches.
>
> Since you are volunteering for the latter, that should improve things.
>
> I still fail to see the benefit of doing that split, same for having a
> separate fbdev tree. Using drm-misc only have advantages, among other
> things providing redundancy in cases that a maintainer isn't available
> for a period of time.
The above is the point of view from a DRM developer?
For an fbdev developer, the burden to receive unrelated DRM driver
updates and patches would be significant.
The first page of https://lore.kernel.org/dri-devel/ goes back to yesterday.
The first page of https://lore.kernel.org/linux-fbdev/ goes back to Nov 30th.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC PATCH v4 0/3] Add support modifiers for drivers whose planes only support linear layout
On Tue, Jan 18, 2022 at 05:36:49PM +0900, Tomohito Esaki wrote: > Some drivers whose planes only support linear layout fb do not support format > modifiers. > These drivers should support modifiers, however the DRM core should handle > this > rather than open-coding in every driver. > > In this patch series, these drivers expose format modifiers based on the > following suggestion[1]. > > On Thu, Nov 18, 2021 at 01:02:11PM +, Daniel Stone wrote: > > I think the best way forward here is: > > - add a new mode_config.cannot_support_modifiers flag, and enable > > this in radeon (plus any other drivers in the same boat) > > - change drm_universal_plane_init() to advertise the LINEAR modifier > > when NULL is passed as the modifier list (including installing a > > default .format_mod_supported hook) > > - remove the mode_config.allow_fb_modifiers hook and always > > advertise modifier support, unless > > mode_config.cannot_support_modifiers is set FWIW, Reviewed-by: Andy Shevchenko > [1] > https://patchwork.kernel.org/project/linux-renesas-soc/patch/20190509054518.10781-1-e...@igel.co.jp/#24602575 > > v4: > * modify documentation for fb_modifiers_not_supported flag in kerneldoc > > v3: https://www.spinics.net/lists/dri-devel/msg329102.html > * change the order as follows: >1. add fb_modifiers_not_supported flag >2. add default modifiers >3. remove allow_fb_modifiers flag > * add a conditional disable in amdgpu_dm_plane_init() > > v2: https://www.spinics.net/lists/dri-devel/msg328939.html > * rebase to the latest master branch (5.16.0+) > + "drm/plane: Make format_mod_supported truly optional" patch [2] > [2] https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3 > > v1: https://www.spinics.net/lists/dri-devel/msg327352.html > * The initial patch set > > Tomohito Esaki (3): > drm: introduce fb_modifiers_not_supported flag in mode_config > drm: add support modifiers for drivers whose planes only support > linear layout > drm: remove allow_fb_modifiers > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++--- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 ++ > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 ++ > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 + > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++ > drivers/gpu/drm/drm_framebuffer.c | 6 ++--- > drivers/gpu/drm/drm_ioctl.c | 2 +- > drivers/gpu/drm/drm_plane.c | 22 +-- > drivers/gpu/drm/nouveau/nouveau_display.c | 6 +++-- > drivers/gpu/drm/radeon/radeon_display.c | 2 ++ > .../gpu/drm/selftests/test-drm_framebuffer.c | 1 - > include/drm/drm_mode_config.h | 18 +-- > include/drm/drm_plane.h | 3 +++ > 14 files changed, 43 insertions(+), 33 deletions(-) > > -- > 2.25.1 > -- With Best Regards, Andy Shevchenko
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote: > On Mon, 17 Jan 2022 19:47:39 +0100 > Sven Schnelle wrote: > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > > a dmesg with 919 lines one the text console took about 2s to display. In > > x11, i measure 22ms. This might be unfair because encoding might be > > different, but i cannot confirm the 'memcpy' is faster than hardware > > blitting' point. I think if that would be the case, no-one would care > > about 2D acceleration. > > I think that is an extremely unfair comparison, because a graphical > terminal app is not going to render every line of text streamed to it. > It probably renders only the final view alone if you simply run > 'dmesg', skipping the first 800-900 lines completely. Probably more like "render on every vblank", but yes, unlike fbcon it surely wouldn't render every single character sent to the terminal. Also acceleration on modern hardware is more like "compose window content using the 3d engine" than "use 2d blitter to scroll the window". > Maybe fbcon should do the same when presented with a flood of text, > but I don't know how or why it works like it works. fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of doing it synchronously. take care, Gerd
Re: [RFC PATCH v3 2/3] drm: add support modifiers for drivers whose planes only support linear layout
On Mon, Jan 17, 2022 at 02:15:48PM +0900, Esaki Tomohito wrote:
> On 2022/01/14 23:16, Andy Shevchenko wrote:
> > On Fri, Jan 14, 2022 at 07:17:52PM +0900, Tomohito Esaki wrote:
> > > The LINEAR modifier is advertised as default if a driver doesn't specify
> > > modifiers.
> >
> > ...
> >
> > > + const uint64_t default_modifiers[] = {
> > > + DRM_FORMAT_MOD_LINEAR,
> > > + DRM_FORMAT_MOD_INVALID
> >
> > + Comma?
>
> There is no mention in the coding style about adding/removing a comma to the
> last element of an array. Is there a policy in drm driver?
>
> I think the advantage of adding a comma to the last element of an array is
> that diff is only one line when an element is added to the end.
> However since INVALID is always the last element in the modifiers array, I
> think it can be either in this case.
> If there is a policy, I will match it.
Indeed, but there is a common sense. The idea behind (multi-line) definitions
that when next time somebody will add an element in the array, there are will
be:
a) no additional churn (like in case of this patch, if the item will be added
at the bottom;
b) an element that may not be added behind the terminator, which will look
weird.
That said, the question is if the element is terminator one or not, if not,
comma is better than no comma and vise versa.
--
With Best Regards,
Andy Shevchenko
[PATCH 0/7] Add GuC Error Capture Support
This series: 1. Enables support of GuC to execute error- state-capture based on a list of MMIO registers the driver registers and GuC will dump and report back right before a GuC triggered engine-reset event. 2. Updates the ADS blob creation to register lists of global and engine registers with GuC. 3. Defines tables of register lists that are global or engine class or engine instance in scope. 4. Separates GuC log-buffer access locks for relay logging vs the new region for the error state capture data. 5. Allocates an additional interim circular buffer store to copy snapshots of new GuC reported error-state-capture dumps in response to the G2H notification. 6. Connects the i915_gpu_coredump reporting function to the GuC error capture module to print all GuC error state capture dumps that is reported. This is the 4th rev of this series with the first 3 revs labelled as RFC. Prior receipts of rvb's: - Patch #4 has received R-v-b from Matthew Brost Changes from prior revs: v4: - Rebased on latest drm-tip that has been merged with the support of GuC firmware version 69.0.3 that is required for GuC error-state-catpure to work. - Added register list for DG2 which is the same as XE_LP except an additional steering register set. - Fixed a bug in the end of capture parsing loop in intel_guc_capture_out_print_next_group that was not properly comparing the engine-instance and engine- class being parsed against the one that triggered the i915_gpu_coredump. v3: - Fixed all review comments from rev2 except the following: - Michal Wajdeczko proposed adding a seperate function to lookup register string nameslookup (based on offset) but decided against it because of offset conflicts and the current table layout is easier to maintain. - Last set of checkpatch errors pertaining to "COMPLEX MACROS" should be fixed on next rev. - Abstracted internal-to-guc-capture information into a new __guc_state_capture_priv structure that allows the exclusion of intel_guc.h and intel_guc_fwif.h from intel_guc_capture.h. Now, only the first 2 patches have a wider build time impact because of the changes to intel_guc_fwif.h but subsequent changes to guc-capture internal structures or firmware interfaces used solely by guc-capture module shoudn't impact the rest of the driver build. - Added missing Gen12LP registers and added slice+subslice indices when reporting extended steered registers. - Add additional checks to ensure that the GuC reported error capture information matches the i915_gpu_coredump that is being printed before we print out the corresponding VMA dumps such as the batch buffer. v2: - Ignore - failed CI retest. Alan Previn (7): drm/i915/guc: Update GuC ADS size for error capture lists drm/i915/guc: Add XE_LP registers for GuC error state capture. drm/i915/guc: Add DG2 registers for GuC error state capture. drm/i915/guc: Add GuC's error state capture output structures. drm/i915/guc: Update GuC's log-buffer-state access for error capture. drm/i915/guc: Copy new GuC error capture logs upon G2H notification. drm/i915/guc: Print the GuC error capture output register list. drivers/gpu/drm/i915/Makefile |1 + drivers/gpu/drm/i915/gt/intel_engine_cs.c |4 +- .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h |7 + drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 85 ++ drivers/gpu/drm/i915/gt/uc/intel_guc.c| 13 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 13 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 36 +- .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 1310 + .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 30 + drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 21 +- drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 155 +- drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 20 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 14 +- drivers/gpu/drm/i915/i915_gpu_error.c | 65 +- drivers/gpu/drm/i915/i915_gpu_error.h | 14 + 15 files changed, 1669 insertions(+), 119 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h -- 2.25.1
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On 1/18/22 10:16, Gerd Hoffmann wrote: > On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote: >> On 1/18/22 07:29, Gerd Hoffmann wrote: Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is currently unaccelerated and bound to Truecolour modes only, >>> >>> Yes. Adding support for formats beside argb to the drm fbcon >>> emulation shouldn't be that much of a problem though. >> >> Really? Assuming a graphic card which runs with only 256 colors framebuffer >> is easily supported by DRM, and you can use fbcon without using lots of >> memcpy()? > > Driver: programming a fixed color cube palette, then use RGB332. > > fbcon/fbdev emulation: RGB332 support must be added I think. But both > argb888 and rgb565 are supported today, so it should not be hard to find > the places where you have to add some code to handle RGB332 too. I'd expect that that framework is provided by DRM developers if there is the wish to get rid of old fbdev and transition existing drivers over to use DRM. >>> Acceleration is harder. The scroll acceleration had issues nobody >>> addressed for years, and on modern hardware it is simply not used, which >>> is probably the reason nobody stepped up fixing things and it ended up >>> being dropped. >> >> The DRM layer doesn't use scroll acceleration. >> More than 30 other existing fbdev drivers use it. > > Yes. The world shifted from 2d acceleration to 3d acceleration. Modern > hardware simply has no classic blitter any more. Which is a problem > when it comes to keeping scroll acceleration alive, it is already a very > niche use case and it will only become worse ... For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today with the arguments mentioned multiple times). But the patches broke existing fbdev acceleration which is available by the fbdev drivers. That's a big regression from point of fbdev. >>> Bringing it back is much more work than just reverting the commits removing >>> it. >> >> Reverting those commits have no effect on DRM's usage of fbcon. >> But reverting those commits bring back scroll acceleration for all others. >> I'm trying to find out which patches did apparently fixed such issues >> for the REDRAW case. If you have a pointer it would be helpful. > > IIRC the code had a bunch of races and syzkaller flagged problems. > I didn't follow very closely though. That's sad. Nevertheless I wonder if the changes which were apparently done for the SCROLL_REDRAW case (on the higher level?) didn't also fixed the issues for SCROLL_MOVE. Helge
Re: [PATCH] phy: dphy: Correct clk_pre parameter
Hi Andrzej,
Thanks for your review.
On Tue, 2022-01-18 at 10:24 +0100, Andrzej Hajda wrote:
> Hi,
>
> On 18.01.2022 03:59, Liu Ying wrote:
> > The D-PHY specification (v1.2) explicitly mentions that the T-CLK-PRE
> > parameter's unit is Unit Interval(UI) and the minimum value is 8. Also,
> > kernel doc of the 'clk_pre' member of struct phy_configure_opts_mipi_dphy
> > mentions that it should be in UI. However, the dphy core driver wrongly
> > sets 'clk_pre' to 8000, which seems to hint that it's in picoseconds.
> > And, the kernel doc of the 'clk_pre' member wrongly says the minimum value
> > is '8 UI', instead of 8.
> >
> > So, let's fix both the dphy core driver and the kernel doc of the 'clk_pre'
> > member to correctly reflect the T-CLK-PRE parameter's unit and the minimum
> > value according to the D-PHY specification.
> >
> > I'm assuming that all impacted custom drivers shall program values in
> > TxByteClkHS cycles into hardware for the T-CLK-PRE parameter. The D-PHY
> > specification mentions that the frequency of TxByteClkHS is exactly 1/8
> > the High-Speed(HS) bit rate(each HS bit consumes one UI). So, relevant
> > custom driver code is changed to program those values as
> > DIV_ROUND_UP(cfg->clk_pre, MIPI_DPHY_UI_PER_TXBYTECLKHS_PERIOD), then.
> >
> > Note that I've only tested the patch with RM67191 DSI panel on i.MX8mq EVK.
> > Help is needed to test with other i.MX8mq, Meson and Rockchip platforms,
> > as I don't have the hardwares.
> >
> > Fixes: 2ed869990e14 ("phy: Add MIPI D-PHY configuration options")
> > Cc: Andrzej Hajda
> > Cc: Neil Armstrong
> > Cc: Robert Foss
> > Cc: Laurent Pinchart
> > Cc: Jonas Karlman
> > Cc: Jernej Skrabec
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Kishon Vijay Abraham I
> > Cc: Vinod Koul
> > Cc: Kevin Hilman
> > Cc: Jerome Brunet
> > Cc: Martin Blumenstingl
> > Cc: Heiko Stuebner
> > Cc: Maxime Ripard
> > Cc: Guido Günther
> > Tested-by: Liu Ying # RM67191 DSI panel on i.MX8mq EVK
> > Signed-off-by: Liu Ying
> > ---
> > drivers/gpu/drm/bridge/nwl-dsi.c | 7 ++-
> > drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c| 3 ++-
> > drivers/phy/phy-core-mipi-dphy.c | 4 ++--
> > drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c | 3 ++-
> > include/linux/phy/phy-mipi-dphy.h| 4 +++-
> > 5 files changed, 11 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> > b/drivers/gpu/drm/bridge/nwl-dsi.c
> > index a7389a0facfb..f1fdcdf763ee 100644
> > --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> > @@ -196,12 +196,9 @@ static u32 ps2bc(struct nwl_dsi *dsi, unsigned long
> > long ps)
> > /*
> >* ui2bc - UI time periods to byte clock cycles
> >*/
> > -static u32 ui2bc(struct nwl_dsi *dsi, unsigned long long ui)
> > +static u32 ui2bc(struct nwl_dsi *dsi, unsigned int ui)
> > {
> > - u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> > -
> > - return DIV64_U64_ROUND_UP(ui * dsi->lanes,
> > - dsi->mode.clock * 1000 * bpp);
> > + return DIV_ROUND_UP(ui, MIPI_DPHY_UI_PER_TXBYTECLKHS_PERIOD);
>
> I have some doubts here. According to specs:
>
> UI - duration of any HS state on the Clock Lane,
>
> TxByteClkHS - exactly 1/8 the High-Speed(HS) bit rate
>
> I'd like to emphasize "BIT RATE" above (not clock rate).
>
> In such case I would expect that ui2bc would take into account number of
> lanes:
>
> byte clock cycles = div_round_up(ui * dsi->lanes, 8)
>
> So in case of one lane we need 8 ticks to get byte, and in case of 4
> lanes 2 ticks are enough.
>
> Am I correct, or I've missed sth?
Sorry, I think you are wrong.
The spec also mentions that it is recommended that all transmitting
Data Lane Modules share one TxByteClkHS signal. So, usually,
TxByteClkHS has nothing to do with data lane number, but only UI - one
bit period is HS state. I think the NWL DSI follows the recommended
implementation.
'Table 20 HS Transmitter AC Specifications' in the spec notes
that Applicable when supporting maximum HS bit rates ≤ 1 Gbps (UI ≥ 1
ns). This hints that HS bit rate is 1/UI.
>
>
> > }
> >
> > /*
> > diff --git a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
> > b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
> > index cd2332bf0e31..8a818cdb7606 100644
> > --- a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
> > +++ b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
> > @@ -250,7 +250,8 @@ static int phy_meson_axg_mipi_dphy_power_on(struct phy
> > *phy)
> > (DIV_ROUND_UP(priv->config.clk_zero, temp) << 16) |
> > (DIV_ROUND_UP(priv->config.clk_prepare, temp) << 24));
> > regmap_write(priv->regmap, MIPI_DSI_CLK_TIM1,
> > -DIV_ROUND_UP(priv->config.clk_pre, temp));
> > +DIV_ROUND_UP(priv->config.clk_pre,
> > + MIPI_DPHY_UI_PER_TXBYTECLKHS_PERIOD));
>
Re: [PATCH] phy: dphy: Correct clk_pre parameter
On 18.01.2022 11:14, Liu Ying wrote:
Hi Andrzej,
Thanks for your review.
On Tue, 2022-01-18 at 10:24 +0100, Andrzej Hajda wrote:
Hi,
On 18.01.2022 03:59, Liu Ying wrote:
The D-PHY specification (v1.2) explicitly mentions that the T-CLK-PRE
parameter's unit is Unit Interval(UI) and the minimum value is 8. Also,
kernel doc of the 'clk_pre' member of struct phy_configure_opts_mipi_dphy
mentions that it should be in UI. However, the dphy core driver wrongly
sets 'clk_pre' to 8000, which seems to hint that it's in picoseconds.
And, the kernel doc of the 'clk_pre' member wrongly says the minimum value
is '8 UI', instead of 8.
So, let's fix both the dphy core driver and the kernel doc of the 'clk_pre'
member to correctly reflect the T-CLK-PRE parameter's unit and the minimum
value according to the D-PHY specification.
I'm assuming that all impacted custom drivers shall program values in
TxByteClkHS cycles into hardware for the T-CLK-PRE parameter. The D-PHY
specification mentions that the frequency of TxByteClkHS is exactly 1/8
the High-Speed(HS) bit rate(each HS bit consumes one UI). So, relevant
custom driver code is changed to program those values as
DIV_ROUND_UP(cfg->clk_pre, MIPI_DPHY_UI_PER_TXBYTECLKHS_PERIOD), then.
Note that I've only tested the patch with RM67191 DSI panel on i.MX8mq EVK.
Help is needed to test with other i.MX8mq, Meson and Rockchip platforms,
as I don't have the hardwares.
Fixes: 2ed869990e14 ("phy: Add MIPI D-PHY configuration options")
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Cc: David Airlie
Cc: Daniel Vetter
Cc: Kishon Vijay Abraham I
Cc: Vinod Koul
Cc: Kevin Hilman
Cc: Jerome Brunet
Cc: Martin Blumenstingl
Cc: Heiko Stuebner
Cc: Maxime Ripard
Cc: Guido Günther
Tested-by: Liu Ying # RM67191 DSI panel on i.MX8mq EVK
Signed-off-by: Liu Ying
---
drivers/gpu/drm/bridge/nwl-dsi.c | 7 ++-
drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c| 3 ++-
drivers/phy/phy-core-mipi-dphy.c | 4 ++--
drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c | 3 ++-
include/linux/phy/phy-mipi-dphy.h| 4 +++-
5 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index a7389a0facfb..f1fdcdf763ee 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -196,12 +196,9 @@ static u32 ps2bc(struct nwl_dsi *dsi, unsigned long long
ps)
/*
* ui2bc - UI time periods to byte clock cycles
*/
-static u32 ui2bc(struct nwl_dsi *dsi, unsigned long long ui)
+static u32 ui2bc(struct nwl_dsi *dsi, unsigned int ui)
{
- u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
-
- return DIV64_U64_ROUND_UP(ui * dsi->lanes,
- dsi->mode.clock * 1000 * bpp);
+ return DIV_ROUND_UP(ui, MIPI_DPHY_UI_PER_TXBYTECLKHS_PERIOD);
I have some doubts here. According to specs:
UI - duration of any HS state on the Clock Lane,
TxByteClkHS - exactly 1/8 the High-Speed(HS) bit rate
I'd like to emphasize "BIT RATE" above (not clock rate).
In such case I would expect that ui2bc would take into account number of
lanes:
byte clock cycles = div_round_up(ui * dsi->lanes, 8)
So in case of one lane we need 8 ticks to get byte, and in case of 4
lanes 2 ticks are enough.
Am I correct, or I've missed sth?
Sorry, I think you are wrong.
The spec also mentions that it is recommended that all transmitting
Data Lane Modules share one TxByteClkHS signal. So, usually,
TxByteClkHS has nothing to do with data lane number, but only UI - one
bit period is HS state. I think the NWL DSI follows the recommended
implementation.
'Table 20 HS Transmitter AC Specifications' in the spec notes
that Applicable when supporting maximum HS bit rates ≤ 1 Gbps (UI ≥ 1
ns). This hints that HS bit rate is 1/UI.
OK, apparently "bit rate" in case of PHYs usually means "bit rate per lane".
Regards
Andrzej
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On 1/18/22 11:13, Helge Deller wrote: > On 1/18/22 10:16, Gerd Hoffmann wrote: >> On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote: >>> On 1/18/22 07:29, Gerd Hoffmann wrote: > Please correct me if I'm wrong, but text-console emulation/scrolling on > DRM is > currently unaccelerated and bound to Truecolour modes only, Yes. Adding support for formats beside argb to the drm fbcon emulation shouldn't be that much of a problem though. >>> >>> Really? Assuming a graphic card which runs with only 256 colors framebuffer >>> is easily supported by DRM, and you can use fbcon without using lots of >>> memcpy()? >> >> Driver: programming a fixed color cube palette, then use RGB332. >> >> fbcon/fbdev emulation: RGB332 support must be added I think. But both >> argb888 and rgb565 are supported today, so it should not be hard to find >> the places where you have to add some code to handle RGB332 too. > > I'd expect that that framework is provided by DRM developers if there is the > wish > to get rid of old fbdev and transition existing drivers over to use DRM. > Acceleration is harder. The scroll acceleration had issues nobody addressed for years, and on modern hardware it is simply not used, which is probably the reason nobody stepped up fixing things and it ended up being dropped. >>> >>> The DRM layer doesn't use scroll acceleration. >>> More than 30 other existing fbdev drivers use it. >> >> Yes. The world shifted from 2d acceleration to 3d acceleration. Modern >> hardware simply has no classic blitter any more. Which is a problem >> when it comes to keeping scroll acceleration alive, it is already a very >> niche use case and it will only become worse ... > > For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today > with the arguments mentioned multiple times). > But the patches broke existing fbdev acceleration which is available by > the fbdev drivers. That's a big regression from point of fbdev. > Bringing it back is much more work than just reverting the commits removing it. >>> >>> Reverting those commits have no effect on DRM's usage of fbcon. >>> But reverting those commits bring back scroll acceleration for all others. >>> I'm trying to find out which patches did apparently fixed such issues >>> for the REDRAW case. If you have a pointer it would be helpful. >> >> IIRC the code had a bunch of races and syzkaller flagged problems. >> I didn't follow very closely though. > > That's sad. > Nevertheless I wonder if the changes which were apparently done for > the SCROLL_REDRAW case (on the higher level?) didn't also fixed the issues > for SCROLL_MOVE. I've just looked through all patches in drivers/video which were tagged with syzbot or syzkaller back to year 2005. The vast majority fixed the reported issues on a higher level, e.g. when screen is to be resized, or when font size is to be changed. The few ones which touched driver code fixed a real driver bug, e.g. by adding a check. NONE of those patches touched either the SCROLL_MOVE or the SCROLL_REDRAW case. That means, I see no reason why SCROLL_MOVE had to be ripped-out and just SCROLL_REDRAW had to be used instead, other than simply "it's not being used by DRM, so let's pull it out". The patches which removed SCROLL_MOVE support simply ignored the fact that SCROLL_MOVE is still heavily used by fbdev (non-DRM). I don't see a reason why the two patches which removed SCROLL_MOVE shouldn't be reverted. Or what am I missing? Helge
[PATCH v9 1/6] drm: move the buddy allocator from i915 into common drm
Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
- add Makefile support for drm buddy
- export functions and write kerneldoc description
- Remove i915 selftest config check condition as buddy selftest
will be moved to drm selftest folder
cleanup i915 buddy references in i915 driver module
and replace with drm buddy
v2:
- include header file in alphabetical order(Thomas)
- merged changes listed in the body section into a single patch
to keep the build intact(Christian, Jani)
v3:
- make drm buddy a separate module(Thomas, Christian)
v4:
- Fix build error reported by kernel test robot
- removed i915 buddy selftest from i915_mock_selftests.h to
avoid build error
- removed selftests/i915_buddy.c file as we create a new set of
buddy test cases in drm/selftests folder
v5:
- Fix merge conflict issue
v6:
- replace drm_buddy_mm structure name as drm_buddy(Thomas, Christian)
- replace drm_buddy_alloc() function name as drm_buddy_alloc_blocks()
(Thomas)
- replace drm_buddy_free() function name as drm_buddy_free_block()
(Thomas)
- export drm_buddy_free_block() function
- fix multiple instances of KMEM_CACHE() entry
v7:
- fix warnings reported by kernel test robot
- modify the license(Christian)
v8:
- fix warnings reported by kernel test robot
Signed-off-by: Arunpravin
---
drivers/gpu/drm/Kconfig | 6 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/drm_buddy.c | 535
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/i915_buddy.c | 466 ---
drivers/gpu/drm/i915/i915_buddy.h | 143
drivers/gpu/drm/i915/i915_module.c| 3 -
drivers/gpu/drm/i915/i915_scatterlist.c | 11 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 33 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 4 +-
drivers/gpu/drm/i915/selftests/i915_buddy.c | 787 --
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
.../drm/i915/selftests/intel_memory_region.c | 13 +-
include/drm/drm_buddy.h | 150
15 files changed, 725 insertions(+), 1431 deletions(-)
create mode 100644 drivers/gpu/drm/drm_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h
delete mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c
create mode 100644 include/drm/drm_buddy.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 91f54aeb0b7c..cc3e979c9c9d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -204,6 +204,12 @@ config DRM_TTM
GPU memory types. Will be enabled automatically if a device driver
uses it.
+config DRM_BUDDY
+ tristate
+ depends on DRM
+ help
+ A page based buddy allocator
+
config DRM_VRAM_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 700abeb4945e..8675c2af7ae1 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -40,6 +40,8 @@ obj-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_cma_helper.o
drm_shmem_helper-y := drm_gem_shmem_helper.o
obj-$(CONFIG_DRM_GEM_SHMEM_HELPER) += drm_shmem_helper.o
+obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
+
drm_vram_helper-y := drm_gem_vram_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
new file mode 100644
index ..d60878bc9c20
--- /dev/null
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -0,0 +1,535 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+static struct kmem_cache *slab_blocks;
+
+static struct drm_buddy_block *drm_block_alloc(struct drm_buddy *mm,
+ struct drm_buddy_block *parent,
+ unsigned int order,
+ u64 offset)
+{
+ struct drm_buddy_block *block;
+
+ BUG_ON(order > DRM_BUDDY_MAX_ORDER);
+
+ block = kmem_cache_zalloc(slab_blocks, GFP_KERNEL);
+ if (!block)
+ return NULL;
+
+ block->header = offset;
+ block->header |= order;
+ block->parent = parent;
+
+ BUG_ON(block->header & DRM_BUDDY_HEADER_UNUSED);
+ return block;
+}
+
+static void drm_block_free(struct drm_buddy *mm,
+ struct drm_buddy_block *block)
+{
+ kmem_cache_free(slab_blocks, block);
+}
+
+static void mark_allocated(struct drm_buddy_block *block)
+{
+
[PATCH v9 3/6] drm: implement top-down allocation method
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver requests address at a low specific
range, allocator traverses from the root block and splits
the larger blocks until it reaches the specific block and
in the process of splitting, lower orders in the freelist
are occupied with low range address blocks and for the
subsequent TOPDOWN memory request we may return the low
range blocks.To overcome this issue, we may go with the
below approach.
The other approach, sorting each order list entries in
ascending order and compares the last entry of each
order list in the freelist and return the max block.
This creates sorting overhead on every drm_buddy_free()
request and split up of larger blocks for a single page
request.
v2:
- Fix alignment issues(Matthew Auld)
- Remove unnecessary list_empty check(Matthew Auld)
- merged the below patch to see the feature in action
- add top-down alloc support to i915 driver
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 36 ---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 3 ++
include/drm/drm_buddy.h | 1 +
3 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 954e31962c74..6aa5c1ce25bf 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -371,6 +371,26 @@ alloc_range_bias(struct drm_buddy *mm,
return ERR_PTR(err);
}
+static struct drm_buddy_block *
+get_maxblock(struct list_head *head)
+{
+ struct drm_buddy_block *max_block = NULL, *node;
+
+ max_block = list_first_entry_or_null(head,
+struct drm_buddy_block,
+link);
+ if (!max_block)
+ return NULL;
+
+ list_for_each_entry(node, head, link) {
+ if (drm_buddy_block_offset(node) >
+ drm_buddy_block_offset(max_block))
+ max_block = node;
+ }
+
+ return max_block;
+}
+
static struct drm_buddy_block *
alloc_from_freelist(struct drm_buddy *mm,
unsigned int order,
@@ -381,11 +401,17 @@ alloc_from_freelist(struct drm_buddy *mm,
int err;
for (i = order; i <= mm->max_order; ++i) {
- block = list_first_entry_or_null(&mm->free_list[i],
-struct drm_buddy_block,
-link);
- if (block)
- break;
+ if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
+ block = get_maxblock(&mm->free_list[i]);
+ if (block)
+ break;
+ } else {
+ block = list_first_entry_or_null(&mm->free_list[i],
+struct drm_buddy_block,
+link);
+ if (block)
+ break;
+ }
}
if (!block)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index 1411f4cf1f21..3662434b64bb 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -53,6 +53,9 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
INIT_LIST_HEAD(&bman_res->blocks);
bman_res->mm = mm;
+ if (place->flags & TTM_PL_FLAG_TOPDOWN)
+ bman_res->flags |= DRM_BUDDY_TOPDOWN_ALLOCATION;
+
if (place->fpfn || lpfn != man->size)
bman_res->flags |= DRM_BUDDY_RANGE_ALLOCATION;
diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
index 865664b90a8a..424fc443115e 100644
--- a/include/drm/drm_buddy.h
+++ b/include/drm/drm_buddy.h
@@ -28,6 +28,7 @@
})
#define DRM_BUDDY_RANGE_ALLOCATION (1 << 0)
+#define DRM_BUDDY_TOPDOWN_ALLOCATION (1 << 1)
struct drm_buddy_block {
#define DRM_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12)
--
2.25.1
[PATCH v9 2/6] drm: improve drm_buddy_alloc function
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation and memory alignment logic from
i915 driver to drm buddy
v2:
merged below changes to keep the build unbroken
- drm_buddy_alloc_range() becomes obsolete and may be removed
- enable ttm range allocation (fpfn / lpfn) support in i915 driver
- apply enhanced drm_buddy_alloc() function to i915 driver
v3(Matthew Auld):
- Fix alignment issues and remove unnecessary list_empty check
- add more validation checks for input arguments
- make alloc_range() block allocations as bottom-up
- optimize order computation logic
- replace uint64_t with u64, which is preferred in the kernel
v4(Matthew Auld):
- keep drm_buddy_alloc_range() function implementation for generic
actual range allocations
- keep alloc_range() implementation for end bias allocations
v5(Matthew Auld):
- modify drm_buddy_alloc() passing argument place->lpfn to lpfn
as place->lpfn will currently always be zero for i915
v6(Matthew Auld):
- fixup potential uaf - If we are unlucky and can't allocate
enough memory when splitting blocks, where we temporarily
end up with the given block and its buddy on the respective
free list, then we need to ensure we delete both blocks,
and no just the buddy, before potentially freeing them
- fix warnings reported by kernel test robot
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 326 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 67 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 2 +
include/drm/drm_buddy.h | 22 +-
4 files changed, 293 insertions(+), 124 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index d60878bc9c20..954e31962c74 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -282,23 +282,99 @@ void drm_buddy_free_list(struct drm_buddy *mm, struct
list_head *objects)
}
EXPORT_SYMBOL(drm_buddy_free_list);
-/**
- * drm_buddy_alloc_blocks - allocate power-of-two blocks
- *
- * @mm: DRM buddy manager to allocate from
- * @order: size of the allocation
- *
- * The order value here translates to:
- *
- * 0 = 2^0 * mm->chunk_size
- * 1 = 2^1 * mm->chunk_size
- * 2 = 2^2 * mm->chunk_size
- *
- * Returns:
- * allocated ptr to the &drm_buddy_block on success
- */
-struct drm_buddy_block *
-drm_buddy_alloc_blocks(struct drm_buddy *mm, unsigned int order)
+static inline bool overlaps(u64 s1, u64 e1, u64 s2, u64 e2)
+{
+ return s1 <= e2 && e1 >= s2;
+}
+
+static inline bool contains(u64 s1, u64 e1, u64 s2, u64 e2)
+{
+ return s1 <= s2 && e1 >= e2;
+}
+
+static struct drm_buddy_block *
+alloc_range_bias(struct drm_buddy *mm,
+u64 start, u64 end,
+unsigned int order)
+{
+ struct drm_buddy_block *block;
+ struct drm_buddy_block *buddy;
+ LIST_HEAD(dfs);
+ int err;
+ int i;
+
+ end = end - 1;
+
+ for (i = 0; i < mm->n_roots; ++i)
+ list_add_tail(&mm->roots[i]->tmp_link, &dfs);
+
+ do {
+ u64 block_start;
+ u64 block_end;
+
+ block = list_first_entry_or_null(&dfs,
+struct drm_buddy_block,
+tmp_link);
+ if (!block)
+ break;
+
+ list_del(&block->tmp_link);
+
+ if (drm_buddy_block_order(block) < order)
+ continue;
+
+ block_start = drm_buddy_block_offset(block);
+ block_end = block_start + drm_buddy_block_size(mm, block) - 1;
+
+ if (!overlaps(start, end, block_start, block_end))
+ continue;
+
+ if (drm_buddy_block_is_allocated(block))
+ continue;
+
+ if (contains(start, end, block_start, block_end) &&
+ order == drm_buddy_block_order(block)) {
+ /*
+* Find the free block within the range.
+*/
+ if (drm_buddy_block_is_free(block))
+ return block;
+
+ continue;
+ }
+
+ if (!drm_buddy_block_is_split(block)) {
+ err = split_block(mm, block);
+ if (unlikely(err))
+ goto err_undo;
+ }
+
+ list_add(&block->right->tmp_link, &dfs);
+ list_add(&block->left->tmp_link, &dfs);
+ } while (1);
+
+ return ERR_PTR(-ENOSPC);
+
+err_undo:
+ /*
+* We really don't want to leave around a bunch of split blocks, since
+*
[PATCH v9 5/6] drm/amdgpu: move vram inline functions into a header
Move shared vram inline functions and structs
into a header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 51
1 file changed, 51 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
new file mode 100644
index ..59983464cce5
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2021 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __AMDGPU_VRAM_MGR_H__
+#define __AMDGPU_VRAM_MGR_H__
+
+#include
+
+struct amdgpu_vram_mgr_node {
+ struct ttm_resource base;
+ struct list_head blocks;
+ unsigned long flags;
+};
+
+static inline u64 amdgpu_node_start(struct drm_buddy_block *block)
+{
+ return drm_buddy_block_offset(block);
+}
+
+static inline u64 amdgpu_node_size(struct drm_buddy_block *block)
+{
+ return PAGE_SIZE << drm_buddy_block_order(block);
+}
+
+static inline struct amdgpu_vram_mgr_node *
+to_amdgpu_vram_mgr_node(struct ttm_resource *res)
+{
+ return container_of(res, struct amdgpu_vram_mgr_node, base);
+}
+
+#endif
--
2.25.1
[PATCH v9 4/6] drm: implement a method to free unused pages
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
- replace input argument name 'actual_size' with 'new_size'
- add more validation checks for input arguments
- add overlaps check to avoid needless searching and splitting
- merged the below patch to see the feature in action
- add free unused pages support to i915 driver
- lock drm_buddy_block_trim() function as it calls mark_free/mark_split
are all globally visible
v3(Matthew Auld):
- remove trim method error handling as we address the failure case
at drm_buddy_block_trim() function
v4:
- in case of trim, at __alloc_range() split_block failure path
marks the block as free and removes it from the original list,
potentially also freeing it, to overcome this problem, we turn
the drm_buddy_block_trim() input node into a temporary node to
prevent recursively freeing itself, but still retain the
un-splitting/freeing of the other nodes(Matthew Auld)
- modify the drm_buddy_block_trim() function return type
v5(Matthew Auld):
- revert drm_buddy_block_trim() function return type changes in v4
- modify drm_buddy_block_trim() passing argument n_pages to original_size
as n_pages has already been rounded up to the next power-of-two and
passing n_pages results noop
v6:
- fix warnings reported by kernel test robot
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 65 +++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 10 +++
include/drm/drm_buddy.h | 4 ++
3 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 6aa5c1ce25bf..c5902a81b8c5 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -546,6 +546,71 @@ static int __drm_buddy_alloc_range(struct drm_buddy *mm,
return __alloc_range(mm, &dfs, start, size, blocks);
}
+/**
+ * drm_buddy_block_trim - free unused pages
+ *
+ * @mm: DRM buddy manager
+ * @new_size: original size requested
+ * @blocks: output list head to add allocated blocks
+ *
+ * For contiguous allocation, we round up the size to the nearest
+ * power of two value, drivers consume *actual* size, so remaining
+ * portions are unused and it can be freed.
+ *
+ * Returns:
+ * 0 on success, error code on failure.
+ */
+int drm_buddy_block_trim(struct drm_buddy *mm,
+u64 new_size,
+struct list_head *blocks)
+{
+ struct drm_buddy_block *parent;
+ struct drm_buddy_block *block;
+ LIST_HEAD(dfs);
+ u64 new_start;
+ int err;
+
+ if (!list_is_singular(blocks))
+ return -EINVAL;
+
+ block = list_first_entry(blocks,
+struct drm_buddy_block,
+link);
+
+ if (!drm_buddy_block_is_allocated(block))
+ return -EINVAL;
+
+ if (new_size > drm_buddy_block_size(mm, block))
+ return -EINVAL;
+
+ if (!new_size && !IS_ALIGNED(new_size, mm->chunk_size))
+ return -EINVAL;
+
+ if (new_size == drm_buddy_block_size(mm, block))
+ return 0;
+
+ list_del(&block->link);
+ mark_free(mm, block);
+ mm->avail += drm_buddy_block_size(mm, block);
+
+ /* Prevent recursively freeing this node */
+ parent = block->parent;
+ block->parent = NULL;
+
+ new_start = drm_buddy_block_offset(block);
+ list_add(&block->tmp_link, &dfs);
+ err = __alloc_range(mm, &dfs, new_start, new_size, blocks);
+ if (err) {
+ mark_allocated(block);
+ mm->avail -= drm_buddy_block_size(mm, block);
+ list_add(&block->link, blocks);
+ }
+
+ block->parent = parent;
+ return err;
+}
+EXPORT_SYMBOL(drm_buddy_block_trim);
+
/**
* drm_buddy_alloc_blocks - allocate power-of-two blocks
*
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index 3662434b64bb..53eb100688a6 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -97,6 +97,16 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
if (unlikely(err))
goto err_free_blocks;
+ if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
+ u64 original_size = (u64)bman_res->base.num_pages << PAGE_SHIFT;
+
+ mutex_lock(&bman->lock);
+ drm_buddy_block_trim(mm,
+original_size,
+&bman_res->blocks);
+ mutex_unlock(&bman->lock);
+ }
+
*res = &bman_res->base;
return 0;
diff --git a/include/dr
[PATCH v9 6/6] drm/amdgpu: add drm buddy support to amdgpu
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
v2(Matthew Auld):
- replace spinlock with mutex as we call kmem_cache_zalloc
(..., GFP_KERNEL) in drm_buddy_alloc() function
- lock drm_buddy_block_trim() function as it calls
mark_free/mark_split are all globally visible
v3(Matthew Auld):
- remove trim method error handling as we address the failure case
at drm_buddy_block_trim() function
v4:
- fix warnings reported by kernel test robot
Signed-off-by: Arunpravin
---
drivers/gpu/drm/Kconfig | 1 +
.../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h| 97 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 7 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 259 ++
4 files changed, 231 insertions(+), 133 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index cc3e979c9c9d..ff5628c477b4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -278,6 +278,7 @@ config DRM_AMDGPU
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+ select DRM_BUDDY
help
Choose this option if you have a recent AMD Radeon graphics card.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index acfa207cf970..da12b4ff2e45 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -30,12 +30,15 @@
#include
#include
+#include "amdgpu_vram_mgr.h"
+
/* state back for walking over vram_mgr and gtt_mgr allocations */
struct amdgpu_res_cursor {
uint64_tstart;
uint64_tsize;
uint64_tremaining;
- struct drm_mm_node *node;
+ void*node;
+ uint32_tmem_type;
};
/**
@@ -52,27 +55,63 @@ static inline void amdgpu_res_first(struct ttm_resource
*res,
uint64_t start, uint64_t size,
struct amdgpu_res_cursor *cur)
{
+ struct drm_buddy_block *block;
+ struct list_head *head, *next;
struct drm_mm_node *node;
- if (!res || res->mem_type == TTM_PL_SYSTEM) {
- cur->start = start;
- cur->size = size;
- cur->remaining = size;
- cur->node = NULL;
- WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
- return;
- }
+ if (!res)
+ goto err_out;
BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
- node = to_ttm_range_mgr_node(res)->mm_nodes;
- while (start >= node->size << PAGE_SHIFT)
- start -= node++->size << PAGE_SHIFT;
+ cur->mem_type = res->mem_type;
+
+ switch (cur->mem_type) {
+ case TTM_PL_VRAM:
+ head = &to_amdgpu_vram_mgr_node(res)->blocks;
+
+ block = list_first_entry_or_null(head,
+struct drm_buddy_block,
+link);
+ if (!block)
+ goto err_out;
+
+ while (start >= amdgpu_node_size(block)) {
+ start -= amdgpu_node_size(block);
+
+ next = block->link.next;
+ if (next != head)
+ block = list_entry(next, struct
drm_buddy_block, link);
+ }
+
+ cur->start = amdgpu_node_start(block) + start;
+ cur->size = min(amdgpu_node_size(block) - start, size);
+ cur->remaining = size;
+ cur->node = block;
+ break;
+ case TTM_PL_TT:
+ node = to_ttm_range_mgr_node(res)->mm_nodes;
+ while (start >= node->size << PAGE_SHIFT)
+ start -= node++->size << PAGE_SHIFT;
+
+ cur->start = (node->start << PAGE_SHIFT) + start;
+ cur->size = min((node->size << PAGE_SHIFT) - start, size);
+ cur->remaining = size;
+ cur->node = node;
+ break;
+ default:
+ goto err_out;
+ }
- cur->start = (node->start << PAGE_SHIFT) + start;
- cur->size = min((node->size << PAGE_SHIFT) - start, size);
+ return;
+
+err_out:
+ cur->start = start;
+ cur->size = size;
cur->remaining = size;
- cur->node = node;
+ cur->node = NULL;
+ WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
+ return;
}
/**
@@ -85,7 +124,9 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
*/
static inline void amdgpu_res_next(struct amdgpu_res_cursor *cur, uint64_t
size)
{
- struct drm_mm_node *node = cur->node;
+ struct drm_buddy_block *block;
+ struct drm_mm_node *node;
+
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi Michel, Michel Dänzer writes: > On 2022-01-17 19:47, Sven Schnelle wrote: >> >>> * There's no new development in fbdev and there are no new >>>drivers. Everyone works on DRM, which is better in most >>>regards. The consequence is that userspace is slowly loosing the >>> ability to use fbdev. >> >> That might be caused by the fact that no new drivers are accepted for >> fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last >> year which was rejected for inclusion into fbdev[1]. >> >> Based on your recommendation i re-wrote the whole thing in DRM. This >> works but has several drawbacks: >> >> - no modesetting. With fbdev, i can nicely switch resolutions with >> fbset. That doesn't work, and i've been told that this is not supported[2] >> >> - It is *much* slower than fbset with hardware blitting. I would have to >> dig out the numbers, but it's in the ratio of 1:15. The nice thing >> with fbdev blitting is that i get an array of pixels and the >> foreground/background colors all of these these pixels should have. >> With the help of the hardware blitting, i can write 32 pixels at once >> with every 32-bit transfer. >> >> With DRM, the closest i could find was DRM_FORMAT_C8, which means one >> byte per pixel. So i can put 4 pixels into one 32-bit transfer. >> >> fbdev also clears the lines with hardware blitting, which is much >> faster than clearing it with memcpy. >> >> Based on your recommendation i also verified that pci coalescing is >> enabled. >> >> These numbers are with DRM's unnatural scrolling behaviour - it seems >> to scroll several (text)lines at once if it takes to much time. I >> guess if DRM would scroll line by line it would be even slower. >> >> If DRM would add those things - hardware clearing of memory regions, >> hw blitting for text with a FG/BG color and modesetting i wouldn't >> care about fbdev at all. But right now, it's working way faster for me. > > A DRM driver can implement the same fbdev acceleration hooks as an fbdev > driver. But i guess i can still only use the DRM_FORMAT_* encodings with that? What i need is a pixel bitmap with separate FG/BG colors. Is that possible? /Sven
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Mon, Jan 17, 2022 at 10:55 PM Ilia Mirkin wrote: > > On Mon, Jan 17, 2022 at 2:47 PM Helge Deller wrote: > > > > On 1/17/22 17:21, Helge Deller wrote: > > > On 1/17/22 16:58, Thomas Zimmermann wrote: > > >> Hi > > >> > > >> Am 17.01.22 um 16:42 schrieb Helge Deller: > > >>> [...] > > > c) reintroduce the state where fbcon is fast on fbdev. This is > > > important for non-DRM machines, > > > either when run on native hardware or in an emulator. > > > d) not break DRM development > > > > > > Especially regarding c) I complained in [1] and got no feedback. I > > > really would like to > > > understand where the actual problems were and what's necessary to fix > > > them. > > > > > > Helge > > > > > > [1] > > > https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723...@gmx.de > > >> > > >> Seems like few people read linux-fbdev these days. > > >> I suggest to partly revert the patch to the point were performance > > >> gets better again. > > > Yes, *please*! > > > That would solve my biggest concern. > > > > > > As far as I can see that's only 2 commits to be reverted: > > > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part > > > 1 (from TODO list)" > > > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next > > > > > > I think both were not related to any 0-day bug reports (but again, I > > > might be wrong). > > > > I did some more checking... > > > > Both patches are not related to DRM, since no DRM driver sets the > > FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags. > > These used to be set by, at least, nouveau (which is a drm driver). > And yeah, console responsiveness is _way_ worse without that. People > keep pushing the messaging that it's the same speed to do it as > memcpy, but that's just not the case in my experience, on a pretty > bog-standard x86 desktop. The support got dumped, and it felt pretty > clear from the messaging at the time, "too bad". Would love to see it > come back. You need to add in a shadow buffer and it's fast. The problem is that the default fbcon sw code just replaces a hw blitter, and so does a _lot_ of memmoves reading from wc/uc memory. Which is an absolute disaster and results in a slideshow. Once you stop doing that the thing is pretty reasonable, which would also be what all the userspace sw compositors are doing. Fact that no one bothers to roll this out for most drivers just shows how little people care about accelerated fbcon. -Daniel > > Cheers, > > -ilia -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/gt: make a gt sysfs group and move power management files
On 17/01/2022 19:32, Andi Shyti wrote:
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create a 'gt/' directory in sysfs which will contain gt0...gtN
directories related to each tile configured in the GPU. Move the
power management files inside those directories.
The previous power management files are kept in their original
root directory to avoid breaking the ABI. They point to the tile
'0' and a warning message is printed whenever accessed to. A
warning will be issued if the old interfaces will be accessed.
The new sysfs structure will have a similar layout for the 4 tile
case:
/sys/.../card0
├── gt
│ ├── gt0
│ │ ├── id
│ │ ├── rc6_enable
│ │ ├── rc6_residency_ms
│ │ ├── rps_act_freq_mhz
│ │ ├── rps_boost_freq_mhz
│ │ ├── rps_cur_freq_mhz
│ │ ├── rps_max_freq_mhz
│ │ ├── rps_min_freq_mhz
│ │ ├── rps_RP0_freq_mhz
│ │ ├── rps_RP1_freq_mhz
│ │ └── rps_RPn_freq_mhz
. .
. .
. .
│ └── gt3
│ ├── id
│ ├── rc6_enable
│ ├── rc6_residency_ms
│ ├── rps_act_freq_mhz
│ ├── rps_boost_freq_mhz
│ ├── rps_cur_freq_mhz
│ ├── rps_max_freq_mhz
│ ├── rps_min_freq_mhz
│ ├── rps_RP0_freq_mhz
│ ├── rps_RP1_freq_mhz
│ └── rps_RPn_freq_mhz
├── gt_act_freq_mhz -+
├── gt_boost_freq_mhz |
├── gt_cur_freq_mhz|Original interface
├── gt_max_freq_mhz+─-> kept as existing ABI;
├── gt_min_freq_mhz|it points to gt0/
├── gt_RP0_freq_mhz|
└── gt_RP1_freq_mhz|
└── gt_RPn_freq_mhz -+
As soon as multitile platforms will start being supported, this
interface will allow to control the power (either manually or
with tools) on each tile, instead of affecting only tile 0 and
getting incomplete results.
Signed-off-by: Andi Shyti
Signed-off-by: Lucas De Marchi
Cc: Matt Roper
Cc: Sujaritha Sundaresan
Cc: Tvrtko Ursulin
Reviewed-by: Sujaritha Sundaresan
---
drivers/gpu/drm/i915/Makefile | 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +
drivers/gpu/drm/i915/gt/sysfs_gt.c| 136 +
drivers/gpu/drm/i915/gt/sysfs_gt.h| 32 +++
drivers/gpu/drm/i915/gt/sysfs_gt_pm.c | 392 ++
drivers/gpu/drm/i915/gt/sysfs_gt_pm.h | 16 ++
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_sysfs.c | 315 +
drivers/gpu/drm/i915/i915_sysfs.h | 3 +
9 files changed, 596 insertions(+), 306 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.h
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index aa86ac33effc..5fd203c626fc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -121,7 +121,9 @@ gt-y += \
gt/intel_timeline.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
- gt/sysfs_engines.o
+ gt/sysfs_engines.o \
+ gt/sysfs_gt.o \
+ gt/sysfs_gt_pm.o
# autogenerated null render state
gt-y += \
gt/gen6_renderstate.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 17927da9e23e..2584c51c1c14 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -25,6 +25,7 @@
#include "intel_rps.h"
#include "intel_uncore.h"
#include "shmem_utils.h"
+#include "sysfs_gt.h"
#include "pxp/intel_pxp.h"
static void
@@ -453,6 +454,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
intel_rps_driver_register(>->rps);
intel_gt_debugfs_register(gt);
+ intel_gt_sysfs_register(gt);
}
static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
diff --git a/drivers/gpu/drm/i915/gt/sysfs_gt.c
b/drivers/gpu/drm/i915/gt/sysfs_gt.c
new file mode 100644
index ..7a2f1d91f221
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/sysfs_gt.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_sysfs.h"
+#include "intel_gt.h"
+#include "intel_gt_types.h"
+#include "intel_rc6.h"
+
+#include "sysfs_gt.h"
+#include "sysfs_gt_pm.h"
+
+bool is_object_gt(struct kobject *kobj)
Not sure if you will need it exported in a later patch but for now it
seems only users are local to this file.
Regards,
Tvrtko
+{
+ return !strncmp(kobj->name, "gt", 2);
+}
+
+static struct i
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Tue, Jan 18, 2022 at 9:56 AM Helge Deller wrote: > > On 1/18/22 09:38, Jani Nikula wrote: > > On Mon, 17 Jan 2022, Helge Deller wrote: > >> On 1/17/22 22:40, Jani Nikula wrote: > >>> On Mon, 17 Jan 2022, Thomas Zimmermann wrote: > Seems like few people read linux-fbdev these days. > >>> > >>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel > >>> also? > >> > >> Doesn't seem like much traffic - which IMHO is OK for such a tree with > >> mostly just maintenance patches. > >> > >>> Do we still need a separate linux-fbdev mailing list at all? > >> > >> Yes. I want to have it seperate of dri-devel. > >> Actually I'd prefer to drop dri-devel from the list where patches > >> for fbdev are sent... > > > > Disagreed. If anything, this thread shows we can't have fbdev and drm in > > silos of their own. > > Patches to fbdev usually don't affect DRM. > Patches which affect DRM needs to through to dri-devel. > In addition this would take the burden of the dri-developers to receive > unrelated fbdev driver updates and patches. I added dri-devel for fbdev because stuff landed that shouldn't have. Let's not remove that, because the amount of patches for fbdev which arent relevant for drm drivers is pretty much nothing. I really don't like the idea that fbdev goes off again becoming a silo, just because it's too hard to wire through low-bit greyscale support. Which no I can't type for you, because I don't have such hw here. Everything where people cared enough for adding fbdev compat support for to actually write a patch is supported. If you do want a silo for fbdev then I think the only reasonable option is that we create a copy of the fbdev/fbcon code for drm (somewhat renamed), so that you can do the reverts without impacting drm drivers. But there will still be some overlap and minimal coordination, plus I'm not seeing anyone from the drm side volunteering for the sizeable amount of work. -Daniel > > Also, if the patches continue to get merged through drm-misc, they need > > to be sent to dri-devel. > > Helge -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Tue, Jan 18, 2022 at 10:54 AM Gerd Hoffmann wrote: > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote: > > On Mon, 17 Jan 2022 19:47:39 +0100 > > Sven Schnelle wrote: > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > > > a dmesg with 919 lines one the text console took about 2s to display. In > > > x11, i measure 22ms. This might be unfair because encoding might be > > > different, but i cannot confirm the 'memcpy' is faster than hardware > > > blitting' point. I think if that would be the case, no-one would care > > > about 2D acceleration. > > > > I think that is an extremely unfair comparison, because a graphical > > terminal app is not going to render every line of text streamed to it. > > It probably renders only the final view alone if you simply run > > 'dmesg', skipping the first 800-900 lines completely. > > Probably more like "render on every vblank", but yes, unlike fbcon it > surely wouldn't render every single character sent to the terminal. > > Also acceleration on modern hardware is more like "compose window > content using the 3d engine" than "use 2d blitter to scroll the window". > > > Maybe fbcon should do the same when presented with a flood of text, > > but I don't know how or why it works like it works. > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of > doing it synchronously. Yeah, and if you use the shadow fb support in drm fbdev helpers, that's what you get. Maybe we should just make that the default, since that would also greatly simply stuff like modesetting support for fbdev. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Tue, Jan 18, 2022 at 9:41 AM Geert Uytterhoeven wrote:
>
> Hi Jani,
>
> On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula
> wrote:
> > On Mon, 17 Jan 2022, Helge Deller wrote:
> > > On 1/17/22 22:40, Jani Nikula wrote:
> > >> On Mon, 17 Jan 2022, Thomas Zimmermann wrote:
> > >>> Seems like few people read linux-fbdev these days.
> > >>
> > >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
> > >> also?
> > >
> > > Doesn't seem like much traffic - which IMHO is OK for such a tree with
> > > mostly just maintenance patches.
> > >
> > >> Do we still need a separate linux-fbdev mailing list at all?
> > >
> > > Yes. I want to have it seperate of dri-devel.
> > > Actually I'd prefer to drop dri-devel from the list where patches
> > > for fbdev are sent...
> >
> > Disagreed. If anything, this thread shows we can't have fbdev and drm in
> > silos of their own.
>
> Unless DRM drops fbdev support. Isn't that the long-term plan anyway?
No. There's way too much old stuff still using the fbdev interface to
do that. We've even done things like standardize the vblank wait
ioctl, because people need that.
There's some effort to make fbdev drivers like efifb obsolete, and
there's been discussions to have a drm-native fbcon. But none of these
are going to make fbdev on top of drm obsolete and something we can
remove. Pretty sure at least not this decade.
-Daniel
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On 1/18/22 12:18, Daniel Vetter wrote: > On Tue, Jan 18, 2022 at 9:56 AM Helge Deller wrote: >> >> On 1/18/22 09:38, Jani Nikula wrote: >>> On Mon, 17 Jan 2022, Helge Deller wrote: On 1/17/22 22:40, Jani Nikula wrote: > On Mon, 17 Jan 2022, Thomas Zimmermann wrote: >> Seems like few people read linux-fbdev these days. > > How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel > also? Doesn't seem like much traffic - which IMHO is OK for such a tree with mostly just maintenance patches. > Do we still need a separate linux-fbdev mailing list at all? Yes. I want to have it seperate of dri-devel. Actually I'd prefer to drop dri-devel from the list where patches for fbdev are sent... >>> >>> Disagreed. If anything, this thread shows we can't have fbdev and drm in >>> silos of their own. >> >> Patches to fbdev usually don't affect DRM. >> Patches which affect DRM needs to through to dri-devel. >> In addition this would take the burden of the dri-developers to receive >> unrelated fbdev driver updates and patches. > > I added dri-devel for fbdev because stuff landed that shouldn't have. > Let's not remove that, because the amount of patches for fbdev which > arent relevant for drm drivers is pretty much nothing. I'm fine with keeping both lists mentioned in the MAINTAINERS file. It was a proposal and I understand you want to keep it. Ok for me. > I really don't like the idea that fbdev goes off again becoming a > silo, just because it's too hard to wire through low-bit greyscale > support. Which no I can't type for you, because I don't have such hw > here. > > Everything where people cared enough for adding fbdev compat support > for to actually write a patch is supported. > > If you do want a silo for fbdev then I think the only reasonable > option is that we create a copy of the fbdev/fbcon code for drm > (somewhat renamed), so that you can do the reverts without impacting > drm drivers. I don't see *any impact* on drm drivers at all if both patches would be reverted now. > But there will still be some overlap and minimal > coordination, plus I'm not seeing anyone from the drm side > volunteering for the sizeable amount of work. I wonder why you don't want to give it a try? My current proposal is to revert those two changes. Reverting them does not affect DRM code. Both DRM and some fbdev drivers still share excactly the same code paths in the SCROLL_REDRAW case. In addition there are some fbdev drivers which provide 2D support and instead allow SCROLL_MOVE. That's it. Currently I don't know which other cleanups or refactorings of fbcon are planned from DRM side, but I'm sure there is a easy way to keep both supported. If it then really turns out that it's not possible we can decide then how to continue. Helge > -Daniel > >>> Also, if the patches continue to get merged through drm-misc, they need >>> to be sent to dri-devel. >> >> Helge > > >
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Tue, Jan 18, 2022 at 9:10 AM Geert Uytterhoeven wrote:
>
> Hi Gerd,
>
> On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann wrote:
> > Also note that using a shadow framebuffer allows to decouple fbcon
> > updates and scanout framebuffer updates. Can be used to speed up
> > things without depending on the 2d blitter.
>
> Assuming accesses to the shadow frame buffer are faster than accesses
> to the scanout frame buffer. While this is true on modern hardware,
> this is not the case on all hardware. Especially if the shadow frame
> buffer has a higher depth (XRGB) than the scanout frame buffer
> (e.g. Cn)...
>
> The funny thing is that the systems we are interested in, once used
> to be known for their graphics capabilities and/or performance...
That's just a pure strawman. No one is forcing you to run your shadow
buffer with xrgb. You can already do C8, any any other C1 is a few
lines of code. Which I can't type for you, because I don't have such
high performance hardware, but if someone would have spent hacking
instead of typing mails any time this came up the past few years, we'd
have it long ago. It's really not hard.
Same goes for modesetting support in the fbdev emulation layer (that's
a bit more work, but really not much) and really anything. And we do
actually merge additions in the emulation support pretty quickly. If
they show up.
-Daniel
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi, > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of > > doing it synchronously. > > Yeah, and if you use the shadow fb support in drm fbdev helpers, > that's what you get. Maybe we should just make that the default, since > that would also greatly simply stuff like modesetting support for > fbdev. Yep, that helps of course. I was thinking more about the chars + attrs + font -> framebuffer step in the fbcon rendering pipeline though where one could do something simliar to save even more cpu cycles. take care, Gerd
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Tuesday, January 18th, 2022 at 12:41, Daniel Vetter wrote: > On Tue, Jan 18, 2022 at 9:41 AM Geert Uytterhoeven > wrote: > > > > Hi Jani, > > > > On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula > > wrote: > > > On Mon, 17 Jan 2022, Helge Deller wrote: > > > > On 1/17/22 22:40, Jani Nikula wrote: > > > >> On Mon, 17 Jan 2022, Thomas Zimmermann wrote: > > > >>> Seems like few people read linux-fbdev these days. > > > >> > > > >> How much traffic is there to linux-fbdev that is *not* Cc'd to > > > >> dri-devel > > > >> also? > > > > > > > > Doesn't seem like much traffic - which IMHO is OK for such a tree with > > > > mostly just maintenance patches. > > > > > > > >> Do we still need a separate linux-fbdev mailing list at all? > > > > > > > > Yes. I want to have it seperate of dri-devel. > > > > Actually I'd prefer to drop dri-devel from the list where patches > > > > for fbdev are sent... > > > > > > Disagreed. If anything, this thread shows we can't have fbdev and drm in > > > silos of their own. > > > > Unless DRM drops fbdev support. Isn't that the long-term plan anyway? > > No. There's way too much old stuff still using the fbdev interface to > do that. We've even done things like standardize the vblank wait > ioctl, because people need that. Kind of related: I wonder, could we document somewhere that fbdev is a deprecated uAPI? ie. new user-space shouldn't use it and should prefer DRM. I don't see that mentioned anywhere, although it seems like it's the consensus among all kernel developers I've talked to.
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi, > > fbcon/fbdev emulation: RGB332 support must be added I think. But both > > argb888 and rgb565 are supported today, so it should not be hard to find > > the places where you have to add some code to handle RGB332 too. > > I'd expect that that framework is provided by DRM developers if there is the > wish > to get rid of old fbdev and transition existing drivers over to use DRM. Good luck with that. Asking people to code up stuff they can't even test due to lack of hardware isn't going to fly very well. > > Yes. The world shifted from 2d acceleration to 3d acceleration. Modern > > hardware simply has no classic blitter any more. Which is a problem > > when it comes to keeping scroll acceleration alive, it is already a very > > niche use case and it will only become worse ... > > For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today > with the arguments mentioned multiple times). > But the patches broke existing fbdev acceleration which is available by > the fbdev drivers. That's a big regression from point of fbdev. Keeping it alive and working will be a tough challenge. 2d acceleration is a thing of the past and the number of people which are able and willing to put effort into supporting it will only decline. It has been a problem for a while already, basically it was dropped due to lack of support ... take care, Gerd
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/gt: make a gt sysfs group and move power management files
Hi Tvrtko, > > +bool is_object_gt(struct kobject *kobj) > > Not sure if you will need it exported in a later patch but for now it seems > only users are local to this file. it is actually used by sysfs_gt.c and sysfs_gt_pm.c. Thank you, Andi PS. in this v4 I forgot to replace many drm_err() with drm_warn(), will do it properly in the next version.
[PATCH 1/2] drm: mediatek: mtk_drm_plane: Use kmalloc in mtk_plane_duplicate_state
There is no need to zero out the newly allocated memory because we are duplicating all members of struct mtk_plane_state: switch to kmalloc to save some overhead. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c index c74cb94e445e..39cb9a80d976 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c @@ -57,7 +57,7 @@ static struct drm_plane_state *mtk_plane_duplicate_state(struct drm_plane *plane struct mtk_plane_state *old_state = to_mtk_plane_state(plane->state); struct mtk_plane_state *state; - state = kzalloc(sizeof(*state), GFP_KERNEL); + state = kmalloc(sizeof(*state), GFP_KERNEL); if (!state) return NULL; -- 2.33.1
[PATCH 2/2] drm: mediatek: mtk_drm_crtc: Use kmalloc in mtk_drm_crtc_duplicate_state
Optimize mtk_drm_crtc_duplicate_state() by switching from kzalloc() to
kmalloc(): the only variable of this struct that gets checked in other
functions is `pending_config`, but if that's set to false, then all of
the remaining variables will only ever be set, but not read - so, also
set `pending_config` to false.
This saves us some small overhead.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 09fc9ad02c7a..f536a0a927e4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -185,7 +185,7 @@ static struct drm_crtc_state
*mtk_drm_crtc_duplicate_state(struct drm_crtc *crtc
{
struct mtk_crtc_state *state;
- state = kzalloc(sizeof(*state), GFP_KERNEL);
+ state = kmalloc(sizeof(*state), GFP_KERNEL);
if (!state)
return NULL;
@@ -193,6 +193,7 @@ static struct drm_crtc_state
*mtk_drm_crtc_duplicate_state(struct drm_crtc *crtc
WARN_ON(state->base.crtc != crtc);
state->base.crtc = crtc;
+ state->pending_config = false;
return &state->base;
}
--
2.33.1
Re: [PATCH] drm/amdgpu: Add missing pm_runtime_put_autosuspend
On 1/18/2022 5:31 PM, Yongzhi Liu wrote:
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code, thus a matching decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Yongzhi Liu
Thanks!
Reviewed-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 9aea1cc..4b950de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1120,8 +1120,10 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct file
*f, char __user *buf,
return -EINVAL;
r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
- if (r < 0)
+ if (r < 0) {
+ pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
return r;
+ }
while (size) {
uint32_t value;
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi Am 17.01.22 um 19:47 schrieb Sven Schnelle: Hi Thomas, Thomas Zimmermann writes: Hi Am 14.01.22 um 19:11 schrieb Helge Deller: The fbdev layer is orphaned, but seems to need some care. So I'd like to step up as new maintainer. Signed-off-by: Helge Deller First of all, thank you for stepping up to maintain the fbdev codebase. It really needs someone actively looking after it. And now comes the BUT. I want to second everything said by Danial and Javier. In addition to purely organizational topics (trees, PRs, etc), there are a number of inherit problems with fbdev. * It's 90s technology. Neither does it fit today's userspace, not hardware. If you have more than just the most trivial of graphical output fbdev isn't for you. * There's no new development in fbdev and there are no new drivers. Everyone works on DRM, which is better in most regards. The consequence is that userspace is slowly loosing the ability to use fbdev. That might be caused by the fact that no new drivers are accepted for And that is caused by the fact that fbdev is nowhere up to todays requirements. fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last year which was rejected for inclusion into fbdev[1]. Yep, I was hoping for a reply. Based on your recommendation i re-wrote the whole thing in DRM. This works but has several drawbacks: - no modesetting. With fbdev, i can nicely switch resolutions with fbset. That doesn't work, and i've been told that this is not supported[2] I didn't say that we're not going to support it at all. It's just not supported at the momont. vmwgfx has modesetting code that can serve as starting point. - It is *much* slower than fbset with hardware blitting. I would have to dig out the numbers, but it's in the ratio of 1:15. The nice thing with fbdev blitting is that i get an array of pixels and the foreground/background colors all of these these pixels should have. With the help of the hardware blitting, i can write 32 pixels at once with every 32-bit transfer. For comparison, how fast is fbdev with plain memcpy() and memset()? With DRM, the closest i could find was DRM_FORMAT_C8, which means one byte per pixel. So i can put 4 pixels into one 32-bit transfer. IIRC the hardware only supported 8-bit palette colors, so C8 was the correct choice. Otherwise, you can add new formats and add them to the console. fbdev also clears the lines with hardware blitting, which is much faster than clearing it with memcpy. Based on your recommendation i also verified that pci coalescing is enabled. These numbers are with DRM's unnatural scrolling behaviour - it seems to scroll several (text)lines at once if it takes to much time. I guess if DRM would scroll line by line it would be even slower. If DRM would add those things - hardware clearing of memory regions, hw blitting for text with a FG/BG color and modesetting i wouldn't care about fbdev at all. But right now, it's working way faster for me. I admit that your hardware is at the edge of what DRM currently supports. But I've used some of the DRM stuff on Athlon XPs with PCI graphics. While the performance wasn't good, it was far from unusable. I guess you used GEM SHMEM for memory buffers. fbdev and mmap with shmem pages use some of the same bits in struct page, so shmem cannot mmap it's pages directly. We have to use an additional shadow buffer. Any display update goes from the shadow buffer into the shmem buffer and into the videoram. That's two memcpys. This can be reduced to one memcpy, but we never had the requirement to do so. There's also potential for reducing the amount of page mappings/unmappings with gem shmem. And DRM supports shadow buffers, virtual screen sizes and damage handling in DRM. A sophisticated driver might be able to use shadow buffering, damage handling and hardware panning to reduce the amount of screen updates to a minimum. Until these things are fixed, adding hardware blitting doesn't really make sense IMHO. As with other things, we didn't have a requirement for all these optimizations so far. A usually good approach to improve the sitution is to get a basic driver merged and then address the problems one by one. Best regards Thomas I also tested the speed on my Thinkpad X1 with Intel graphics, and there a dmesg with 919 lines one the text console took about 2s to display. In x11, i measure 22ms. This might be unfair because encoding might be different, but i cannot confirm the 'memcpy' is faster than hardware blitting' point. I think if that would be the case, no-one would care about 2D acceleration. Don't get me wrong, i'm not saying there's no reason for DRM. I fully understand why it exists and think it's a good way to go. But for system where a (fast) local console is required without X11, fbdev might be the better choice at the moment. Regards Sven [1] htt
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi Am 17.01.22 um 17:21 schrieb Helge Deller: On 1/17/22 16:58, Thomas Zimmermann wrote: Hi Am 17.01.22 um 16:42 schrieb Helge Deller: [...] c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, either when run on native hardware or in an emulator. d) not break DRM development Especially regarding c) I complained in [1] and got no feedback. I really would like to understand where the actual problems were and what's necessary to fix them. Helge [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723...@gmx.de Seems like few people read linux-fbdev these days. I suggest to partly revert the patch to the point were performance gets better again. If you want that, you should send a patch. Best regards Thomas Yes, *please*! That would solve my biggest concern. As far as I can see that's only 2 commits to be reverted: b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next I think both were not related to any 0-day bug reports (but again, I might be wrong). Helge -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi
Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven:
Hi Gerd,
On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann wrote:
Also note that using a shadow framebuffer allows to decouple fbcon
updates and scanout framebuffer updates. Can be used to speed up
things without depending on the 2d blitter.
Assuming accesses to the shadow frame buffer are faster than accesses
to the scanout frame buffer. While this is true on modern hardware,
this is not the case on all hardware. Especially if the shadow frame
buffer has a higher depth (XRGB) than the scanout frame buffer
(e.g. Cn)...
The funny thing is that the systems we are interested in, once used
to be known for their graphics capabilities and/or performance...
What I still don't understand: why are you so keen on maintaining an
interface that only serves the console? Nothing else uses fbdev these
days. Why not improve DRM/userspace to the point where it fits your
requirements? Long-term, the latter would make a lot more sense.
Best regards
Thomas
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Tuesday, January 18th, 2022 at 15:23, Thomas Zimmermann wrote: > Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven: > > Hi Gerd, > > > > On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann wrote: > >> Also note that using a shadow framebuffer allows to decouple fbcon > >> updates and scanout framebuffer updates. Can be used to speed up > >> things without depending on the 2d blitter. > > > > Assuming accesses to the shadow frame buffer are faster than accesses > > to the scanout frame buffer. While this is true on modern hardware, > > this is not the case on all hardware. Especially if the shadow frame > > buffer has a higher depth (XRGB) than the scanout frame buffer > > (e.g. Cn)... > > > > The funny thing is that the systems we are interested in, once used > > to be known for their graphics capabilities and/or performance... > > What I still don't understand: why are you so keen on maintaining an > interface that only serves the console? Nothing else uses fbdev these > days. Why not improve DRM/userspace to the point where it fits your > requirements? Long-term, the latter would make a lot more sense. +1 If you need any help with adapting user-space, feel free to ping me. I'd be interested in discussing, providing feedback and potentially user-space patches.
Re: [PATCH] drm/i915: Add locking to i915_gem_evict_vm(), v3.
Op 17-01-2022 om 15:08 schreef Thomas Hellström: > > On 1/17/22 08:56, Maarten Lankhorst wrote: >> i915_gem_evict_vm will need to be able to evict objects that are >> locked by the current ctx. By testing if the current context already >> locked the object, we can do this correctly. This allows us to >> evict the entire vm even if we already hold some objects' locks. >> >> Previously, this was spread over several commits, but it makes >> more sense to commit the changes to i915_gem_evict_vm separately >> from the changes to i915_gem_evict_something() and >> i915_gem_evict_for_node(). >> >> Changes since v1: >> - Handle evicting dead objects better. >> Changes since v2: >> - Use for_i915_gem_ww in igt_evict_vm. (Thomas) >> >> Signed-off-by: Maarten Lankhorst > > Reviewed-by: Thomas Hellström > > (Please note the series checkpatch- and DOC warnings before commiting!) > > Thanks, > > Thomas > > Fixed and pushed. :) ~Maarten
Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Paul, any insights on the JZ_REG_LCD_OSDC issue below? There is a second, unrelated issue with the introduction of "drm/bridge: display-connector: implement bus fmts callbacks" which breaks bus format negotiations. These are the two last unsolved issues to submit a fully working driver. > Am 22.12.2021 um 15:03 schrieb H. Nikolaus Schaller : > >> Am 08.11.2021 um 10:37 schrieb Paul Cercueil : >> >> Hi Nikolaus, >> >> Le dim., nov. 7 2021 at 21:25:38 +0100, H. Nikolaus Schaller >> a écrit : >>> Hi Paul, >>> >>> @@ -1274,7 +1319,7 @@ static int ingenic_drm_bind(struct device *dev, >>> bool has_components) >>> /* Enable OSD if available */ >>> if (soc_info->has_osd) >>> - regmap_write(priv->map, JZ_REG_LCD_OSDC, >>> JZ_LCD_OSDC_OSDEN); >>> + regmap_set_bits(priv->map, JZ_REG_LCD_OSDC, >>> JZ_LCD_OSDC_OSDEN); >> This change is unrelated to this patch, and I'm not even sure it's a >> valid change. The driver shouldn't rely on previous register values. > I think I already commented that I think the driver should also not reset > previous register values to zero. You did comment this, yes, but I don't agree. The driver *should* reset the registers to zero. It should *not* have to rely on whatever was configured before. Even if I did agree, this is a functional change unrelated to JZ4780 support, so it would have to be splitted to its own patch. >>> Well it is in preparation of setting more bits that are only available for >>> the jz4780. >>> But it will be splitted into its own patch for other reasons - if we ever >>> make osd working... > If I counted correctly this register has 18 bits which seem to include > some interrupt masks (which could be initialized somewhere else) and we > write a constant 0x1. > Of course most other bits are clearly OSD related (alpha blending), > i.e. they can have any value (incl. 0) if OSD is disabled. But here we > enable it. I think there may be missing some setting for the other bits. > So are you sure, that we can unconditionally reset *all* bits > except JZ_LCD_OSDC_OSDEN for the jz4780? > Well I have no experience with OSD being enabled at all. I.e. I have no > test scenario. > > It turns out that the line > > ret = clk_prepare_enable(priv->lcd_clk); > > initializes JZ_REG_LCD_OSDC to 0x00010005 (i.e. printk tells 0x0 before). more detailled test shows that it is the underlying clk_enable(priv->lcd_clk) (i.e. not the prepare). > > and writing > > regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN); > > overwrites it with 0x0001. > > This makes the HDMI monitor go/stay black until I write manually 0x5 to > JZ_REG_LCD_OSDC. > > This means that JZ_LCD_OSDC_ALPHAEN must be enabled on jz4780 as well. > Hence overwriting just with JZ_LCD_OSDC_OSDEN breaks it. > > Now the questions: > a) 0x5 is understandable that it sets JZ_LCD_OSDC_ALPHAEN - but why is it > needed? > Is this a not well documented difference between jz4740/60/70/80? > b) how can clk_prepare_enable() write 0x00010005 to JZ_REG_LCD_OSDC? Bug or > feature? > Something in cgu driver going wrong? I now suspect that it is an undocumented SoC feature. > c) what do your SoC or panels do if you write 0x5 to JZ_REG_LCD_OSDC? > d) 0x00010005 also has bit 16 set which is undocumented... But this is a > don't care > according to jz4780 PM. BR and thanks, Nikolaus
[PATCH 1/2] drm/msm: add support for QCM2290 MDSS
Add compatibility for QCM2290 display subsystem, including
required entries in DPU hw catalog.
Signed-off-by: Loic Poulain
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 175 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
4 files changed, 177 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index ce6f32a..7fa3fc7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -25,6 +25,8 @@
#define VIG_SM8250_MASK \
(VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE))
+#define VIG_QCM2290_MASK VIG_MASK
+
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -251,6 +253,18 @@ static const struct dpu_caps sc7280_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
+static const struct dpu_caps qcm2290_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0x4,
+ .qseed_type = DPU_SSPP_SCALER_QSEED4,
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2,
+ .ubwc_version = DPU_HW_UBWC_VER_20,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .max_linewidth = 2160,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -336,6 +350,19 @@ static const struct dpu_mdp_cfg sc7280_mdp[] = {
},
};
+static const struct dpu_mdp_cfg qcm2290_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = 0,
+ .highest_bank_bit = 0x2,
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+ .reg_off = 0x2AC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+ .reg_off = 0x2AC, .bit_off = 8},
+ },
+};
+
/*
* CTL sub blocks config
*/
@@ -459,6 +486,15 @@ static const struct dpu_ctl_cfg sc7280_ctl[] = {
},
};
+static const struct dpu_ctl_cfg qcm2290_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x1000, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+};
+
/*
* SSPP sub blocks config
*/
@@ -595,6 +631,30 @@ static const struct dpu_sspp_cfg sc7280_sspp[] = {
sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
};
+
+#define _QCM2290_VIG_SBLK(num, sdma_pri) \
+ { \
+ .maxdwnscale = SSPP_UNITY_SCALE, \
+ .maxupscale = SSPP_UNITY_SCALE, \
+ .smart_dma_priority = sdma_pri, \
+ .src_blk = {.name = STRCAT("sspp_src_", num), \
+ .id = DPU_SSPP_SRC, .base = 0x00, .len = 0x150,}, \
+ .format_list = plane_formats_yuv, \
+ .num_formats = ARRAY_SIZE(plane_formats_yuv), \
+ .virt_format_list = plane_formats, \
+ .virt_num_formats = ARRAY_SIZE(plane_formats), \
+ }
+
+static const struct dpu_sspp_sub_blks qcm2290_vig_sblk_0 =
_QCM2290_VIG_SBLK("0", 2);
+static const struct dpu_sspp_sub_blks qcm2290_dma_sblk_0 = _DMA_SBLK("8", 1);
+
+static const struct dpu_sspp_cfg qcm2290_sspp[] = {
+ SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_QCM2290_MASK,
+qcm2290_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
+ SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK,
+qcm2290_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
+};
+
/*
* MIXER sub blocks config
*/
@@ -679,6 +739,21 @@ static const struct dpu_lm_cfg sc7280_lm[] = {
&sc7180_lm_sblk, PINGPONG_3, LM_2, 0),
};
+/* QCM2290 */
+
+static const struct dpu_lm_sub_blks qcm2290_lm_sblk = {
+ .maxwidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .maxblendstages = 4, /* excluding base layer */
+ .blendstage_base = { /* offsets relative to mixer base */
+ 0x20, 0x38, 0x50, 0x68
+ },
+};
+
+static const struct dpu_lm_cfg qcm2290_lm[] = {
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_SC7180_MASK,
+ &qcm2290_lm_sblk, PINGPONG_0, 0, DSPP_0),
+};
+
/*
* DSPP sub blocks config
*/
@@ -692,6 +767,11 @@ static const struct dpu_dspp_sub_blks sm8150_dspp_sblk = {
.len
[PATCH 2/2] dt-bindings: msm: disp: add yaml schemas for QCM2290 DPU bindings
QCM2290 MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI etc. Add YAML schema for DPU device
tree bindings
Signed-off-by: Loic Poulain
---
.../bindings/display/msm/dpu-qcm2290.yaml | 214 +
1 file changed, 214 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
new file mode 100644
index ..8766b13
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
@@ -0,0 +1,214 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dpu-qcm2290.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU dt properties for QCM2290 target
+
+maintainers:
+ - Loic Poulain
+
+description: |
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller and DSI. Device tree bindings of MDSS
+ and DPU are mentioned for QCM2290 target.
+
+properties:
+ compatible:
+items:
+ - const: qcom,qcm2290-mdss
+
+ reg:
+maxItems: 1
+
+ reg-names:
+const: mdss
+
+ power-domains:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Display AHB clock from gcc
+ - description: Display AXI clock
+ - description: Display core clock
+
+ clock-names:
+items:
+ - const: iface
+ - const: bus
+ - const: core
+
+ interrupts:
+maxItems: 1
+
+ interrupt-controller: true
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+ "#interrupt-cells":
+const: 1
+
+ iommus:
+items:
+ - description: Phandle to apps_smmu node with SID mask for Hard-Fail
port0
+ - description: Phandle to apps_smmu node with SID mask for Hard-Fail
port1
+
+ ranges: true
+
+ interconnects:
+items:
+ - description: Interconnect path specifying the port ids for data bus
+
+ interconnect-names:
+const: mdp0-mem
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+type: object
+description: Node containing the properties of DPU.
+
+properties:
+ compatible:
+items:
+ - const: qcom,qcm2290-dpu
+
+ reg:
+items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+items:
+ - description: Display AXI clock from gcc
+ - description: Display AHB clock from dispcc
+ - description: Display core clock from dispcc
+ - description: Display lut clock from dispcc
+ - description: Display vsync clock from dispcc
+
+ clock-names:
+items:
+ - const: bus
+ - const: iface
+ - const: core
+ - const: lut
+ - const: vsync
+
+ interrupts:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ operating-points-v2: true
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description: |
+ Contains the list of output ports from DPU device. These ports
+ connect to interfaces that are external to the DPU hardware,
+ such as DSI. Each output port contains an endpoint that
+ describes how it is connected to an external interface.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: DPU_INTF1 (DSI1)
+
+required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - interrupts
+ - power-domains
+ - operating-points-v2
+ - ports
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - power-domains
+ - clocks
+ - interrupts
+ - interrupt-controller
+ - iommus
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+
+mdss: mdss@5e0 {
+#address-cells = <1>;
+#size-cells = <1>;
+compatible = "qcom,qcm2290-mdss", "qcom,mdss";
+reg = <0x05e0 0x1000>;
+reg-names = "mdss";
+power-domains = <&dispcc MDSS_GDSC>;
+clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+clock-names = "iface", "bus", "core";
+
+interrupts = ;
+interrupt-controller;
+#interrupt-cells = <1>;
+
+interconnects = <&mmrt_virt MASTER_MDP0 &bimc SLAVE_EBI1>;
+interconnect-names = "mdp0-mem";
+
+iommus = <&apps_smmu 0x420 0x2>,
+ <&apps_smmu 0x421 0x0>;
+ranges;
+
+mdss_mdp: mdp@5e01000 {
+
[PATCH] drm/selftests: Select DRM_DP_HELPER
Resolve warnings about non-existing symbols by selecting DRM_DP_HELPER.
Signed-off-by: Thomas Zimmermann
Fixes: adb9d5a2cc77 ("drm/dp: Move DisplayPort helpers into separate helper
module")
Reported-by: kernel test robot
Cc: Lyude Paul
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 91f54aeb0b7c..6589d931 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -68,6 +68,7 @@ config DRM_DEBUG_SELFTEST
depends on DRM
depends on DEBUG_KERNEL
select PRIME_NUMBERS
+ select DRM_DP_HELPER
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
select DRM_EXPORT_FOR_TESTS if m
--
2.34.1
[PATCH] drm/msm: Fix include statements for DisplayPort
Update the include statements for DisplayPort helpers. The header
files are in the dp/ subdirectory.
Signed-off-by: Thomas Zimmermann
Fixes: 5b529e8d9c38 ("drm/dp: Move public DisplayPort headers into dp/")
Reported-by: kernel test robot
Cc: Lyude Paul
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/msm/edp/edp.h | 2 +-
drivers/gpu/drm/msm/edp/edp_ctrl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/edp/edp.h b/drivers/gpu/drm/msm/edp/edp.h
index 8590f2ce274d..1a82d7a4af9f 100644
--- a/drivers/gpu/drm/msm/edp/edp.h
+++ b/drivers/gpu/drm/msm/edp/edp.h
@@ -10,9 +10,9 @@
#include
#include
#include
+#include
#include
#include
-#include
#include "msm_drv.h"
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index a68a4a1867c1..9f537b1fd849 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -6,8 +6,8 @@
#include
#include
#include
+#include
#include
-#include
#include
#include "edp.h"
--
2.34.1
Re: [PATCH v3] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Fri, Oct 22, 2021 at 12:51:12PM -0700, Navare, Manasi wrote:
>
> Hi Ville,
>
> Could you take a look at this, this addresses teh review comments from prev
> version
I don't think I ever got an answer to my question as to whether this
was tested with all the interesting scenarios:
1) just with the master crtc added by userspace into the commit
2) just with the slave crtc added by userspace into the commit
3) both crtcs added by userspace into the commit
I guess 1) has been tested since that happens all the time, but the other
two scanarios would likely need to be done with a synthetic test to make
sure we're actually hitting them.
I think it *should* work, but I'd like to have real proof of that.
Reviewed-by: Ville Syrjälä
>
> Manasi
>
> On Mon, Oct 04, 2021 at 04:59:13AM -0700, Manasi Navare wrote:
> > In case of a modeset where a mode gets split across mutiple CRTCs
> > in the driver specific implementation (bigjoiner in i915) we wrongly count
> > the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC
> > as
> > an affected CRTC in atomic_check_only().
> > This triggers a warning since affected CRTCs doent match requested CRTC.
> >
> > To fix this in such bigjoiner configurations, we should only
> > increment affected crtcs if that CRTC is enabled in UAPI not
> > if it is just used internally in the driver to split the mode.
> >
> > v3: Add the same uapi crtc_state->enable check in requested
> > crtc calc (Ville)
> >
> > Cc: Ville Syrjälä
> > Cc: Simon Ser
> > Cc: Pekka Paalanen
> > Cc: Daniel Stone
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/drm_atomic.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index ff1416cd609a..a1e4c7905ebb 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1310,8 +1310,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> >
> > DRM_DEBUG_ATOMIC("checking %p\n", state);
> >
> > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > - requested_crtc |= drm_crtc_mask(crtc);
> > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > + if (new_crtc_state->enable)
> > + requested_crtc |= drm_crtc_mask(crtc);
> > + }
> >
> > for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> > new_plane_state, i) {
> > ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> > @@ -1360,8 +1362,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > }
> > }
> >
> > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > - affected_crtc |= drm_crtc_mask(crtc);
> > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > + if (new_crtc_state->enable)
> > + affected_crtc |= drm_crtc_mask(crtc);
> > + }
> >
> > /*
> > * For commits that allow modesets drivers can add other CRTCs to the
> > --
> > 2.19.1
> >
--
Ville Syrjälä
Intel
Re: [PATCH] mgag200 fix memmapsl configuration in GCTL6 register
Hello Jocelyn, On 1/14/22 10:47, Jocelyn Falempe wrote: > On some server with MGA G200e (rev 42), booting with Legacy BIOS, > The hardware hangs when using kdump and kexec into the kdump kernel. > This happens when the uncompress code tries to write "Decompressing Linux" > to the VGA Console. > > It can be reproduced by writing to the VGA console (0xB8000) after > booting to graphic mode, it generates the following error: > > kernel:NMI: PCI system error (SERR) for reason a0 on CPU 0. > kernel:Dazed and confused, but trying to continue > > The root cause is a bad configuration of the MGA GCTL6 register > > According to the GCTL6 register documentation: > > bit 0 is gcgrmode: > 0: Enables alpha mode, and the character generator addressing system is > activated. > 1: Enables graphics mode, and the character addressing system is not used. > > bit 1 is chainodd even: > 0: The A0 signal of the memory address bus is used during system memory > addressing. > 1: Allows A0 to be replaced by either the A16 signal of the system > address (if > memmapsl is ‘00’), or by the hpgoddev (MISC<5>, odd/even page select) > field, > described on page 3-294). > > bit 3-2 are memmapsl: > Memory map select bits 1 and 0. VGA. > These bits select where the video memory is mapped, as shown below: > 00 => Ah - Bh > 01 => Ah - Ah > 10 => Bh - B7FFFh > 11 => B8000h - Bh > > bit 7-4 are reserved. > > Current driver code set it to 0x05 => memmapsl to b01 => 0xA > but on x86, the VGA console is at 0xB8000 I think this need some rewording after imirkin's explanation that 0xA is the address of the VGA video memory and 0xB8000 the address of the VGA text buffer. > arch/x86/boot/compressed/misc.c define vidmem to 0xb8000 in extract_kernel() > so it's better to configure it to b11 > Thus changing the value 0x05 to 0x0d > > Signed-off-by: Jocelyn Falempe > --- > drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c > b/drivers/gpu/drm/mgag200/mgag200_mode.c > index b983541a4c53..c7f63610b278 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_mode.c > +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c > @@ -529,7 +529,7 @@ static void mgag200_set_format_regs(struct mga_device > *mdev, > WREG_GFX(3, 0x00); > WREG_GFX(4, 0x00); > WREG_GFX(5, 0x40); > - WREG_GFX(6, 0x05); > + WREG_GFX(6, 0x0d); My worry is if this could cause other issues so I would only do this change if (is_kdump_kernel()), to make it as non intrusive as possible. And also add a verbose comment about why this is needed. If you make those changes, feel free to add: Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH] mgag200 fix memmapsl configuration in GCTL6 register
On 18/01/2022 17:38, Javier Martinez Canillas wrote: Hello Jocelyn, On 1/14/22 10:47, Jocelyn Falempe wrote: My worry is if this could cause other issues so I would only do this change if (is_kdump_kernel()), to make it as non intrusive as possible. And also add a verbose comment about why this is needed. This change must be done in the "first" kernel, so that when kdump starts, it doesn't hang the machine by writing to the VGA interface, in the early boot code. To make this change less intrusive, we can do it only on problematic hardware (G200_SE rev 42), but Thomas said it was probably not needed. If you make those changes, feel free to add: Reviewed-by: Javier Martinez Canillas Best regards,
Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Nikolaus, Le mar., janv. 18 2022 at 15:50:01 +0100, H. Nikolaus Schaller a écrit : Hi Paul, any insights on the JZ_REG_LCD_OSDC issue below? Sorry, I missed your previous email. I blame the holidays ;) There is a second, unrelated issue with the introduction of "drm/bridge: display-connector: implement bus fmts callbacks" which breaks bus format negotiations. These are the two last unsolved issues to submit a fully working driver. Am 22.12.2021 um 15:03 schrieb H. Nikolaus Schaller : Am 08.11.2021 um 10:37 schrieb Paul Cercueil : Hi Nikolaus, Le dim., nov. 7 2021 at 21:25:38 +0100, H. Nikolaus Schaller a écrit : Hi Paul, @@ -1274,7 +1319,7 @@ static int ingenic_drm_bind(struct device *dev, bool has_components) /* Enable OSD if available */ if (soc_info->has_osd) - regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN); + regmap_set_bits(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN); This change is unrelated to this patch, and I'm not even sure it's a valid change. The driver shouldn't rely on previous register values. I think I already commented that I think the driver should also not reset previous register values to zero. You did comment this, yes, but I don't agree. The driver *should* reset the registers to zero. It should *not* have to rely on whatever was configured before. Even if I did agree, this is a functional change unrelated to JZ4780 support, so it would have to be splitted to its own patch. Well it is in preparation of setting more bits that are only available for the jz4780. But it will be splitted into its own patch for other reasons - if we ever make osd working... If I counted correctly this register has 18 bits which seem to include some interrupt masks (which could be initialized somewhere else) and we write a constant 0x1. Of course most other bits are clearly OSD related (alpha blending), i.e. they can have any value (incl. 0) if OSD is disabled. But here we enable it. I think there may be missing some setting for the other bits. So are you sure, that we can unconditionally reset *all* bits except JZ_LCD_OSDC_OSDEN for the jz4780? Well I have no experience with OSD being enabled at all. I.e. I have no test scenario. It turns out that the line ret = clk_prepare_enable(priv->lcd_clk); initializes JZ_REG_LCD_OSDC to 0x00010005 (i.e. printk tells 0x0 before). more detailled test shows that it is the underlying clk_enable(priv->lcd_clk) (i.e. not the prepare). and writing regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN); overwrites it with 0x0001. This makes the HDMI monitor go/stay black until I write manually 0x5 to JZ_REG_LCD_OSDC. This means that JZ_LCD_OSDC_ALPHAEN must be enabled on jz4780 as well. Hence overwriting just with JZ_LCD_OSDC_OSDEN breaks it. Now the questions: a) 0x5 is understandable that it sets JZ_LCD_OSDC_ALPHAEN - but why is it needed? Is this a not well documented difference between jz4740/60/70/80? b) how can clk_prepare_enable() write 0x00010005 to JZ_REG_LCD_OSDC? Bug or feature? Something in cgu driver going wrong? I now suspect that it is an undocumented SoC feature. Not at all. If the clock is disabled, the LCD controller is disabled, so all the registers read zero, this makes sense. You can only read the registers when the clock is enabled. On some SoCs, reading disabled registers can even cause a complete lockup. Why is this JZ_LCD_OSDC_ALPHAEN bit needed now? I remember it working fine last time I tried, and now I indeed get a black screen unless this bit is set. The PM doesn't make it obvious that the bit is required, but that wouldn't be surprising. Anyway, feel free to send a patch to fix it (with a Fixes: tag). Ideally something like this: u32 osdc = 0; ... if (soc_info->has_osd) osdc |= JZ_LCD_OSDC_OSDEN; if (soc_info->has_alpha) osdc |= JZ_LCD_OSDC_ALPHAEN; regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc); This also ensures that the OSDC register is properly initialized in the !has_osd case. The driver shouldn't rely on pre-boot values in the registers. Cheers, -Paul c) what do your SoC or panels do if you write 0x5 to JZ_REG_LCD_OSDC? d) 0x00010005 also has bit 16 set which is undocumented... But this is a don't care according to jz4780 PM. BR and thanks, Nikolaus
Re: [PATCH] mgag200 fix memmapsl configuration in GCTL6 register
On 1/18/22 17:52, Jocelyn Falempe wrote: > On 18/01/2022 17:38, Javier Martinez Canillas wrote: >> Hello Jocelyn, >> >> On 1/14/22 10:47, Jocelyn Falempe wrote: > >> >> My worry is if this could cause other issues so I would only do this change >> if (is_kdump_kernel()), to make it as non intrusive as possible. And also >> add a verbose comment about why this is needed. > > This change must be done in the "first" kernel, so that when kdump > starts, it doesn't hang the machine by writing to the VGA interface, in > the early boot code. > Ah, got it. The patch then makes sense to me as is in that case. My comment about documenting why this is needed still applies though. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH] mgag200 fix memmapsl configuration in GCTL6 register
On 18/01/2022 18:17, Javier Martinez Canillas wrote: On 1/18/22 17:52, Jocelyn Falempe wrote: On 18/01/2022 17:38, Javier Martinez Canillas wrote: Hello Jocelyn, On 1/14/22 10:47, Jocelyn Falempe wrote: My worry is if this could cause other issues so I would only do this change if (is_kdump_kernel()), to make it as non intrusive as possible. And also add a verbose comment about why this is needed. This change must be done in the "first" kernel, so that when kdump starts, it doesn't hang the machine by writing to the VGA interface, in the early boot code. Ah, got it. The patch then makes sense to me as is in that case. My comment about documenting why this is needed still applies though. Yes, I will fix the commit message, and add a comment in the code. I didn't know 0xA was the graphic mode, so I though the configuration was a mistake. But it turns out, the current configuration is good, but as the driver don't use this address, and kdump fails if this address is not VGA text mode on some hardware, it's better to set it to 0xb8000. Best regards, Thanks,
Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Paul, > Am 18.01.2022 um 17:58 schrieb Paul Cercueil : > > Hi Nikolaus, > > Le mar., janv. 18 2022 at 15:50:01 +0100, H. Nikolaus Schaller > a écrit : >> Hi Paul, >> any insights on the JZ_REG_LCD_OSDC issue below? > > Sorry, I missed your previous email. I blame the holidays ;) No problem... We all had deserved them. > >> There is a second, unrelated issue with the introduction of >> "drm/bridge: display-connector: implement bus fmts callbacks" >> which breaks bus format negotiations. >> These are the two last unsolved issues to submit a fully working driver. >>> Am 22.12.2021 um 15:03 schrieb H. Nikolaus Schaller : Am 08.11.2021 um 10:37 schrieb Paul Cercueil : Hi Nikolaus, Le dim., nov. 7 2021 at 21:25:38 +0100, H. Nikolaus Schaller a écrit : > Hi Paul, > @@ -1274,7 +1319,7 @@ static int ingenic_drm_bind(struct device *dev, > bool has_components) > /* Enable OSD if available */ > if (soc_info->has_osd) > - regmap_write(priv->map, JZ_REG_LCD_OSDC, > JZ_LCD_OSDC_OSDEN); > + regmap_set_bits(priv->map, JZ_REG_LCD_OSDC, > JZ_LCD_OSDC_OSDEN); This change is unrelated to this patch, and I'm not even sure it's a valid change. The driver shouldn't rely on previous register values. >>> I think I already commented that I think the driver should also not >>> reset >>> previous register values to zero. >> You did comment this, yes, but I don't agree. The driver *should* reset >> the registers to zero. It should *not* have to rely on whatever was >> configured before. >> Even if I did agree, this is a functional change unrelated to JZ4780 >> support, so it would have to be splitted to its own patch. > Well it is in preparation of setting more bits that are only available > for the jz4780. > But it will be splitted into its own patch for other reasons - if we ever > make osd working... >>> If I counted correctly this register has 18 bits which seem to include >>> some interrupt masks (which could be initialized somewhere else) and we >>> write a constant 0x1. >>> Of course most other bits are clearly OSD related (alpha blending), >>> i.e. they can have any value (incl. 0) if OSD is disabled. But here we >>> enable it. I think there may be missing some setting for the other bits. >>> So are you sure, that we can unconditionally reset *all* bits >>> except JZ_LCD_OSDC_OSDEN for the jz4780? >>> Well I have no experience with OSD being enabled at all. I.e. I have no >>> test scenario. >>> It turns out that the line >>> ret = clk_prepare_enable(priv->lcd_clk); >>> initializes JZ_REG_LCD_OSDC to 0x00010005 (i.e. printk tells 0x0 before). >> more detailled test shows that it is the underlying >> clk_enable(priv->lcd_clk) >> (i.e. not the prepare). >>> and writing >>> regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN); >>> overwrites it with 0x0001. >>> This makes the HDMI monitor go/stay black until I write manually 0x5 to >>> JZ_REG_LCD_OSDC. >>> This means that JZ_LCD_OSDC_ALPHAEN must be enabled on jz4780 as well. >>> Hence overwriting just with JZ_LCD_OSDC_OSDEN breaks it. >>> Now the questions: >>> a) 0x5 is understandable that it sets JZ_LCD_OSDC_ALPHAEN - but why is it >>> needed? >>> Is this a not well documented difference between jz4740/60/70/80? >>> b) how can clk_prepare_enable() write 0x00010005 to JZ_REG_LCD_OSDC? Bug or >>> feature? >>> Something in cgu driver going wrong? >> I now suspect that it is an undocumented SoC feature. > > Not at all. If the clock is disabled, the LCD controller is disabled, so all > the registers read zero, this makes sense. You can only read the registers > when the clock is enabled. On some SoCs, reading disabled registers can even > cause a complete lockup. This is the right answer to the wrong question :) The question is why the register becomes 0x10005 as soon as the clock is enabled. Without writing to it. And contrary to the documented reset state. Or are you aware that u-boot initialized the lcdc and clocks get disabled when/during starting the kernel (I am using the good old v2013.10)? That could be an explanation that we read 0 before the clock is enabled and 0x10005 after. > Why is this JZ_LCD_OSDC_ALPHAEN bit needed now? I remember it working fine > last time I tried, and now I indeed get a black screen unless this bit is > set. The PM doesn't make it obvious that the bit is required, exactly. > but that wouldn't be surprising. > > Anyway, feel free to send a patch to fix it (with a Fixes: tag). Ideally > something like this: > > u32 osdc = 0; > ... > if (soc_info->has_osd) > osdc |= JZ_LCD_OSDC_OSDEN; > if (soc_info->has_alpha) > osdc |= JZ_LCD_OSDC_ALPHAEN; > regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc); Looks good to me. I'll give it a try. > > T
Re: [RE]: [PATCH v3 10/10] vfio/ccw: Move the lifecycle of the struct vfio_ccw_private to the mdev
On Mon, 2022-01-17 at 11:35 -0400, Jason Gunthorpe wrote: > On Fri, Jan 14, 2022 at 11:30:36AM -0500, Eric Farman wrote: > > On Fri, 2022-01-14 at 20:28 +0800, Liu Yi L wrote: > > > Hi Eric, > > > > > > Hope you are back from new year holiday.:-) Have you got chane to > > > consider > > > this patch? > > > > Hi Yi Liu, > > > > It's coming up the list, but it's not there yet. Haven't forgotten. > > :) > > Liu would like to see ccw use a normal lifecycle for the vfio_device > backing memory, is there a shorter path to achieve that then what I > came up with? Getting through your proposal is the task on our plate. Just not enough hours in the day at the moment, sorry. Eric > > Jason
[PATCH v2 0/4] discsrete card 64K page support
This series continues support for 64K pages for discrete cards. It supersedes the 64K patches from https://patchwork.freedesktop.org/series/95686/#rev4 Changes since that series: - set min alignment for DG2 to 2MB in i915_address_space_init - replace coloring with simpler 2MB VA alignment for lmem buffers - enforce alignment to 2MB for lmem objects on DG2 in i915_vma_insert - expand vma reservation to round up to 2MB on DG2 in i915_vma_insert - add alignment test v2: rebase and fix for async vma that landed Matthew Auld (3): drm/i915: enforce min GTT alignment for discrete cards drm/i915: support 64K GTT pages for discrete cards drm/i915/uapi: document behaviour for DG2 64K support Robert Beckett (1): drm/i915: add gtt misalignment test .../gpu/drm/i915/gem/selftests/huge_pages.c | 60 + .../i915/gem/selftests/i915_gem_client_blt.c | 23 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 - drivers/gpu/drm/i915/gt/intel_gtt.c | 14 ++ drivers/gpu/drm/i915/gt/intel_gtt.h | 12 + drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 + drivers/gpu/drm/i915/i915_vma.c | 14 ++ drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 226 +++--- include/uapi/drm/i915_drm.h | 44 +++- 9 files changed, 453 insertions(+), 49 deletions(-) -- 2.25.1
[PATCH v2 1/4] drm/i915: enforce min GTT alignment for discrete cards
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
For DG2 we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../i915/gem/selftests/i915_gem_client_blt.c | 23 +++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 14 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 9 ++
drivers/gpu/drm/i915/i915_vma.c | 14 +++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ---
5 files changed, 115 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index c08f766e6e15..7fee95a65414 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -39,6 +39,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+ u64 align;
u32 width;
u32 height;
};
@@ -410,14 +411,21 @@ tiled_blits_create(struct intel_engine_cs *engine, struct
rnd_state *prng)
goto err_free;
}
- hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+ t->align = I915_GTT_PAGE_SIZE_2M; /* XXX worst case, derive from vm! */
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL));
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+ hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
- hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+ hole_size += 2 * t->align; /* padding on either side */
mutex_lock(&t->ce->vm->mutex);
memset(&hole, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(&t->ce->vm->mm, &hole,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
0, U64_MAX,
DRM_MM_INSERT_BEST);
if (!err)
@@ -428,7 +436,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct
rnd_state *prng)
goto err_put;
}
- t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+ t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -455,7 +463,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
static int tiled_blits_prepare(struct tiled_blits *t,
struct rnd_state *prng)
{
- u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+ u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -486,8 +494,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
{
- u64 offset =
- round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+ u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
/* We want to check position invariant tiling across GTT eviction */
@@ -500,7 +507,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct
rnd_state *prng)
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
-&t->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+&t->buffers[2], t->hole + t->align,
&t->buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be4197b93f..7c92b25c0f26 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -223,6 +223,20 @@ void i915_address_space_init(struct i915_address_space
*vm, int subclass)
GEM_BUG_ON(!vm->total);
drm_mm_init(&vm->mm, 0, vm->total);
+
+ memset64(vm->min_alignment, I915_GTT_MIN_ALIGNMENT,
+ARRAY_SIZE(vm->min_alignment));
+
+ if (HAS_64K_PAGES(vm->i915)) {
+ if (IS_DG2(vm->i915)) {
+ vm->min_alignment[INTEL_MEMORY_LOCAL] =
I915_GTT_PAGE_SIZE_2M;
+ vm->min_alignment[INTEL_MEMORY_STOLEN_LOCAL] =
I915_GTT_PAGE_SIZE_2M;
+ } else
[PATCH v2 4/4] drm/i915/uapi: document behaviour for DG2 64K support
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
include/uapi/drm/i915_drm.h | 44 -
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..486b7b96291e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+*
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+*
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* **DG2 64K min page size implications:**
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects. Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* **Special DG2 GTT address alignment requirement:**
+*
+* The GTT alignment will also need be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+* 1) The entire PDE(which covers a 2MB virtual address range), must
+* contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+* PDE is forbidden by the hardware.
+*
+* 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+* objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB. As this only wastes virtual
+* address space and avoids userland having to copy any needlessly
+* complicated PDE sharing scheme (coloring) and only affects GD2, this
+* id deemed to be a good compromise.
*/
__u64 size;
/**
--
2.25.1
[PATCH v2 2/4] drm/i915: support 64K GTT pages for discrete cards
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 ++
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 +-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
4 files changed, 169 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 26f997c376a2..7efa6a598b03 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1478,6 +1478,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
+static int igt_ppgtt_compact(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ /*
+* Simple test to catch issues with compact 64K pages -- since the pt is
+* compacted to 256B that gives us 32 entries per pt, however since the
+* backing page for the pt is 4K, any extra entries we might incorrectly
+* write out should be ignored by the HW. If ever hit such a case this
+* test should catch it since some of our writes would land in scratch.
+*/
+
+ if (!HAS_64K_PAGES(i915)) {
+ pr_info("device lacks compact 64K page support, skipping\n");
+ return 0;
+ }
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /* We want the range to cover multiple page-table boundaries. */
+ obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+ if (IS_ERR(obj))
+ return err;
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM compact unable to allocate huge-page(s)\n");
+ goto out_unpin;
+ }
+
+ /*
+* Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+* insertion.
+*/
+ obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+ err = igt_write_huge(i915, obj);
+ if (err)
+ pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_tmpfs_fallback(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1735,6 +1794,7 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+ SUBTEST(igt_ppgtt_compact),
};
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
start, end, lvl);
} else {
unsigned int count;
+ unsigned int pte = gen8_pd_index(start, 0);
+ unsigned int num_ptes;
u64 *vaddr;
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
atomic_read(&pt->used));
GEM_BUG_ON(!count || count >= atomic_read(&pt->used));
+ num_ptes = count;
+ if (pt->is_compact) {
+ GEM_BUG_ON(num_ptes % 16);
+ GEM_BUG_ON(pte % 16);
+ num_ptes /= 16;
+ pte /= 16;
+ }
+
vaddr = px_vaddr(pt);
- memset64(vaddr + gen8_pd_index(start, 0),
+ memset64(vaddr + pte,
vm->scratch[0]->encode,
-count);
+num_ptes);
atomic_sub(count, &pt->used);
start += count;
@@ -453,6 +463,95 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
[PATCH v2 3/4] drm/i915: add gtt misalignment test
add test to check handling of misaligned offsets and sizes
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 130 ++
1 file changed, 130 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 2f3f0c01786b..76696a5e547e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -22,10 +22,12 @@
*
*/
+#include "gt/intel_gtt.h"
#include
#include
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_context.h"
#include "gt/intel_gpu_commands.h"
@@ -1067,6 +1069,120 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
}
+static int misaligned_case(struct i915_address_space *vm, struct
intel_memory_region *mr,
+ u64 addr, u64 size, unsigned long flags)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int err = 0;
+ u64 expected_vma_size, expected_node_size;
+
+ obj = i915_gem_object_create_region(mr, size, 0, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_put;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, addr | flags);
+ if (err)
+ goto err_put;
+ i915_vma_unpin(vma);
+
+ if (!drm_mm_node_allocated(&vma->node)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ expected_vma_size = round_up(size, 1 <<
(ffs(vma->resource->page_sizes_gtt) - 1));
+ expected_node_size = expected_vma_size;
+
+ if (IS_DG2(vm->i915) && i915_gem_object_is_lmem(obj)) {
+ /* dg2 should expand lmem node to 2MB */
+ expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+ expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+ }
+
+ if (vma->size != expected_vma_size || vma->node.size !=
expected_node_size) {
+ err = i915_vma_unbind(vma);
+ err = -EBADSLT;
+ goto err_put;
+ }
+
+ err = i915_vma_unbind(vma);
+ if (err)
+ goto err_put;
+
+ GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
+
+err_put:
+ i915_gem_object_put(obj);
+ cleanup_freed_objects(vm->i915);
+ return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+ struct intel_memory_region *mr;
+ enum intel_region_id id;
+ unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ int err = 0;
+ u64 hole_size = hole_end - hole_start;
+
+ if (i915_is_ggtt(vm))
+ flags |= PIN_GLOBAL;
+
+ for_each_memory_region(mr, vm->i915, id) {
+ u64 min_alignment = i915_vm_min_alignment(vm, id);
+ u64 size = min_alignment;
+ u64 addr = round_up(hole_start + (hole_size / 2),
min_alignment);
+
+ /* we can't test < 4k alignment due to flags being encoded in
lower bits */
+ if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+ err = misaligned_case(vm, mr, addr + (min_alignment /
2), size, flags);
+ /* misaligned should error with -EINVAL*/
+ if (!err)
+ err = -EBADSLT;
+ if (err != -EINVAL)
+ return err;
+ }
+
+ /* test for vma->size expansion to min page size */
+ err = misaligned_case(vm, mr, addr, PAGE_SIZE, flags);
+ if (min_alignment > hole_size) {
+ if (!err)
+ err = -EBADSLT;
+ else if (err == -ENOSPC)
+ err = 0;
+ }
+ if (err)
+ return err;
+
+ /* test for intermediate size not expanding vma->size for large
alignments */
+ err = misaligned_case(vm, mr, addr, size / 2, flags);
+ if (min_alignment > hole_size) {
+ if (!err)
+ err = -EBADSLT;
+ else if (err == -ENOSPC)
+ err = 0;
+ }
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
static int exercise_ppgtt(struct drm_i915_private *dev_priv,
int (*func)(struct i915_address_space *vm,
u64 hole_start, u64 hole_
Re: [PATCH 1/2] drm/msm: add support for QCM2290 MDSS
On 18/01/2022 18:47, Loic Poulain wrote:
Add compatibility for QCM2290 display subsystem, including
required entries in DPU hw catalog.
Signed-off-by: Loic Poulain
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 175 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
4 files changed, 177 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index ce6f32a..7fa3fc7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -25,6 +25,8 @@
#define VIG_SM8250_MASK \
(VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE))
+#define VIG_QCM2290_MASK VIG_MASK
| BIT(DPU_SSPP_QOS_8LVL)
+
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -251,6 +253,18 @@ static const struct dpu_caps sc7280_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
+static const struct dpu_caps qcm2290_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0x4,
+ .qseed_type = DPU_SSPP_SCALER_QSEED4,
If there is no scaler, we probably shouldn't define it here too.
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2,
+ .ubwc_version = DPU_HW_UBWC_VER_20,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .max_linewidth = 2160,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -336,6 +350,19 @@ static const struct dpu_mdp_cfg sc7280_mdp[] = {
},
};
+static const struct dpu_mdp_cfg qcm2290_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = 0,
+ .highest_bank_bit = 0x2,
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+ .reg_off = 0x2AC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+ .reg_off = 0x2AC, .bit_off = 8},
+ },
+};
+
/*
* CTL sub blocks config
*/
@@ -459,6 +486,15 @@ static const struct dpu_ctl_cfg sc7280_ctl[] = {
},
};
+static const struct dpu_ctl_cfg qcm2290_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x1000, .len = 0x1dc,
+ .features = BIT(DPU_CTL_ACTIVE_CFG),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+};
+
/*
* SSPP sub blocks config
*/
@@ -595,6 +631,30 @@ static const struct dpu_sspp_cfg sc7280_sspp[] = {
sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
};
+
+#define _QCM2290_VIG_SBLK(num, sdma_pri) \
Let's call it _VIG_SBLK_NOSCALE?
+ { \
+ .maxdwnscale = SSPP_UNITY_SCALE, \
+ .maxupscale = SSPP_UNITY_SCALE, \
+ .smart_dma_priority = sdma_pri, \
+ .src_blk = {.name = STRCAT("sspp_src_", num), \
+ .id = DPU_SSPP_SRC, .base = 0x00, .len = 0x150,}, \
No scaler for VIG SSPP?
+ .format_list = plane_formats_yuv, \
+ .num_formats = ARRAY_SIZE(plane_formats_yuv), \
+ .virt_format_list = plane_formats, \
+ .virt_num_formats = ARRAY_SIZE(plane_formats), \
+ }
+
+static const struct dpu_sspp_sub_blks qcm2290_vig_sblk_0 =
_QCM2290_VIG_SBLK("0", 2);
+static const struct dpu_sspp_sub_blks qcm2290_dma_sblk_0 = _DMA_SBLK("8", 1);
+
+static const struct dpu_sspp_cfg qcm2290_sspp[] = {
+ SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_QCM2290_MASK,
+qcm2290_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
+ SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK,
+qcm2290_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
+};
+
/*
* MIXER sub blocks config
*/
@@ -679,6 +739,21 @@ static const struct dpu_lm_cfg sc7280_lm[] = {
&sc7180_lm_sblk, PINGPONG_3, LM_2, 0),
};
+/* QCM2290 */
+
+static const struct dpu_lm_sub_blks qcm2290_lm_sblk = {
+ .maxwidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .maxblendstages = 4, /* excluding base layer */
+ .blendstage_base = { /* offsets relative to mixer base */
+ 0x20, 0x38, 0x50, 0x68
+ },
+};
+
+static const struct dpu_lm_cfg qcm2290_lm[] = {
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_SC7180_MASK,
+ &qcm2290_lm_sblk, PINGPONG_0, 0, DSPP_0),
+};
+
/***
[PATCH 1/2] staging: fbtft: Fix error path in fbtft_driver_module_init()
If registering the platform driver fails, the function must not return
without undoing the spi driver registration first.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Uwe Kleine-König
---
drivers/staging/fbtft/fbtft.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 4cdec34e23d2..55677efc0138 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -334,7 +334,10 @@ static int __init fbtft_driver_module_init(void)
\
ret = spi_register_driver(&fbtft_driver_spi_driver); \
if (ret < 0) \
return ret;\
- return platform_driver_register(&fbtft_driver_platform_driver);\
+ ret = platform_driver_register(&fbtft_driver_platform_driver); \
+ if (ret < 0) \
+ spi_unregister_driver(&fbtft_driver_spi_driver); \
+ return ret;\
} \
\
static void __exit fbtft_driver_module_exit(void) \
base-commit: 0c947b893d69231a9add855939da7c66237ab44f
--
2.34.1
[PATCH 2/2] staging: fbtft: Deduplicate driver registration macros
The two macros FBTFT_REGISTER_DRIVER and FBTFT_REGISTER_SPI_DRIVER
contain quite some duplication: Both define an spi driver and an of device
table and the differences are quite subtle.
So create two new macros and use both twice.
Signed-off-by: Uwe Kleine-König
---
drivers/staging/fbtft/fbtft.h | 93 ++-
1 file changed, 36 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 55677efc0138..6a7545b5bcd2 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -272,21 +272,40 @@ void fbtft_write_reg8_bus9(struct fbtft_par *par, int
len, ...);
void fbtft_write_reg16_bus8(struct fbtft_par *par, int len, ...);
void fbtft_write_reg16_bus16(struct fbtft_par *par, int len, ...);
+#define FBTFT_DT_TABLE(_compatible)
\
+static const struct of_device_id dt_ids[] = {
\
+ { .compatible = _compatible },
\
+ {},
\
+};
\
+MODULE_DEVICE_TABLE(of, dt_ids);
+
+#define FBTFT_SPI_DRIVER(_name, _compatible, _display, _spi_ids)
\
+
\
+static int fbtft_driver_probe_spi(struct spi_device *spi)
\
+{
\
+ return fbtft_probe_common(_display, spi, NULL);
\
+}
\
+
\
+static int fbtft_driver_remove_spi(struct spi_device *spi)
\
+{
\
+ struct fb_info *info = spi_get_drvdata(spi);
\
+
\
+ fbtft_remove_common(&spi->dev, info);
\
+ return 0;
\
+}
\
+
\
+static struct spi_driver fbtft_driver_spi_driver = {
\
+ .driver = {
\
+ .name = _name,
\
+ .of_match_table = dt_ids,
\
+ },
\
+ .id_table = _spi_ids,
\
+ .probe = fbtft_driver_probe_spi,
\
+ .remove = fbtft_driver_remove_spi,
\
+};
+
#define FBTFT_REGISTER_DRIVER(_name, _compatible, _display)\
\
-static int fbtft_driver_probe_spi(struct spi_device *spi) \
-{ \
- return fbtft_probe_common(_display, spi, NULL);\
-} \
- \
-static int fbtft_driver_remove_spi(struct spi_device *spi) \
-{ \
- struct fb_info *info = spi_get_drvdata(spi); \
- \
- fbtft_remove_common(&spi->dev, info); \
- return 0; \
-} \
- \
static int fbtft_driver_probe_pdev(struct platform_device *pdev) \
{ \
return fbtft_probe_common(_display, NULL, pdev); \
@@ -300,22 +319,9 @@ static int fbtft_driver_remove_pdev(struct platform_device
*pdev) \
return 0; \
} \
\
-static const struct of_device_id dt_ids[] = { \
- { .compatible =
[PATCH v18 0/4] group dp driver related patches into one series
Group below 4 dp driver related patches into one series. Kuogee Hsieh (4): drm/msm/dp: do not initialize phy until plugin interrupt received drm/msm/dp: populate connector of struct dp_panel drm/msm/dp: add support of tps4 (training pattern 4) for HBR3 drm/msm/dp: stop link training after link training 2 failed drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++-- drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +- drivers/gpu/drm/msm/dp/dp_ctrl.c| 100 ++- drivers/gpu/drm/msm/dp/dp_ctrl.h| 8 ++- drivers/gpu/drm/msm/dp/dp_display.c | 116 +++- 5 files changed, 119 insertions(+), 119 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v18 2/4] drm/msm/dp: populate connector of struct dp_panel
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
connector is stored in struct msm_dp::connector. When we run compliance
testing test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid
edid set in struct dp_panel::edid so we'll try to use the connectors
real_edid_checksum and hit a NULL pointer dereference error because the
connector pointer is never assigned.
Changes in V2:
-- populate panel connector at msm_dp_modeset_init() instead of at
dp_panel_read_sink_caps()
Changes in V3:
-- remove unhelpful kernel crash trace commit text
-- remove renaming dp_display parameter to dp
Changes in V4:
-- add more details to commit text
Changes in v10:
-- group into one series
Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read
Fixes: 7948fe12d47 ("drm/msm/dp: return correct edid checksum after corrupted
edid checksum read")
Signee-off-by: Kuogee Hsieh
Reviewed-by: Bjorn Andersson
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 3059023..1d7f82e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1463,6 +1463,7 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
struct drm_encoder *encoder)
{
struct msm_drm_private *priv;
+ struct dp_display_private *dp_priv;
int ret;
if (WARN_ON(!encoder) || WARN_ON(!dp_display) || WARN_ON(!dev))
@@ -1471,6 +1472,8 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
priv = dev->dev_private;
dp_display->drm_dev = dev;
+ dp_priv = container_of(dp_display, struct dp_display_private,
dp_display);
+
ret = dp_display_request_irq(dp_display);
if (ret) {
DRM_ERROR("request_irq failed, ret=%d\n", ret);
@@ -1488,6 +1491,8 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
return ret;
}
+ dp_priv->panel->connector = dp_display->connector;
+
priv->connectors[priv->num_connectors++] = dp_display->connector;
dp_display->bridge = msm_dp_bridge_init(dp_display, dev, encoder);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v18 1/4] drm/msm/dp: do not initialize phy until plugin interrupt received
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume (including booting up), dongle plugin, dongle unplugged and suspend.
Regulators, core clocks and irq are grouped together and enabled at resume
(or booting up) so that the DP controller is armed and ready to receive HPD
plugin interrupts. HPD plugin interrupt is generated when a dongle plugs
into DUT (device under test). Once HPD plugin interrupt is received, DP
controller will initialize phy so that dpcd read/write will function and
following link training can be proceeded successfully. DP phy will be
disabled after main link is teared down at end of unplugged HPD interrupt
handle triggered by dongle unplugged out of DUT. Finally regulators, code
clocks and irq are disabled at corresponding suspension.
Changes in V2:
-- removed unnecessary dp_ctrl NULL check
-- removed unnecessary phy init_count and power_count DRM_DEBUG_DP logs
-- remove flip parameter out of dp_ctrl_irq_enable()
-- add fixes tag
Changes in V3:
-- call dp_display_host_phy_init() instead of dp_ctrl_phy_init() at
dp_display_host_init() for eDP
Changes in V4:
-- rewording commit text to match this commit changes
Changes in V5:
-- rebase on top of msm-next branch
Changes in V6:
-- delete flip variable
Changes in V7:
-- dp_ctrl_irq_enable/disabe() merged into dp_ctrl_reset_irq_ctrl()
Changes in V8:
-- add more detail comment regrading dp phy at dp_display_host_init()
Changes in V9:
-- remove set phy_initialized to false when -ECONNRESET detected
Changes in v10:
-- group into one series
Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately
if aux read
Changes in v12:
-- move dp_display_host_phy_exit() after dp_display_host_deinit()
Changes in v13:
-- do not execute phy_init until plugged_in interrupt for edp, same as DP.
Changes in v14:
-- remove redundant dp->core_initialized = false form dp_pm_suspend.
Changes in v15:
-- remove core_initialized flag check at both host_init and host_deinit
Changes in v16:
-- remove dp_display_host_phy_exit core_initialized=false at dp_pm_suspend
Changes in v17:
-- remove core_initialized checking before execute attention_cb()
Changes in v18:
-- remove core_initialized checking at dp_pm_suspend
Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
Chipsets")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 80 ++
drivers/gpu/drm/msm/dp/dp_ctrl.h| 8 ++-
drivers/gpu/drm/msm/dp/dp_display.c | 111 ++--
3 files changed, 92 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index c724cb0..9c80b49 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1365,60 +1365,44 @@ static int dp_ctrl_enable_stream_clocks(struct
dp_ctrl_private *ctrl)
return ret;
}
-int dp_ctrl_host_init(struct dp_ctrl *dp_ctrl, bool flip, bool reset)
+void dp_ctrl_reset_irq_ctrl(struct dp_ctrl *dp_ctrl, bool enable)
+{
+ struct dp_ctrl_private *ctrl;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+
+ dp_catalog_ctrl_reset(ctrl->catalog);
+
+ if (enable)
+ dp_catalog_ctrl_enable_irq(ctrl->catalog, enable);
+}
+
+void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
struct dp_io *dp_io;
struct phy *phy;
- if (!dp_ctrl) {
- DRM_ERROR("Invalid input data\n");
- return -EINVAL;
- }
-
ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
dp_io = &ctrl->parser->io;
phy = dp_io->phy;
- ctrl->dp_ctrl.orientation = flip;
-
- if (reset)
- dp_catalog_ctrl_reset(ctrl->catalog);
-
- DRM_DEBUG_DP("flip=%d\n", flip);
dp_catalog_ctrl_phy_reset(ctrl->catalog);
phy_init(phy);
- dp_catalog_ctrl_enable_irq(ctrl->catalog, true);
-
- return 0;
}
-/**
- * dp_ctrl_host_deinit() - Uninitialize DP controller
- * @dp_ctrl: Display Port Driver data
- *
- * Perform required steps to uninitialize DP controller
- * and its resources.
- */
-void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
+void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
struct dp_io *dp_io;
struct phy *phy;
- if (!dp_ctrl) {
- DRM_ERROR("Invalid input data\n");
- return;
- }
-
ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
dp_io = &ctrl->parser->io;
phy = dp_io->phy;
- dp_catalog_ctrl_enable_irq(ctrl->catalog, false);
+ dp_catalog_ctrl_phy_reset(ctrl->catalog)
[PATCH v18 4/4] drm/msm/dp: stop link training after link training 2 failed
Each DP link training contains link training 1 followed by link
training 2. There is maximum of 5 retries of DP link training
before declared link training failed. It is required to stop link
training at end of link training 2 if it is failed so that next
link training 1 can start freshly. This patch fixes link compliance
test case 4.3.1.13 (Source Device Link Training EQ Fallback Test).
Changes in v10:
-- group into one series
Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read
Fixes: 2e0adc765d88 ("drm/msm/dp: do not end dp link training until video is
ready")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index f98df93..245e1b9 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1755,6 +1755,9 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
/* end with failure */
break; /* lane == 1 already */
}
+
+ /* stop link training before start re training */
+ dp_ctrl_clear_training_pattern(ctrl);
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v18 3/4] drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
-- change state_ctrl_bits type to u32 and pattern type to u8
Changes in V4:
-- align } else if { and } else {
Changes in v10:
-- group into one series
Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++--
drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 17 -
3 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 6ae9b29..64f0b26 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -456,19 +456,19 @@ void dp_catalog_ctrl_config_msa(struct dp_catalog
*dp_catalog,
dp_write_p0(catalog, MMSS_DP_DSC_DTO, 0x0);
}
-int dp_catalog_ctrl_set_pattern(struct dp_catalog *dp_catalog,
- u32 pattern)
+int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog *dp_catalog,
+ u32 state_bit)
{
int bit, ret;
u32 data;
struct dp_catalog_private *catalog = container_of(dp_catalog,
struct dp_catalog_private, dp_catalog);
- bit = BIT(pattern - 1);
- DRM_DEBUG_DP("hw: bit=%d train=%d\n", bit, pattern);
+ bit = BIT(state_bit - 1);
+ DRM_DEBUG_DP("hw: bit=%d train=%d\n", bit, state_bit);
dp_catalog_ctrl_state_ctrl(dp_catalog, bit);
- bit = BIT(pattern - 1) << DP_MAINLINK_READY_LINK_TRAINING_SHIFT;
+ bit = BIT(state_bit - 1) << DP_MAINLINK_READY_LINK_TRAINING_SHIFT;
/* Poll for mainlink ready status */
ret = readx_poll_timeout(readl, catalog->io->dp_controller.link.base +
@@ -476,7 +476,7 @@ int dp_catalog_ctrl_set_pattern(struct dp_catalog
*dp_catalog,
data, data & bit,
POLLING_SLEEP_US, POLLING_TIMEOUT_US);
if (ret < 0) {
- DRM_ERROR("set pattern for link_train=%d failed\n", pattern);
+ DRM_ERROR("set state_bit for link_train=%d failed\n",
state_bit);
return ret;
}
return 0;
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 6965afa..7dea101 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -94,7 +94,7 @@ void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog
*dp_catalog, bool enable);
void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32 cc, u32
tb);
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32 rate,
u32 stream_rate_khz, bool fixed_nvid);
-int dp_catalog_ctrl_set_pattern(struct dp_catalog *dp_catalog, u32 pattern);
+int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog *dp_catalog, u32
pattern);
void dp_catalog_ctrl_reset(struct dp_catalog *dp_catalog);
bool dp_catalog_ctrl_mainlink_ready(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_enable_irq(struct dp_catalog *dp_catalog, bool enable);
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 9c80b49..f98df93 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1083,7 +1083,7 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private
*ctrl,
*training_step = DP_TRAINING_1;
- ret = dp_catalog_ctrl_set_pattern(ctrl->catalog, DP_TRAINING_PATTERN_1);
+ ret = dp_catalog_ctrl_set_pattern_state_bit(ctrl->catalog, 1);
if (ret)
return ret;
dp_ctrl_train_pattern_set(ctrl, DP_TRAINING_PATTERN_1 |
@@ -1181,7 +1181,8 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private
*ctrl,
int *training_step)
{
int tries = 0, ret = 0;
- char pattern;
+ u8 pattern;
+ u32 state_ctrl_bit;
int const maximum_retries = 5;
u8 link_status[DP_LINK_STATUS_SIZE];
@@ -1189,12 +1190,18 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private
*ctrl,
*training_step = DP_TRAINING_2;
- if (drm_dp_tps3_supported(ctrl->panel->dpcd))
+ if (drm_dp_tps4_supported(ctrl->panel->dpcd)) {
+ pattern = DP_TRAINING_PATTERN_4;
+ state_ctrl_bit = 4;
+ } else if (drm_dp_tps3_supported(ctrl->panel->dpcd)) {
pattern = DP_TRAINING_PATTERN_3;
- else
+ state_ctrl_bit = 3;
+ } else {
pattern = DP_TRAINING_PATTERN_2;
+ state_ctrl_bit = 2;
+ }
- ret = dp_c
[drm-tip:drm-tip 8/10] drivers/gpu/drm/i915/i915_gem_evict.h:15:15: error: declaration of 'struct i915_gem_ww_ctx' will not be visible outside of this function
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: ceefc39c8abf37ff93eb36001f82e725756863c8 commit: e38294cfc29f789b541ecc08be2e578da746663c [8/10] Merge remote-tracking branch 'drm-intel/drm-intel-gt-next' into drm-tip config: x86_64-randconfig-a002-20220117 (https://download.01.org/0day-ci/archive/20220119/202201190210.q12rphmz-...@intel.com/config) compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project c10cbb243cafc0cf42c3e922cb2918327932) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git remote add drm-tip git://anongit.freedesktop.org/drm/drm-tip git fetch --no-tags drm-tip drm-tip git checkout e38294cfc29f789b541ecc08be2e578da746663c # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from :4: >> drivers/gpu/drm/i915/i915_gem_evict.h:15:15: error: declaration of 'struct >> i915_gem_ww_ctx' will not be visible outside of this function >> [-Werror,-Wvisibility] struct i915_gem_ww_ctx *ww, ^ drivers/gpu/drm/i915/i915_gem_evict.h:21:14: error: declaration of 'struct i915_gem_ww_ctx' will not be visible outside of this function [-Werror,-Wvisibility] struct i915_gem_ww_ctx *ww, ^ drivers/gpu/drm/i915/i915_gem_evict.h:25:16: error: declaration of 'struct i915_gem_ww_ctx' will not be visible outside of this function [-Werror,-Wvisibility] struct i915_gem_ww_ctx *ww); ^ 3 errors generated. vim +15 drivers/gpu/drm/i915/i915_gem_evict.h 13 14 int __must_check i915_gem_evict_something(struct i915_address_space *vm, > 15struct i915_gem_ww_ctx *ww, 16u64 min_size, u64 alignment, 17unsigned long color, 18u64 start, u64 end, 19unsigned flags); 20 int __must_check i915_gem_evict_for_node(struct i915_address_space *vm, 21 struct i915_gem_ww_ctx *ww, 22 struct drm_mm_node *node, 23 unsigned int flags); 24 int i915_gem_evict_vm(struct i915_address_space *vm, 25struct i915_gem_ww_ctx *ww); 26 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v3] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Tue, Jan 18, 2022 at 06:34:20PM +0200, Ville Syrjälä wrote:
> On Fri, Oct 22, 2021 at 12:51:12PM -0700, Navare, Manasi wrote:
> >
> > Hi Ville,
> >
> > Could you take a look at this, this addresses teh review comments from prev
> > version
>
> I don't think I ever got an answer to my question as to whether this
> was tested with all the interesting scenarios:
> 1) just with the master crtc added by userspace into the commit
> 2) just with the slave crtc added by userspace into the commit
> 3) both crtcs added by userspace into the commit
>
> I guess 1) has been tested since that happens all the time, but the other
> two scanarios would likely need to be done with a synthetic test to make
> sure we're actually hitting them.
>
> I think it *should* work, but I'd like to have real proof of that.
> Reviewed-by: Ville Syrjälä
Thank you for your review here Ville.
I have triggered a separate email thread to understand all the above testing
scenarios and get them tested with bigjoiner IGT.
Manasi
>
> >
> > Manasi
> >
> > On Mon, Oct 04, 2021 at 04:59:13AM -0700, Manasi Navare wrote:
> > > In case of a modeset where a mode gets split across mutiple CRTCs
> > > in the driver specific implementation (bigjoiner in i915) we wrongly count
> > > the affected CRTCs based on the drm_crtc_mask and indicate the stolen
> > > CRTC as
> > > an affected CRTC in atomic_check_only().
> > > This triggers a warning since affected CRTCs doent match requested CRTC.
> > >
> > > To fix this in such bigjoiner configurations, we should only
> > > increment affected crtcs if that CRTC is enabled in UAPI not
> > > if it is just used internally in the driver to split the mode.
> > >
> > > v3: Add the same uapi crtc_state->enable check in requested
> > > crtc calc (Ville)
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Simon Ser
> > > Cc: Pekka Paalanen
> > > Cc: Daniel Stone
> > > Cc: Daniel Vetter
> > > Cc: dri-devel@lists.freedesktop.org
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 12
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index ff1416cd609a..a1e4c7905ebb 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1310,8 +1310,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> > > *state)
> > >
> > > DRM_DEBUG_ATOMIC("checking %p\n", state);
> > >
> > > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > - requested_crtc |= drm_crtc_mask(crtc);
> > > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > + if (new_crtc_state->enable)
> > > + requested_crtc |= drm_crtc_mask(crtc);
> > > + }
> > >
> > > for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> > > new_plane_state, i) {
> > > ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> > > @@ -1360,8 +1362,10 @@ int drm_atomic_check_only(struct drm_atomic_state
> > > *state)
> > > }
> > > }
> > >
> > > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > - affected_crtc |= drm_crtc_mask(crtc);
> > > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > + if (new_crtc_state->enable)
> > > + affected_crtc |= drm_crtc_mask(crtc);
> > > + }
> > >
> > > /*
> > >* For commits that allow modesets drivers can add other CRTCs to the
> > > --
> > > 2.19.1
> > >
>
> --
> Ville Syrjälä
> Intel
Re: [PATCH] drm/vmwgfx: Stop requesting the pci regions
Hello Zack,
On 1/17/22 19:03, Zack Rusin wrote:
> From: Zack Rusin
>
> When sysfb_simple is enabled loading vmwgfx fails because the regions
> are held by the platform. In that case remove_conflicting*_framebuffers
> only removes the simplefb but not the regions held by sysfb.
>
Indeed, that's an issue. I wonder if we should drop the IORESOURCE_BUSY
flag from the memory resource added to the "simple-framebuffer" device ?
In fact, maybe in sysfb_create_simplefb() shouldn't even attempt to claim
a memory resource and just register the platform device with no resources ?
> Like the other drm drivers we need to stop requesting all the pci regions
> to let the driver load with platform code enabled.
> This allows vmwgfx to load correctly on systems with sysfb_simple enabled.
>
I read this very interesting thread from two years ago:
https://lkml.org/lkml/2020/11/5/248
Maybe is worth mentioning in the commit message what Daniel said there,
that is that only a few DRM drivers request explicitly the PCI regions
and the only reliable approach is for bus drivers to claim these.
In other words, removing the pci_request_regions() seems to have merit
on its own.
> Signed-off-by: Zack Rusin
> Fixes: 523375c943e5 ("drm/vmwgfx: Port vmwgfx to arm64")
> Cc: dri-devel@lists.freedesktop.org
> Cc:
> Reviewed-by: Martin Krastev
> ---
The patch looks good to me, thanks a lot for fixing this:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH] mgag200 fix memmapsl configuration in GCTL6 register
We should probably Cc: sta...@vger.kernel.org this as well, see: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for more info. As well, some useful tools for adding the appropriate Fixes: tags: https://drm.pages.freedesktop.org/maintainer-tools/dim.html At least on my end this is: Acked-by: Lyude Paul I'd very much like Thomas Zimmerman to verify that this patch is OK though with an R-b before we push anything upstream. On Fri, 2022-01-14 at 10:47 +0100, Jocelyn Falempe wrote: > On some server with MGA G200e (rev 42), booting with Legacy BIOS, > The hardware hangs when using kdump and kexec into the kdump kernel. > This happens when the uncompress code tries to write "Decompressing Linux" > to the VGA Console. > > It can be reproduced by writing to the VGA console (0xB8000) after > booting to graphic mode, it generates the following error: > > kernel:NMI: PCI system error (SERR) for reason a0 on CPU 0. > kernel:Dazed and confused, but trying to continue > > The root cause is a bad configuration of the MGA GCTL6 register > > According to the GCTL6 register documentation: > > bit 0 is gcgrmode: > 0: Enables alpha mode, and the character generator addressing system is > activated. > 1: Enables graphics mode, and the character addressing system is not > used. > > bit 1 is chainodd even: > 0: The A0 signal of the memory address bus is used during system memory > addressing. > 1: Allows A0 to be replaced by either the A16 signal of the system > address (if > memmapsl is ‘00’), or by the hpgoddev (MISC<5>, odd/even page select) > field, > described on page 3-294). > > bit 3-2 are memmapsl: > Memory map select bits 1 and 0. VGA. > These bits select where the video memory is mapped, as shown below: > 00 => Ah - Bh > 01 => Ah - Ah > 10 => Bh - B7FFFh > 11 => B8000h - Bh > > bit 7-4 are reserved. > > Current driver code set it to 0x05 => memmapsl to b01 => 0xA > but on x86, the VGA console is at 0xB8000 > arch/x86/boot/compressed/misc.c define vidmem to 0xb8000 in extract_kernel() > so it's better to configure it to b11 > Thus changing the value 0x05 to 0x0d > > Signed-off-by: Jocelyn Falempe > --- > drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c > b/drivers/gpu/drm/mgag200/mgag200_mode.c > index b983541a4c53..c7f63610b278 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_mode.c > +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c > @@ -529,7 +529,7 @@ static void mgag200_set_format_regs(struct mga_device > *mdev, > WREG_GFX(3, 0x00); > WREG_GFX(4, 0x00); > WREG_GFX(5, 0x40); > - WREG_GFX(6, 0x05); > + WREG_GFX(6, 0x0d); > WREG_GFX(7, 0x0f); > WREG_GFX(8, 0x0f); > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH v11 03/19] dyndbg: add write-to-tracefs code
On Fri, Jan 14, 2022 at 4:46 AM Vincent Whitchurch wrote: > > On Fri, Jan 07, 2022 at 06:29:26AM +0100, Jim Cromie wrote: > > > > Enabling debug-to-tracefs is 2 steps: > > > > # event enable > > echo 1 > /sys/kernel/tracing/events/dyndbg/enable > > # callsite enable > > echo module foo +T > /proc/dynamic_debug/control > > > > This patch,~1,~2 are based upon: > > > > https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchu...@axis.com/ > > > > .. with simplification of temporarily reusing trace_console() rather > > than adding a new printk:dyndbg event. Soon, add 2 new events > > capturing the pr_debug & dev_dbg() args. > > The example above does not match the code in this patch since the > dyndbg:* events are only added in a later patch. Perhaps you could > reorder this patch stack so that you don't use trace_console() in this > patch just to replace it with the new events in the next patch? > good catch, thanks. Ive just dropped the example, it seemed the simplest fix. It seemed proper to commit your code as pristine as practical, so that subsequent mistakes receive the blame. and Ive fixed the spurious whitespace change you noted.
Re: [PATCH 1/2] drm/msm/dsi: move DSI host powerup to modeset time
On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
The DSI subsystem does not fully fall into the pre-enable/enable system
of callbacks, since typically DSI device bridge drivers expect to be
able to communicate with DSI devices at the pre-enable() callback. The
reason is that for some DSI hosts enabling the video stream would
prevent other drivers from sending DSI commands. For example see the
panel-bridge driver, which does drm_panel_prepare() from the
pre_enable() callback (which would be called before our pre_enable()
callback, resulting in panel preparation failures as the link is not yet
ready).
Therewere several attempts to solve this issue, but currently the best
approach is to power up the DSI link from the mode_set() callback,
allowing next bridge/panel to use DSI transfers in the pre_enable()
time. Follow this approach.
Change looks okay. As per the programming guideline, we should set the
VIDEO_MODE_EN register in the DSI controller followed by enabling the
timing engine which will still happen even now because we will do it in
modeset instead of the pre_enable().
But, this can potentially increase the delay between VIDEO_MODE_EN
and TIMING_ENGINE_EN. I dont see anything in the programming guide
against this but since this is a change from the original flow, I would
like to do one test before acking this. Can you please try adding a huge
delay like 200-300ms between VIDEO_MODE_EN and timing engine enable to
make sure there are no issues? You can do that here:
int msm_dsi_host_enable(struct mipi_dsi_host *host)
{
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
dsi_op_mode_config(msm_host,
!!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO), true);
msleep(300);
}
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 43 +++
1 file changed, 31 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 681ca74fe410..497719efb9e9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -336,13 +336,12 @@ dsi_mgr_connector_best_encoder(struct drm_connector
*connector)
return msm_dsi_get_encoder(msm_dsi);
}
-static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
+static void dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
{
int id = dsi_mgr_bridge_get_id(bridge);
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
struct mipi_dsi_host *host = msm_dsi->host;
- struct drm_panel *panel = msm_dsi->panel;
struct msm_dsi_phy_shared_timings phy_shared_timings[DSI_MAX];
bool is_bonded_dsi = IS_BONDED_DSI();
int ret;
@@ -383,6 +382,34 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
if (is_bonded_dsi && msm_dsi1)
msm_dsi_host_enable_irq(msm_dsi1->host);
+ return;
+
+host1_on_fail:
+ msm_dsi_host_power_off(host);
+host_on_fail:
+ dsi_mgr_phy_disable(id);
+phy_en_fail:
+ return;
+}
+
+static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
+{
+ int id = dsi_mgr_bridge_get_id(bridge);
+ struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
+ struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
+ struct mipi_dsi_host *host = msm_dsi->host;
+ struct drm_panel *panel = msm_dsi->panel;
+ bool is_bonded_dsi = IS_BONDED_DSI();
+ int ret;
+
+ DBG("id=%d", id);
+ if (!msm_dsi_device_connected(msm_dsi))
+ return;
+
+ /* Do nothing with the host if it is slave-DSI in case of bonded DSI */
+ if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
+ return;
+
/* Always call panel functions once, because even for dual panels,
* there is only one drm_panel instance.
*/
@@ -417,17 +444,7 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
if (panel)
drm_panel_unprepare(panel);
panel_prep_fail:
- msm_dsi_host_disable_irq(host);
- if (is_bonded_dsi && msm_dsi1)
- msm_dsi_host_disable_irq(msm_dsi1->host);
- if (is_bonded_dsi && msm_dsi1)
- msm_dsi_host_power_off(msm_dsi1->host);
-host1_on_fail:
- msm_dsi_host_power_off(host);
-host_on_fail:
- dsi_mgr_phy_disable(id);
-phy_en_fail:
return;
}
@@ -573,6 +590,8 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge *bridge,
msm_dsi_host_set_display_mode(host, adjusted_mode);
if (is_bonded_dsi && other_dsi)
msm_dsi_host_set_display_mode(other_dsi->host, adjusted_mode);
+
+ dsi_mgr_bridge_power_on(bridge);
}
static const struct drm_connector_funcs dsi_mgr_connector_funcs = {
Re: [PATCH 2/2] drm/msm/dsi: switch to DRM_PANEL_BRIDGE
On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-bridge
driver (already selected in Kconfig) and dropping support for
handling the panel directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.c | 32 +---
drivers/gpu/drm/msm/dsi/dsi.h | 10 +-
drivers/gpu/drm/msm/dsi/dsi_host.c| 20 +-
drivers/gpu/drm/msm/dsi/dsi_manager.c | 257 +++---
4 files changed, 32 insertions(+), 287 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 9670e548b3e9..b61f451a282e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -208,7 +208,7 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
struct drm_encoder *encoder)
{
struct msm_drm_private *priv;
- struct drm_bridge *ext_bridge;
+ struct drm_connector *connector;
int ret;
if (WARN_ON(!encoder) || WARN_ON(!msm_dsi) || WARN_ON(!dev))
@@ -238,31 +238,17 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
goto fail;
}
- /*
-* check if the dsi encoder output is connected to a panel or an
-* external bridge. We create a connector only if we're connected to a
-* drm_panel device. When we're connected to an external bridge, we
-* assume that the drm_bridge driver will create the connector itself.
-*/
- ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
-
- if (ext_bridge)
- msm_dsi->connector =
- msm_dsi_manager_ext_bridge_init(msm_dsi->id);
- else
- msm_dsi->connector =
- msm_dsi_manager_connector_init(msm_dsi->id);
-
- if (IS_ERR(msm_dsi->connector)) {
- ret = PTR_ERR(msm_dsi->connector);
+ connector = msm_dsi_manager_ext_bridge_init(msm_dsi->id);
+
+ if (IS_ERR(connector)) {
+ ret = PTR_ERR(connector);
DRM_DEV_ERROR(dev->dev,
"failed to create dsi connector: %d\n", ret);
- msm_dsi->connector = NULL;
goto fail;
}
Please correct my understanding if incorrect. Here you are expecting
that the existing panels/bridges have already used
drm_panel_bridge_add_typed add the bridge? Otherwise we will goto the
fail goto?
@@ -727,8 +509,11 @@ struct drm_connector
*msm_dsi_manager_ext_bridge_init(u8 id)
int ret;
int_bridge = msm_dsi->bridge;
- ext_bridge = msm_dsi->external_bridge =
- msm_dsi_host_get_bridge(msm_dsi->host);
+ ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
+ if (IS_ERR(ext_bridge))
+ return ERR_PTR(PTR_ERR(ext_bridge));
+
+ msm_dsi->external_bridge = ext_bridge;
Does that mean you plan to migrate the existing msm panels/bridges to
use devm_drm_panel_bridge_add_typed?
priv->bridges[priv->num_bridges++] = msm_dsi->bridge;
- priv->connectors[priv->num_connectors++] = msm_dsi->connector;
+ priv->connectors[priv->num_connectors++] = connector;
return 0;
fail:
@@ -272,12 +258,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
msm_dsi->bridge = NULL;
}
- /* don't destroy connector if we didn't make it */
- if (msm_dsi->connector && !msm_dsi->external_bridge)
- msm_dsi->connector->funcs->destroy(msm_dsi->connector);
-
- msm_dsi->connector = NULL;
-
return ret;
}
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index f46df52c6985..7eb778070a8c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -49,8 +49,6 @@ struct msm_dsi {
struct drm_device *dev;
struct platform_device *pdev;
- /* connector managed by us when we're connected to a drm_panel */
- struct drm_connector *connector;
/* internal dsi bridge attached to MDP interface */
struct drm_bridge *bridge;
@@ -58,10 +56,8 @@ struct msm_dsi {
struct msm_dsi_phy *phy;
/*
-* panel/external_bridge connected to dsi bridge output, only one of the
-* two can be valid at a time
+* external_bridge connected to dsi bridge output
*/
- struct drm_panel *panel;
struct drm_bridge *external_bridge;
struct device *phy_dev;
@@ -76,7 +72,6 @@ struct msm_dsi {
/* dsi manager */
struct drm_bridge *msm_dsi_manager_bridge_init(u8 id);
void msm_dsi_manager_bridge_destroy(struct drm_bridge *bridge);
-struct drm_connector *msm_dsi_manager_connector_init(u8 id);
struct drm_connector *msm_dsi_manager_ext_bridge_init(u8 id);
int msm_ds
Re: [PATCH] drm/dp: Remove common Post Cursor2 register handling
On 1/5/22 11:35, Kees Cook wrote:
> The link_status array was not large enough to read the Adjust Request
> Post Cursor2 register, so remove the common helper function to avoid
> an OOB read, found with a -Warray-bounds build:
>
> drivers/gpu/drm/drm_dp_helper.c: In function
> 'drm_dp_get_adjust_request_post_cursor':
> drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside
> array bounds of 'const u8[6]' {aka 'const unsigned char[6]'}
> [-Werror=array-bounds]
>59 | return link_status[r - DP_LANE0_1_STATUS];
> |~~~^~~
> drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status'
> 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
> |
> ~^~~~
>
> Replace the only user of the helper with an open-coded fetch and decode,
> similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.
>
> Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
This should be tagged for -stable:
Cc: sta...@vger.kernel.org
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Kees Cook
Reviewed-by: Gustavo A. R. Silva
Thanks
--
Gustavo
> ---
> This is the alternative to:
> https://lore.kernel.org/lkml/20211203084354.3105253-1-keesc...@chromium.org/
> ---
> drivers/gpu/drm/drm_dp_helper.c | 10 --
> drivers/gpu/drm/tegra/dp.c | 11 ++-
> include/drm/drm_dp_helper.h | 2 --
> 3 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 23f9073bc473..c9528aa62c9c 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -144,16 +144,6 @@ u8 drm_dp_get_adjust_tx_ffe_preset(const u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
>
> -u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
> - unsigned int lane)
> -{
> - unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
> - u8 value = dp_link_status(link_status, offset);
> -
> - return (value >> (lane << 1)) & 0x3;
> -}
> -EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
> -
> static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux, u8
> rd_interval)
> {
> if (rd_interval > 4)
> diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
> index 70dfb7d1dec5..f5535eb04c6b 100644
> --- a/drivers/gpu/drm/tegra/dp.c
> +++ b/drivers/gpu/drm/tegra/dp.c
> @@ -549,6 +549,15 @@ static void drm_dp_link_get_adjustments(struct
> drm_dp_link *link,
> {
> struct drm_dp_link_train_set *adjust = &link->train.adjust;
> unsigned int i;
> + u8 post_cursor;
> + int err;
> +
> + err = drm_dp_dpcd_read(link->aux, DP_ADJUST_REQUEST_POST_CURSOR2,
> +&post_cursor, sizeof(post_cursor));
> + if (err < 0) {
> + DRM_ERROR("failed to read post_cursor2: %d\n", err);
> + post_cursor = 0;
> + }
>
> for (i = 0; i < link->lanes; i++) {
> adjust->voltage_swing[i] =
> @@ -560,7 +569,7 @@ static void drm_dp_link_get_adjustments(struct
> drm_dp_link *link,
> DP_TRAIN_PRE_EMPHASIS_SHIFT;
>
> adjust->post_cursor[i] =
> - drm_dp_get_adjust_request_post_cursor(status, i);
> + (post_cursor >> (i << 1)) & 0x3;
> }
> }
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 472dac376284..fdf3cf6ccc02 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1528,8 +1528,6 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> int lane);
> u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane);
> -u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
> - unsigned int lane);
>
> #define DP_BRANCH_OUI_HEADER_SIZE0xc
> #define DP_RECEIVER_CAP_SIZE 0xf
>
Re: [Freedreno] [PATCH v2] drm/msm: reduce usage of round_pixclk callback
On 1/5/2022 11:06 PM, Dmitry Baryshkov wrote:
The round_pixclk() callback returns different rate only on MDP4 in HDMI
(DTV) case. Stop using this callback in other cases to simplify
mode_valid callbacks.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
Changes since v1:
- Rebased on top of HDMI changes
- Dropped eDP part, driver got removed
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 ---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 7 ---
drivers/gpu/drm/msm/dsi/dsi_manager.c| 22 --
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 11 +++
4 files changed, 7 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 47fe11a84a77..ebbee5f103e1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -774,12 +774,6 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
return ret;
}
-static long dpu_kms_round_pixclk(struct msm_kms *kms, unsigned long rate,
- struct drm_encoder *encoder)
-{
- return rate;
-}
-
static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
{
int i;
@@ -948,7 +942,6 @@ static const struct msm_kms_funcs kms_funcs = {
.disable_vblank = dpu_kms_disable_vblank,
.check_modified_format = dpu_format_check_modified_format,
.get_format = dpu_get_msm_format,
- .round_pixclk= dpu_kms_round_pixclk,
.destroy = dpu_kms_destroy,
.snapshot= dpu_kms_mdp_snapshot,
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 12a5f81e402b..20859fd7af4a 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -190,12 +190,6 @@ static void mdp5_complete_commit(struct msm_kms *kms,
unsigned crtc_mask)
mdp5_smp_complete_commit(mdp5_kms->smp, &global_state->smp);
}
-static long mdp5_round_pixclk(struct msm_kms *kms, unsigned long rate,
- struct drm_encoder *encoder)
-{
- return rate;
-}
-
static int mdp5_set_split_display(struct msm_kms *kms,
struct drm_encoder *encoder,
struct drm_encoder *slave_encoder,
@@ -278,7 +272,6 @@ static const struct mdp_kms_funcs kms_funcs = {
.wait_flush = mdp5_wait_flush,
.complete_commit = mdp5_complete_commit,
.get_format = mdp_get_format,
- .round_pixclk= mdp5_round_pixclk,
.set_split_display = mdp5_set_split_display,
.destroy = mdp5_kms_destroy,
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index f19bae475c96..1dbbfca163d9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -305,27 +305,6 @@ static int dsi_mgr_connector_get_modes(struct
drm_connector *connector)
return num;
}
-static enum drm_mode_status dsi_mgr_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- int id = dsi_mgr_connector_get_id(connector);
- struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
- struct drm_encoder *encoder = msm_dsi_get_encoder(msm_dsi);
- struct msm_drm_private *priv = connector->dev->dev_private;
- struct msm_kms *kms = priv->kms;
- long actual, requested;
-
- DBG("");
- requested = 1000 * mode->clock;
- actual = kms->funcs->round_pixclk(kms, requested, encoder);
-
- DBG("requested=%ld, actual=%ld", requested, actual);
- if (actual != requested)
- return MODE_CLOCK_RANGE;
-
- return MODE_OK;
-}
-
static struct drm_encoder *
dsi_mgr_connector_best_encoder(struct drm_connector *connector)
{
@@ -586,7 +565,6 @@ static const struct drm_connector_funcs
dsi_mgr_connector_funcs = {
static const struct drm_connector_helper_funcs dsi_mgr_conn_helper_funcs = {
.get_modes = dsi_mgr_connector_get_modes,
- .mode_valid = dsi_mgr_connector_mode_valid,
.best_encoder = dsi_mgr_connector_best_encoder,
};
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 68fba4bf7212..10ebe2089cb6 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -282,15 +282,18 @@ static enum drm_mode_status
msm_hdmi_bridge_mode_valid(struct drm_bridge *bridge
long actual, requested;
requested = 1000 * mode->clock;
- actual = kms->funcs->round_pixclk(kms,
- requested, hdmi_bridge->hdmi->encoder);
/* for mdp5/apq8074, we manage our own pixel clk (as opposed to
* mdp4/dtv stuff where pixel clk is assigned to mdp/encoder
* instead):
*/
Re: [PATCH 2/2] drm/msm/dsi: switch to DRM_PANEL_BRIDGE
On Tue, 18 Jan 2022 at 22:41, Abhinav Kumar wrote:
>
>
>
> On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
> > Currently the DSI driver has two separate paths: one if the next device
> > in a chain is a bridge and another one if the panel is connected
> > directly to the DSI host. Simplify the code path by using panel-bridge
> > driver (already selected in Kconfig) and dropping support for
> > handling the panel directly.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/dsi/dsi.c | 32 +---
> > drivers/gpu/drm/msm/dsi/dsi.h | 10 +-
> > drivers/gpu/drm/msm/dsi/dsi_host.c| 20 +-
> > drivers/gpu/drm/msm/dsi/dsi_manager.c | 257 +++---
> > 4 files changed, 32 insertions(+), 287 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
> > index 9670e548b3e9..b61f451a282e 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> > @@ -208,7 +208,7 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi,
> > struct drm_device *dev,
> >struct drm_encoder *encoder)
> > {
> > struct msm_drm_private *priv;
> > - struct drm_bridge *ext_bridge;
> > + struct drm_connector *connector;
> > int ret;
> >
> > if (WARN_ON(!encoder) || WARN_ON(!msm_dsi) || WARN_ON(!dev))
> > @@ -238,31 +238,17 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi,
> > struct drm_device *dev,
> > goto fail;
> > }
> >
> > - /*
> > - * check if the dsi encoder output is connected to a panel or an
> > - * external bridge. We create a connector only if we're connected to a
> > - * drm_panel device. When we're connected to an external bridge, we
> > - * assume that the drm_bridge driver will create the connector itself.
> > - */
> > - ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
> > -
> > - if (ext_bridge)
> > - msm_dsi->connector =
> > - msm_dsi_manager_ext_bridge_init(msm_dsi->id);
> > - else
> > - msm_dsi->connector =
> > - msm_dsi_manager_connector_init(msm_dsi->id);
> > -
> > - if (IS_ERR(msm_dsi->connector)) {
> > - ret = PTR_ERR(msm_dsi->connector);
> > + connector = msm_dsi_manager_ext_bridge_init(msm_dsi->id);
> > +
> > + if (IS_ERR(connector)) {
> > + ret = PTR_ERR(connector);
> > DRM_DEV_ERROR(dev->dev,
> > "failed to create dsi connector: %d\n", ret);
> > - msm_dsi->connector = NULL;
> > goto fail;
> > }
> Please correct my understanding if incorrect. Here you are expecting
> that the existing panels/bridges have already used
> drm_panel_bridge_add_typed add the bridge? Otherwise we will goto the
> fail goto?
No.
>
> @@ -727,8 +509,11 @@ struct drm_connector
> *msm_dsi_manager_ext_bridge_init(u8 id)
> int ret;
>
> int_bridge = msm_dsi->bridge;
> - ext_bridge = msm_dsi->external_bridge =
> - msm_dsi_host_get_bridge(msm_dsi->host);
> + ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
> + if (IS_ERR(ext_bridge))
> + return ERR_PTR(PTR_ERR(ext_bridge));
> +
> + msm_dsi->external_bridge = ext_bridge;
>
> Does that mean you plan to migrate the existing msm panels/bridges to
> use devm_drm_panel_bridge_add_typed?
No. panel-bridge.c/devm_drm_of_get_bridge() does that in a transparent
way. It calls devm_drm_panel_bridge_add() on it's own.
> >
> > priv->bridges[priv->num_bridges++] = msm_dsi->bridge;
> > - priv->connectors[priv->num_connectors++] = msm_dsi->connector;
> > + priv->connectors[priv->num_connectors++] = connector;
> >
> > return 0;
> > fail:
> > @@ -272,12 +258,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi,
> > struct drm_device *dev,
> > msm_dsi->bridge = NULL;
> > }
> >
> > - /* don't destroy connector if we didn't make it */
> > - if (msm_dsi->connector && !msm_dsi->external_bridge)
> > - msm_dsi->connector->funcs->destroy(msm_dsi->connector);
> > -
> > - msm_dsi->connector = NULL;
> > -
> > return ret;
> > }
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
> > index f46df52c6985..7eb778070a8c 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi.h
> > +++ b/drivers/gpu/drm/msm/dsi/dsi.h
> > @@ -49,8 +49,6 @@ struct msm_dsi {
> > struct drm_device *dev;
> > struct platform_device *pdev;
> >
> > - /* connector managed by us when we're connected to a drm_panel */
> > - struct drm_connector *connector;
> > /* internal dsi bridge attached to MDP interface */
> > struct drm_bridge *bridge;
> >
> > @@ -58,10 +56,8 @@ struct msm_dsi {
> > struct msm_dsi_phy *phy;
> >
> > /*
> > - * panel/external_bridge connected to dsi bridge output, only one of
> > the
> > -
Re: [PATCH 1/2] drm/msm/dsi: move DSI host powerup to modeset time
On Tue, 18 Jan 2022 at 22:29, Abhinav Kumar wrote:
>
>
>
> On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
> > The DSI subsystem does not fully fall into the pre-enable/enable system
> > of callbacks, since typically DSI device bridge drivers expect to be
> > able to communicate with DSI devices at the pre-enable() callback. The
> > reason is that for some DSI hosts enabling the video stream would
> > prevent other drivers from sending DSI commands. For example see the
> > panel-bridge driver, which does drm_panel_prepare() from the
> > pre_enable() callback (which would be called before our pre_enable()
> > callback, resulting in panel preparation failures as the link is not yet
> > ready).
> >
> > Therewere several attempts to solve this issue, but currently the best
> > approach is to power up the DSI link from the mode_set() callback,
> > allowing next bridge/panel to use DSI transfers in the pre_enable()
> > time. Follow this approach.
> >
> Change looks okay. As per the programming guideline, we should set the
> VIDEO_MODE_EN register in the DSI controller followed by enabling the
> timing engine which will still happen even now because we will do it in
> modeset instead of the pre_enable().
> But, this can potentially increase the delay between VIDEO_MODE_EN
> and TIMING_ENGINE_EN. I dont see anything in the programming guide
> against this but since this is a change from the original flow, I would
> like to do one test before acking this. Can you please try adding a huge
> delay like 200-300ms between VIDEO_MODE_EN and timing engine enable to
> make sure there are no issues? You can do that here:
Fine, I'll do the test as the time permits.
>
> int msm_dsi_host_enable(struct mipi_dsi_host *host)
> {
> struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
>
> dsi_op_mode_config(msm_host,
> !!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO), true);
>
> msleep(300);
> }
>
>
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/dsi/dsi_manager.c | 43 +++
> > 1 file changed, 31 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > index 681ca74fe410..497719efb9e9 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > @@ -336,13 +336,12 @@ dsi_mgr_connector_best_encoder(struct drm_connector
> > *connector)
> > return msm_dsi_get_encoder(msm_dsi);
> > }
> >
> > -static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
> > +static void dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
> > {
> > int id = dsi_mgr_bridge_get_id(bridge);
> > struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
> > struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
> > struct mipi_dsi_host *host = msm_dsi->host;
> > - struct drm_panel *panel = msm_dsi->panel;
> > struct msm_dsi_phy_shared_timings phy_shared_timings[DSI_MAX];
> > bool is_bonded_dsi = IS_BONDED_DSI();
> > int ret;
> > @@ -383,6 +382,34 @@ static void dsi_mgr_bridge_pre_enable(struct
> > drm_bridge *bridge)
> > if (is_bonded_dsi && msm_dsi1)
> > msm_dsi_host_enable_irq(msm_dsi1->host);
> >
> > + return;
> > +
> > +host1_on_fail:
> > + msm_dsi_host_power_off(host);
> > +host_on_fail:
> > + dsi_mgr_phy_disable(id);
> > +phy_en_fail:
> > + return;
> > +}
> > +
> > +static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
> > +{
> > + int id = dsi_mgr_bridge_get_id(bridge);
> > + struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
> > + struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
> > + struct mipi_dsi_host *host = msm_dsi->host;
> > + struct drm_panel *panel = msm_dsi->panel;
> > + bool is_bonded_dsi = IS_BONDED_DSI();
> > + int ret;
> > +
> > + DBG("id=%d", id);
> > + if (!msm_dsi_device_connected(msm_dsi))
> > + return;
> > +
> > + /* Do nothing with the host if it is slave-DSI in case of bonded DSI
> > */
> > + if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
> > + return;
> > +
> > /* Always call panel functions once, because even for dual panels,
> >* there is only one drm_panel instance.
> >*/
> > @@ -417,17 +444,7 @@ static void dsi_mgr_bridge_pre_enable(struct
> > drm_bridge *bridge)
> > if (panel)
> > drm_panel_unprepare(panel);
> > panel_prep_fail:
> > - msm_dsi_host_disable_irq(host);
> > - if (is_bonded_dsi && msm_dsi1)
> > - msm_dsi_host_disable_irq(msm_dsi1->host);
> >
> > - if (is_bonded_dsi && msm_dsi1)
> > - msm_dsi_host_power_off(msm_dsi1->host);
> > -host1_on_fail:
> > - msm_dsi_host_power_off(host);
> > -host_on_fail:
> > - dsi_mgr_phy_disable(id);
> > -phy_en_fail:
> > return;
> > }
> >
> > @@ -573,6 +590,8 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge
> > *bridge,
> >
Re: [PATCH] drm/amdgpu: Add missing pm_runtime_put_autosuspend
Applied. Strangely I can't seem to find this patch in my inbox or in
the dri-devel or amd-gfx archives.
Alex
On Tue, Jan 18, 2022 at 9:03 AM Lazar, Lijo wrote:
>
>
>
> On 1/18/2022 5:31 PM, Yongzhi Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > when it returns an error code, thus a matching decrement is needed
> > on the error handling path to keep the counter balanced.
> >
> > Signed-off-by: Yongzhi Liu
>
> Thanks!
>
> Reviewed-by: Lijo Lazar
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > index 9aea1cc..4b950de 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > @@ -1120,8 +1120,10 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct
> > file *f, char __user *buf,
> > return -EINVAL;
> >
> > r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
> > - if (r < 0)
> > + if (r < 0) {
> > + pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> > return r;
> > + }
> >
> > while (size) {
> > uint32_t value;
> >
Re: [PATCH] drm/radeon: fix UVD suspend error
Applied. Thanks!
On Mon, Jan 17, 2022 at 3:05 PM Leo Liu wrote:
>
>
> On 2022-01-17 2:47 a.m., Qiang Ma wrote:
> > I met a bug recently and the kernel log:
> >
> > [ 330.171875] radeon :03:00.0: couldn't schedule ib
> > [ 330.175781] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying
> > UVD (-22)!
> >
> > In radeon drivers, using UVD suspend is as follows:
> >
> > if (rdev->has_uvd) {
> > uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > }
> >
> > In radeon_ib_schedule function, we check the 'ring->ready' state,
> > but in uvd_v1_0_fini funciton, we've cleared the ready state.
> > So, just modify the suspend code flow to fix error.
>
> It seems reasonable to me. The suspend sends the destroy message if
> there is still incomplete job, so it should be before the fini which
> stops the hardware.
>
> The series are:
>
> Reviewed-by: Leo Liu
>
>
> >
> > Signed-off-by: Qiang Ma
> > ---
> > drivers/gpu/drm/radeon/cik.c | 2 +-
> > drivers/gpu/drm/radeon/evergreen.c | 2 +-
> > drivers/gpu/drm/radeon/ni.c| 2 +-
> > drivers/gpu/drm/radeon/r600.c | 2 +-
> > drivers/gpu/drm/radeon/rv770.c | 2 +-
> > drivers/gpu/drm/radeon/si.c| 2 +-
> > 6 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> > index 81b4de7be9f2..5819737c21c6 100644
> > --- a/drivers/gpu/drm/radeon/cik.c
> > +++ b/drivers/gpu/drm/radeon/cik.c
> > @@ -8517,8 +8517,8 @@ int cik_suspend(struct radeon_device *rdev)
> > cik_cp_enable(rdev, false);
> > cik_sdma_enable(rdev, false);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > if (rdev->has_vce)
> > radeon_vce_suspend(rdev);
> > diff --git a/drivers/gpu/drm/radeon/evergreen.c
> > b/drivers/gpu/drm/radeon/evergreen.c
> > index eeb590d2dec2..455f8036aa54 100644
> > --- a/drivers/gpu/drm/radeon/evergreen.c
> > +++ b/drivers/gpu/drm/radeon/evergreen.c
> > @@ -5156,8 +5156,8 @@ int evergreen_suspend(struct radeon_device *rdev)
> > radeon_pm_suspend(rdev);
> > radeon_audio_fini(rdev);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > r700_cp_stop(rdev);
> > r600_dma_stop(rdev);
> > diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> > index 4a364ca7a1be..927e5f42e97d 100644
> > --- a/drivers/gpu/drm/radeon/ni.c
> > +++ b/drivers/gpu/drm/radeon/ni.c
> > @@ -2323,8 +2323,8 @@ int cayman_suspend(struct radeon_device *rdev)
> > cayman_cp_enable(rdev, false);
> > cayman_dma_stop(rdev);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > evergreen_irq_suspend(rdev);
> > radeon_wb_disable(rdev);
> > diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> > index ca3fcae2adb5..dd78fc499402 100644
> > --- a/drivers/gpu/drm/radeon/r600.c
> > +++ b/drivers/gpu/drm/radeon/r600.c
> > @@ -3232,8 +3232,8 @@ int r600_suspend(struct radeon_device *rdev)
> > radeon_audio_fini(rdev);
> > r600_cp_stop(rdev);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > r600_irq_suspend(rdev);
> > radeon_wb_disable(rdev);
> > diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
> > index e592e57be1bb..38796af4fadd 100644
> > --- a/drivers/gpu/drm/radeon/rv770.c
> > +++ b/drivers/gpu/drm/radeon/rv770.c
> > @@ -1894,8 +1894,8 @@ int rv770_suspend(struct radeon_device *rdev)
> > radeon_pm_suspend(rdev);
> > radeon_audio_fini(rdev);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > r700_cp_stop(rdev);
> > r600_dma_stop(rdev);
> > diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> > index 013e44ed0f39..8d5e4b25609d 100644
> > --- a/drivers/gpu/drm/radeon/si.c
> > +++ b/drivers/gpu/drm/radeon/si.c
> > @@ -6800,8 +6800,8 @@ int si_suspend(struct radeon_device *rdev)
> > si_cp_enable(rdev, false);
> > cayman_dma_stop(rdev);
> > if (rdev->has_uvd) {
> > - uvd_v1_0_fini(rdev);
> > radeon_uvd_suspend(rdev);
> > + uvd_v1_0_fini(rdev);
> > }
> > if (rdev->has_vce)
> > radeon_vce_suspend(rdev);
