[PATCH] drm/mcde: dsi: Add of_node_put() before return
Fix following coccicheck warning:
./drivers/gpu/drm/mcde/mcde_dsi.c:1104:1-33: WARNING: Function
for_each_available_child_of_node should have of_node_put() before return
Early exits from for_each_available_child_of_node should decrement the
node reference counter.
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/mcde/mcde_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 5651734ce977..9f9ac8699310 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -,6 +,7 @@ static int mcde_dsi_bind(struct device *dev, struct
device *master,
bridge = of_drm_find_bridge(child);
if (!bridge) {
dev_err(dev, "failed to find bridge\n");
+ of_node_put(child);
return -EINVAL;
}
}
--
2.20.1
Re: [PATCH 0/6] drm/i915: Failsafe migration blits
Hi, Dave, On 10/14/21 03:50, Dave Airlie wrote: On Fri, 8 Oct 2021 at 23:36, Thomas Hellström wrote: This patch series introduces failsafe migration blits. The reason for this seemingly strange concept is that if the initial clearing or readback of LMEM fails for some reason, and we then set up either GPU- or CPU ptes to the allocated LMEM, we can expose old contents from other clients. Can we enumerate "for some reason" here? This feels like "security" with no defined threat model. Maybe if the cover letter contains more details on the threat model it would make more sense. TBH, I'd be quite happy if we could find a way to skip this series (or even a reworked version) completely. Assuming that the migration request setup code is bug-free enough to not never cause an engine reset, there are at least two ways I can see the migration fail: 1) The migration fence we will be depending on when fully async (ttm->moving) may signal with error after the following: malicious_batchbuffer_causing_reset -> async eviction -> allocation -> async clearing 2) malicious_batchbuffers_causing_gt_wedge submitted to copy engine -> migration_blit submitted to copy_engine. If wedging the gt, the migration blit will never be executed, fence->error will end up with -EIO but TTM will happily fault the pages to user-space. Now we had other versions around looking at the ttm_bo->moving errors at vma binding and cpu faulting, but this was the direction chosen after discussions with our arch team. Either way we'd probably want to block the error propagation after async_eviction. I can of course add 1) and 2) above to the cover-letter, but if you have any additional input on the best way to handle this, that'd be appreciated. Thanks, Thomas Dave.
Re: [Intel-gfx] [PATCH] drm/i915: Use dma_resv_iter for waiting in i915_gem_object_wait_reservation.
On 13/10/2021 17:17, Daniel Vetter wrote:
On Wed, Oct 13, 2021 at 04:37:03PM +0100, Tvrtko Ursulin wrote:
On 13/10/2021 15:00, Daniel Vetter wrote:
On Wed, Oct 13, 2021 at 02:32:03PM +0200, Maarten Lankhorst wrote:
No memory should be allocated when calling i915_gem_object_wait,
because it may be called to idle a BO when evicting memory.
Fix this by using dma_resv_iter helpers to call
i915_gem_object_wait_fence() on each fence, which cleans up the code a lot.
Also remove dma_resv_prune, it's questionably.
This will result in the following lockdep splat.
<4> [83.538517] ==
<4> [83.538520] WARNING: possible circular locking dependency detected
<4> [83.538522] 5.15.0-rc5-CI-Trybot_8062+ #1 Not tainted
<4> [83.538525] --
<4> [83.538527] gem_render_line/5242 is trying to acquire lock:
<4> [83.538530] 8275b1e0 (fs_reclaim){+.+.}-{0:0}, at:
__kmalloc_track_caller+0x56/0x270
<4> [83.538538]
but task is already holding lock:
<4> [83.538540] 88813471d1e0 (&vm->mutex/1){+.+.}-{3:3}, at:
i915_vma_pin_ww+0x1c7/0x970 [i915]
<4> [83.538638]
which lock already depends on the new lock.
<4> [83.538642]
the existing dependency chain (in reverse order) is:
<4> [83.538645]
-> #1 (&vm->mutex/1){+.+.}-{3:3}:
<4> [83.538649]lock_acquire+0xd3/0x310
<4> [83.538654]i915_gem_shrinker_taints_mutex+0x2d/0x50 [i915]
<4> [83.538730]i915_address_space_init+0xf5/0x1b0 [i915]
<4> [83.538794]ppgtt_init+0x55/0x70 [i915]
<4> [83.538856]gen8_ppgtt_create+0x44/0x5d0 [i915]
<4> [83.538912]i915_ppgtt_create+0x28/0xf0 [i915]
<4> [83.538971]intel_gt_init+0x130/0x3b0 [i915]
<4> [83.539029]i915_gem_init+0x14b/0x220 [i915]
<4> [83.539100]i915_driver_probe+0x97e/0xdd0 [i915]
<4> [83.539149]i915_pci_probe+0x43/0x1d0 [i915]
<4> [83.539197]pci_device_probe+0x9b/0x110
<4> [83.539201]really_probe+0x1b0/0x3b0
<4> [83.539205]__driver_probe_device+0xf6/0x170
<4> [83.539208]driver_probe_device+0x1a/0x90
<4> [83.539210]__driver_attach+0x93/0x160
<4> [83.539213]bus_for_each_dev+0x72/0xc0
<4> [83.539216]bus_add_driver+0x14b/0x1f0
<4> [83.539220]driver_register+0x66/0xb0
<4> [83.539222]hdmi_get_spk_alloc+0x1f/0x50 [snd_hda_codec_hdmi]
<4> [83.539227]do_one_initcall+0x53/0x2e0
<4> [83.539230]do_init_module+0x55/0x200
<4> [83.539234]load_module+0x2700/0x2980
<4> [83.539237]__do_sys_finit_module+0xaa/0x110
<4> [83.539241]do_syscall_64+0x37/0xb0
<4> [83.539244]entry_SYSCALL_64_after_hwframe+0x44/0xae
<4> [83.539247]
-> #0 (fs_reclaim){+.+.}-{0:0}:
<4> [83.539251]validate_chain+0xb37/0x1e70
<4> [83.539254]__lock_acquire+0x5a1/0xb70
<4> [83.539258]lock_acquire+0xd3/0x310
<4> [83.539260]fs_reclaim_acquire+0x9d/0xd0
<4> [83.539264]__kmalloc_track_caller+0x56/0x270
<4> [83.539267]krealloc+0x48/0xa0
<4> [83.539270]dma_resv_get_fences+0x1c3/0x280
<4> [83.539274]i915_gem_object_wait+0x1ff/0x410 [i915]
<4> [83.539342]i915_gem_evict_for_node+0x16b/0x440 [i915]
Btw this looks like an impossible call stack? At least I don't see the
one calling the other.
<4> [83.539412]i915_gem_gtt_reserve+0xff/0x130 [i915]
<4> [83.539482]i915_vma_pin_ww+0x765/0x970 [i915]
<4> [83.539556]eb_validate_vmas+0x6fe/0x8e0 [i915]
<4> [83.539626]i915_gem_do_execbuffer+0x9a6/0x20a0 [i915]
<4> [83.539693]i915_gem_execbuffer2_ioctl+0x11f/0x2c0 [i915]
<4> [83.539759]drm_ioctl_kernel+0xac/0x140
<4> [83.539763]drm_ioctl+0x201/0x3d0
<4> [83.539766]__x64_sys_ioctl+0x6a/0xa0
<4> [83.539769]do_syscall_64+0x37/0xb0
<4> [83.539772]entry_SYSCALL_64_after_hwframe+0x44/0xae
<4> [83.539775]
other info that might help us debug this:
<4> [83.539778] Possible unsafe locking scenario:
<4> [83.539781]CPU0CPU1
<4> [83.539783]
<4> [83.539785] lock(&vm->mutex/1);
<4> [83.539788]lock(fs_reclaim);
<4> [83.539791]lock(&vm->mutex/1);
<4> [83.539794] lock(fs_reclaim);
<4> [83.539796]
*** DEADLOCK ***
<4> [83.539799] 3 locks held by gem_render_line/5242:
<4> [83.539802] #0: c9d4bbf0
(reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_gem_do_execbuffer+0x8e5/0x20a0
[i915]
<4> [83.539870] #1: 88811e48bae8 (reservation_ww_class_mutex){+.+.}-{3:3},
at: eb_validate_vmas+0x81/0x8e0 [i915]
<4> [83.539936] #2: 88813471d1e0 (&vm->mutex/1){+.+.}-{3:3}, at:
i915_vma_pin_ww+0x1c7/0x970 [i915]
<4> [83.540011]
stack backtrace:
<4> [83.540014] CPU: 2 PID: 5242 Comm: gem_render_line Not tainted
5.15.0-rc5-CI-Trybot_8062+ #1
<4> [83.540019] Hardware name: Intel(R) Client Systems NUC11TNHi3/NUC11TNBi3,
BIOS TNTGL357.
Re: [PATCH v2 3/4] dt-bindings: drm/bridge: ti-sn65dsi83: Add vcc supply bindings
On Wed, Oct 13, 2021 at 12:37:47PM +0300, Laurent Pinchart wrote: > Hi Maxime, > > On Wed, Oct 13, 2021 at 09:47:22AM +0200, Maxime Ripard wrote: > > On Tue, Oct 12, 2021 at 08:48:42AM +0200, Alexander Stein wrote: > > > Add a VCC regulator which needs to be enabled before the EN pin is > > > released. > > > > > > Reviewed-by: Sam Ravnborg > > > Signed-off-by: Alexander Stein > > > --- > > > .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > > index a5779bf17849..49ace6f312d5 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 > > > > > > @@ -93,6 +96,7 @@ properties: > > > required: > > >- compatible > > >- reg > > > + - vcc-supply > > > > This isn't a backward-compatible change. All the previous users of that > > binding will now require a vcc-supply property even though it was > > working fine for them before. > > > > You handle that nicely in the code, but you can't make that new property > > required. > > We can't make it required in the driver, but can't we make it required > in the bindings ? This indicates that all new DTs need to set the > property. We also need to mass-patch the in-tree DTs to avoid validation > failures, but apart from that, I don't see any issue. I guess we'd need to clarify what the schemas are here for. We've been using them for two things: define the bindings, and make sure that the users of a binding actually follow it. The second part makes it very tempting to also cram "and make sure they follow our best practices" in there. We never had the discussion about whether that's ok or not, and I think the schemas syntax falls a bit short there since I don't think we can make the difference between a warning and an error that would make it work. However, if we're talking about the binding itself, then no, you can't introduce a new property. Since it was acceptable in the past, it still needs to be acceptable going forward. Maxime signature.asc Description: PGP signature
Re: [PATCH] fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)
On Wed, Oct 13, 2021 at 04:08:02PM +0200, Thomas Zimmermann wrote: > Hi > > Am 01.10.21 um 14:48 schrieb Claudio Suarez: > > On Fri, Oct 01, 2021 at 10:21:44AM +0200, Thomas Zimmermann wrote: > > > Hi > > > > > > Am 30.09.21 um 17:10 schrieb Claudio: > > > > Scroll acceleration is disabled in fbcon by hard-wiring > > > > p->scrollmode = SCROLL_REDRAW. Remove the obsolete code in fbcon.c > > > > and fbdev/core/ > > > > > > > > Signed-off-by: Claudio Suarez > > > > --- > > > > > > > > - This is a task in the TODO list Documentation/gpu/todo.rst > > > > - The contact in the task is Daniel Vetter. He is/you are in copy. > > > > - To ease the things and saving time, I did a patch. It is included in > > > > this > > > > message. I can redo it if there is something wrong. > > > > - I tested it in some configurations. > > > > > > > > My plan for new patches in this task: > > > > - A buch of patches to remove code from drivers: fb_copyarea and > > > > related. > > > > - Simplify the code around fbcon_ops as much as possible to remove the > > > > hooks > > > > as the TODO suggests. > > > > - Remove fb_copyarea in headers and exported symbols: cfb_copyarea, > > > > etc. This > > > > must be done when all the drivers are changed. > > > > > > > > I think that the correct list to ask questions about this > > > > is linux-fb...@vger.kernel.org . Is it correct ? > > > > My question: I can develop the new changes. I can test in two > > > > computers/two > > > > drivers. Is there a way to test the rest of the patches ? I have not > > > > hardware > > > > to test them. Is anyone helping with this? Only regression tests are > > > > needed. > > > > I can test other patches in return. > > > > > > > > Thank you. > > > > Claudio Suarez. > > > > > > > > Patch follows: > > > > > > > >Documentation/gpu/todo.rst | 13 +- > > > >drivers/video/fbdev/core/bitblit.c | 16 - > > > >drivers/video/fbdev/core/fbcon.c| 509 > > > > ++-- > > > >drivers/video/fbdev/core/fbcon.h| 59 > > > >drivers/video/fbdev/core/fbcon_ccw.c| 28 +- > > > >drivers/video/fbdev/core/fbcon_cw.c | 28 +- > > > >drivers/video/fbdev/core/fbcon_rotate.h | 9 - > > > >drivers/video/fbdev/core/fbcon_ud.c | 37 +-- > > > >drivers/video/fbdev/core/tileblit.c | 16 - > > > >drivers/video/fbdev/skeletonfb.c| 12 +- > > > >include/linux/fb.h | 2 +- > > > >11 files changed, 51 insertions(+), 678 deletions(-) > > > > > > Nice stats :) > > > > > > I looked through it and it looks good. Maybe double-check that everything > > > still builds. > > > > > > Acked-by: Thomas Zimmermann > > > > > > > Yes, it still builds :) > > I had built with some different .config options, including > > allyesconfig, allno, some randoms and debian default config. I tested > > some .config options related to fbdev. I spent time running some kernels > > with different parameters and everything was ok. > > Today, I've just applied the patch to source from two gits: Linus > > rc and drm. Both have built ok. > > I think that I did enough tests to ensure it works fine. This code is going > > to run in many computers, mine included! > > Of course, if you or anyone is worried about something specific, please, > > tell me and I can check and re-check it. I don't want to miss something > > important. > > > > Thank you! > > I added the patch to drm-misc-next. Great! Then I start to work in the second phase of removing unnecessary code from every driver, which depends on this one. Thanks a lot! Best regards, Claudio Suarez > > Best regards > Thomas > > > > > Best regards > > Claudio Suarez > > > > > Best regards > > > Thomas > > > > > > > > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > > > index 12e61869939e..bb1e04bbf4fb 100644 > > > > --- a/Documentation/gpu/todo.rst > > > > +++ b/Documentation/gpu/todo.rst > > > > @@ -314,16 +314,19 @@ Level: Advanced > > > >Garbage collect fbdev scrolling acceleration > > > > > > > > -Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode = > > > > -SCROLL_REDRAW. There's a ton of code this will allow us to remove: > > > > +Scroll acceleration has been disabled in fbcon. Now it works as the old > > > > +SCROLL_REDRAW mode. A ton of code was removed in fbcon.c and the hook > > > > bmove was > > > > +removed from fbcon_ops. > > > > +Remaining tasks: > > > > -- lots of code in fbcon.c > > > > - > > > > -- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could > > > > be called > > > > +- a bunch of the hooks in fbcon_ops could be removed or simplified by > > > > calling > > > > directly instead of the function table (with a switch on p->rotate) > > > >- fb_copyarea is unused after this, and can be deleted from all > > > > drivers > > > > +- afte
Re:linux-next: build failure after merge of the drm-misc tree
Hi,
I review the code.
It seems I forget to delete the definition of the variable "inst",I'm sry for
that.: (
I'll submit another patch soon.
> Hi all,> > After merging the drm-misc tree, today's linux-next build (x86_64>
> allmodconfig) failed like this:> >
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c: In function
> 'gp100_vmm_fault_cancel':>
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c:491:6: error: unused
> variable 'inst' [-Werror=unused-variable]> 491 | u32 inst, aper;> |
> ^~~~> cc1: all warnings being treated as errors> > Caused by commit> >
> 404046cf4805 ("drm/nouveau/mmu/gp100-: drop unneeded assignment in the if
> condition.")>> I have used the drm-misc tree from next-20211011 for today.> >
> -- > Cheers,> Stephen Rothwell
Re: [PATCH RFC] virtio: wrap config->reset calls
On 13.10.2021 12:55, Michael S. Tsirkin wrote: This will enable cleanups down the road. The idea is to disable cbs, then add "flush_queued_cbs" callback as a parameter, this way drivers can flush any work queued after callbacks have been disabled. Signed-off-by: Michael S. Tsirkin --- sound/virtio/virtio_card.c | 4 ++-- Reviewed-by: Anton Yakovlev -- Anton Yakovlev Senior Software Engineer OpenSynergy GmbH Rotherstr. 20, 10245 Berlin
Re: [PATCH 2/2] drm/i915/pmu: Connect engine busyness stats from GuC to pmu
On 13/10/2021 01:56, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for all engines using shared memory. For each engine, this
info contains:
- total busyness: total time that the context was running (total)
- id: id of the running context (id)
- start timestamp: timestamp when the context started running (start)
At the time (now) of sampling the engine busyness, if the id is valid
(!= ~0), and start is non-zero, then the context is considered to be
active and the engine busyness is calculated using the below equation
engine busyness = total + (now - start)
All times are obtained from the gt clock base. For inactive contexts,
engine busyness is just equal to the total.
The start and total values provided by GuC are 32 bits and wrap around
in a few minutes. Since perf pmu provides busyness as 64 bit
monotonically increasing values, there is a need for this implementation
to account for overflows and extend the time to 64 bits before returning
busyness to the user. In order to do that, a worker runs periodically at
frequency = 1/8th the time it takes for the timestamp to wrap. As an
example, that would be once in 27 seconds for a gt clock frequency of
19.2 MHz.
Note:
There might be an overaccounting of busyness due to the fact that GuC
may be updating the total and start values while kmd is reading them.
(i.e kmd may read the updated total and the stale start). In such a
case, user may see higher busyness value followed by smaller ones which
would eventually catch up to the higher value.
v2: (Tvrtko)
- Include details in commit message
- Move intel engine busyness function into execlist code
- Use union inside engine->stats
- Use natural type for ping delay jiffies
- Drop active_work condition checks
- Use for_each_engine if iterating all engines
- Drop seq locking, use spinlock at guc level to update engine stats
- Document worker specific details
v3: (Tvrtko/Umesh)
- Demarcate guc and execlist stat objects with comments
- Document known over-accounting issue in commit
- Provide a consistent view of guc state
- Add hooks to gt park/unpark for guc busyness
- Stop/start worker in gt park/unpark path
- Drop inline
- Move spinlock and worker inits to guc initialization
- Drop helpers that are called only once
v4: (Tvrtko/Matt/Umesh)
- Drop addressed opens from commit message
- Get runtime pm in ping, remove from the park path
- Use cancel_delayed_work_sync in disable_submission path
- Update stats during reset prepare
- Skip ping if reset in progress
- Explicitly name execlists and guc stats objects
- Since disable_submission is called from many places, move resetting
stats to intel_guc_submission_reset_prepare
v5: (Tvrtko)
- Add a trylock helper that does not sleep and synchronize PMU event
callbacks and worker with gt reset
Signed-off-by: John Harrison
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 28 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 33 ++-
.../drm/i915/gt/intel_execlists_submission.c | 34 +++
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +
drivers/gpu/drm/i915/gt/intel_reset.c | 16 ++
drivers/gpu/drm/i915/gt/intel_reset.h | 1 +
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 30 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 21 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 13 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 267 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 2 +
14 files changed, 427 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 38436f4b5706..6b783fdcba2a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1873,23 +1873,6 @@ void intel_engine_dump(struct intel_engine_cs *engine,
intel_engine_print_breadcrumbs(engine, m);
}
-static ktime_t __intel_engine_get_busy_time(struct intel_engine_cs *engine,
- ktime_t *now)
-{
- struct intel_engine_execlists_stats *stats = &engine->stats.execlists;
- ktime_t total = stats->total;
-
- /*
-* If the engine is executing something at the moment
-* add it to the total.
-*/
- *now = ktime_get();
- if (READ_ONCE(stats->active))
- total = ktime_add(total, ktime_sub(*now, stats->start));
-
- return total;
-}
-
/**
* intel_engine_get_busy_time() - Return current accumulated engine busyness
* @engine: engine to report on
@@ -1899,16 +1882,7 @@ sta
Re: [PATCH RFC] virtio: wrap config->reset calls
On Wed, Oct 13, 2021 at 06:55:31AM -0400, Michael S. Tsirkin wrote: > This will enable cleanups down the road. > The idea is to disable cbs, then add "flush_queued_cbs" callback > as a parameter, this way drivers can flush any work > queued after callbacks have been disabled. > > Signed-off-by: Michael S. Tsirkin > --- > drivers/iommu/virtio-iommu.c | 2 +- Reviewed-by: Jean-Philippe Brucker
Re: [Intel-gfx] [PATCH] drm/i915: Use dma_resv_iter for waiting in i915_gem_object_wait_reservation.
On 13/10/2021 11:41, Maarten Lankhorst wrote:
No memory should be allocated when calling i915_gem_object_wait,
because it may be called to idle a BO when evicting memory.
Fix this by using dma_resv_iter helpers to call
i915_gem_object_wait_fence() on each fence, which cleans up the code a lot.
Also remove dma_resv_prune, it's questionably.
This will result in the following lockdep splat.
@@ -37,56 +36,17 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
unsigned int flags,
long timeout)
{
- struct dma_fence *excl;
- bool prune_fences = false;
-
- if (flags & I915_WAIT_ALL) {
- struct dma_fence **shared;
- unsigned int count, i;
- int ret;
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
- ret = dma_resv_get_fences(resv, &excl, &count, &shared);
- if (ret)
- return ret;
-
- for (i = 0; i < count; i++) {
- timeout = i915_gem_object_wait_fence(shared[i],
-flags, timeout);
- if (timeout < 0)
- break;
+ dma_resv_iter_begin(&cursor, resv, flags & I915_WAIT_ALL);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
- dma_fence_put(shared[i]);
- }
-
- for (; i < count; i++)
- dma_fence_put(shared[i]);
- kfree(shared);
-
- /*
-* If both shared fences and an exclusive fence exist,
-* then by construction the shared fences must be later
-* than the exclusive fence. If we successfully wait for
-* all the shared fences, we know that the exclusive fence
-* must all be signaled. If all the shared fences are
-* signaled, we can prune the array and recover the
-* floating references on the fences/requests.
-*/
- prune_fences = count && timeout >= 0;
- } else {
- excl = dma_resv_get_excl_unlocked(resv);
+ timeout = i915_gem_object_wait_fence(fence, flags, timeout);
+ if (timeout <= 0)
+ break;
You have another change in behaviour here, well a bug really. When
userspace passes in zero timeout you fail to report activity in other
than the first fence.
Regards,
Tvrtko
Re: [PATCH 1/2] drm/dp: add helpers to read link training delays
On Thu, 14 Oct 2021, Ville Syrjälä wrote:
> On Tue, Oct 12, 2021 at 05:43:20PM +0300, Jani Nikula wrote:
>> The link training delays are different and/or available in different
>> DPCD offsets depending on:
>>
>> - Clock recovery vs. channel equalization
>> - DPRX vs. LTTPR
>> - 128b/132b vs. 8b/10b
>> - DPCD 1.4+ vs. earlier
>>
>> Add helpers to get the correct delays in us, reading DPCD if
>> necessary. This is more straightforward than trying to retrofit the
>> existing helpers to take 128b/132b into account.
>>
>> Having to pass in the DPCD receiver cap field seems unavoidable, because
>> reading it involves checking the revision and reading extended receiver
>> cap. So unfortunately the interface is mixed cached and read as needed.
>>
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_dp_helper.c | 132
>> include/drm/drm_dp_helper.h | 21 -
>> 2 files changed, 151 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 4d0d1e8e51fa..04ebef7f5aa7 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -154,6 +154,138 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8
>> link_status[DP_LINK_STATUS_SIZ
>> }
>> EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
>>
>> +static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux, u8
>> rd_interval)
>> +{
>> +if (rd_interval > 4)
>> +drm_dbg_kms(aux->drm_dev, "%s: invalid AUX interval 0x%02x (max
>> 4)\n",
>> +aux->name, rd_interval);
>> +
>> +if (rd_interval == 0)
>> +return 100;
>> +
>> +return rd_interval * 4 * USEC_PER_MSEC;
>> +}
>> +
>> +static int __8b10b_channel_eq_delay_us(const struct drm_dp_aux *aux, u8
>> rd_interval)
>> +{
>> +if (rd_interval > 4)
>> +drm_dbg_kms(aux->drm_dev, "%s: invalid AUX interval 0x%02x (max
>> 4)\n",
>> +aux->name, rd_interval);
>> +
>> +if (rd_interval == 0)
>> +return 400;
>> +
>> +return rd_interval * 4 * USEC_PER_MSEC;
>> +}
>
> Is there a reason you're not reusing these in the existing sleepy
> functions?
I decided to see how this flies first, and do that as a follow-up.
> Maybe just passing in the dpcd receiver cap all the way
> would also be nicer since then these functions would do all the work,
> instead of splitting it partially between these and the caller.
It's a bit subtle. Checking for dpcd receiver cap in the caller allows
early return without the dpcd read in some cases.
It's all really unnecessarily complicated how the delays are spread all
over the place in dpcd. I couldn't think of a cleaner approach (without
a massive dpcd caching rewrite using regmap, anyway ;).
> Also with the 1.4+ case handled elsewhere there won't be debug
> spew for illegal values (not sure we care too much though).
That's subtle too. This leaves out the check when we're not using the
value, which seems fine to me. However, the same dpcd offset is used for
channel equalization, and that will have the check and debug print.
>> +
>> +static int __128b132b_channel_eq_delay_us(const struct drm_dp_aux *aux, u8
>> rd_interval)
>> +{
>> +switch (rd_interval) {
>> +default:
>> +drm_dbg_kms(aux->drm_dev, "%s: invalid AUX interval 0x%02x\n",
>> +aux->name, rd_interval);
>> +fallthrough;
>> +case DP_128B132B_TRAINING_AUX_RD_INTERVAL_400_US:
>> +return 400;
>> +case DP_128B132B_TRAINING_AUX_RD_INTERVAL_4_MS:
>> +return 4000;
>> +case DP_128B132B_TRAINING_AUX_RD_INTERVAL_8_MS:
>> +return 8000;
>> +case DP_128B132B_TRAINING_AUX_RD_INTERVAL_12_MS:
>> +return 12000;
>> +case DP_128B132B_TRAINING_AUX_RD_INTERVAL_16_MS:
>> +return 16000;
>> +case DP_128B132B_TRAINING_AUX_RD_INTERVAL_32_MS:
>> +return 32000;
>> +case DP_128B132B_TRAINING_AUX_RD_INTERVAL_64_MS:
>> +return 64000;
>> +}
>> +}
>
> The spec does claim that only 00-06 are legal also for the CR delay.
> So here too we lose the debug spew if we don' have the CR version
> of this.
>
>> +
>> +/*
>> + * The link training delays are different for:
>> + *
>> + * - Clock recovery vs. channel equalization
>> + * - DPRX vs. LTTPR
>> + * - 128b/132b vs. 8b/10b
>> + * - DPCD rev 1.3 vs. later
>> + *
>> + * Get the correct delay in us, reading DPCD if necessary.
>> + */
>> +static int __read_delay(struct drm_dp_aux *aux, const u8
>> dpcd[DP_RECEIVER_CAP_SIZE],
>> +enum drm_dp_phy dp_phy, bool uhbr, bool cr)
>> +{
>> +int (*parse)(const struct drm_dp_aux *aux, u8 rd_interval);
>> +unsigned int offset;
>> +u8 rd_interval, mask;
>> +int delay_us;
>> +
>> +if (dp_phy == DP_PHY_DPRX) {
>> +if (uhbr) {
>> +if (cr)
>> +
[PATCH] drm/i915/gt: make a gt sysfs group and move power management files
From: Andi Shyti
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create a 'gt/' directory in sysfs which will contain gt0...gtN
directories related to each tile configured in the GPU. Move the
power management files inside those directories.
The previous power management files are kept in their original
root directory to avoid breaking the ABI. They point to the tile
'0' and a warning message is printed whenever accessed to. The
deprecated interface needs for the CONFIG_SYSFS_DEPRECATED_V2
flag in order to be generated.
The new sysfs structure will have a similar layout for the 4 tile
case:
/sys/.../card0
├── gt
│ ├── gt0
│ │ ├── id
│ │ ├── rc6_enable
│ │ ├── rc6_residency_ms
│ │ ├── rps_act_freq_mhz
│ │ ├── rps_boost_freq_mhz
│ │ ├── rps_cur_freq_mhz
│ │ ├── rps_max_freq_mhz
│ │ ├── rps_min_freq_mhz
│ │ ├── rps_RP0_freq_mhz
│ │ ├── rps_RP1_freq_mhz
│ │ └── rps_RPn_freq_mhz
. .
. .
. .
│ └── gt3
│ ├── id
│ ├── rc6_enable
│ ├── rc6_residency_ms
│ ├── rps_act_freq_mhz
│ ├── rps_boost_freq_mhz
│ ├── rps_cur_freq_mhz
│ ├── rps_max_freq_mhz
│ ├── rps_min_freq_mhz
│ ├── rps_RP0_freq_mhz
│ ├── rps_RP1_freq_mhz
│ └── rps_RPn_freq_mhz
├── gt_act_freq_mhz -+
├── gt_boost_freq_mhz |
├── gt_cur_freq_mhz|Original interface
├── gt_max_freq_mhz+─-> kept as existing ABI;
├── gt_min_freq_mhz|it points to gt0/
├── gt_RP0_freq_mhz|
└── gt_RP1_freq_mhz|
└── gt_RPn_freq_mhz -+
Signed-off-by: Andi Shyti
Signed-off-by: Lucas De Marchi
Cc: Matt Roper
Cc: Sujaritha Sundaresan
Cc: Tvrtko Ursulin
---
Hi,
this patch needs to go on top of Matt Roper's multitile series:
https://patchwork.freedesktop.org/series/95631/
because it requires multitile support.
Matt if you want and it's not much hassle for you, you can take
this patch along with your series.
Thanks,
Andi
drivers/gpu/drm/i915/Makefile | 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 3 +
drivers/gpu/drm/i915/gt/sysfs_gt.c| 130 +
drivers/gpu/drm/i915/gt/sysfs_gt.h| 45 +++
drivers/gpu/drm/i915/gt/sysfs_gt_pm.c | 394 ++
drivers/gpu/drm/i915/gt/sysfs_gt_pm.h | 16 ++
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/i915_sysfs.c | 328 +
drivers/gpu/drm/i915/i915_sysfs.h | 3 +
10 files changed, 607 insertions(+), 319 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.h
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 21b05ed0e4e8c..f39e00a0d584f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -120,7 +120,9 @@ gt-y += \
gt/intel_timeline.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
- gt/sysfs_engines.o
+ gt/sysfs_engines.o \
+ gt/sysfs_gt.o \
+ gt/sysfs_gt_pm.o
# autogenerated null render state
gt-y += \
gt/gen6_renderstate.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 0879e30ace7cc..748a21ab717d2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -21,6 +21,7 @@
#include "intel_rps.h"
#include "intel_uncore.h"
#include "shmem_utils.h"
+#include "sysfs_gt.h"
#include "pxp/intel_pxp.h"
static void
@@ -448,6 +449,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
intel_rps_driver_register(>->rps);
intel_gt_debugfs_register(gt);
+ intel_gt_sysfs_register(gt);
}
static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
@@ -764,6 +766,7 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
{
intel_wakeref_t wakeref;
+ intel_gt_sysfs_unregister(gt);
intel_rps_driver_unregister(>->rps);
intel_pxp_fini(>->pxp);
diff --git a/drivers/gpu/drm/i915/gt/sysfs_gt.c
b/drivers/gpu/drm/i915/gt/sysfs_gt.c
new file mode 100644
index 0..0d1398b2d61ce
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/sysfs_gt.c
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_sysfs.h"
+#include "intel_gt.h"
+#include "intel_gt_types.h"
+#include "intel_rc6.h"
+
+#include "sysfs_gt.h"
+#include "s
[PATCH 0/4] drm/i915: Make the driver not oops on load on old machines
From: Ville Syrjälä Fix a pile of regression on older machines which just oops the driver on load. Cc: Dave Airlie Cc: Jani Nikula Cc: Maarten Lankhorst Cc: Thomas Hellström Cc: Chris Wilson Cc: Mika Kuoppala Ville Syrjälä (4): drm/i915: Replace the unconditional clflush with drm_clflush_virt_range() drm/i915: Convert unconditional clflush to drm_clflush_virt_range() drm/i915: Catch yet another unconditioal clflush drm/i915: Fix oops on platforms w/o hpd support drivers/gpu/drm/i915/display/intel_hotplug.c| 3 ++- drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/intel_timeline.c| 4 ++-- 3 files changed, 5 insertions(+), 4 deletions(-) -- 2.32.0
[PATCH 1/4] drm/i915: Replace the unconditional clflush with drm_clflush_virt_range()
From: Ville Syrjälä
Not all machines have clflush, so don't go assuming they do.
Not really sure why the clflush is even here since hwsp
is supposed to get snooped I thought.
Although in my case we're talking about a i830 machine where
render/blitter snooping is definitely busted. But it might
work for the hswp perhaps. Haven't really reverse engineered
that one fully.
Cc: sta...@vger.kernel.org
Cc: Chris Wilson
Cc: Mika Kuoppala
Fixes: b436a5f8b6c8 ("drm/i915/gt: Track all timelines created using the HWSP")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 593524195707..586dca1731ce 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -292,7 +292,7 @@ static void xcs_sanitize(struct intel_engine_cs *engine)
sanitize_hwsp(engine);
/* And scrub the dirty cachelines for the HWSP */
- clflush_cache_range(engine->status_page.addr, PAGE_SIZE);
+ drm_clflush_virt_range(engine->status_page.addr, PAGE_SIZE);
intel_engine_reset_pinned_contexts(engine);
}
--
2.32.0
[PATCH 2/4] drm/i915: Convert unconditional clflush to drm_clflush_virt_range()
From: Ville Syrjälä
This one is apparently a "clflush for good measure", so bit more
justification (if you can call it that) than some of the others.
Convert to drm_clflush_virt_range() again so that machines without
clflush will survive the ordeal.
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Thomas Hellström #v1
Fixes: 12ca695d2c1e ("drm/i915: Do not share hwsp across contexts any more,
v8.")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 1257f4f11e66..23d7328892ed 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -225,7 +225,7 @@ void intel_timeline_reset_seqno(const struct intel_timeline
*tl)
memset(hwsp_seqno + 1, 0, TIMELINE_SEQNO_BYTES - sizeof(*hwsp_seqno));
WRITE_ONCE(*hwsp_seqno, tl->seqno);
- clflush(hwsp_seqno);
+ drm_clflush_virt_range(hwsp_seqno, TIMELINE_SEQNO_BYTES);
}
void intel_timeline_enter(struct intel_timeline *tl)
--
2.32.0
[PATCH 4/4] drm/i915: Fix oops on platforms w/o hpd support
From: Ville Syrjälä
We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
Let's not oops when loading the driver on one those machines.
Cc: Dave Airlie
Cc: Jani Nikula
Fixes: cd030c7c11a4 ("drm/i915: constify hotplug function vtable.")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 3c1cec953b42..0e949a258a22 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -215,7 +215,8 @@ intel_hpd_irq_storm_switch_to_polling(struct
drm_i915_private *dev_priv)
static void intel_hpd_irq_setup(struct drm_i915_private *i915)
{
- if (i915->display_irqs_enabled && i915->hotplug_funcs->hpd_irq_setup)
+ if (i915->display_irqs_enabled &&
+ i915->hotplug_funcs && i915->hotplug_funcs->hpd_irq_setup)
i915->hotplug_funcs->hpd_irq_setup(i915);
}
--
2.32.0
[PATCH 3/4] drm/i915: Catch yet another unconditioal clflush
From: Ville Syrjälä
Replace the unconditional clflush() with drm_clflush_virt_range()
which does the wbinvd() fallback when clflush is not available.
This time no justification is given for the clflush in the
offending commit.
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Thomas Hellström
Fixes: 2c8ab3339e39 ("drm/i915: Pin timeline map after first timeline pin, v4.")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 23d7328892ed..438bbc7b8147 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -64,7 +64,7 @@ intel_timeline_pin_map(struct intel_timeline *timeline)
timeline->hwsp_map = vaddr;
timeline->hwsp_seqno = memset(vaddr + ofs, 0, TIMELINE_SEQNO_BYTES);
- clflush(vaddr + ofs);
+ drm_clflush_virt_range(vaddr + ofs, TIMELINE_SEQNO_BYTES);
return 0;
}
--
2.32.0
Re: [PATCH 4/4] drm/i915: Fix oops on platforms w/o hpd support
On Thu, 14 Oct 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
> Let's not oops when loading the driver on one those machines.
D'oh!
Lemme guess, CI just casually dropped the machines from the results
because they didn't boot?
Reviewed-by: Jani Nikula
>
> Cc: Dave Airlie
> Cc: Jani Nikula
> Fixes: cd030c7c11a4 ("drm/i915: constify hotplug function vtable.")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_hotplug.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> index 3c1cec953b42..0e949a258a22 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> @@ -215,7 +215,8 @@ intel_hpd_irq_storm_switch_to_polling(struct
> drm_i915_private *dev_priv)
>
> static void intel_hpd_irq_setup(struct drm_i915_private *i915)
> {
> - if (i915->display_irqs_enabled && i915->hotplug_funcs->hpd_irq_setup)
> + if (i915->display_irqs_enabled &&
> + i915->hotplug_funcs && i915->hotplug_funcs->hpd_irq_setup)
> i915->hotplug_funcs->hpd_irq_setup(i915);
> }
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v7, 04/15] media: mtk-vcodec: Manage multi hardware information
Manage each hardware information which includes irq/power/clk.
The hardware includes LAT0, LAT1 and CORE.
Signed-off-by: Yunfei Dong
---
v7: Using of_platform_populate not component framework to manage multi hardware.
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 151
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 165 ++
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 49 ++
.../mtk-vcodec/mtk_vcodec_dec_stateful.c | 1 +
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 1 +
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 23 +++
8 files changed, 359 insertions(+), 33 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
Hello Yunfei,
thanks for this great series! However, there are a few things to improve...
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index ca8e9e7a9c4e..edeb3b66e9e9 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -15,6 +15,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
mtk_vcodec_dec_stateful.o \
mtk_vcodec_dec_stateless.o \
mtk_vcodec_dec_pm.o \
+ mtk_vcodec_dec_hw.o \
mtk-vcodec-enc-y := venc/venc_vp8_if.o \
venc/venc_h264_if.o \
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
index 9fbd24186c1a..c509224cbff4 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
@@ -66,6 +66,7 @@ extern const struct v4l2_ioctl_ops mtk_vdec_ioctl_ops;
extern const struct v4l2_m2m_ops mtk_vdec_m2m_ops;
extern const struct media_device_ops mtk_vcodec_media_ops;
+extern struct platform_driver mtk_vdec_comp_driver;
This may be useless... more on that later in this review.
/*
* mtk_vdec_lock/mtk_vdec_unlock are for ctx instance to
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 dd749d41c75a..17cb3e3519eb 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,61 @@
#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 struct of_device_id mtk_vdec_drv_ids[] = {
+ {
+ .compatible = "mediatek,mtk-vcodec-lat",
+ .data = (void *)MTK_VDEC_LAT0,
+ },
+ {
+ .compatible = "mediatek,mtk-vcodec-core",
+ .data = (void *)MTK_VDEC_CORE,
+ },
+ {},
+};
Is this a duplicate of "mtk_vdec_comp_ids", found in mtk_vcodec_dec_hw.c?!
+
+static int mtk_vcodec_comp_device_check(struct mtk_vcodec_ctx *ctx)
+ {
+ struct mtk_vcodec_dev *vdec_dev = ctx->dev;
+ struct platform_device *pdev = vdec_dev->plat_dev;
+ struct device_node *comp_node;
+ enum mtk_vdec_hw_id comp_idx;
+ const struct of_device_id *of_id;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(mtk_vdec_drv_ids); i++) {
+ of_id = &mtk_vdec_drv_ids[i];
+ comp_node = of_find_compatible_node(NULL, NULL,
+ of_id->compatible);
+ if (!comp_node)
+ continue;
+
+ if (!of_device_is_available(comp_node)) {
+ of_node_put(comp_node);
+ dev_err(&pdev->dev, "Fail to get MMSYS node\n");
+ continue;
+ }
+
+ comp_idx = (enum mtk_vdec_hw_id)of_id->data;
+ vdec_dev->component_node[comp_idx] = comp_node;
+
+ if (!test_bit(comp_idx, vdec_dev->hardware_bitmap)) {
+ dev_err(&pdev->dev, "Vdec comp_idx is not ready %d.",
+ comp_idx);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void *priv)
{
struct mtk_vcodec_dev *dev = priv;
@@ -95,6 +137,41 @@ static int mtk_vcodec_get_reg_bases(struct mtk_vcodec_dev
*dev)
return 0;
}
+static int mtk_vcodec_init_dec_params(struct mtk_vcodec_dev *dev)
+{
+ struct platform_device *pdev = dev->plat_dev;
+ int ret;
+
+ ret = mtk_vcode
Re: [PATCH 4/4] drm/i915: Fix oops on platforms w/o hpd support
On Thu, 14 Oct 2021, Jani Nikula wrote:
> On Thu, 14 Oct 2021, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
>> Let's not oops when loading the driver on one those machines.
>
> D'oh!
>
> Lemme guess, CI just casually dropped the machines from the results
> because they didn't boot?
>
> Reviewed-by: Jani Nikula
>
>>
>> Cc: Dave Airlie
>> Cc: Jani Nikula
>> Fixes: cd030c7c11a4 ("drm/i915: constify hotplug function vtable.")
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/display/intel_hotplug.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
>> b/drivers/gpu/drm/i915/display/intel_hotplug.c
>> index 3c1cec953b42..0e949a258a22 100644
>> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
>> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
>> @@ -215,7 +215,8 @@ intel_hpd_irq_storm_switch_to_polling(struct
>> drm_i915_private *dev_priv)
>>
>> static void intel_hpd_irq_setup(struct drm_i915_private *i915)
>> {
>> -if (i915->display_irqs_enabled && i915->hotplug_funcs->hpd_irq_setup)
>> +if (i915->display_irqs_enabled &&
>> +i915->hotplug_funcs && i915->hotplug_funcs->hpd_irq_setup)
Btw i915->hotplug_funcs->hpd_irq_setup is always set if
i915->hotplug_funcs is set, so that bit is a bit redundant.
Anyway, r-b stands either way you decide to go.
>> i915->hotplug_funcs->hpd_irq_setup(i915);
>> }
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 4/4] drm/i915: Fix oops on platforms w/o hpd support
On Thu, Oct 14, 2021 at 12:20:24PM +0300, Jani Nikula wrote:
> On Thu, 14 Oct 2021, Jani Nikula wrote:
> > On Thu, 14 Oct 2021, Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
> >> Let's not oops when loading the driver on one those machines.
> >
> > D'oh!
> >
> > Lemme guess, CI just casually dropped the machines from the results
> > because they didn't boot?
> >
> > Reviewed-by: Jani Nikula
> >
> >>
> >> Cc: Dave Airlie
> >> Cc: Jani Nikula
> >> Fixes: cd030c7c11a4 ("drm/i915: constify hotplug function vtable.")
> >> Signed-off-by: Ville Syrjälä
> >> ---
> >> drivers/gpu/drm/i915/display/intel_hotplug.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> >> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> >> index 3c1cec953b42..0e949a258a22 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> >> @@ -215,7 +215,8 @@ intel_hpd_irq_storm_switch_to_polling(struct
> >> drm_i915_private *dev_priv)
> >>
> >> static void intel_hpd_irq_setup(struct drm_i915_private *i915)
> >> {
> >> - if (i915->display_irqs_enabled && i915->hotplug_funcs->hpd_irq_setup)
> >> + if (i915->display_irqs_enabled &&
> >> + i915->hotplug_funcs && i915->hotplug_funcs->hpd_irq_setup)
>
> Btw i915->hotplug_funcs->hpd_irq_setup is always set if
> i915->hotplug_funcs is set, so that bit is a bit redundant.
Right. I'll drop the drop the belt, leaving just the suspenders.
>
> Anyway, r-b stands either way you decide to go.
>
>
> >>i915->hotplug_funcs->hpd_irq_setup(i915);
> >> }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
Re: [PATCH 4/4] drm/i915: Fix oops on platforms w/o hpd support
On Thu, Oct 14, 2021 at 12:18:23PM +0300, Jani Nikula wrote:
> On Thu, 14 Oct 2021, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
> > Let's not oops when loading the driver on one those machines.
>
> D'oh!
>
> Lemme guess, CI just casually dropped the machines from the results
> because they didn't boot?
Dunno where the gdg has gone actually. Tomi?
>
> Reviewed-by: Jani Nikula
>
> >
> > Cc: Dave Airlie
> > Cc: Jani Nikula
> > Fixes: cd030c7c11a4 ("drm/i915: constify hotplug function vtable.")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_hotplug.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > index 3c1cec953b42..0e949a258a22 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > @@ -215,7 +215,8 @@ intel_hpd_irq_storm_switch_to_polling(struct
> > drm_i915_private *dev_priv)
> >
> > static void intel_hpd_irq_setup(struct drm_i915_private *i915)
> > {
> > - if (i915->display_irqs_enabled && i915->hotplug_funcs->hpd_irq_setup)
> > + if (i915->display_irqs_enabled &&
> > + i915->hotplug_funcs && i915->hotplug_funcs->hpd_irq_setup)
> > i915->hotplug_funcs->hpd_irq_setup(i915);
> > }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
Re: [PATCH v7, 04/15] media: mtk-vcodec: Manage multi hardware information
> Manage each hardware information which includes irq/power/clk.
> The hardware includes LAT0, LAT1 and CORE.
>
> Signed-off-by: Yunfei Dong
> ---
> v7: Using of_platform_populate not component framework to manage multi
hardware.
> ---
> drivers/media/platform/mtk-vcodec/Makefile| 1 +
> .../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +
> .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 151
> .../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 165 ++
> .../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 49 ++
> .../mtk-vcodec/mtk_vcodec_dec_stateful.c | 1 +
> .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 1 +
> .../platform/mtk-vcodec/mtk_vcodec_drv.h | 23 +++
> 8 files changed, 359 insertions(+), 33 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
>
Hello Yunfei,
thanks for this great series! However, there are a few things to improve...
> diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
> index ca8e9e7a9c4e..edeb3b66e9e9 100644
> --- a/drivers/media/platform/mtk-vcodec/Makefile
> +++ b/drivers/media/platform/mtk-vcodec/Makefile
> @@ -15,6 +15,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
> mtk_vcodec_dec_stateful.o \
> mtk_vcodec_dec_stateless.o \
> mtk_vcodec_dec_pm.o \
> +mtk_vcodec_dec_hw.o \
> mtk-vcodec-enc-y := venc/venc_vp8_if.o \
> venc/venc_h264_if.o \
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
> index 9fbd24186c1a..c509224cbff4 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
> @@ -66,6 +66,7 @@ extern const struct v4l2_ioctl_ops mtk_vdec_ioctl_ops;
> extern const struct v4l2_m2m_ops mtk_vdec_m2m_ops;
> extern const struct media_device_ops mtk_vcodec_media_ops;
> +extern struct platform_driver mtk_vdec_comp_driver;
This may be useless... more on that later in this review.
> /*
>* mtk_vdec_lock/mtk_vdec_unlock are for ctx instance to
> 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 dd749d41c75a..17cb3e3519eb 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,61 @@
> #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_ACTIVE0x10
> -#define VDEC_IRQ_CFG0x11
> -#define VDEC_IRQ_CLR0x10
> -#define VDEC_IRQ_CFG_REG0xa4
> -
> module_param(mtk_v4l2_dbg_level, int, 0644);
> module_param(mtk_vcodec_dbg, bool, 0644);
> +static struct of_device_id mtk_vdec_drv_ids[] = {
> +{
> +.compatible = "mediatek,mtk-vcodec-lat",
> +.data = (void *)MTK_VDEC_LAT0,
> +},
> +{
> +.compatible = "mediatek,mtk-vcodec-core",
> +.data = (void *)MTK_VDEC_CORE,
> +},
> +{},
> +};
Is this a duplicate of "mtk_vdec_comp_ids", found in mtk_vcodec_dec_hw.c?!
> +
> +static int mtk_vcodec_comp_device_check(struct mtk_vcodec_ctx *ctx)
> + {
> +struct mtk_vcodec_dev *vdec_dev = ctx->dev;
> +struct platform_device *pdev = vdec_dev->plat_dev;
> +struct device_node *comp_node;
> +enum mtk_vdec_hw_id comp_idx;
> +const struct of_device_id *of_id;
> +int i;
> +
> +for (i = 0; i < ARRAY_SIZE(mtk_vdec_drv_ids); i++) {
> +of_id = &mtk_vdec_drv_ids[i];
> +comp_node = of_find_compatible_node(NULL, NULL,
> +of_id->compatible);
> +if (!comp_node)
> +continue;
> +
> +if (!of_device_is_available(comp_node)) {
> +of_node_put(comp_node);
> +dev_err(&pdev->dev, "Fail to get MMSYS node\n");
> +continue;
> +}
> +
> +comp_idx = (enum mtk_vdec_hw_id)of_id->data;
> +vdec_dev->component_node[comp_idx] = comp_node;
> +
> +if (!test_bit(comp_idx, vdec_dev->hardware_bitmap)) {
> +dev_err(&pdev->dev, "Vdec comp_idx is not ready %d.",
> +comp_idx);
> +return -EINVAL;
> +}
> +}
> +
> +return 0;
> +}
> +
> static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void *priv)
> {
> struct mtk_vcodec_dev *dev = priv;
> @@ -95,6 +137,41 @@ static int mtk_vcodec_get_reg_bases(struct mtk_vcodec_dev
*dev)
> return 0;
> }
> +static int mtk_vcodec_init_dec_params(struct mtk_vcodec_dev *dev)
> +{
> +struc
RE: [PATCH 4/4] drm/i915: Fix oops on platforms w/o hpd support
> From: Ville Syrjälä > On Thu, Oct 14, 2021 at 12:18:23PM +0300, Jani Nikula wrote: > > On Thu, 14 Oct 2021, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > We don't have hpd support on i8xx/i915 which means > hotplug_funcs==NULL. > > > Let's not oops when loading the driver on one those machines. > > > > D'oh! > > > > Lemme guess, CI just casually dropped the machines from the results > > because they didn't boot? > > Dunno where the gdg has gone actually. Tomi? Both GDGs are dead to old age (PSU / power delivery). Tomi
Re: [lib/stackdepot] 1cd8ce52c5: BUG:unable_to_handle_page_fault_for_address
On 10/14/21 10:54, kernel test robot wrote:
>
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 1cd8ce52c520c26c513899fb5aee42b8e5f60d0d ("[PATCH v2] lib/stackdepot:
> allow optional init and stack_table allocation by kvmalloc()")
> url:
> https://github.com/0day-ci/linux/commits/Vlastimil-Babka/lib-stackdepot-allow-optional-init-and-stack_table-allocation-by-kvmalloc/20211012-170816
> base: git://anongit.freedesktop.org/drm-intel for-linux-next
>
> in testcase: rcutorture
> version:
> with following parameters:
>
> runtime: 300s
> test: cpuhotplug
> torture_type: srcud
>
> test-description: rcutorture is rcutorture kernel module load/unload test.
> test-url: https://www.kernel.org/doc/Documentation/RCU/torture.txt
>
>
> on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> +-+++
> | | a94a6d76c9 | 1cd8ce52c5 |
> +-+++
> | boot_successes | 30 | 0 |
> | boot_failures | 0 | 7 |
> | BUG:kernel_NULL_pointer_dereference,address | 0 | 2 |
> | Oops:#[##] | 0 | 7 |
> | EIP:stack_depot_save| 0 | 7 |
> | Kernel_panic-not_syncing:Fatal_exception| 0 | 7 |
> | BUG:unable_to_handle_page_fault_for_address | 0 | 5 |
> +-+++
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot
>
>
>
> [ 319.147926][ T259] BUG: unable to handle page fault for address: 0ec74110
> [ 319.149309][ T259] #PF: supervisor read access in kernel mode
> [ 319.150362][ T259] #PF: error_code(0x) - not-present page
> [ 319.151372][ T259] *pde =
> [ 319.151964][ T259] Oops: [#1] SMP
> [ 319.152617][ T259] CPU: 0 PID: 259 Comm: systemd-rc-loca Not tainted
> 5.15.0-rc1-00270-g1cd8ce52c520 #1
> [ 319.154514][ T259] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.12.0-1 04/01/2014
> [ 319.156200][ T259] EIP: stack_depot_save+0x12a/0x4d0
Cc Mike Rapoport, looks like:
- memblock_alloc() should have failed (I think, because page allocator
already took over?), but didn't. So apparently we got some area that wasn't
fully mapped.
- using slab_is_available() is not accurate enough to detect when to use
memblock or page allocator (kvmalloc in case of my patch). I have used it
because memblock_alloc_internal() checks the same condition to issue a warning.
Relevant part of dmesg.xz that was attached:
[1.589075][T0] Dentry cache hash table entries: 524288 (order: 9,
2097152 bytes, linear)
[1.592396][T0] Inode-cache hash table entries: 262144 (order: 8,
1048576 bytes, linear)
[2.916844][T0] allocated 31496920 bytes of page_ext
- this means we were allocating from page allocator by alloc_pages_exact_nid()
already
[2.918197][T0] mem auto-init: stack:off, heap alloc:off, heap free:on
[2.919683][T0] mem auto-init: clearing system memory may take some
time...
[2.921239][T0] Initializing HighMem for node 0 (000b67fe:000bffe0)
[ 23.023619][T0] Initializing Movable for node 0 (:)
[ 245.194520][T0] Checking if this processor honours the WP bit even in
supervisor mode...Ok.
[ 245.196847][T0] Memory: 2914460K/3145208K available (20645K kernel code,
5953K rwdata, 12624K rodata, 760K init, 8112K bss, 230748K reserved, 0K
cma-reserved, 155528K highmem)
[ 245.200521][T0] Stack Depot allocating hash table with memblock_alloc
- initializing stack depot as part of initializing page_owner, uses
memblock_alloc()
because slab_is_available() is still false
[ 245.212005][T0] Node 0, zone Normal: page owner found early allocated
0 pages
[ 245.213867][T0] Node 0, zone HighMem: page owner found early allocated
0 pages
[ 245.216126][T0] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2,
Nodes=1
- printed by slub's kmem_cache_init() after create_kmalloc_caches() setting
slab_state
to UP, making slab_is_available() true, but too late
In my local testing of the patch, when stackdepot was initialized through
page owner init, it was using kvmalloc() so slab_is_available() was true.
Looks like the exact order of slab vs page_owner alloc is non-deterministic,
could be arch-dependent or just random ordering of init calls. A wrong order
will exploit the apparent fact that slab_is_available() is not a good
indicator of using memblock vs page allocator, and we would need a better one.
Thoughts?
Re: [PATCH 4/4] drm/i915: Fix oops on platforms w/o hpd support
On Thu, Oct 14, 2021 at 09:31:40AM +, Sarvela, Tomi P wrote: > > From: Ville Syrjälä > > On Thu, Oct 14, 2021 at 12:18:23PM +0300, Jani Nikula wrote: > > > On Thu, 14 Oct 2021, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > > > > > > We don't have hpd support on i8xx/i915 which means > > hotplug_funcs==NULL. > > > > Let's not oops when loading the driver on one those machines. > > > > > > D'oh! > > > > > > Lemme guess, CI just casually dropped the machines from the results > > > because they didn't boot? > > > > Dunno where the gdg has gone actually. Tomi? > > Both GDGs are dead to old age (PSU / power delivery). We don't have spare PSUs to throw at them? Or are the boards also semi-dead due to rotted caps etc.? -- Ville Syrjälä Intel
RE: [PATCH 4/4] drm/i915: Fix oops on platforms w/o hpd support
> From: Ville Syrjälä > On Thu, Oct 14, 2021 at 09:31:40AM +, Sarvela, Tomi P wrote: > > > From: Ville Syrjälä > > > On Thu, Oct 14, 2021 at 12:18:23PM +0300, Jani Nikula wrote: > > > > On Thu, 14 Oct 2021, Ville Syrjala > > > > wrote: > > > > > From: Ville Syrjälä > > > > > > > > > > We don't have hpd support on i8xx/i915 which means > > > hotplug_funcs==NULL. > > > > > Let's not oops when loading the driver on one those machines. > > > > > > > > D'oh! > > > > > > > > Lemme guess, CI just casually dropped the machines from the results > > > > because they didn't boot? > > > > > > Dunno where the gdg has gone actually. Tomi? > > > > Both GDGs are dead to old age (PSU / power delivery). > > We don't have spare PSUs to throw at them? Or are the boards also > semi-dead due to rotted caps etc.? It could be MB caps, PSU caps, or PSU anything else. Nothing comes on when power is turned on, no fans, no leds, nothing. Same issue on both hosts. No surprises there, they're identical models. It could be CPU, but IIRC I already tried changing that. The PSU part is vendor-specific. Standard PSU maybe could be retrofitted, but that'd need some dedicated time. Tomi
Re: [RFC v1 3/6] drm: Add a capability flag to support additional flip completion signalling
On Mon, 13 Sep 2021 16:35:26 -0700
Vivek Kasireddy wrote:
> If a driver supports this capability, it means that there would be an
> additional signalling mechanism for a page flip completion in addition
> to out_fence or DRM_MODE_PAGE_FLIP_EVENT.
>
> This capability may only be relevant for Virtual KMS drivers and is currently
> used only by virtio-gpu. Also, it can provide a potential solution for:
> https://gitlab.freedesktop.org/wayland/weston/-/issues/514
>
> Signed-off-by: Vivek Kasireddy
> ---
> drivers/gpu/drm/drm_ioctl.c | 3 +++
> include/drm/drm_mode_config.h | 8
> include/uapi/drm/drm.h| 1 +
> 3 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 8b8744dcf691..8a420844f8bc 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -302,6 +302,9 @@ static int drm_getcap(struct drm_device *dev, void *data,
> struct drm_file *file_
> case DRM_CAP_CRTC_IN_VBLANK_EVENT:
> req->value = 1;
> break;
> + case DRM_CAP_RELEASE_FENCE:
> + req->value = dev->mode_config.release_fence;
> + break;
Hi Vivek,
is this actually necessary?
I would think that userspace figures out the existence of the release
fence capability by seeing that the KMS property "RELEASE_FENCE_PTR"
either exists or not.
However, would we not need a client cap instead?
If a KMS driver knows that userspace is aware of "RELEASE_FENCE_PTR"
and will use it when necessary, then the KMS driver can send the
pageflip completion without waiting for the host OS to signal the old
buffer as free for re-use.
If the KMS driver does not know that userspace can handle pageflip
completing "too early", then it has no choice but to wait until the old
buffer is really free before signalling pageflip completion.
Wouldn't that make sense?
Otherwise, this proposal sounds fine to me.
Thanks,
pq
> default:
> return -EINVAL;
> }
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 12b964540069..944bebf359d7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -935,6 +935,14 @@ struct drm_mode_config {
>*/
> bool normalize_zpos;
>
> + /**
> + * @release_fence:
> + *
> + * If this option is set, it means there would be an additional
> signalling
> + * mechanism for a page flip completion.
> + */
> + bool release_fence;
> +
> /**
>* @modifiers_property: Plane property to list support modifier/format
>* combination.
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 3b810b53ba8b..8b8985f65581 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -767,6 +767,7 @@ struct drm_gem_open {
> * Documentation/gpu/drm-mm.rst, section "DRM Sync Objects".
> */
> #define DRM_CAP_SYNCOBJ_TIMELINE 0x14
> +#define DRM_CAP_RELEASE_FENCE0x15
>
> /* DRM_IOCTL_GET_CAP ioctl argument type */
> struct drm_get_cap {
pgpDLeKtd4h0h.pgp
Description: OpenPGP digital signature
[PATCH v2 2/2] drm: panel-simple: Add support for the Innolux G070Y2-T02 panel
Add compatible and timings for the Innolux G070Y2-T02 panel. It is 7"
WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 6451114b1be3..4d535a7a7d13 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2524,6 +2524,31 @@ static const struct panel_desc innolux_g070y2_l01 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode innolux_g070y2_t02_mode = {
+ .clock = 3,
+ .hdisplay = 800,
+ .hsync_start = 800 + 210,
+ .hsync_end = 800 + 210 + 20,
+ .htotal = 800 + 210 + 20 + 46,
+ .vdisplay = 480,
+ .vsync_start = 480 + 22,
+ .vsync_end = 480 + 22 + 10,
+ .vtotal = 480 + 22 + 23 + 10,
+};
+
+static const struct panel_desc innolux_g070y2_t02 = {
+ .modes = &innolux_g070y2_t02_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 152,
+ .height = 92,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct display_timing innolux_g101ice_l01_timing = {
.pixelclock = { 6040, 7110, 7470 },
.hactive = { 1280, 1280, 1280 },
@@ -4695,6 +4720,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,g070y2-l01",
.data = &innolux_g070y2_l01,
+ }, {
+ .compatible = "innolux,g070y2-t02",
+ .data = &innolux_g070y2_t02,
}, {
.compatible = "innolux,g101ice-l01",
.data = &innolux_g101ice_l01
--
2.30.2
[PATCH v2 1/2] dt-bindings: display: simple: add Innolux G070Y2-T02 panel
Add binding for the Innolux G070Y2-T02 panel. It is 7" WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit. Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 335776c45474..2f1c0928d260 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -166,6 +166,8 @@ properties: - innolux,at070tn92 # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel - innolux,g070y2-l01 +# Innolux G070Y2-T02 7" WVGA (800x480) TFT LCD TTL panel + - innolux,g070y2-t02 # Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel - innolux,g101ice-l01 # Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel -- 2.30.2
Re: [PATCH v7, 07/15] media: mtk-vcodec: Add irq interface for multi hardware
Adds irq interface for multi hardware.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 33 +--
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 2 +-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 25 ++
.../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 4 +--
.../platform/mtk-vcodec/mtk_vcodec_intr.c | 27 +++
.../platform/mtk-vcodec/mtk_vcodec_intr.h | 4 +--
.../platform/mtk-vcodec/vdec/vdec_h264_if.c | 2 +-
.../mtk-vcodec/vdec/vdec_h264_req_if.c| 2 +-
.../platform/mtk-vcodec/vdec/vdec_vp8_if.c| 2 +-
.../platform/mtk-vcodec/vdec/vdec_vp9_if.c| 2 +-
.../platform/mtk-vcodec/venc/venc_h264_if.c | 2 +-
.../platform/mtk-vcodec/venc/venc_vp8_if.c| 2 +-
12 files changed, 71 insertions(+), 36 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 17cb3e3519eb..ff70fa5b34e3 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -73,6 +73,20 @@ static int mtk_vcodec_comp_device_check(struct
mtk_vcodec_ctx *ctx)
return 0;
}
+static int mtk_vcodec_get_hw_count(struct mtk_vcodec_dev *dev)
+{
+ switch (dev->vdec_pdata->hw_arch) {
+ case MTK_VDEC_PURE_SINGLE_CORE:
+return MTK_VDEC_ONE_CORE;
+ case MTK_VDEC_LAT_SINGLE_CORE:
+ return MTK_VDEC_ONE_LAT_ONE_CORE;
+ default:
+ mtk_v4l2_err("not support hw arch:%d",
+ dev->vdec_pdata->hw_arch);
+ return MTK_VDEC_NO_HW;
+ }
+}
+
static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void *priv)
{
struct mtk_vcodec_dev *dev = priv;
@@ -104,7 +118,7 @@ static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void
*priv)
writel((readl(vdec_misc_addr) & ~VDEC_IRQ_CLR),
dev->reg_base[VDEC_MISC] + VDEC_IRQ_CFG_REG);
- wake_up_ctx(ctx, MTK_INST_IRQ_RECEIVED);
+ wake_up_ctx(ctx, MTK_INST_IRQ_RECEIVED, 0);
mtk_v4l2_debug(3,
"mtk_vcodec_dec_irq_handler :wake up ctx %d,
dec_done_status=%x",
@@ -176,7 +190,7 @@ static int fops_vcodec_open(struct file *file)
{
struct mtk_vcodec_dev *dev = video_drvdata(file);
struct mtk_vcodec_ctx *ctx = NULL;
- int ret = 0;
+ int ret = 0, i, hw_count;
struct vb2_queue *src_vq;
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -190,7 +204,19 @@ static int fops_vcodec_open(struct file *file)
v4l2_fh_add(&ctx->fh);
INIT_LIST_HEAD(&ctx->list);
ctx->dev = dev;
- init_waitqueue_head(&ctx->queue);
+
+ if (ctx->dev->vdec_pdata->is_comp_supported) {
As pointed out in the review for patch 04/15 of this series, is_comp_supported
is always false since you moved away from the component framework.
That means that this code can be removed, as nothing ever hits that.
Please note that other patches in this series are following similar/same
patterns,
so this comment applies to the entire series.
+ hw_count = mtk_vcodec_get_hw_count(dev);
+ if (!hw_count) {
+ ret = -EINVAL;
+ goto err_init_queue;
+ }
+ for (i = 0; i < hw_count; i++)
+ init_waitqueue_head(&ctx->queue[i]);
+ } else {
+ init_waitqueue_head(&ctx->queue[0]);
+ }
+
mutex_init(&ctx->lock);
ret = mtk_vcodec_comp_device_check(ctx);
@@ -253,6 +279,7 @@ static int fops_vcodec_open(struct file *file)
err_m2m_ctx_init:
v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
err_ctrls_setup:
+err_init_queue:
...and if that unused component code gets removed, this label can also be
removed.
v4l2_fh_del(&ctx->fh);
v4l2_fh_exit(&ctx->fh);
kfree(ctx);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
index 3752ccaea284..0997a5a08156 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
@@ -56,7 +56,7 @@ static irqreturn_t mtk_vdec_comp_irq_handler(int irq, void
*priv)
writel(dec_done_status | VDEC_IRQ_CFG, vdec_misc_addr);
writel(dec_done_status & ~VDEC_IRQ_CLR, vdec_misc_addr);
- wake_up_ctx(ctx, MTK_INST_IRQ_RECEIVED);
+ wake_up_ctx(ctx, MTK_INST_IRQ_RECEIVED, dev->comp_idx);
mtk_v4l2_debug(3, "wake up ctx %d, dec_done_status=%x",
ctx->id, dec_done_status);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 140f1a761942..f8e8b5ba408b 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -104,6 +104,16 @@ enum mtk_vdec_hw_i
Re: [lib/stackdepot] 1cd8ce52c5: BUG:unable_to_handle_page_fault_for_address
On Thu, Oct 14, 2021 at 11:33:03AM +0200, Vlastimil Babka wrote:
> On 10/14/21 10:54, kernel test robot wrote:
> >
> >
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 1cd8ce52c520c26c513899fb5aee42b8e5f60d0d ("[PATCH v2]
> > lib/stackdepot: allow optional init and stack_table allocation by
> > kvmalloc()")
> > url:
> > https://github.com/0day-ci/linux/commits/Vlastimil-Babka/lib-stackdepot-allow-optional-init-and-stack_table-allocation-by-kvmalloc/20211012-170816
> > base: git://anongit.freedesktop.org/drm-intel for-linux-next
> >
> > in testcase: rcutorture
> > version:
> > with following parameters:
> >
> > runtime: 300s
> > test: cpuhotplug
> > torture_type: srcud
> >
> > test-description: rcutorture is rcutorture kernel module load/unload test.
> > test-url: https://www.kernel.org/doc/Documentation/RCU/torture.txt
> >
> >
> > on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire
> > log/backtrace):
> >
> >
> > +-+++
> > | | a94a6d76c9 | 1cd8ce52c5 |
> > +-+++
> > | boot_successes | 30 | 0 |
> > | boot_failures | 0 | 7 |
> > | BUG:kernel_NULL_pointer_dereference,address | 0 | 2 |
> > | Oops:#[##] | 0 | 7 |
> > | EIP:stack_depot_save| 0 | 7 |
> > | Kernel_panic-not_syncing:Fatal_exception| 0 | 7 |
> > | BUG:unable_to_handle_page_fault_for_address | 0 | 5 |
> > +-+++
> >
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot
> >
> >
> >
> > [ 319.147926][ T259] BUG: unable to handle page fault for address:
> > 0ec74110
> > [ 319.149309][ T259] #PF: supervisor read access in kernel mode
> > [ 319.150362][ T259] #PF: error_code(0x) - not-present page
> > [ 319.151372][ T259] *pde =
> > [ 319.151964][ T259] Oops: [#1] SMP
> > [ 319.152617][ T259] CPU: 0 PID: 259 Comm: systemd-rc-loca Not tainted
> > 5.15.0-rc1-00270-g1cd8ce52c520 #1
> > [ 319.154514][ T259] Hardware name: QEMU Standard PC (i440FX + PIIX,
> > 1996), BIOS 1.12.0-1 04/01/2014
> > [ 319.156200][ T259] EIP: stack_depot_save+0x12a/0x4d0
>
>
> Cc Mike Rapoport, looks like:
> - memblock_alloc() should have failed (I think, because page allocator
> already took over?), but didn't. So apparently we got some area that wasn't
> fully mapped.
> - using slab_is_available() is not accurate enough to detect when to use
> memblock or page allocator (kvmalloc in case of my patch). I have used it
> because memblock_alloc_internal() checks the same condition to issue a
> warning.
>
> Relevant part of dmesg.xz that was attached:
> [1.589075][T0] Dentry cache hash table entries: 524288 (order: 9,
> 2097152 bytes, linear)
> [1.592396][T0] Inode-cache hash table entries: 262144 (order: 8,
> 1048576 bytes, linear)
> [2.916844][T0] allocated 31496920 bytes of page_ext
>
> - this means we were allocating from page allocator by
> alloc_pages_exact_nid() already
>
> [2.918197][T0] mem auto-init: stack:off, heap alloc:off, heap free:on
> [2.919683][T0] mem auto-init: clearing system memory may take some
> time...
> [2.921239][T0] Initializing HighMem for node 0 (000b67fe:000bffe0)
> [ 23.023619][T0] Initializing Movable for node 0 (:)
> [ 245.194520][T0] Checking if this processor honours the WP bit even in
> supervisor mode...Ok.
> [ 245.196847][T0] Memory: 2914460K/3145208K available (20645K kernel
> code, 5953K rwdata, 12624K rodata, 760K init, 8112K bss, 230748K reserved, 0K
> cma-reserved, 155528K highmem)
> [ 245.200521][T0] Stack Depot allocating hash table with memblock_alloc
>
> - initializing stack depot as part of initializing page_owner, uses
> memblock_alloc()
> because slab_is_available() is still false
>
> [ 245.212005][T0] Node 0, zone Normal: page owner found early
> allocated 0 pages
> [ 245.213867][T0] Node 0, zone HighMem: page owner found early
> allocated 0 pages
> [ 245.216126][T0] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2,
> Nodes=1
>
> - printed by slub's kmem_cache_init() after create_kmalloc_caches() setting
> slab_state
> to UP, making slab_is_available() true, but too late
>
> In my local testing of the patch, when stackdepot was initialized through
> page owner init, it was using kvmalloc() so slab_is_available() was true.
> Looks like the exact order of slab vs page_owne
[PATCH 2/2] drm/msm: Fix missing include files in msm_gem_shrinker.c
Include linux/vmalloc.h to fix below errors: error: implicit declaration of function 'register_vmap_purge_notifier' error: implicit declaration of function 'unregister_vmap_purge_notifier' Signed-off-by: Yanteng Si --- drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c b/drivers/gpu/drm/msm/msm_gem_shrinker.c index 0f1b29ee04a9..4a1420b05e97 100644 --- a/drivers/gpu/drm/msm/msm_gem_shrinker.c +++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c @@ -4,6 +4,8 @@ * Author: Rob Clark */ +#include + #include "msm_drv.h" #include "msm_gem.h" #include "msm_gpu.h" -- 2.27.0
[PATCH 0/2] drm/msm: fix build error
Include linux/vmalloc.h to fix below errors: error: implicit declaration of function 'vmap'; error: implicit declaration of function 'register_vmap_purge_notifier' error: implicit declaration of function 'unregister_vmap_purge_notifier' Yanteng Si (2): drm/msm: Fix missing include files in msm_gem.c drm/msm: Fix missing include files in msm_gem_shrinker.c drivers/gpu/drm/msm/msm_gem.c | 1 + drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 ++ 2 files changed, 3 insertions(+) -- 2.27.0
[PATCH 1/2] drm/msm: Fix missing include files in msm_gem.c
Include linux/vmalloc.h to fix below errors: error: implicit declaration of function 'vmap' Signed-off-by: Yanteng Si --- drivers/gpu/drm/msm/msm_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 40a9863f5951..198caa9c22e4 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -5,6 +5,7 @@ */ #include +#include #include #include #include -- 2.27.0
[PATCH v3] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME
From: Guangming Cao
In this patch(https://patchwork.freedesktop.org/patch/310349),
it add a new IOCTL to support dma-buf user to set debug name.
But it also added a limitation of this IOCTL, it needs the
attachments of dmabuf should be empty, otherwise it will fail.
For the original series, the idea was that allowing name change
mid-use could confuse the users about the dma-buf.
However, the rest of the series also makes sure each dma-buf have a unique
inode(https://patchwork.freedesktop.org/patch/310387/), and any accounting
should probably use that, without relying on the name as much.
So, removing this restriction will let dma-buf userspace users to use it
more comfortably and without any side effect.
Signed-off-by: Guangming Cao
---
drivers/dma-buf/dma-buf.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 511fe0d217a0..5fbb3a2068a3 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
/**
* dma_buf_set_name - Set a name to a specific dma_buf to track the usage.
- * The name of the dma-buf buffer can only be set when the dma-buf is not
- * attached to any devices. It could theoritically support changing the
- * name of the dma-buf if the same piece of memory is used for multiple
- * purpose between different devices.
+ * It could support changing the name of the dma-buf if the same
+ * piece of memory is used for multiple purpose between different devices.
*
* @dmabuf: [in] dmabuf buffer that will be renamed.
* @buf:[in] A piece of userspace memory that contains the name of
@@ -341,25 +339,16 @@ static __poll_t dma_buf_poll(struct file *file,
poll_table *poll)
static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf)
{
char *name = strndup_user(buf, DMA_BUF_NAME_LEN);
- long ret = 0;
if (IS_ERR(name))
return PTR_ERR(name);
- dma_resv_lock(dmabuf->resv, NULL);
- if (!list_empty(&dmabuf->attachments)) {
- ret = -EBUSY;
- kfree(name);
- goto out_unlock;
- }
spin_lock(&dmabuf->name_lock);
kfree(dmabuf->name);
dmabuf->name = name;
spin_unlock(&dmabuf->name_lock);
-out_unlock:
- dma_resv_unlock(dmabuf->resv);
- return ret;
+ return 0;
}
static long dma_buf_ioctl(struct file *file,
--
2.17.1
[PATCH v3] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME
From: Guangming Cao
On Wed, 2021-10-13 at 14:20 +0200, Christian König wrote:
> Am 13.10.21 um 01:56 schrieb Sumit Semwal:
> > Hello Guangming, Christian,
> >
> >
> >
> > On Tue, 12 Oct 2021, 14:09 , wrote:
> > > From: Guangming Cao
> > >
> > > > Am 09.10.21 um 07:55 schrieb guangming@mediatek.com:
> > > > From: Guangming Cao
> > > > >
> > > > > If dma-buf don't want userspace users to touch the dmabuf
> > > buffer,
> > > > > it seems we should add this restriction into
> > > dma_buf_ops.mmap,
> > > > > not in this IOCTL:DMA_BUF_SET_NAME.
> > > > >
> > > > > With this restriction, we can only know the kernel users of
> > > the dmabuf
> > > > > by attachments.
> > > > > However, for many userspace users, such as userpsace users of
> > > dma_heap,
> > > > > they also need to mark the usage of dma-buf, and they don't
> > > care about
> > > > > who attached to this dmabuf, and seems it's no meaning to be
> > > waiting for
> > > > > IOCTL:DMA_BUF_SET_NAME rather than mmap.
> > > >
> > > > Sounds valid to me, but I have no idea why this restriction was
> > > added in
> > > > the first place.
> > > >
> > > > Can you double check the git history and maybe identify when
> > > that was
> > > > added? Mentioning this change in the commit message then might
> > > make
> > > > things a bit easier to understand.
> > > >
> > > > Thanks,
> > > > Christian.
> > > It was add in this patch:
> > > https://patchwork.freedesktop.org/patch/310349/.
> > > However, there is no illustration about it.
> > > I guess it wants users to set_name when no attachments on the
> > > dmabuf,
> > > for case with attachments, we can find owner by device in
> > > attachments.
> > > But just I said in commit message, this is might not a good idea.
> > >
> > > Do you have any idea?
> > >
> >
> > For the original series, the idea was that allowing name change
> > mid-use could confuse the users about the dma-buf. However, the
> > rest of the series also makes sure each dma-buf have a unique
> > inode, and any accounting should probably use that, without relying
> > on the name as much.
> > So I don't have an objection to this change.
>
> I suggest to add that explanation and the original commit id into the
> commit message.
>
> With that changed the patch has my rb as well.
>
> Regards,
> Christian.
>
updated, thanks!
Guangming.
> > Best,
> > Sumit.
> > > >
> > > > >
> > > > > Signed-off-by: Guangming Cao
> > > > > ---
> > > > > drivers/dma-buf/dma-buf.c | 14 ++
> > > > > 1 file changed, 2 insertions(+), 12 deletions(-)
> > > > >
> > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-
> > > buf.c
> > > > > index 511fe0d217a0..db2f4efdec32 100644
> > > > > --- a/drivers/dma-buf/dma-buf.c
> > > > > +++ b/drivers/dma-buf/dma-buf.c
> > > > > @@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file
> > > *file, poll_table *poll)
> > > > >
> > > > > /**
> > > > >* dma_buf_set_name - Set a name to a specific dma_buf to
> > > track the usage.
> > > > > - * The name of the dma-buf buffer can only be set when the
> > > dma-buf is not
> > > > > - * attached to any devices. It could theoritically support
> > > changing the
> > > > > - * name of the dma-buf if the same piece of memory is used
> > > for multiple
> > > > > - * purpose between different devices.
> > > > > + * It could theoretically support changing the name of the
> > > dma-buf if the same
> > > > > + * piece of memory is used for multiple purpose between
> > > different devices.
> > > > >*
> > > > >* @dmabuf: [in] dmabuf buffer that will be renamed.
> > > > >* @buf:[in] A piece of userspace memory that
> > > contains the name of
> > > > > @@ -346,19 +344,11 @@ static long dma_buf_set_name(struct
> > > dma_buf *dmabuf, const char __user *buf)
> > > > > if (IS_ERR(name))
> > > > > return PTR_ERR(name);
> > > > >
> > > > > - dma_resv_lock(dmabuf->resv, NULL);
> > > > > - if (!list_empty(&dmabuf->attachments)) {
> > > > > - ret = -EBUSY;
> > > > > - kfree(name);
> > > > > - goto out_unlock;
> > > > > - }
> > > > > spin_lock(&dmabuf->name_lock);
> > > > > kfree(dmabuf->name);
> > > > > dmabuf->name = name;
> > > > > spin_unlock(&dmabuf->name_lock);
> > > > >
> > > > > -out_unlock:
> > > > > - dma_resv_unlock(dmabuf->resv);
> > > > > return ret;
> > > > > }
> > > > >
> > >
>
Re: [PATCH v7, 08/15] media: mtk-vcodec: Add msg queue feature for lat and core architecture
For lat and core architecture, lat thread will send message to core
thread when lat decode done. Core hardware will use the message
from lat to decode, then free message to lat thread when decode done.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 5 +
.../platform/mtk-vcodec/vdec_msg_queue.c | 258 ++
.../platform/mtk-vcodec/vdec_msg_queue.h | 151 ++
4 files changed, 415 insertions(+)
create mode 100644 drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
create mode 100644 drivers/media/platform/mtk-vcodec/vdec_msg_queue.h
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index edeb3b66e9e9..5000e59da576 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -11,6 +11,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
mtk_vcodec_dec_drv.o \
vdec_drv_if.o \
vdec_vpu_if.o \
+ vdec_msg_queue.o \
mtk_vcodec_dec.o \
mtk_vcodec_dec_stateful.o \
mtk_vcodec_dec_stateless.o \
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index f8e8b5ba408b..ab401b2db30e 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -15,7 +15,9 @@
#include
#include
#include
+
#include "mtk_vcodec_util.h"
+#include "vdec_msg_queue.h"
#define MTK_VCODEC_DRV_NAME "mtk_vcodec_drv"
#define MTK_VCODEC_DEC_NAME "mtk-vcodec-dec"
@@ -282,6 +284,8 @@ struct vdec_pic_info {
* @decoded_frame_cnt: number of decoded frames
* @lock: protect variables accessed by V4L2 threads and worker thread such as
* mtk_video_dec_buf.
+ *
+ * @msg_queue: msg queue used to store lat buffer information.
*/
struct mtk_vcodec_ctx {
enum mtk_instance_type type;
@@ -325,6 +329,7 @@ struct mtk_vcodec_ctx {
int decoded_frame_cnt;
struct mutex lock;
+ struct vdec_msg_queue msg_queue;
};
enum mtk_chip {
diff --git a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
new file mode 100644
index ..d66ed98c79a9
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Author: Yunfei Dong
+ */
+
+#include
+#include
+#include
+
+#include "mtk_vcodec_dec_pm.h"
+#include "mtk_vcodec_drv.h"
+#include "vdec_msg_queue.h"
+
+#define VDEC_LAT_SLICE_HEADER_SZ(640 * 1024)
This can be 640 * SZ_1K, or 5 * SZ_128K
...if applicable, please multiply as value * alignment, such that, for example,
if the data needs to be 1K aligned, you should prefer writing it as 640 * SZ_1K.
+#define VDEC_ERR_MAP_SZ_AVC ((8192 / 16) * (4352 / 16) / 8)
...and you could do the same here... except, I see some sizes here being divided
and multiplied and I take that as a hint.
In that case, when you convert it to use sizes definitions, it would be very
nice
if you keep that hint / better describe it in a comment.
+
+/* lat write decoded hardware information to trans buffer,
+ * and core will read the trans buffer to decode again. The
+ * trans buffer size of FHD and 4K bitstreams are different.
+ */
+static int vde_msg_queue_get_trans_size(int width, int height)
+{
+ if (width > 1920 || height > 1088)
+ return (30 * 1024 * 1024);
So here we're referring to buffer sizes. 1024 * 1024 is SZ_1M, as defined in
linux/sizes.h.
Means that this can be simply
return 30 * SZ_1M;
+ else
+ return 6 * 1024 * 1024;
return 6 * SZ_1M;
+}
+
+void vdec_msg_queue_init_ctx(struct vdec_msg_queue_ctx *ctx,
+ int hardware_index)
+{
+ init_waitqueue_head(&ctx->ready_to_use);
+ INIT_LIST_HEAD(&ctx->ready_queue);
+ spin_lock_init(&ctx->ready_lock);
+ ctx->ready_num = 0;
+ ctx->hardware_index = hardware_index;
+}
+
+int vdec_msg_queue_init(
+ struct vdec_msg_queue *msg_queue,
+ struct mtk_vcodec_ctx *ctx,
+ core_decode_cb_t core_decode,
+ int private_size)
+{
+ struct vdec_lat_buf *lat_buf;
+ int i, err;
+
+ /* already init msg queue */
+ if (msg_queue->wdma_addr.size)
+ return 0;
+
+ vdec_msg_queue_init_ctx(&msg_queue->lat_ctx, MTK_VDEC_LAT0);
+ msg_queue->wdma_addr.size = vde_msg_queue_get_trans_size(
+ ctx->picinfo.buf_w, ctx->picinfo.buf_h);
+
+ err = mtk_vcodec_mem_alloc(ctx, &msg_queue->wdma_addr);
+ if (err) {
+ mtk_v4l2_err("failed to allocate wdma_addr buf");
+ return -ENOMEM;
+ }
+ msg_queue->wdma_rptr_addr = msg_queue->wdma_
Re: [PATCH v7, 09/15] media: mtk-vcodec: Generalize power and clock on/off interfaces
Generalizes power and clock on/off interfaces to support different hardware.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 +-
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 2 +-
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 4 +
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 76 ++--
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 8 +-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 2 +
.../platform/mtk-vcodec/mtk_vcodec_util.c | 87 ---
.../platform/mtk-vcodec/mtk_vcodec_util.h | 8 +-
.../media/platform/mtk-vcodec/vdec_drv_if.c | 21 ++---
9 files changed, 174 insertions(+), 40 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 ff70fa5b34e3..3ea1e96e0ec0 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -96,7 +96,7 @@ static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void
*priv)
void __iomem *vdec_misc_addr = dev->reg_base[VDEC_MISC] +
VDEC_IRQ_CFG_REG;
- ctx = mtk_vcodec_get_curr_ctx(dev);
+ ctx = mtk_vcodec_get_curr_ctx(dev, MTK_VDEC_CORE);
/* check if HW active or not */
cg_status = readl(dev->reg_base[0]);
@@ -245,7 +245,7 @@ static int fops_vcodec_open(struct file *file)
mtk_vcodec_dec_set_default_params(ctx);
if (v4l2_fh_is_singular(&ctx->fh)) {
- ret = mtk_vcodec_dec_pw_on(&dev->pm);
+ ret = mtk_vcodec_dec_pw_on(dev, MTK_VDEC_LAT0);
if (ret < 0)
goto err_load_fw;
/*
@@ -306,7 +306,7 @@ static int fops_vcodec_release(struct file *file)
mtk_vcodec_dec_release(ctx);
if (v4l2_fh_is_singular(&ctx->fh))
- mtk_vcodec_dec_pw_off(&dev->pm);
+ mtk_vcodec_dec_pw_off(dev, MTK_VDEC_LAT0);
v4l2_fh_del(&ctx->fh);
v4l2_fh_exit(&ctx->fh);
v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
index 0997a5a08156..78d25916395d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
@@ -37,7 +37,7 @@ static irqreturn_t mtk_vdec_comp_irq_handler(int irq, void
*priv)
void __iomem *vdec_misc_addr = dev->reg_base[VDEC_COMP_MISC] +
VDEC_IRQ_CFG_REG;
- ctx = mtk_vcodec_get_curr_ctx(dev->master_dev);
+ ctx = mtk_vcodec_get_curr_ctx(dev->master_dev, dev->comp_idx);
/* check if HW active or not */
cg_status = readl(dev->reg_base[VDEC_COMP_SYS]);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h
index 8d6e818a3474..0a4c2e6f5df2 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h
@@ -32,6 +32,8 @@ enum mtk_comp_hw_reg_idx {
* @master_dev: master device
* @reg_base: Mapped address of MTK Vcodec registers.
*
+ * @curr_ctx: The context that is waiting for codec hardware
+ *
* @dec_irq: decoder irq resource
* @pm: power management control
* @comp_idx: component index
@@ -41,6 +43,8 @@ struct mtk_vdec_comp_dev {
struct mtk_vcodec_dev *master_dev;
void __iomem *reg_base[VDEC_COMP_MAX];
+ struct mtk_vcodec_ctx *curr_ctx;
+
int dec_irq;
struct mtk_vcodec_pm pm;
int comp_idx;
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 20bd157a855c..183d4c4e36f0 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -5,11 +5,13 @@
*/
#include
+#include
#include
#include
#include
#include
+#include "mtk_vcodec_dec_hw.h"
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
@@ -84,10 +86,23 @@ void mtk_vcodec_release_dec_pm(struct mtk_vcodec_pm *pm)
put_device(pm->larbvdec);
}
-int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
+int mtk_vcodec_dec_pw_on(struct mtk_vcodec_dev *vdec_dev, int comp_idx)
{
+ struct mtk_vdec_comp_dev *comp_dev;
+ struct mtk_vcodec_pm *pm;
int ret;
+ if (vdec_dev->vdec_pdata->is_comp_supported) {
This code is never hit, is_comp_supported is never true.
+ comp_dev = mtk_vcodec_get_hw_dev(vdec_dev, comp_idx);
+ if (!comp_dev) {
+ mtk_v4l2_err("Failed to get hw dev\n");
+ return -EINVAL;
+ }
+ pm = &comp_dev->pm;
+ } else {
+ pm = &vdec_dev->pm;
+ }
+
ret = pm_runtime_resume_and_get(pm->dev)
Re: [PATCH v7, 10/15] media: mtk-vcodec: Add new interface to lock different hardware
For add new hardware, not only need to lock lat hardware, also need to lock core hardware in case of different instance start to decoder at the same time. Signed-off-by: Yunfei Dong --- Reviewed-By: AngeloGioacchino Del Regno
Re: [PATCH v7, 11/15] media: mtk-vcodec: Add core thread
Core thread:
1. Gets lat_buf from core msg queue.
2. Proceeds core decode.
3. Puts the lat_buf back to lat msg queue.
Both H264 and VP9 rely on the core thread.
Signed-off-by: Yunfei Dong
I would be happier to see a better commit message, for example:
"Introduce a core thread, responsible for... getting lat_buf from ...
which then proceeds core decode by ... and finally, puts the lat_buf
back to the lat message queue"
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 12 +++
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 7
.../platform/mtk-vcodec/vdec_msg_queue.c | 32 +++
.../platform/mtk-vcodec/vdec_msg_queue.h | 6
4 files changed, 57 insertions(+)
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 e21e0c4bcd86..de83e3b821b4 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -364,6 +364,18 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
goto err_dec_pm;
}
+ if (VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) {
+ vdec_msg_queue_init_ctx(&dev->msg_queue_core_ctx,
+ MTK_VDEC_CORE);
No need to break this line.
+ dev->kthread_core = kthread_run(vdec_msg_queue_core_thead, dev,
+ "mtk-%s", "core");
Please fix indentation, like so:
dev->kthread_core = kthread_run(vdec_msg_queue_core_thead, dev,
"mtk-%s", "core");
+ if (IS_ERR(dev->kthread_core)) {
+ dev_err(&pdev->dev, "Failed to create core thread");
+ ret = PTR_ERR(dev->kthread_core);
+ goto err_res;
+ }
+ }
+
for (i = 0; i < MTK_VDEC_HW_MAX; i++)
mutex_init(&dev->dec_mutex[i]);
spin_lock_init(&dev->irqlock);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 9d072c082f73..68a9b1a2d3b3 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_BENCHMARK0
#define WAIT_INTR_TIMEOUT_MS 1000
+#define VDEC_LAT_ARCH(hw_arch) ((hw_arch) >= MTK_VDEC_LAT_SINGLE_CORE)
I'd propose to change this to IS_VDEC_LAT_ARCH(hw_arch): that would increase
human
readability when using this macro.
/*
* enum mtk_hw_reg_idx - MTK hw register base index
@@ -466,6 +467,9 @@ struct mtk_vcodec_enc_pdata {
* @comp_dev: component hardware device
* @component_node: component node
*
+ * @kthread_core: thread used for core hardware decode
+ * @msg_queue_core_ctx: msg queue context used for core thread
+ *
* @hardware_bitmap: used to record hardware is ready or not
*/
struct mtk_vcodec_dev {
@@ -508,6 +512,9 @@ struct mtk_vcodec_dev {
void *comp_dev[MTK_VDEC_HW_MAX];
struct device_node *component_node[MTK_VDEC_HW_MAX];
+ struct task_struct *kthread_core;
+ struct vdec_msg_queue_ctx msg_queue_core_ctx;
+
DECLARE_BITMAP(hardware_bitmap, 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 d66ed98c79a9..665f571eab4b 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
@@ -256,3 +256,35 @@ void vdec_msg_queue_deinit(
kfree(lat_buf->private_data);
}
}
+
+int vdec_msg_queue_core_thead(void *data)
+{
+ struct mtk_vcodec_dev *dev = data;
+ struct vdec_lat_buf *lat_buf;
+ struct mtk_vcodec_ctx *ctx;
+
+ set_freezable();
+ for (;;) {
+ try_to_freeze();
+ if (kthread_should_stop())
+ break;
+
+ lat_buf = vdec_msg_queue_dqbuf(&dev->msg_queue_core_ctx);
+ if (!lat_buf)
+ continue;
+
+ ctx = lat_buf->ctx;
+ mtk_vcodec_set_curr_ctx(dev, ctx, MTK_VDEC_CORE);
+
+ if (!lat_buf->core_decode)
+ mtk_v4l2_err("Core decode callback func is NULL");
Is this supposed to really happen?
I see that this is always initialized in function vdec_msg_queue_init().
Regards,
- Angelo
Re: [PATCH v7, 12/15] media: mtk-vcodec: Support 34bits dma address for vdec
Use the dma_set_mask_and_coherent helper to set vdec DMA bit mask to support 34bits iova space(16GB) that the mt8192 iommu HW support. Whole the iova range separate to 0~4G/4G~8G/8G~12G/12G~16G, regarding which iova range VDEC actually locate, it depends on the dma-ranges property of vdec dtsi node. Signed-off-by: Yunfei Dong --- drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 3 +++ 1 file changed, 3 insertions(+) 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 de83e3b821b4..da963cdac96b 100644 --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c @@ -376,6 +376,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev) } } + if (of_get_property(pdev->dev.of_node, "dma-ranges", NULL)) + dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(34)); + This function returns 0 for success, or negative number for failure: please check the return value, or this driver may not work correctly in some corner cases. Regards, - Angelo for (i = 0; i < MTK_VDEC_HW_MAX; i++) mutex_init(&dev->dec_mutex[i]); spin_lock_init(&dev->irqlock);
Re: [PATCH v7, 14/15] media: mtk-vcodec: Add core dec and dec end ipi msg
Add core dec and dec end ipi msg: AP_IPIMSG_DEC_CORE/AP_IPIMSG_DEC_CORE_END. Signed-off-by: Yunfei Dong --- .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 4 .../media/platform/mtk-vcodec/vdec_vpu_if.c| 12 .../media/platform/mtk-vcodec/vdec_vpu_if.h| 18 ++ 3 files changed, 34 insertions(+) Reviewed-By: AngeloGioacchino Del Regno
Re: [PATCH v7, 15/15] media: mtk-vcodec: Use codec type to separate different hardware
There are just one core thread, in order to separeate different hardware, using codec type to separeate it in scp driver. Signed-off-by: Yunfei Dong --- .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 --- .../media/platform/mtk-vcodec/vdec_vpu_if.c | 34 --- .../media/platform/mtk-vcodec/vdec_vpu_if.h | 4 +++ 3 files changed, 41 insertions(+), 9 deletions(-) Reviewed-By: AngeloGioacchino Del Regno
Re: [PATCH v7, 03/15] media: mtk-vcodec: Refactor vcodec pm interface
Using the needed param for pm init/release function and remove unused param mtkdev in 'struct mtk_vcodec_pm'. Reviewed-by: Tzung-Bi Shih Signed-off-by: Yunfei Dong --- .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 ++--- .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 22 --- .../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 5 +++-- .../platform/mtk-vcodec/mtk_vcodec_drv.h | 1 - .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 1 - 5 files changed, 15 insertions(+), 20 deletions(-) Acked-By: AngeloGioacchino Del Regno
Re: [PATCH v7, 02/15] media: mtk-vcodec: Align vcodec wake up interrupt interface
Il 11/10/21 09:02, Yunfei Dong ha scritto: Vdec and venc can use the same function to wake up interrupt event. Reviewed-by: Tzung-Bi Shih Signed-off-by: Yunfei Dong Reviewed-By: AngeloGioacchino Del Regno
Re: [PATCH v7, 06/15] media: mtk-vcodec: Use pure single core for MT8183
Separates different architecture for hardware: pure_sin_core and lat_sin_core. MT8183 is pure single core. Uses .hw_arch to distinguish. Signed-off-by: Yunfei Dong Acked-By: AngeloGioacchino Del Regno
Re: [PATCH 20/28] drm/i915: use new iterator in i915_gem_object_wait_reservation
Op 05-10-2021 om 13:37 schreef Christian König:
> Simplifying the code a bit.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 51 +---
> 1 file changed, 9 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> index f909aaa09d9c..a13193db1dba 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> @@ -37,55 +37,22 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
>unsigned int flags,
>long timeout)
> {
> - struct dma_fence *excl;
> - bool prune_fences = false;
> -
> - if (flags & I915_WAIT_ALL) {
> - struct dma_fence **shared;
> - unsigned int count, i;
> - int ret;
> + struct dma_resv_iter cursor;
> + struct dma_fence *fence;
>
> - ret = dma_resv_get_fences(resv, &excl, &count, &shared);
> - if (ret)
> - return ret;
> -
> - for (i = 0; i < count; i++) {
> - timeout = i915_gem_object_wait_fence(shared[i],
> - flags, timeout);
> - if (timeout < 0)
> - break;
> -
> - dma_fence_put(shared[i]);
> - }
> -
> - for (; i < count; i++)
> - dma_fence_put(shared[i]);
> - kfree(shared);
> -
> - /*
> - * If both shared fences and an exclusive fence exist,
> - * then by construction the shared fences must be later
> - * than the exclusive fence. If we successfully wait for
> - * all the shared fences, we know that the exclusive fence
> - * must all be signaled. If all the shared fences are
> - * signaled, we can prune the array and recover the
> - * floating references on the fences/requests.
> - */
> - prune_fences = count && timeout >= 0;
> - } else {
> - excl = dma_resv_get_excl_unlocked(resv);
> + dma_resv_iter_begin(&cursor, resv, flags & I915_WAIT_ALL);
> + dma_resv_for_each_fence_unlocked(&cursor, fence) {
> + timeout = i915_gem_object_wait_fence(fence, flags, timeout);
> + if (timeout < 0)
> + break;
> }
> -
> - if (excl && timeout >= 0)
> - timeout = i915_gem_object_wait_fence(excl, flags, timeout);
> -
> - dma_fence_put(excl);
> + dma_resv_iter_end(&cursor);
>
> /*
>* Opportunistically prune the fences iff we know they have *all* been
>* signaled.
>*/
> - if (prune_fences)
> + if (timeout > 0)
> dma_resv_prune(resv);
>
> return timeout;
When replying to tvrtko about correctness of the conversion, I just now noticed
a logic bug here, the same logic bug also affects dma_resv_wait_timeout.
long dma_resv_wait_timeout(struct dma_resv *obj, bool wait_all, bool intr,
unsigned long timeout)
{
long ret = timeout ? timeout : 1;
struct dma_resv_iter cursor;
struct dma_fence *fence;
dma_resv_iter_begin(&cursor, obj, wait_all);
dma_resv_for_each_fence_unlocked(&cursor, fence) {
ret = dma_fence_wait_timeout(fence, intr, ret);
if (ret <= 0) {
dma_resv_iter_end(&cursor);
return ret;
}
}
dma_resv_iter_end(&cursor);
return ret;
}
It fails to handle the case correctly when timeout = 0, I think the original
code probably did.
dma_fence_wait_timeout should be called with timeout = 0 explicitly.
Fixed code for inner loop:
ret = dma_fence_wait_timeout(fence, intr, timeout);
if (ret <= 0) break;
if (timeout) timeout = ret;
This bug also affects i915_gem_object_wait_reservation, so the whole series
might need to be
respinned, or at least checked, if more wait conversions are affected.
~Maarten
[PULL] drm-misc-next
Hi Dave, Daniel, Here's this week drm-misc-next PR Maxime drm-misc-next-2021-10-14: drm-misc-next for 5.16: UAPI Changes: Cross-subsystem Changes: Core Changes: - fbdev: Fix double-free, Remove unused scrolling acceleration - locking: improve logging for contented locks without backoff - dma-buf: Add dma_resv_for_each_fence iterator, and conversion of users Driver Changes: - nouveau: Various code style improvements - bridge: HPD improvements for lt9611uxc, eDP aux-bus support for ps8640, lvds-codec data-mapping selection support - panels: Vivax TPC-9150, Innolux G070Y2-T02, LOGIC Technologies LTTD800480070-L2RT, Sharp LS060T1SX01, The following changes since commit 9962601ca5719050906915c3c33a63744ac7b15c: drm/bridge: dw-hdmi-cec: Make use of the helper function devm_add_action_or_reset() (2021-10-06 11:21:46 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-10-14 for you to fetch changes up to b3ec8cdf457e5e63d396fe1346cc788cf7c1b578: fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list) (2021-10-13 15:29:23 +0200) drm-misc-next for 5.16: UAPI Changes: Cross-subsystem Changes: Core Changes: - fbdev: Fix double-free, Remove unused scrolling acceleration - locking: improve logging for contented locks without backoff - dma-buf: Add dma_resv_for_each_fence iterator, and conversion of users Driver Changes: - nouveau: Various code style improvements - bridge: HPD improvements for lt9611uxc, eDP aux-bus support for ps8640, lvds-codec data-mapping selection support - panels: Vivax TPC-9150, Innolux G070Y2-T02, LOGIC Technologies LTTD800480070-L2RT, Sharp LS060T1SX01, Alex Xu (Hello71) (1): drm/plane-helper: fix uninitialized variable reference Amos Kong (1): drm/ttm_bo_api: update the description for @placement and @sg Christian König (7): dma-buf: add dma_resv_for_each_fence v3 dma-buf: use the new iterator in dma_buf_debug_show dma-buf: use the new iterator in dma_resv_poll drm/ttm: use the new iterator in ttm_bo_flush_all_fences drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2 drm/i915: use the new iterator in i915_request_await_object v2 drm: use new iterator in drm_gem_fence_array_add_implicit v3 Claudio Suarez (1): fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list) Dan Carpenter (1): drm/v3d: fix copy_from_user() error codes David Heidelberg (1): dt-bindings: display: simple: hardware can use ddc-i2c-bus Dmitry Baryshkov (5): drm/bridge/lontium-lt9611uxc: fix provided connector suport dt-bindings: add bindings for the Sharp LS060T1SX01 panel drm/panel: Add support for Sharp LS060T1SX01 panel dt-bindings: add bindings for the Sharp LS060T1SX01 panel drm/panel: Add support for Sharp LS060T1SX01 panel Guido Günther (5): drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts drm/panel: mantix: Add media bus format drm/panel: st7703: Add media bus format drm: mxsfb: Print failed bus format in hex drm: mxsfb: Set fallback bus format when the bridge doesn't provide one Jani Nikula (1): drm/locking: add backtrace for locking contended locks without backoff Jing Xiangfeng (1): drm/virtio: fix the missed drm_gem_object_put() in virtio_gpu_user_framebuffer_create() Karol Herbst (1): drm/nouveau/mmu/gp100: remove unused variable Lee Jones (1): drm/nouveau/nouveau_bo: Remove unused variables 'dev' Luo penghao (2): drm/nouveau/mmu: drop unneeded assignment in the nvkm_uvmm_mthd_page() drm/nouveau/mmu/gp100-: drop unneeded assignment in the if condition. Marek Vasut (3): drm/bridge: ti-sn65dsi83: Implement .detach callback dt-bindings: display: bridge: lvds-codec: Document LVDS data mapping select drm/bridge: lvds-codec: Add support for LVDS data mapping select Nikola Pavlica (2): dt-bindings: add vendor prefix for Vivax dt-bindings: display: simple: Add Vivax TPC-9150 panel Oleksij Rempel (1): dt-bindings: display: simple: add Innolux G070Y2-T02 panel Philip Chen (1): dt-bindings: drm/bridge: ps8640: Add aux-bus child Randy Dunlap (1): drm/connector: fix all kernel-doc warnings Sam Ravnborg (2): Revert "drm/panel: Add support for Sharp LS060T1SX01 panel" Revert "dt-bindings: add bindings for the Sharp LS060T1SX01 panel" Simon Ser (1): drm/connector: refer to CTA-861-G in the "content type" prop docs Søren Andersen (1): drm/panel: panel-simple: add LOGIC Technologies LTTD800480070-L2RT panel Tvrtko Ursulin (1): dma-resv: Fix dma_resv_get_fences and dma_resv_copy_fences after conversion Uwe Kleine-König (1): drm/p
Re: [Intel-gfx] [PATCH] drm/i915: Use dma_resv_iter for waiting in i915_gem_object_wait_reservation.
Op 14-10-2021 om 10:37 schreef Tvrtko Ursulin:
>
> On 13/10/2021 11:41, Maarten Lankhorst wrote:
>> No memory should be allocated when calling i915_gem_object_wait,
>> because it may be called to idle a BO when evicting memory.
>>
>> Fix this by using dma_resv_iter helpers to call
>> i915_gem_object_wait_fence() on each fence, which cleans up the code a lot.
>> Also remove dma_resv_prune, it's questionably.
>>
>> This will result in the following lockdep splat.
>
>
>
>> @@ -37,56 +36,17 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
>> unsigned int flags,
>> long timeout)
>> {
>> - struct dma_fence *excl;
>> - bool prune_fences = false;
>> -
>> - if (flags & I915_WAIT_ALL) {
>> - struct dma_fence **shared;
>> - unsigned int count, i;
>> - int ret;
>> + struct dma_resv_iter cursor;
>> + struct dma_fence *fence;
>> - ret = dma_resv_get_fences(resv, &excl, &count, &shared);
>> - if (ret)
>> - return ret;
>> -
>> - for (i = 0; i < count; i++) {
>> - timeout = i915_gem_object_wait_fence(shared[i],
>> - flags, timeout);
>> - if (timeout < 0)
>> - break;
>> + dma_resv_iter_begin(&cursor, resv, flags & I915_WAIT_ALL);
>> + dma_resv_for_each_fence_unlocked(&cursor, fence) {
>> - dma_fence_put(shared[i]);
>> - }
>> -
>> - for (; i < count; i++)
>> - dma_fence_put(shared[i]);
>> - kfree(shared);
>> -
>> - /*
>> - * If both shared fences and an exclusive fence exist,
>> - * then by construction the shared fences must be later
>> - * than the exclusive fence. If we successfully wait for
>> - * all the shared fences, we know that the exclusive fence
>> - * must all be signaled. If all the shared fences are
>> - * signaled, we can prune the array and recover the
>> - * floating references on the fences/requests.
>> - */
>> - prune_fences = count && timeout >= 0;
>> - } else {
>> - excl = dma_resv_get_excl_unlocked(resv);
>> + timeout = i915_gem_object_wait_fence(fence, flags, timeout);
>> + if (timeout <= 0)
>> + break;
>
> You have another change in behaviour here, well a bug really. When userspace
> passes in zero timeout you fail to report activity in other than the first
> fence.
Hmm, not necessarily, passing 0 to i915_gem_object_wait_fence timeout = 0 is a
special case and means test only. It will return 1 on success.
Of course it is still broken, I sent a reply to könig about it, hope it will
get fixed and respun. :)
~Maarten
[PULL] drm-misc-fixes
drm-misc-fixes-2021-10-14: drm-misc-fixes for v5.15-rc6: - Respun clock fixes for vc4/hdmi. - Cap connector_bad_edid()'s num_of_ext by num_blocks read. - Clamp fbdev size to max available height. - Hide hyper-v's hw pointer, to prevent double pointers. - Use the correct engine bit in nouveau's g84_fifo_chan_engine_fini. - Build fix for r128 on UML. - Add missing dependency for CONFIG_CRC32 to olimex-lcd-olinuxino. The following changes since commit f5a8703a9c418c6fc54eb772712dfe7641e3991c: drm/nouveau/debugfs: fix file release memory leak (2021-10-06 11:12:29 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-10-14 for you to fetch changes up to 6de148d82d9e790caf7622a002229df745fd2d94: drm/vc4: crtc: Make sure the HDMI controller is powered when disabling (2021-10-13 14:40:43 +0200) drm-misc-fixes for v5.15-rc6: - Respun clock fixes for vc4/hdmi. - Cap connector_bad_edid()'s num_of_ext by num_blocks read. - Clamp fbdev size to max available height. - Hide hyper-v's hw pointer, to prevent double pointers. - Use the correct engine bit in nouveau's g84_fifo_chan_engine_fini. - Build fix for r128 on UML. - Add missing dependency for CONFIG_CRC32 to olimex-lcd-olinuxino. Dexuan Cui (1): drm/hyperv: Fix double mouse pointers Douglas Anderson (1): drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read Marek Vasut (1): drm/nouveau/fifo: Reinstate the correct engine bit programming Maxime Ripard (11): clk: bcm-2835: Pick the closest clock rate clk: bcm-2835: Remove rounding up the dividers drm/vc4: hdmi: Set a default HSM rate drm/vc4: hdmi: Move the HSM clock enable to runtime_pm drm/vc4: hdmi: Make sure the controller is powered in detect drm/vc4: hdmi: Make sure the controller is powered up during bind drm/vc4: hdmi: Rework the pre_crtc_configure error handling drm/vc4: hdmi: Split the CEC disable / enable functions in two drm/vc4: hdmi: Make sure the device is powered with CEC drm/vc4: hdmi: Warn if we access the controller while disabled drm/vc4: crtc: Make sure the HDMI controller is powered when disabling Randy Dunlap (1): drm/r128: fix build for UML Thomas Zimmermann (1): drm/fbdev: Clamp fbdev surface size if too large Vegard Nossum (1): drm/panel: olimex-lcd-olinuxino: select CRC32 drivers/clk/bcm/clk-bcm2835.c | 13 +- drivers/gpu/drm/drm_edid.c | 15 +- drivers/gpu/drm/drm_fb_helper.c| 6 + drivers/gpu/drm/hyperv/hyperv_drm.h| 1 + drivers/gpu/drm/hyperv/hyperv_drm_modeset.c| 1 + drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 54 +- drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c | 2 +- drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/r128/ati_pcigart.c | 2 +- drivers/gpu/drm/vc4/vc4_crtc.c | 19 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 208 ++--- drivers/gpu/drm/vc4/vc4_hdmi_regs.h| 6 + 12 files changed, 248 insertions(+), 80 deletions(-)
Re: [PATCH v7, 11/15] media: mtk-vcodec: Add core thread
Hi Yunfei,
On Mon, Oct 11, 2021 at 03:02:43PM +0800, Yunfei Dong wrote:
> Core thread:
> 1. Gets lat_buf from core msg queue.
> 2. Proceeds core decode.
> 3. Puts the lat_buf back to lat msg queue.
>
> Both H264 and VP9 rely on the core thread.
>
Avoid the kthread API and instead go with the workqueue API.
See Documentation/core-api/workqueue.rst and include/linux/workqueue.h.
Thanks!
Ezequiel
> Signed-off-by: Yunfei Dong
> ---
> .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 12 +++
> .../platform/mtk-vcodec/mtk_vcodec_drv.h | 7
> .../platform/mtk-vcodec/vdec_msg_queue.c | 32 +++
> .../platform/mtk-vcodec/vdec_msg_queue.h | 6
> 4 files changed, 57 insertions(+)
>
> 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 e21e0c4bcd86..de83e3b821b4 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> @@ -364,6 +364,18 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
> goto err_dec_pm;
> }
>
> + if (VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) {
> + vdec_msg_queue_init_ctx(&dev->msg_queue_core_ctx,
> + MTK_VDEC_CORE);
> + dev->kthread_core = kthread_run(vdec_msg_queue_core_thead, dev,
> + "mtk-%s", "core");
> + if (IS_ERR(dev->kthread_core)) {
> + dev_err(&pdev->dev, "Failed to create core thread");
> + ret = PTR_ERR(dev->kthread_core);
> + goto err_res;
> + }
> + }
> +
> for (i = 0; i < MTK_VDEC_HW_MAX; i++)
> mutex_init(&dev->dec_mutex[i]);
> spin_lock_init(&dev->irqlock);
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> index 9d072c082f73..68a9b1a2d3b3 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_PLANES3
> #define MTK_V4L2_BENCHMARK 0
> #define WAIT_INTR_TIMEOUT_MS 1000
> +#define VDEC_LAT_ARCH(hw_arch) ((hw_arch) >= MTK_VDEC_LAT_SINGLE_CORE)
>
> /*
> * enum mtk_hw_reg_idx - MTK hw register base index
> @@ -466,6 +467,9 @@ struct mtk_vcodec_enc_pdata {
> * @comp_dev: component hardware device
> * @component_node: component node
> *
> + * @kthread_core: thread used for core hardware decode
> + * @msg_queue_core_ctx: msg queue context used for core thread
> + *
> * @hardware_bitmap: used to record hardware is ready or not
> */
> struct mtk_vcodec_dev {
> @@ -508,6 +512,9 @@ struct mtk_vcodec_dev {
> void *comp_dev[MTK_VDEC_HW_MAX];
> struct device_node *component_node[MTK_VDEC_HW_MAX];
>
> + struct task_struct *kthread_core;
> + struct vdec_msg_queue_ctx msg_queue_core_ctx;
> +
> DECLARE_BITMAP(hardware_bitmap, 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 d66ed98c79a9..665f571eab4b 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> +++ b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> @@ -256,3 +256,35 @@ void vdec_msg_queue_deinit(
> kfree(lat_buf->private_data);
> }
> }
> +
> +int vdec_msg_queue_core_thead(void *data)
> +{
> + struct mtk_vcodec_dev *dev = data;
> + struct vdec_lat_buf *lat_buf;
> + struct mtk_vcodec_ctx *ctx;
> +
> + set_freezable();
> + for (;;) {
> + try_to_freeze();
> + if (kthread_should_stop())
> + break;
> +
> + lat_buf = vdec_msg_queue_dqbuf(&dev->msg_queue_core_ctx);
> + if (!lat_buf)
> + continue;
> +
> + ctx = lat_buf->ctx;
> + mtk_vcodec_set_curr_ctx(dev, ctx, MTK_VDEC_CORE);
> +
> + if (!lat_buf->core_decode)
> + mtk_v4l2_err("Core decode callback func is NULL");
> + else
> + lat_buf->core_decode(lat_buf);
> +
> + mtk_vcodec_set_curr_ctx(dev, NULL, MTK_VDEC_CORE);
> + vdec_msg_queue_qbuf(&ctx->msg_queue.lat_ctx, lat_buf);
> + }
> +
> + mtk_v4l2_debug(3, "Video Capture Thread End");
> + return 0;
> +}
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.h
> b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.h
> index 1905ce713592..b5745b144140 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.h
> +++ b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.h
> @@ -148,4 +148,10 @@ void vdec_msg_queue_deinit(
> struct vdec_msg_queue *msg_queue,
> struct mtk_vcodec_ctx *ctx);
>
> +/**
> + * vdec_msg_queue_core_thead - used for core decoder.
> + * @data: private data used for each
Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode
Hi Yunfei, On Tue, 12 Oct 2021 at 22:17, yunfei.d...@mediatek.com wrote: > > Hi Ezequiel, > > Thanks for your feedback, > > The driver can work well now according to your advice with > of_platform_populate interface. > > In order to separate parent node with children node, parent node is > master device, children node is component device. > > The master and component are registered platform device. > > > Could you please help to review the patch again when you are free: > > https://patchwork.linuxtv.org/project/linux-media/cover/20211011070247.792-1-yunfei.d...@mediatek.com/ > I'm glad you managed to simplify the driver. I tried applying the patches but they don't apply on media master. Please push a branch to gitlab or github or somewhere public. Keep in mind that when you need people to review your code, it's generally good practice to try to make it easy on them. The harder you make it, the less inclined people will be to spend time on your work. Thanks, Ezequiel
Re: [PATCH v3 7/7] drm/kmb: Enable support for framebuffer console
Hi
Am 14.10.21 um 01:36 schrieb Anitha Chrisanthus:
Enable support for fbcon (framebuffer console).
The user can initialize fbcon by loading kmb-drm with the parameter
console=1.
v2: added missing static clk_enable
Signed-off-by: Edmund Dea
Signed-off-by: Anitha Chrisanthus
---
drivers/gpu/drm/kmb/kmb_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c
index 961ac6fb5fcf..b4e66eac63b5 100644
--- a/drivers/gpu/drm/kmb/kmb_drv.c
+++ b/drivers/gpu/drm/kmb/kmb_drv.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -15,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -24,6 +26,12 @@
#include "kmb_dsi.h"
#include "kmb_regs.h"
+/* Module Parameters */
+static bool console;
+module_param(console, bool, 0400);
+MODULE_PARM_DESC(console,
+"Enable framebuffer console support (0=disable [default],
1=on)");
There's already fbdev_emulation in drm_fb_helper.c. No need for a
separate parameter here.
Best regards
Thomas
+
static int kmb_display_clk_enable(struct kmb_drm_private *kmb)
{
int ret = 0;
@@ -559,6 +567,9 @@ static int kmb_probe(struct platform_device *pdev)
if (ret)
goto err_register;
+ if (console)
+ drm_fbdev_generic_setup(&kmb->drm, 32);
+
return 0;
err_register:
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v3 7/7] drm/kmb: Enable support for framebuffer console
Hi
Am 14.10.21 um 01:36 schrieb Anitha Chrisanthus:
Enable support for fbcon (framebuffer console).
The user can initialize fbcon by loading kmb-drm with the parameter
console=1.
v2: added missing static clk_enable
Signed-off-by: Edmund Dea
Signed-off-by: Anitha Chrisanthus
---
drivers/gpu/drm/kmb/kmb_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c
index 961ac6fb5fcf..b4e66eac63b5 100644
--- a/drivers/gpu/drm/kmb/kmb_drv.c
+++ b/drivers/gpu/drm/kmb/kmb_drv.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -15,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -24,6 +26,12 @@
#include "kmb_dsi.h"
#include "kmb_regs.h"
+/* Module Parameters */
+static bool console;
+module_param(console, bool, 0400);
+MODULE_PARM_DESC(console,
+"Enable framebuffer console support (0=disable [default],
1=on)");
+
static int kmb_display_clk_enable(struct kmb_drm_private *kmb)
{
int ret = 0;
@@ -559,6 +567,9 @@ static int kmb_probe(struct platform_device *pdev)
if (ret)
goto err_register;
+ if (console)
+ drm_fbdev_generic_setup(&kmb->drm, 32);
The use of the final parameter is somewhat confusing and should probably
be 0. It's the number of bits per pixel. 32 is the default. But the
preferred way of selecting color mode is via
dev->mode_config.preferred_depth, which is the color depth (24!). So
maybe rather set preferred_depth to 24 and let the fbdev helper figure
out the details.
Best regards
Thomas
+
return 0;
err_register:
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: Regression with mainline kernel on rpi4
On Wed, Oct 13, 2021 at 05:01:03PM +0200, Maxime Ripard wrote: > On Thu, Sep 30, 2021 at 11:19:59AM +0200, Daniel Vetter wrote: > > On Tue, Sep 28, 2021 at 10:34:46AM +0200, Maxime Ripard wrote: > > > Hi Daniel, > > > > > > On Sat, Sep 25, 2021 at 12:50:17AM +0200, Daniel Vetter wrote: > > > > On Fri, Sep 24, 2021 at 3:30 PM Maxime Ripard wrote: > > > > > > > > > > On Wed, Sep 22, 2021 at 01:25:21PM -0700, Linus Torvalds wrote: > > > > > > On Wed, Sep 22, 2021 at 1:19 PM Sudip Mukherjee > > > > > > wrote: > > > > > > > > > > > > > > I added some debugs to print the addresses, and I am getting: > > > > > > > [ 38.813809] sudip crtc > > > > > > > > > > > > > > This is from struct drm_crtc *crtc = connector->state->crtc; > > > > > > > > > > > > Yeah, that was my personal suspicion, because while the line number > > > > > > implied "crtc->state" being NULL, the drm data structure > > > > > > documentation > > > > > > and other drivers both imply that "crtc" was the more likely one. > > > > > > > > > > > > I suspect a simple > > > > > > > > > > > > if (!crtc) > > > > > > return; > > > > > > > > > > > > in vc4_hdmi_set_n_cts() is at least part of the fix for this all, > > > > > > but > > > > > > I didn't check if there is possibly something else that needs to be > > > > > > done too. > > > > > > > > > > Thanks for the decode_stacktrace.sh and the follow-up > > > > > > > > > > Yeah, it looks like we have several things wrong here: > > > > > > > > > > * we only check that connector->state is set, and not > > > > > connector->state->crtc indeed. > > > > > > > > > > * We also check only in startup(), so at open() and not later on > > > > > when > > > > > the sound streaming actually start. This has been there for a > > > > > while, > > > > > so I guess it's never really been causing a practical issue > > > > > before. > > > > > > > > You also have no locking > > > > > > Indeed. Do we just need locking to prevent a concurrent audio setup and > > > modeset, or do you have another corner case in mind? > > > > > > Also, generally, what locks should we make sure we have locked when > > > accessing the connector and CRTC state? drm_mode_config.connection_mutex > > > and drm_mode_config.mutex, respectively? > > > > > > > plus looking at ->state objects outside of atomic commit machinery > > > > makes no sense because you're not actually in sync with the hw state. > > > > Relevant bits need to be copied over at commit time, protected by some > > > > spinlock (and that spinlock also needs to be held over whatever other > > > > stuff you're setting to make sure we don't get a funny out-of-sync > > > > state anywhere). > > > > > > If we already have a lock protecting against having both an ASoC and KMS > > > function running, it's not clear to me what the spinlock would prevent > > > here? > > > > Replicating the irc chat here. With > > > > commit 6c5ed5ae353cdf156f9ac4db17e15db56b4de880 > > Author: Maarten Lankhorst > > Date: Thu Apr 6 20:55:20 2017 +0200 > > > > drm/atomic: Acquire connection_mutex lock in > > drm_helper_probe_single_connector_modes, v4. > > > > this is already taken care of for drivers and should be all good from a > > locking pov. > > So, if I understand this properly, this superseeds your comment on the > spinlock for the hw state, but not the comment that we need some locking > to synchronize between the audio and KMS path (and CEC?). Right? Other way round. There's 3 things involved here: 1. kms output probe code 2. kms atomic commit code 3. calls from asoc side The above referenced commit makes sure 1&2 are synchronized. The problem is that 2&3 are not synchonronized, and from 3, no matter how much locking you have, you cannot look at kms state. I.e. not allowed to look at crtc->state for example, irrespective of whether you're holding drm_modeset_lock or not. This is because the atomic nonblocking commit is done without holding any locks, protection is purely down to ownership rules of state structures and ordering (through drm_crtc_commit) of in-flight nonblocking atomic commits. That's why you need a sperate lock _and_ copy state, so taht 2&3 stay in sync. In practice you only care about modeset changes from 2 vs anything from 3, and most userspace does modeset atomic commits as blocking commits, which means you won't notice that your locking has gaps. btw same problem exists between atomic and (vblank) irq handler. There you need a irqsafe spinlock and you also have to copy (because the irq handler just cannot access ->state in any safe way, because it doesn't own that structure). This is maybe a bit the confusing thing with atomic commit: ->state isn't protected by locks, but through ownership rules. Only for atomic check is ->state protected by locks, but once we're committed we switch over to ownership rules for protection. swap_states() is that point of no return. Cheers, Daniel -- Daniel Vetter Softwar
Re: DSI Bridge switching
Hi Laurent, On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart wrote: > > Hello, > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote: > > Hi, > > > > Removed my invalid email (I will update files next week). > > > > On 08.10.2021 13:14, Jagan Teki wrote: > > > Hi, > > > > > > I think this seems to be a known use case for industrial these days with > > > i.mx8m. > > > > > > The host DSI would configure with two bridges one for DSI to LVDS > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we > > > can use only one bridge at a time as host DSI support single out port. > > > So we can have two separate device tree files for LVDS and HDMI and > > > load them static. > > > > > > But, one of the use cases is to support both of them in single dts, and > > > - Turn On LVDS (default) > > > - Turn Off LVDS then Turn On HDMI when cable plug-in > > > > Are you sure it will work from hardware PoV? Do you have some demuxer? > > isolation of pins? > > It may be in the category of "you shouldn't do this, but it actually > works". I've seen the same being done with two CSI-2 camera sensors > connected to the same receiver, with one of them being held in reset at > all times. Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2 input data lanes and 1 clock lane from SoC and produces 4 data lanes and 2 clock lanes and from switch output 2 lanes and 1 clock are inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to LVDS. However, routing of these lanes are controlled by SEL, OE GPIO pins. So at a time we can access only single bridge. > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design. > > > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on > > > port 2 in the DSI host node, and trying to attach the respective > > > bridge based on HDMI-INT like repeating the bridge attachment cycle > > > based on the HDMI-INT. > > > > I think more appropriate would be to share the same port, but provide > > two endpoints inside this port - we have two hardware sharing the same > > physical port. > > That sounds like the correct DT description to me. > > > > Can it be possible to do bridge attachment at runtime? something like > > > a bridge hotplug event? or any other possible solutions? > > > > > > Any suggestions? > > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi + > > some toshiba bridge - panel and bridge are dynamically 'plugged' and > > 'unplugged' from exynos_drm, but they do not use bridge chain for this > > and some other reasons. (un|re|)plugging should be performed of course > > when pipeline is off (connector disconnected). I am not sure about > > bridges added to bridge chain - you need to inspect all opses to ensure > > it can be done safely. > > > > And the main issue: Daniel does not like it :) > > Neither do I :-) Could it be handled with two DRM connectors that are > mutually exclusive ? How about adding lvds-connector, hdmi-connector on the pipeline and select them based on the switch SEL GPIO? does it make sense to do this implementation via display-connector.c Thanks, Jagan.
[pull] amdgpu, amdkfd drm-next-5.16
Hi Dave, Daniel, Bug fixes for 5.16. The following changes since commit 1176d15f0f6e556d54ced510ac4a91694960332b: Merge tag 'drm-intel-gt-next-2021-10-08' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-10-11 18:09:39 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.16-2021-10-14 for you to fetch changes up to 48737ac4d70faffeb516e2a9847e24f9a7eee05f: drm/amdgpu/psp: add some missing cases to psp_check_pmfw_centralized_cstate_management (2021-10-13 22:51:41 -0400) amd-drm-next-5.16-2021-10-14: amdgpu: - Cyan Skillfish fixes - HDP flush fixes for asics with more than 2 SDMA instances - IP discovery enumeration fixes - Display fixes - RAS fixes for Aldebaran - Power limit fixes - IOMMU fixes for Raven - Fix potential out of bounds write in debugfs amdkfd: - SVM fixes Alex Deucher (5): drm/amdgpu/nbio7.4: don't use GPU_HDP_FLUSH bit 12 drm/amdgpu/nbio2.3: don't use GPU_HDP_FLUSH bit 12 drm/amdgpu/smu11: fix firmware version check for vangogh drm/amdgpu/swsmu: fix is_support_sw_smu() for VEGA20 drm/amdgpu/psp: add some missing cases to psp_check_pmfw_centralized_cstate_management Alex Sierra (2): drm/amdkfd: avoid conflicting address mappings amd/amdkfd: remove svms declaration to avoid werror Aurabindo Pillai (1): drm/amd/display: fix null pointer deref when plugging in display Darren Powell (2): amdgpu/pm: (v2) add limit_type to (pptable_funcs)->set_power_limit signature drm/amd/pm: Fix incorrect power limit readback in smu11 if POWER_SOURCE_DC Harry Wentland (1): MAINTAINERS: Add Siqueira for AMD DC Lang Yu (2): drm/amdgpu: query default sclk from smu for cyan_skillfish drm/amdgpu: enable display for cyan skillfish Mukul Joshi (2): drm/amdgpu: Enable RAS error injection after mode2 reset on Aldebaran drm/amdgpu: Fix RAS page retirement with mode2 reset on Aldebaran Nicholas Kazlauskas (2): drm/amd/display: Enable PSR by default on newer DCN drm/amd/display: Fix surface optimization regression on Carrizo Philip Yang (3): drm/amdkfd: ratelimited svm debug messages drm/amdkfd: handle svm partial migration cpages 0 drm/amdkfd: unregistered svm range not overlap with TTM range Simon Ser (1): amd/display: check cursor plane matches underlying plane Thelford Williams (1): drm/amdgpu: fix out of bounds write Yifan Zhang (4): drm/amdkfd: export svm_range_list_lock_and_flush_work drm/amdkfd: fix KFDSVMRangeTest.PartialUnmapSysMemTest fails drm/amdkfd: fix boot failure when iommu is disabled in Picasso. drm/amdkfd: fix resume error when iommu disabled in Picasso MAINTAINERS| 1 + drivers/gpu/drm/amd/amdgpu/aldebaran.c | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 - drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 33 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 2 +- drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 31 drivers/gpu/drm/amd/amdgpu/nbio_v2_3.h | 1 + drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 21 ++- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 17 ++ drivers/gpu/drm/amd/amdkfd/kfd_device.c| 4 + drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 120 +++-- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 185 ++--- drivers/gpu/drm/amd/amdkfd/kfd_svm.h | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 66 ++-- .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 15 +- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 3 +- drivers/gpu/drm/amd/include/amd_shared.h | 5 +- drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h| 4 +- drivers/gpu/drm/amd/pm/inc/smu_v11_0.h | 4 +- drivers/gpu/drm/amd/pm/inc/smu_v13_0.h | 4 +- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 9 +- .../drm/amd/pm/swsmu/smu11/cyan_skillfish_ppt.c| 17 +- drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 20 ++- drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 7 +- drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 6 +- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 11 +- 30 files changed, 458 insertions(+), 152 deletions(-)
Re: [RFC PATCH] drm: Increase DRM_OBJECT_MAX_PROPERTY by 18.
On Wed, Oct 13, 2021 at 07:35:48PM +0200, Sebastian Andrzej Siewior wrote: > On 2021-10-13 14:57:34 [+0200], Daniel Vetter wrote: > > Hm there's a pile of commits there, and nothing immediately jumps to > > light. The thing is, 18 is likely way too much, since if e.g. we have a > > single new property on a plane and that pushes over the limit on all of > > them, you get iirc 3x4 already simply because we have that many planes. > > > > So would be good to know the actual culprit. > > > > Can you pls try to bisect the above range, applying the patch as a fixup > > locally (without commit, that will confuse git bisect a bit I think), so > > we know what/where went wrong? > > c7fcbf2513973 -> does not boot > c7fcbf2513973 + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY > 6f11f37459d8f -> boots, 0 x DRM_OBJECT_MAX_PROPERTY > 6f11f37459d8f + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY Just to check, you've built 6f11f37459d8f, and then you cherry-picked 2f425cf5242a0 on top (not merged), and that already got you the warning flood? I'm probably blind, but I'm really not seeing where this pile of properties is coming from. Can you pls also boot with drm.debug=0xe and attach full dmesg? Plus your .config please. Thanks, Daniel > > > I'm still confused why this isn't showing up anywhere in our intel ci ... > > > > Thanks, Daniel > > Sebastian -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 1/4] drm: Introduce drm_modeset_lock_ctx_retry()
On Wed, Oct 13, 2021 at 11:00:35PM +0200, Fernando Ramos wrote: > On 21/10/13 03:06PM, Ville Syrjälä wrote: > > > And yes C is dangerous, but also C is verbose. I think one lesson from igt > > > is that too many magic block constructs are bad, it's just not how C > > > works. Definitely not in the kernel, where "oops I got it wrong because it > > > was too clever" is bad. > > > > > > > > Yes the macro we have is also not nice, but at least it's a screaming > > > > > macro since it's all uppercase, so options are all a bit sucky. Which > > > > > leads me to think we have a bit a https://xkcd.com/927/ situation > > > > > going > > > > > on. > > > > > > > > > > I think minimally we should have one way to do this. > > > > > > > > Well, there is no one way atm. All you can do is hand roll all the > > > > boilerplate (and likely get it slightly wrong) if you don't want > > > > lock_all. > > > > > > > > The current macros only help with lock_all, and IMO the hidden gotos > > > > are even uglier than a hidden for loop. Fernando already hit a case > > > > where he couldn't use the macros twice due to conflicting goto > > > > labels. With this for loop thing I think it would have just worked(tm). > > > > > > I'm totally ok with repainting the shed, I just don't want some 80s > > > multicolor flash show. > > > > You have a better idea in mind? > > Sorry, I completely forgot this discussion was going on and I just published > V4 > of my patch set here: > > https://lore.kernel.org/dri-devel/20211013204846.90026-1-green...@u92.eu/ > > Please, feel free to let me know (ideally, as a reply to the corresponding > i915 > patch from that set) if you rather me not to modify i915 files for now. My request is that we only have one way of doing this drm_modeset lock retry business. So either this one here proposed by Ville, or the one Sean Paul merged. I honestly don't care which color we pick, as long as it's consistent across the board. Please all you, figure this out. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] video: smscufx: Fix null-ptr-deref in ufx_usb_probe()
I got a null-ptr-deref report:
BUG: kernel NULL pointer dereference, address:
...
RIP: 0010:fb_destroy_modelist+0x38/0x100
...
Call Trace:
ufx_usb_probe.cold+0x2b5/0xac1 [smscufx]
usb_probe_interface+0x1aa/0x3c0 [usbcore]
really_probe+0x167/0x460
...
ret_from_fork+0x1f/0x30
If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will
be called to destroy modelist in the error handling path. But modelist
has not been initialized yet, so it will result in null-ptr-deref.
Initialize modelist before calling fb_alloc_cmap() to fix this bug.
Fixes: 3c8a63e22a08 ("Add support for SMSC UFX6000/7000 USB display adapters")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
---
drivers/video/fbdev/smscufx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index bfac3ee4a642..28768c272b73 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1656,6 +1656,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
info->par = dev;
info->pseudo_palette = dev->pseudo_palette;
info->fbops = &ufx_ops;
+ INIT_LIST_HEAD(&info->modelist);
retval = fb_alloc_cmap(&info->cmap, 256, 0);
if (retval < 0) {
@@ -1666,8 +1667,6 @@ static int ufx_usb_probe(struct usb_interface *interface,
INIT_DELAYED_WORK(&dev->free_framebuffer_work,
ufx_free_framebuffer_work);
- INIT_LIST_HEAD(&info->modelist);
-
retval = ufx_reg_read(dev, 0x3000, &id_rev);
check_warn_goto_error(retval, "error %d reading 0x3000 register from
device", retval);
dev_dbg(dev->gdev, "ID_REV register value 0x%08x", id_rev);
--
2.25.1
Re: [Intel-gfx] [PULL] drm-misc-next
Hi, On 10/14/21 2:04 PM, Maxime Ripard wrote: > Hi Dave, Daniel, > > Here's this week drm-misc-next PR > > Maxime > > drm-misc-next-2021-10-14: > drm-misc-next for 5.16: Ugh, this just missed the drm-privacy-screen work which I just pushed out to drm-misc-next (I was waiting for the last i915 integration patch to get reviewed). It would be nice if we can still get the drm-privacy-screen work included into 5.16. But if it is too late I understand. Regards, Hans > > UAPI Changes: > > Cross-subsystem Changes: > > Core Changes: > - fbdev: Fix double-free, Remove unused scrolling acceleration > - locking: improve logging for contented locks without backoff > - dma-buf: Add dma_resv_for_each_fence iterator, and conversion of > users > > Driver Changes: > - nouveau: Various code style improvements > - bridge: HPD improvements for lt9611uxc, eDP aux-bus support for > ps8640, lvds-codec data-mapping selection support > - panels: Vivax TPC-9150, Innolux G070Y2-T02, LOGIC Technologies > LTTD800480070-L2RT, Sharp LS060T1SX01, > The following changes since commit 9962601ca5719050906915c3c33a63744ac7b15c: > > drm/bridge: dw-hdmi-cec: Make use of the helper function > devm_add_action_or_reset() (2021-10-06 11:21:46 +0200) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-10-14 > > for you to fetch changes up to b3ec8cdf457e5e63d396fe1346cc788cf7c1b578: > > fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO > list) (2021-10-13 15:29:23 +0200) > > > drm-misc-next for 5.16: > > UAPI Changes: > > Cross-subsystem Changes: > > Core Changes: > - fbdev: Fix double-free, Remove unused scrolling acceleration > - locking: improve logging for contented locks without backoff > - dma-buf: Add dma_resv_for_each_fence iterator, and conversion of > users > > Driver Changes: > - nouveau: Various code style improvements > - bridge: HPD improvements for lt9611uxc, eDP aux-bus support for > ps8640, lvds-codec data-mapping selection support > - panels: Vivax TPC-9150, Innolux G070Y2-T02, LOGIC Technologies > LTTD800480070-L2RT, Sharp LS060T1SX01, > > > Alex Xu (Hello71) (1): > drm/plane-helper: fix uninitialized variable reference > > Amos Kong (1): > drm/ttm_bo_api: update the description for @placement and @sg > > Christian König (7): > dma-buf: add dma_resv_for_each_fence v3 > dma-buf: use the new iterator in dma_buf_debug_show > dma-buf: use the new iterator in dma_resv_poll > drm/ttm: use the new iterator in ttm_bo_flush_all_fences > drm/scheduler: use new iterator in > drm_sched_job_add_implicit_dependencies v2 > drm/i915: use the new iterator in i915_request_await_object v2 > drm: use new iterator in drm_gem_fence_array_add_implicit v3 > > Claudio Suarez (1): > fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO > list) > > Dan Carpenter (1): > drm/v3d: fix copy_from_user() error codes > > David Heidelberg (1): > dt-bindings: display: simple: hardware can use ddc-i2c-bus > > Dmitry Baryshkov (5): > drm/bridge/lontium-lt9611uxc: fix provided connector suport > dt-bindings: add bindings for the Sharp LS060T1SX01 panel > drm/panel: Add support for Sharp LS060T1SX01 panel > dt-bindings: add bindings for the Sharp LS060T1SX01 panel > drm/panel: Add support for Sharp LS060T1SX01 panel > > Guido Günther (5): > drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts > drm/panel: mantix: Add media bus format > drm/panel: st7703: Add media bus format > drm: mxsfb: Print failed bus format in hex > drm: mxsfb: Set fallback bus format when the bridge doesn't provide one > > Jani Nikula (1): > drm/locking: add backtrace for locking contended locks without backoff > > Jing Xiangfeng (1): > drm/virtio: fix the missed drm_gem_object_put() in > virtio_gpu_user_framebuffer_create() > > Karol Herbst (1): > drm/nouveau/mmu/gp100: remove unused variable > > Lee Jones (1): > drm/nouveau/nouveau_bo: Remove unused variables 'dev' > > Luo penghao (2): > drm/nouveau/mmu: drop unneeded assignment in the nvkm_uvmm_mthd_page() > drm/nouveau/mmu/gp100-: drop unneeded assignment in the if condition. > > Marek Vasut (3): > drm/bridge: ti-sn65dsi83: Implement .detach callback > dt-bindings: display: bridge: lvds-codec: Document LVDS data mapping > select > drm/bridge: lvds-codec: Add support for LVDS data mapping select > > Nikola Pavlica (2): > dt-bindings: add vendor prefix for Vivax > dt-bindings: display: simple: Add Vivax TPC-9150 panel > > Oleksij Rempel (1): > dt-bindings: display: simple: add Innolux G070Y2-T02 panel > > Philip Chen (1
Re: [Intel-gfx] [PATCH] drm/i915: Use dma_resv_iter for waiting in i915_gem_object_wait_reservation.
On 14/10/2021 13:05, Maarten Lankhorst wrote:
Op 14-10-2021 om 10:37 schreef Tvrtko Ursulin:
On 13/10/2021 11:41, Maarten Lankhorst wrote:
No memory should be allocated when calling i915_gem_object_wait,
because it may be called to idle a BO when evicting memory.
Fix this by using dma_resv_iter helpers to call
i915_gem_object_wait_fence() on each fence, which cleans up the code a lot.
Also remove dma_resv_prune, it's questionably.
This will result in the following lockdep splat.
@@ -37,56 +36,17 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
unsigned int flags,
long timeout)
{
- struct dma_fence *excl;
- bool prune_fences = false;
-
- if (flags & I915_WAIT_ALL) {
- struct dma_fence **shared;
- unsigned int count, i;
- int ret;
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
- ret = dma_resv_get_fences(resv, &excl, &count, &shared);
- if (ret)
- return ret;
-
- for (i = 0; i < count; i++) {
- timeout = i915_gem_object_wait_fence(shared[i],
- flags, timeout);
- if (timeout < 0)
- break;
+ dma_resv_iter_begin(&cursor, resv, flags & I915_WAIT_ALL);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
- dma_fence_put(shared[i]);
- }
-
- for (; i < count; i++)
- dma_fence_put(shared[i]);
- kfree(shared);
-
- /*
- * If both shared fences and an exclusive fence exist,
- * then by construction the shared fences must be later
- * than the exclusive fence. If we successfully wait for
- * all the shared fences, we know that the exclusive fence
- * must all be signaled. If all the shared fences are
- * signaled, we can prune the array and recover the
- * floating references on the fences/requests.
- */
- prune_fences = count && timeout >= 0;
- } else {
- excl = dma_resv_get_excl_unlocked(resv);
+ timeout = i915_gem_object_wait_fence(fence, flags, timeout);
+ if (timeout <= 0)
+ break;
You have another change in behaviour here, well a bug really. When userspace
passes in zero timeout you fail to report activity in other than the first
fence.
Hmm, not necessarily, passing 0 to i915_gem_object_wait_fence timeout = 0 is a
special case and means test only. It will return 1 on success.
I tried to enumerate the whole chain here. All for timeout == 0. Please double
check I did not make a mistake somewhere since there are many return code
inversions here.
As building blocks for the whole "game" we have:
1. dma_fence_default_wait, it returns for states:
not signaled -> 0
signaled -> 1
2. i915_request_wait
not signaled -> -ETIME
signaled -> 0
Then i915_gem_object_wait_fence builds on top of it and has therefore these
possible outputs:
signaled -> 0
not signaled:
i915 path -> -ETIME
ext fence -> 0
So this looks a like problem already with 0 for signaled and not signaled.
Unless it is by design that the return value does not want to report external
fences? But it is not documented and it still waits on them so odd.
Then in i915_gem_object_wait_reservation we have a loop:
for (i = 0; i < count; i++) {
timeout = i915_gem_object_wait_fence(shared[i],
flags, timeout);
if (timeout < 0)
break;
So short circuit happens only for i915 fences, by virtue of no negative return
codes otherwise.
If we focus for i915 fences only for a moment. It means it keeps skipping
signaled to check if any is not, therefore returning -ETIME if any is not
signaled. i915_gem_object_wait passes the negative return on.
With your patch you have:
+timeout = i915_gem_object_wait_fence(fence, flags, timeout);
+if (timeout <= 0)
+break;
Which means you break on first signaled fence (i915 or external), therefore
missing to report any possible subsequent unsignaled fences. So gem_wait ioctl
breaks unless I am missing something.
Regards,
Tvrtko
Of course it is still broken, I sent a reply to könig about it, hope it will
get fixed and respun. :)
~Maarten
Re: [PATCH v2 02/34] component: Introduce the aggregate bus_type
On Thu, Oct 07, 2021 at 04:42:48PM -0400, Stephen Boyd wrote: > Quoting Greg Kroah-Hartman (2021-10-06 22:37:40) > > On Wed, Oct 06, 2021 at 12:37:47PM -0700, Stephen Boyd wrote: > > > > > > Let's make the component driver into an actual device driver that has > > > probe/remove/shutdown functions. The driver will only be bound to the > > > aggregate device once all component drivers have called component_add() > > > to indicate they're ready to assemble the aggregate driver. This allows > > > us to attach shutdown logic (and in the future runtime PM logic) to the > > > aggregate driver so that it runs the hooks in the correct order. > > > > Why are you creating a new bus type and not using the auxiliary bus > > instead? > > > > You have seen Documentation/driver-api/auxiliary_bus.rst, right? > > > > Nope, but I read it now. Thanks for the pointer. > > My read of it is that the auxiliary bus is a way to slice up a single IP > block into multiple devices and then have drivers attach to those > different "pieces" of the IP. It avoids polluting the platform bus with > devices that don't belong on the platform bus because they are sub > components of a larger IP block that sits on the platform bus. > > The aggregate bus is solving the reverse problem. It is rounding up a > collection of IP blocks that live on some bus (platform, i2c, spi, > whatever) and presenting them as a single aggregate device (sound card, > display card, whatever) whenever all the component devices call > component_add(). For example, we don't want to do operations on the > entire display pipeline until all the devices that make up the display > are probed and drivers are attached. I suppose the aggregate_device in > this patch series has a 1:1 relationship with the drm class_type that > makes up /sys/class/drm/cardN but there's also a couple sound users and > a power_supply user so I don't know the equivalent there. > > Long term, maybe all of this component code could be placed directly > into the driver core? That's probably even more invasive of a change but > I imagine we could make device links with component_add() as we're > already doing with these patches and then have driver core call some > class function pointer when all the links are probed. That would > handle the 'bind/probe' callback for the aggregate device but it won't > handle the component_bind_all() path where we call bind_component() for > each component device that makes up the aggregate device. Maybe we can > add even more devices for the components and then call probe there too. > > Sorry that's a long-winded non-answer. I don't think they're solving the > same problem so using the same bus type looks wrong. We'd have to take > two different paths depending on what type of device it is (aggregate > vs. auxiliary) so there's not much of anything that is shared code-wise. Yeah component is the reverse of auxiliary, and right now a lot of subsystems have their own hand-rolled version of this. I do hope that component.c does become more of a standard (that's why it's in drivers/base/), but I guess that's a bit tricky if the device model maintainer hasn't seen it yet ... Hopefully putting more proper device model concepts into it can fix this problem :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 03/11] drm/msm/disp/dpu1: Add support for DSC in pingpong block
On 07/10/2021 10:08, Vinod Koul wrote:
In SDM845, DSC can be enabled by writing to pingpong block registers, so
add support for DSC in hw_pp
Reviewed-by: Abhinav Kumar
Signed-off-by: Vinod Koul
Reviewed-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 32 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14
2 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 55766c97c4c8..47c6ab6caf95 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -28,6 +28,9 @@
#define PP_FBC_MODE 0x034
#define PP_FBC_BUDGET_CTL 0x038
#define PP_FBC_LOSSY_MODE 0x03C
+#define PP_DSC_MODE 0x0a0
+#define PP_DCE_DATA_IN_SWAP 0x0ac
+#define PP_DCE_DATA_OUT_SWAP0x0c8
#define PP_DITHER_EN 0x000
#define PP_DITHER_BITDEPTH0x004
@@ -245,6 +248,32 @@ static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong
*pp)
return line;
}
+static int dpu_hw_pp_dsc_enable(struct dpu_hw_pingpong *pp)
+{
+ struct dpu_hw_blk_reg_map *c = &pp->hw;
+
+ DPU_REG_WRITE(c, PP_DSC_MODE, 1);
+ return 0;
+}
+
+static void dpu_hw_pp_dsc_disable(struct dpu_hw_pingpong *pp)
+{
+ struct dpu_hw_blk_reg_map *c = &pp->hw;
+
+ DPU_REG_WRITE(c, PP_DSC_MODE, 0);
+}
+
+static int dpu_hw_pp_setup_dsc(struct dpu_hw_pingpong *pp)
+{
+ struct dpu_hw_blk_reg_map *pp_c = &pp->hw;
+ int data;
+
+ data = DPU_REG_READ(pp_c, PP_DCE_DATA_OUT_SWAP);
+ data |= BIT(18); /* endian flip */
+ DPU_REG_WRITE(pp_c, PP_DCE_DATA_OUT_SWAP, data);
+ return 0;
+}
+
static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
unsigned long features)
{
@@ -256,6 +285,9 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
c->ops.get_autorefresh = dpu_hw_pp_get_autorefresh_config;
c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
c->ops.get_line_count = dpu_hw_pp_get_line_count;
+ c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
+ c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
+ c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
if (test_bit(DPU_PINGPONG_DITHER, &features))
c->ops.setup_dither = dpu_hw_pp_setup_dither;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
index 89d08a715c16..12758468d9ca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
@@ -124,6 +124,20 @@ struct dpu_hw_pingpong_ops {
*/
void (*setup_dither)(struct dpu_hw_pingpong *pp,
struct dpu_hw_dither_cfg *cfg);
+ /**
+* Enable DSC
+*/
+ int (*enable_dsc)(struct dpu_hw_pingpong *pp);
+
+ /**
+* Disable DSC
+*/
+ void (*disable_dsc)(struct dpu_hw_pingpong *pp);
+
+ /**
+* Setup DSC
+*/
+ int (*setup_dsc)(struct dpu_hw_pingpong *pp);
};
struct dpu_hw_merge_3d;
--
With best wishes
Dmitry
Re: [PATCH 03/14] drm/i915/xehpsdv: enforce min GTT alignment
On Wed, Oct 13, 2021 at 03:13:33PM +0100, Matthew Auld wrote:
> On 13/10/2021 14:38, Daniel Vetter wrote:
> > On Mon, Oct 11, 2021 at 09:41:44PM +0530, Ramalingam C wrote:
> > > From: Matthew Auld
> > >
> > > For local-memory objects we need to align the GTT addresses to 64K, both
> > > for the ppgtt and ggtt.
> > >
> > > Signed-off-by: Matthew Auld
> > > Signed-off-by: Stuart Summers
> > > Signed-off-by: Ramalingam C
> > > Cc: Joonas Lahtinen
> > > Cc: Rodrigo Vivi
> >
> > Do we still need this with relocations removed? Userspace is picking all
> > the addresses for us, so all we have to check is whether userspace got it
> > right.
>
> Yeah, for OFFSET_FIXED this just validates that the provided address is
> correctly aligned to 64K, while for the in-kernel insertion stuff we still
> need to allocate an address that is aligned to 64K. Setting the alignment
> here handles both cases.
Can't we just teach any in-kernel allocators to align to 2M and call it a
day? Ofc the code can still validate we don't have bugs (always good to
check your work). Ofc if the benefits is "no code can be removed anyway
since we still need to check" then ofc no point :-)
Just want to make sure we're not carrying complexity around for nothing,
since this predates the relocation removal.
-Daniel
>
> > -Daniel
> >
> >
> > > ---
> > > drivers/gpu/drm/i915/i915_vma.c | 9 +++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_vma.c
> > > b/drivers/gpu/drm/i915/i915_vma.c
> > > index 4b7fc4647e46..1ea1fa08efdf 100644
> > > --- a/drivers/gpu/drm/i915/i915_vma.c
> > > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > > @@ -670,8 +670,13 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
> > > alignment, u64 flags)
> > > }
> > > color = 0;
> > > - if (vma->obj && i915_vm_has_cache_coloring(vma->vm))
> > > - color = vma->obj->cache_level;
> > > + if (vma->obj) {
> > > + if (HAS_64K_PAGES(vma->vm->i915) &&
> > > i915_gem_object_is_lmem(vma->obj))
> > > + alignment = max(alignment, I915_GTT_PAGE_SIZE_64K);
> > > +
> > > + if (i915_vm_has_cache_coloring(vma->vm))
> > > + color = vma->obj->cache_level;
> > > + }
> > > if (flags & PIN_OFFSET_FIXED) {
> > > u64 offset = flags & PIN_OFFSET_MASK;
> > > --
> > > 2.20.1
> > >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 05/11] drm/msm/disp/dpu1: Add DSC for SDM845 to hw_catalog
On 07/10/2021 10:08, Vinod Koul wrote:
This adds SDM845 DSC blocks into hw_catalog
Signed-off-by: Vinod Koul
Reviewed-by: Dmitry Baryshkov
---
Changes since
v1:
- Remove DSC_SDM845_MASK and use 0 as feature mask
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 20 +++
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index b131fd376192..6423a2fe6698 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -821,6 +821,24 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, 0, sc7280_pp_sblk, -1, -1),
PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, 0, sc7280_pp_sblk, -1, -1),
};
+
+/*
+ * DSC sub blocks config
+ */
+#define DSC_BLK(_name, _id, _base) \
+ {\
+ .name = _name, .id = _id, \
+ .base = _base, .len = 0x140, \
+ .features = 0, \
+ }
+
+static struct dpu_dsc_cfg sdm845_dsc[] = {
+ DSC_BLK("dsc_0", DSC_0, 0x8),
+ DSC_BLK("dsc_1", DSC_1, 0x80400),
+ DSC_BLK("dsc_2", DSC_2, 0x80800),
+ DSC_BLK("dsc_3", DSC_3, 0x80c00),
+};
+
/*
* INTF sub blocks config
*/
@@ -1130,6 +1148,8 @@ static void sdm845_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.mixer = sdm845_lm,
.pingpong_count = ARRAY_SIZE(sdm845_pp),
.pingpong = sdm845_pp,
+ .dsc_count = ARRAY_SIZE(sdm845_dsc),
+ .dsc = sdm845_dsc,
.intf_count = ARRAY_SIZE(sdm845_intf),
.intf = sdm845_intf,
.vbif_count = ARRAY_SIZE(sdm845_vbif),
--
With best wishes
Dmitry
Re: [PATCH v2 06/11] drm/msm/disp/dpu1: Don't use DSC with mode_3d
On 07/10/2021 10:08, Vinod Koul wrote:
We cannot enable mode_3d when we are using the DSC. So pass
configuration to detect DSC is enabled and not enable mode_3d
when we are using DSC
We add a helper dpu_encoder_helper_get_dsc_mode() to detect dsc
enabled and pass this to .setup_intf_cfg()
Signed-off-by: Vinod Koul
---
Changes since
v1:
- Move this patch from 7 to 6
- Update the changelog
- Make dsc as int and store the DSC indices
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 5 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 2 ++
4 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index e7270eb6b84b..fca07ed03317 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -332,6 +332,17 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
return BLEND_3D_NONE;
}
+static inline bool dpu_encoder_helper_get_dsc_mode(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc = phys_enc->parent;
+ struct msm_drm_private *priv = drm_enc->dev->dev_private;
+
+ if (priv->dsc)
+ return BIT(0) | BIT(1); /* Hardcoding for 2 DSC topology */
Please use defined values here rater than just BIT().
+
+ return 0;
+}
+
/**
* dpu_encoder_helper_split_config - split display configuration helper
function
*This helper function may be used by physical encoders to configure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index aa01698d6b25..8e5c0911734c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -70,6 +70,8 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
intf_cfg.intf_mode_sel = DPU_CTL_MODE_SEL_CMD;
intf_cfg.stream_sel = cmd_enc->stream_sel;
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
+ intf_cfg.dsc = dpu_encoder_helper_get_dsc_mode(phys_enc);
+
ctl->ops.setup_intf_cfg(ctl, &intf_cfg);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 64740ddb983e..3c79bd9c2fe5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -118,7 +118,7 @@ static u32 dpu_hw_ctl_get_pending_flush(struct dpu_hw_ctl
*ctx)
return ctx->pending_flush_mask;
}
-static inline void dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)
+static void dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)
{
if (ctx->pending_flush_mask & BIT(MERGE_3D_IDX))
@@ -519,7 +519,8 @@ static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
intf_cfg |= (cfg->intf & 0xF) << 4;
- if (cfg->mode_3d) {
+ /* In DSC we can't set merge, so check for dsc too */
+ if (cfg->mode_3d && !cfg->dsc) {
The more I think about this hunk, the more I'm unsure about it.
Downstream has the following topoligies defined:
* @SDE_RM_TOPOLOGY_DUALPIPE_3DMERGE_DSC: 2 LM, 2 PP, 3DMux, 1 DSC, 1
INTF/WB
* @SDE_RM_TOPOLOGY_QUADPIPE_3DMERGE_DSC 4 LM, 4 PP, 3DMux, 3 DSC, 2 INTF
While the latter is not supported on sdm845, the former one should be
(by the hardware). So in the driver I think we should make sure that
mode_3d does not get set rather than disallowing it here.
intf_cfg |= BIT(19);
intf_cfg |= (cfg->mode_3d - 0x1) << 20;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index 806c171e5df2..5dfac5994bd4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -39,6 +39,7 @@ struct dpu_hw_stage_cfg {
* @mode_3d: 3d mux configuration
* @merge_3d: 3d merge block used
* @intf_mode_sel: Interface mode, cmd / vid
+ * @dsc: DSC BIT masks
* @stream_sel:Stream selection for multi-stream interfaces
*/
struct dpu_hw_intf_cfg {
@@ -46,6 +47,7 @@ struct dpu_hw_intf_cfg {
enum dpu_3d_blend_mode mode_3d;
enum dpu_merge_3d merge_3d;
enum dpu_ctl_mode_sel intf_mode_sel;
+ unsigned int dsc;
int stream_sel;
};
--
With best wishes
Dmitry
Re: [PATCH v7, 03/15] media: mtk-vcodec: Refactor vcodec pm interface
On 11.10.21 09:02, Yunfei Dong wrote:
Using the needed param for pm init/release function and remove unused
param mtkdev in 'struct mtk_vcodec_pm'.
I see that there is a lot of code duplication between
mtk_vcodec_release_dec_pm.c and mtk_vcodec_release_enc_pm.c
I think if you bother to factor the decoder you should do the same factor to
the encoder, but actually the much better thing to do
is to unify all code duplication between these two files, just for example of
identical functions:
mtk_vcodec_enc/dec_clock_on/off
mtk_vcodec_release_enc_pm
mtk_vcodec_init_dec_pm
In addition, the function mtk_vcodec_dec_pw_on can be remove since it only
calls pm_runtime_resume_and_get.
It would be much better to call pm_runtime_resume_and_get directly and not hide
it in a different function
Thanks,
Dafna
Reviewed-by: Tzung-Bi Shih
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 ++---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 22 ---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 5 +++--
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 1 -
5 files changed, 15 insertions(+), 20 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 8db9cdc66043..dd749d41c75a 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -249,7 +249,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
if (IS_ERR(dev->fw_handler))
return PTR_ERR(dev->fw_handler);
- ret = mtk_vcodec_init_dec_pm(dev);
+ ret = mtk_vcodec_init_dec_pm(dev->plat_dev, &dev->pm);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to get mt vcodec clock source");
goto err_dec_pm;
@@ -379,7 +379,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
err_dec_alloc:
v4l2_device_unregister(&dev->v4l2_dev);
err_res:
- mtk_vcodec_release_dec_pm(dev);
+ mtk_vcodec_release_dec_pm(&dev->pm);
err_dec_pm:
mtk_vcodec_fw_release(dev->fw_handler);
return ret;
@@ -422,7 +422,7 @@ static int mtk_vcodec_dec_remove(struct platform_device
*pdev)
video_unregister_device(dev->vfd_dec);
v4l2_device_unregister(&dev->v4l2_dev);
- mtk_vcodec_release_dec_pm(dev);
+ mtk_vcodec_release_dec_pm(&dev->pm);
mtk_vcodec_fw_release(dev->fw_handler);
return 0;
}
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 6038db96f71c..20bd157a855c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -13,18 +13,15 @@
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
-int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
+int mtk_vcodec_init_dec_pm(struct platform_device *pdev,
+ struct mtk_vcodec_pm *pm)
{
struct device_node *node;
- struct platform_device *pdev;
- struct mtk_vcodec_pm *pm;
+ struct platform_device *larb_pdev;
struct mtk_vcodec_clk *dec_clk;
struct mtk_vcodec_clk_info *clk_info;
int i = 0, ret = 0;
- pdev = mtkdev->plat_dev;
- pm = &mtkdev->pm;
- pm->mtkdev = mtkdev;
dec_clk = &pm->vdec_clk;
node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
if (!node) {
@@ -32,13 +29,12 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
return -1;
}
- pdev = of_find_device_by_node(node);
+ larb_pdev = of_find_device_by_node(node);
of_node_put(node);
- if (WARN_ON(!pdev)) {
+ if (WARN_ON(!larb_pdev)) {
return -1;
}
- pm->larbvdec = &pdev->dev;
- pdev = mtkdev->plat_dev;
+ pm->larbvdec = &larb_pdev->dev;
pm->dev = &pdev->dev;
dec_clk->clk_num =
@@ -82,10 +78,10 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
return ret;
}
-void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
+void mtk_vcodec_release_dec_pm(struct mtk_vcodec_pm *pm)
{
- pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
+ pm_runtime_disable(pm->dev);
+ put_device(pm->larbvdec);
}
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
index 280aeaefdb65..a3df6aef6cb9 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
@@ -9,8 +9,9 @@
#include "mtk_vcodec_drv.h"
-int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *dev);
-void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev);
+int mtk_vcodec_
Re: [Intel-gfx] [PATCH] drm/i915: Use dma_resv_iter for waiting in i915_gem_object_wait_reservation.
Op 14-10-2021 om 15:25 schreef Tvrtko Ursulin:
>
> On 14/10/2021 13:05, Maarten Lankhorst wrote:
>> Op 14-10-2021 om 10:37 schreef Tvrtko Ursulin:
>>>
>>> On 13/10/2021 11:41, Maarten Lankhorst wrote:
No memory should be allocated when calling i915_gem_object_wait,
because it may be called to idle a BO when evicting memory.
Fix this by using dma_resv_iter helpers to call
i915_gem_object_wait_fence() on each fence, which cleans up the code a lot.
Also remove dma_resv_prune, it's questionably.
This will result in the following lockdep splat.
>>>
>>>
>>>
@@ -37,56 +36,17 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
unsigned int flags,
long timeout)
{
- struct dma_fence *excl;
- bool prune_fences = false;
-
- if (flags & I915_WAIT_ALL) {
- struct dma_fence **shared;
- unsigned int count, i;
- int ret;
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
- ret = dma_resv_get_fences(resv, &excl, &count, &shared);
- if (ret)
- return ret;
-
- for (i = 0; i < count; i++) {
- timeout = i915_gem_object_wait_fence(shared[i],
- flags, timeout);
- if (timeout < 0)
- break;
+ dma_resv_iter_begin(&cursor, resv, flags & I915_WAIT_ALL);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
- dma_fence_put(shared[i]);
- }
-
- for (; i < count; i++)
- dma_fence_put(shared[i]);
- kfree(shared);
-
- /*
- * If both shared fences and an exclusive fence exist,
- * then by construction the shared fences must be later
- * than the exclusive fence. If we successfully wait for
- * all the shared fences, we know that the exclusive fence
- * must all be signaled. If all the shared fences are
- * signaled, we can prune the array and recover the
- * floating references on the fences/requests.
- */
- prune_fences = count && timeout >= 0;
- } else {
- excl = dma_resv_get_excl_unlocked(resv);
+ timeout = i915_gem_object_wait_fence(fence, flags, timeout);
+ if (timeout <= 0)
+ break;
>>>
>>> You have another change in behaviour here, well a bug really. When
>>> userspace passes in zero timeout you fail to report activity in other than
>>> the first fence.
>>
>> Hmm, not necessarily, passing 0 to i915_gem_object_wait_fence timeout = 0 is
>> a special case and means test only. It will return 1 on success.
>
> I tried to enumerate the whole chain here. All for timeout == 0. Please
> double check I did not make a mistake somewhere since there are many return
> code inversions here.
>
> As building blocks for the whole "game" we have:
>
> 1. dma_fence_default_wait, it returns for states:
>
> not signaled -> 0
> signaled -> 1
>
> 2. i915_request_wait
>
> not signaled -> -ETIME
> signaled -> 0
>
> Then i915_gem_object_wait_fence builds on top of it and has therefore these
> possible outputs:
>
> signaled -> 0
> not signaled:
> i915 path -> -ETIME
> ext fence -> 0
>
> So this looks a like problem already with 0 for signaled and not signaled.
> Unless it is by design that the return value does not want to report external
> fences? But it is not documented and it still waits on them so odd.
>
> Then in i915_gem_object_wait_reservation we have a loop:
>
> for (i = 0; i < count; i++) {
> timeout = i915_gem_object_wait_fence(shared[i],
> flags, timeout);
> if (timeout < 0)
> break;
>
> So short circuit happens only for i915 fences, by virtue of no negative
> return codes otherwise.
>
> If we focus for i915 fences only for a moment. It means it keeps skipping
> signaled to check if any is not, therefore returning -ETIME if any is not
> signaled. i915_gem_object_wait passes the negative return on.
>
> With your patch you have:
>
> + timeout = i915_gem_object_wait_fence(fence, flags, timeout);
> + if (timeout <= 0)
> + break;
>
> Which means you break on first signaled fence (i915 or external), therefore
> missing to report any possible subsequent unsignaled fences. So gem_wait
> ioctl breaks unless I am missing something.
You're cc'd on a mail I sent to König regarding this.
"Re: [PATCH 20/28] drm/i915: use new iterator in
i915_gem_object_wait_reservation"
5accca25-8ac3-47ca-ee56-8b33c208f...@linux.intel.com
timeout = 0 is a special case, fence_wait should return 1 if signaled, or 0 if
waiting. Not -ETIME, as i915 does currently.
This means our i915_fence_wait()
Re: [RFC PATCH] drm: Increase DRM_OBJECT_MAX_PROPERTY by 18.
On 2021-10-14 15:21:22 [+0200], Daniel Vetter wrote: > On Wed, Oct 13, 2021 at 07:35:48PM +0200, Sebastian Andrzej Siewior wrote: > > c7fcbf2513973 -> does not boot > > c7fcbf2513973 + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY > > 6f11f37459d8f -> boots, 0 x DRM_OBJECT_MAX_PROPERTY > > 6f11f37459d8f + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY > > Just to check, you've built 6f11f37459d8f, and then you cherry-picked > 2f425cf5242a0 on top (not merged), and that already got you the warning > flood? Correct. > I'm probably blind, but I'm really not seeing where this pile of > properties is coming from. Can you pls also boot with drm.debug=0xe and > attach full dmesg? Plus your .config please. attached. dmesg.txt is 6f11f37459d8f and the other is 6f11f37459d8f + 2f425cf5242a0. > Thanks, Daniel Sebastian config.xz Description: application/xz dmesg.txt.xz Description: application/xz dmesg-with-2f425cf5242a0.txt.xz Description: application/xz
Re: [PATCH v2 06/11] drm/msm/disp/dpu1: Don't use DSC with mode_3d
On 14/10/2021 16:41, Dmitry Baryshkov wrote:
On 07/10/2021 10:08, Vinod Koul wrote:
We cannot enable mode_3d when we are using the DSC. So pass
configuration to detect DSC is enabled and not enable mode_3d
when we are using DSC
We add a helper dpu_encoder_helper_get_dsc_mode() to detect dsc
enabled and pass this to .setup_intf_cfg()
Signed-off-by: Vinod Koul
---
Changes since
v1:
- Move this patch from 7 to 6
- Update the changelog
- Make dsc as int and store the DSC indices
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 5 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 2 ++
4 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index e7270eb6b84b..fca07ed03317 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -332,6 +332,17 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
return BLEND_3D_NONE;
}
+static inline bool dpu_encoder_helper_get_dsc_mode(struct
dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc = phys_enc->parent;
+ struct msm_drm_private *priv = drm_enc->dev->dev_private;
+
+ if (priv->dsc)
+ return BIT(0) | BIT(1); /* Hardcoding for 2 DSC topology */
Please use defined values here rater than just BIT().
Ah, it's a list of DSC blocks used. So the function name is misleading
(as it's not a mode). I think we'd better pass DSC_n names here. What
about using an array for cfg->dsc?
+
+ return 0;
+}
+
/**
* dpu_encoder_helper_split_config - split display configuration
helper function
* This helper function may be used by physical encoders to
configure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index aa01698d6b25..8e5c0911734c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -70,6 +70,8 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
intf_cfg.intf_mode_sel = DPU_CTL_MODE_SEL_CMD;
intf_cfg.stream_sel = cmd_enc->stream_sel;
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
+ intf_cfg.dsc = dpu_encoder_helper_get_dsc_mode(phys_enc);
+
ctl->ops.setup_intf_cfg(ctl, &intf_cfg);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 64740ddb983e..3c79bd9c2fe5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -118,7 +118,7 @@ static u32 dpu_hw_ctl_get_pending_flush(struct
dpu_hw_ctl *ctx)
return ctx->pending_flush_mask;
}
-static inline void dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)
+static void dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)
{
if (ctx->pending_flush_mask & BIT(MERGE_3D_IDX))
@@ -519,7 +519,8 @@ static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl
*ctx,
intf_cfg |= (cfg->intf & 0xF) << 4;
- if (cfg->mode_3d) {
+ /* In DSC we can't set merge, so check for dsc too */
+ if (cfg->mode_3d && !cfg->dsc) {
The more I think about this hunk, the more I'm unsure about it.
Downstream has the following topoligies defined:
* @SDE_RM_TOPOLOGY_DUALPIPE_3DMERGE_DSC: 2 LM, 2 PP, 3DMux, 1 DSC, 1
INTF/WB
* @SDE_RM_TOPOLOGY_QUADPIPE_3DMERGE_DSC 4 LM, 4 PP, 3DMux, 3 DSC, 2 INTF
While the latter is not supported on sdm845, the former one should be
(by the hardware). So in the driver I think we should make sure that
mode_3d does not get set rather than disallowing it here.
intf_cfg |= BIT(19);
intf_cfg |= (cfg->mode_3d - 0x1) << 20;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index 806c171e5df2..5dfac5994bd4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -39,6 +39,7 @@ struct dpu_hw_stage_cfg {
* @mode_3d: 3d mux configuration
* @merge_3d: 3d merge block used
* @intf_mode_sel: Interface mode, cmd / vid
+ * @dsc: DSC BIT masks
* @stream_sel: Stream selection for multi-stream interfaces
*/
struct dpu_hw_intf_cfg {
@@ -46,6 +47,7 @@ struct dpu_hw_intf_cfg {
enum dpu_3d_blend_mode mode_3d;
enum dpu_merge_3d merge_3d;
enum dpu_ctl_mode_sel intf_mode_sel;
+ unsigned int dsc;
I think this should be:
enum dpu_dsc dsc[MAX_DSCS];
unsigned int num_dsc;
int stream_sel;
};
--
With best wishes
Dmitry
Revert "arm64: dts: qcom: sm8250: remove bus clock from the mdss node for sm8250 target"
From: Amit Pundir This reverts commit 001ce9785c0674d913531345e86222c965fc8bf4. This upstream commit broke AOSP (post Android 12 merge) build on RB5. The device either silently crashes into USB crash mode after android boot animation or we see a blank blue screen with following dpu errors in dmesg: [ T444] hw recovery is not complete for ctl:3 [ T444] [drm:dpu_encoder_phys_vid_prepare_for_kickoff:539] [dpu error]enc31 intf1 ctl 3 reset failure: -22 [ T444] [drm:dpu_encoder_phys_vid_wait_for_commit_done:513] [dpu error]vblank timeout [ T444] [drm:dpu_kms_wait_for_commit_done:454] [dpu error]wait for commit done returned -110 [C7] [drm:dpu_encoder_frame_done_timeout:2127] [dpu error]enc31 frame done timeout [ T444] [drm:dpu_encoder_phys_vid_wait_for_commit_done:513] [dpu error]vblank timeout [ T444] [drm:dpu_kms_wait_for_commit_done:454] [dpu error]wait for commit done returned -110 Signed-off-by: Amit Pundir --- arch/arm64/boot/dts/qcom/sm8250.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi index 8c15d9fed08f..d12e4cbfc852 100644 --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi @@ -2590,9 +2590,10 @@ power-domains = <&dispcc MDSS_GDSC>; clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, +<&gcc GCC_DISP_HF_AXI_CLK>, <&gcc GCC_DISP_SF_AXI_CLK>, <&dispcc DISP_CC_MDSS_MDP_CLK>; - clock-names = "iface", "nrt_bus", "core"; + clock-names = "iface", "bus", "nrt_bus", "core"; assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>; assigned-clock-rates = <46000>; -- cgit v1.2.1
Re: [Intel-gfx] [PATCH] drm/i915: Use dma_resv_iter for waiting in i915_gem_object_wait_reservation.
On 14/10/2021 14:45, Maarten Lankhorst wrote:
Op 14-10-2021 om 15:25 schreef Tvrtko Ursulin:
On 14/10/2021 13:05, Maarten Lankhorst wrote:
Op 14-10-2021 om 10:37 schreef Tvrtko Ursulin:
On 13/10/2021 11:41, Maarten Lankhorst wrote:
No memory should be allocated when calling i915_gem_object_wait,
because it may be called to idle a BO when evicting memory.
Fix this by using dma_resv_iter helpers to call
i915_gem_object_wait_fence() on each fence, which cleans up the code a lot.
Also remove dma_resv_prune, it's questionably.
This will result in the following lockdep splat.
@@ -37,56 +36,17 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
unsigned int flags,
long timeout)
{
- struct dma_fence *excl;
- bool prune_fences = false;
-
- if (flags & I915_WAIT_ALL) {
- struct dma_fence **shared;
- unsigned int count, i;
- int ret;
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
- ret = dma_resv_get_fences(resv, &excl, &count, &shared);
- if (ret)
- return ret;
-
- for (i = 0; i < count; i++) {
- timeout = i915_gem_object_wait_fence(shared[i],
- flags, timeout);
- if (timeout < 0)
- break;
+ dma_resv_iter_begin(&cursor, resv, flags & I915_WAIT_ALL);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
- dma_fence_put(shared[i]);
- }
-
- for (; i < count; i++)
- dma_fence_put(shared[i]);
- kfree(shared);
-
- /*
- * If both shared fences and an exclusive fence exist,
- * then by construction the shared fences must be later
- * than the exclusive fence. If we successfully wait for
- * all the shared fences, we know that the exclusive fence
- * must all be signaled. If all the shared fences are
- * signaled, we can prune the array and recover the
- * floating references on the fences/requests.
- */
- prune_fences = count && timeout >= 0;
- } else {
- excl = dma_resv_get_excl_unlocked(resv);
+ timeout = i915_gem_object_wait_fence(fence, flags, timeout);
+ if (timeout <= 0)
+ break;
You have another change in behaviour here, well a bug really. When userspace
passes in zero timeout you fail to report activity in other than the first
fence.
Hmm, not necessarily, passing 0 to i915_gem_object_wait_fence timeout = 0 is a
special case and means test only. It will return 1 on success.
I tried to enumerate the whole chain here. All for timeout == 0. Please double
check I did not make a mistake somewhere since there are many return code
inversions here.
As building blocks for the whole "game" we have:
1. dma_fence_default_wait, it returns for states:
not signaled -> 0
signaled -> 1
2. i915_request_wait
not signaled -> -ETIME
signaled -> 0
Then i915_gem_object_wait_fence builds on top of it and has therefore these
possible outputs:
signaled -> 0
not signaled:
i915 path -> -ETIME
ext fence -> 0
So this looks a like problem already with 0 for signaled and not signaled.
Unless it is by design that the return value does not want to report external
fences? But it is not documented and it still waits on them so odd.
Then in i915_gem_object_wait_reservation we have a loop:
for (i = 0; i < count; i++) {
timeout = i915_gem_object_wait_fence(shared[i],
flags, timeout);
if (timeout < 0)
break;
So short circuit happens only for i915 fences, by virtue of no negative return
codes otherwise.
If we focus for i915 fences only for a moment. It means it keeps skipping
signaled to check if any is not, therefore returning -ETIME if any is not
signaled. i915_gem_object_wait passes the negative return on.
With your patch you have:
+ timeout = i915_gem_object_wait_fence(fence, flags, timeout);
+ if (timeout <= 0)
+ break;
Which means you break on first signaled fence (i915 or external), therefore
missing to report any possible subsequent unsignaled fences. So gem_wait ioctl
breaks unless I am missing something.
You're cc'd on a mail I sent to König regarding this.
"Re: [PATCH 20/28] drm/i915: use new iterator in
i915_gem_object_wait_reservation"
5accca25-8ac3-47ca-ee56-8b33c208f...@linux.intel.com
timeout = 0 is a special case, fence_wait should return 1 if signaled, or 0 if
waiting. Not -ETIME, as i915 does currently.
This means our i915_fence_wait() handler is currently very wrong too, needs to
be fixed. It returns 0 if timeout = 0 even
if signaled.
I think it cancels the fail in our gem_object_wait, but more consistency is
definitely needed first.
I think it's best to keep the current semantics for i915_reuest_wait, but make
it a wrapper around a
fixed i915_reques
Re: [PATCH] video: smscufx: Fix null-ptr-deref in ufx_usb_probe()
Hi
Am 14.10.21 um 15:22 schrieb Wang Hai:
I got a null-ptr-deref report:
BUG: kernel NULL pointer dereference, address:
...
RIP: 0010:fb_destroy_modelist+0x38/0x100
...
Call Trace:
ufx_usb_probe.cold+0x2b5/0xac1 [smscufx]
usb_probe_interface+0x1aa/0x3c0 [usbcore]
really_probe+0x167/0x460
...
ret_from_fork+0x1f/0x30
If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will
be called to destroy modelist in the error handling path. But modelist
has not been initialized yet, so it will result in null-ptr-deref.
Initialize modelist before calling fb_alloc_cmap() to fix this bug.
Fixes: 3c8a63e22a08 ("Add support for SMSC UFX6000/7000 USB display adapters")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
Acked-by: Thomas Zimmermann
I got one of these devices but the driver didn't produce any output for
me. Are actually able to use the driver?
Best regards
Thomas
---
drivers/video/fbdev/smscufx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index bfac3ee4a642..28768c272b73 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1656,6 +1656,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
info->par = dev;
info->pseudo_palette = dev->pseudo_palette;
info->fbops = &ufx_ops;
+ INIT_LIST_HEAD(&info->modelist);
retval = fb_alloc_cmap(&info->cmap, 256, 0);
if (retval < 0) {
@@ -1666,8 +1667,6 @@ static int ufx_usb_probe(struct usb_interface *interface,
INIT_DELAYED_WORK(&dev->free_framebuffer_work,
ufx_free_framebuffer_work);
- INIT_LIST_HEAD(&info->modelist);
-
retval = ufx_reg_read(dev, 0x3000, &id_rev);
check_warn_goto_error(retval, "error %d reading 0x3000 register from
device", retval);
dev_dbg(dev->gdev, "ID_REV register value 0x%08x", id_rev);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v11 09/16] soc: mediatek: add mtk-mmsys support for mt8195 vdosys0
Add mt8195 vdosys0 clock driver name and routing table to the driver data of mtk-mmsys. Signed-off-by: jason-jh.lin --- This patch is base on [1] [1] soc: mediatek: mmsys: add mt8192 mmsys support - https://patchwork.kernel.org/project/linux-mediatek/list/?series=524857 The vdosys1 impelmentation patch [2] [2] soc: mediatek: add mtk-mmsys support for mt8195 vdosys1 - https://patchwork.kernel.org/project/linux-mediatek/patch/20210906071539.12953-7-nancy@mediatek.com/ --- Hello Jason, thanks for the patch! However, there are a few things to improve: drivers/soc/mediatek/mt8195-mmsys.h| 114 + drivers/soc/mediatek/mtk-mmsys.c | 11 +++ include/linux/soc/mediatek/mtk-mmsys.h | 9 ++ 3 files changed, 134 insertions(+) create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h diff --git a/drivers/soc/mediatek/mt8195-mmsys.h b/drivers/soc/mediatek/mt8195-mmsys.h new file mode 100644 index ..0c97a5f016c1 --- /dev/null +++ b/drivers/soc/mediatek/mt8195-mmsys.h @@ -0,0 +1,114 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __SOC_MEDIATEK_MT8195_MMSYS_H +#define __SOC_MEDIATEK_MT8195_MMSYS_H + +#define MT8195_VDO0_OVL_MOUT_EN0xf14 +#define MT8195_MOUT_DISP_OVL0_TO_DISP_RDMA0BIT(0) +#define MT8195_MOUT_DISP_OVL0_TO_DISP_WDMA0BIT(1) +#define MT8195_MOUT_DISP_OVL0_TO_DISP_OVL1 BIT(2) +#define MT8195_MOUT_DISP_OVL1_TO_DISP_RDMA1BIT(4) +#define MT8195_MOUT_DISP_OVL1_TO_DISP_WDMA1BIT(5) +#define MT8195_MOUT_DISP_OVL1_TO_DISP_OVL0 BIT(6) + +#define MT8195_VDO0_SEL_IN 0xf34 +#define MT8195_SEL_IN_VPP_MERGE_FROM_DSC_WRAP0_OUT (0 << 0) Bitshifting 0 by 0 bits == 0, so this is simply 0. +#define MT8195_SEL_IN_VPP_MERGE_FROM_DISP_DITHER1 (1 << 0) I would write 0x1 here +#define MT8195_SEL_IN_VPP_MERGE_FROM_VDO1_VIRTUAL0 (2 << 0) and 0x2 here: bitshifting of 0 bits makes little sense. +#define MT8195_SEL_IN_DSC_WRAP0_IN_FROM_DISP_DITHER0 (0 << 4) Bitshifting 0 by 4 bits is still 0, so this is again 0. This is repeated too many times, so I will not list it for all of the occurrences. +#define MT8195_SEL_IN_DSC_WRAP0_IN_FROM_VPP_MERGE (1 << 4) This is BIT(4). +#define MT8195_SEL_IN_DSC_WRAP1_IN_FROM_DISP_DITHER1 (0 << 5) > +#define MT8195_SEL_IN_DSC_WRAP1_IN_FROM_VPP_MERGE (1 << 5) ...and this is BIT(5) +#define MT8195_SEL_IN_SINA_VIRTUAL0_FROM_VPP_MERGE (0 << 8) +#define MT8195_SEL_IN_SINA_VIRTUAL0_FROM_DSC_WRAP1_OUT (1 << 8) BIT(8) +#define MT8195_SEL_IN_SINB_VIRTUAL0_FROM_DSC_WRAP0_OUT (0 << 9) +#define MT8195_SEL_IN_DP_INTF0_FROM_DSC_WRAP1_OUT (0 << 12) +#define MT8195_SEL_IN_DP_INTF0_FROM_VPP_MERGE (1 << 12) BIT(12) +#define MT8195_SEL_IN_DP_INTF0_FROM_VDO1_VIRTUAL0 (2 << 12) BIT(13) ... and please, use the BIT(nr) macro for all these bit definitions, it's way more readable like that. Regards, - Angelo
Re: [PATCH v2 07/11] drm/msm/disp/dpu1: Add DSC support in hw_ctl
On 07/10/2021 10:08, Vinod Koul wrote:
Later gens of hardware have DSC bits moved to hw_ctl, so configure these
bits so that DSC would work there as well
Signed-off-by: Vinod Koul
---
Changes since
v1:
- Move this patch from 6 to 7 due to dependency on 6th one
- Use DSC indices for programming DSC registers and program only on non
null indices
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 3c79bd9c2fe5..8ea9d8dce3f7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -25,6 +25,8 @@
#define CTL_MERGE_3D_ACTIVE 0x0E4
#define CTL_INTF_ACTIVE 0x0F4
#define CTL_MERGE_3D_FLUSH0x100
+#define CTL_DSC_ACTIVE0x0E8
+#define CTL_DSC_FLUSH0x104
#define CTL_INTF_FLUSH0x110
#define CTL_INTF_MASTER 0x134
#define CTL_FETCH_PIPE_ACTIVE 0x0FC
@@ -34,6 +36,7 @@
#define DPU_REG_RESET_TIMEOUT_US2000
#define MERGE_3D_IDX 23
+#define DSC_IDX22
#define INTF_IDX 31
#define CTL_INVALID_BIT 0x
@@ -120,7 +123,6 @@ static u32 dpu_hw_ctl_get_pending_flush(struct dpu_hw_ctl *ctx)
static void dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)
{
-
if (ctx->pending_flush_mask & BIT(MERGE_3D_IDX))
DPU_REG_WRITE(&ctx->hw, CTL_MERGE_3D_FLUSH,
ctx->pending_merge_3d_flush_mask);
@@ -128,7 +130,6 @@ static void dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl
*ctx)
DPU_REG_WRITE(&ctx->hw, CTL_INTF_FLUSH,
ctx->pending_intf_flush_mask);
- DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, ctx->pending_flush_mask);
This would break non-DSC case.
}
static inline void dpu_hw_ctl_trigger_flush(struct dpu_hw_ctl *ctx)
@@ -498,6 +499,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
u32 intf_active = 0;
u32 mode_sel = 0;
+ if (cfg->dsc)
+ DPU_REG_WRITE(&ctx->hw, CTL_DSC_FLUSH, cfg->dsc);
+
if (cfg->intf_mode_sel == DPU_CTL_MODE_SEL_CMD)
mode_sel |= BIT(17);
@@ -509,6 +513,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
+ if (cfg->dsc) {
+ DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, ctx->pending_flush_mask |
BIT(DSC_IDX));
Why?
+ DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
+ }
}
static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
--
With best wishes
Dmitry
Re: [PATCH v2 04/11] drm/msm/disp/dpu1: Add DSC support in RM
On 07/10/2021 10:08, Vinod Koul wrote:
This add the bits in RM to enable the DSC blocks
Signed-off-by: Vinod Koul
---
Changes since
v1:
- Add _dpu_rm_reserve_dsc() function which checks if DSC is enabled
- Fix to use dsc_blks
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 61 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 1 +
3 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 323a6bce9e64..da646817585d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -159,6 +159,7 @@ struct dpu_global_state {
uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
uint32_t intf_to_enc_id[INTF_MAX - INTF_0];
uint32_t dspp_to_enc_id[DSPP_MAX - DSPP_0];
+ uint32_t dsc_to_enc_id[DSC_MAX - DSC_0];
};
struct dpu_global_state
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index f9c83d6e427a..95bdabc16280 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -11,6 +11,7 @@
#include "dpu_hw_intf.h"
#include "dpu_hw_dspp.h"
#include "dpu_hw_merge3d.h"
+#include "dpu_hw_dsc.h"
#include "dpu_encoder.h"
#include "dpu_trace.h"
@@ -75,6 +76,14 @@ int dpu_rm_destroy(struct dpu_rm *rm)
dpu_hw_intf_destroy(hw);
}
}
+ for (i = 0; i < ARRAY_SIZE(rm->dsc_blks); i++) {
+ struct dpu_hw_dsc *hw;
+
+ if (rm->dsc_blks[i]) {
+ hw = to_dpu_hw_dsc(rm->dsc_blks[i]);
+ dpu_hw_dsc_destroy(hw);
+ }
+ }
return 0;
}
@@ -221,6 +230,19 @@ int dpu_rm_init(struct dpu_rm *rm,
rm->dspp_blks[dspp->id - DSPP_0] = &hw->base;
}
+ for (i = 0; i < cat->dsc_count; i++) {
+ struct dpu_hw_dsc *hw;
+ const struct dpu_dsc_cfg *dsc = &cat->dsc[i];
+
+ hw = dpu_hw_dsc_init(dsc->id, mmio, cat);
+ if (IS_ERR_OR_NULL(hw)) {
+ rc = PTR_ERR(hw);
+ DPU_ERROR("failed dsc object creation: err %d\n", rc);
+ goto fail;
+ }
+ rm->dsc_blks[dsc->id - DSC_0] = &hw->base;
+ }
+
return 0;
fail:
@@ -476,6 +498,7 @@ static int _dpu_rm_reserve_intf(
}
global_state->intf_to_enc_id[idx] = enc_id;
+
return 0;
}
@@ -500,6 +523,33 @@ static int _dpu_rm_reserve_intf_related_hw(
return ret;
}
+static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
+ struct dpu_global_state *global_state,
+ struct drm_encoder *enc)
+{
+ struct msm_drm_private *priv;
+
+ priv = enc->dev->dev_private;
+
+ if (!priv)
+ return -EIO;
+
+ /* check if DSC is supported */
+ if (!priv->dsc)
+ return 0;
+
+ /* check if DSC 0 & 1 and allocated or not */
+ if (global_state->dsc_to_enc_id[0] || global_state->dsc_to_enc_id[1]) {
+ DPU_ERROR("DSC 0|1 is already allocated\n");
+ return -EIO;
+ }
+
+ global_state->dsc_to_enc_id[0] = enc->base.id;
+ global_state->dsc_to_enc_id[1] = enc->base.id;
Still hardcoding DSC_0 and DSC_1.
Could you please add num_dsc to the topology and allocate the requested
amount of DSC blocks? Otherwise this would break for the DSI + DP case.
+
+ return 0;
+}
+
static int _dpu_rm_make_reservation(
struct dpu_rm *rm,
struct dpu_global_state *global_state,
@@ -526,6 +576,10 @@ static int _dpu_rm_make_reservation(
if (ret)
return ret;
+ ret = _dpu_rm_reserve_dsc(rm, global_state, enc);
+ if (ret)
+ return ret;
+
return ret;
}
@@ -567,6 +621,8 @@ void dpu_rm_release(struct dpu_global_state *global_state,
ARRAY_SIZE(global_state->ctl_to_enc_id), enc->base.id);
_dpu_rm_clear_mapping(global_state->intf_to_enc_id,
ARRAY_SIZE(global_state->intf_to_enc_id), enc->base.id);
+ _dpu_rm_clear_mapping(global_state->dsc_to_enc_id,
+ ARRAY_SIZE(global_state->dsc_to_enc_id), enc->base.id);
}
int dpu_rm_reserve(
@@ -640,6 +696,11 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
hw_to_enc_id = global_state->dspp_to_enc_id;
max_blks = ARRAY_SIZE(rm->dspp_blks);
break;
+ case DPU_HW_BLK_DSC:
+ hw_blks = rm->dsc_blks;
+ hw_to_enc_id = global_state->dsc_to_enc_id;
+ max_blks = ARRAY_SIZE(rm->dsc_blks);
+ break;
default:
DPU_ERROR("blk type %d not managed by rm\n", type);
return 0;
diff --git a/drivers/gpu/drm
Re: [PATCH v2 09/11] drm/msm/disp/dpu1: Add support for DSC in topology
On 07/10/2021 10:08, Vinod Koul wrote:
For DSC to work we typically need a 2,2,1 configuration. This should
suffice for resolutions upto 4k. For more resolutions like 8k this won't
work.
Also, it is better to use 2 LMs and DSC instances as half width results
in lesser power consumption as compared to single LM, DSC at full width.
The panel has been tested only with 2,2,1 configuration, so for
now we blindly create 2,2,1 topology when DSC is enabled
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Signed-off-by: Vinod Koul
---
Changes since
RFC:
- Add more details in changelog
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index aac51c1bdf94..70f57a071165 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -538,6 +538,8 @@ static struct msm_display_topology dpu_encoder_get_topology(
struct drm_display_mode *mode)
{
struct msm_display_topology topology = {0};
+ struct drm_encoder *drm_enc;
+ struct msm_drm_private *priv;
int i, intf_count = 0;
for (i = 0; i < MAX_PHYS_ENCODERS_PER_VIRTUAL; i++)
@@ -572,8 +574,22 @@ static struct msm_display_topology
dpu_encoder_get_topology(
topology.num_enc = 0;
topology.num_intf = intf_count;
+ drm_enc = &dpu_enc->base;
+ priv = drm_enc->dev->dev_private;
+ if (priv && priv->dsc) {
+ /* In case of Display Stream Compression DSC, we would use
+* 2 encoders, 2 line mixers and 1 interface
+* this is power optimal and can drive upto (including) 4k
+* screens
+*/
+ topology.num_enc = 2;
+ topology.num_intf = 1;
+ topology.num_lm = 2;
So, here you'd set the topology.num_rm.
+ }
+
return topology;
}
+
static int dpu_encoder_virt_atomic_check(
struct drm_encoder *drm_enc,
struct drm_crtc_state *crtc_state,
--
With best wishes
Dmitry
[PULL] drm-intel-fixes
Hi Dave & Daniel - drm-intel-fixes-2021-10-14: drm/i915 fixes for v5.15-rc6: - Fix ACPI object leak - Fix context leak in user proto-context creation - Fix missing i915_sw_fence_fini call BR, Jani. The following changes since commit 64570fbc14f8d7cb3fe3995f20e26bc25ce4b2cc: Linux 5.15-rc5 (2021-10-10 17:01:59 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-10-14 for you to fetch changes up to 82a59c7f456db9f2874e9f1e9cb4cc19e71e95c5: drm/i915: Free the returned object of acpi_evaluate_dsm() (2021-10-13 13:41:16 +0300) drm/i915 fixes for v5.15-rc6: - Fix ACPI object leak - Fix context leak in user proto-context creation - Fix missing i915_sw_fence_fini call Matthew Auld (1): drm/i915: remember to call i915_sw_fence_fini Matthew Brost (1): drm/i915: Fix bug in user proto-context creation that leaked contexts Zenghui Yu (1): drm/i915: Free the returned object of acpi_evaluate_dsm() drivers/gpu/drm/i915/display/intel_acpi.c | 7 +-- drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 - drivers/gpu/drm/i915/gt/intel_context.c | 1 + 3 files changed, 10 insertions(+), 3 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 03/14] drm/i915/xehpsdv: enforce min GTT alignment
On 14/10/2021 14:33, Daniel Vetter wrote:
On Wed, Oct 13, 2021 at 03:13:33PM +0100, Matthew Auld wrote:
On 13/10/2021 14:38, Daniel Vetter wrote:
On Mon, Oct 11, 2021 at 09:41:44PM +0530, Ramalingam C wrote:
From: Matthew Auld
For local-memory objects we need to align the GTT addresses to 64K, both
for the ppgtt and ggtt.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Do we still need this with relocations removed? Userspace is picking all
the addresses for us, so all we have to check is whether userspace got it
right.
Yeah, for OFFSET_FIXED this just validates that the provided address is
correctly aligned to 64K, while for the in-kernel insertion stuff we still
need to allocate an address that is aligned to 64K. Setting the alignment
here handles both cases.
Can't we just teach any in-kernel allocators to align to 2M and call it a
day? Ofc the code can still validate we don't have bugs (always good to
check your work). Ofc if the benefits is "no code can be removed anyway
since we still need to check" then ofc no point :-)
Yeah, if we want to make it 2M, then we still need to add that here,
like with 64K.
Just want to make sure we're not carrying complexity around for nothing,
since this predates the relocation removal.
If we were to just make everything 2M then we can in theory ditch all
the colouring stuff. Assuming userspace is happy with 2M or nothing,
then it just means potentially terrible utilisation of the ppGTT for the
kernel, but maybe that doesn't matter much really? For userspace maybe
they will have some kind of sub-allocation scheme?
Well actually I guess it would be 2M alignment + 2M vma padding for
anything that can be placed in I915_MEMORY_CLASS_DEVICE, including mixed
objects. And then the usual 4K alignment for I915_MEMORY_CLASS_SYSTEM
only objects.
-Daniel
-Daniel
---
drivers/gpu/drm/i915/i915_vma.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4b7fc4647e46..1ea1fa08efdf 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -670,8 +670,13 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
}
color = 0;
- if (vma->obj && i915_vm_has_cache_coloring(vma->vm))
- color = vma->obj->cache_level;
+ if (vma->obj) {
+ if (HAS_64K_PAGES(vma->vm->i915) &&
i915_gem_object_is_lmem(vma->obj))
+ alignment = max(alignment, I915_GTT_PAGE_SIZE_64K);
+
+ if (i915_vm_has_cache_coloring(vma->vm))
+ color = vma->obj->cache_level;
+ }
if (flags & PIN_OFFSET_FIXED) {
u64 offset = flags & PIN_OFFSET_MASK;
--
2.20.1
Re: [PATCH v11 15/16] drm/mediatek: add MERGE support for mediatek-drm
Il 21/09/21 17:52, jason-jh.lin ha scritto:
Add MERGE engine file:
MERGE module is used to merge two slice-per-line inputs
into one side-by-side output.
Signed-off-by: jason-jh.lin
---
rebase on series [1]
[1] drm/mediatek: add support for mediatek SOC MT8192
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=529489
---
drivers/gpu/drm/mediatek/Makefile | 1 +
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 +
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 239
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 16 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
7 files changed, 269 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_merge.c
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index 29098d7c8307..a38e88e82d12 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -4,6 +4,7 @@ mediatek-drm-y := mtk_disp_aal.o \
mtk_disp_ccorr.o \
mtk_disp_color.o \
mtk_disp_gamma.o \
+ mtk_disp_merge.o \
mtk_disp_ovl.o \
mtk_disp_rdma.o \
mtk_drm_crtc.o \
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 86c3068894b1..a33b13fe2b6e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -55,6 +55,14 @@ void mtk_gamma_set_common(void __iomem *regs, struct
drm_crtc_state *state);
void mtk_gamma_start(struct device *dev);
void mtk_gamma_stop(struct device *dev);
+int mtk_merge_clk_enable(struct device *dev);
+void mtk_merge_clk_disable(struct device *dev);
+void mtk_merge_config(struct device *dev, unsigned int width,
+ unsigned int height, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+void mtk_merge_start(struct device *dev);
+void mtk_merge_stop(struct device *dev);
+
void mtk_ovl_bgclr_in_on(struct device *dev);
void mtk_ovl_bgclr_in_off(struct device *dev);
void mtk_ovl_bypass_shadow(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
new file mode 100644
index ..b05e1df79c3d
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
@@ -0,0 +1,239 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_drv.h"
+#include "mtk_disp_drv.h"
+
+#define DISP_REG_MERGE_CTRL0x000
+#define MERGE_EN 1
+#define DISP_REG_MERGE_CFG_0 0x010
+#define DISP_REG_MERGE_CFG_4 0x020
+#define DISP_REG_MERGE_CFG_10 0x038
+/* no swap */
+#define SWAP_MODE 0
+#define FLD_SWAP_MODE GENMASK(4, 0)
+#define DISP_REG_MERGE_CFG_12 0x040
+#define CFG_10_10_1PI_2PO_BUF_MODE 6
+#define CFG_10_10_2PI_2PO_BUF_MODE 8
+#define FLD_CFG_MERGE_MODE GENMASK(4, 0)
+#define DISP_REG_MERGE_CFG_24 0x070
+#define DISP_REG_MERGE_CFG_25 0x074
+#define DISP_REG_MERGE_CFG_36 0x0a0
+#define ULTRA_EN BIT(0)
+#define PREULTRA_ENBIT(4)
+#define DISP_REG_MERGE_CFG_37 0x0a4
+/* 0: Off, 1: SRAM0, 2: SRAM1, 3: SRAM0 + SRAM1 */
+#define BUFFER_MODE3
+#define FLD_BUFFER_MODEGENMASK(1, 0)
+/*
+ * For the ultra and preultra settings, 6us ~ 9us is experience value
+ * and the maximum frequency of mmsys clock is 594MHz.
+ */
+#define DISP_REG_MERGE_CFG_40 0x0b0
+/* 6 us, 594M pixel/sec */
+#define ULTRA_TH_LOW (6 * 594)
+/* 8 us, 594M pixel/sec */
+#define ULTRA_TH_HIGH (8 * 594)
+#define FLD_ULTRA_TH_LOW GENMASK(15, 0)
+#define FLD_ULTRA_TH_HIGH GENMASK(31, 16)
+#define DISP_REG_MERGE_CFG_41 0x0b4
+/* 8 us, 594M pixel/sec */
+#define PREULTRA_TH_LOW(8 * 594)
+/* 9 us, 594M pixel/sec */
+#define PREULTRA_TH_HIGH (9 * 594)
+#define FLD_PREULTRA_TH_LOWGENMASK(15, 0)
+#define FLD_PREULTRA_TH_HIGH GENMASK(31, 16)
+
+struct mtk_disp_merge {
+ void __iomem *regs;
+ struct clk *clk;
+ struct clk *async_clk;
+ struct cmdq_client_reg cmdq_reg;
+ boolfifo_en;
+};
+
+void mtk_merge_start(struct device *dev)
+{
+ struct mtk_disp_merge *priv = dev_get_drvdata(dev);
+
+ writel(MERGE_EN,
Re: [Intel-gfx] [PULL] drm-misc-next
Hi, On 10/14/21 3:24 PM, Hans de Goede wrote: > Hi, > > On 10/14/21 2:04 PM, Maxime Ripard wrote: >> Hi Dave, Daniel, >> >> Here's this week drm-misc-next PR >> >> Maxime >> >> drm-misc-next-2021-10-14: >> drm-misc-next for 5.16: > > Ugh, this just missed the drm-privacy-screen work which I just pushed > out to drm-misc-next (I was waiting for the last i915 integration patch > to get reviewed). > > It would be nice if we can still get the drm-privacy-screen work > included into 5.16. But if it is too late I understand. Thinking more about this, delaying this till 5.17 is fine, that will nicely align its release with GNOME42 which will be the first userspace to support this; and it will give it a nice long time to find any issues in -next (not that I expect any). Regards, Hans >> UAPI Changes: >> >> Cross-subsystem Changes: >> >> Core Changes: >> - fbdev: Fix double-free, Remove unused scrolling acceleration >> - locking: improve logging for contented locks without backoff >> - dma-buf: Add dma_resv_for_each_fence iterator, and conversion of >> users >> >> Driver Changes: >> - nouveau: Various code style improvements >> - bridge: HPD improvements for lt9611uxc, eDP aux-bus support for >> ps8640, lvds-codec data-mapping selection support >> - panels: Vivax TPC-9150, Innolux G070Y2-T02, LOGIC Technologies >> LTTD800480070-L2RT, Sharp LS060T1SX01, >> The following changes since commit 9962601ca5719050906915c3c33a63744ac7b15c: >> >> drm/bridge: dw-hdmi-cec: Make use of the helper function >> devm_add_action_or_reset() (2021-10-06 11:21:46 +0200) >> >> are available in the Git repository at: >> >> git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-10-14 >> >> for you to fetch changes up to b3ec8cdf457e5e63d396fe1346cc788cf7c1b578: >> >> fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO >> list) (2021-10-13 15:29:23 +0200) >> >> >> drm-misc-next for 5.16: >> >> UAPI Changes: >> >> Cross-subsystem Changes: >> >> Core Changes: >> - fbdev: Fix double-free, Remove unused scrolling acceleration >> - locking: improve logging for contented locks without backoff >> - dma-buf: Add dma_resv_for_each_fence iterator, and conversion of >> users >> >> Driver Changes: >> - nouveau: Various code style improvements >> - bridge: HPD improvements for lt9611uxc, eDP aux-bus support for >> ps8640, lvds-codec data-mapping selection support >> - panels: Vivax TPC-9150, Innolux G070Y2-T02, LOGIC Technologies >> LTTD800480070-L2RT, Sharp LS060T1SX01, >> >> >> Alex Xu (Hello71) (1): >> drm/plane-helper: fix uninitialized variable reference >> >> Amos Kong (1): >> drm/ttm_bo_api: update the description for @placement and @sg >> >> Christian König (7): >> dma-buf: add dma_resv_for_each_fence v3 >> dma-buf: use the new iterator in dma_buf_debug_show >> dma-buf: use the new iterator in dma_resv_poll >> drm/ttm: use the new iterator in ttm_bo_flush_all_fences >> drm/scheduler: use new iterator in >> drm_sched_job_add_implicit_dependencies v2 >> drm/i915: use the new iterator in i915_request_await_object v2 >> drm: use new iterator in drm_gem_fence_array_add_implicit v3 >> >> Claudio Suarez (1): >> fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO >> list) >> >> Dan Carpenter (1): >> drm/v3d: fix copy_from_user() error codes >> >> David Heidelberg (1): >> dt-bindings: display: simple: hardware can use ddc-i2c-bus >> >> Dmitry Baryshkov (5): >> drm/bridge/lontium-lt9611uxc: fix provided connector suport >> dt-bindings: add bindings for the Sharp LS060T1SX01 panel >> drm/panel: Add support for Sharp LS060T1SX01 panel >> dt-bindings: add bindings for the Sharp LS060T1SX01 panel >> drm/panel: Add support for Sharp LS060T1SX01 panel >> >> Guido Günther (5): >> drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts >> drm/panel: mantix: Add media bus format >> drm/panel: st7703: Add media bus format >> drm: mxsfb: Print failed bus format in hex >> drm: mxsfb: Set fallback bus format when the bridge doesn't provide one >> >> Jani Nikula (1): >> drm/locking: add backtrace for locking contended locks without backoff >> >> Jing Xiangfeng (1): >> drm/virtio: fix the missed drm_gem_object_put() in >> virtio_gpu_user_framebuffer_create() >> >> Karol Herbst (1): >> drm/nouveau/mmu/gp100: remove unused variable >> >> Lee Jones (1): >> drm/nouveau/nouveau_bo: Remove unused variables 'dev' >> >> Luo penghao (2): >> drm/nouveau/mmu: drop unneeded assignment in the nvkm_uvmm_mthd_page() >> drm/nouveau/mmu/gp100-: drop unneeded assignment in the if condition. >> >> Marek Vasut (3): >> drm/bridge: ti-sn65dsi83: Implement .detach callback >>
Re: [PATCH v2 02/11] drm/msm/disp/dpu1: Add support for DSC
On 07/10/2021 10:08, Vinod Koul wrote:
Display Stream Compression (DSC) is one of the hw blocks in dpu, so add
support by adding hw blocks for DSC
Signed-off-by: Vinod Koul
---
Changes since
v1:
- remove unused variable lp
- Update copyright year
RFC:
- Drop unused enums
drivers/gpu/drm/msm/Makefile | 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 13 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 210 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h| 77 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 13 ++
5 files changed, 314 insertions(+)
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 904535eda0c4..46c05e401d04 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -60,6 +60,7 @@ msm-y := \
disp/dpu1/dpu_formats.o \
disp/dpu1/dpu_hw_catalog.o \
disp/dpu1/dpu_hw_ctl.o \
+ disp/dpu1/dpu_hw_dsc.o \
disp/dpu1/dpu_hw_interrupts.o \
disp/dpu1/dpu_hw_intf.o \
disp/dpu1/dpu_hw_lm.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index d2a945a27cfa..699c378814b1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -553,6 +553,16 @@ struct dpu_merge_3d_cfg {
const struct dpu_merge_3d_sub_blks *sblk;
};
+/**
+ * struct dpu_dsc_cfg - information of DSC blocks
+ * @id enum identifying this block
+ * @base register offset of this block
+ * @features bit mask identifying sub-blocks/features
+ */
+struct dpu_dsc_cfg {
+ DPU_HW_BLK_INFO;
+};
+
/**
* struct dpu_intf_cfg - information of timing engine blocks
* @id enum identifying this block
@@ -757,6 +767,9 @@ struct dpu_mdss_cfg {
u32 merge_3d_count;
const struct dpu_merge_3d_cfg *merge_3d;
+ u32 dsc_count;
+ struct dpu_dsc_cfg *dsc;
+
u32 intf_count;
const struct dpu_intf_cfg *intf;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
new file mode 100644
index ..09682c4832ba
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020-2021, Linaro Limited
+ */
+
+#include "dpu_kms.h"
+#include "dpu_hw_catalog.h"
+#include "dpu_hwio.h"
+#include "dpu_hw_mdss.h"
+#include "dpu_hw_dsc.h"
+
+#define DSC_COMMON_MODE0x000
+#define DSC_ENC 0X004
+#define DSC_PICTURE 0x008
+#define DSC_SLICE 0x00C
+#define DSC_CHUNK_SIZE 0x010
+#define DSC_DELAY 0x014
+#define DSC_SCALE_INITIAL 0x018
+#define DSC_SCALE_DEC_INTERVAL 0x01C
+#define DSC_SCALE_INC_INTERVAL 0x020
+#define DSC_FIRST_LINE_BPG_OFFSET 0x024
+#define DSC_BPG_OFFSET 0x028
+#define DSC_DSC_OFFSET 0x02C
+#define DSC_FLATNESS0x030
+#define DSC_RC_MODEL_SIZE 0x034
+#define DSC_RC 0x038
+#define DSC_RC_BUF_THRESH 0x03C
+#define DSC_RANGE_MIN_QP0x074
+#define DSC_RANGE_MAX_QP0x0B0
+#define DSC_RANGE_BPG_OFFSET0x0EC
+
+static void dpu_hw_dsc_disable(struct dpu_hw_dsc *dsc)
+{
+ struct dpu_hw_blk_reg_map *c = &dsc->hw;
+
+ DPU_REG_WRITE(c, DSC_COMMON_MODE, 0);
+}
+
+static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
+ struct msm_display_dsc_config *dsc, u32 mode)
+{
+ struct dpu_hw_blk_reg_map *c = &hw_dsc->hw;
+ u32 data, lsb, bpp;
+ u32 initial_lines = dsc->initial_lines;
+ bool is_cmd_mode = !(mode & BIT(2));
DSC_MODE_VIDEO
+
+ DPU_REG_WRITE(c, DSC_COMMON_MODE, mode);
+
+ if (is_cmd_mode)
+ initial_lines += 1;
+
+ data = (initial_lines << 20);
+ data |= ((dsc->slice_last_group_size - 1) << 18);
+ /* bpp is 6.4 format, 4 LSBs bits are for fractional part */
+ data |= dsc->drm->bits_per_pixel << 12;
+ lsb = dsc->drm->bits_per_pixel % 4;
+ bpp = dsc->drm->bits_per_pixel / 4;
+ bpp *= 4;
+ bpp <<= 4;
+ bpp |= lsb;
+
+ data |= bpp << 8;
+ data |= (dsc->drm->block_pred_enable << 7);
+ data |= (dsc->drm->line_buf_depth << 3);
+ data |= (dsc->drm->simple_422 << 2);
+ data |= (dsc->drm->convert_rgb << 1);
+ data |= dsc->drm->bits_per_component;
+
+ DPU_REG_WRITE(c, DSC_ENC, data);
+
+ data = dsc->drm->pic_width << 16;
+ data |= dsc->drm->pic_height;
+ DPU_REG_WRITE(c, DSC_PICTURE, data);
+
+ data
Re: [PATCH v6 06/16] soc: mediatek: add mtk-mmsys support for mt8195 vdosys1
Add mt8195 vdosys1 clock driver name and routing table to the driver data of mtk-mmsys. Signed-off-by: Nancy.Lin --- drivers/soc/mediatek/mt8195-mmsys.h| 136 + drivers/soc/mediatek/mtk-mmsys.c | 10 ++ include/linux/soc/mediatek/mtk-mmsys.h | 2 + 3 files changed, 148 insertions(+) diff --git a/drivers/soc/mediatek/mt8195-mmsys.h b/drivers/soc/mediatek/mt8195-mmsys.h index 0c97a5f016c1..f19ec72c1243 100644 --- a/drivers/soc/mediatek/mt8195-mmsys.h +++ b/drivers/soc/mediatek/mt8195-mmsys.h @@ -59,6 +59,70 @@ #define MT8195_SOUT_DSC_WRAP1_OUT_TO_SINA_VIRTUAL0(2 << 16) #define MT8195_SOUT_DSC_WRAP1_OUT_TO_VPP_MERGE(3 << 16) +#define MT8195_VDO1_VPP_MERGE0_P0_SEL_IN 0xf04 +#define MT8195_VPP_MERGE0_P0_SEL_IN_FROM_MDP_RDMA0 (1 << 0) There is no bitshifting action here: this is simply 1. + +#define MT8195_VDO1_VPP_MERGE0_P1_SEL_IN 0xf08 +#define MT8195_VPP_MERGE0_P1_SEL_IN_FROM_MDP_RDMA1 (1 << 0) Same here. + +#define MT8195_VDO1_DISP_DPI1_SEL_IN 0xf10 +#define MT8195_DISP_DPI1_SEL_IN_FROM_VPP_MERGE4_MOUT (0 << 0) And this is 0. + +#define MT8195_VDO1_DISP_DP_INTF0_SEL_IN 0xf14 +#define MT8195_DISP_DP_INTF0_SEL_IN_FROM_VPP_MERGE4_MOUT (0 << 0) + +#define MT8195_VDO1_MERGE4_SOUT_SEL0xf18 +#define MT8195_MERGE4_SOUT_TO_DPI1_SEL (2 << 0) This is simply 0x2... +#define MT8195_MERGE4_SOUT_TO_DP_INTF0_SEL (3 << 0) ...and this is 0x3. There are other occurrences of the same logic, so please fix them all. Regards, - Angelo
Re: [PATCH v6 09/16] soc: mediatek: mmsys: modify reset controller for MT8195 vdosys1
Il 04/10/21 08:21, Nancy.Lin ha scritto: MT8195 vdosys1 has more than 32 reset bits and a different reset base than other chips. Modify mmsys for support 64 bit and different reset base. Signed-off-by: Nancy.Lin --- drivers/soc/mediatek/mt8195-mmsys.h | 1 + drivers/soc/mediatek/mtk-mmsys.c| 21 - drivers/soc/mediatek/mtk-mmsys.h| 2 ++ 3 files changed, 19 insertions(+), 5 deletions(-) diff --git a/drivers/soc/mediatek/mt8195-mmsys.h b/drivers/soc/mediatek/mt8195-mmsys.h index 648baaec112b..f67801c42fd9 100644 --- a/drivers/soc/mediatek/mt8195-mmsys.h +++ b/drivers/soc/mediatek/mt8195-mmsys.h @@ -123,6 +123,7 @@ #define MT8195_VDO1_MIXER_SOUT_SEL_IN 0xf68 #define MT8195_MIXER_SOUT_SEL_IN_FROM_DISP_MIXER (0 << 0) +#define MT8195_VDO1_SW0_RST_B 0x1d0 All other definitions are indented with tabulations, but these are spaces here. Please, do not mix formatting. Regards, - Angelo
[PATCH 3/3] drm/i915/dp: use new link training delay helpers
Use the new link training delay helpers, fixing the delays for
128b/132b.
For existing 8b/10b functionality, this will cause additional 1-byte
DPCD reads for LTTPR delays instead of using the cached values. It's
just too complicated to combine generic helpers with local caching in a
sensible way.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_dp_link_training.c | 38 +++
1 file changed, 13 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 85676c953e0a..a72f2dc93718 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -683,15 +683,6 @@ intel_dp_prepare_link_train(struct intel_dp *intel_dp,
return true;
}
-static void intel_dp_link_training_clock_recovery_delay(struct intel_dp
*intel_dp,
- enum drm_dp_phy dp_phy)
-{
- if (dp_phy == DP_PHY_DPRX)
- drm_dp_link_train_clock_recovery_delay(&intel_dp->aux,
intel_dp->dpcd);
- else
- drm_dp_lttpr_link_train_clock_recovery_delay();
-}
-
static bool intel_dp_adjust_request_changed(const struct intel_crtc_state
*crtc_state,
const u8
old_link_status[DP_LINK_STATUS_SIZE],
const u8
new_link_status[DP_LINK_STATUS_SIZE])
@@ -750,6 +741,11 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
u8 link_status[DP_LINK_STATUS_SIZE];
bool max_vswing_reached = false;
char phy_name[10];
+ int delay_us;
+
+ delay_us = drm_dp_read_clock_recovery_delay(&intel_dp->aux,
+ intel_dp->dpcd, dp_phy,
+
intel_dp_is_uhbr(crtc_state));
intel_dp_phy_name(dp_phy, phy_name, sizeof(phy_name));
@@ -777,7 +773,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
voltage_tries = 1;
for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
- intel_dp_link_training_clock_recovery_delay(intel_dp, dp_phy);
+ usleep_range(delay_us, 2 * delay_us);
if (drm_dp_dpcd_read_phy_link_status(&intel_dp->aux, dp_phy,
link_status) < 0) {
@@ -895,19 +891,6 @@ static u32 intel_dp_training_pattern(struct intel_dp
*intel_dp,
return DP_TRAINING_PATTERN_2;
}
-static void
-intel_dp_link_training_channel_equalization_delay(struct intel_dp *intel_dp,
- enum drm_dp_phy dp_phy)
-{
- if (dp_phy == DP_PHY_DPRX) {
- drm_dp_link_train_channel_eq_delay(&intel_dp->aux,
intel_dp->dpcd);
- } else {
- const u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
-
- drm_dp_lttpr_link_train_channel_eq_delay(&intel_dp->aux,
phy_caps);
- }
-}
-
/*
* Perform the link training channel equalization phase on the given DP PHY
* using one of training pattern 2, 3 or 4 depending on the source and
@@ -925,6 +908,11 @@ intel_dp_link_training_channel_equalization(struct
intel_dp *intel_dp,
u8 link_status[DP_LINK_STATUS_SIZE];
bool channel_eq = false;
char phy_name[10];
+ int delay_us;
+
+ delay_us = drm_dp_read_channel_eq_delay(&intel_dp->aux,
+ intel_dp->dpcd, dp_phy,
+ intel_dp_is_uhbr(crtc_state));
intel_dp_phy_name(dp_phy, phy_name, sizeof(phy_name));
@@ -944,8 +932,8 @@ intel_dp_link_training_channel_equalization(struct intel_dp
*intel_dp,
}
for (tries = 0; tries < 5; tries++) {
- intel_dp_link_training_channel_equalization_delay(intel_dp,
- dp_phy);
+ usleep_range(delay_us, 2 * delay_us);
+
if (drm_dp_dpcd_read_phy_link_status(&intel_dp->aux, dp_phy,
link_status) < 0) {
drm_err(&i915->drm,
--
2.30.2
[PATCH 2/3] drm/dp: reuse the 8b/10b link training delay helpers
Reuse the 8b/10b link training delay helpers. Functionally this skips
the check for invalid values for DPCD 1.4 and later at clock recovery
delay (as it's a fixed delay and bypasses the rd_interval) but the same
value will be checked and invalid values reported at channel
equalization.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f7ebf5974fa7..ada0a1ff262d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -284,35 +284,25 @@ EXPORT_SYMBOL(drm_dp_read_channel_eq_delay);
void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
- unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
-DP_TRAINING_AUX_RD_MASK;
+ u8 rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_TRAINING_AUX_RD_MASK;
+ int delay_us;
- if (rd_interval > 4)
- drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range
(max 4)\n",
- aux->name, rd_interval);
-
- if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
- rd_interval = 100;
+ if (dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
+ delay_us = 100;
else
- rd_interval *= 4 * USEC_PER_MSEC;
+ delay_us = __8b10b_clock_recovery_delay_us(aux, rd_interval);
- usleep_range(rd_interval, rd_interval * 2);
+ usleep_range(delay_us, delay_us * 2);
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
static void __drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
-unsigned long rd_interval)
+u8 rd_interval)
{
- if (rd_interval > 4)
- drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range
(max 4)\n",
- aux->name, rd_interval);
-
- if (rd_interval == 0)
- rd_interval = 400;
- else
- rd_interval *= 4 * USEC_PER_MSEC;
+ int delay_us = __8b10b_channel_eq_delay_us(aux, rd_interval);
- usleep_range(rd_interval, rd_interval * 2);
+ usleep_range(delay_us, delay_us * 2);
}
void drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
--
2.30.2
[PATCH 1/3] drm/dp: add helpers to read link training delays
The link training delays are different and/or available in different
DPCD offsets depending on:
- Clock recovery vs. channel equalization
- DPRX vs. LTTPR
- 128b/132b vs. 8b/10b
- DPCD 1.4+ vs. earlier
Add helpers to get the correct delays in us, reading DPCD if
necessary. This is more straightforward than trying to retrofit the
existing helpers to take 128b/132b into account.
Having to pass in the DPCD receiver cap field seems unavoidable, because
reading it involves checking the revision and reading extended receiver
cap. So unfortunately the interface is mixed cached and read as needed.
v2: Remove delay_us < 0 check and the whole local var (Ville)
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 127
include/drm/drm_dp_helper.h | 21 +-
2 files changed, 146 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4d0d1e8e51fa..f7ebf5974fa7 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -154,6 +154,133 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZ
}
EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
+static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux, u8
rd_interval)
+{
+ if (rd_interval > 4)
+ drm_dbg_kms(aux->drm_dev, "%s: invalid AUX interval 0x%02x (max
4)\n",
+ aux->name, rd_interval);
+
+ if (rd_interval == 0)
+ return 100;
+
+ return rd_interval * 4 * USEC_PER_MSEC;
+}
+
+static int __8b10b_channel_eq_delay_us(const struct drm_dp_aux *aux, u8
rd_interval)
+{
+ if (rd_interval > 4)
+ drm_dbg_kms(aux->drm_dev, "%s: invalid AUX interval 0x%02x (max
4)\n",
+ aux->name, rd_interval);
+
+ if (rd_interval == 0)
+ return 400;
+
+ return rd_interval * 4 * USEC_PER_MSEC;
+}
+
+static int __128b132b_channel_eq_delay_us(const struct drm_dp_aux *aux, u8
rd_interval)
+{
+ switch (rd_interval) {
+ default:
+ drm_dbg_kms(aux->drm_dev, "%s: invalid AUX interval 0x%02x\n",
+ aux->name, rd_interval);
+ fallthrough;
+ case DP_128B132B_TRAINING_AUX_RD_INTERVAL_400_US:
+ return 400;
+ case DP_128B132B_TRAINING_AUX_RD_INTERVAL_4_MS:
+ return 4000;
+ case DP_128B132B_TRAINING_AUX_RD_INTERVAL_8_MS:
+ return 8000;
+ case DP_128B132B_TRAINING_AUX_RD_INTERVAL_12_MS:
+ return 12000;
+ case DP_128B132B_TRAINING_AUX_RD_INTERVAL_16_MS:
+ return 16000;
+ case DP_128B132B_TRAINING_AUX_RD_INTERVAL_32_MS:
+ return 32000;
+ case DP_128B132B_TRAINING_AUX_RD_INTERVAL_64_MS:
+ return 64000;
+ }
+}
+
+/*
+ * The link training delays are different for:
+ *
+ * - Clock recovery vs. channel equalization
+ * - DPRX vs. LTTPR
+ * - 128b/132b vs. 8b/10b
+ * - DPCD rev 1.3 vs. later
+ *
+ * Get the correct delay in us, reading DPCD if necessary.
+ */
+static int __read_delay(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE],
+ enum drm_dp_phy dp_phy, bool uhbr, bool cr)
+{
+ int (*parse)(const struct drm_dp_aux *aux, u8 rd_interval);
+ unsigned int offset;
+ u8 rd_interval, mask;
+
+ if (dp_phy == DP_PHY_DPRX) {
+ if (uhbr) {
+ if (cr)
+ return 100;
+
+ offset = DP_128B132B_TRAINING_AUX_RD_INTERVAL;
+ mask = DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK;
+ parse = __128b132b_channel_eq_delay_us;
+ } else {
+ if (cr && dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
+ return 100;
+
+ offset = DP_TRAINING_AUX_RD_INTERVAL;
+ mask = DP_TRAINING_AUX_RD_MASK;
+ if (cr)
+ parse = __8b10b_clock_recovery_delay_us;
+ else
+ parse = __8b10b_channel_eq_delay_us;
+ }
+ } else {
+ if (uhbr) {
+ offset =
DP_128B132B_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER(dp_phy);
+ mask = DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK;
+ parse = __128b132b_channel_eq_delay_us;
+ } else {
+ if (cr)
+ return 100;
+
+ offset =
DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER(dp_phy);
+ mask = DP_TRAINING_AUX_RD_MASK;
+ parse = __8b10b_channel_eq_delay_us;
+ }
+ }
+
+ if (offset < DP_RECEIVER_CAP_SIZE) {
+ rd_inter
Re: [PATCH v6 10/16] soc: mediatek: add mtk-mutex support for mt8195 vdosys1
Add mtk-mutex support for mt8195 vdosys1. The vdosys1 path component contains ovl_adaptor, merge5, and dp_intf1. Ovl_adaptor is composed of several sub-elements, so change it to support multi-bit control. Signed-off-by: Nancy.Lin --- drivers/soc/mediatek/mtk-mutex.c | 296 ++- 1 file changed, 175 insertions(+), 121 deletions(-) diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c index 36502b27fe20..7767fedbd14f 100644 --- a/drivers/soc/mediatek/mtk-mutex.c +++ b/drivers/soc/mediatek/mtk-mutex.c @@ -29,113 +29,142 @@ #define INT_MUTEXBIT(1) -#define MT8167_MUTEX_MOD_DISP_PWM 1 This patch doesn't only add support for MT8195 vdosys1, but also changes all definitions to a different "format", and also changes the type for "mutex_mod" from int to long. In reality, the actual functional change is minimal, compared to the size of this entire patch. Please, split this patch in two parts: one patch changing the defines and the mutex_mod type (specifying that it's a preparation for adding support for mt8195 vdosys1 mutex) and one patch adding such support. Thanks! Regards, - Angelo
[PATCH 0/7] drm/meson: rework encoders to pass ATTACH_NO_CONNECTOR
This serie finnally reworks the drm/meson driver by extracting the encoders
in their own file and moves to bridge-only callbacks.
This permits passing the ATTACH_NO_CONNECTOR bridge attach flag and finally
use the CVBS & HDMI display-connector driver.
This will ease Martin Blumenstingl writting the HDMI transceiver driver for
the older Meson8/8b SoCs, and sets the proper architecture for the work in
progress MIPI-DSI support.
Finally, this serie will path the way to a removal of the device component
and use the drmm memory management.
Neil Armstrong (7):
drm/bridge: display-connector: implement bus fmts callbacks
drm/meson: remove useless recursive components matching
drm/meson: split out encoder from meson_dw_hdmi
drm/bridge: synopsys: dw-hdmi: also allow interlace on bridge
drm/meson: encoder_hdmi: switch to bridge
DRM_BRIDGE_ATTACH_NO_CONNECTOR
drm/meson: rename venc_cvbs to encoder_cvbs
drm/meson: encoder_cvbs: switch to bridge with ATTACH_NO_CONNECTOR
drivers/gpu/drm/bridge/display-connector.c| 88
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 +
drivers/gpu/drm/meson/Kconfig | 2 +
drivers/gpu/drm/meson/Makefile| 3 +-
drivers/gpu/drm/meson/meson_drv.c | 71 ++-
drivers/gpu/drm/meson/meson_dw_hdmi.c | 342 +-
...meson_venc_cvbs.c => meson_encoder_cvbs.c} | 198
...meson_venc_cvbs.h => meson_encoder_cvbs.h} | 2 +-
drivers/gpu/drm/meson/meson_encoder_hdmi.c| 436 ++
drivers/gpu/drm/meson/meson_encoder_hdmi.h| 12 +
10 files changed, 679 insertions(+), 476 deletions(-)
rename drivers/gpu/drm/meson/{meson_venc_cvbs.c => meson_encoder_cvbs.c} (51%)
rename drivers/gpu/drm/meson/{meson_venc_cvbs.h => meson_encoder_cvbs.h} (92%)
create mode 100644 drivers/gpu/drm/meson/meson_encoder_hdmi.c
create mode 100644 drivers/gpu/drm/meson/meson_encoder_hdmi.h
base-commit: e4e737bb5c170df6135a127739a9e6148ee3da82
--
2.25.1
[PATCH 1/7] drm/bridge: display-connector: implement bus fmts callbacks
Since this bridge is tied to the connector, it acts like a passthrough,
so concerning the output & input bus formats, either pass the bus formats from
the
previous bridge or return fallback data like done in the bridge function:
drm_atomic_bridge_chain_select_bus_fmts() & select_bus_fmt_recursive.
This permits avoiding skipping the negociation if the remaining bridge chain has
all the bits in place.
Without this bus fmt negociation breaks on drm/meson HDMI pipeline when
attaching
dw-hdmi with DRM_BRIDGE_ATTACH_NO_CONNECTOR, because the last bridge of the
display-connector doesn't implement buf fmt callbacks and MEDIA_BUS_FMT_FIXED
is used leading to select an unsupported default bus format from dw-hdmi.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge/display-connector.c | 88 ++
1 file changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index 05eb759da6fc..9697ac173157 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
struct display_connector {
@@ -87,10 +88,97 @@ static struct edid *display_connector_get_edid(struct
drm_bridge *bridge,
return drm_get_edid(connector, conn->bridge.ddc);
}
+/*
+ * Since this bridge is tied to the connector, it acts like a passthrough,
+ * so concerning the output bus formats, either pass the bus formats from the
+ * previous bridge or return fallback data like done in the bridge function:
+ * drm_atomic_bridge_chain_select_bus_fmts().
+ * This permits avoiding skipping the negociation if the bridge chain has all
+ * bits in place.
+ */
+static u32 *display_connector_get_output_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ unsigned int *num_output_fmts)
+{
+ struct drm_bridge *prev_bridge = drm_bridge_get_prev_bridge(bridge);
+ struct drm_bridge_state *prev_bridge_state;
+
+ if (!prev_bridge || !prev_bridge->funcs->atomic_get_output_bus_fmts) {
+ struct drm_connector *conn = conn_state->connector;
+ u32 *out_bus_fmts;
+
+ *num_output_fmts = 1;
+ out_bus_fmts = kmalloc(sizeof(*out_bus_fmts), GFP_KERNEL);
+ if (!out_bus_fmts)
+ return NULL;
+
+ if (conn->display_info.num_bus_formats &&
+ conn->display_info.bus_formats)
+ out_bus_fmts[0] = conn->display_info.bus_formats[0];
+ else
+ out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
+
+ return out_bus_fmts;
+ }
+
+ prev_bridge_state = drm_atomic_get_new_bridge_state(crtc_state->state,
+ prev_bridge);
+
+ return prev_bridge->funcs->atomic_get_output_bus_fmts(prev_bridge,
prev_bridge_state,
+ crtc_state,
conn_state,
+ num_output_fmts);
+}
+
+/*
+ * Since this bridge is tied to the connector, it acts like a passthrough,
+ * so concerning the input bus formats, either pass the bus formats from the
+ * previous bridge or return fallback data like done in the bridge function:
+ * select_bus_fmt_recursive() when atomic_get_input_bus_fmts is not supported.
+ * This permits avoiding skipping the negociation if the bridge chain has all
+ * bits in place.
+ */
+static u32 *display_connector_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ struct drm_bridge *prev_bridge = drm_bridge_get_prev_bridge(bridge);
+ struct drm_bridge_state *prev_bridge_state;
+
+ if (!prev_bridge || !prev_bridge->funcs->atomic_get_input_bus_fmts) {
+ u32 *in_bus_fmts;
+
+ *num_input_fmts = 1;
+ in_bus_fmts = kmalloc(sizeof(*in_bus_fmts), GFP_KERNEL);
+ if (!in_bus_fmts)
+ return NULL;
+
+ in_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
+
+ return in_bus_fmts;
+ }
+
+ prev_bridge_state = drm_atomic_get_new_bridge_state(crtc_state->state,
+ prev_bridge);
+
+ return prev_bridge->funcs->atomic_get_input_bus_fmts(prev_bridge,
prev_br
[PATCH 4/7] drm/bridge: synopsys: dw-hdmi: also allow interlace on bridge
Since we allow interlace on the encoder, also allow it on the bridge so we can allow interlaced modes when using DRM_BRIDGE_ATTACH_NO_CONNECTOR. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index f08d0fded61f..62ae63565d3a 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -3413,6 +3413,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev, hdmi->bridge.funcs = &dw_hdmi_bridge_funcs; hdmi->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_HPD; + hdmi->bridge.interlace_allowed = true; #ifdef CONFIG_OF hdmi->bridge.of_node = pdev->dev.of_node; #endif -- 2.25.1
[PATCH 2/7] drm/meson: remove useless recursive components matching
The initial design was recursive to cover all port/endpoints, but only the
first layer
of endpoints should be covered by the components list.
This also breaks the MIPI-DSI init/bridge attach sequence, thus only parse the
first endpoints instead of recursing.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.c | 62 +++
1 file changed, 21 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index bc0d60df04ae..b53606d8825f 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -427,46 +427,6 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
}
-/* Possible connectors nodes to ignore */
-static const struct of_device_id connectors_match[] = {
- { .compatible = "composite-video-connector" },
- { .compatible = "svideo-connector" },
- { .compatible = "hdmi-connector" },
- { .compatible = "dvi-connector" },
- {}
-};
-
-static int meson_probe_remote(struct platform_device *pdev,
- struct component_match **match,
- struct device_node *parent,
- struct device_node *remote)
-{
- struct device_node *ep, *remote_node;
- int count = 1;
-
- /* If node is a connector, return and do not add to match table */
- if (of_match_node(connectors_match, remote))
- return 1;
-
- component_match_add(&pdev->dev, match, compare_of, remote);
-
- for_each_endpoint_of_node(remote, ep) {
- remote_node = of_graph_get_remote_port_parent(ep);
- if (!remote_node ||
- remote_node == parent || /* Ignore parent endpoint */
- !of_device_is_available(remote_node)) {
- of_node_put(remote_node);
- continue;
- }
-
- count += meson_probe_remote(pdev, match, remote, remote_node);
-
- of_node_put(remote_node);
- }
-
- return count;
-}
-
static void meson_drv_shutdown(struct platform_device *pdev)
{
struct meson_drm *priv = dev_get_drvdata(&pdev->dev);
@@ -478,6 +438,13 @@ static void meson_drv_shutdown(struct platform_device
*pdev)
drm_atomic_helper_shutdown(priv->drm);
}
+/* Possible connectors nodes to ignore */
+static const struct of_device_id connectors_match[] = {
+ { .compatible = "composite-video-connector" },
+ { .compatible = "svideo-connector" },
+ {}
+};
+
static int meson_drv_probe(struct platform_device *pdev)
{
struct component_match *match = NULL;
@@ -492,8 +459,21 @@ static int meson_drv_probe(struct platform_device *pdev)
continue;
}
- count += meson_probe_remote(pdev, &match, np, remote);
+ /* If an analog connector is detected, count it as an output */
+ if (of_match_node(connectors_match, remote)) {
+ ++count;
+ of_node_put(remote);
+ continue;
+ }
+
+ DRM_DEBUG_DRIVER("parent %pOF remote match add %pOF parent
%s\n",
+ np, remote, dev_name(&pdev->dev));
+
+ component_match_add(&pdev->dev, &match, compare_of, remote);
+
of_node_put(remote);
+
+ ++count;
}
if (count && !match)
--
2.25.1
[PATCH 6/7] drm/meson: rename venc_cvbs to encoder_cvbs
Rename the cvbs encoder to match the newly introduced meson_encoder_hdmi.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/Makefile| 2 +-
drivers/gpu/drm/meson/meson_drv.c | 4 +-
...meson_venc_cvbs.c => meson_encoder_cvbs.c} | 78 +--
...meson_venc_cvbs.h => meson_encoder_cvbs.h} | 2 +-
4 files changed, 43 insertions(+), 43 deletions(-)
rename drivers/gpu/drm/meson/{meson_venc_cvbs.c => meson_encoder_cvbs.c} (74%)
rename drivers/gpu/drm/meson/{meson_venc_cvbs.h => meson_encoder_cvbs.h} (92%)
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index 523fce45f16b..3afa31bdc950 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
-meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o
+meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_encoder_cvbs.o
meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o
meson_overlay.o
meson-drm-y += meson_rdma.o meson_osd_afbcd.o
meson-drm-y += meson_encoder_hdmi.o
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 0a28a8e29d63..d07d302ce4a6 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -31,7 +31,7 @@
#include "meson_plane.h"
#include "meson_osd_afbcd.h"
#include "meson_registers.h"
-#include "meson_venc_cvbs.h"
+#include "meson_encoder_cvbs.h"
#include "meson_encoder_hdmi.h"
#include "meson_viu.h"
#include "meson_vpp.h"
@@ -308,7 +308,7 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
/* Encoder Initialization */
- ret = meson_venc_cvbs_create(priv);
+ ret = meson_encoder_cvbs_init(priv);
if (ret)
goto free_drm;
diff --git a/drivers/gpu/drm/meson/meson_venc_cvbs.c
b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
similarity index 74%
rename from drivers/gpu/drm/meson/meson_venc_cvbs.c
rename to drivers/gpu/drm/meson/meson_encoder_cvbs.c
index f1747fde1fe0..01024c5f610c 100644
--- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
@@ -20,7 +20,7 @@
#include "meson_registers.h"
#include "meson_vclk.h"
-#include "meson_venc_cvbs.h"
+#include "meson_encoder_cvbs.h"
/* HHI VDAC Registers */
#define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
@@ -28,16 +28,16 @@
#define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
#define HHI_VDAC_CNTL1_G12A0x2F0 /* 0xbe offset in data sheet */
-struct meson_venc_cvbs {
+struct meson_encoder_cvbs {
struct drm_encoder encoder;
struct drm_connectorconnector;
struct meson_drm*priv;
};
-#define encoder_to_meson_venc_cvbs(x) \
- container_of(x, struct meson_venc_cvbs, encoder)
+#define encoder_to_meson_encoder_cvbs(x) \
+ container_of(x, struct meson_encoder_cvbs, encoder)
-#define connector_to_meson_venc_cvbs(x) \
- container_of(x, struct meson_venc_cvbs, connector)
+#define connector_to_meson_encoder_cvbs(x) \
+ container_of(x, struct meson_encoder_cvbs, connector)
/* Supported Modes */
@@ -140,16 +140,16 @@ struct drm_connector_helper_funcs
meson_cvbs_connector_helper_funcs = {
/* Encoder */
-static void meson_venc_cvbs_encoder_destroy(struct drm_encoder *encoder)
+static void meson_encoder_cvbs_encoder_destroy(struct drm_encoder *encoder)
{
drm_encoder_cleanup(encoder);
}
-static const struct drm_encoder_funcs meson_venc_cvbs_encoder_funcs = {
- .destroy= meson_venc_cvbs_encoder_destroy,
+static const struct drm_encoder_funcs meson_encoder_cvbs_encoder_funcs = {
+ .destroy= meson_encoder_cvbs_encoder_destroy,
};
-static int meson_venc_cvbs_encoder_atomic_check(struct drm_encoder *encoder,
+static int meson_encoder_cvbs_encoder_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
@@ -159,11 +159,11 @@ static int meson_venc_cvbs_encoder_atomic_check(struct
drm_encoder *encoder,
return -EINVAL;
}
-static void meson_venc_cvbs_encoder_disable(struct drm_encoder *encoder)
+static void meson_encoder_cvbs_encoder_disable(struct drm_encoder *encoder)
{
- struct meson_venc_cvbs *meson_venc_cvbs =
- encoder_to_meson_venc_cvbs(encoder);
- struct meson_drm *priv = meson_venc_cvbs->priv;
+ struct meson_encoder_cvbs *meson_encoder_cvbs =
+ encoder_to_meson_encoder_cvbs(encoder);
+ struct meson_drm *priv = meson_encoder_cvbs->priv;
/* Disable CVBS VDAC */
if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) {
@@ -175,11 +175,11 @@ static void meson_venc_cvbs_encoder_disable(struct
drm_encoder *encoder)
[PATCH 7/7] drm/meson: encoder_cvbs: switch to bridge with ATTACH_NO_CONNECTOR
Drop the local connector and move all callback to bridge funcs in order
to leverage the generic CVBS diplay connector.
This will also permit adding custom cvbs connectors for ADC based HPD
detection on some Amlogic SoC based boards.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_encoder_cvbs.c | 178 +
1 file changed, 79 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
index 01024c5f610c..0b974667cf55 100644
--- a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
@@ -13,6 +13,9 @@
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -30,14 +33,14 @@
struct meson_encoder_cvbs {
struct drm_encoder encoder;
- struct drm_connectorconnector;
+ struct drm_bridge bridge;
+ struct drm_bridge *next_bridge;
+ struct drm_connector*connector;
struct meson_drm*priv;
};
-#define encoder_to_meson_encoder_cvbs(x) \
- container_of(x, struct meson_encoder_cvbs, encoder)
-#define connector_to_meson_encoder_cvbs(x) \
- container_of(x, struct meson_encoder_cvbs, connector)
+#define bridge_to_meson_encoder_cvbs(x) \
+ container_of(x, struct meson_encoder_cvbs, bridge)
/* Supported Modes */
@@ -81,21 +84,18 @@ meson_cvbs_get_mode(const struct drm_display_mode *req_mode)
return NULL;
}
-/* Connector */
-
-static void meson_cvbs_connector_destroy(struct drm_connector *connector)
+static int meson_encoder_cvbs_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
{
- drm_connector_cleanup(connector);
-}
+ struct meson_encoder_cvbs *meson_encoder_cvbs =
+ bridge_to_meson_encoder_cvbs(bridge);
-static enum drm_connector_status
-meson_cvbs_connector_detect(struct drm_connector *connector, bool force)
-{
- /* FIXME: Add load-detect or jack-detect if possible */
- return connector_status_connected;
+ return drm_bridge_attach(bridge->encoder,
meson_encoder_cvbs->next_bridge,
+&meson_encoder_cvbs->bridge, flags);
}
-static int meson_cvbs_connector_get_modes(struct drm_connector *connector)
+static int meson_encoder_cvbs_get_modes(struct drm_bridge *bridge,
+ struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode;
@@ -116,40 +116,18 @@ static int meson_cvbs_connector_get_modes(struct
drm_connector *connector)
return i;
}
-static int meson_cvbs_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static int meson_encoder_cvbs_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_info
*display_info,
+ const struct drm_display_mode *mode)
{
- /* Validate the modes added in get_modes */
- return MODE_OK;
-}
-
-static const struct drm_connector_funcs meson_cvbs_connector_funcs = {
- .detect = meson_cvbs_connector_detect,
- .fill_modes = drm_helper_probe_single_connector_modes,
- .destroy= meson_cvbs_connector_destroy,
- .reset = drm_atomic_helper_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static const
-struct drm_connector_helper_funcs meson_cvbs_connector_helper_funcs = {
- .get_modes = meson_cvbs_connector_get_modes,
- .mode_valid = meson_cvbs_connector_mode_valid,
-};
+ if (meson_cvbs_get_mode(mode))
+ return MODE_OK;
-/* Encoder */
-
-static void meson_encoder_cvbs_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
+ return MODE_BAD;
}
-static const struct drm_encoder_funcs meson_encoder_cvbs_encoder_funcs = {
- .destroy= meson_encoder_cvbs_encoder_destroy,
-};
-
-static int meson_encoder_cvbs_encoder_atomic_check(struct drm_encoder *encoder,
+static int meson_encoder_cvbs_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
@@ -159,10 +137,10 @@ static int meson_encoder_cvbs_encoder_atomic_check(struct
drm_encoder *encoder,
return -EINVAL;
}
-static void meson_encoder_cvbs_encoder_disable(struct drm_encoder *encoder)
+static void meson_encoder_cvbs_disable(struct drm_bridge *bridge)
{
struct meson_encoder_cvbs *meson_encode
[PATCH 3/7] drm/meson: split out encoder from meson_dw_hdmi
This moves all the non-DW-HDMI code where it should be:
an encoder in the drm/meson core driver.
The bridge functions are copied as-is, the encoder init uses the
simple kms helper and for now the bridge attach flags is 0.
The meson dw-hdmi glue is slighly fixed to live without the
encoder in the same driver.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/Makefile | 1 +
drivers/gpu/drm/meson/meson_drv.c | 5 +
drivers/gpu/drm/meson/meson_dw_hdmi.c | 341 ++-
drivers/gpu/drm/meson/meson_encoder_hdmi.c | 359 +
drivers/gpu/drm/meson/meson_encoder_hdmi.h | 12 +
5 files changed, 396 insertions(+), 322 deletions(-)
create mode 100644 drivers/gpu/drm/meson/meson_encoder_hdmi.c
create mode 100644 drivers/gpu/drm/meson/meson_encoder_hdmi.h
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index 28a519cdf66b..523fce45f16b 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -2,6 +2,7 @@
meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o
meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o
meson_overlay.o
meson-drm-y += meson_rdma.o meson_osd_afbcd.o
+meson-drm-y += meson_encoder_hdmi.o
obj-$(CONFIG_DRM_MESON) += meson-drm.o
obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index b53606d8825f..0a28a8e29d63 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -32,6 +32,7 @@
#include "meson_osd_afbcd.h"
#include "meson_registers.h"
#include "meson_venc_cvbs.h"
+#include "meson_encoder_hdmi.h"
#include "meson_viu.h"
#include "meson_vpp.h"
#include "meson_rdma.h"
@@ -319,6 +320,10 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
}
}
+ ret = meson_encoder_hdmi_init(priv);
+ if (ret)
+ goto free_drm;
+
ret = meson_plane_create(priv);
if (ret)
goto free_drm;
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 2ed87cfdd735..c2480b3335ac 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -22,14 +22,11 @@
#include
#include
-#include
#include
#include "meson_drv.h"
#include "meson_dw_hdmi.h"
#include "meson_registers.h"
-#include "meson_vclk.h"
-#include "meson_venc.h"
#define DRIVER_NAME "meson-dw-hdmi"
#define DRIVER_DESC "Amlogic Meson HDMI-TX DRM driver"
@@ -135,8 +132,6 @@ struct meson_dw_hdmi_data {
};
struct meson_dw_hdmi {
- struct drm_encoder encoder;
- struct drm_bridge bridge;
struct dw_hdmi_plat_data dw_plat_data;
struct meson_drm *priv;
struct device *dev;
@@ -148,12 +143,8 @@ struct meson_dw_hdmi {
struct regulator *hdmi_supply;
u32 irq_stat;
struct dw_hdmi *hdmi;
- unsigned long output_bus_fmt;
+ struct drm_bridge *bridge;
};
-#define encoder_to_meson_dw_hdmi(x) \
- container_of(x, struct meson_dw_hdmi, encoder)
-#define bridge_to_meson_dw_hdmi(x) \
- container_of(x, struct meson_dw_hdmi, bridge)
static inline int dw_hdmi_is_compatible(struct meson_dw_hdmi *dw_hdmi,
const char *compat)
@@ -295,14 +286,14 @@ static inline void dw_hdmi_dwc_write_bits(struct
meson_dw_hdmi *dw_hdmi,
/* Setup PHY bandwidth modes */
static void meson_hdmi_phy_setup_mode(struct meson_dw_hdmi *dw_hdmi,
- const struct drm_display_mode *mode)
+ const struct drm_display_mode *mode,
+ bool mode_is_420)
{
struct meson_drm *priv = dw_hdmi->priv;
unsigned int pixel_clock = mode->clock;
/* For 420, pixel clock is half unlike venc clock */
- if (dw_hdmi->output_bus_fmt == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
- pixel_clock /= 2;
+ if (mode_is_420) pixel_clock /= 2;
if (dw_hdmi_is_compatible(dw_hdmi, "amlogic,meson-gxl-dw-hdmi") ||
dw_hdmi_is_compatible(dw_hdmi, "amlogic,meson-gxm-dw-hdmi")) {
@@ -374,68 +365,25 @@ static inline void meson_dw_hdmi_phy_reset(struct
meson_dw_hdmi *dw_hdmi)
mdelay(2);
}
-static void dw_hdmi_set_vclk(struct meson_dw_hdmi *dw_hdmi,
-const struct drm_display_mode *mode)
-{
- struct meson_drm *priv = dw_hdmi->priv;
- int vic = drm_match_cea_mode(mode);
- unsigned int phy_freq;
- unsigned int vclk_freq;
- unsigned int venc_freq;
- unsigned int hdmi_freq;
-
- vclk_freq = mode->clock;
-
- /* For 420, pixel clock is half unlike venc clock */
- if (dw_hdmi->output_bus_fmt == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
- vclk_freq /= 2;
-
- /* TMDS clock is pixel_clock * 10 */
- phy_freq =
[PATCH 5/7] drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR
This implements the necessary change to no more use the embedded
connector in dw-hdmi and use the dedicated bridge connector driver
by passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to the bridge attach call.
The necessary connector properties are added to handle the same
functionalities as the embedded dw-hdmi connector, i.e. the HDR
metadata, the CEC notifier & other flags.
The dw-hdmi output_port is set to 1 in order to look for a connector
next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR working.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/Kconfig | 2 +
drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
drivers/gpu/drm/meson/meson_encoder_hdmi.c | 81 +-
3 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig
index 9f9281dd49f8..a4e1ed96e5e8 100644
--- a/drivers/gpu/drm/meson/Kconfig
+++ b/drivers/gpu/drm/meson/Kconfig
@@ -6,9 +6,11 @@ config DRM_MESON
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
+ select DRM_DISPLAY_CONNECTOR
select VIDEOMODE_HELPERS
select REGMAP_MMIO
select MESON_CANVAS
+ select CEC_CORE if CEC_NOTIFIER
config DRM_MESON_DW_HDMI
tristate "HDMI Synopsys Controller support for Amlogic Meson Display"
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index c2480b3335ac..933ff63b1ecf 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -805,6 +805,7 @@ static int meson_dw_hdmi_bind(struct device *dev, struct
device *master,
dw_plat_data->input_bus_encoding = V4L2_YCBCR_ENC_709;
dw_plat_data->ycbcr_420_allowed = true;
dw_plat_data->disable_cec = true;
+ dw_plat_data->output_port = 1;
if (dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxl-dw-hdmi") ||
dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxm-dw-hdmi") ||
diff --git a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
index c775a1ab5b1e..a4264587d89a 100644
--- a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
@@ -14,9 +14,12 @@
#include
#include
+#include
+
#include
#include
#include
+#include
#include
#include
#include
@@ -34,8 +37,10 @@ struct meson_encoder_hdmi {
struct drm_encoder encoder;
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
+ struct drm_connector *connector;
struct meson_drm *priv;
unsigned long output_bus_fmt;
+ struct cec_notifier *cec_notifier;
};
#define bridge_to_meson_encoder_hdmi(x) \
@@ -50,6 +55,14 @@ static int meson_encoder_hdmi_attach(struct drm_bridge
*bridge,
&encoder_hdmi->bridge, flags);
}
+static void meson_encoder_hdmi_detach(struct drm_bridge *bridge)
+{
+ struct meson_encoder_hdmi *encoder_hdmi =
bridge_to_meson_encoder_hdmi(bridge);
+
+ cec_notifier_conn_unregister(encoder_hdmi->cec_notifier);
+ encoder_hdmi->cec_notifier = NULL;
+}
+
static void meson_encoder_hdmi_enable(struct drm_bridge *bridge)
{
struct meson_encoder_hdmi *encoder_hdmi =
bridge_to_meson_encoder_hdmi(bridge);
@@ -284,12 +297,33 @@ static int meson_encoder_hdmi_atomic_check(struct
drm_bridge *bridge,
return 0;
}
+static void meson_encoder_hdmi_hpd_notify(struct drm_bridge *bridge,
+ enum drm_connector_status status)
+{
+ struct meson_encoder_hdmi *encoder_hdmi =
bridge_to_meson_encoder_hdmi(bridge);
+ struct edid *edid;
+
+ if (!encoder_hdmi->cec_notifier)
+ return;
+
+ if (status == connector_status_connected) {
+ edid = drm_bridge_get_edid(encoder_hdmi->next_bridge,
encoder_hdmi->connector);
+ if (!edid)
+ return;
+
+
cec_notifier_set_phys_addr_from_edid(encoder_hdmi->cec_notifier, edid);
+ } else
+ cec_notifier_phys_addr_invalidate(encoder_hdmi->cec_notifier);
+}
+
static const struct drm_bridge_funcs meson_encoder_hdmi_bridge_funcs = {
.attach = meson_encoder_hdmi_attach,
+ .detach = meson_encoder_hdmi_detach,
.enable = meson_encoder_hdmi_enable,
.disable = meson_encoder_hdmi_disable,
.mode_valid = meson_encoder_hdmi_mode_valid,
.mode_set = meson_encoder_hdmi_mode_set,
+ .hpd_notify = meson_encoder_hdmi_hpd_notify,
.atomic_get_input_bus_fmts = meson_encoder_hdmi_get_inp_bus_fmts,
.atomic_check = meson_encoder_hdmi_atomic_check,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
@@ -300,6 +334,7 @@ static const struct drm_bridge_funcs
meson_encoder_hdmi_bridge_funcs = {
int meson_encoder_hdmi_init(struct meson_drm *priv)
{
struct meson_encoder_hdmi
Re: [PATCH 16/25] drm/i915/guc: Connect UAPI to GuC multi-lrc interface
On Wed, Oct 13, 2021 at 06:02:42PM -0700, John Harrison wrote:
> On 10/13/2021 13:42, Matthew Brost wrote:
> > Introduce 'set parallel submit' extension to connect UAPI to GuC
> > multi-lrc interface. Kernel doc in new uAPI should explain it all.
> >
> > IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071&rev=1
> > media UMD: https://github.com/intel/media-driver/pull/1252
> >
> > v2:
> > (Daniel Vetter)
> >- Add IGT link and placeholder for media UMD link
> > v3:
> > (Kernel test robot)
> >- Fix warning in unpin engines call
> > (John Harrison)
> >- Reword a bunch of the kernel doc
> > v4:
> > (John Harrison)
> >- Add comment why perma-pin is done after setting gem context
> >- Update some comments / docs for proto contexts
> >
> > Cc: Tvrtko Ursulin
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 228 +-
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 16 +-
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +-
> > drivers/gpu/drm/i915/gt/intel_engine.h| 12 +-
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +-
> > .../drm/i915/gt/intel_execlists_submission.c | 6 +-
> > drivers/gpu/drm/i915/gt/selftest_execlists.c | 12 +-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 114 -
> > include/uapi/drm/i915_drm.h | 131 ++
> > 9 files changed, 503 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index d225d3dd0b40..6f23aff6e642 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -556,9 +556,150 @@ set_proto_ctx_engines_bond(struct i915_user_extension
> > __user *base, void *data)
> > return 0;
> > }
> > +static int
> > +set_proto_ctx_engines_parallel_submit(struct i915_user_extension __user
> > *base,
> > + void *data)
> > +{
> > + struct i915_context_engines_parallel_submit __user *ext =
> > + container_of_user(base, typeof(*ext), base);
> > + const struct set_proto_ctx_engines *set = data;
> > + struct drm_i915_private *i915 = set->i915;
> > + u64 flags;
> > + int err = 0, n, i, j;
> > + u16 slot, width, num_siblings;
> > + struct intel_engine_cs **siblings = NULL;
> > + intel_engine_mask_t prev_mask;
> > +
> > + /* Disabling for now */
> > + return -ENODEV;
> > +
> > + /* FIXME: This is NIY for execlists */
> > + if (!(intel_uc_uses_guc_submission(&i915->gt.uc)))
> > + return -ENODEV;
> > +
> > + if (get_user(slot, &ext->engine_index))
> > + return -EFAULT;
> > +
> > + if (get_user(width, &ext->width))
> > + return -EFAULT;
> > +
> > + if (get_user(num_siblings, &ext->num_siblings))
> > + return -EFAULT;
> > +
> > + if (slot >= set->num_engines) {
> > + drm_dbg(&i915->drm, "Invalid placement value, %d >= %d\n",
> > + slot, set->num_engines);
> > + return -EINVAL;
> > + }
> > +
> > + if (set->engines[slot].type != I915_GEM_ENGINE_TYPE_INVALID) {
> > + drm_dbg(&i915->drm,
> > + "Invalid placement[%d], already occupied\n", slot);
> > + return -EINVAL;
> > + }
> > +
> > + if (get_user(flags, &ext->flags))
> > + return -EFAULT;
> > +
> > + if (flags) {
> > + drm_dbg(&i915->drm, "Unknown flags 0x%02llx", flags);
> > + return -EINVAL;
> > + }
> > +
> > + for (n = 0; n < ARRAY_SIZE(ext->mbz64); n++) {
> > + err = check_user_mbz(&ext->mbz64[n]);
> > + if (err)
> > + return err;
> > + }
> > +
> > + if (width < 2) {
> > + drm_dbg(&i915->drm, "Width (%d) < 2\n", width);
> > + return -EINVAL;
> > + }
> > +
> > + if (num_siblings < 1) {
> > + drm_dbg(&i915->drm, "Number siblings (%d) < 1\n",
> > + num_siblings);
> > + return -EINVAL;
> > + }
> > +
> > + siblings = kmalloc_array(num_siblings * width,
> > +sizeof(*siblings),
> > +GFP_KERNEL);
> > + if (!siblings)
> > + return -ENOMEM;
> > +
> > + /* Create contexts / engines */
> > + for (i = 0; i < width; ++i) {
> > + intel_engine_mask_t current_mask = 0;
> > + struct i915_engine_class_instance prev_engine;
> > +
> > + for (j = 0; j < num_siblings; ++j) {
> > + struct i915_engine_class_instance ci;
> > +
> > + n = i * num_siblings + j;
> > + if (copy_from_user(&ci, &ext->engines[n], sizeof(ci))) {
> > + err = -EFAULT;
> > + goto out_err;
> > + }
> > +
> > + siblings[n] =
> > + intel_engine_lookup_user(i91
Re: [PATCH 20/25] drm/i915: Multi-BB execbuf
On Wed, Oct 13, 2021 at 05:55:51PM -0700, John Harrison wrote:
> On 10/13/2021 13:42, Matthew Brost wrote:
> > Allow multiple batch buffers to be submitted in a single execbuf IOCTL
> > after a context has been configured with the 'set_parallel' extension.
> > The number batches is implicit based on the contexts configuration.
> >
> > This is implemented with a series of loops. First a loop is used to find
> > all the batches, a loop to pin all the HW contexts, a loop to create all
> > the requests, a loop to submit (emit BB start, etc...) all the requests,
> > a loop to tie the requests to the VMAs they touch, and finally a loop to
> > commit the requests to the backend.
> >
> > A composite fence is also created for the generated requests to return
> > to the user and to stick in dma resv slots.
> >
> > No behavior from the existing IOCTL should be changed aside from when
> > throttling because the ring for a context is full. In this situation,
> > i915 will now wait while holding the object locks. This change was done
> > because the code is much simpler to wait while holding the locks and we
> > believe there isn't a huge benefit of dropping these locks. If this
> > proves false we can restructure the code to drop the locks during the
> > wait.
> >
> > IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071&rev=1
> > media UMD: https://github.com/intel/media-driver/pull/1252
> >
> > v2:
> > (Matthew Brost)
> >- Return proper error value if i915_request_create fails
> > v3:
> > (John Harrison)
> >- Add comment explaining create / add order loops + locking
> >- Update commit message explaining different in IOCTL behavior
> >- Line wrap some comments
> >- eb_add_request returns void
> >- Return -EINVAL rather triggering BUG_ON if cmd parser used
> > (Checkpatch)
> >- Check eb->batch_len[*current_batch]
> > v4:
> > (CI)
> >- Set batch len if passed if via execbuf args
> >- Call __i915_request_skip after __i915_request_commit
> > (Kernel test robot)
> >- Initialize rq to NULL in eb_pin_timeline
> >
> > Signed-off-by: Matthew Brost
> > ---
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 783 --
> > drivers/gpu/drm/i915/gt/intel_context.h | 8 +-
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 10 +
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +
> > drivers/gpu/drm/i915/i915_request.h | 9 +
> > drivers/gpu/drm/i915/i915_vma.c | 21 +-
> > drivers/gpu/drm/i915/i915_vma.h | 13 +-
> > 7 files changed, 595 insertions(+), 251 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index c75afc8784e3..6509c9d8c298 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -246,17 +246,25 @@ struct i915_execbuffer {
> > struct drm_i915_gem_exec_object2 *exec; /** ioctl execobj[] */
> > struct eb_vma *vma;
> > - struct intel_engine_cs *engine; /** engine to queue the request to */
> > + struct intel_gt *gt; /* gt for the execbuf */
> > struct intel_context *context; /* logical state for the request */
> > struct i915_gem_context *gem_context; /** caller's context */
> > - struct i915_request *request; /** our request to build */
> > - struct eb_vma *batch; /** identity of the batch obj/vma */
> > + /** our requests to build */
> > + struct i915_request *requests[MAX_ENGINE_INSTANCE + 1];
> > + /** identity of the batch obj/vma */
> > + struct eb_vma *batches[MAX_ENGINE_INSTANCE + 1];
> > struct i915_vma *trampoline; /** trampoline used for chaining */
> > + /** used for excl fence in dma_resv objects when > 1 BB submitted */
> > + struct dma_fence *composite_fence;
> > +
> > /** actual size of execobj[] as we may extend it for the cmdparser */
> > unsigned int buffer_count;
> > + /* number of batches in execbuf IOCTL */
> > + unsigned int num_batches;
> > +
> > /** list of vma not yet bound during reservation phase */
> > struct list_head unbound;
> > @@ -283,7 +291,8 @@ struct i915_execbuffer {
> > u64 invalid_flags; /** Set of execobj.flags that are invalid */
> > - u64 batch_len; /** Length of batch within object */
> > + /** Length of batch within object */
> > + u64 batch_len[MAX_ENGINE_INSTANCE + 1];
> > u32 batch_start_offset; /** Location within object of batch */
> > u32 batch_flags; /** Flags composed for emit_bb_start() */
> > struct intel_gt_buffer_pool_node *batch_pool; /** pool node for batch
> > buffer */
> > @@ -301,14 +310,13 @@ struct i915_execbuffer {
> > };
> > static int eb_parse(struct i915_execbuffer *eb);
> > -static struct i915_request *eb_pin_engine(struct i915_execbuffer *eb,
> > - bool throttle);
> > +static int eb_pin_engine(struct i915_execbuffer *eb, bool
