Re: [Patch v2] drm/amdgpu: Don't inherit GEM object VMAs in child process
Am 11.12.21 um 01:55 schrieb Felix Kuehling: On 2021-12-10 4:48 p.m., Rajneesh Bhardwaj wrote: When an application having open file access to a node forks, its shared mappings also get reflected in the address space of child process even though it cannot access them with the object permissions applied. With the existing permission checks on the gem objects, it might be reasonable to also create the VMAs with VM_DONTCOPY flag so a user space application doesn't need to explicitly call the madvise(addr, len, MADV_DONTFORK) system call to prevent the pages in the mapped range to appear in the address space of the child process. It also prevents the memory leaks due to additional reference counts on the mapped BOs in the child process that prevented freeing the memory in the parent for which we had worked around earlier in the user space inside the thunk library. Additionally, we faced this issue when using CRIU to checkpoint restore an application that had such inherited mappings in the child which confuse CRIU when it mmaps on restore. Having this flag set for the render node VMAs helps. VMAs mapped via KFD already take care of this so this is needed only for the render nodes. To limit the impact of the change to user space consumers such as OpenGL etc, limit it to KFD BOs only. Cc: Felix Kuehling Signed-off-by: David Yat Sin Signed-off-by: Rajneesh Bhardwaj Acked-by: Felix Kuehling At some point we probably want to extend that to all AMDGPU BOs, but for now the patch is Reviewed-by: Christian König Thanks, Christian. --- Changes in v2: * Addressed Christian's concerns for user space impact * Further reduced the scope to KFD BOs only drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c index a224b5295edd..64a7931eda8c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -263,6 +263,9 @@ static int amdgpu_gem_object_mmap(struct drm_gem_object *obj, struct vm_area_str !(vma->vm_flags & (VM_READ | VM_WRITE | VM_EXEC))) vma->vm_flags &= ~VM_MAYWRITE; + if (bo->kfd_bo) + vma->vm_flags |= VM_DONTCOPY; + return drm_gem_ttm_mmap(obj, vma); }
Re: [PATCH 6/7] drm/amdgpu: Ensure kunmap is called on error
Am 14.12.21 um 04:37 schrieb Ira Weiny:
On Mon, Dec 13, 2021 at 09:37:32PM +0100, Christian König wrote:
Am 11.12.21 um 00:24 schrieb ira.we...@intel.com:
From: Ira Weiny
The default case leaves the buffer object mapped in error.
Add amdgpu_bo_kunmap() to that case to ensure the mapping is cleaned up.
Mhm, good catch. But why do you want to do this in the first place?
I'm not sure I understand the question.
Any mapping of memory should be paired with an unmapping when no longer needed.
And this is supported by the call to amdgpu_bo_kunmap() in the other
non-default cases.
Do you believe the mapping is not needed?
No, the unmapping is not needed here. See the function amdgpu_bo_kmap(),
it either creates the mapping or return the cached pointer.
A call to amdgpu_bo_kunmap() is only done in a few places where we know
that the created mapping most likely won't be needed any more. If that's
not done the mapping is automatically destroyed when the BO is moved or
freed up.
I mean good bug fix, but you seem to see this as some kind of
prerequisite to some follow up work converting TTM to use kmap_local()
which most likely won't work in the first place.
Regards,
Christian.
Ira
Christian.
Signed-off-by: Ira Weiny
---
NOTE: It seems like this function could use a fair bit of refactoring
but this is the easiest way to fix the actual bug.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 1 +
1 file changed, 1 insertion(+)
nice
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 6f8de11a17f1..b3ffd0f6b35f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -889,6 +889,7 @@ static int amdgpu_uvd_cs_msg(struct amdgpu_uvd_cs_ctx *ctx,
return 0;
default:
+ amdgpu_bo_kunmap(bo);
DRM_ERROR("Illegal UVD message type (%d)!\n", msg_type);
}
Re: [PATCH 6/7] drm/amdgpu: Ensure kunmap is called on error
On Mon, Dec 13, 2021 at 09:37:32PM +0100, Christian König wrote:
> Am 11.12.21 um 00:24 schrieb ira.we...@intel.com:
> > From: Ira Weiny
> >
> > The default case leaves the buffer object mapped in error.
> >
> > Add amdgpu_bo_kunmap() to that case to ensure the mapping is cleaned up.
>
> Mhm, good catch. But why do you want to do this in the first place?
I'm not sure I understand the question.
Any mapping of memory should be paired with an unmapping when no longer needed.
And this is supported by the call to amdgpu_bo_kunmap() in the other
non-default cases.
Do you believe the mapping is not needed?
Ira
>
> Christian.
>
> >
> > Signed-off-by: Ira Weiny
> >
> > ---
> > NOTE: It seems like this function could use a fair bit of refactoring
> > but this is the easiest way to fix the actual bug.
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 1 +
> > 1 file changed, 1 insertion(+)
> > nice
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> > index 6f8de11a17f1..b3ffd0f6b35f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> > @@ -889,6 +889,7 @@ static int amdgpu_uvd_cs_msg(struct amdgpu_uvd_cs_ctx
> > *ctx,
> > return 0;
> > default:
> > + amdgpu_bo_kunmap(bo);
> > DRM_ERROR("Illegal UVD message type (%d)!\n", msg_type);
> > }
>
Re: [PATCH v3 2/3] drm/vc4: plane: Add support for DRM_FORMAT_P030
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip v5.16-rc5]
[cannot apply to anholt/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-vc4-Support-for-30-bits-YUV-formats/20211214-005817
base: git://anongit.freedesktop.org/drm/drm drm-next
config: arm64-randconfig-r031-20211213
(https://download.01.org/0day-ci/archive/20211214/202112141058.ebplkmsk-...@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
b6a2ddb6c8ac29412b1361810972e15221fa021c)
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
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/0day-ci/linux/commit/58b0d045769ea7e075fd1968a0da080b14b9ab70
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Maxime-Ripard/drm-vc4-Support-for-30-bits-YUV-formats/20211214-005817
git checkout 58b0d045769ea7e075fd1968a0da080b14b9ab70
# 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=arm64 SHELL=/bin/bash drivers/gpu/drm/vc4/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/vc4/vc4_plane.c:841:5: warning: variable 'tile_w' is used
>> uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
default:
^~~
drivers/gpu/drm/vc4/vc4_plane.c:844:20: note: uninitialized use occurs here
pix_per_tile = tile_w / fb->format->cpp[0];
^~
drivers/gpu/drm/vc4/vc4_plane.c:812:14: note: initialize the variable
'tile_w' to silence this warning
u32 tile_w, tile, x_off, pix_per_tile;
^
= 0
1 warning generated.
vim +/tile_w +841 drivers/gpu/drm/vc4/vc4_plane.c
625
626 /* Writes out a full display list for an active plane to the plane's
627 * private dlist state.
628 */
629 static int vc4_plane_mode_set(struct drm_plane *plane,
630struct drm_plane_state *state)
631 {
632 struct vc4_dev *vc4 = to_vc4_dev(plane->dev);
633 struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
634 struct drm_framebuffer *fb = state->fb;
635 u32 ctl0_offset = vc4_state->dlist_count;
636 const struct hvs_format *format =
vc4_get_hvs_format(fb->format->format);
637 u64 base_format_mod = fourcc_mod_broadcom_mod(fb->modifier);
638 int num_planes = fb->format->num_planes;
639 u32 h_subsample = fb->format->hsub;
640 u32 v_subsample = fb->format->vsub;
641 bool mix_plane_alpha;
642 bool covers_screen;
643 u32 scl0, scl1, pitch0;
644 u32 tiling, src_y;
645 u32 hvs_format = format->hvs;
646 unsigned int rotation;
647 int ret, i;
648
649 if (vc4_state->dlist_initialized)
650 return 0;
651
652 ret = vc4_plane_setup_clipping_and_scaling(state);
653 if (ret)
654 return ret;
655
656 /* SCL1 is used for Cb/Cr scaling of planar formats. For RGB
657 * and 4:4:4, scl1 should be set to scl0 so both channels of
658 * the scaler do the same thing. For YUV, the Y plane needs
659 * to be put in channel 1 and Cb/Cr in channel 0, so we swap
660 * the scl fields here.
661 */
662 if (num_planes == 1) {
663 scl0 = vc4_get_scl_field(state, 0);
664 scl1 = scl0;
665 } else {
666 scl0 = vc4_get_scl_field(state, 1);
667 scl1 = vc4_get_scl_field(state, 0);
668 }
669
670 rotation = drm_rotation_simplify(state->rotation,
671 DRM_MODE_ROTATE_0 |
672 DRM_MODE_REFLECT_X |
673 DRM_MODE_REFLECT_Y);
674
675 /* We
[PATCH v2] drm/ast: potential dereference of null pointer
The return value of kzalloc() needs to be checked.
To avoid use of null pointer '_state->base' in case of the
failure of alloc.
Fixes: f0adbc382b8b ("drm/ast: Allocate initial CRTC state of the correct size")
Signed-off-by: Jiasheng Jiang
---
Changelog:
v1 -> v2
*Change 1. Add the else statement that calling
__drm_atomic_helper_crtc_reset() with a state of NULL.
---
drivers/gpu/drm/ast/ast_mode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 36d9575aa27b..65099f0359f9 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1120,7 +1120,10 @@ static void ast_crtc_reset(struct drm_crtc *crtc)
if (crtc->state)
crtc->funcs->atomic_destroy_state(crtc, crtc->state);
- __drm_atomic_helper_crtc_reset(crtc, _state->base);
+ if (ast_state)
+ __drm_atomic_helper_crtc_reset(crtc, _state->base);
+ else
+ __drm_atomic_helper_crtc_reset(crtc, NULL);
}
static struct drm_crtc_state *
--
2.25.1
[PATCH] drm/ast: potential dereference of null pointer
The return value of kzalloc() needs to be checked.
To avoid use of null pointer '_state->base' in case of the
failure of alloc.
Fixes: f0adbc382b8b ("drm/ast: Allocate initial CRTC state of the correct size")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/ast/ast_mode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 36d9575aa27b..65099f0359f9 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1120,7 +1120,10 @@ static void ast_crtc_reset(struct drm_crtc *crtc)
if (crtc->state)
crtc->funcs->atomic_destroy_state(crtc, crtc->state);
- __drm_atomic_helper_crtc_reset(crtc, _state->base);
+ if (ast_state)
+ __drm_atomic_helper_crtc_reset(crtc, _state->base);
+ else
+ __drm_atomic_helper_crtc_reset(crtc, NULL);
}
static struct drm_crtc_state *
--
2.25.1
Re: RPI 7" display touch controller
On Mon, Dec 13, 2021 at 12:58 PM Tim Harvey wrote:
>
> On Mon, Dec 13, 2021 at 11:39 AM Tim Harvey wrote:
> >
> > On Mon, Dec 13, 2021 at 4:04 AM Dave Stevenson
> > wrote:
> > >
> > > On Fri, 10 Dec 2021 at 22:40, Tim Harvey wrote:
> > > >
> > > > On Fri, Dec 10, 2021 at 11:29 AM Tim Harvey
> > > > wrote:
> > > > >
> > > > > On Fri, Dec 10, 2021 at 10:41 AM Dave Stevenson
> > > > > wrote:
> > > > > >
> > > > > > On Fri, 10 Dec 2021 at 18:20, Tim Harvey
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Nov 18, 2021 at 12:52 PM Tim Harvey
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Nov 18, 2021 at 10:30 AM Dave Stevenson
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Thu, 18 Nov 2021 at 17:36, Tim Harvey
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Tim
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 18 Nov 2021 at 01:26, Tim Harvey
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Greetings,
> > > > > > > > > > > >
> > > > > > > > > > > > I'm trying to get a RPI 7" touchscreen display working
> > > > > > > > > > > > on an IMX8MM
> > > > > > > > > > > > board and while I've been able to get the MIPI DSI
> > > > > > > > > > > > display and
> > > > > > > > > > > > backlight working I still can't seem to figure out the
> > > > > > > > > > > > touch
> > > > > > > > > > > > controller.
> > > > > > > > > > > >
> > > > > > > > > > > > It's supposed to have an FT5406 controller on it
> > > > > > > > > > > > without an interrupt
> > > > > > > > > > > > so I added polling support
> > > > > > > > > > > > drivers/input/touchscreen/edt-ft5x06.c
> > > > > > > > > > > > which I was able to verify using another touchscreen
> > > > > > > > > > > > with that
> > > > > > > > > > > > controller but when reading data from the FT5406 on the
> > > > > > > > > > > > RPI controller
> > > > > > > > > > > > the data does not make sense.
> > > > > > > > > > > >
> > > > > > > > > > > > These panels appear to route the I2C from the FT5406 to
> > > > > > > > > > > > a STM32F103
> > > > > > > > > > > > MPU that then provides a different I2C slave interface
> > > > > > > > > > > > to the 15pin
> > > > > > > > > > > > connector that I'm connected to. On that I2C interface
> > > > > > > > > > > > I see an i2c
> > > > > > > > > > > > slave at 0x45 which is managed by the regulator driver
> > > > > > > > > > > > Marek wrote
> > > > > > > > > > > > (drivers/regulator/rpi-panel-attiny-regulator.c) and
> > > > > > > > > > > > there is also an
> > > > > > > > > > > > i2c slave at 0x38 which I assumed was the FT5406 but I
> > > > > > > > > > > > believe the MPU
> > > > > > > > > > > > is perhaps obfuscating that touch data.
> > > > > > > > > > > >
> > > > > > > > > > > > Anyone have any ideas on how to make that touch
> > > > > > > > > > > > controller useful?
> > > > > > > > > > >
> > > > > > > > > > > There should be nothing unusual. 0x38 is the EDT touch
> > > > > > > > > > > controller.
> > > > > > > > > > > Starting with the Raspberry Pi OS Bullseye release, we're
> > > > > > > > > > > now using
> > > > > > > > > > > the panel directly from DRM rather than through the
> > > > > > > > > > > firmware. That's
> > > > > > > > > > > based on the branch at
> > > > > > > > > > > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Dave,
> > > > > > > > > >
> > > > > > > > > > That sounds like the driver that made it into mainline with
> > > > > > > > > > Eric's
> > > > > > > > > > commit 2f733d6194bd ("drm/panel: Add support for the
> > > > > > > > > > Raspberry Pi 7"
> > > > > > > > > > Touchscreen."). I looked there but that driver just deals
> > > > > > > > > > with the DSI
> > > > > > > > > > and not with touch.
> > > > > > > > >
> > > > > > > > > No, we've reverted away from that driver as it exposes no
> > > > > > > > > regulator
> > > > > > > > > framework either, so again the touch element loses power.
> > > > > > > > >
> > > > > > > > > > > I also added polling support to edt-ft5x04.c.
> > > > > > > > > > > For DT, it uses a combination of the overlays vc4-kms-v3d,
> > > > > > > > > > > vc4-kms-dsi-7inch, and that includes edt-ft5406.dtsi, all
> > > > > > > > > > > of which are
> > > > > > > > > > > in /arch/arm/boot/dts/overlays
> > > > > > > > > >
> > > > > > > > > > It doesn't look like you ever submitted your edt-ft5x04
> > > > > > > > > > polling mode
> > > > > > > > > > support upstream. I saw another series to add polling
> > > > > > > > > > support
> > > > > > > > > > submitted by Nicolas back in 2019 but was never followed up
> > > > > > > > > > on
> > > > > > > > > > (https://patchwork.kernel.org/project/linux-input/list/?series=112187=both).
> > > > > > > > >
> > > > > > > > > No I haven't as it's been crazy trying to get
Re: [PATCH 6/7] drm/i915/guc: Kick G2H tasklet if no credits
On 12/11/2021 09:35, Matthew Brost wrote:
Let's be paranoid and kick the G2H tasklet, which dequeues messages, if
G2H credits are exhausted.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 741be9abab68..aa6dd6415202 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -591,12 +591,19 @@ static inline bool h2g_has_room(struct intel_guc_ct *ct,
u32 len_dw)
static int has_room_nb(struct intel_guc_ct *ct, u32 h2g_dw, u32 g2h_dw)
{
+ bool h2g = h2g_has_room(ct, h2g_dw);
+ bool g2h = g2h_has_room(ct, g2h_dw);
+
lockdep_assert_held(>ctbs.send.lock);
- if (unlikely(!h2g_has_room(ct, h2g_dw) || !g2h_has_room(ct, g2h_dw))) {
+ if (unlikely(!h2g || !g2h)) {
if (ct->stall_time == KTIME_MAX)
ct->stall_time = ktime_get();
+ /* Be paranoid and kick G2H tasklet to free credits */
+ if (!g2h)
+ tasklet_hi_schedule(>receive_tasklet);
+
if (unlikely(ct_deadlocked(ct)))
return -EPIPE;
else
Re: [PATCH 7/7] drm/i915/guc: Selftest for stealing of guc ids
On 12/11/2021 09:35, Matthew Brost wrote:
Testing the stealing of guc ids is hard from user space as we have 64k
guc_ids. Add a selftest, which artificially reduces the number of guc
ids, and forces a steal. Description of test below.
Last sentence seems redundant.
The test creates a spinner which is used to block all subsequent
submissions until it completes. Next, a loop creates a context and a NOP
request each iteration until the guc_ids are exhausted (request creation
returns -EAGAIN). The spinner is ended, unblocking all requests created
in the loop. At this point all guc_ids are exhausted but are available
to steal. Try to create another request which should successfully steal
a guc_id. Wait on last request to complete, idle GPU, verify a guc_id
was stolen via a counter, and exit the test. Test also artificially
reduces the number of guc_ids so the test runs in a timely manner.
v2:
(John Harrison)
- s/stole/stolen
- Fix some wording in test description
- Rework indexing into context array
- Add test description to commit message
- Fix typo in commit message
(Checkpatch)
- s/guc/(guc) in NUMBER_MULTI_LRC_GUC_ID
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 16 +-
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 173 ++
3 files changed, 196 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 1cb46098030d..f9240d4baa69 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -94,6 +94,11 @@ struct intel_guc {
* @guc_ids: used to allocate new guc_ids, single-lrc
*/
struct ida guc_ids;
+ /**
+* @num_guc_ids: Number of guc_ids, selftest feature to be able
+* to reduce this number while testing.
+*/
+ int num_guc_ids;
/**
* @guc_ids_bitmap: used to allocate new guc_ids, multi-lrc
*/
@@ -202,6 +207,13 @@ struct intel_guc {
*/
struct delayed_work work;
} timestamp;
+
+#ifdef CONFIG_DRM_I915_SELFTEST
+ /**
+* @number_guc_id_stolen: The number of guc_ids that have been stolen
+*/
+ int number_guc_id_stolen;
+#endif
};
static inline struct intel_guc *log_to_guc(struct intel_guc_log *log)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 96fcf869e3ff..99414b49ca6d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -145,7 +145,8 @@ guc_create_parallel(struct intel_engine_cs **engines,
* use should be low and 1/16 should be sufficient. Minimum of 32 guc_ids for
* multi-lrc.
*/
-#define NUMBER_MULTI_LRC_GUC_ID(GUC_MAX_LRC_DESCRIPTORS / 16)
+#define NUMBER_MULTI_LRC_GUC_ID(guc) \
+ ((guc)->submission_state.num_guc_ids / 16)
/*
* Below is a set of functions which control the GuC scheduling state which
@@ -1775,7 +1776,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
destroyed_worker_func);
guc->submission_state.guc_ids_bitmap =
- bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID, GFP_KERNEL);
+ bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
if (!guc->submission_state.guc_ids_bitmap)
return -ENOMEM;
@@ -1869,13 +1870,13 @@ static int new_guc_id(struct intel_guc *guc, struct intel_context *ce)
if (intel_context_is_parent(ce))
ret =
bitmap_find_free_region(guc->submission_state.guc_ids_bitmap,
- NUMBER_MULTI_LRC_GUC_ID,
+ NUMBER_MULTI_LRC_GUC_ID(guc),
order_base_2(ce->parallel.number_children
+ 1));
else
ret = ida_simple_get(>submission_state.guc_ids,
-NUMBER_MULTI_LRC_GUC_ID,
-GUC_MAX_LRC_DESCRIPTORS,
+NUMBER_MULTI_LRC_GUC_ID(guc),
+guc->submission_state.num_guc_ids,
GFP_KERNEL | __GFP_RETRY_MAYFAIL |
__GFP_NOWARN);
if (unlikely(ret < 0))
@@ -1941,6 +1942,10 @@ static int steal_guc_id(struct intel_guc *guc, struct
intel_context *ce)
set_context_guc_id_invalid(cn);
+#ifdef CONFIG_DRM_I915_SELFTEST
+ guc->number_guc_id_stolen++;
+#endif
+
return 0;
} else {
return -EAGAIN;
@@ -3779,6 +3784,7 @@ static bool
Re: [Mesa-dev] [PATCH v3 13/17] uapi/drm/dg2: Format modifier for DG2 unified compression and clear color
On 2021-12-09 at 14:41:57 -0500, Nanley Chery wrote:
> Ping. I see that a v4 has been sent out without these comments being
> addressed.
Sorry for the miss. I will address it soon.
Ram.
>
> -Nanley
>
> On Tue, Dec 7, 2021 at 6:51 PM Nanley Chery wrote:
> >
> > Hi Ramalingam,
> >
> > On Wed, Oct 27, 2021 at 5:22 PM Ramalingam C wrote:
> > >
> > > From: Matt Roper
> > >
> > > DG2 unifies render compression and media compression into a single
> > > format for the first time. The programming and buffer layout is
> > > supposed to match compression on older gen12 platforms, but the
> > > actual compression algorithm is different from any previous platform; as
> > > such, we need a new framebuffer modifier to represent buffers in this
> > > format, but otherwise we can re-use the existing gen12 compression driver
> > > logic.
> > >
> > > DG2 clear color render compression uses Tile4 layout. Therefore, we need
> > > to define a new format modifier for uAPI to support clear color rendering.
> > >
> >
> > I left some feedback on the modifier texts below, but I think it also
> > applies to this commit message.
> >
> > > v2: Rebased on new format modifier check [Ram]
> > >
> > > Signed-off-by: Matt Roper
> > > Signed-off-by: Mika Kahola (v2)
> > > Signed-off-by: Juha-Pekka Heikkilä
> > > Signed-off-by: Ramalingam C
> > > cc: Simon Ser
> > > Cc: Pekka Paalanen
> > > Cc: Jordan Justen
> > > Cc: Kenneth Graunke
> > > Cc: mesa-...@lists.freedesktop.org
> > > Cc: Tony Ye
> > > Cc: Slawomir Milczarek
> > > Acked-by: Simon Ser
> > > ---
> > > drivers/gpu/drm/i915/display/intel_fb.c | 43 +++
> > > .../drm/i915/display/skl_universal_plane.c| 29 -
> > > include/uapi/drm/drm_fourcc.h | 30 +
> > > 3 files changed, 101 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> > > b/drivers/gpu/drm/i915/display/intel_fb.c
> > > index 562d5244688d..484ae1fd0e94 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > > @@ -106,6 +106,21 @@ static const struct drm_format_info
> > > gen12_ccs_cc_formats[] = {
> > > .hsub = 1, .vsub = 1, .has_alpha = true },
> > > };
> > >
> > > +static const struct drm_format_info gen12_flat_ccs_cc_formats[] = {
> > > + { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
> > > + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = {
> > > 1, 1 },
> > > + .hsub = 1, .vsub = 1, },
> > > + { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
> > > + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = {
> > > 1, 1 },
> > > + .hsub = 1, .vsub = 1, },
> > > + { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
> > > + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = {
> > > 1, 1 },
> > > + .hsub = 1, .vsub = 1, .has_alpha = true },
> > > + { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
> > > + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = {
> > > 1, 1 },
> > > + .hsub = 1, .vsub = 1, .has_alpha = true },
> > > +};
> > > +
> > > struct intel_modifier_desc {
> > > u64 modifier;
> > > struct {
> > > @@ -166,6 +181,27 @@ static const struct intel_modifier_desc
> > > intel_modifiers[] = {
> > > .ccs.packed_aux_planes = BIT(1),
> > >
> > > FORMAT_OVERRIDE(gen12_ccs_cc_formats),
> > > + }, {
> > > + .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
> > > + .display_ver = { 12, 13 },
> > > + .tiling = I915_TILING_NONE,
> > > +
> > > + .ccs.type = INTEL_CCS_RC,
> > > + }, {
> > > + .modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
> > > + .display_ver = { 12, 13 },
> > > + .tiling = I915_TILING_NONE,
> > > +
> > > + .ccs.type = INTEL_CCS_MC,
> > > + }, {
> > > + .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC,
> > > + .display_ver = { 12, 13 },
> > > + .tiling = I915_TILING_NONE,
> > > +
> > > + .ccs.type = INTEL_CCS_RC_CC,
> > > + .ccs.cc_planes = BIT(1),
> > > +
> > > + FORMAT_OVERRIDE(gen12_flat_ccs_cc_formats),
> > > }, {
> > > .modifier = I915_FORMAT_MOD_Yf_TILED_CCS,
> > > .display_ver = { 9, 11 },
> > > @@ -582,6 +618,9 @@ intel_tile_width_bytes(const struct drm_framebuffer
> > > *fb, int color_plane)
> > > return 128;
> > > else
> > > return 512;
> > > + case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
> > > + case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
> > > + case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
> > > case I915_FORMAT_MOD_4_TILED:
> > >
Re: [PATCH] drm/dp: Fix off-by-one in register cache size
On Fri, Dec 03, 2021 at 12:43:33AM -0800, Kees Cook wrote:
> The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the
> math to calculate the max size. Found from a -Warray-bounds build:
>
> drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_pcon_dsc_bpp_incr':
> drivers/gpu/drm/drm_dp_helper.c:3130:28: error: array subscript 12 is outside
> array bounds of 'const u8[12]' {aka 'const unsigned char[12]'}
> [-Werror=array-bounds]
> 3130 | buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR -
> DP_PCON_DSC_ENCODER];
> |
> ~^~~~
> drivers/gpu/drm/drm_dp_helper.c:3126:39: note: while referencing
> 'pcon_dsc_dpcd'
> 3126 | int drm_dp_pcon_dsc_bpp_incr(const u8
> pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
> |
> ~^~~
>
> Fixes: e2e16da398d9 ("drm/dp_helper: Add support for Configuring DSC for
> HDMI2.1 Pcon")
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
> ---
> include/drm/drm_dp_helper.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 30359e434c3f..472dac376284 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -456,7 +456,7 @@ struct drm_panel;
> #define DP_FEC_CAPABILITY_1 0x091 /* 2.0 */
>
> /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
> -#define DP_PCON_DSC_ENCODER_CAP_SIZE0xC /* 0x9E - 0x92 */
> +#define DP_PCON_DSC_ENCODER_CAP_SIZE0xD /* 0x92 through 0x9E */
> #define DP_PCON_DSC_ENCODER 0x092
> # define DP_PCON_DSC_ENCODER_SUPPORTED (1 << 0)
> # define DP_PCON_DSC_PPS_ENC_OVERRIDE (1 << 1)
> --
> 2.30.2
>
Re: [PATCH v12, 06/19] media: mtk-vcodec: Add to support multi hardware decode
Hi Yunfei,
Thank you for reflecting comments.
Reviewed-by: Steve Cho
On Mon, Dec 13, 2021 at 12:40 AM yunfei.d...@mediatek.com
wrote:
>
> Hi Steve,
>
> Thanks for your suggestion,
> On Thu, 2021-12-09 at 15:29 -0800, Steve Cho wrote:
> > Few comments and questions.
> >
> > On Wed, Dec 1, 2021 at 7:46 PM Yunfei Dong
> > wrote:
> > >
> > > There are more than two hardwares for decoder: LAT0, LAT1 and CORE.
> > > In order to
> > > manage these hardwares, register each hardware as independent
> > > platform device
> > > for the larbs are different.
> >
> > basic question: what is "larbs"?
> >
> Can regard larbs as some hardware which decode depends on.
> > >
> > > Each hardware module controls its own information which includes
> > > interrupt/power/
> > > clocks/registers.
> > >
> > > Calling of_platform_populate in parent device, and use
> > > subdev_bitmap to record
> > > whether the hardwares are registered done.
> >
> > nit: s/registered done/registered/ ?
> >
> Fix in v13.
> > >
> > > Signed-off-by: Yunfei Dong
> > > ---
> > > drivers/media/platform/mtk-vcodec/Makefile| 5 +-
> > > .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 111 +++
> > > .../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 172
> > > ++
> > > .../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 51 ++
> > > .../mtk-vcodec/mtk_vcodec_dec_stateful.c | 1 +
> > > .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 2 +
> > > .../platform/mtk-vcodec/mtk_vcodec_drv.h | 19 ++
> > > 7 files changed, 329 insertions(+), 32 deletions(-)
> > > create mode 100644 drivers/media/platform/mtk-
> > > vcodec/mtk_vcodec_dec_hw.c
> > > create mode 100644 drivers/media/platform/mtk-
> > > vcodec/mtk_vcodec_dec_hw.h
> > >
> > > diff --git a/drivers/media/platform/mtk-vcodec/Makefile
> > > b/drivers/media/platform/mtk-vcodec/Makefile
> > > index ca8e9e7a9c4e..c61bfb179bcc 100644
> > > --- a/drivers/media/platform/mtk-vcodec/Makefile
> > > +++ b/drivers/media/platform/mtk-vcodec/Makefile
> > > @@ -2,7 +2,8 @@
> > >
> > > obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-dec.o \
> > >mtk-vcodec-enc.o \
> > > - mtk-vcodec-common.o
> > > + mtk-vcodec-common.o \
> > > + mtk-vcodec-dec-hw.o
> > >
> > > mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
> > > vdec/vdec_vp8_if.o \
> > > @@ -16,6 +17,8 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
> > > mtk_vcodec_dec_stateless.o \
> > > mtk_vcodec_dec_pm.o \
> > >
> > > +mtk-vcodec-dec-hw-y := mtk_vcodec_dec_hw.o
> > > +
> > > mtk-vcodec-enc-y := venc/venc_vp8_if.o \
> > > venc/venc_h264_if.o \
> > > mtk_vcodec_enc.o \
> > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> > > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> > > index b7a51e96d4ba..95fbe9be3f6d 100644
> > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> > > @@ -18,19 +18,40 @@
> > >
> > > #include "mtk_vcodec_drv.h"
> > > #include "mtk_vcodec_dec.h"
> > > +#include "mtk_vcodec_dec_hw.h"
> > > #include "mtk_vcodec_dec_pm.h"
> > > #include "mtk_vcodec_intr.h"
> > > #include "mtk_vcodec_util.h"
> > > #include "mtk_vcodec_fw.h"
> > >
> > > -#define VDEC_HW_ACTIVE 0x10
> > > -#define VDEC_IRQ_CFG 0x11
> > > -#define VDEC_IRQ_CLR 0x10
> > > -#define VDEC_IRQ_CFG_REG 0xa4
> > > -
> > > module_param(mtk_v4l2_dbg_level, int, 0644);
> > > module_param(mtk_vcodec_dbg, bool, 0644);
> > >
> > > +static int mtk_vcodec_subdev_device_check(struct mtk_vcodec_dev
> > > *vdec_dev)
> > > +{
> > > + struct platform_device *pdev = vdec_dev->plat_dev;
> > > + struct device_node *subdev_node;
> > > + enum mtk_vdec_hw_id hw_idx;
> > > + const struct of_device_id *of_id;
> > > + int i;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(mtk_vdec_hw_match); i++) {
> > > + of_id = _vdec_hw_match[i];
> > > + subdev_node = of_find_compatible_node(NULL, NULL,
> > > + of_id->compatible);
> > > + if (!subdev_node)
> > > + continue;
> > > +
> > > + hw_idx = (enum mtk_vdec_hw_id)(uintptr_t)of_id-
> > > >data;
> > > + if (!test_bit(hw_idx, vdec_dev->subdev_bitmap)) {
> > > + dev_err(>dev, "Vdec %d is not ready",
> > > hw_idx);
> > > + return -EAGAIN;
> > > + }
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void *priv)
> > > {
> > > struct mtk_vcodec_dev *dev = priv;
> > > @@ -95,6 +116,42 @@ static int mtk_vcodec_get_reg_bases(struct
> > > mtk_vcodec_dev *dev)
> > > return 0;
> > > }
> > >
>
Re: [PATCH v12, 13/19] media: mtk-vcodec: Add work queue for core hardware decode
Hi Yunfei,
Thank you for addressing my questions and comments.
Note that my comments for formatting are usually based on standards
from chromium & chrome os.
So feel free to reflect only if you think it is relevant.
Reviewed-by: Steve Cho
On Mon, Dec 13, 2021 at 12:52 AM yunfei.d...@mediatek.com
wrote:
>
> Hi steve,
>
> Thanks for your suggestion.
>
> On Thu, 2021-12-09 at 15:44 -0800, Steve Cho wrote:
> > On Wed, Dec 1, 2021 at 7:46 PM Yunfei Dong
> > wrote:
> > >
> > > Add work queue to process core hardware information.
> > > First, get lat_buf from message queue, then call core
> > > hardware of each codec(H264/VP9/AV1) to decode, finally
> > > puts lat_buf back to the message.
> > >
> > > Signed-off-by: Yunfei Dong
> > > ---
> > > .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 16 +++-
> > > .../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 ++
> > > .../platform/mtk-vcodec/vdec_msg_queue.c | 41
> > > ---
> > > .../platform/mtk-vcodec/vdec_msg_queue.h | 8 ++--
> > > 4 files changed, 57 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> > > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> > > index d460703f335d..4fbff61d2334 100644
> > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> > > @@ -341,6 +341,17 @@ static int mtk_vcodec_probe(struct
> > > platform_device *pdev)
> > > goto err_dec_pm;
> > > }
> > >
> > > + if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) {
> > > + vdec_msg_queue_init_ctx(>msg_queue_core_ctx,
> > > MTK_VDEC_CORE);
> > > + dev->core_workqueue =
> > > alloc_ordered_workqueue("core-decoder",
> > > + WQ_MEM_RECLAIM | WQ_FREEZABLE);
> > > + if (!dev->core_workqueue) {
> > > + mtk_v4l2_err("Failed to create core
> > > workqueue");
> > > + ret = -EINVAL;
> > > + goto err_res;
> > > + }
> > > + }
> > > +
> > > for (i = 0; i < MTK_VDEC_HW_MAX; i++)
> > > mutex_init(>dec_mutex[i]);
> > > spin_lock_init(>irqlock);
> > > @@ -351,7 +362,7 @@ static int mtk_vcodec_probe(struct
> > > platform_device *pdev)
> > > ret = v4l2_device_register(>dev, >v4l2_dev);
> > > if (ret) {
> > > mtk_v4l2_err("v4l2_device_register err=%d", ret);
> > > - goto err_res;
> > > + goto err_core_workq;
> > > }
> > >
> > > init_waitqueue_head(>queue);
> > > @@ -450,6 +461,9 @@ static int mtk_vcodec_probe(struct
> > > platform_device *pdev)
> > > video_unregister_device(vfd_dec);
> > > err_dec_alloc:
> > > v4l2_device_unregister(>v4l2_dev);
> > > +err_core_workq:
> > > + if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch))
> > > + destroy_workqueue(dev->core_workqueue);
> > > err_res:
> > > mtk_vcodec_release_dec_pm(>pm);
> > > err_dec_pm:
> > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> > > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> > > index cbaed96dcfa2..a558cc16026d 100644
> > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> > > @@ -27,6 +27,7 @@
> > > #define MTK_VCODEC_MAX_PLANES 3
> > > #define MTK_V4L2_BENCHMARK 0
> > > #define WAIT_INTR_TIMEOUT_MS 1000
> > > +#define IS_VDEC_LAT_ARCH(hw_arch) ((hw_arch) >=
> > > MTK_VDEC_LAT_SINGLE_CORE)
> >
> > Basic question: What is practical meaning of this? What architectures
> > are supported?
> >
> This definition is used to separate different architectures.
> Pure single core/lat single core at current period is supported.
> > >
> > > /*
> > > * enum mtk_hw_reg_idx - MTK hw register base index
> > > @@ -464,6 +465,7 @@ struct mtk_vcodec_enc_pdata {
> > > * @dec_capability: used to identify decode capability, ex: 4k
> > > * @enc_capability: used to identify encode capability
> > > *
> > > + * @core_workqueue: queue used for core hardware decode
> > > * @msg_queue_core_ctx: msg queue context used for core workqueue
> > > *
> > > * @subdev_dev: subdev hardware device
> > > @@ -506,6 +508,7 @@ struct mtk_vcodec_dev {
> > > unsigned int dec_capability;
> > > unsigned int enc_capability;
> > >
> > > + struct workqueue_struct *core_workqueue;
> > > struct vdec_msg_queue_ctx msg_queue_core_ctx;
> > >
> > > void *subdev_dev[MTK_VDEC_HW_MAX];
> > > diff --git a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> > > b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> > > index 913aefa67618..24f1d03df9f1 100644
> > > --- a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> > > +++ b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> > > @@ -68,6 +68,9 @@ int
Re: [PATCH v2] drm/mediatek: Set the default value of rotation to DRM_MODE_ROTATE_0
Hi, Mark:
Mark Yacoub 於 2021年12月14日 週二 上午12:08寫道：
>
> At the reset hook, call __drm_atomic_helper_plane_reset which is
> called at the initialization of the plane and sets the default value of
> rotation on all planes to DRM_MODE_ROTATE_0 which is equal to 1.
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Tested on Jacuzzi (MTK).
> Resolves IGT@kms_properties@plane-properties-{legacy,atomic}
>
> Signed-off-by: Mark Yacoub
> ---
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index e6dcb34d30522..accd26481b9fb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -44,9 +44,10 @@ static void mtk_plane_reset(struct drm_plane *plane)
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> if (!state)
> return;
> - plane->state = >base;
> }
>
> + __drm_atomic_helper_plane_reset(plane, >base);
> +
> state->base.plane = plane;
> state->pending.format = DRM_FORMAT_RGB565;
> }
> --
> 2.34.1.173.g76aa8bc2d0-goog
>
Re: [PATCH] dt-bindings: convert power domain node for rockchip DW MIPI DSI
On Sat, Dec 11, 2021 at 11:55:58AM +0100, Heiko Stübner wrote: > Hi David, > > Am Montag, 6. Dezember 2021, 22:26:50 CET schrieb David Heidelberg: > > Convert into YAML format into format, which can be validated. > > > > Changes: > > - drop panel from example > > the patch subject is strange, talking about a "power domain node". > That needs a fix. > > Some more things below. > > > > +properties: > > + compatible: > > +oneOf: > > + - items: > > + - enum: > > + - rockchip,px30-mipi-dsi > > + - rockchip,rk3288-mipi-dsi > > + - rockchip,rk3399-mipi-dsi > > + - const: snps,dw-mipi-dsi > > > + - items: > > + - const: rockchip,px30-mipi-dsi > > + - items: > > + - const: rockchip,rk3288-mipi-dsi > > + - items: > > + - const: rockchip,rk3399-mipi-dsi > > what are these for? > > I see that px30 uses the dsi without the snps part, but you > can also just add a patch adding that second compatible to px30.dtsi Or drop snps,dw-mipi-dsi as it doesn't seem to be all that meaningful. But I guess that's more invasive so maybe stick with changing px30. > > I don't think we need to support both ways. Agreed. Rob
Re: [PATCH] dt-bindings: convert power domain node for rockchip DW MIPI DSI
On Mon, Dec 06, 2021 at 10:26:50PM +0100, David Heidelberg wrote:
> Convert into YAML format into format, which can be validated.
>
> Changes:
> - drop panel from example
>
> Signed-off-by: David Heidelberg
> ---
> .../display/rockchip/dw_mipi_dsi_rockchip.txt | 93
> .../rockchip/rockchip,dw-mipi-dsi.yaml| 200 ++
> 2 files changed, 200 insertions(+), 93 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> create mode 100644
> Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> deleted file mode 100644
> index 39792f051d2d..
> ---
> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> +++ /dev/null
> @@ -1,93 +0,0 @@
> -Rockchip specific extensions to the Synopsys Designware MIPI DSI
> -
> -
> -Required properties:
> -- #address-cells: Should be <1>.
> -- #size-cells: Should be <0>.
> -- compatible: one of
> - "rockchip,px30-mipi-dsi", "snps,dw-mipi-dsi"
> - "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi"
> - "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi"
> -- reg: Represent the physical address range of the controller.
> -- interrupts: Represent the controller's interrupt to the CPU(s).
> -- clocks, clock-names: Phandles to the controller's pll reference
> - clock(ref) when using an internal dphy and APB clock(pclk).
> - For RK3399, a phy config clock (phy_cfg) and a grf clock(grf)
> - are required. As described in [1].
> -- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
> -- ports: contain a port node with endpoint definitions as defined in [2].
> - For vopb,set the reg = <0> and set the reg = <1> for vopl.
> -- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
> -- video port 1 for either a panel or subsequent encoder
> -
> -Optional properties:
> -- phys: from general PHY binding: the phandle for the PHY device.
> -- phy-names: Should be "dphy" if phys references an external phy.
> -- #phy-cells: Defined when used as ISP phy, should be 0.
> -- power-domains: a phandle to mipi dsi power domain node.
> -- resets: list of phandle + reset specifier pairs, as described in [3].
> -- reset-names: string reset name, must be "apb".
> -
> -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[2] Documentation/devicetree/bindings/media/video-interfaces.txt
> -[3] Documentation/devicetree/bindings/reset/reset.txt
> -
> -Example:
> - mipi_dsi: mipi@ff96 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
> - reg = <0xff96 0x4000>;
> - interrupts = ;
> - clocks = < SCLK_MIPI_24M>, < PCLK_MIPI_DSI0>;
> - clock-names = "ref", "pclk";
> - resets = < SRST_MIPIDSI0>;
> - reset-names = "apb";
> - rockchip,grf = <>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - mipi_in: port@0 {
> - reg = <0>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - mipi_in_vopb: endpoint@0 {
> - reg = <0>;
> - remote-endpoint = <_out_mipi>;
> - };
> - mipi_in_vopl: endpoint@1 {
> - reg = <1>;
> - remote-endpoint = <_out_mipi>;
> - };
> - };
> -
> - mipi_out: port@1 {
> - reg = <1>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - mipi_out_panel: endpoint {
> - remote-endpoint = <_in_mipi>;
> - };
> - };
> - };
> -
> - panel {
> - compatible ="boe,tv080wum-nl0";
> - reg = <0>;
> -
> - enable-gpios = < 3 GPIO_ACTIVE_HIGH>;
> - pinctrl-names = "default";
> - pinctrl-0 = <_en>;
> - backlight = <>;
> -
> - port {
> - panel_in_mipi: endpoint {
> - remote-endpoint = <_out_panel>;
> - };
> - };
> - };
> - };
> diff --git
>
Re: [PATCH v4 00/34] component: Make into an aggregate bus
Quoting Daniel Vetter (2021-12-07 10:22:15) > On Thu, Dec 02, 2021 at 02:26:58PM -0800, Stephen Boyd wrote: > > This series is from discussion we had on reordering the device lists for > > drm shutdown paths[1]. I've introduced an 'aggregate' bus that we put > > the aggregate device onto and then we probe the aggregate device once > > all the components are probed and call component_add(). The probe/remove > > hooks are where the bind/unbind calls go, and then a shutdown hook is > > added that can be used to shutdown the drm display pipeline at the right > > time. > > > > This works for me on my sc7180 board. I no longer get a warning from i2c > > at shutdown that we're trying to make an i2c transaction after the i2c > > bus has been shutdown. There's more work to do on the msm drm driver to > > extract component device resources like clks, regulators, etc. out of > > the component bind function into the driver probe but I wanted to move > > everything over now in other component drivers before tackling that > > problem. > > > > Tested-by tags would be appreciated, and Acked-by/Reviewed-by tags too. > > Thanks for pushing this forward. Unfortunately I'm completely burried and > it's just not improving, so merge plan: > > - please get Greg KH to ack the bus/driver core stuff > > - please get one of the drm-misc committers we have from Google's Chromeos > team (there should be a few by now) to review this. Sounds like a plan. Thanks! > > Otherwise I fear this might get stuck and I'd really like to avoid that. >
Re: RPI 7" display touch controller
On Mon, Dec 13, 2021 at 11:39 AM Tim Harvey wrote:
>
> On Mon, Dec 13, 2021 at 4:04 AM Dave Stevenson
> wrote:
> >
> > On Fri, 10 Dec 2021 at 22:40, Tim Harvey wrote:
> > >
> > > On Fri, Dec 10, 2021 at 11:29 AM Tim Harvey wrote:
> > > >
> > > > On Fri, Dec 10, 2021 at 10:41 AM Dave Stevenson
> > > > wrote:
> > > > >
> > > > > On Fri, 10 Dec 2021 at 18:20, Tim Harvey
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Nov 18, 2021 at 12:52 PM Tim Harvey
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Nov 18, 2021 at 10:30 AM Dave Stevenson
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, 18 Nov 2021 at 17:36, Tim Harvey
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Tim
> > > > > > > > > >
> > > > > > > > > > On Thu, 18 Nov 2021 at 01:26, Tim Harvey
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Greetings,
> > > > > > > > > > >
> > > > > > > > > > > I'm trying to get a RPI 7" touchscreen display working on
> > > > > > > > > > > an IMX8MM
> > > > > > > > > > > board and while I've been able to get the MIPI DSI
> > > > > > > > > > > display and
> > > > > > > > > > > backlight working I still can't seem to figure out the
> > > > > > > > > > > touch
> > > > > > > > > > > controller.
> > > > > > > > > > >
> > > > > > > > > > > It's supposed to have an FT5406 controller on it without
> > > > > > > > > > > an interrupt
> > > > > > > > > > > so I added polling support
> > > > > > > > > > > drivers/input/touchscreen/edt-ft5x06.c
> > > > > > > > > > > which I was able to verify using another touchscreen with
> > > > > > > > > > > that
> > > > > > > > > > > controller but when reading data from the FT5406 on the
> > > > > > > > > > > RPI controller
> > > > > > > > > > > the data does not make sense.
> > > > > > > > > > >
> > > > > > > > > > > These panels appear to route the I2C from the FT5406 to a
> > > > > > > > > > > STM32F103
> > > > > > > > > > > MPU that then provides a different I2C slave interface to
> > > > > > > > > > > the 15pin
> > > > > > > > > > > connector that I'm connected to. On that I2C interface I
> > > > > > > > > > > see an i2c
> > > > > > > > > > > slave at 0x45 which is managed by the regulator driver
> > > > > > > > > > > Marek wrote
> > > > > > > > > > > (drivers/regulator/rpi-panel-attiny-regulator.c) and
> > > > > > > > > > > there is also an
> > > > > > > > > > > i2c slave at 0x38 which I assumed was the FT5406 but I
> > > > > > > > > > > believe the MPU
> > > > > > > > > > > is perhaps obfuscating that touch data.
> > > > > > > > > > >
> > > > > > > > > > > Anyone have any ideas on how to make that touch
> > > > > > > > > > > controller useful?
> > > > > > > > > >
> > > > > > > > > > There should be nothing unusual. 0x38 is the EDT touch
> > > > > > > > > > controller.
> > > > > > > > > > Starting with the Raspberry Pi OS Bullseye release, we're
> > > > > > > > > > now using
> > > > > > > > > > the panel directly from DRM rather than through the
> > > > > > > > > > firmware. That's
> > > > > > > > > > based on the branch at
> > > > > > > > > > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Dave,
> > > > > > > > >
> > > > > > > > > That sounds like the driver that made it into mainline with
> > > > > > > > > Eric's
> > > > > > > > > commit 2f733d6194bd ("drm/panel: Add support for the
> > > > > > > > > Raspberry Pi 7"
> > > > > > > > > Touchscreen."). I looked there but that driver just deals
> > > > > > > > > with the DSI
> > > > > > > > > and not with touch.
> > > > > > > >
> > > > > > > > No, we've reverted away from that driver as it exposes no
> > > > > > > > regulator
> > > > > > > > framework either, so again the touch element loses power.
> > > > > > > >
> > > > > > > > > > I also added polling support to edt-ft5x04.c.
> > > > > > > > > > For DT, it uses a combination of the overlays vc4-kms-v3d,
> > > > > > > > > > vc4-kms-dsi-7inch, and that includes edt-ft5406.dtsi, all
> > > > > > > > > > of which are
> > > > > > > > > > in /arch/arm/boot/dts/overlays
> > > > > > > > >
> > > > > > > > > It doesn't look like you ever submitted your edt-ft5x04
> > > > > > > > > polling mode
> > > > > > > > > support upstream. I saw another series to add polling support
> > > > > > > > > submitted by Nicolas back in 2019 but was never followed up on
> > > > > > > > > (https://patchwork.kernel.org/project/linux-input/list/?series=112187=both).
> > > > > > > >
> > > > > > > > No I haven't as it's been crazy trying to get this lot to work
> > > > > > > > under
> > > > > > > > KMS at all over the last couple of months.
> > > > > > > >
> > > > > > > > > I have updated Nicolas' patch with the changes requested and
> > > > > > > > > am happy
> > > > > > > > > to submit it upstream. The benefit of his patch is that it
> > > > > > > > >
Re: [PATCH] drm:amdgpu:remove unneeded variable
Applied. Thanks!
Alex
On Thu, Dec 9, 2021 at 11:56 AM wrote:
>
> From: chiminghao
>
> return value form directly instead of
> taking this in another redundant variable.
>
> Reported-by: Zeal Robot
> Signed-off-by: chiminghao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c | 5 +
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 6 ++
> 2 files changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c
> index 5cf142e849bb..fb92f827eeb7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c
> @@ -37,12 +37,9 @@
> long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd, unsigned
> long arg)
> {
> unsigned int nr = DRM_IOCTL_NR(cmd);
> - int ret;
>
> if (nr < DRM_COMMAND_BASE)
> return drm_compat_ioctl(filp, cmd, arg);
>
> - ret = amdgpu_drm_ioctl(filp, cmd, arg);
> -
> - return ret;
> + return amdgpu_drm_ioctl(filp, cmd, arg);
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> index cb82404df534..269a7b04b7e7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> @@ -1742,7 +1742,7 @@ static int gmc_v9_0_hw_init(void *handle)
> {
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> bool value;
> - int r, i;
> + int i;
>
> /* The sequence of these two function calls matters.*/
> gmc_v9_0_init_golden_registers(adev);
> @@ -1777,9 +1777,7 @@ static int gmc_v9_0_hw_init(void *handle)
> if (adev->umc.funcs && adev->umc.funcs->init_registers)
> adev->umc.funcs->init_registers(adev);
>
> - r = gmc_v9_0_gart_enable(adev);
> -
> - return r;
> + return gmc_v9_0_gart_enable(adev);
> }
>
> /**
> --
> 2.25.1
>
Re: [PATCH/RFC v2] dt-bindings: display: bridge: sil,sii9022: Convert to json-schema
On Fri, Dec 03, 2021 at 03:14:07PM +0100, Geert Uytterhoeven wrote:
> Convert the Silicon Image sii902x HDMI bridge Device Tree binding
> documentation to json-schema.
>
> Add missing sil,sii9022-cpi and sil,sii9022-tpi compatible values.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> RFC as I do not know the meaning of the various ports subnodes.
Is that too hard to figure out? There's no examples in the tree?
>
> v2:
> - Rework sil,i2s-data-lanes,
> - Add schema reference to ports.
> ---
> .../bindings/display/bridge/sii902x.txt | 78 --
> .../bindings/display/bridge/sil,sii9022.yaml | 133 ++
> 2 files changed, 133 insertions(+), 78 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/bridge/sii902x.txt
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> deleted file mode 100644
> index 3bc760cc31cbbeee..
> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> +++ /dev/null
> @@ -1,78 +0,0 @@
> -sii902x HDMI bridge bindings
> -
> -Required properties:
> - - compatible: "sil,sii9022"
> - - reg: i2c address of the bridge
> -
> -Optional properties:
> - - interrupts: describe the interrupt line used to inform the host
> - about hotplug events.
> - - reset-gpios: OF device-tree gpio specification for RST_N pin.
> - - iovcc-supply: I/O Supply Voltage (1.8V or 3.3V)
> - - cvcc12-supply: Digital Core Supply Voltage (1.2V)
> -
> - HDMI audio properties:
> - - #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin
> -is wired, <1> if the both are wired. HDMI audio is
> -configured only if this property is found.
> - - sil,i2s-data-lanes: Array of up to 4 integers with values of 0-3
> -Each integer indicates which i2s pin is connected to which
> -audio fifo. The first integer selects i2s audio pin for the
> -first audio fifo#0 (HDMI channels 1&2), second for fifo#1
> -(HDMI channels 3&4), and so on. There is 4 fifos and 4 i2s
> -pins (SD0 - SD3). Any i2s pin can be connected to any fifo,
> -but there can be no gaps. E.g. an i2s pin must be mapped to
> -fifo#0 and fifo#1 before mapping a channel to fifo#2. Default
> -value is <0>, describing SD0 pin beiging routed to hdmi audio
> -fifo #0.
> - - clocks: phandle and clock specifier for each clock listed in
> - the clock-names property
> - - clock-names: "mclk"
> -Describes SII902x MCLK input. MCLK can be used to produce
> -HDMI audio CTS values. This property follows
> -Documentation/devicetree/bindings/clock/clock-bindings.txt
> -consumer binding.
> -
> - If HDMI audio is configured the sii902x device becomes an I2S
> - and/or spdif audio codec component (e.g a digital audio sink),
> - that can be used in configuring a full audio devices with
> - simple-card or audio-graph-card binding. See their binding
> - documents on how to describe the way the sii902x device is
> - connected to the rest of the audio system:
> - Documentation/devicetree/bindings/sound/simple-card.yaml
> - Documentation/devicetree/bindings/sound/audio-graph-card.yaml
> - Note: In case of the audio-graph-card binding the used port
> - index should be 3.
At least the audio port was defined.
> -
> -Optional subnodes:
> - - video input: this subnode can contain a video input port node
> - to connect the bridge to a display controller output (See this
> - documentation [1]).
> -
> -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> -
> -Example:
> - hdmi-bridge@39 {
> - compatible = "sil,sii9022";
> - reg = <0x39>;
> - reset-gpios = < 1 0>;
> - iovcc-supply = <_hdmi>;
> - cvcc12-supply = <_hdmi>;
> -
> - #sound-dai-cells = <0>;
> - sil,i2s-data-lanes = < 0 1 2 >;
> - clocks = <>;
> - clock-names = "mclk";
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - bridge_in: endpoint {
> - remote-endpoint = <_out>;
> - };
> - };
> - };
> - };
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
> b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
> new file mode 100644
> index ..b39537f4fe8694ef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
> @@ -0,0 +1,133 @@
> +#
Re: [PATCH 6/7] drm/amdgpu: Ensure kunmap is called on error
Am 11.12.21 um 00:24 schrieb ira.we...@intel.com:
From: Ira Weiny
The default case leaves the buffer object mapped in error.
Add amdgpu_bo_kunmap() to that case to ensure the mapping is cleaned up.
Mhm, good catch. But why do you want to do this in the first place?
Christian.
Signed-off-by: Ira Weiny
---
NOTE: It seems like this function could use a fair bit of refactoring
but this is the easiest way to fix the actual bug.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 1 +
1 file changed, 1 insertion(+)
nice
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 6f8de11a17f1..b3ffd0f6b35f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -889,6 +889,7 @@ static int amdgpu_uvd_cs_msg(struct amdgpu_uvd_cs_ctx *ctx,
return 0;
default:
+ amdgpu_bo_kunmap(bo);
DRM_ERROR("Illegal UVD message type (%d)!\n", msg_type);
}
Re: [PATCH v2 0/3] drm/i915: Support bigger GuC RSA keys
On 12/10/2021 4:07 PM, Daniele Ceraolo Spurio wrote: Some of the newer platforms use a bigger RSA key to authenticate the GuC, which is provided to the HW via a ggtt-pinned object instead of mmio. While doing the changes for this I've also spotted an inconsistency in the error status of the fw on init failure, so I've added a path to fix that as well. v2: clarify in comments that the expected RSA size is hardcoded in the bootrom (Matt) I've confirmed with Matt that he's ok with the updated comment and pushed. Daniele Cc: Michal Wajdeczko Cc: John Harrison Cc: Matthew Brost Daniele Ceraolo Spurio (2): drm/i915/uc: correctly track uc_fw init failure drm/i915/guc: support bigger RSA keys Michal Wajdeczko (1): drm/i915/uc: Prepare for different firmware key sizes drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 33 ++-- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 75 +- drivers/gpu/drm/i915/gt/uc/intel_huc.h| 2 - drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 95 --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 18 +++-- 5 files changed, 128 insertions(+), 95 deletions(-)
Re: RPI 7" display touch controller
On Mon, Dec 13, 2021 at 4:04 AM Dave Stevenson
wrote:
>
> On Fri, 10 Dec 2021 at 22:40, Tim Harvey wrote:
> >
> > On Fri, Dec 10, 2021 at 11:29 AM Tim Harvey wrote:
> > >
> > > On Fri, Dec 10, 2021 at 10:41 AM Dave Stevenson
> > > wrote:
> > > >
> > > > On Fri, 10 Dec 2021 at 18:20, Tim Harvey wrote:
> > > > >
> > > > > On Thu, Nov 18, 2021 at 12:52 PM Tim Harvey
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Nov 18, 2021 at 10:30 AM Dave Stevenson
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, 18 Nov 2021 at 17:36, Tim Harvey
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Tim
> > > > > > > > >
> > > > > > > > > On Thu, 18 Nov 2021 at 01:26, Tim Harvey
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Greetings,
> > > > > > > > > >
> > > > > > > > > > I'm trying to get a RPI 7" touchscreen display working on
> > > > > > > > > > an IMX8MM
> > > > > > > > > > board and while I've been able to get the MIPI DSI display
> > > > > > > > > > and
> > > > > > > > > > backlight working I still can't seem to figure out the touch
> > > > > > > > > > controller.
> > > > > > > > > >
> > > > > > > > > > It's supposed to have an FT5406 controller on it without an
> > > > > > > > > > interrupt
> > > > > > > > > > so I added polling support
> > > > > > > > > > drivers/input/touchscreen/edt-ft5x06.c
> > > > > > > > > > which I was able to verify using another touchscreen with
> > > > > > > > > > that
> > > > > > > > > > controller but when reading data from the FT5406 on the RPI
> > > > > > > > > > controller
> > > > > > > > > > the data does not make sense.
> > > > > > > > > >
> > > > > > > > > > These panels appear to route the I2C from the FT5406 to a
> > > > > > > > > > STM32F103
> > > > > > > > > > MPU that then provides a different I2C slave interface to
> > > > > > > > > > the 15pin
> > > > > > > > > > connector that I'm connected to. On that I2C interface I
> > > > > > > > > > see an i2c
> > > > > > > > > > slave at 0x45 which is managed by the regulator driver
> > > > > > > > > > Marek wrote
> > > > > > > > > > (drivers/regulator/rpi-panel-attiny-regulator.c) and there
> > > > > > > > > > is also an
> > > > > > > > > > i2c slave at 0x38 which I assumed was the FT5406 but I
> > > > > > > > > > believe the MPU
> > > > > > > > > > is perhaps obfuscating that touch data.
> > > > > > > > > >
> > > > > > > > > > Anyone have any ideas on how to make that touch controller
> > > > > > > > > > useful?
> > > > > > > > >
> > > > > > > > > There should be nothing unusual. 0x38 is the EDT touch
> > > > > > > > > controller.
> > > > > > > > > Starting with the Raspberry Pi OS Bullseye release, we're now
> > > > > > > > > using
> > > > > > > > > the panel directly from DRM rather than through the firmware.
> > > > > > > > > That's
> > > > > > > > > based on the branch at
> > > > > > > > > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/
> > > > > > > > >
> > > > > > > >
> > > > > > > > Dave,
> > > > > > > >
> > > > > > > > That sounds like the driver that made it into mainline with
> > > > > > > > Eric's
> > > > > > > > commit 2f733d6194bd ("drm/panel: Add support for the Raspberry
> > > > > > > > Pi 7"
> > > > > > > > Touchscreen."). I looked there but that driver just deals with
> > > > > > > > the DSI
> > > > > > > > and not with touch.
> > > > > > >
> > > > > > > No, we've reverted away from that driver as it exposes no
> > > > > > > regulator
> > > > > > > framework either, so again the touch element loses power.
> > > > > > >
> > > > > > > > > I also added polling support to edt-ft5x04.c.
> > > > > > > > > For DT, it uses a combination of the overlays vc4-kms-v3d,
> > > > > > > > > vc4-kms-dsi-7inch, and that includes edt-ft5406.dtsi, all of
> > > > > > > > > which are
> > > > > > > > > in /arch/arm/boot/dts/overlays
> > > > > > > >
> > > > > > > > It doesn't look like you ever submitted your edt-ft5x04 polling
> > > > > > > > mode
> > > > > > > > support upstream. I saw another series to add polling support
> > > > > > > > submitted by Nicolas back in 2019 but was never followed up on
> > > > > > > > (https://patchwork.kernel.org/project/linux-input/list/?series=112187=both).
> > > > > > >
> > > > > > > No I haven't as it's been crazy trying to get this lot to work
> > > > > > > under
> > > > > > > KMS at all over the last couple of months.
> > > > > > >
> > > > > > > > I have updated Nicolas' patch with the changes requested and am
> > > > > > > > happy
> > > > > > > > to submit it upstream. The benefit of his patch is that it uses
> > > > > > > > a dt
> > > > > > > > binding for the polling interval. I'm happy to submit this
> > > > > > > > upstream.
> > > > > > >
> > > > > > > I hadn't seen Nicolas' patches, hence implementing it myself.
> > > > > > >
> > > > > > > If you've implemented the requested changes, could you check that
> > > > >
Re: [PATCH v4 2/6] drm: improve drm_buddy_alloc function
On 09/12/2021 15:47, Paneer Selvam, Arunpravin wrote:
[AMD Official Use Only]
Hi Matthew,
Ping on this?
No new comments from me :) I guess just a question of what we should do
with the selftests, and then ofc at some point being able to throw this
at CI, or at least test locally, once the series builds.
Regards,
Arun
-Original Message-
From: amd-gfx On Behalf Of Arunpravin
Sent: Wednesday, December 1, 2021 10:10 PM
To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
amd-...@lists.freedesktop.org
Cc: dan...@ffwll.ch; Paneer Selvam, Arunpravin ;
jani.nik...@linux.intel.com; matthew.a...@intel.com; tzimmerm...@suse.de; Deucher, Alexander
; Koenig, Christian
Subject: [PATCH v4 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
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 316 +-
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, 285 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c index
9340a4b61c5a..7f47632821f4 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -280,23 +280,97 @@ void drm_buddy_free_list(struct drm_buddy_mm *mm, struct
list_head *objects) } EXPORT_SYMBOL(drm_buddy_free_list);
-/**
- * drm_buddy_alloc - 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 _buddy_block on success
- */
-struct drm_buddy_block *
-drm_buddy_alloc(struct drm_buddy_mm *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 *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(>roots[i]->tmp_link, );
+
+ do {
+ u64 block_start;
+ u64 block_end;
+
+ block = list_first_entry_or_null(,
+struct drm_buddy_block,
+tmp_link);
+ if (!block)
+ break;
+
+ list_del(>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;
+ }
+
+
[PATCH] drm/edid: support Microsoft extension for HMDs and specialized monitors
Add minimal support for parsing VSDBs documented in Microsoft's "EDID
extension for head-mounted and specialized monitors" [1]. The version
field and the desktop usage flag can be used to set the non_desktop
connector property.
Remove the non-desktop quirk for devices that are verified to contain
the VSDB: HPN-3515 and LEN-B800. Presumably most of the other Windows
Mixed Reality headsets contain it as well, but there are ACR-7FCE and
SEC-5194 devices without it.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/display/specialized-monitors-edid-extension
Tested with HPN-36C1 and LEN-B800.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/drm_edid.c | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 12893e7be89b..baea65dfff7d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -93,6 +93,8 @@ static int oui(u8 first, u8 second, u8 third)
/* Non desktop display (i.e. HMD) */
#define EDID_QUIRK_NON_DESKTOP (1 << 12)
+#define MICROSOFT_IEEE_OUI 0xca125c
+
struct detailed_mode_closure {
struct drm_connector *connector;
struct edid *edid;
@@ -212,9 +214,7 @@ static const struct edid_quirk {
/* Windows Mixed Reality Headsets */
EDID_QUIRK('A', 'C', 'R', 0x7fce, EDID_QUIRK_NON_DESKTOP),
- EDID_QUIRK('H', 'P', 'N', 0x3515, EDID_QUIRK_NON_DESKTOP),
EDID_QUIRK('L', 'E', 'N', 0x0408, EDID_QUIRK_NON_DESKTOP),
- EDID_QUIRK('L', 'E', 'N', 0xb800, EDID_QUIRK_NON_DESKTOP),
EDID_QUIRK('F', 'U', 'J', 0x1970, EDID_QUIRK_NON_DESKTOP),
EDID_QUIRK('D', 'E', 'L', 0x7fce, EDID_QUIRK_NON_DESKTOP),
EDID_QUIRK('S', 'E', 'C', 0x144a, EDID_QUIRK_NON_DESKTOP),
@@ -4222,6 +4222,17 @@ static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
return oui(db[3], db[2], db[1]) == HDMI_FORUM_IEEE_OUI;
}
+static bool cea_db_is_microsoft_vsdb(const u8 *db)
+{
+ if (cea_db_tag(db) != VENDOR_BLOCK)
+ return false;
+
+ if (cea_db_payload_len(db) != 21)
+ return false;
+
+ return oui(db[3], db[2], db[1]) == MICROSOFT_IEEE_OUI;
+}
+
static bool cea_db_is_vcdb(const u8 *db)
{
if (cea_db_tag(db) != USE_EXTENDED_TAG)
@@ -5149,6 +5160,25 @@ drm_parse_hdmi_vsdb_video(struct drm_connector
*connector, const u8 *db)
drm_parse_hdmi_deep_color_info(connector, db);
}
+/*
+ * See EDID extension for head-mounted and specialized monitors, specified at:
+ *
https://docs.microsoft.com/en-us/windows-hardware/drivers/display/specialized-monitors-edid-extension
+ */
+static void drm_parse_microsoft_vsdb(struct drm_connector *connector,
+const u8 *db)
+{
+ struct drm_display_info *info = >display_info;
+ u8 version = db[4];
+ bool desktop_usage = db[5] & BIT(6);
+
+ /* Version 1 and 2 for HMDs, version 3 flags desktop usage explicitly */
+ if (version == 1 || version == 2 || (version == 3 && !desktop_usage))
+ info->non_desktop = 1;
+
+ drm_dbg_kms(connector->dev, "HMD or specialized display VSDB version
%u: 0x%02x\n",
+ version, db[5]);
+}
+
static void drm_parse_cea_ext(struct drm_connector *connector,
const struct edid *edid)
{
@@ -5179,6 +5209,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_hdmi_vsdb_video(connector, db);
if (cea_db_is_hdmi_forum_vsdb(db))
drm_parse_hdmi_forum_vsdb(connector, db);
+ if (cea_db_is_microsoft_vsdb(db))
+ drm_parse_microsoft_vsdb(connector, db);
if (cea_db_is_y420cmdb(db))
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_vcdb(db))
base-commit: fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf
--
2.34.1
Re: [PATCH] drm/i915: Fix implicit use of struct pci_dev
On Mon, 13 Dec 2021, broo...@kernel.org wrote:
> From: Mark Brown
>
> intel_device_info.h references struct pci_dev but does not ensure that
> the struct has been declared, causing build failures if something in
> other headers changes so that the implicit dependency it is relying on
> is no longer satisfied:
>
> In file included from
> /tmp/next/build/drivers/gpu/drm/i915/intel_device_info.h:32,
> from
> /tmp/next/build/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h:11,
> from
> /tmp/next/build/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:11:
> /tmp/next/build/drivers/gpu/drm/i915/display/intel_display.h:643:39: error:
> 'struct pci_dev' declared inside parameter list will not be visible outside
> of this definition or declaration [-Werror]
> 643 | bool intel_modeset_probe_defer(struct pci_dev *pdev);
> | ^~~
> cc1: all warnings being treated as errors
>
> Add a declaration of the struct to fix this.
>
> Signed-off-by: Mark Brown
Thanks,
Fixes: 94b541f53db1 ("drm/i915: Add intel_modeset_probe_defer() helper")
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 4b688a9727b39..377790393a855 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -57,6 +57,7 @@ struct intel_plane;
> struct intel_plane_state;
> struct intel_remapped_info;
> struct intel_rotation_info;
> +struct pci_dev;
>
> enum i915_gpio {
> GPIOA,
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v4 4/6] drm: implement a method to free unused pages
On 01/12/2021 16:39, Arunpravin wrote:
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:
- remove drm_buddy_block_trim() error handling and
print a warn message if it fails
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 72 ++-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 10 +++
include/drm/drm_buddy.h | 4 ++
3 files changed, 83 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index eddc1eeda02e..707efc82216d 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -434,7 +434,8 @@ alloc_from_freelist(struct drm_buddy_mm *mm,
static int __alloc_range(struct drm_buddy_mm *mm,
struct list_head *dfs,
u64 start, u64 size,
-struct list_head *blocks)
+struct list_head *blocks,
+bool trim_path)
{
struct drm_buddy_block *block;
struct drm_buddy_block *buddy;
@@ -480,8 +481,20 @@ static int __alloc_range(struct drm_buddy_mm *mm,
if (!drm_buddy_block_is_split(block)) {
err = split_block(mm, block);
- if (unlikely(err))
+ if (unlikely(err)) {
+ if (trim_path)
+ /*
+* Here in case of trim, we return and
dont goto
+* split failure path as it removes
from the
+* original list and potentially also
freeing
+* the block. so we could leave as it
is,
+* worse case we get some internal
fragmentation
+* and leave the decision to the user
+*/
+ return err;
Hmm, ideally we don't want to leave around blocks where both buddies are
free without then also merging them back(not sure if that trips some
BUG_ON). Also IIUC, if we hit this failure path, depending on where the
split_block() fails we might be allocating something less than new_size?
Also if it's the first split_block() that fails then the user just gets
an empty list?
Could we perhaps just turn this node into a temporary root node to
prevent recursively freeing itself, but still retain the
un-splitting/freeing of the other nodes i.e something like:
list_del(>link);
mark_free(mm, block);
mm->avail += ...;
/* Prevent recursively freeing this node */
parent = block->parent;
block->parent = NULL;
list_add(>tmp_link, );
ret = _alloc_range(mm, , new_start, new_size, blocks);
if (ret) {
mem->avail -= ...;
mark_allocated(block);
list_add(>link, blocks);
}
block->parent = parent;
return ret;
That way we can also drop the special trim_path handling. Thoughts?
+
goto err_undo;
+ }
}
list_add(>right->tmp_link, dfs);
@@ -535,8 +548,61 @@ static int __drm_buddy_alloc_range(struct drm_buddy_mm *mm,
for (i = 0; i < mm->n_roots; ++i)
list_add_tail(>roots[i]->tmp_link, );
- return __alloc_range(mm, , start, size, blocks);
+ return __alloc_range(mm, , start, size, blocks, 0);
+}
+
+/**
+ * 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 *mm,
+u64 new_size,
+struct list_head *blocks)
+{
+ struct drm_buddy_block *block;
+ u64 new_start;
+ LIST_HEAD(dfs);
+
+ if (!list_is_singular(blocks))
+ return -EINVAL;
+
+ block = list_first_entry(blocks,
+struct drm_buddy_block,
+link);
+
+ if (!drm_buddy_block_is_allocated(block))
+
Re: [PATCH RESEND v7 12/12] drm/i915: Move the GGTT from i915 private data to the GT
Hi Matt,
On Mon, Dec 13, 2021 at 10:16:47AM -0800, Matt Roper wrote:
> On Sun, Dec 12, 2021 at 05:21:17PM +0200, Andi Shyti wrote:
> > GGTT was available both through i915->ggtt and gt->ggtt, and we
> > eventually want to get rid of the i915->ggtt one.
> > Move the GGTT from i915 to gt and use to_gt() for accesssing the
> > ggtt.
> >
> > Signed-off-by: Andi Shyti
> > Cc: Michal Wajdeczko
> > Cc: Matt Roper
> > ---
> ...
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > index 14216cc471b1..02fc7641b82e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > @@ -69,7 +69,7 @@ enum intel_submission_method {
> > struct intel_gt {
> > struct drm_i915_private *i915;
> > struct intel_uncore *uncore;
> > - struct i915_ggtt *ggtt;
> > + struct i915_ggtt ggtt;
> >
> > struct intel_uc uc;
> >
>
> I'm not sure this is the direction we want to go. Although it works for
> the initial multi-tile support, there's some other stuff coming up soon
> that will require two intel_gt's to share the same ggtt rather than
> each having an independent one.
Sure... I sent this just to have an opinion, I'm dropping it.
Thanks,
Andi
Re: [PATCH RESEND v7 12/12] drm/i915: Move the GGTT from i915 private data to the GT
On Sun, Dec 12, 2021 at 05:21:17PM +0200, Andi Shyti wrote:
> GGTT was available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Move the GGTT from i915 to gt and use to_gt() for accesssing the
> ggtt.
>
> Signed-off-by: Andi Shyti
> Cc: Michal Wajdeczko
> Cc: Matt Roper
> ---
...
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index 14216cc471b1..02fc7641b82e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -69,7 +69,7 @@ enum intel_submission_method {
> struct intel_gt {
> struct drm_i915_private *i915;
> struct intel_uncore *uncore;
> - struct i915_ggtt *ggtt;
> + struct i915_ggtt ggtt;
>
> struct intel_uc uc;
>
I'm not sure this is the direction we want to go. Although it works for
the initial multi-tile support, there's some other stuff coming up soon
that will require two intel_gt's to share the same ggtt rather than
each having an independent one.
Matt
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [PATCH RESEND v7 11/12] drm/i915: Use to_gt() helper for GGTT accesses
Hi Matt,
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index 95174938b160..2619bb17b6eb 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -571,6 +571,8 @@ static int i915_driver_hw_probe(struct drm_i915_private
> > *dev_priv)
> >
> > i915_perf_init(dev_priv);
> >
> > + intel_gt_init_hw_early(to_gt(dev_priv), to_gt(dev_priv)->ggtt);
>
> intel_gt_init_hw_early is defined as
>
> void intel_gt_init_hw_early(struct intel_gt *gt, struct i915_ggtt
> *ggtt)
> {
> gt->ggtt = ggtt;
> }
>
> so this call is now essentially doing
>
> to_gt(dev_priv)->ggtt = to_gt(dev_priv)->ggtt
>
> which isn't what you intended. It might be better to just drop the
> function completely and instead assign the gt's ggtt pointer here to a
> drmm_kzalloc() dynamic allocation.
ehehe... yes, I actually had this fixed (in mock device it's
indeed correct), but I might have brought it back by mistake.
Thanks for noticing it.
The next patch removes it.
Andi
[PATCH 3/3] drm/vkms: drop "Multiple overlay planes" TODO
Signed-off-by: José Expósito --- Documentation/gpu/vkms.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 941f0e7e5eef..9c873c3912cc 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -124,8 +124,6 @@ Add Plane Features There's lots of plane features we could add support for: -- Multiple overlay planes. [Good to get started] - - Clearing primary plane: clear primary plane before plane composition (at the start) for correctness of pixel blend ops. It also guarantees alpha channel is cleared in the target buffer for stable crc. [Good to get started] -- 2.25.1
[PATCH 1/3] drm/vkms: refactor overlay plane creation
Move the logic to create an overlay plane to its own function.
Refactor, no functional changes.
Signed-off-by: José Expósito
---
drivers/gpu/drm/vkms/vkms_output.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_output.c
b/drivers/gpu/drm/vkms/vkms_output.c
index 04406bd3ff02..2e805b2d36ae 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -32,6 +32,21 @@ static const struct drm_connector_helper_funcs
vkms_conn_helper_funcs = {
.get_modes= vkms_conn_get_modes,
};
+static int vkms_add_overlay_plane(struct vkms_device *vkmsdev, int index,
+ struct drm_crtc *crtc)
+{
+ struct vkms_plane *overlay;
+
+ overlay = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_OVERLAY, index);
+ if (IS_ERR(overlay))
+ return PTR_ERR(overlay);
+
+ if (!overlay->base.possible_crtcs)
+ overlay->base.possible_crtcs = drm_crtc_mask(crtc);
+
+ return 0;
+}
+
int vkms_output_init(struct vkms_device *vkmsdev, int index)
{
struct vkms_output *output = >output;
@@ -39,7 +54,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
struct drm_connector *connector = >connector;
struct drm_encoder *encoder = >encoder;
struct drm_crtc *crtc = >crtc;
- struct vkms_plane *primary, *cursor = NULL, *overlay = NULL;
+ struct vkms_plane *primary, *cursor = NULL;
int ret;
int writeback;
@@ -48,12 +63,9 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
return PTR_ERR(primary);
if (vkmsdev->config->overlay) {
- overlay = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_OVERLAY,
index);
- if (IS_ERR(overlay))
- return PTR_ERR(overlay);
-
- if (!overlay->base.possible_crtcs)
- overlay->base.possible_crtcs = drm_crtc_mask(crtc);
+ ret = vkms_add_overlay_plane(vkmsdev, index, crtc);
+ if (ret)
+ return ret;
}
if (vkmsdev->config->cursor) {
--
2.25.1
[PATCH 2/3] drm/vkms: add support for multiple overlay planes
Add a new module parameter to allow to set the number of overlay planes
to create. Set it to 1 by default in order to keep the "enable_overlay"
backwards compatible.
Signed-off-by: José Expósito
---
drivers/gpu/drm/vkms/vkms_drv.c| 5 +
drivers/gpu/drm/vkms/vkms_drv.h| 1 +
drivers/gpu/drm/vkms/vkms_output.c | 9 ++---
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 0ffe5f0e33f7..bb98f6c6c561 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -51,6 +51,10 @@ static bool enable_overlay;
module_param_named(enable_overlay, enable_overlay, bool, 0444);
MODULE_PARM_DESC(enable_overlay, "Enable/Disable overlay support");
+static unsigned int num_overlay_planes = 1;
+module_param_named(num_overlay_planes, num_overlay_planes, uint, 0444);
+MODULE_PARM_DESC(num_overlay_planes, "Number of overlay planes to create");
+
DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
static void vkms_release(struct drm_device *dev)
@@ -229,6 +233,7 @@ static int __init vkms_init(void)
config->cursor = enable_cursor;
config->writeback = enable_writeback;
config->overlay = enable_overlay;
+ config->num_overlay_planes = num_overlay_planes;
return vkms_create(config);
}
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index d48c23d40ce5..33bdf717e3cd 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -97,6 +97,7 @@ struct vkms_config {
bool writeback;
bool cursor;
bool overlay;
+ unsigned int num_overlay_planes;
/* only set when instantiated */
struct vkms_device *dev;
};
diff --git a/drivers/gpu/drm/vkms/vkms_output.c
b/drivers/gpu/drm/vkms/vkms_output.c
index 2e805b2d36ae..6f26998fdb7e 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -57,15 +57,18 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
struct vkms_plane *primary, *cursor = NULL;
int ret;
int writeback;
+ unsigned int n;
primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY, index);
if (IS_ERR(primary))
return PTR_ERR(primary);
if (vkmsdev->config->overlay) {
- ret = vkms_add_overlay_plane(vkmsdev, index, crtc);
- if (ret)
- return ret;
+ for (n = 0; n < vkmsdev->config->num_overlay_planes; n++) {
+ ret = vkms_add_overlay_plane(vkmsdev, index, crtc);
+ if (ret)
+ return ret;
+ }
}
if (vkmsdev->config->cursor) {
--
2.25.1
[PATCH 0/3] drm/vkms: add support for multiple overlay planes
Hi all, First of all, let me quickly introduce myself. I'm José Expósito and I'm a hobbyist open source developer. My contributions are usually in the kernel input/HID subsystems and in its userspace library (libinput) as well as other projects. I'm trying to learn more about the GPU and I found VKMS as a good project to get started. So, now that you have been warned about my (lack) of experience in this subsystem, let's get into the patches. The series adds support for multiple overlay planes by adding a new module parameter that allows to configure the number of overlay planes to add. I checked that the planes are properly created using drm_info[1] and also executed the IGT test "kms_plane" to make sure that the planes were listed in the output. In addition, I checked the vkms_composer and -even though I'm not sure how to properly test it- it looks like it is already prepared to compose an arbitrary number of planes. Having said that, I really hope I didn't make any obvious mistakes. I noticed that the docs say: > For all of these, we also want to review the igt test coverage and > make sure all relevant igt testcases work on vkms I ran some plane related tests, but some of them were already failing without my code, so I'd appreciate some help with this bit. Thank you very much in advance for your time. Any suggestions to improve this patchset or about what to work on next are very welcome. Jose [1] https://github.com/ascent12/drm_info José Expósito (3): drm/vkms: refactor overlay plane creation drm/vkms: add support for multiple overlay planes drm/vkms: drop "Multiple overlay planes" TODO Documentation/gpu/vkms.rst | 2 -- drivers/gpu/drm/vkms/vkms_drv.c| 5 + drivers/gpu/drm/vkms/vkms_drv.h| 1 + drivers/gpu/drm/vkms/vkms_output.c | 29 ++--- 4 files changed, 28 insertions(+), 9 deletions(-) -- 2.25.1
Re: [PATCH RESEND v7 11/12] drm/i915: Use to_gt() helper for GGTT accesses
On Sun, Dec 12, 2021 at 05:21:16PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
> .../drm/i915/display/intel_plane_initial.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +-
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 16 +++
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 6 +++---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 8
> .../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_context.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_mman.c| 16 +++
> .../drm/i915/gem/selftests/i915_gem_object.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 ++---
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 6 +++---
> drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 ++--
> drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +-
> drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> drivers/gpu/drm/i915/i915_driver.c| 8
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 20 +--
> drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++---
> drivers/gpu/drm/i915/i915_getparam.c | 2 +-
> drivers/gpu/drm/i915/i915_perf.c | 4 ++--
> drivers/gpu/drm/i915/selftests/i915_gem.c | 8
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 6 +++---
> drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
> .../gpu/drm/i915/selftests/mock_gem_device.c | 4 ++--
> drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 +-
> 32 files changed, 82 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 8be01b93015f..98319c0322d7 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -595,7 +595,7 @@ static void ivb_fbc_activate(struct intel_fbc *fbc)
> else if (DISPLAY_VER(i915) == 9)
> skl_fbc_program_cfb_stride(fbc);
>
> - if (i915->ggtt.num_fences)
> + if (to_gt(i915)->ggtt->num_fences)
> snb_fbc_program_fence(fbc);
>
> intel_de_write(i915, ILK_DPFC_CONTROL,
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index adc3a81be9f7..41d279db2be6 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -180,7 +180,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
> struct drm_device *dev = helper->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> - struct i915_ggtt *ggtt = _priv->ggtt;
> + struct i915_ggtt *ggtt = to_gt(dev_priv)->ggtt;
> const struct i915_ggtt_view view = {
> .type = I915_GGTT_VIEW_NORMAL,
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index 01ce1d72297f..e4186a0b8edb 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -94,7 +94,7 @@ initial_plane_vma(struct drm_i915_private *i915,
> goto err_obj;
> }
>
> - vma = i915_vma_instance(obj, >ggtt.vm, NULL);
> + vma = i915_vma_instance(obj, _gt(i915)->ggtt->vm, NULL);
> if (IS_ERR(vma))
> goto err_obj;
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> index babfecb17ad1..e5b0f66ea1fe 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> @@ -174,7 +174,7 @@ i915_gem_context_get_eb_vm(struct i915_gem_context *ctx)
>
> vm = ctx->vm;
> if (!vm)
> - vm = >i915->ggtt.vm;
> + vm = _gt(ctx->i915)->ggtt->vm;
> vm = i915_vm_get(vm);
>
> return vm;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index ec7c4a29a720..3078611d5bfe 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++
Re: [PATCH v6 3/6] drm: sun4i: dsi: Add bridge support
On Fri, Dec 10, 2021 at 04:47:08PM +0530, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output, those
> can have an option to connect the DSI host by means of interface
> bridge converter.
>
> This DSI to non-DSI interface bridge converter would require
> DSI Host to handle drm bridge functionalities in order to
> communicate interface bridge.
>
> This patch adds support for bridge functionalities in Allwinner
> DSI controller.
>
> Supporting down-stream bridge makes few changes in the driver.
>
> - It drops drm_connector and related operations as drm_bridge_attach
> creates connector during attachment.
>
> - It drop panel pointer and iterate the bridge, so-that it can operate
> the normal bridge and panel_bridge in constitutive callbacks.
>
> - It uses devm_drm_of_get_bridge for panel or bridge lookup. It uses
> port 0 and endpoint 0 to support I2C-based bridges eventhough the
> usual Allwinner DSI OF graph doesn't require this for panel and
> non-I2C based downstream bridges.
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v6:
> - support donwstream bridge
> - drop bridge conversion
> - devm_drm_of_get_bridge() require child lookup
> https://patchwork.kernel.org/project/dri-devel/cover/20211207054747.461029-1-ja...@amarulasolutions.com/
> Changes for v5:
> - add atomic APIs
> - find host and device variant DSI devices.
> Changes for v4, v3:
> - none
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 83 ++
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 9 +--
> 2 files changed, 33 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 9cf91dcac3f2..f1d612bf1a0b 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -21,6 +21,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -720,6 +721,7 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
> *encoder)
> struct mipi_dsi_device *device = dsi->device;
> union phy_configure_opts opts = { };
> struct phy_configure_opts_mipi_dphy *cfg = _dphy;
> + struct drm_bridge *iter;
> u16 delay;
> int err;
>
> @@ -769,8 +771,10 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
> *encoder)
> phy_configure(dsi->dphy, );
> phy_power_on(dsi->dphy);
>
> - if (dsi->panel)
> - drm_panel_prepare(dsi->panel);
> + list_for_each_entry(iter, >bridge_chain, chain_node) {
> + if (iter->funcs->pre_enable)
> + iter->funcs->pre_enable(iter);
> + }
Like we discussed in the previous version already, this is unnecessary,
just like the poking at bridge_chain in the encoder.
Maxime
signature.asc
Description: PGP signature
[PATCH] drm/i915: Fix implicit use of struct pci_dev
From: Mark Brown
intel_device_info.h references struct pci_dev but does not ensure that
the struct has been declared, causing build failures if something in
other headers changes so that the implicit dependency it is relying on
is no longer satisfied:
In file included from
/tmp/next/build/drivers/gpu/drm/i915/intel_device_info.h:32,
from
/tmp/next/build/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h:11,
from
/tmp/next/build/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:11:
/tmp/next/build/drivers/gpu/drm/i915/display/intel_display.h:643:39: error:
'struct pci_dev' declared inside parameter list will not be visible outside of
this definition or declaration [-Werror]
643 | bool intel_modeset_probe_defer(struct pci_dev *pdev);
| ^~~
cc1: all warnings being treated as errors
Add a declaration of the struct to fix this.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/i915/display/intel_display.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 4b688a9727b39..377790393a855 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -57,6 +57,7 @@ struct intel_plane;
struct intel_plane_state;
struct intel_remapped_info;
struct intel_rotation_info;
+struct pci_dev;
enum i915_gpio {
GPIOA,
--
2.30.2
Re: [PATCH v6 2/6] drm: sun4i: dsi: Add component only once DSI device attached
On Fri, Dec 10, 2021 at 04:47:07PM +0530, Jagan Teki wrote:
> Having component_add for running all drm bind callbacks returns
> error or unbound due to chain of DSI devices connected across
> bridge topology on a display pipeline.
I'm not sure what that means?
> In a typical bridge oriented display pipeline where the host is
> connected to the bridge converter and that indeed connected to
> a panel.
>
> DRM => SUN6I DSI Host => Chipone ICN6211 => BananaPi Panel
>
> The bridge converter is looking for a panel to probe first and
> then attach the host. The host attach is looking for a bridge
> converter to probe and preserve bridge pointer, at this movement
^ moment ?
> the host is trying to bind the all callbacks and one of the bind
> callback in the DSI host is trying to find the bridge using the
> bridge pointer in sun6i_dsi_attach call.
>
> chipone_probe().start
> drm_of_find_panel_or_bridge
> mipi_dsi_attach
> sun6i_dsi_attach
> drm_of_find_panel_or_bridge
> chipone_probe().done
>
> sun6i_dsi_probe().start
> mipi_dsi_host_register
> component_add
> sun6i_dsi_probe().done
>
> However, the movement when panel defers the probe, will make the
> bridge converter defer the host attach call which eventually found
> a NULL bridge pointer during DSI component bind callback.
>
> So, in order to prevent this scenario of binding invalid bridge,
> wait for DSI devices on the pipeline to probe first and start the
> binding process by moving component_add in host probe to attach call.
>
> chipone_probe().start
> drm_of_find_panel_or_bridge
> mipi_dsi_attach
> sun6i_dsi_attach
> drm_of_find_panel_or_bridge
> component_add
> chipone_probe().done
>
> sun6i_dsi_probe().start
> mipi_dsi_host_register
> sun6i_dsi_probe().done
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v6:
> - none
> Changes for v5:
> - new patch
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 120 +
> 1 file changed, 61 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 4bdcce8f1d84..9cf91dcac3f2 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -959,11 +959,63 @@ static int sun6i_dsi_dcs_read(struct sun6i_dsi *dsi,
> return 1;
> }
>
> +static int sun6i_dsi_bind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct drm_device *drm = data;
> + struct sun6i_dsi *dsi = dev_get_drvdata(dev);
> + int ret;
> +
> + drm_encoder_helper_add(>encoder,
> +_dsi_enc_helper_funcs);
> + ret = drm_simple_encoder_init(drm, >encoder,
> + DRM_MODE_ENCODER_DSI);
> + if (ret) {
> + dev_err(dsi->dev, "Couldn't initialise the DSI encoder\n");
> + return ret;
> + }
> + dsi->encoder.possible_crtcs = BIT(0);
> +
> + drm_connector_helper_add(>connector,
> + _dsi_connector_helper_funcs);
> + ret = drm_connector_init(drm, >connector,
> + _dsi_connector_funcs,
> + DRM_MODE_CONNECTOR_DSI);
> + if (ret) {
> + dev_err(dsi->dev,
> + "Couldn't initialise the DSI connector\n");
> + goto err_cleanup_connector;
> + }
> +
> + drm_connector_attach_encoder(>connector, >encoder);
> +
> + return 0;
> +
> +err_cleanup_connector:
> + drm_encoder_cleanup(>encoder);
> + return ret;
> +}
> +
> +static void sun6i_dsi_unbind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct sun6i_dsi *dsi = dev_get_drvdata(dev);
> +
> + drm_encoder_cleanup(>encoder);
> +}
> +
> +static const struct component_ops sun6i_dsi_ops = {
> + .bind = sun6i_dsi_bind,
> + .unbind = sun6i_dsi_unbind,
> +};
Just use a forward declaration there, it will make the patch more
straightforward.
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v6 1/6] drm: sun4i: dsi: Drop DRM bind race with bridge attach
On Fri, Dec 10, 2021 at 04:47:06PM +0530, Jagan Teki wrote:
> Existing host driver will keep looking for DRM pointer in
> sun6i_dsi_attach and defers even if the particular DSI device
> is found for the first time. Meanwhile it triggers the bind
> callback and gets the DRM pointer and then continues the
> sun6i_dsi_attach.
>
> This makes a deadlock situation if sun6i_dsi_attach is trying
> to find the bridge.
I'm not sure what you mean by deadlock here, there's no lock involved?
> If interface bridge is trying to call host attach, then host
> sun6i_dsi_attach is trying to find bridge and defers the
> interface bridge even if it found the bridge as bind callback
> does not complete at the movement. So, this sun6i_dsi_attach
> defers interface bridge and triggers the bind callback and
> tries to attach the bridge with a bridge pointer which is not
> available at the moment.
>
> Eventually these callbacks are triggered recursively, as
> sun6i_dsi_attach defers interface bridge and bind callback
> defers sun6i_dsi_attach due to invalid bridge ponter.
^ pointer
>
> This patch prevents this situation by probing all DSI devices
> on the pipeline first and then triggers the bind callback by
> dropping exing DRM binding logic.
^ existing I guess?
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v6:
> - none
> Changes for v5:
> - new patch
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +-
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 -
> 2 files changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 527c7b2474da..4bdcce8f1d84 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -967,14 +967,10 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
>
> if (IS_ERR(panel))
> return PTR_ERR(panel);
> - if (!dsi->drm || !dsi->drm->registered)
> - return -EPROBE_DEFER;
>
> dsi->panel = panel;
> dsi->device = device;
>
> - drm_kms_helper_hotplug_event(dsi->drm);
> -
> dev_info(host->dev, "Attached device %s\n", device->name);
>
> return 0;
> @@ -988,8 +984,6 @@ static int sun6i_dsi_detach(struct mipi_dsi_host *host,
> dsi->panel = NULL;
> dsi->device = NULL;
>
> - drm_kms_helper_hotplug_event(dsi->drm);
> -
> return 0;
> }
>
> @@ -1077,8 +1071,6 @@ static int sun6i_dsi_bind(struct device *dev, struct
> device *master,
>
> drm_connector_attach_encoder(>connector, >encoder);
>
> - dsi->drm = drm;
> -
> return 0;
>
> err_cleanup_connector:
> @@ -1091,7 +1083,7 @@ static void sun6i_dsi_unbind(struct device *dev, struct
> device *master,
> {
> struct sun6i_dsi *dsi = dev_get_drvdata(dev);
>
> - dsi->drm = NULL;
> + drm_encoder_cleanup(>encoder);
> }
>
> static const struct component_ops sun6i_dsi_ops = {
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> index c863900ae3b4..61e88ea6044d 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> @@ -29,7 +29,6 @@ struct sun6i_dsi {
>
> struct device *dev;
> struct mipi_dsi_device *device;
> - struct drm_device *drm;
> struct drm_panel*panel;
> };
>
> --
> 2.25.1
>
signature.asc
Description: PGP signature
Re: [PATCH v6 0/6] drm: sun4i: dsi: Bridge support
Hi, On Fri, Dec 10, 2021 at 04:47:05PM +0530, Jagan Teki wrote: > This series add bridge support for Allwinner DSI controller. > > In addition to previous version, this series add bridge support > only not doing any bridge conversion at the moment. > > Previous version changes [1]. > > Patch 1: Drop the DRM bind race while attaching bridges > > Patch 2: Move component_add into sun6i_dsi_attach > > Patch 3: Add Bridge driver > > Patch 4: Add mode_set API > > Patch 5: Enable DSI Panel > > Patch 6: Enable DSI Bridge > > Patch 7: Enable DSI Bridge (I2C) It would be worth mentioning that we can't apply this patch until the one for drm_of_find_panel_or_bridge has landed? Otherwise, we're going to break every user so far. Maxime signature.asc Description: PGP signature
[PATCH v3 3/3] drm/vc4: plane: Add support for YUV color encodings and ranges
From: Dave Stevenson
The BT601/BT709 color encoding and limited vs full
range properties were not being exposed, defaulting
always to BT601 limited range.
Expose the parameters and set the registers appropriately.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_plane.c | 71 +++--
drivers/gpu/drm/vc4/vc4_regs.h | 19 ++---
2 files changed, 82 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 18627b240a55..1155b0beb620 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -623,6 +623,51 @@ static int vc4_plane_allocate_lbm(struct drm_plane_state
*state)
return 0;
}
+/*
+ * The colorspace conversion matrices are held in 3 entries in the dlist.
+ * Create an array of them, with entries for each full and limited mode, and
+ * each supported colorspace.
+ */
+static const u32 colorspace_coeffs[2][DRM_COLOR_ENCODING_MAX][3] = {
+ {
+ /* Limited range */
+ {
+ /* BT601 */
+ SCALER_CSC0_ITR_R_601_5,
+ SCALER_CSC1_ITR_R_601_5,
+ SCALER_CSC2_ITR_R_601_5,
+ }, {
+ /* BT709 */
+ SCALER_CSC0_ITR_R_709_3,
+ SCALER_CSC1_ITR_R_709_3,
+ SCALER_CSC2_ITR_R_709_3,
+ }, {
+ /* BT2020 */
+ SCALER_CSC0_ITR_R_2020,
+ SCALER_CSC1_ITR_R_2020,
+ SCALER_CSC2_ITR_R_2020,
+ }
+ }, {
+ /* Full range */
+ {
+ /* JFIF */
+ SCALER_CSC0_JPEG_JFIF,
+ SCALER_CSC1_JPEG_JFIF,
+ SCALER_CSC2_JPEG_JFIF,
+ }, {
+ /* BT709 */
+ SCALER_CSC0_ITR_R_709_3_FR,
+ SCALER_CSC1_ITR_R_709_3_FR,
+ SCALER_CSC2_ITR_R_709_3_FR,
+ }, {
+ /* BT2020 */
+ SCALER_CSC0_ITR_R_2020_FR,
+ SCALER_CSC1_ITR_R_2020_FR,
+ SCALER_CSC2_ITR_R_2020_FR,
+ }
+ }
+};
+
/* Writes out a full display list for an active plane to the plane's
* private dlist state.
*/
@@ -1018,9 +1063,20 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
/* Colorspace conversion words */
if (vc4_state->is_yuv) {
- vc4_dlist_write(vc4_state, SCALER_CSC0_ITR_R_601_5);
- vc4_dlist_write(vc4_state, SCALER_CSC1_ITR_R_601_5);
- vc4_dlist_write(vc4_state, SCALER_CSC2_ITR_R_601_5);
+ enum drm_color_encoding color_encoding = state->color_encoding;
+ enum drm_color_range color_range = state->color_range;
+ const u32 *ccm;
+
+ if (color_encoding >= DRM_COLOR_ENCODING_MAX)
+ color_encoding = DRM_COLOR_YCBCR_BT601;
+ if (color_range >= DRM_COLOR_RANGE_MAX)
+ color_range = DRM_COLOR_YCBCR_LIMITED_RANGE;
+
+ ccm = colorspace_coeffs[color_range][color_encoding];
+
+ vc4_dlist_write(vc4_state, ccm[0]);
+ vc4_dlist_write(vc4_state, ccm[1]);
+ vc4_dlist_write(vc4_state, ccm[2]);
}
vc4_state->lbm_offset = 0;
@@ -1449,6 +1505,15 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
DRM_MODE_REFLECT_X |
DRM_MODE_REFLECT_Y);
+ drm_plane_create_color_properties(plane,
+ BIT(DRM_COLOR_YCBCR_BT601) |
+ BIT(DRM_COLOR_YCBCR_BT709) |
+ BIT(DRM_COLOR_YCBCR_BT2020),
+ BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
+ BIT(DRM_COLOR_YCBCR_FULL_RANGE),
+ DRM_COLOR_YCBCR_BT709,
+ DRM_COLOR_YCBCR_LIMITED_RANGE);
+
return plane;
}
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index 489f921ef44d..7538b84a6dca 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -975,7 +975,10 @@ enum hvs_pixel_format {
#define SCALER_CSC0_COEF_CR_OFS_SHIFT 0
#define SCALER_CSC0_ITR_R_601_50x00f0
#define SCALER_CSC0_ITR_R_709_30x00f0
+#define SCALER_CSC0_ITR_R_2020 0x00f0
#define SCALER_CSC0_JPEG_JFIF 0x
+#define SCALER_CSC0_ITR_R_709_3_FR 0x
+#define SCALER_CSC0_ITR_R_2020_FR
[PATCH v3 2/3] drm/vc4: plane: Add support for DRM_FORMAT_P030
From: Dave Stevenson
The P030 format, used with the DRM_FORMAT_MOD_BROADCOM_SAND128 modifier,
is a format output by the video decoder on the BCM2711.
Add native support to the KMS planes for that format.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_plane.c | 128
1 file changed, 97 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index ac761c683663..18627b240a55 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -33,6 +33,7 @@ static const struct hvs_format {
u32 hvs; /* HVS_FORMAT_* */
u32 pixel_order;
u32 pixel_order_hvs5;
+ bool hvs5_only;
} hvs_formats[] = {
{
.drm = DRM_FORMAT_XRGB,
@@ -128,6 +129,12 @@ static const struct hvs_format {
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_2PLANE,
.pixel_order = HVS_PIXEL_ORDER_XYCRCB,
},
+ {
+ .drm = DRM_FORMAT_P030,
+ .hvs = HVS_PIXEL_FORMAT_YCBCR_10BIT,
+ .pixel_order = HVS_PIXEL_ORDER_XYCBCR,
+ .hvs5_only = true,
+ },
};
static const struct hvs_format *vc4_get_hvs_format(u32 drm_format)
@@ -762,47 +769,91 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
case DRM_FORMAT_MOD_BROADCOM_SAND128:
case DRM_FORMAT_MOD_BROADCOM_SAND256: {
uint32_t param = fourcc_mod_broadcom_param(fb->modifier);
- u32 tile_w, tile, x_off, pix_per_tile;
-
- hvs_format = HVS_PIXEL_FORMAT_H264;
-
- switch (base_format_mod) {
- case DRM_FORMAT_MOD_BROADCOM_SAND64:
- tiling = SCALER_CTL0_TILING_64B;
- tile_w = 64;
- break;
- case DRM_FORMAT_MOD_BROADCOM_SAND128:
- tiling = SCALER_CTL0_TILING_128B;
- tile_w = 128;
- break;
- case DRM_FORMAT_MOD_BROADCOM_SAND256:
- tiling = SCALER_CTL0_TILING_256B_OR_T;
- tile_w = 256;
- break;
- default:
- break;
- }
if (param > SCALER_TILE_HEIGHT_MASK) {
- DRM_DEBUG_KMS("SAND height too large (%d)\n", param);
+ DRM_DEBUG_KMS("SAND height too large (%d)\n",
+ param);
return -EINVAL;
}
- pix_per_tile = tile_w / fb->format->cpp[0];
- tile = vc4_state->src_x / pix_per_tile;
- x_off = vc4_state->src_x % pix_per_tile;
+ if (fb->format->format == DRM_FORMAT_P030) {
+ hvs_format = HVS_PIXEL_FORMAT_YCBCR_10BIT;
+ tiling = SCALER_CTL0_TILING_128B;
+ } else {
+ hvs_format = HVS_PIXEL_FORMAT_H264;
+
+ switch (base_format_mod) {
+ case DRM_FORMAT_MOD_BROADCOM_SAND64:
+ tiling = SCALER_CTL0_TILING_64B;
+ break;
+ case DRM_FORMAT_MOD_BROADCOM_SAND128:
+ tiling = SCALER_CTL0_TILING_128B;
+ break;
+ case DRM_FORMAT_MOD_BROADCOM_SAND256:
+ tiling = SCALER_CTL0_TILING_256B_OR_T;
+ break;
+ default:
+ return -EINVAL;
+ break;
+ }
+ }
/* Adjust the base pointer to the first pixel to be scanned
* out.
+*
+* For P030, y_ptr [31:4] is the 128bit word for the start pixel
+* y_ptr [3:0] is the pixel (0-11) contained within that 128bit
+* word that should be taken as the first pixel.
+* Ditto uv_ptr [31:4] vs [3:0], however [3:0] contains the
+* element within the 128bit word, eg for pixel 3 the value
+* should be 6.
*/
for (i = 0; i < num_planes; i++) {
+ u32 tile_w, tile, x_off, pix_per_tile;
+
+ if (fb->format->format == DRM_FORMAT_P030) {
+ /*
+* Spec says: bits [31:4] of the given address
+* should point to the 128-bit word containing
+* the desired starting pixel, and bits[3:0]
+* should be between 0 and 11, indicating which
+* of the 12-pixels in that 128-bit word is the
+* first pixel
[PATCH v3 1/3] drm/fourcc: Add packed 10bit YUV 4:2:0 format
From: Dave Stevenson
Adds a format that is 3 10bit YUV 4:2:0 samples packed into
a 32bit word (with 2 spare bits).
Supported on Broadcom BCM2711 chips.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 11 +++
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 25837b1d6639..07741b678798 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -269,6 +269,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
.num_planes = 3, .char_per_block = { 2, 2, 2 },
.block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
.vsub = 0, .is_yuv = true },
+ { .format = DRM_FORMAT_P030,.depth = 0,
.num_planes = 2,
+ .char_per_block = { 4, 8, 0 }, .block_w = { 3, 3, 0 },
.block_h = { 1, 1, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 7f652c96845b..fc0c1454d275 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -314,6 +314,13 @@ extern "C" {
*/
#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane 16 bits per channel */
+/* 2 plane YCbCr420.
+ * 3 10 bit components and 2 padding bits packed into 4 bytes.
+ * index 0 = Y plane, [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian
+ * index 1 = Cr:Cb plane, [63:0] x:Cr2:Cb2:Cr1:x:Cb1:Cr0:Cb0
[2:10:10:10:2:10:10:10] little endian
+ */
+#define DRM_FORMAT_P030fourcc_code('P', '0', '3', '0') /* 2x2
subsampled Cr:Cb plane 10 bits per channel packed */
+
/* 3 plane non-subsampled (444) YCbCr
* 16 bits per component, but only 10 bits are used and 6 bits are padded
* index 0: Y plane, [15:0] Y:x [10:6] little endian
@@ -854,6 +861,10 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
* and UV. Some SAND-using hardware stores UV in a separate tiled
* image from Y to reduce the column height, which is not supported
* with these modifiers.
+ *
+ * The DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT modifier is also
+ * supported for DRM_FORMAT_P030 where the columns remain as 128 bytes
+ * wide, but as this is a 10 bpp format that translates to 96 pixels.
*/
#define DRM_FORMAT_MOD_BROADCOM_SAND32_COL_HEIGHT(v) \
--
2.33.1
[PATCH v3 0/3] drm/vc4: Support for 30 bits YUV formats
Hi, Here are a few patches adding support for the P030 and the BT709 and BT2020 colorspaces. Let me know what you think, Maxime Changes from v2: - Fixed Dave email address - Fixed a typo in the first patch commit log Changes from v1: - Reworded the format description - Fixed use before initialisation Dave Stevenson (3): drm/fourcc: Add packed 10bit YUV 4:2:0 format drm/vc4: plane: Add support for DRM_FORMAT_P030 drm/vc4: plane: Add support for YUV color encodings and ranges drivers/gpu/drm/drm_fourcc.c| 3 + drivers/gpu/drm/vc4/vc4_plane.c | 199 ++-- drivers/gpu/drm/vc4/vc4_regs.h | 19 ++- include/uapi/drm/drm_fourcc.h | 11 ++ 4 files changed, 193 insertions(+), 39 deletions(-) -- 2.33.1
Re: [PATCH v6 7/7] drm/mediatek: Add mt8195 DisplayPort driver
On Thu, Dec 02, 2021 at 06:48:12AM -0800, Guillaume Ranquet wrote: > Hi, > > Quoting Maxime Ripard (2021-11-25 15:30:34) > > On Wed, Nov 24, 2021 at 01:45:21PM +, Guillaume Ranquet wrote: > > > Hi, > > > Thanks for all your input, really appreciated. > > > > > > Quoting Maxime Ripard (2021-11-16 15:51:12) > > > > Hi, > > > > > > > > On Mon, Nov 15, 2021 at 09:33:52AM -0500, Guillaume Ranquet wrote: > > > > > Quoting Maxime Ripard (2021-11-15 11:11:29) > > > > > > > The driver creates a child device for the phy. The child device > > > > > > > will > > > > > > > never exist without the parent being active. As they are sharing a > > > > > > > register range, the parent passes a regmap pointer to the child > > > > > > > so that > > > > > > > both can work with the same register range. The phy driver sets > > > > > > > device > > > > > > > data that is read by the parent to get the phy device that can be > > > > > > > used > > > > > > > to control the phy properties. > > > > > > > > > > > > If the PHY is in the same register space than the DP controller, > > > > > > why do > > > > > > you need a separate PHY driver in the first place? > > > > > > > > > > This has been asked by Chun-Kuang Hu in a previous revision of the > > > > > series: > > > > > > > > > > https://lore.kernel.org/linux-mediatek/CAAOTY_-+T-wRCH2yw2XSm=zbabbqbq4eqpu2p0tf90gawqe...@mail.gmail.com/ > > > > > > > > It's a bit of a circular argument though :) > > > > > > > > It's a separate phy driver because it needs to go through another > > > > maintainer's tree, but it needs to go through another maintainer's tree > > > > because it's a separate phy driver. > > > > > > > > It doesn't explain why it needs to be a separate phy driver? Why can't > > > > the phy setup be done directly in the DP driver, if it's essentially a > > > > single device? > > > > > > > > That being said, usually what those kind of questions mean is that > > > > you're missing a comment or something in the commit log to provide that > > > > context in the first place, so it would be great to add that context > > > > here. > > > > > > > > And it will avoid the situation we're now in where multiple reviewers > > > > ask the same questions over and over again :) > > > > > > > At first I didn't understand your reply, then I realized I gave you > > > the wrong link... > > > my bad! I'm struggling a bit with mail reviews, but I'll get there > > > eventually. > > > > > > The driver and phy were a single driver until v2 of this patch series > > > and the phy setup > > > was done directly in the driver (single driver, single C file). > > > Here's the relevant link to the discussion between Chun-Kuang and Markus > > > > > > https://lore.kernel.org/linux-mediatek/caaoty__cjmqcaieeraj2sz4gi0zs-ainxz38_x7dpqea6hv...@mail.gmail.com/#t > > > > > > I'll try to find a way to make it clearer for v7. > > > > OK, it makes sense then :) > > > > There's something weird though: the devices definitely look like they're > > in a separate register range, yet you mention a regmap to handle the > > shared register range. That range doesn't seem described anywhere in the > > device tree though? What is it for? > > My understanding is that 0x1000 to 0x1fff controls the phy > functionalities and 0x2000 to 0x4fff controls "non-phy" > functionalities. And you are right, there's no description of that in > the device tree whatsoever. The ranges are in the same actual device > and thus it has been decided to not have dt-bindings for the phy > device. Sure, that last part makes sense, but then I'm not sure why you don't have the full register range in the device node you have in the DT? > The phy driver is a child of the DP driver that we register using > platform_device_register_data() and we pass along the same regmap as > the DP driver in its platform data. Especially if it's used by something, it should be described in the DT somewhere. Maxime signature.asc Description: PGP signature
Re: [PATCH v3 1/3] dt-bindings: gpu: mali-bifrost: Document RZ/G2L support
On 08/12/2021 10:40, Biju Das wrote:
> The Renesas RZ/G2{L, LC} SoC (a.k.a R9A07G044) has a Bifrost Mali-G31 GPU,
> add a compatible string for it.
>
> Signed-off-by: Biju Das
> Reviewed-by: Lad Prabhakar
> ---
> v2->v3:
> * Moved optional clock-names and reset-names to SoC-specific conditional
> schemas.
> * minimum number of reset for the generic GPU is set to 1.
> * Documented number of clocks, resets, interrupts and interrupt-names in
> RZ/G2L
>SoC-specific conditional schemas.
> v1->v2:
> * Updated minItems for resets as 2
> * Documented optional property reset-names
> * Documented reset-names as required property for RZ/G2L SoC.
> ---
> .../bindings/gpu/arm,mali-bifrost.yaml| 45 ++-
> 1 file changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> index 6f98dd55fb4c..63a08f3f321d 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> @@ -19,6 +19,7 @@ properties:
>- amlogic,meson-g12a-mali
>- mediatek,mt8183-mali
>- realtek,rtd1619-mali
> + - renesas,r9a07g044-mali
>- rockchip,px30-mali
>- rockchip,rk3568-mali
>- const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully
> discoverable
> @@ -27,19 +28,26 @@ properties:
> maxItems: 1
>
>interrupts:
> +minItems: 3
> items:
>- description: Job interrupt
>- description: MMU interrupt
>- description: GPU interrupt
> + - description: Event interrupt
>
>interrupt-names:
> +minItems: 3
> items:
>- const: job
>- const: mmu
>- const: gpu
> + - const: event
FWIW: I think it's fair to add the "event" interrupt even if it isn't
included in the bindings for kbase. While pretty much useless on Bifrost
it is a hardware feature and in theory it could be used.
Reviewed-by: Steven Price
Steve
>
>clocks:
> -maxItems: 1
> +minItems: 1
> +maxItems: 3
> +
> + clock-names: true
>
>mali-supply: true
>
> @@ -52,7 +60,10 @@ properties:
> maxItems: 3
>
>resets:
> -maxItems: 2
> +minItems: 1
> +maxItems: 3
> +
> + reset-names: true
>
>"#cooling-cells":
> const: 2
> @@ -94,6 +105,36 @@ allOf:
> then:
>required:
> - resets
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: renesas,r9a07g044-mali
> +then:
> + properties:
> +interrupts:
> + minItems: 4
> +interrupt-names:
> + minItems: 4
> +clocks:
> + minItems: 3
> +clock-names:
> + items:
> +- const: gpu
> +- const: bus
> +- const: bus_ace
> +resets:
> + minItems: 3
> +reset-names:
> + items:
> +- const: rst
> +- const: axi_rst
> +- const: ace_rst
> + required:
> +- clock-names
> +- power-domains
> +- resets
> +- reset-names
>- if:
>properties:
> compatible:
>
[PATCH RESEND v4 v4 4/4] drm/vc4: Notify the firmware when DRM is in charge
Once the call to drm_fb_helper_remove_conflicting_framebuffers() has
been made, simplefb has been unregistered and the KMS driver is entirely
in charge of the display.
Thus, we can notify the firmware it can free whatever resource it was
using to maintain simplefb functional.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index c0d7e510694f..e4bb37a191f6 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -37,6 +37,8 @@
#include
#include
+#include
+
#include "uapi/drm/vc4_drm.h"
#include "vc4_drv.h"
@@ -215,6 +217,7 @@ static void vc4_match_add_drivers(struct device *dev,
static int vc4_drm_bind(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
+ struct rpi_firmware *firmware = NULL;
struct drm_device *drm;
struct vc4_dev *vc4;
struct device_node *node;
@@ -251,10 +254,29 @@ static int vc4_drm_bind(struct device *dev)
if (ret)
return ret;
+ node = of_find_compatible_node(NULL, NULL,
"raspberrypi,bcm2835-firmware");
+ if (node) {
+ firmware = rpi_firmware_get(node);
+ of_node_put(node);
+
+ if (!firmware)
+ return -EPROBE_DEFER;
+ }
+
ret = drm_aperture_remove_framebuffers(false, _drm_driver);
if (ret)
return ret;
+ if (firmware) {
+ ret = rpi_firmware_property(firmware,
+ RPI_FIRMWARE_NOTIFY_DISPLAY_DONE,
+ NULL, 0);
+ if (ret)
+ drm_warn(drm, "Couldn't stop firmware display driver:
%d\n", ret);
+
+ rpi_firmware_put(firmware);
+ }
+
ret = component_bind_all(dev, drm);
if (ret)
return ret;
--
2.33.1
[PATCH RESEND v4 v4 3/4] drm/vc4: Remove conflicting framebuffers before callind bind_all
The bind hooks will modify their controller registers, so simplefb is going to be unusable anyway. Let's avoid any transient state where it could still be in the system but no longer functionnal. Acked-by: Nicolas Saenz Julienne Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_drv.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 12694e2201e7..c0d7e510694f 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -251,6 +251,10 @@ static int vc4_drm_bind(struct device *dev) if (ret) return ret; + ret = drm_aperture_remove_framebuffers(false, _drm_driver); + if (ret) + return ret; + ret = component_bind_all(dev, drm); if (ret) return ret; @@ -259,10 +263,6 @@ static int vc4_drm_bind(struct device *dev) if (ret) goto unbind_all; - ret = drm_aperture_remove_framebuffers(false, _drm_driver); - if (ret) - goto unbind_all; - ret = vc4_kms_load(drm); if (ret < 0) goto unbind_all; -- 2.33.1
[PATCH RESEND v4 v4 2/4] drm/vc4: Support nomodeset
If we have nomodeset on the kernel command line we should have the
firmware framebuffer driver kept as is and not try to load the
full-blown KMS driver.
In this case, let's just register the v3d driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 16abc3a3d601..12694e2201e7 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -357,12 +357,22 @@ static int __init vc4_drm_register(void)
{
int ret;
- ret = platform_register_drivers(component_drivers,
- ARRAY_SIZE(component_drivers));
- if (ret)
- return ret;
+ if (!drm_firmware_drivers_only()) {
+ ret = platform_register_drivers(component_drivers,
+ ARRAY_SIZE(component_drivers));
+ if (ret)
+ return ret;
- return platform_driver_register(_platform_driver);
+ ret = platform_driver_register(_platform_driver);
+ if (ret)
+ return ret;
+ } else {
+ ret = platform_driver_register(_v3d_driver);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
}
static void __exit vc4_drm_unregister(void)
--
2.33.1
[PATCH RESEND v4 v4 1/4] firmware: raspberrypi: Add RPI_FIRMWARE_NOTIFY_DISPLAY_DONE
The RPI_FIRMWARE_NOTIFY_DISPLAY_DONE firmware call allows to tell the
firmware the kernel is in charge of the display now and the firmware can
free whatever resources it was using.
Acked-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
include/soc/bcm2835/raspberrypi-firmware.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h
b/include/soc/bcm2835/raspberrypi-firmware.h
index 73ad784fca96..811ea668c4a1 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -91,6 +91,7 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_GET_POE_HAT_VAL =0x00030049,
RPI_FIRMWARE_SET_POE_HAT_VAL =0x00030050,
RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
+ RPI_FIRMWARE_NOTIFY_DISPLAY_DONE =0x00030066,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
--
2.33.1
[PATCH RESEND v4 v4 0/4] drm/vc4: Use the firmware to stop the display pipeline
Hi, The VC4 driver has had limited support to disable the HDMI controllers and pixelvalves at boot if the firmware has enabled them. However, this proved to be limited, and a bit unreliable so a new firmware command has been introduced some time ago to make it free all its resources and disable any display output it might have enabled. This series takes advantage of that command to call it once the transition from simplefb to the KMS driver has been done. Let me know what you think, Maxime --- Changes from v3: - Support nomodeset Changes from v2: - Switch back to rpi_firmware_get / rpi_firmware_put - Moved the rpi_firmware pointer to a local variable Changes from v1: - Use of_find_compatible_node instead of a phandle - Use devm_rpi_firmware_get Maxime Ripard (4): firmware: raspberrypi: Add RPI_FIRMWARE_NOTIFY_DISPLAY_DONE drm/vc4: Support nomodeset drm/vc4: Remove conflicting framebuffers before callind bind_all drm/vc4: Notify the firmware when DRM is in charge drivers/gpu/drm/vc4/vc4_drv.c | 50 ++ include/soc/bcm2835/raspberrypi-firmware.h | 1 + 2 files changed, 42 insertions(+), 9 deletions(-) -- 2.33.1
[PATCH v4 0001/1584] dt-bindings: gpio: gpio-vf610: Add imx8ulp compatible string
From: Jacky Bai Add the compatible string for i.MX8ULP. Reviewed-by: Linus Walleij Reviewed-by: Dong Aisheng Acked-by: Rob Herring Signed-off-by: Jacky Bai Signed-off-by: Peng Fan Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/gpio/gpio-vf610.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml index 19738a457a58..e1359391d3a4 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml @@ -24,6 +24,9 @@ properties: - items: - const: fsl,imx7ulp-gpio - const: fsl,vf610-gpio + - items: + - const: fsl,imx8ulp-gpio + - const: fsl,imx7ulp-gpio reg: description: The first reg tuple represents the PORT module, the second tuple -- 2.33.1
Re: [PATCH v4 0000/1584] drm/vc4: Use the firmware to stop the display pipeline
On Mon, Dec 13, 2021 at 04:58:13PM +0100, Maxime Ripard wrote: > Hi, > > The VC4 driver has had limited support to disable the HDMI controllers and > pixelvalves at boot if the firmware has enabled them. > > However, this proved to be limited, and a bit unreliable so a new firmware > command has been introduced some time ago to make it free all its resources > and > disable any display output it might have enabled. > > This series takes advantage of that command to call it once the transition > from > simplefb to the KMS driver has been done. > > Let me know what you think, > Maxime That was obviously an error on my end, I'll resend it, sorry Maxime signature.asc Description: PGP signature
[PATCH v4 0000/1584] drm/vc4: Use the firmware to stop the display pipeline
Hi, The VC4 driver has had limited support to disable the HDMI controllers and pixelvalves at boot if the firmware has enabled them. However, this proved to be limited, and a bit unreliable so a new firmware command has been introduced some time ago to make it free all its resources and disable any display output it might have enabled. This series takes advantage of that command to call it once the transition from simplefb to the KMS driver has been done. Let me know what you think, Maxime --- Changes from v3: - Support nomodeset Changes from v2: - Switch back to rpi_firmware_get / rpi_firmware_put - Moved the rpi_firmware pointer to a local variable Changes from v1: - Use of_find_compatible_node instead of a phandle - Use devm_rpi_firmware_get Abdun Nihaal (1): staging: r8188eu: Fix coding style error Abhyuday Godhasara (3): drivers: soc: xilinx: add xilinx event management driver firmware: xilinx: instantiate xilinx event manager driver driver: soc: xilinx: register for power events in zynqmp power driver Aditya Garg (2): Bluetooth: add quirk disabling LE Read Transmit Power Bluetooth: btbcm: disable read tx power for some Macs with the T2 Security chip Adrian Hunter (1): perf inject: Fix itrace space allowed for new attributes Ajith P V (1): binder: remove repeat word from comment Akira Yokosawa (1): media: docs: media: Fix imbalance of LaTeX group Al Cooper (1): serial: 8250_bcm7271: UART errors after resuming from S2 Alan Young (1): ALSA: ctl: Fix copy of updated id with element read/write Alberto Merciai (1): staging: vt6655: refactor camelcase uCurrRSSI to current_rssi Alex Deucher (8): drm/amdgpu: handle SRIOV VCN revision parsing drm/amdgpu: add another raven1 gfxoff quirk drm/amdgpu: only check for _PR3 on dGPUs drm/amdgpu/swsmu/vgh: rename MSG_RlcPowerNotify Revert "amd/amdgpu: Disable VCN DPG mode for Picasso" Revert "drm/amd/display: To modify the condition in indicating branch device" drm/amdgpu/UAPI: add new PROFILE IOCTL drm/amdgpu: bump driver version for PROFILE IOCTL Alex Hung (1): platform/x86/intel: hid: add quirk to support Surface Go 3 Alexander Aring (7): fs: dlm: use list_empty() to check last iteration fs: dlm: check for pending users filling buffers fs: dlm: use event based wait for pending remove fs: dlm: remove wq_alloc mutex fs: dlm: memory cache for midcomms hotpath fs: dlm: memory cache for writequeue_entry fs: dlm: memory cache for lowcomms hotpath Alexander Lobakin (2): samples: bpf: Fix xdp_sample_user.o linking with Clang samples: bpf: Fix 'unknown warning group' build warning on Clang Alexander Potapenko (1): compiler_attributes.h: Add __disable_sanitizer_instrumentation Alexander Stein (1): dt-bindings: net: Reintroduce PHY no lane swap binding Alexandre Belloni (1): rtc: da9063: switch to RTC_FEATURE_UPDATE_INTERRUPT Alexei Starovoitov (19): libbpf: Replace btf__type_by_id() with btf_type_by_id(). bpf: Rename btf_member accessors. bpf: Prepare relo_core.c for kernel duty. bpf: Define enum bpf_core_relo_kind as uapi. bpf: Pass a set of bpf_core_relo-s to prog_load command. bpf: Adjust BTF log size limit. bpf: Add bpf_core_add_cands() and wire it into bpf_core_apply_relo_insn(). libbpf: Use CO-RE in the kernel in light skeleton. libbpf: Support init of inner maps in light skeleton. libbpf: Clean gen_loader's attach kind. selftests/bpf: Add lskel version of kfunc test. selftests/bpf: Improve inner_map test coverage. selftests/bpf: Convert map_ptr_kern test to use light skeleton. selftests/bpf: Additional test for CO-RE in the kernel. selftests/bpf: Revert CO-RE removal in test_ksyms_weak. selftests/bpf: Add CO-RE relocations to verifier scale test. libbpf: Reduce bpf_core_apply_relo_insn() stack usage. bpftool: Add debug mode for gen_loader. bpf: Silence purge_cand_cache build warning. Alexey Dobriyan (2): kstrtox: uninline everything ELF: fix overflow in total mapping size calculation Alexey Makhalov (1): mm: fix panic in __alloc_pages Alistair Popple (2): mm/migrate.c: rework migration_entry_wait() to not take a pageref mm/hmm.c: Allow VM_MIXEDMAP to work with hmm_range_fault Alyssa Ross (1): iio: trigger: stm32-timer: fix MODULE_ALIAS Ameer Hamza (1): ASoC: test-component: fix null pointer dereference. Amit Daniel Kachhap (1): fs/ioctl: remove unnecessary __user annotation Anders Roxell (2): selftests: cgroup: build error multiple outpt files ALSA: ppc: beep: fix clang -Wimplicit-fallthrough Andreas Gruenbacher (7): gfs2: Fix remote demote of weak glock holders gfs2: gfs2_inode_lookup cleanup gfs2: gfs2_inode_lookup rework gfs2: gfs2_create_inode rework gfs2: Fix __gfs2_holder_init function name in kernel-doc comment gfs2: Remove redundant check for GLF_INSTANTIATE_NEEDED gfs2: Fix gfs2_instantiate description Andreas Oetken (1): mtd: Fixed breaking list in
Re: [PATCH RESEND v7 12/12] drm/i915: Move the GGTT from i915 private data to the GT
Hi Andi,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on drm/drm-next]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next v5.16-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/More-preparation-for-multi-gt-patches/20211212-232416
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a003-20211213
(https://download.01.org/0day-ci/archive/20211213/202112132358.iwecweww-...@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
b6a2ddb6c8ac29412b1361810972e15221fa021c)
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
#
https://github.com/0day-ci/linux/commit/98ef49d710790dda7a193c10b5b7f28516f730bc
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Andi-Shyti/More-preparation-for-multi-gt-patches/20211212-232416
git checkout 98ef49d710790dda7a193c10b5b7f28516f730bc
# 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
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gvt/gtt.c:321:25: error: passing 'struct i915_ggtt' to
>> parameter of incompatible type 'struct i915_ggtt *'; take the address with &
e->val64 = read_pte64(vgpu->gvt->gt->ggtt, index);
^~~
&
drivers/gpu/drm/i915/gvt/gtt.c:282:41: note: passing argument to parameter
'ggtt' here
static u64 read_pte64(struct i915_ggtt *ggtt, unsigned long index)
^
drivers/gpu/drm/i915/gvt/gtt.c:346:15: error: passing 'struct i915_ggtt' to
parameter of incompatible type 'struct i915_ggtt *'; take the address with &
write_pte64(vgpu->gvt->gt->ggtt, index, e->val64);
^~~
&
drivers/gpu/drm/i915/gvt/gtt.c:296:43: note: passing argument to parameter
'ggtt' here
static void write_pte64(struct i915_ggtt *ggtt, unsigned long index, u64 pte)
^
drivers/gpu/drm/i915/gvt/gtt.c:2900:17: error: passing 'struct i915_ggtt' to
parameter of incompatible type 'struct i915_ggtt *'; take the address with &
write_pte64(vgpu->gvt->gt->ggtt, offset +
idx, pte);
^~~
&
drivers/gpu/drm/i915/gvt/gtt.c:296:43: note: passing argument to parameter
'ggtt' here
static void write_pte64(struct i915_ggtt *ggtt, unsigned long index, u64 pte)
^
drivers/gpu/drm/i915/gvt/gtt.c:2908:17: error: passing 'struct i915_ggtt' to
parameter of incompatible type 'struct i915_ggtt *'; take the address with &
write_pte64(vgpu->gvt->gt->ggtt, offset +
idx, pte);
^~~
&
drivers/gpu/drm/i915/gvt/gtt.c:296:43: note: passing argument to parameter
'ggtt' here
static void write_pte64(struct i915_ggtt *ggtt, unsigned long index, u64 pte)
^
4 errors generated.
vim +321 drivers/gpu/drm/i915/gvt/gtt.c
2707e44466881d Zhi Wang 2016-03-28 302
4b2dbbc22541e4 Changbin Du 2017-08-02 303 static inline int
gtt_get_entry64(void *pt,
2707e44466881d Zhi Wang 2016-03-28 304 struct
intel_gvt_gtt_entry *e,
2707e44466881d Zhi Wang 2016-03-28 305 unsigned long index,
bool hypervisor_access, unsigned long gpa,
2707e44466881d Zhi Wang 2016-03-28 306 struct intel_vgpu *vgpu)
2707e44466881d Zhi Wang 2016-03-28 307 {
2707e44466881d Zhi Wang 2016-03-28 308 const struct
intel_gvt_device_info *info = >gvt->device_info;
2707e44466881d Zhi Wang 2016-03-28 309 int ret;
2707e44466881d Zhi Wang 2016-03-28 310
2707e44466881d Zhi Wang 2016-03-28 311 if
(WARN_ON(info->gtt_entry_size != 8))
4b2dbbc22541e4 Changbin Du 2017-08-02 312 return -EINVAL;
2707e44466881d Zhi Wang 2016-03-28 313
2707e44466881d Zhi Wang 201
[PATCH v2] drm/mediatek: Set the default value of rotation to DRM_MODE_ROTATE_0
At the reset hook, call __drm_atomic_helper_plane_reset which is
called at the initialization of the plane and sets the default value of
rotation on all planes to DRM_MODE_ROTATE_0 which is equal to 1.
Tested on Jacuzzi (MTK).
Resolves IGT@kms_properties@plane-properties-{legacy,atomic}
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index e6dcb34d30522..accd26481b9fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -44,9 +44,10 @@ static void mtk_plane_reset(struct drm_plane *plane)
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (!state)
return;
- plane->state = >base;
}
+ __drm_atomic_helper_plane_reset(plane, >base);
+
state->base.plane = plane;
state->pending.format = DRM_FORMAT_RGB565;
}
--
2.34.1.173.g76aa8bc2d0-goog
Re: [PATCH 1/7] drm/i915: Replace kmap() with kmap_local_page()
On Mon, Dec 13, 2021 at 01:04:07AM -0800, Christoph Hellwig wrote: > On Fri, Dec 10, 2021 at 03:23:58PM -0800, ira.we...@intel.com wrote: > > - vaddr = kmap(page); > > + vaddr = kmap_local_page(page); > > memcpy(vaddr, data, len); > > - kunmap(page); > > + kunmap_local(vaddr); > > memcpy_to_page? Opps! Yea! David, Daniel, Do you prefer me to resent the entire series or reply to this message with a V2? Ira
Re: [PATCH 1/7] drm/i915: Replace kmap() with kmap_local_page()
On Mon, Dec 13, 2021 at 02:39:59PM +0200, Ville Syrjälä wrote:
> On Fri, Dec 10, 2021 at 03:23:58PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > kmap() is being deprecated and these usages are all local to the thread
> > so there is no reason kmap_local_page() can't be used.
> >
> > Replace kmap() calls with kmap_local_page().
> >
> > Signed-off-by: Ira Weiny
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 ++--
> > drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8
> > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--
> > drivers/gpu/drm/i915/gt/shmem_utils.c | 4 ++--
> > drivers/gpu/drm/i915/i915_gem.c| 8
> > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++--
> > 6 files changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > index d77da59fae04..fa8b820e14aa 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > @@ -597,9 +597,9 @@ i915_gem_object_create_shmem_from_data(struct
> > drm_i915_private *dev_priv,
> > if (err < 0)
> > goto fail;
> >
> > - vaddr = kmap(page);
> > + vaddr = kmap_local_page(page);
> > memcpy(vaddr, data, len);
> > - kunmap(page);
> > + kunmap_local(vaddr);
> >
> > err = pagecache_write_end(file, file->f_mapping,
> > offset, len, len,
> > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > index 6d30cdfa80f3..e59e1725e29d 100644
> > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > @@ -144,7 +144,7 @@ static int check_partial_mapping(struct
> > drm_i915_gem_object *obj,
> > intel_gt_flush_ggtt_writes(_i915(obj->base.dev)->gt);
> >
> > p = i915_gem_object_get_page(obj, offset >> PAGE_SHIFT);
> > - cpu = kmap(p) + offset_in_page(offset);
> > + cpu = kmap_local_page(p) + offset_in_page(offset);
>
> Does kunmap_local() do some magic to make it work even when you
> don't pass in the same value you got from kmap_local_page()?
Yes. It sounds like a patch like this would be nice to clarify?
Ira
diff --git a/include/linux/highmem-internal.h b/include/linux/highmem-internal.h
index 0a0b2b09b1b8..fb2d3e033c01 100644
--- a/include/linux/highmem-internal.h
+++ b/include/linux/highmem-internal.h
@@ -246,6 +246,17 @@ do {
\
__kunmap_atomic(__addr);\
} while (0)
+/**
+ * kunmap_local - Unmap a page mapped via kmap_local_page().
+ * @__addr: An address within the page mapped
+ *
+ * __addr is often an address returned from kmap_local_page(). However,
+ * this address can be any address within the mapped page. It does not need to
+ * be the exact address returned from kmap_local_page()
+ *
+ * Unmapping should be done in the reverse order of the mapping. See
+ * kmap_local_page() for details.
+ */
#define kunmap_local(__addr) \
do { \
BUILD_BUG_ON(__same_type((__addr), struct page *)); \
Re: [PATCH v3 5/8] drm/i915/gtt: allow overriding the pt alignment
On 2021-12-06 at 13:31:37 +, Matthew Auld wrote:
> On some platforms we have alignment restrictions when accessing LMEM
> from the GTT. In the next patch few patches we need to be able to modify
probably extra "patch"
Apart from that looks good to me
Reviewed-by : Ramalingam C
> the page-tables directly via the GTT itself.
>
> Suggested-by: Ramalingam C
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> Cc: Ramalingam C
> ---
> drivers/gpu/drm/i915/gt/intel_gtt.h | 10 +-
> drivers/gpu/drm/i915/gt/intel_ppgtt.c | 16
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index cbc0b5266cb4..a00d278d8175 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -196,6 +196,14 @@ void *__px_vaddr(struct drm_i915_gem_object *p);
> struct i915_vm_pt_stash {
> /* preallocated chains of page tables/directories */
> struct i915_page_table *pt[2];
> + /*
> + * Optionally override the alignment/size of the physical page that
> + * contains each PT. If not set defaults back to the usual
> + * I915_GTT_PAGE_SIZE_4K. This does not influence the other paging
> + * structures. MUST be a power-of-two. ONLY applicable on discrete
> + * platforms.
> + */
> + int pt_sz;
> };
>
> struct i915_vma_ops {
> @@ -583,7 +591,7 @@ void free_scratch(struct i915_address_space *vm);
>
> struct drm_i915_gem_object *alloc_pt_dma(struct i915_address_space *vm, int
> sz);
> struct drm_i915_gem_object *alloc_pt_lmem(struct i915_address_space *vm, int
> sz);
> -struct i915_page_table *alloc_pt(struct i915_address_space *vm);
> +struct i915_page_table *alloc_pt(struct i915_address_space *vm, int sz);
> struct i915_page_directory *alloc_pd(struct i915_address_space *vm);
> struct i915_page_directory *__alloc_pd(int npde);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
> b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
> index b8238f5bc8b1..3c90aea25072 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
> @@ -12,7 +12,7 @@
> #include "gen6_ppgtt.h"
> #include "gen8_ppgtt.h"
>
> -struct i915_page_table *alloc_pt(struct i915_address_space *vm)
> +struct i915_page_table *alloc_pt(struct i915_address_space *vm, int sz)
> {
> struct i915_page_table *pt;
>
> @@ -20,7 +20,7 @@ struct i915_page_table *alloc_pt(struct i915_address_space
> *vm)
> if (unlikely(!pt))
> return ERR_PTR(-ENOMEM);
>
> - pt->base = vm->alloc_pt_dma(vm, I915_GTT_PAGE_SIZE_4K);
> + pt->base = vm->alloc_pt_dma(vm, sz);
> if (IS_ERR(pt->base)) {
> kfree(pt);
> return ERR_PTR(-ENOMEM);
> @@ -219,17 +219,25 @@ int i915_vm_alloc_pt_stash(struct i915_address_space
> *vm,
> u64 size)
> {
> unsigned long count;
> - int shift, n;
> + int shift, n, pt_sz;
>
> shift = vm->pd_shift;
> if (!shift)
> return 0;
>
> + pt_sz = stash->pt_sz;
> + if (!pt_sz)
> + pt_sz = I915_GTT_PAGE_SIZE_4K;
> + else
> + GEM_BUG_ON(!IS_DGFX(vm->i915));
> +
> + GEM_BUG_ON(!is_power_of_2(pt_sz));
> +
> count = pd_count(size, shift);
> while (count--) {
> struct i915_page_table *pt;
>
> - pt = alloc_pt(vm);
> + pt = alloc_pt(vm, pt_sz);
> if (IS_ERR(pt)) {
> i915_vm_free_pt_stash(vm, stash);
> return PTR_ERR(pt);
> --
> 2.31.1
>
RE: [PATCH] drm/edid: Refine HDMI VSDB detect
On Monday, December 13, 2021 at 02:36 p.m, Ville Syrjälä wrote: >On Mon, Dec 13, 2021 at 02:09:33PM +, Lee, Shawn C wrote: >> >> On Monday, December 13, 2021 at 12:45 p.m, Ville Syrjälä wrote: >> >On Mon, Dec 13, 2021 at 12:42:22PM +, Lee, Shawn C wrote: >> >> >> >> On Monday, December 13, 2021 8:31 PM, Ville Syrjälä wrote: >> >> >On Sun, Dec 12, 2021 at 11:33:31PM +0800, Lee Shawn C wrote: >> >> >> According to CEA-861-F chapter 7.5.4. It says "The VSDB shall contain >> >> >> the >> >> >> 3 bytes of the IEEE OUI as well as any additional payload bytes >> >> >> needed." >> >> >> Now DRM driver check HDMI OUI but VSDB payload size at least five >> >> >> bytes. >> >> >> That may caused some HDMI monitors' audio feature can't be enabled. >> >> >> Because of they only have three bytes payload (OUI only) in VSDB. >> >> > >> >> >HDMI 1.4a says >> >> >"Sinks shall contain an HDMI VSDB minimally containing a 2-byte Source >> >> >Physical Address field following the 24-bit identifier. ... >> >> > The minimum value of N (length) is 5 and the maximum value of N is 31." >> >> > >> >> >Do you actually have an EDID that violates that? >> >> > >> >> >> >> Yes! User report when connect to HDMI port on Acer V226HQL. Audio is not >> >> working. >> >> But windows system did not have the same problem. We found its VSDB just >> >> have 3 bytes >> >> payload (OUI). Then we share this patch to user then they report audio >> >> works properly >> >> with this patch. >> > >> >Hrm. This deserves a comment then since it clearly violates the spec. >> >Also a link to the bug if you have one would be nice to include here. >> > >> >> Let me create an issue and update monitor's EDID for you reference. >> But I'm not sure which community is suitable to report this problem. >> It looks to me should belong to DRM driver >> https://gitlab.freedesktop.org/drm/misc/-/issues. > >That seems fine to me. > Here is the link, thanks! https://gitlab.freedesktop.org/drm/misc/-/issues/28 >> Do you have any suggestion? Thanks! >> >> >> >> >> Best regards, >> >> Shawn >> >> >> >> >> >> >> >> Cc: Ville Syrjälä >> >> >> Cc: Adam Jackson >> >> >> Cc: Dave Airlie >> >> >> Signed-off-by: Lee Shawn C >> >> >> --- >> >> >> drivers/gpu/drm/drm_edid.c | 2 +- >> >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c >> >> >> index 12893e7be89b..5aa4a6bf4a13 100644 >> >> >> --- a/drivers/gpu/drm/drm_edid.c >> >> >> +++ b/drivers/gpu/drm/drm_edid.c >> >> >> @@ -4205,7 +4205,7 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db) >> >> >>if (cea_db_tag(db) != VENDOR_BLOCK) >> >> >>return false; >> >> >> >> >> >> - if (cea_db_payload_len(db) < 5) >> >> >> + if (cea_db_payload_len(db) < 3) >> >> >>return false; >> >> >> >> >> >>return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI; >> >> >> -- >> >> >> 2.31.1 >> >> > >> >> >-- >> >> >Ville Syrjälä >> >> >Intel >> >> > >
Re: [PATCH v3 1/3] of: Move simple-framebuffer device handling from simplefb to of
On Mon, Dec 13, 2021 at 2:16 AM Thomas Zimmermann wrote: > > Hi > > Am 12.12.21 um 22:29 schrieb Rob Herring: > > On Sun, Dec 12, 2021 at 12:24 AM Hector Martin wrote: > >> > >> This code is required for both simplefb and simpledrm, so let's move it > >> into the OF core instead of having it as an ad-hoc initcall in the > >> drivers. > >> > >> Acked-by: Thomas Zimmermann > >> Signed-off-by: Hector Martin > >> --- > >> drivers/of/platform.c | 4 > >> drivers/video/fbdev/simplefb.c | 21 + > >> 2 files changed, 5 insertions(+), 20 deletions(-) > > > > Reviewed-by: Rob Herring > > > > Can I merge this patch through DRM trees? Yes. Rob
Re: [PATCH v3 1/3] of: Move simple-framebuffer device handling from simplefb to of
On Mon, Dec 13, 2021 at 5:30 AM Javier Martinez Canillas wrote: > > On Mon, Dec 13, 2021 at 11:46 AM Hector Martin wrote: > > > > On 13/12/2021 17.44, Javier Martinez Canillas wrote: > > > Hello Hector, > > > > > > On Sun, Dec 12, 2021 at 7:24 AM Hector Martin wrote: > > >> > > >> This code is required for both simplefb and simpledrm, so let's move it > > >> into the OF core instead of having it as an ad-hoc initcall in the > > >> drivers. > > >> > > >> Acked-by: Thomas Zimmermann > > >> Signed-off-by: Hector Martin > > >> --- > > >> drivers/of/platform.c | 4 > > >> drivers/video/fbdev/simplefb.c | 21 + > > >> 2 files changed, 5 insertions(+), 20 deletions(-) > > >> > > > > > > This is indeed a much better approach than what I suggested. I just > > > have one comment. > > > > > >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c > > >> index b3faf89744aa..793350028906 100644 > > >> --- a/drivers/of/platform.c > > >> +++ b/drivers/of/platform.c > > >> @@ -540,6 +540,10 @@ static int __init > > >> of_platform_default_populate_init(void) > > >> of_node_put(node); > > >> } > > >> > > >> + node = of_get_compatible_child(of_chosen, "simple-framebuffer"); > > > > > > You have to check if the node variable is NULL here. > > > > > >> + of_platform_device_create(node, NULL, NULL); > > > > > > Otherwise this could lead to a NULL pointer dereference if debug > > > output is enabled (the node->full_name is printed). > > > > Where is it printed? I thought I might need a NULL check, but this code > > Sorry, I misread of_amba_device_create() as > of_platform_device_create(), which uses the "%pOF" printk format > specifier [0] to print the node's full name as a debug output [1]. > > [0]: > https://elixir.bootlin.com/linux/v5.16-rc5/source/Documentation/core-api/printk-formats.rst#L462 > [1]: > https://elixir.bootlin.com/linux/v5.16-rc5/source/drivers/of/platform.c#L233 > > > was suggested verbatim by Rob in v2 without the NULL check and digging > > through I found that the NULL codepath is safe. > > > > You are right that passing NULL is a safe code path for now due the > of_device_is_available(node) check, but that seems fragile to me since > just adding a similar debug output to of_platform_device_create() > could trigger the NULL pointer dereference. All/most DT functions work with a NULL node ptr, so why should this one be different? Rob
Re: [PATCH] drm/edid: Refine HDMI VSDB detect
On Mon, Dec 13, 2021 at 02:09:33PM +, Lee, Shawn C wrote: > > On Monday, December 13, 2021 at 12:45 p.m, Ville Syrjälä wrote: > >On Mon, Dec 13, 2021 at 12:42:22PM +, Lee, Shawn C wrote: > >> > >> On Monday, December 13, 2021 8:31 PM, Ville Syrjälä wrote: > >> >On Sun, Dec 12, 2021 at 11:33:31PM +0800, Lee Shawn C wrote: > >> >> According to CEA-861-F chapter 7.5.4. It says "The VSDB shall contain > >> >> the > >> >> 3 bytes of the IEEE OUI as well as any additional payload bytes needed." > >> >> Now DRM driver check HDMI OUI but VSDB payload size at least five bytes. > >> >> That may caused some HDMI monitors' audio feature can't be enabled. > >> >> Because of they only have three bytes payload (OUI only) in VSDB. > >> > > >> >HDMI 1.4a says > >> >"Sinks shall contain an HDMI VSDB minimally containing a 2-byte Source > >> >Physical Address field following the 24-bit identifier. ... > >> > The minimum value of N (length) is 5 and the maximum value of N is 31." > >> > > >> >Do you actually have an EDID that violates that? > >> > > >> > >> Yes! User report when connect to HDMI port on Acer V226HQL. Audio is not > >> working. > >> But windows system did not have the same problem. We found its VSDB just > >> have 3 bytes > >> payload (OUI). Then we share this patch to user then they report audio > >> works properly > >> with this patch. > > > >Hrm. This deserves a comment then since it clearly violates the spec. > >Also a link to the bug if you have one would be nice to include here. > > > > Let me create an issue and update monitor's EDID for you reference. > But I'm not sure which community is suitable to report this problem. > It looks to me should belong to DRM driver > https://gitlab.freedesktop.org/drm/misc/-/issues. That seems fine to me. > Do you have any suggestion? Thanks! > > >> > >> Best regards, > >> Shawn > >> > >> >> > >> >> Cc: Ville Syrjälä > >> >> Cc: Adam Jackson > >> >> Cc: Dave Airlie > >> >> Signed-off-by: Lee Shawn C > >> >> --- > >> >> drivers/gpu/drm/drm_edid.c | 2 +- > >> >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> >> > >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > >> >> index 12893e7be89b..5aa4a6bf4a13 100644 > >> >> --- a/drivers/gpu/drm/drm_edid.c > >> >> +++ b/drivers/gpu/drm/drm_edid.c > >> >> @@ -4205,7 +4205,7 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db) > >> >> if (cea_db_tag(db) != VENDOR_BLOCK) > >> >> return false; > >> >> > >> >> - if (cea_db_payload_len(db) < 5) > >> >> + if (cea_db_payload_len(db) < 3) > >> >> return false; > >> >> > >> >> return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI; > >> >> -- > >> >> 2.31.1 > >> > > >> >-- > >> >Ville Syrjälä > >> >Intel > >> > -- Ville Syrjälä Intel
Re: [PATCH 1/2] drm/amd/display: Reduce stack size for dml31_ModeSupportAndSystemConfigurationFull
On 2021-12-13 4:46 a.m., Michel Dänzer wrote:
On 2021-12-11 13:20, Rodrigo Siqueira Jordao wrote:
On 2021-12-09 11:46 a.m., Michel Dänzer wrote:
From: Michel Dänzer
Move code using the Pipe struct to a new helper function.
Works around[0] this warning (resulting in failure to build a RHEL debug
kernel with Werror enabled):
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c: In
function ‘dml31_ModeSupportAndSystemConfigurationFull’:
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:5740:1:
warning: the frame size of 2144 bytes is larger than 2048 bytes
[-Wframe-larger-than=]
The culprit seems to be the Pipe struct, so pull the relevant block out
into its own sub-function. (This is porting
a62427ef9b55 "drm/amd/display: Reduce stack size for
dml21_ModeSupportAndSystemConfigurationFull"
from dml31 to dml21)
[0] AFAICT this doesn't actually reduce the total amount of stack which
can be used, just moves some of it from
dml31_ModeSupportAndSystemConfigurationFull to the new helper function,
so the former happens to no longer exceed the limit for a single
function.
Signed-off-by: Michel Dänzer
---
.../dc/dml/dcn31/display_mode_vba_31.c | 185 ++
1 file changed, 99 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
index 7e937bdcea00..8965f9af9d0a 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
@@ -3949,6 +3949,102 @@ static double TruncToValidBPP(
return BPP_INVALID;
}
+static noinline void CalculatePrefetchSchedulePerPlane(
+ struct display_mode_lib *mode_lib,
+ double HostVMInefficiencyFactor,
+ int i,
+ unsigned j,
+ unsigned k)
+{
+ struct vba_vars_st *v = _lib->vba;
+ Pipe myPipe;
+
+ myPipe.DPPCLK = v->RequiredDPPCLK[i][j][k];
+ myPipe.DISPCLK = v->RequiredDISPCLK[i][j];
+ myPipe.PixelClock = v->PixelClock[k];
+ myPipe.DCFCLKDeepSleep = v->ProjectedDCFCLKDeepSleep[i][j];
+ myPipe.DPPPerPlane = v->NoOfDPP[i][j][k];
+ myPipe.ScalerEnabled = v->ScalerEnabled[k];
+ myPipe.SourceScan = v->SourceScan[k];
+ myPipe.BlockWidth256BytesY = v->Read256BlockWidthY[k];
+ myPipe.BlockHeight256BytesY = v->Read256BlockHeightY[k];
+ myPipe.BlockWidth256BytesC = v->Read256BlockWidthC[k];
+ myPipe.BlockHeight256BytesC = v->Read256BlockHeightC[k];
+ myPipe.InterlaceEnable = v->Interlace[k];
+ myPipe.NumberOfCursors = v->NumberOfCursors[k];
+ myPipe.VBlank = v->VTotal[k] - v->VActive[k];
+ myPipe.HTotal = v->HTotal[k];
+ myPipe.DCCEnable = v->DCCEnable[k];
+ myPipe.ODMCombineIsEnabled = v->ODMCombineEnablePerState[i][k] ==
dm_odm_combine_mode_4to1
+ || v->ODMCombineEnablePerState[i][k] == dm_odm_combine_mode_2to1;
+ myPipe.SourcePixelFormat = v->SourcePixelFormat[k];
+ myPipe.BytePerPixelY = v->BytePerPixelY[k];
+ myPipe.BytePerPixelC = v->BytePerPixelC[k];
+ myPipe.ProgressiveToInterlaceUnitInOPP =
v->ProgressiveToInterlaceUnitInOPP;
+ v->NoTimeForPrefetch[i][j][k] = CalculatePrefetchSchedule(
+ mode_lib,
+ HostVMInefficiencyFactor,
+ ,
+ v->DSCDelayPerState[i][k],
+ v->DPPCLKDelaySubtotal + v->DPPCLKDelayCNVCFormater,
+ v->DPPCLKDelaySCL,
+ v->DPPCLKDelaySCLLBOnly,
+ v->DPPCLKDelayCNVCCursor,
+ v->DISPCLKDelaySubtotal,
+ v->SwathWidthYThisState[k] / v->HRatio[k],
+ v->OutputFormat[k],
+ v->MaxInterDCNTileRepeaters,
+ dml_min(v->MaxVStartup, v->MaximumVStartup[i][j][k]),
+ v->MaximumVStartup[i][j][k],
+ v->GPUVMMaxPageTableLevels,
+ v->GPUVMEnable,
+ v->HostVMEnable,
+ v->HostVMMaxNonCachedPageTableLevels,
+ v->HostVMMinPageSize,
+ v->DynamicMetadataEnable[k],
+ v->DynamicMetadataVMEnabled,
+ v->DynamicMetadataLinesBeforeActiveRequired[k],
+ v->DynamicMetadataTransmittedBytes[k],
+ v->UrgLatency[i],
+ v->ExtraLatency,
+ v->TimeCalc,
+ v->PDEAndMetaPTEBytesPerFrame[i][j][k],
+ v->MetaRowBytes[i][j][k],
+ v->DPTEBytesPerRow[i][j][k],
+ v->PrefetchLinesY[i][j][k],
+ v->SwathWidthYThisState[k],
+ v->PrefillY[k],
+ v->MaxNumSwY[k],
+ v->PrefetchLinesC[i][j][k],
+ v->SwathWidthCThisState[k],
+ v->PrefillC[k],
+ v->MaxNumSwC[k],
+ v->swath_width_luma_ub_this_state[k],
+ v->swath_width_chroma_ub_this_state[k],
+ v->SwathHeightYThisState[k],
+ v->SwathHeightCThisState[k],
+ v->TWait,
+ >DSTXAfterScaler[k],
+ >DSTYAfterScaler[k],
+ >LineTimesForPrefetch[k],
+ >PrefetchBW[k],
+ >LinesForMetaPTE[k],
+ >LinesForMetaAndDPTERow[k],
+ >VRatioPreY[i][j][k],
+
Re: [PATCH v3 0/7] drm: exynos: dsi: Convert drm bridge
Hi Jagan,
On 13.12.2021 14:56, Jagan Teki wrote:
> On Mon, Dec 13, 2021 at 6:51 PM Marek Szyprowski
> wrote:
>> On 13.12.2021 13:31, Jagan Teki wrote:
>>> On Mon, Dec 13, 2021 at 5:42 PM Marek Szyprowski
>>> wrote:
On 13.12.2021 13:08, Jagan Teki wrote:
> On Mon, Dec 13, 2021 at 5:34 PM Marek Szyprowski
> wrote:
>> On 12.12.2021 19:14, Jagan Teki wrote:
>>> Updated series about drm bridge conversion of exynos dsi.
>>>
>>> Patch 1: panel checker
>>>
>>> Patch 2: panel_bridge API
>>>
>>> Patch 3: Bridge conversion
>>>
>>> Patch 4: pree_enable, post_disable
>>>
>>> Patch 5: Atomic functions
>>>
>>> Patch 6: atomic_set
>>>
>>> Patch 7: DSI init in enable
>>>
>>> [1]
>>> https://patchwork.kernel.org/project/dri-devel/cover/20211210191922.2367979-1-ja...@amarulasolutions.com/
>>>
>>> Any inputs?
>> I've checked this patchset on Exynos based Trats2 board (the one with
>> simplest display pipeline: Exynos FIMD -> Exynos DSI -> s6e8aa0 DSI
>> panel). DRM stops working after the 2nd patch ("[PATCH v3 2/7] drm:
>> exynos: dsi: Use drm panel_bridge API"):
>>
>> # dmesg | grep drm
>> [2.511893] [drm] Exynos DRM: using 11c0.fimd device for DMA
>> mapping operations
>> [2.518653] exynos-drm exynos-drm: bound 11c0.fimd (ops
>> fimd_component_ops)
>> [2.535699] exynos-drm exynos-drm: bound 11c8.dsi (ops
>> exynos_dsi_component_ops)
>> [2.543912] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
>> [2.556107] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
>> minor 0
>> [2.573212] exynos-dsi 11c8.dsi: [drm:exynos_dsi_host_attach]
>> *ERROR* failed to find the bridge: -19
> Look like you have missed to apply the Child lookup patch. is it so?
>
> Let me send it, I will CC you as well. And I will also send tc358764
> panel_bridge conversion.
The above log is from Trats2 board, which uses only the s6e8aa0 DSI
panel. I've also checked the Arndale board, which has tc358764 bridge
and it also doesn't work. Which patches I have to apply for the tests?
>>> [PATCH v2] drm: of: Lookup if child node has panel or bridge
>>> [PATCH] drm: bridge: tc358764: Use drm panel_bridge API
>> Ok, I've applied both. Still no success on Trats:
>>
>> [2.451632] exynos4-fb 11c0.fimd: Adding to iommu group 0
>> [2.458137] OF: graph: no port node found in /soc/fimd@11c0
>> [2.476903] [drm] Exynos DRM: using 11c0.fimd device for DMA
>> mapping operations
>> [2.483905] exynos-drm exynos-drm: bound 11c0.fimd (ops
>> fimd_component_ops)
>> [2.490858] OF: graph: no port node found in /soc/dsi@11c8
>> [2.500283] exynos-drm exynos-drm: bound 11c8.dsi (ops
>> exynos_dsi_component_ops)
>> [2.508490] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
>> [2.520121] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
>> minor 0
>> [2.537231] exynos-dsi 11c8.dsi: [drm:exynos_dsi_host_attach]
>> Attached s6e8aa0 device
>> [2.566358] [ cut here ]
>> [2.569894] WARNING: CPU: 1 PID: 29 at
>> drivers/gpu/drm/drm_atomic_state_helper.c:494
>> drm_atomic_helper_connector_duplicate_state+0x94/0x9c
>> [2.586123] Modules linked in:
>> [2.586171] CPU: 1 PID: 29 Comm: kworker/1:2 Not tainted
>> 5.16.0-rc1-9-g704b1dbfa4c2 #11058
>> [2.586190] Hardware name: Samsung Exynos (Flattened Device Tree)
>> [2.586203] Workqueue: events output_poll_execute
>> [2.586235] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [2.586267] [] (show_stack) from []
>> (dump_stack_lvl+0x58/0x70)
>> [2.586299] [] (dump_stack_lvl) from []
>> (__warn+0xd0/0x134)
>> [2.586324] [] (__warn) from []
>> (warn_slowpath_fmt+0x5c/0xb4)
>> [2.586346] [] (warn_slowpath_fmt) from []
>> (drm_atomic_helper_connector_duplicate_state+0x94/0x9c)
>> [2.586371] []
>> (drm_atomic_helper_connector_duplicate_state) from []
>> (drm_atomic_get_connector_state+0xd4/0x190)
>> [2.586398] [] (drm_atomic_get_connector_state) from
>> [] (__drm_atomic_helper_set_config+0x314/0x368)
>> [2.586421] [] (__drm_atomic_helper_set_config) from
>> [] (drm_client_modeset_commit_atomic+0x170/0x278)
>> [2.586453] [] (drm_client_modeset_commit_atomic) from
>> [] (drm_client_modeset_commit_locked+0x60/0x1c8)
>> [2.586479] [] (drm_client_modeset_commit_locked) from
>> [] (drm_client_modeset_commit+0x24/0x40)
>> [2.586505] [] (drm_client_modeset_commit) from
>> [] (drm_fb_helper_set_par+0xb8/0xf8)
>> [2.586535] [] (drm_fb_helper_set_par) from []
>> (drm_fb_helper_hotplug_event.part.0+0xa8/0xc0)
>> [2.586560] [] (drm_fb_helper_hotplug_event.part.0) from
>> [] (output_poll_execute+0xac/0x21c)
>> [2.586585] [] (output_poll_execute) from []
>> (process_one_work+0x288/0x7a4)
>> [2.586611] []
RE: [PATCH] drm/edid: Refine HDMI VSDB detect
On Monday, December 13, 2021 at 12:45 p.m, Ville Syrjälä wrote: >On Mon, Dec 13, 2021 at 12:42:22PM +, Lee, Shawn C wrote: >> >> On Monday, December 13, 2021 8:31 PM, Ville Syrjälä wrote: >> >On Sun, Dec 12, 2021 at 11:33:31PM +0800, Lee Shawn C wrote: >> >> According to CEA-861-F chapter 7.5.4. It says "The VSDB shall contain >> >> the >> >> 3 bytes of the IEEE OUI as well as any additional payload bytes needed." >> >> Now DRM driver check HDMI OUI but VSDB payload size at least five bytes. >> >> That may caused some HDMI monitors' audio feature can't be enabled. >> >> Because of they only have three bytes payload (OUI only) in VSDB. >> > >> >HDMI 1.4a says >> >"Sinks shall contain an HDMI VSDB minimally containing a 2-byte Source >> >Physical Address field following the 24-bit identifier. ... >> > The minimum value of N (length) is 5 and the maximum value of N is 31." >> > >> >Do you actually have an EDID that violates that? >> > >> >> Yes! User report when connect to HDMI port on Acer V226HQL. Audio is not >> working. >> But windows system did not have the same problem. We found its VSDB just >> have 3 bytes >> payload (OUI). Then we share this patch to user then they report audio works >> properly >> with this patch. > >Hrm. This deserves a comment then since it clearly violates the spec. >Also a link to the bug if you have one would be nice to include here. > Let me create an issue and update monitor's EDID for you reference. But I'm not sure which community is suitable to report this problem. It looks to me should belong to DRM driver https://gitlab.freedesktop.org/drm/misc/-/issues. Do you have any suggestion? Thanks! >> >> Best regards, >> Shawn >> >> >> >> >> Cc: Ville Syrjälä >> >> Cc: Adam Jackson >> >> Cc: Dave Airlie >> >> Signed-off-by: Lee Shawn C >> >> --- >> >> drivers/gpu/drm/drm_edid.c | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c >> >> index 12893e7be89b..5aa4a6bf4a13 100644 >> >> --- a/drivers/gpu/drm/drm_edid.c >> >> +++ b/drivers/gpu/drm/drm_edid.c >> >> @@ -4205,7 +4205,7 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db) >> >> if (cea_db_tag(db) != VENDOR_BLOCK) >> >> return false; >> >> >> >> - if (cea_db_payload_len(db) < 5) >> >> + if (cea_db_payload_len(db) < 3) >> >> return false; >> >> >> >> return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI; >> >> -- >> >> 2.31.1 >> > >> >-- >> >Ville Syrjälä >> >Intel >> >
Re: [PATCH v3 0/7] drm: exynos: dsi: Convert drm bridge
Hi Marek,
On Mon, Dec 13, 2021 at 6:51 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 13.12.2021 13:31, Jagan Teki wrote:
> > On Mon, Dec 13, 2021 at 5:42 PM Marek Szyprowski
> > wrote:
> >> On 13.12.2021 13:08, Jagan Teki wrote:
> >>> On Mon, Dec 13, 2021 at 5:34 PM Marek Szyprowski
> >>> wrote:
> On 12.12.2021 19:14, Jagan Teki wrote:
> > Updated series about drm bridge conversion of exynos dsi.
> >
> > Patch 1: panel checker
> >
> > Patch 2: panel_bridge API
> >
> > Patch 3: Bridge conversion
> >
> > Patch 4: pree_enable, post_disable
> >
> > Patch 5: Atomic functions
> >
> > Patch 6: atomic_set
> >
> > Patch 7: DSI init in enable
> >
> > [1]
> > https://patchwork.kernel.org/project/dri-devel/cover/20211210191922.2367979-1-ja...@amarulasolutions.com/
> >
> > Any inputs?
> I've checked this patchset on Exynos based Trats2 board (the one with
> simplest display pipeline: Exynos FIMD -> Exynos DSI -> s6e8aa0 DSI
> panel). DRM stops working after the 2nd patch ("[PATCH v3 2/7] drm:
> exynos: dsi: Use drm panel_bridge API"):
>
> # dmesg | grep drm
> [2.511893] [drm] Exynos DRM: using 11c0.fimd device for DMA
> mapping operations
> [2.518653] exynos-drm exynos-drm: bound 11c0.fimd (ops
> fimd_component_ops)
> [2.535699] exynos-drm exynos-drm: bound 11c8.dsi (ops
> exynos_dsi_component_ops)
> [2.543912] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
> [2.556107] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
> minor 0
> [2.573212] exynos-dsi 11c8.dsi: [drm:exynos_dsi_host_attach]
> *ERROR* failed to find the bridge: -19
> >>> Look like you have missed to apply the Child lookup patch. is it so?
> >>>
> >>> Let me send it, I will CC you as well. And I will also send tc358764
> >>> panel_bridge conversion.
> >> The above log is from Trats2 board, which uses only the s6e8aa0 DSI
> >> panel. I've also checked the Arndale board, which has tc358764 bridge
> >> and it also doesn't work. Which patches I have to apply for the tests?
> > [PATCH v2] drm: of: Lookup if child node has panel or bridge
> > [PATCH] drm: bridge: tc358764: Use drm panel_bridge API
>
> Ok, I've applied both. Still no success on Trats:
>
> [2.451632] exynos4-fb 11c0.fimd: Adding to iommu group 0
> [2.458137] OF: graph: no port node found in /soc/fimd@11c0
> [2.476903] [drm] Exynos DRM: using 11c0.fimd device for DMA
> mapping operations
> [2.483905] exynos-drm exynos-drm: bound 11c0.fimd (ops
> fimd_component_ops)
> [2.490858] OF: graph: no port node found in /soc/dsi@11c8
> [2.500283] exynos-drm exynos-drm: bound 11c8.dsi (ops
> exynos_dsi_component_ops)
> [2.508490] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
> [2.520121] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
> minor 0
> [2.537231] exynos-dsi 11c8.dsi: [drm:exynos_dsi_host_attach]
> Attached s6e8aa0 device
> [2.566358] [ cut here ]
> [2.569894] WARNING: CPU: 1 PID: 29 at
> drivers/gpu/drm/drm_atomic_state_helper.c:494
> drm_atomic_helper_connector_duplicate_state+0x94/0x9c
> [2.586123] Modules linked in:
> [2.586171] CPU: 1 PID: 29 Comm: kworker/1:2 Not tainted
> 5.16.0-rc1-9-g704b1dbfa4c2 #11058
> [2.586190] Hardware name: Samsung Exynos (Flattened Device Tree)
> [2.586203] Workqueue: events output_poll_execute
> [2.586235] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [2.586267] [] (show_stack) from []
> (dump_stack_lvl+0x58/0x70)
> [2.586299] [] (dump_stack_lvl) from []
> (__warn+0xd0/0x134)
> [2.586324] [] (__warn) from []
> (warn_slowpath_fmt+0x5c/0xb4)
> [2.586346] [] (warn_slowpath_fmt) from []
> (drm_atomic_helper_connector_duplicate_state+0x94/0x9c)
> [2.586371] []
> (drm_atomic_helper_connector_duplicate_state) from []
> (drm_atomic_get_connector_state+0xd4/0x190)
> [2.586398] [] (drm_atomic_get_connector_state) from
> [] (__drm_atomic_helper_set_config+0x314/0x368)
> [2.586421] [] (__drm_atomic_helper_set_config) from
> [] (drm_client_modeset_commit_atomic+0x170/0x278)
> [2.586453] [] (drm_client_modeset_commit_atomic) from
> [] (drm_client_modeset_commit_locked+0x60/0x1c8)
> [2.586479] [] (drm_client_modeset_commit_locked) from
> [] (drm_client_modeset_commit+0x24/0x40)
> [2.586505] [] (drm_client_modeset_commit) from
> [] (drm_fb_helper_set_par+0xb8/0xf8)
> [2.586535] [] (drm_fb_helper_set_par) from []
> (drm_fb_helper_hotplug_event.part.0+0xa8/0xc0)
> [2.586560] [] (drm_fb_helper_hotplug_event.part.0) from
> [] (output_poll_execute+0xac/0x21c)
> [2.586585] [] (output_poll_execute) from []
> (process_one_work+0x288/0x7a4)
> [2.586611] [] (process_one_work) from []
> (worker_thread+0x44/0x534)
> [2.586633] [] (worker_thread)
Re: [PATCH 0/3] drm/dp: Move DisplayPort helpers into own module
Hi
Am 13.12.21 um 14:34 schrieb Jani Nikula:
On Mon, 13 Dec 2021, Thomas Zimmermann wrote:
Split-off DisplayPort functions from KMS helper library and move them
into their own module. Reduces the size of drm_kms_helper.ko by ~50%.
This patchset is part of an on-going effort to reduce the minimum
binary size of the DRM core and helpers. It's helpful for systems with
early-boot DRM graphics, which requires DRM to be linked into the
kernel image.
Would it be time to add a subdirectory for each non-driver, non-core drm
module? We've touched this topic before. I find it increasingly hard to
remember which files are part of helpers. This would also help with the
arbitrary drm_dp_helper_mod.c naming.
Perhaps drivers/gpu/drm/drm_dp/?
It's probably worth it, but I'd prefer a separate patchset and
discussion over this. It affects several modules.
If adding drm_dp_helper_mod.c is overkill, that module code can also be
added to drm_dp.c for now.
Best regards
Thomas
BR,
Jani.
Thomas Zimmermann (3):
drm/dp_mst: Remove trailing whitespace.
drm/dp: Move DP declarations into separate header file
drm/dp: Move DisplayPort helpers into separate helper module
drivers/gpu/drm/Kconfig | 8 ++
drivers/gpu/drm/Makefile | 14 ++
drivers/gpu/drm/bridge/Kconfig| 4 +++
drivers/gpu/drm/bridge/analogix/Kconfig | 2 ++
drivers/gpu/drm/bridge/cadence/Kconfig| 1 +
drivers/gpu/drm/drm_crtc_helper_internal.h| 27 --
drivers/gpu/drm/{drm_dp_helper.c => drm_dp.c} | 2 +-
drivers/gpu/drm/drm_dp_aux_dev.c | 2 +-
drivers/gpu/drm/drm_dp_helper_internal.h | 28 +++
drivers/gpu/drm/drm_dp_helper_mod.c | 22 +++
drivers/gpu/drm/drm_dp_mst_topology.c | 4 +--
drivers/gpu/drm/drm_kms_helper_common.c | 14 --
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/gpu/drm/rockchip/Kconfig | 1 +
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/xlnx/Kconfig | 1 +
18 files changed, 83 insertions(+), 51 deletions(-)
rename drivers/gpu/drm/{drm_dp_helper.c => drm_dp.c} (99%)
create mode 100644 drivers/gpu/drm/drm_dp_helper_internal.h
create mode 100644 drivers/gpu/drm/drm_dp_helper_mod.c
base-commit: 3f422828221d9ceefcddef0be33561b1646a1cbe
prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
--
2.34.1
--
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
[PATCH v5 4/4] drm/bridge: ti-sn65dsi83: Add vcc supply regulator support
VCC needs to be enabled before releasing the enable GPIO.
Reviewed-by: Laurent Pinchart
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 065610edc37a..5650a793db81 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -143,6 +144,7 @@ struct sn65dsi83 {
struct mipi_dsi_device *dsi;
struct drm_bridge *panel_bridge;
struct gpio_desc*enable_gpio;
+ struct regulator*vcc;
int dsi_lanes;
boollvds_dual_link;
boollvds_dual_link_even_odd_swap;
@@ -337,6 +339,12 @@ static void sn65dsi83_atomic_enable(struct drm_bridge
*bridge,
u16 val;
int ret;
+ ret = regulator_enable(ctx->vcc);
+ if (ret) {
+ dev_err(ctx->dev, "Failed to enable vcc: %d\n", ret);
+ return;
+ }
+
/* Deassert reset */
gpiod_set_value(ctx->enable_gpio, 1);
usleep_range(1000, 1100);
@@ -486,11 +494,16 @@ static void sn65dsi83_atomic_disable(struct drm_bridge
*bridge,
struct drm_bridge_state *old_bridge_state)
{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+ int ret;
/* Put the chip in reset, pull EN line low, and assure 10ms reset low
timing. */
gpiod_set_value(ctx->enable_gpio, 0);
usleep_range(1, 11000);
+ ret = regulator_disable(ctx->vcc);
+ if (ret)
+ dev_err(ctx->dev, "Failed to disable vcc: %d\n", ret);
+
regcache_mark_dirty(ctx->regmap);
}
@@ -599,6 +612,11 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum
sn65dsi83_model model)
ctx->panel_bridge = panel_bridge;
+ ctx->vcc = devm_regulator_get(dev, "vcc");
+ if (IS_ERR(ctx->vcc))
+ return dev_err_probe(dev, PTR_ERR(ctx->vcc),
+"Failed to get supply 'vcc'\n");
+
return 0;
}
--
2.25.1
[PATCH v5 3/4] dt-bindings: drm/bridge: ti-sn65dsi83: Add vcc supply bindings
Add a VCC regulator which needs to be enabled before the EN pin is
released.
Reviewed-by: Sam Ravnborg
Acked-by: Rob Herring
Reviewed-by: Jagan Teki
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
index c3f3e73f740a..48a97bb3e2e0 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
@@ -32,6 +32,9 @@ properties:
maxItems: 1
description: GPIO specifier for bridge_en pin (active high).
+ vcc-supply:
+description: A 1.8V power supply (see regulator/regulator.yaml).
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -132,6 +135,7 @@ examples:
reg = <0x2d>;
enable-gpios = < 1 GPIO_ACTIVE_HIGH>;
+vcc-supply = <_sn65dsi83_1v8>;
ports {
#address-cells = <1>;
--
2.25.1
[PATCH v5 2/4] drm/bridge: ti-sn65dsi83: Make enable GPIO optional
The enable signal may not be controllable by the kernel. Make it
optional.
This is a similar to commit bbda1704fc15 ("drm/bridge: ti-sn65dsi86: Make
enable GPIO optional")
Reviewed-by: Laurent Pinchart
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 945f08de45f1..065610edc37a 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -662,7 +662,8 @@ static int sn65dsi83_probe(struct i2c_client *client,
}
/* Put the chip in reset, pull EN line low, and assure 10ms reset low
timing. */
- ctx->enable_gpio = devm_gpiod_get(ctx->dev, "enable", GPIOD_OUT_LOW);
+ ctx->enable_gpio = devm_gpiod_get_optional(ctx->dev, "enable",
+ GPIOD_OUT_LOW);
if (IS_ERR(ctx->enable_gpio))
return PTR_ERR(ctx->enable_gpio);
--
2.25.1
[PATCH v5 1/4] dt-bindings: display: bridge: sn65dsi83: Make enable GPIO optional
From: Laurent Pinchart The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled by means not available to the kernel. Make the GPIO optional. Signed-off-by: Laurent Pinchart Acked-by: Rob Herring Signed-off-by: Alexander Stein --- .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index b446d0f0f1b4..c3f3e73f740a 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -91,7 +91,6 @@ properties: required: - compatible - reg - - enable-gpios - ports allOf: -- 2.25.1
[PATCH v5 0/4] ti-sn65dsi83 patches
Changes in V5 of this set: * Rebased to next-20211208 * Fix format string in error message * Remove superfluous error value for dev_err_probe() * Added Reviewed-by: Jagan Teki for patch 3 & 4 Changes in V4 of this set: * Rebased to next-2028 (due to merge-conflict in linux-next) * Added Rob Herring's Ack on Patch 1 & 3 * Reworked patch 4 due to other changes in linux-next * Removed Sam Ravnborg's Reviewed-by for patch4 due to rework Changes in V3 of this set: * Do not require vcc-supply in bindings, making it purely optional * Move regulator enable/disable to sn65dsi83_atomic_pre_enable and sn65dsi83_atomic_disable Changes in V2 of this set: * Add patch from Laurent for fixing the binding regarding optional GPIO * Reorder patches so bindings are changed beforehand * Add small fixes from Sam's review Alexander Stein (3): drm/bridge: ti-sn65dsi83: Make enable GPIO optional dt-bindings: drm/bridge: ti-sn65dsi83: Add vcc supply bindings drm/bridge: ti-sn65dsi83: Add vcc supply regulator support Laurent Pinchart (1): dt-bindings: display: bridge: sn65dsi83: Make enable GPIO optional .../bindings/display/bridge/ti,sn65dsi83.yaml | 5 - drivers/gpu/drm/bridge/ti-sn65dsi83.c | 21 ++- 2 files changed, 24 insertions(+), 2 deletions(-) -- 2.25.1
Re: [PATCH 0/3] drm/dp: Move DisplayPort helpers into own module
On Mon, 13 Dec 2021, Thomas Zimmermann wrote:
> Split-off DisplayPort functions from KMS helper library and move them
> into their own module. Reduces the size of drm_kms_helper.ko by ~50%.
>
> This patchset is part of an on-going effort to reduce the minimum
> binary size of the DRM core and helpers. It's helpful for systems with
> early-boot DRM graphics, which requires DRM to be linked into the
> kernel image.
Would it be time to add a subdirectory for each non-driver, non-core drm
module? We've touched this topic before. I find it increasingly hard to
remember which files are part of helpers. This would also help with the
arbitrary drm_dp_helper_mod.c naming.
Perhaps drivers/gpu/drm/drm_dp/?
BR,
Jani.
>
> Thomas Zimmermann (3):
> drm/dp_mst: Remove trailing whitespace.
> drm/dp: Move DP declarations into separate header file
> drm/dp: Move DisplayPort helpers into separate helper module
>
> drivers/gpu/drm/Kconfig | 8 ++
> drivers/gpu/drm/Makefile | 14 ++
> drivers/gpu/drm/bridge/Kconfig| 4 +++
> drivers/gpu/drm/bridge/analogix/Kconfig | 2 ++
> drivers/gpu/drm/bridge/cadence/Kconfig| 1 +
> drivers/gpu/drm/drm_crtc_helper_internal.h| 27 --
> drivers/gpu/drm/{drm_dp_helper.c => drm_dp.c} | 2 +-
> drivers/gpu/drm/drm_dp_aux_dev.c | 2 +-
> drivers/gpu/drm/drm_dp_helper_internal.h | 28 +++
> drivers/gpu/drm/drm_dp_helper_mod.c | 22 +++
> drivers/gpu/drm/drm_dp_mst_topology.c | 4 +--
> drivers/gpu/drm/drm_kms_helper_common.c | 14 --
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/msm/Kconfig | 1 +
> drivers/gpu/drm/nouveau/Kconfig | 1 +
> drivers/gpu/drm/rockchip/Kconfig | 1 +
> drivers/gpu/drm/tegra/Kconfig | 1 +
> drivers/gpu/drm/xlnx/Kconfig | 1 +
> 18 files changed, 83 insertions(+), 51 deletions(-)
> rename drivers/gpu/drm/{drm_dp_helper.c => drm_dp.c} (99%)
> create mode 100644 drivers/gpu/drm/drm_dp_helper_internal.h
> create mode 100644 drivers/gpu/drm/drm_dp_helper_mod.c
>
>
> base-commit: 3f422828221d9ceefcddef0be33561b1646a1cbe
> prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
> prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
> --
> 2.34.1
>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v3 0/7] drm: exynos: dsi: Convert drm bridge
Hi Jagan,
On 13.12.2021 13:31, Jagan Teki wrote:
> On Mon, Dec 13, 2021 at 5:42 PM Marek Szyprowski
> wrote:
>> On 13.12.2021 13:08, Jagan Teki wrote:
>>> On Mon, Dec 13, 2021 at 5:34 PM Marek Szyprowski
>>> wrote:
On 12.12.2021 19:14, Jagan Teki wrote:
> Updated series about drm bridge conversion of exynos dsi.
>
> Patch 1: panel checker
>
> Patch 2: panel_bridge API
>
> Patch 3: Bridge conversion
>
> Patch 4: pree_enable, post_disable
>
> Patch 5: Atomic functions
>
> Patch 6: atomic_set
>
> Patch 7: DSI init in enable
>
> [1]
> https://patchwork.kernel.org/project/dri-devel/cover/20211210191922.2367979-1-ja...@amarulasolutions.com/
>
> Any inputs?
I've checked this patchset on Exynos based Trats2 board (the one with
simplest display pipeline: Exynos FIMD -> Exynos DSI -> s6e8aa0 DSI
panel). DRM stops working after the 2nd patch ("[PATCH v3 2/7] drm:
exynos: dsi: Use drm panel_bridge API"):
# dmesg | grep drm
[2.511893] [drm] Exynos DRM: using 11c0.fimd device for DMA
mapping operations
[2.518653] exynos-drm exynos-drm: bound 11c0.fimd (ops
fimd_component_ops)
[2.535699] exynos-drm exynos-drm: bound 11c8.dsi (ops
exynos_dsi_component_ops)
[2.543912] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
[2.556107] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
minor 0
[2.573212] exynos-dsi 11c8.dsi: [drm:exynos_dsi_host_attach]
*ERROR* failed to find the bridge: -19
>>> Look like you have missed to apply the Child lookup patch. is it so?
>>>
>>> Let me send it, I will CC you as well. And I will also send tc358764
>>> panel_bridge conversion.
>> The above log is from Trats2 board, which uses only the s6e8aa0 DSI
>> panel. I've also checked the Arndale board, which has tc358764 bridge
>> and it also doesn't work. Which patches I have to apply for the tests?
> [PATCH v2] drm: of: Lookup if child node has panel or bridge
> [PATCH] drm: bridge: tc358764: Use drm panel_bridge API
Ok, I've applied both. Still no success on Trats:
[ 2.451632] exynos4-fb 11c0.fimd: Adding to iommu group 0
[ 2.458137] OF: graph: no port node found in /soc/fimd@11c0
[ 2.476903] [drm] Exynos DRM: using 11c0.fimd device for DMA
mapping operations
[ 2.483905] exynos-drm exynos-drm: bound 11c0.fimd (ops
fimd_component_ops)
[ 2.490858] OF: graph: no port node found in /soc/dsi@11c8
[ 2.500283] exynos-drm exynos-drm: bound 11c8.dsi (ops
exynos_dsi_component_ops)
[ 2.508490] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
[ 2.520121] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
minor 0
[ 2.537231] exynos-dsi 11c8.dsi: [drm:exynos_dsi_host_attach]
Attached s6e8aa0 device
[ 2.566358] [ cut here ]
[ 2.569894] WARNING: CPU: 1 PID: 29 at
drivers/gpu/drm/drm_atomic_state_helper.c:494
drm_atomic_helper_connector_duplicate_state+0x94/0x9c
[ 2.586123] Modules linked in:
[ 2.586171] CPU: 1 PID: 29 Comm: kworker/1:2 Not tainted
5.16.0-rc1-9-g704b1dbfa4c2 #11058
[ 2.586190] Hardware name: Samsung Exynos (Flattened Device Tree)
[ 2.586203] Workqueue: events output_poll_execute
[ 2.586235] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 2.586267] [] (show_stack) from []
(dump_stack_lvl+0x58/0x70)
[ 2.586299] [] (dump_stack_lvl) from []
(__warn+0xd0/0x134)
[ 2.586324] [] (__warn) from []
(warn_slowpath_fmt+0x5c/0xb4)
[ 2.586346] [] (warn_slowpath_fmt) from []
(drm_atomic_helper_connector_duplicate_state+0x94/0x9c)
[ 2.586371] []
(drm_atomic_helper_connector_duplicate_state) from []
(drm_atomic_get_connector_state+0xd4/0x190)
[ 2.586398] [] (drm_atomic_get_connector_state) from
[] (__drm_atomic_helper_set_config+0x314/0x368)
[ 2.586421] [] (__drm_atomic_helper_set_config) from
[] (drm_client_modeset_commit_atomic+0x170/0x278)
[ 2.586453] [] (drm_client_modeset_commit_atomic) from
[] (drm_client_modeset_commit_locked+0x60/0x1c8)
[ 2.586479] [] (drm_client_modeset_commit_locked) from
[] (drm_client_modeset_commit+0x24/0x40)
[ 2.586505] [] (drm_client_modeset_commit) from
[] (drm_fb_helper_set_par+0xb8/0xf8)
[ 2.586535] [] (drm_fb_helper_set_par) from []
(drm_fb_helper_hotplug_event.part.0+0xa8/0xc0)
[ 2.586560] [] (drm_fb_helper_hotplug_event.part.0) from
[] (output_poll_execute+0xac/0x21c)
[ 2.586585] [] (output_poll_execute) from []
(process_one_work+0x288/0x7a4)
[ 2.586611] [] (process_one_work) from []
(worker_thread+0x44/0x534)
[ 2.586633] [] (worker_thread) from []
(kthread+0x158/0x190)
[ 2.586655] [] (kthread) from []
(ret_from_fork+0x14/0x2c)
[ 2.586675] Exception stack(0xc1f6ffb0 to 0xc1f6fff8)
[ 2.586690] ffa0:
[ 2.586705] ffc0:
Re: [PATCH] drm/mediatek: hdmi: Perform NULL pointer check for mtk_hdmi_conf
Hi, Angelo:
AngeloGioacchino Del Regno 於
2021年12月13日 週一 下午6:02寫道：
>
> Il 28/10/21 09:43, AngeloGioacchino Del Regno ha scritto:
> > In commit 41ca9caaae0b ("drm/mediatek: hdmi: Add check for CEA modes only")
> > a check for CEA modes was added to function mtk_hdmi_bridge_mode_valid()
> > in order to address possible issues on MT8167; moreover, with commit
> > c91026a938c2 ("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode
> > clock")
> > another similar check was introduced.
> >
> > Unfortunately though, at the time of writing, MT8173 does not provide
> > any mtk_hdmi_conf structure and this is crashing the kernel with NULL
> > pointer upon entering mtk_hdmi_bridge_mode_valid(), which happens as
> > soon as a HDMI cable gets plugged in.
> >
> > To fix this regression, add a NULL pointer check for hdmi->conf in the
> > said function, restoring HDMI functionality and avoiding NULL pointer
> > kernel panics.
> >
> > Fixes: 41ca9caaae0b ("drm/mediatek: hdmi: Add check for CEA modes only")
> > Fixes: c91026a938c2 ("drm/mediatek: hdmi: Add optional limit on maximal
> > HDMI mode clock")
> > Signed-off-by: AngeloGioacchino Del Regno
> >
> > ---
> > drivers/gpu/drm/mediatek/mtk_hdmi.c | 12 +++-
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > index 5838c44cbf6f..3196189429bc 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > @@ -1224,12 +1224,14 @@ static int mtk_hdmi_bridge_mode_valid(struct
> > drm_bridge *bridge,
> > return MODE_BAD;
> > }
> >
> > - if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
> > - return MODE_BAD;
> > + if (hdmi->conf) {
> > + if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
> > + return MODE_BAD;
> >
> > - if (hdmi->conf->max_mode_clock &&
> > - mode->clock > hdmi->conf->max_mode_clock)
> > - return MODE_CLOCK_HIGH;
> > + if (hdmi->conf->max_mode_clock &&
> > + mode->clock > hdmi->conf->max_mode_clock)
> > + return MODE_CLOCK_HIGH;
> > + }
> >
> > if (mode->clock < 27000)
> > return MODE_CLOCK_LOW;
> >
>
> Hello, friendly ping!
>
> Can I please get a review (or merge) of this commit?
>
> This is an important fix for a null pointer KP and restores HDMI
> functionality.
Applied to mediatek-drm-fixes [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes
Regards,
Chun-Kuang.
>
> Thanks,
> - Angelo
Re: [PATCH] drm/i915/ttm: fix large buffer population trucation
On 10/12/2021 19:50, Robert Beckett wrote:
ttm->num_pages is uint32_t which was causing very large buffers to
only populate a truncated size.
This fixes gem_create@create-clear igt test on large memory systems.
Fixes: 7ae034590cea ("drm/i915/ttm: add tt shmem backend")
Signed-off-by: Robert Beckett
Nice catch,
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 218a9b3037c7..923cc7ad8d70 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -166,7 +166,7 @@ static int i915_ttm_tt_shmem_populate(struct ttm_device
*bdev,
struct intel_memory_region *mr = i915->mm.regions[INTEL_MEMORY_SYSTEM];
struct i915_ttm_tt *i915_tt = container_of(ttm, typeof(*i915_tt), ttm);
const unsigned int max_segment = i915_sg_segment_size();
- const size_t size = ttm->num_pages << PAGE_SHIFT;
+ const size_t size = (size_t)ttm->num_pages << PAGE_SHIFT;
struct file *filp = i915_tt->filp;
struct sgt_iter sgt_iter;
struct sg_table *st;
Re: [PATCH] drm/i915/debugfs: add noreclaim annotations
On 12/13/21 13:55, Matthew Auld wrote:
We have a debugfs hook to directly call into i915_gem_shrink() with the
fs_reclaim acquire annotations to simulate hitting direct reclaim.
However we should also annotate this with memalloc_noreclaim, which will
set PF_MEMALLOC for us on the current context, to ensure we can't
re-enter direct reclaim(just like "real" direct reclaim does). This is
an issue now that ttm_bo_validate could potentially be called here,
which might try to allocate a tiny amount of memory to hold the new
ttm_resource struct, as per the below splat:
[ 2507.913844] WARNING: possible recursive locking detected
[ 2507.913848] 5.16.0-rc4+ #5 Tainted: G U
[ 2507.913853]
[ 2507.913856] gem_exec_captur/1825 is trying to acquire lock:
[ 2507.913861] b9df2500 (fs_reclaim){..}-{0:0}, at:
kmem_cache_alloc_trace+0x30/0x390
[ 2507.913875]
but task is already holding lock:
[ 2507.913879] b9df2500 (fs_reclaim){..}-{0:0}, at:
i915_drop_caches_set+0x1c9/0x2c0 [i915]
[ 2507.913962]
other info that might help us debug this:
[ 2507.913966] Possible unsafe locking scenario:
[ 2507.913970] CPU0
[ 2507.913973]
[ 2507.913975] lock(fs_reclaim);
[ 2507.913979] lock(fs_reclaim);
[ 2507.913983]
DEADLOCK ***
[ 2507.913988] May be due to missing lock nesting notation
[ 2507.913992] 4 locks held by gem_exec_captur/1825:
[ 2507.913997] #0: 888101f6e460 (sb_writers#17){..}-{0:0}, at:
ksys_write+0xe9/0x1b0
[ 2507.914009] #1: 88812d99e2b8 (>mutex){..}-{3:3}, at:
simple_attr_write+0xbb/0x220
[ 2507.914019] #2: b9df2500 (fs_reclaim){..}-{0:0}, at:
i915_drop_caches_set+0x1c9/0x2c0 [i915]
[ 2507.914085] #3: 8881b4a11b20 (reservation_ww_class_mutex){..}-{3:3}, at:
ww_mutex_trylock+0x43f/0xcb0
[ 2507.914097]
stack backtrace:
[ 2507.914102] CPU: 0 PID: 1825 Comm: gem_exec_captur Tainted: G U 5.16.0-rc4+
#5
[ 2507.914109] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS
0403 01/26/2021
[ 2507.914115] Call Trace:
[ 2507.914118]
[ 2507.914121] dump_stack_lvl+0x59/0x73
[ 2507.914128] __lock_acquire.cold+0x227/0x3b0
[ 2507.914135] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 2507.914141] ? __lock_acquire+0x23ca/0x5000
[ 2507.914147] lock_acquire+0x19c/0x4b0
[ 2507.914152] ? kmem_cache_alloc_trace+0x30/0x390
[ 2507.914157] ? lock_release+0x690/0x690
[ 2507.914163] ? lock_is_held_type+0xe4/0x140
[ 2507.914170] ? ttm_sys_man_alloc+0x47/0xb0 [ttm]
[ 2507.914178] fs_reclaim_acquire+0x11a/0x160
[ 2507.914183] ? kmem_cache_alloc_trace+0x30/0x390
[ 2507.914188] kmem_cache_alloc_trace+0x30/0x390
[ 2507.914192] ? lock_release+0x37f/0x690
[ 2507.914198] ttm_sys_man_alloc+0x47/0xb0 [ttm]
[ 2507.914206] ttm_bo_pipeline_gutting+0x70/0x440 [ttm]
[ 2507.914214] ? ttm_mem_io_free+0x150/0x150 [ttm]
[ 2507.914221] ? lock_is_held_type+0xe4/0x140
[ 2507.914227] ttm_bo_validate+0x2fb/0x370 [ttm]
[ 2507.914234] ? lock_acquire+0x19c/0x4b0
[ 2507.914239] ? ttm_bo_bounce_temp_buffer.constprop.0+0xf0/0xf0 [ttm]
[ 2507.914246] ? lock_acquire+0x131/0x4b0
[ 2507.914251] ? lock_is_held_type+0xe4/0x140
[ 2507.914257] i915_ttm_shrinker_release_pages+0x2bc/0x490 [i915]
[ 2507.914339] ? i915_ttm_swap_notify+0x130/0x130 [i915]
[ 2507.914429] ? i915_gem_object_release_mmap_offset+0x32/0x250 [i915]
[ 2507.914529] i915_gem_shrink+0xb14/0x1290 [i915]
[ 2507.914616] ? ___i915_gem_object_make_shrinkable+0x3e0/0x3e0 [i915]
[ 2507.914698] ? _raw_spin_unlock_irqrestore+0x2d/0x60
[ 2507.914705] ? track_intel_runtime_pm_wakeref+0x180/0x230 [i915]
[ 2507.914777] i915_gem_shrink_all+0x4b/0x70 [i915]
[ 2507.914857] i915_drop_caches_set+0x227/0x2c0 [i915]
Reported-by: Thomas Hellström
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index bafb902269de..359d8ffc6e36 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -666,6 +666,7 @@ static int
i915_drop_caches_set(void *data, u64 val)
{
struct drm_i915_private *i915 = data;
+ unsigned int flags;
int ret;
DRM_DEBUG("Dropping caches: 0x%08llx [0x%08llx]\n",
@@ -676,6 +677,7 @@ i915_drop_caches_set(void *data, u64 val)
return ret;
fs_reclaim_acquire(GFP_KERNEL);
+ flags = memalloc_noreclaim_save();
if (val & DROP_BOUND)
i915_gem_shrink(NULL, i915, LONG_MAX, NULL, I915_SHRINK_BOUND);
@@ -684,6 +686,7 @@ i915_drop_caches_set(void *data, u64 val)
if (val & DROP_SHRINK_ALL)
i915_gem_shrink_all(i915);
+ memalloc_noreclaim_restore(flags);
fs_reclaim_release(GFP_KERNEL);
if (val & DROP_RCU)
Reviewed-by: Thomas Hellström
[PATCH] drm/i915/debugfs: add noreclaim annotations
We have a debugfs hook to directly call into i915_gem_shrink() with the
fs_reclaim acquire annotations to simulate hitting direct reclaim.
However we should also annotate this with memalloc_noreclaim, which will
set PF_MEMALLOC for us on the current context, to ensure we can't
re-enter direct reclaim(just like "real" direct reclaim does). This is
an issue now that ttm_bo_validate could potentially be called here,
which might try to allocate a tiny amount of memory to hold the new
ttm_resource struct, as per the below splat:
[ 2507.913844] WARNING: possible recursive locking detected
[ 2507.913848] 5.16.0-rc4+ #5 Tainted: G U
[ 2507.913853]
[ 2507.913856] gem_exec_captur/1825 is trying to acquire lock:
[ 2507.913861] b9df2500 (fs_reclaim){..}-{0:0}, at:
kmem_cache_alloc_trace+0x30/0x390
[ 2507.913875]
but task is already holding lock:
[ 2507.913879] b9df2500 (fs_reclaim){..}-{0:0}, at:
i915_drop_caches_set+0x1c9/0x2c0 [i915]
[ 2507.913962]
other info that might help us debug this:
[ 2507.913966] Possible unsafe locking scenario:
[ 2507.913970] CPU0
[ 2507.913973]
[ 2507.913975] lock(fs_reclaim);
[ 2507.913979] lock(fs_reclaim);
[ 2507.913983]
DEADLOCK ***
[ 2507.913988] May be due to missing lock nesting notation
[ 2507.913992] 4 locks held by gem_exec_captur/1825:
[ 2507.913997] #0: 888101f6e460 (sb_writers#17){..}-{0:0}, at:
ksys_write+0xe9/0x1b0
[ 2507.914009] #1: 88812d99e2b8 (>mutex){..}-{3:3}, at:
simple_attr_write+0xbb/0x220
[ 2507.914019] #2: b9df2500 (fs_reclaim){..}-{0:0}, at:
i915_drop_caches_set+0x1c9/0x2c0 [i915]
[ 2507.914085] #3: 8881b4a11b20 (reservation_ww_class_mutex){..}-{3:3}, at:
ww_mutex_trylock+0x43f/0xcb0
[ 2507.914097]
stack backtrace:
[ 2507.914102] CPU: 0 PID: 1825 Comm: gem_exec_captur Tainted: G U 5.16.0-rc4+
#5
[ 2507.914109] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS
0403 01/26/2021
[ 2507.914115] Call Trace:
[ 2507.914118]
[ 2507.914121] dump_stack_lvl+0x59/0x73
[ 2507.914128] __lock_acquire.cold+0x227/0x3b0
[ 2507.914135] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 2507.914141] ? __lock_acquire+0x23ca/0x5000
[ 2507.914147] lock_acquire+0x19c/0x4b0
[ 2507.914152] ? kmem_cache_alloc_trace+0x30/0x390
[ 2507.914157] ? lock_release+0x690/0x690
[ 2507.914163] ? lock_is_held_type+0xe4/0x140
[ 2507.914170] ? ttm_sys_man_alloc+0x47/0xb0 [ttm]
[ 2507.914178] fs_reclaim_acquire+0x11a/0x160
[ 2507.914183] ? kmem_cache_alloc_trace+0x30/0x390
[ 2507.914188] kmem_cache_alloc_trace+0x30/0x390
[ 2507.914192] ? lock_release+0x37f/0x690
[ 2507.914198] ttm_sys_man_alloc+0x47/0xb0 [ttm]
[ 2507.914206] ttm_bo_pipeline_gutting+0x70/0x440 [ttm]
[ 2507.914214] ? ttm_mem_io_free+0x150/0x150 [ttm]
[ 2507.914221] ? lock_is_held_type+0xe4/0x140
[ 2507.914227] ttm_bo_validate+0x2fb/0x370 [ttm]
[ 2507.914234] ? lock_acquire+0x19c/0x4b0
[ 2507.914239] ? ttm_bo_bounce_temp_buffer.constprop.0+0xf0/0xf0 [ttm]
[ 2507.914246] ? lock_acquire+0x131/0x4b0
[ 2507.914251] ? lock_is_held_type+0xe4/0x140
[ 2507.914257] i915_ttm_shrinker_release_pages+0x2bc/0x490 [i915]
[ 2507.914339] ? i915_ttm_swap_notify+0x130/0x130 [i915]
[ 2507.914429] ? i915_gem_object_release_mmap_offset+0x32/0x250 [i915]
[ 2507.914529] i915_gem_shrink+0xb14/0x1290 [i915]
[ 2507.914616] ? ___i915_gem_object_make_shrinkable+0x3e0/0x3e0 [i915]
[ 2507.914698] ? _raw_spin_unlock_irqrestore+0x2d/0x60
[ 2507.914705] ? track_intel_runtime_pm_wakeref+0x180/0x230 [i915]
[ 2507.914777] i915_gem_shrink_all+0x4b/0x70 [i915]
[ 2507.914857] i915_drop_caches_set+0x227/0x2c0 [i915]
Reported-by: Thomas Hellström
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index bafb902269de..359d8ffc6e36 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -666,6 +666,7 @@ static int
i915_drop_caches_set(void *data, u64 val)
{
struct drm_i915_private *i915 = data;
+ unsigned int flags;
int ret;
DRM_DEBUG("Dropping caches: 0x%08llx [0x%08llx]\n",
@@ -676,6 +677,7 @@ i915_drop_caches_set(void *data, u64 val)
return ret;
fs_reclaim_acquire(GFP_KERNEL);
+ flags = memalloc_noreclaim_save();
if (val & DROP_BOUND)
i915_gem_shrink(NULL, i915, LONG_MAX, NULL, I915_SHRINK_BOUND);
@@ -684,6 +686,7 @@ i915_drop_caches_set(void *data, u64 val)
if (val & DROP_SHRINK_ALL)
i915_gem_shrink_all(i915);
+ memalloc_noreclaim_restore(flags);
fs_reclaim_release(GFP_KERNEL);
if (val & DROP_RCU)
--
2.31.1
Re: [PATCH] drm/edid: Refine HDMI VSDB detect
On Mon, Dec 13, 2021 at 12:42:22PM +, Lee, Shawn C wrote: > > On Monday, December 13, 2021 8:31 PM, Ville Syrjälä wrote: > >On Sun, Dec 12, 2021 at 11:33:31PM +0800, Lee Shawn C wrote: > >> According to CEA-861-F chapter 7.5.4. It says "The VSDB shall contain > >> the > >> 3 bytes of the IEEE OUI as well as any additional payload bytes needed." > >> Now DRM driver check HDMI OUI but VSDB payload size at least five bytes. > >> That may caused some HDMI monitors' audio feature can't be enabled. > >> Because of they only have three bytes payload (OUI only) in VSDB. > > > >HDMI 1.4a says > >"Sinks shall contain an HDMI VSDB minimally containing a 2-byte Source > >Physical Address field following the 24-bit identifier. ... > > The minimum value of N (length) is 5 and the maximum value of N is 31." > > > >Do you actually have an EDID that violates that? > > > > Yes! User report when connect to HDMI port on Acer V226HQL. Audio is not > working. > But windows system did not have the same problem. We found its VSDB just have > 3 bytes > payload (OUI). Then we share this patch to user then they report audio works > properly > with this patch. Hrm. This deserves a comment then since it clearly violates the spec. Also a link to the bug if you have one would be nice to include here. > > Best regards, > Shawn > > >> > >> Cc: Ville Syrjälä > >> Cc: Adam Jackson > >> Cc: Dave Airlie > >> Signed-off-by: Lee Shawn C > >> --- > >> drivers/gpu/drm/drm_edid.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > >> index 12893e7be89b..5aa4a6bf4a13 100644 > >> --- a/drivers/gpu/drm/drm_edid.c > >> +++ b/drivers/gpu/drm/drm_edid.c > >> @@ -4205,7 +4205,7 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db) > >>if (cea_db_tag(db) != VENDOR_BLOCK) > >>return false; > >> > >> - if (cea_db_payload_len(db) < 5) > >> + if (cea_db_payload_len(db) < 3) > >>return false; > >> > >>return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI; > >> -- > >> 2.31.1 > > > >-- > >Ville Syrjälä > >Intel > > -- Ville Syrjälä Intel
RE: [PATCH] drm/edid: Refine HDMI VSDB detect
On Monday, December 13, 2021 8:31 PM, Ville Syrjälä wrote: >On Sun, Dec 12, 2021 at 11:33:31PM +0800, Lee Shawn C wrote: >> According to CEA-861-F chapter 7.5.4. It says "The VSDB shall contain >> the >> 3 bytes of the IEEE OUI as well as any additional payload bytes needed." >> Now DRM driver check HDMI OUI but VSDB payload size at least five bytes. >> That may caused some HDMI monitors' audio feature can't be enabled. >> Because of they only have three bytes payload (OUI only) in VSDB. > >HDMI 1.4a says >"Sinks shall contain an HDMI VSDB minimally containing a 2-byte Source >Physical Address field following the 24-bit identifier. ... > The minimum value of N (length) is 5 and the maximum value of N is 31." > >Do you actually have an EDID that violates that? > Yes! User report when connect to HDMI port on Acer V226HQL. Audio is not working. But windows system did not have the same problem. We found its VSDB just have 3 bytes payload (OUI). Then we share this patch to user then they report audio works properly with this patch. Best regards, Shawn >> >> Cc: Ville Syrjälä >> Cc: Adam Jackson >> Cc: Dave Airlie >> Signed-off-by: Lee Shawn C >> --- >> drivers/gpu/drm/drm_edid.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c >> index 12893e7be89b..5aa4a6bf4a13 100644 >> --- a/drivers/gpu/drm/drm_edid.c >> +++ b/drivers/gpu/drm/drm_edid.c >> @@ -4205,7 +4205,7 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db) >> if (cea_db_tag(db) != VENDOR_BLOCK) >> return false; >> >> -if (cea_db_payload_len(db) < 5) >> +if (cea_db_payload_len(db) < 3) >> return false; >> >> return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI; >> -- >> 2.31.1 > >-- >Ville Syrjälä >Intel >
Re: [PATCH 1/7] drm/i915: Replace kmap() with kmap_local_page()
On Fri, Dec 10, 2021 at 03:23:58PM -0800, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> kmap() is being deprecated and these usages are all local to the thread
> so there is no reason kmap_local_page() can't be used.
>
> Replace kmap() calls with kmap_local_page().
>
> Signed-off-by: Ira Weiny
> ---
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 ++--
> drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--
> drivers/gpu/drm/i915/gt/shmem_utils.c | 4 ++--
> drivers/gpu/drm/i915/i915_gem.c| 8
> drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++--
> 6 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index d77da59fae04..fa8b820e14aa 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -597,9 +597,9 @@ i915_gem_object_create_shmem_from_data(struct
> drm_i915_private *dev_priv,
> if (err < 0)
> goto fail;
>
> - vaddr = kmap(page);
> + vaddr = kmap_local_page(page);
> memcpy(vaddr, data, len);
> - kunmap(page);
> + kunmap_local(vaddr);
>
> err = pagecache_write_end(file, file->f_mapping,
> offset, len, len,
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> index 6d30cdfa80f3..e59e1725e29d 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> @@ -144,7 +144,7 @@ static int check_partial_mapping(struct
> drm_i915_gem_object *obj,
> intel_gt_flush_ggtt_writes(_i915(obj->base.dev)->gt);
>
> p = i915_gem_object_get_page(obj, offset >> PAGE_SHIFT);
> - cpu = kmap(p) + offset_in_page(offset);
> + cpu = kmap_local_page(p) + offset_in_page(offset);
Does kunmap_local() do some magic to make it work even when you
don't pass in the same value you got from kmap_local_page()?
> drm_clflush_virt_range(cpu, sizeof(*cpu));
> if (*cpu != (u32)page) {
> pr_err("Partial view for %lu [%u] (offset=%llu, size=%u [%llu,
> row size %u], fence=%d, tiling=%d, stride=%d) misalignment, expected write to
> page (%llu + %u [0x%llx]) of 0x%x, found 0x%x\n",
> @@ -162,7 +162,7 @@ static int check_partial_mapping(struct
> drm_i915_gem_object *obj,
> }
> *cpu = 0;
> drm_clflush_virt_range(cpu, sizeof(*cpu));
> - kunmap(p);
> + kunmap_local(cpu);
>
> out:
> __i915_vma_put(vma);
--
Ville Syrjälä
Intel
Re: [PATCH v3 0/7] drm: exynos: dsi: Convert drm bridge
Hi Marek,
On Mon, Dec 13, 2021 at 5:42 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 13.12.2021 13:08, Jagan Teki wrote:
> > On Mon, Dec 13, 2021 at 5:34 PM Marek Szyprowski
> > wrote:
> >> On 12.12.2021 19:14, Jagan Teki wrote:
> >>> Updated series about drm bridge conversion of exynos dsi.
> >>>
> >>> Patch 1: panel checker
> >>>
> >>> Patch 2: panel_bridge API
> >>>
> >>> Patch 3: Bridge conversion
> >>>
> >>> Patch 4: pree_enable, post_disable
> >>>
> >>> Patch 5: Atomic functions
> >>>
> >>> Patch 6: atomic_set
> >>>
> >>> Patch 7: DSI init in enable
> >>>
> >>> [1]
> >>> https://patchwork.kernel.org/project/dri-devel/cover/20211210191922.2367979-1-ja...@amarulasolutions.com/
> >>>
> >>> Any inputs?
> >> I've checked this patchset on Exynos based Trats2 board (the one with
> >> simplest display pipeline: Exynos FIMD -> Exynos DSI -> s6e8aa0 DSI
> >> panel). DRM stops working after the 2nd patch ("[PATCH v3 2/7] drm:
> >> exynos: dsi: Use drm panel_bridge API"):
> >>
> >> # dmesg | grep drm
> >> [2.511893] [drm] Exynos DRM: using 11c0.fimd device for DMA
> >> mapping operations
> >> [2.518653] exynos-drm exynos-drm: bound 11c0.fimd (ops
> >> fimd_component_ops)
> >> [2.535699] exynos-drm exynos-drm: bound 11c8.dsi (ops
> >> exynos_dsi_component_ops)
> >> [2.543912] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
> >> [2.556107] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
> >> minor 0
> >> [2.573212] exynos-dsi 11c8.dsi: [drm:exynos_dsi_host_attach]
> >> *ERROR* failed to find the bridge: -19
> > Look like you have missed to apply the Child lookup patch. is it so?
> >
> > Let me send it, I will CC you as well. And I will also send tc358764
> > panel_bridge conversion.
>
> The above log is from Trats2 board, which uses only the s6e8aa0 DSI
> panel. I've also checked the Arndale board, which has tc358764 bridge
> and it also doesn't work. Which patches I have to apply for the tests?
[PATCH v2] drm: of: Lookup if child node has panel or bridge
[PATCH] drm: bridge: tc358764: Use drm panel_bridge API
Thanks,
Jagan.
Re: [PATCH] drm/edid: Refine HDMI VSDB detect
On Sun, Dec 12, 2021 at 11:33:31PM +0800, Lee Shawn C wrote: > According to CEA-861-F chapter 7.5.4. It says "The VSDB shall contain the > 3 bytes of the IEEE OUI as well as any additional payload bytes needed." > Now DRM driver check HDMI OUI but VSDB payload size at least five bytes. > That may caused some HDMI monitors' audio feature can't be enabled. > Because of they only have three bytes payload (OUI only) in VSDB. HDMI 1.4a says "Sinks shall contain an HDMI VSDB minimally containing a 2-byte Source Physical Address field following the 24-bit identifier. ... The minimum value of N (length) is 5 and the maximum value of N is 31." Do you actually have an EDID that violates that? > > Cc: Ville Syrjälä > Cc: Adam Jackson > Cc: Dave Airlie > Signed-off-by: Lee Shawn C > --- > drivers/gpu/drm/drm_edid.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 12893e7be89b..5aa4a6bf4a13 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -4205,7 +4205,7 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db) > if (cea_db_tag(db) != VENDOR_BLOCK) > return false; > > - if (cea_db_payload_len(db) < 5) > + if (cea_db_payload_len(db) < 3) > return false; > > return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI; > -- > 2.31.1 -- Ville Syrjälä Intel
Re: [PATCH v3 0/7] drm: exynos: dsi: Convert drm bridge
Hi Jagan,
On 13.12.2021 13:08, Jagan Teki wrote:
> On Mon, Dec 13, 2021 at 5:34 PM Marek Szyprowski
> wrote:
>> On 12.12.2021 19:14, Jagan Teki wrote:
>>> Updated series about drm bridge conversion of exynos dsi.
>>>
>>> Patch 1: panel checker
>>>
>>> Patch 2: panel_bridge API
>>>
>>> Patch 3: Bridge conversion
>>>
>>> Patch 4: pree_enable, post_disable
>>>
>>> Patch 5: Atomic functions
>>>
>>> Patch 6: atomic_set
>>>
>>> Patch 7: DSI init in enable
>>>
>>> [1]
>>> https://patchwork.kernel.org/project/dri-devel/cover/20211210191922.2367979-1-ja...@amarulasolutions.com/
>>>
>>> Any inputs?
>> I've checked this patchset on Exynos based Trats2 board (the one with
>> simplest display pipeline: Exynos FIMD -> Exynos DSI -> s6e8aa0 DSI
>> panel). DRM stops working after the 2nd patch ("[PATCH v3 2/7] drm:
>> exynos: dsi: Use drm panel_bridge API"):
>>
>> # dmesg | grep drm
>> [2.511893] [drm] Exynos DRM: using 11c0.fimd device for DMA
>> mapping operations
>> [2.518653] exynos-drm exynos-drm: bound 11c0.fimd (ops
>> fimd_component_ops)
>> [2.535699] exynos-drm exynos-drm: bound 11c8.dsi (ops
>> exynos_dsi_component_ops)
>> [2.543912] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
>> [2.556107] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
>> minor 0
>> [2.573212] exynos-dsi 11c8.dsi: [drm:exynos_dsi_host_attach]
>> *ERROR* failed to find the bridge: -19
> Look like you have missed to apply the Child lookup patch. is it so?
>
> Let me send it, I will CC you as well. And I will also send tc358764
> panel_bridge conversion.
The above log is from Trats2 board, which uses only the s6e8aa0 DSI
panel. I've also checked the Arndale board, which has tc358764 bridge
and it also doesn't work. Which patches I have to apply for the tests?
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
Re: [PATCH v3 0/7] drm: exynos: dsi: Convert drm bridge
Hi Marek,
On Mon, Dec 13, 2021 at 5:34 PM Marek Szyprowski
wrote:
>
> Dear Jagan,
>
> On 12.12.2021 19:14, Jagan Teki wrote:
> > Updated series about drm bridge conversion of exynos dsi.
> >
> > Patch 1: panel checker
> >
> > Patch 2: panel_bridge API
> >
> > Patch 3: Bridge conversion
> >
> > Patch 4: pree_enable, post_disable
> >
> > Patch 5: Atomic functions
> >
> > Patch 6: atomic_set
> >
> > Patch 7: DSI init in enable
> >
> > [1]
> > https://patchwork.kernel.org/project/dri-devel/cover/20211210191922.2367979-1-ja...@amarulasolutions.com/
> >
> > Any inputs?
>
> I've checked this patchset on Exynos based Trats2 board (the one with
> simplest display pipeline: Exynos FIMD -> Exynos DSI -> s6e8aa0 DSI
> panel). DRM stops working after the 2nd patch ("[PATCH v3 2/7] drm:
> exynos: dsi: Use drm panel_bridge API"):
>
> # dmesg | grep drm
> [2.511893] [drm] Exynos DRM: using 11c0.fimd device for DMA
> mapping operations
> [2.518653] exynos-drm exynos-drm: bound 11c0.fimd (ops
> fimd_component_ops)
> [2.535699] exynos-drm exynos-drm: bound 11c8.dsi (ops
> exynos_dsi_component_ops)
> [2.543912] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
> [2.556107] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
> minor 0
> [2.573212] exynos-dsi 11c8.dsi: [drm:exynos_dsi_host_attach]
> *ERROR* failed to find the bridge: -19
Look like you have missed to apply the Child lookup patch. is it so?
Let me send it, I will CC you as well. And I will also send tc358764
panel_bridge conversion.
Thanks,
Jagan.
Re: RPI 7" display touch controller
On Fri, 10 Dec 2021 at 22:40, Tim Harvey wrote:
>
> On Fri, Dec 10, 2021 at 11:29 AM Tim Harvey wrote:
> >
> > On Fri, Dec 10, 2021 at 10:41 AM Dave Stevenson
> > wrote:
> > >
> > > On Fri, 10 Dec 2021 at 18:20, Tim Harvey wrote:
> > > >
> > > > On Thu, Nov 18, 2021 at 12:52 PM Tim Harvey
> > > > wrote:
> > > > >
> > > > > On Thu, Nov 18, 2021 at 10:30 AM Dave Stevenson
> > > > > wrote:
> > > > > >
> > > > > > On Thu, 18 Nov 2021 at 17:36, Tim Harvey
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Tim
> > > > > > > >
> > > > > > > > On Thu, 18 Nov 2021 at 01:26, Tim Harvey
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Greetings,
> > > > > > > > >
> > > > > > > > > I'm trying to get a RPI 7" touchscreen display working on an
> > > > > > > > > IMX8MM
> > > > > > > > > board and while I've been able to get the MIPI DSI display and
> > > > > > > > > backlight working I still can't seem to figure out the touch
> > > > > > > > > controller.
> > > > > > > > >
> > > > > > > > > It's supposed to have an FT5406 controller on it without an
> > > > > > > > > interrupt
> > > > > > > > > so I added polling support
> > > > > > > > > drivers/input/touchscreen/edt-ft5x06.c
> > > > > > > > > which I was able to verify using another touchscreen with that
> > > > > > > > > controller but when reading data from the FT5406 on the RPI
> > > > > > > > > controller
> > > > > > > > > the data does not make sense.
> > > > > > > > >
> > > > > > > > > These panels appear to route the I2C from the FT5406 to a
> > > > > > > > > STM32F103
> > > > > > > > > MPU that then provides a different I2C slave interface to the
> > > > > > > > > 15pin
> > > > > > > > > connector that I'm connected to. On that I2C interface I see
> > > > > > > > > an i2c
> > > > > > > > > slave at 0x45 which is managed by the regulator driver Marek
> > > > > > > > > wrote
> > > > > > > > > (drivers/regulator/rpi-panel-attiny-regulator.c) and there is
> > > > > > > > > also an
> > > > > > > > > i2c slave at 0x38 which I assumed was the FT5406 but I
> > > > > > > > > believe the MPU
> > > > > > > > > is perhaps obfuscating that touch data.
> > > > > > > > >
> > > > > > > > > Anyone have any ideas on how to make that touch controller
> > > > > > > > > useful?
> > > > > > > >
> > > > > > > > There should be nothing unusual. 0x38 is the EDT touch
> > > > > > > > controller.
> > > > > > > > Starting with the Raspberry Pi OS Bullseye release, we're now
> > > > > > > > using
> > > > > > > > the panel directly from DRM rather than through the firmware.
> > > > > > > > That's
> > > > > > > > based on the branch at
> > > > > > > > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/
> > > > > > > >
> > > > > > >
> > > > > > > Dave,
> > > > > > >
> > > > > > > That sounds like the driver that made it into mainline with Eric's
> > > > > > > commit 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi
> > > > > > > 7"
> > > > > > > Touchscreen."). I looked there but that driver just deals with
> > > > > > > the DSI
> > > > > > > and not with touch.
> > > > > >
> > > > > > No, we've reverted away from that driver as it exposes no regulator
> > > > > > framework either, so again the touch element loses power.
> > > > > >
> > > > > > > > I also added polling support to edt-ft5x04.c.
> > > > > > > > For DT, it uses a combination of the overlays vc4-kms-v3d,
> > > > > > > > vc4-kms-dsi-7inch, and that includes edt-ft5406.dtsi, all of
> > > > > > > > which are
> > > > > > > > in /arch/arm/boot/dts/overlays
> > > > > > >
> > > > > > > It doesn't look like you ever submitted your edt-ft5x04 polling
> > > > > > > mode
> > > > > > > support upstream. I saw another series to add polling support
> > > > > > > submitted by Nicolas back in 2019 but was never followed up on
> > > > > > > (https://patchwork.kernel.org/project/linux-input/list/?series=112187=both).
> > > > > >
> > > > > > No I haven't as it's been crazy trying to get this lot to work under
> > > > > > KMS at all over the last couple of months.
> > > > > >
> > > > > > > I have updated Nicolas' patch with the changes requested and am
> > > > > > > happy
> > > > > > > to submit it upstream. The benefit of his patch is that it uses a
> > > > > > > dt
> > > > > > > binding for the polling interval. I'm happy to submit this
> > > > > > > upstream.
> > > > > >
> > > > > > I hadn't seen Nicolas' patches, hence implementing it myself.
> > > > > >
> > > > > > If you've implemented the requested changes, could you check that
> > > > > > the
> > > > > > polling rate is as expected? We were seeing that the input framework
> > > > > > wasn't delivering the requested poll rate when CONFIG_HZ=100 is
> > > > > > defined in the config. I must confess that I haven't checked it on
> > > > > > my
> > > > > > current patch, but it was on my list of things to do.
> > > > > > There was a report that
Re: [PATCH v3 0/7] drm: exynos: dsi: Convert drm bridge
Dear Jagan,
On 12.12.2021 19:14, Jagan Teki wrote:
> Updated series about drm bridge conversion of exynos dsi.
>
> Patch 1: panel checker
>
> Patch 2: panel_bridge API
>
> Patch 3: Bridge conversion
>
> Patch 4: pree_enable, post_disable
>
> Patch 5: Atomic functions
>
> Patch 6: atomic_set
>
> Patch 7: DSI init in enable
>
> [1]
> https://patchwork.kernel.org/project/dri-devel/cover/20211210191922.2367979-1-ja...@amarulasolutions.com/
>
> Any inputs?
I've checked this patchset on Exynos based Trats2 board (the one with
simplest display pipeline: Exynos FIMD -> Exynos DSI -> s6e8aa0 DSI
panel). DRM stops working after the 2nd patch ("[PATCH v3 2/7] drm:
exynos: dsi: Use drm panel_bridge API"):
# dmesg | grep drm
[ 2.511893] [drm] Exynos DRM: using 11c0.fimd device for DMA
mapping operations
[ 2.518653] exynos-drm exynos-drm: bound 11c0.fimd (ops
fimd_component_ops)
[ 2.535699] exynos-drm exynos-drm: bound 11c8.dsi (ops
exynos_dsi_component_ops)
[ 2.543912] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
[ 2.556107] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
minor 0
[ 2.573212] exynos-dsi 11c8.dsi: [drm:exynos_dsi_host_attach]
*ERROR* failed to find the bridge: -19
[ 2.653553] [drm] Initialized lima 1.1.0 20191231 for 1300.gpu on
minor 1
# ./modetest -c -Mexynos
Connectors:
id encoder status name size (mm) modes encoders
Applying the whole patchset doesn't fix anything.
> Jagan.
>
> Jagan Teki (7):
>drm: exynos: dsi: Check panel for panel helpers
>drm: exynos: dsi: Use drm panel_bridge API
>drm: exynos: dsi: Convert to bridge driver
>drm: exynos: dsi: Separate pre_enable, post_disable code
>drm: exynos: dsi: Switch to atomic funcs
>drm: exynos: dsi: Get the mode from bridge
>drm: exynos: dsi: Move DSI init in bridge enable
>
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 240
> 1 file changed, 75 insertions(+), 165 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
Re: [PATCH v3 1/3] of: Move simple-framebuffer device handling from simplefb to of
On 13/12/2021 20.30, Javier Martinez Canillas wrote: On Mon, Dec 13, 2021 at 11:46 AM Hector Martin wrote: On 13/12/2021 17.44, Javier Martinez Canillas wrote: Hello Hector, On Sun, Dec 12, 2021 at 7:24 AM Hector Martin wrote: This code is required for both simplefb and simpledrm, so let's move it into the OF core instead of having it as an ad-hoc initcall in the drivers. Acked-by: Thomas Zimmermann Signed-off-by: Hector Martin --- drivers/of/platform.c | 4 drivers/video/fbdev/simplefb.c | 21 + 2 files changed, 5 insertions(+), 20 deletions(-) This is indeed a much better approach than what I suggested. I just have one comment. diff --git a/drivers/of/platform.c b/drivers/of/platform.c index b3faf89744aa..793350028906 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -540,6 +540,10 @@ static int __init of_platform_default_populate_init(void) of_node_put(node); } + node = of_get_compatible_child(of_chosen, "simple-framebuffer"); You have to check if the node variable is NULL here. + of_platform_device_create(node, NULL, NULL); Otherwise this could lead to a NULL pointer dereference if debug output is enabled (the node->full_name is printed). Where is it printed? I thought I might need a NULL check, but this code Sorry, I misread of_amba_device_create() as of_platform_device_create(), which uses the "%pOF" printk format specifier [0] to print the node's full name as a debug output [1]. [0]: https://elixir.bootlin.com/linux/v5.16-rc5/source/Documentation/core-api/printk-formats.rst#L462 [1]: https://elixir.bootlin.com/linux/v5.16-rc5/source/drivers/of/platform.c#L233 was suggested verbatim by Rob in v2 without the NULL check and digging through I found that the NULL codepath is safe. You are right that passing NULL is a safe code path for now due the of_device_is_available(node) check, but that seems fragile to me since just adding a similar debug output to of_platform_device_create() could trigger the NULL pointer dereference. Since Rob is the DT maintainer, I'm going to defer to his opinion on this one :-) -- Hector Martin (mar...@marcan.st) Public Key: https://mrcn.st/pub
Re: [PATCH v3 1/3] of: Move simple-framebuffer device handling from simplefb to of
On Mon, Dec 13, 2021 at 11:46 AM Hector Martin wrote: > > On 13/12/2021 17.44, Javier Martinez Canillas wrote: > > Hello Hector, > > > > On Sun, Dec 12, 2021 at 7:24 AM Hector Martin wrote: > >> > >> This code is required for both simplefb and simpledrm, so let's move it > >> into the OF core instead of having it as an ad-hoc initcall in the > >> drivers. > >> > >> Acked-by: Thomas Zimmermann > >> Signed-off-by: Hector Martin > >> --- > >> drivers/of/platform.c | 4 > >> drivers/video/fbdev/simplefb.c | 21 + > >> 2 files changed, 5 insertions(+), 20 deletions(-) > >> > > > > This is indeed a much better approach than what I suggested. I just > > have one comment. > > > >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c > >> index b3faf89744aa..793350028906 100644 > >> --- a/drivers/of/platform.c > >> +++ b/drivers/of/platform.c > >> @@ -540,6 +540,10 @@ static int __init > >> of_platform_default_populate_init(void) > >> of_node_put(node); > >> } > >> > >> + node = of_get_compatible_child(of_chosen, "simple-framebuffer"); > > > > You have to check if the node variable is NULL here. > > > >> + of_platform_device_create(node, NULL, NULL); > > > > Otherwise this could lead to a NULL pointer dereference if debug > > output is enabled (the node->full_name is printed). > > Where is it printed? I thought I might need a NULL check, but this code Sorry, I misread of_amba_device_create() as of_platform_device_create(), which uses the "%pOF" printk format specifier [0] to print the node's full name as a debug output [1]. [0]: https://elixir.bootlin.com/linux/v5.16-rc5/source/Documentation/core-api/printk-formats.rst#L462 [1]: https://elixir.bootlin.com/linux/v5.16-rc5/source/drivers/of/platform.c#L233 > was suggested verbatim by Rob in v2 without the NULL check and digging > through I found that the NULL codepath is safe. > You are right that passing NULL is a safe code path for now due the of_device_is_available(node) check, but that seems fragile to me since just adding a similar debug output to of_platform_device_create() could trigger the NULL pointer dereference. Best regards, Javier
[Bug 211807] [drm:drm_dp_mst_dpcd_read] *ERROR* mstb 000000004e6288dd port 3: DPCD read on addr 0x60 for 1 bytes NAKed
https://bugzilla.kernel.org/show_bug.cgi?id=211807 --- Comment #19 from Renaud R. (kernel...@iopsthecloud.com) --- (In reply to Renaud R. from comment #18) > My setup: > * Latitude E5570 via dock DisplayPort > * Kernel: https://bugzilla.kernel.org Kernel: 5.15.7-051507-generic #202112080459 SMP -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 211807] [drm:drm_dp_mst_dpcd_read] *ERROR* mstb 000000004e6288dd port 3: DPCD read on addr 0x60 for 1 bytes NAKed
https://bugzilla.kernel.org/show_bug.cgi?id=211807 Renaud R. (kernel...@iopsthecloud.com) changed: What|Removed |Added CC||kernel...@iopsthecloud.com --- Comment #18 from Renaud R. (kernel...@iopsthecloud.com) --- My setup: * Latitude E5570 via dock DisplayPort * Kernel: https://bugzilla.kernel.org I randomly have blackscreen and I see in my logs (dmesg): * i915 :00:02.0: [drm] *ERROR* mstb adcef9b1 port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed * [38971.851918] i915 :00:02.0: [drm] *ERROR* mstb adcef9b1 port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed My laptop was reinstall from and old ubuntu 18.04 to 20.04. I can't remember the kernel used in Unbuntu 18.04 but I didn't have this issue. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support
2021年12月10日(金) 22:29 Christian König : > > Am 10.12.21 um 14:26 schrieb Jason Gunthorpe: > > On Fri, Dec 10, 2021 at 01:47:37PM +0100, Christian König wrote: > >> Am 10.12.21 um 13:42 schrieb Jason Gunthorpe: > >>> On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote: > Hi Jason, > Thank you for replying. > > 2021年12月8日(水) 2:14 Jason Gunthorpe : > > On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: > >> Hi maintainers, > >> > >> Could you please review this patch series? > > Why is it RFC? > > > > I'm confused why this is useful? > > > > This can't do copy from MMIO memory, so it shouldn't be compatible > > with things like Gaudi - does something prevent this? > I think if an export of the dma-buf supports vmap, CPU is able to access > the > mmio memory. > > Is it wrong? If this is wrong, there is no advantages this changes.. > >>> I don't know what the dmabuf folks did, but yes, it is wrong. > >>> > >>> IOMEM must be touched using only special accessors, some platforms > >>> crash if you don't do this. Even x86 will crash if you touch it with > >>> something like an XMM optimized memcpy. > >>> > >>> Christian? If the vmap succeeds what rules must the caller use to > >>> access the memory? > >> See dma-buf-map.h and especially struct dma_buf_map. > >> > >> MMIO memory is perfectly supported here and actually the most common case. > > Okay that looks sane, but this rxe RFC seems to ignore this > > completely. It stuffs the vaddr directly into a umem which goes to all > > manner of places in the driver. > > > > ?? > > Well, yes that can go boom pretty quickly. Sorry, I was wrong. The dma_buf_map treats both iomem and vaddr region, but this RFC only supports vaddr. Advantage of the partial support is we can use the vaddr dma-buf in RXE without changing a rxe data copy implementation. An example of a dma-buf pointing to a vaddr is some gpu drivers use RAM for VRAM and we can get dma-buf for the region that indicates vaddr regions. Specifically, the gpu driver using gpu/drm/drm_gem_cma_helper.c is one such example. > Not sure what they want to use this for. I'd like to use RDMA with RXE for that memory region. Best, Shunsuke > Christian. > > > > > Jason >
Re: [PATCH 07/18] dt-bindings: display: rockchip: dw-hdmi: Allow "ref" as clock name
On Sun, Dec 12, 2021 at 11:09:24PM +0100, Heiko Stuebner wrote: > Am Mittwoch, 8. Dezember 2021, 16:12:19 CET schrieb Sascha Hauer: > > "vpll" is a misnomer. A clock input to a device should be named after > > the usage in the device, not after the clock that drives it. On the > > rk3568 the same clock is driven by the HPLL. > > To fix that, this patch renames the vpll clock to ref clock. The clock > > name "vpll" is left for compatibility to old device trees. > > Can't we just say that the binding only takes the "ref" name, but > the code still allows "vpll". > > I think I remember Rob suggesting something similar in the past. > > I don't think that we need to keep the binding(-validation) > compatible with old devicetrees, but the kernel itself should stay > compatible. Sounds reasonable. I'll also add a patch changing the in-tree users next round. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v3 1/3] of: Move simple-framebuffer device handling from simplefb to of
On 13/12/2021 17.44, Javier Martinez Canillas wrote:
Hello Hector,
On Sun, Dec 12, 2021 at 7:24 AM Hector Martin wrote:
This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.
Acked-by: Thomas Zimmermann
Signed-off-by: Hector Martin
---
drivers/of/platform.c | 4
drivers/video/fbdev/simplefb.c | 21 +
2 files changed, 5 insertions(+), 20 deletions(-)
This is indeed a much better approach than what I suggested. I just
have one comment.
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b3faf89744aa..793350028906 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -540,6 +540,10 @@ static int __init of_platform_default_populate_init(void)
of_node_put(node);
}
+ node = of_get_compatible_child(of_chosen, "simple-framebuffer");
You have to check if the node variable is NULL here.
+ of_platform_device_create(node, NULL, NULL);
Otherwise this could lead to a NULL pointer dereference if debug
output is enabled (the node->full_name is printed).
Where is it printed? I thought I might need a NULL check, but this code
was suggested verbatim by Rob in v2 without the NULL check and digging
through I found that the NULL codepath is safe.
of_platform_device_create calls of_platform_device_create_pdata
directly, and:
static struct platform_device *of_platform_device_create_pdata(
struct device_node *np,
const char *bus_id,
void *platform_data,
struct device *parent)
{
struct platform_device *dev;
if (!of_device_is_available(np) ||
of_node_test_and_set_flag(np, OF_POPULATED))
return NULL;
of_device_is_available takes a global spinlock and then calls
__of_device_is_available, and that does:
static bool __of_device_is_available(const struct device_node *device)
{
const char *status;
int statlen;
if (!device)
return false;
... so I don't see how this can do anything but immediately return false
if node is NULL.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
Re: [PATCH 2/2] drm/imx/dcss: select DRM_KMS_HELPER
Hi Lucas, On Sat, Dec 11, 2021 at 11:18:48PM +0100, Lucas Stach wrote: > DCSS can not be built without the DRM_KMS_HELPERs being available. > Select this symbol to disallow this invalid configuration. > > Signed-off-by: Lucas Stach Reviewed-by: Laurentiu Palcu Can you also push these 2 patches to drm-misc, when you have some time? Thanks, laurentiu > --- > drivers/gpu/drm/imx/dcss/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/imx/dcss/Kconfig > b/drivers/gpu/drm/imx/dcss/Kconfig > index 2b17a964ff05..4c2158dc5540 100644 > --- a/drivers/gpu/drm/imx/dcss/Kconfig > +++ b/drivers/gpu/drm/imx/dcss/Kconfig > @@ -1,6 +1,7 @@ > config DRM_IMX_DCSS > tristate "i.MX8MQ DCSS" > select IMX_IRQSTEER > + select DRM_KMS_HELPER > select DRM_KMS_CMA_HELPER > select VIDEOMODE_HELPERS > depends on DRM && ARCH_MXC && ARM64 > -- > 2.31.1 >
Re: [PATCH 1/2] drm/imx/dcss: add missing drm_bridge.h include
Hi Lucas, On Sat, Dec 11, 2021 at 11:18:47PM +0100, Lucas Stach wrote: > This has been pulled in via some other include before, which is no > longer true. > > Signed-off-by: Lucas Stach > --- Reviewed-by: Laurentiu Palcu > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c > b/drivers/gpu/drm/imx/dcss/dcss-kms.c > index 9b84df34a6a1..96a9517021fe 100644 > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > @@ -5,6 +5,7 @@ > > #include > #include > +#include > #include > #include > #include > -- > 2.31.1 >
Re: [PATCH] drm: simpledrm: fix wrong unit with pixel clock
Hi
Am 12.12.21 um 17:06 schrieb Alejandro Concepcion-Rodriguez:
Pixel clock has to be set in kHz.
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Signed-off-by: Alejandro Concepcion-Rodriguez
Applied to drm-misc-fixes. Thanks.
Best regards
Thomas
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2f15b9aa..562bf09f9140 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -459,7 +459,7 @@ static struct drm_display_mode simpledrm_mode(unsigned int
width,
{
struct drm_display_mode mode = { SIMPLEDRM_MODE(width, height) };
- mode.clock = 60 /* Hz */ * mode.hdisplay * mode.vdisplay;
+ mode.clock = mode.hdisplay * mode.vdisplay * 60 / 1000 /* kHz */;
drm_mode_set_name();
return mode;
--
2.25.1
--
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] drm/mediatek: hdmi: Perform NULL pointer check for mtk_hdmi_conf
Il 28/10/21 09:43, AngeloGioacchino Del Regno ha scritto:
In commit 41ca9caaae0b ("drm/mediatek: hdmi: Add check for CEA modes only")
a check for CEA modes was added to function mtk_hdmi_bridge_mode_valid()
in order to address possible issues on MT8167; moreover, with commit
c91026a938c2 ("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode
clock")
another similar check was introduced.
Unfortunately though, at the time of writing, MT8173 does not provide
any mtk_hdmi_conf structure and this is crashing the kernel with NULL
pointer upon entering mtk_hdmi_bridge_mode_valid(), which happens as
soon as a HDMI cable gets plugged in.
To fix this regression, add a NULL pointer check for hdmi->conf in the
said function, restoring HDMI functionality and avoiding NULL pointer
kernel panics.
Fixes: 41ca9caaae0b ("drm/mediatek: hdmi: Add check for CEA modes only")
Fixes: c91026a938c2 ("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode
clock")
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 5838c44cbf6f..3196189429bc 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1224,12 +1224,14 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge
*bridge,
return MODE_BAD;
}
- if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
- return MODE_BAD;
+ if (hdmi->conf) {
+ if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
+ return MODE_BAD;
- if (hdmi->conf->max_mode_clock &&
- mode->clock > hdmi->conf->max_mode_clock)
- return MODE_CLOCK_HIGH;
+ if (hdmi->conf->max_mode_clock &&
+ mode->clock > hdmi->conf->max_mode_clock)
+ return MODE_CLOCK_HIGH;
+ }
if (mode->clock < 27000)
return MODE_CLOCK_LOW;
Hello, friendly ping!
Can I please get a review (or merge) of this commit?
This is an important fix for a null pointer KP and restores HDMI functionality.
Thanks,
- Angelo
Re: [Intel-gfx] [PATCH 2/3] drm/dp: Move DP declarations into separate header file
On Mon, 13 Dec 2021, Thomas Zimmermann wrote:
> Split the DP declarations from other helpers before moving the
> DP functions into a separate module.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_crtc_helper_internal.h | 27 -
> drivers/gpu/drm/drm_dp_aux_dev.c | 2 +-
> drivers/gpu/drm/drm_dp_helper.c| 2 +-
> drivers/gpu/drm/drm_dp_helper_internal.h | 28 ++
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> drivers/gpu/drm/drm_kms_helper_common.c| 1 +
> 6 files changed, 32 insertions(+), 30 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_dp_helper_internal.h
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
> b/drivers/gpu/drm/drm_crtc_helper_internal.h
> index 61e09f8a8d0f..28e04e750130 100644
> --- a/drivers/gpu/drm/drm_crtc_helper_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
> @@ -28,36 +28,9 @@
>
> #include
> #include
> -#include
> #include
> #include
>
> -/* drm_dp_aux_dev.c */
> -#ifdef CONFIG_DRM_DP_AUX_CHARDEV
> -int drm_dp_aux_dev_init(void);
> -void drm_dp_aux_dev_exit(void);
> -int drm_dp_aux_register_devnode(struct drm_dp_aux *aux);
> -void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux);
> -#else
> -static inline int drm_dp_aux_dev_init(void)
> -{
> - return 0;
> -}
> -
> -static inline void drm_dp_aux_dev_exit(void)
> -{
> -}
> -
> -static inline int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
> -{
> - return 0;
> -}
> -
> -static inline void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
> -{
> -}
> -#endif
> -
> /* drm_probe_helper.c */
> enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
>const struct drm_display_mode *mode);
> diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c
> b/drivers/gpu/drm/drm_dp_aux_dev.c
> index 06b374cae956..0618dfe16660 100644
> --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> @@ -40,7 +40,7 @@
> #include
> #include
>
> -#include "drm_crtc_helper_internal.h"
> +#include "drm_dp_helper_internal.h"
>
> struct drm_dp_aux_dev {
> unsigned index;
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 23f9073bc473..e995a0262ed7 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -35,7 +35,7 @@
> #include
> #include
>
> -#include "drm_crtc_helper_internal.h"
> +#include "drm_dp_helper_internal.h"
>
> struct dp_aux_backlight {
> struct backlight_device *base;
> diff --git a/drivers/gpu/drm/drm_dp_helper_internal.h
> b/drivers/gpu/drm/drm_dp_helper_internal.h
> new file mode 100644
> index ..5c9f8bb0c99a
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_helper_internal.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +#include
Please don't include other headers if you can avoid them by using
forward declarations.
BR,
Jani.
> +
> +#ifdef CONFIG_DRM_DP_AUX_CHARDEV
> +int drm_dp_aux_dev_init(void);
> +void drm_dp_aux_dev_exit(void);
> +int drm_dp_aux_register_devnode(struct drm_dp_aux *aux);
> +void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux);
> +#else
> +static inline int drm_dp_aux_dev_init(void)
> +{
> + return 0;
> +}
> +
> +static inline void drm_dp_aux_dev_exit(void)
> +{
> +}
> +
> +static inline int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
> +{
> + return 0;
> +}
> +
> +static inline void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
> +{
> +}
> +#endif
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 7f0ff96261cf..9f7b0b606924 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -45,7 +45,7 @@
> #include
> #include
>
> -#include "drm_crtc_helper_internal.h"
> +#include "drm_dp_helper_internal.h"
> #include "drm_dp_mst_topology_internal.h"
>
> /**
> diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
> b/drivers/gpu/drm/drm_kms_helper_common.c
> index 47e92400548d..88260d26409c 100644
> --- a/drivers/gpu/drm/drm_kms_helper_common.c
> +++ b/drivers/gpu/drm/drm_kms_helper_common.c
> @@ -29,6 +29,7 @@
>
> #include
>
> +#include "drm_dp_helper_internal.h"
> #include "drm_crtc_helper_internal.h"
>
> MODULE_AUTHOR("David Airlie, Jesse Barnes");
--
Jani Nikula, Intel Open Source Graphics Center
