Re: [PATCH v2 1/5] string.h: add array-wrappers for (v)memdup_user()
On Sat, Sep 16, 2023 at 05:32:42PM +0300, Dan Carpenter wrote:
> On Fri, Sep 08, 2023 at 09:59:40PM +0200, Philipp Stanner wrote:
...
> > +static inline void *memdup_array_user(const void __user *src, size_t n,
> > size_t size)
> > +{
> > + size_t nbytes;
> > +
> > + if (unlikely(check_mul_overflow(n, size, )))
> > + return ERR_PTR(-EOVERFLOW);
>
> No need for an unlikely() because check_mul_overflow() already has one
> inside.
Makes sense.
> I feel like -ENOMEM is more traditional but I doubt anyone/userspace
> cares.
ENOMEM is good for the real allocation calls, here is not the one (the one is
below). Hence ENOMEM is not good candidate above. And whenever functions returns
an error pointer the caller must not assume that it will be only ENOMEM for
allocators.
> > + return memdup_user(src, nbytes);
> > +}
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] drm: fix up fbdev Kconfig defaults
Thomas Zimmermann writes:
> Hi
>
> Am 11.09.23 um 22:52 schrieb Arnd Bergmann:
>> From: Arnd Bergmann
>>
>> As a result of the recent Kconfig reworks, the default settings for the
>> framebuffer interfaces changed in unexpected ways:
>>
>> Configurations that leave CONFIG_FB disabled but use DRM now get
>> DRM_FBDEV_EMULATION by default. This also turns on the deprecated /dev/fb
>> device nodes for machines that don't actually want it.
>>
>> In turn, configurations that previously had DRM_FBDEV_EMULATION enabled
>> now only get the /dev/fb front-end but not the more useful framebuffer
>> console, which is not selected any more.
>>
>> We had previously decided that any combination of the three frontends
>> (FB_DEVICE, FRAMEBUFFER_CONSOLE and LOGO) should be selectable, but the
>> new default settings mean that a lot of defconfig files would have to
>> get adapted.
>>
>> Change the defaults back to what they were in Linux 6.5:
>>
>> - Leave DRM_FBDEV_EMULATION turned off unless CONFIG_FB
>> is enabled. Previously this was a hard dependency but now the two are
>> independent. However, configurations that enable CONFIG_FB probably
>> also want to keep the emulation for DRM, while those without FB
>> presumably did that intentionally in the past.
>>
>> - Leave FB_DEVICE turned off for FB=n. Following the same
>> logic, the deprecated option should not automatically get enabled
>> here, most users that had FB turned off in the past do not want it,
>> even if they want the console
>>
>> - Turn the FRAMEBUFFER_CONSOLE option on if
>> DRM_FBDEV_EMULATION is set to avoid having to change defconfig
>> files that relied on it being selected unconditionally in the past.
>> This also makes sense since both LOGO and FB_DEVICE are now disabled
>> by default for builds without CONFIG_FB, but DRM_FBDEV_EMULATION
>> would make no sense if all three are disabled.
>>
>> Fixes: a5ae331edb02b ("drm: Drop select FRAMEBUFFER_CONSOLE for
>> DRM_FBDEV_EMULATION")
>> Fixes: 701d2054fa317 ("fbdev: Make support for userspace interfaces
>> configurable")
>> Reported-by: Geert Uytterhoeven
>> Signed-off-by: Arnd Bergmann
>
> Acked-by: Thomas Zimmermann
>
Pushed to drm-misc (drm-misc-fixes). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH for-next v2 02/10] PM: Update EXPORT_*_DEV_PM_OPS() to EXPORT_*_RUNTIME_PM_OPS()
On Mon, Sep 18, 2023 at 10:20:29AM +0200, Paul Cercueil wrote: > Le lundi 18 septembre 2023 à 13:39 +0530, Raag Jadav a écrit : > > Rename EXPORT_*_DEV_PM_OPS() macros to EXPORT_*_RUNTIME_PM_OPS() > > and while at it, move them to pm_runtime.h. > > This is done in conjunction with the introduction of > > EXPORT_*_SIMPLE_PM_OPS() set of macros, to make things less > > confusing. > > This makes both _RUNTIME_ and _SIMPLE_ variants of export macros more > > distinguishable and self explanatory. > > Well I don't really agree with this one. The EXPORT_*_DEV_PM_OPS() can > be used with any callback you need, not just the typical runtime-PM > callbacks. They are generic PM macros. I agree on the usage part. But with the introduction of export macros for _SIMPLE_ variants, current naming scheme would make things unnecessarily confusing to the users in my opinion. Perhaps we can have it simplified some other way? Raag
Re: [PATCH v2 06/11] drm/mediatek: Support alpha blending in display driver
Re: [PATCH v5 4/6] drm/drm_file: Add DRM obj's RSS reporting function for fdinfo
On 14/09/2023 23:38, Adrián Larumbe wrote:
> Some BO's might be mapped onto physical memory chunkwise and on demand,
> like Panfrost's tiler heap. In this case, even though the
> drm_gem_shmem_object page array might already be allocated, only a very
> small fraction of the BO is currently backed by system memory, but
> drm_show_memory_stats will then proceed to add its entire virtual size to
> the file's total resident size regardless.
>
> This led to very unrealistic RSS sizes being reckoned for Panfrost, where
> said tiler heap buffer is initially allocated with a virtual size of 128
> MiB, but only a small part of it will eventually be backed by system memory
> after successive GPU page faults.
>
> Provide a new DRM object generic function that would allow drivers to
> return a more accurate RSS size for their BOs.
>
> Signed-off-by: Adrián Larumbe
> Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/drm_file.c | 5 -
> include/drm/drm_gem.h | 9 +
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 883d83bc0e3d..762965e3d503 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -944,7 +944,10 @@ void drm_show_memory_stats(struct drm_printer *p, struct
> drm_file *file)
> }
>
> if (s & DRM_GEM_OBJECT_RESIDENT) {
> - status.resident += obj->size;
> + if (obj->funcs && obj->funcs->rss)
> + status.resident += obj->funcs->rss(obj);
> + else
> + status.resident += obj->size;
> } else {
> /* If already purged or not yet backed by pages, don't
>* count it as purgeable:
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index bc9f6aa2f3fe..16364487fde9 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -208,6 +208,15 @@ struct drm_gem_object_funcs {
>*/
> enum drm_gem_object_status (*status)(struct drm_gem_object *obj);
>
> + /**
> + * @rss:
> + *
> + * Return resident size of the object in physical memory.
> + *
> + * Called by drm_show_memory_stats().
> + */
> + size_t (*rss)(struct drm_gem_object *obj);
> +
> /**
>* @vm_ops:
>*
Re: [PATCH v5 5/6] drm/panfrost: Implement generic DRM object RSS reporting function
On Mon, 18 Sep 2023 11:01:43 +0100
Steven Price wrote:
> On 14/09/2023 23:38, Adrián Larumbe wrote:
> > BO's RSS is updated every time new pages are allocated on demand and mapped
> > for the object at GPU page fault's IRQ handler, but only for heap buffers.
> > The reason this is unnecessary for non-heap buffers is that they are mapped
> > onto the GPU's VA space and backed by physical memory in their entirety at
> > BO creation time.
> >
> > This calculation is unnecessary for imported PRIME objects, since heap
> > buffers cannot be exported by our driver, and the actual BO RSS size is the
> > one reported in its attached dmabuf structure.
> >
> > Signed-off-by: Adrián Larumbe
> > Reviewed-by: Boris Brezillon
>
> Am I missing something, or are we missing a way of resetting
> heap_rss_size when the shrinker purges? It looks like after several
> grow/purge cycles, heap_rss_size could actually grow to be larger than
> the BO which is clearly wrong.
Didn't even consider this case since we don't flag heap BOs purgeable
in mesa(panfrost), but let's assume we did. If the BO is purged, I'd
expect the core to report 0MB of resident memory anyway. And purged BOs
are not supposed to be re-used if MADVISE(WILL_NEED) returns
retained=false, they should be destroyed. Not 100% sure this is
enforced everywhere though (we might actually miss tests to make sure
users don't pass purged BOs to jobs, or make the alloc-on-fault logic
doesn't try to grow a purged GEM).
If we want to implement transparent BO swap{out,in} (Dmitry's
patchset), that's be a different story, and we'll indeed have to set
heap_rss_size back to zero on eviction.
>
> Steve
>
> > ---
> > drivers/gpu/drm/panfrost/panfrost_gem.c | 15 +++
> > drivers/gpu/drm/panfrost/panfrost_gem.h | 5 +
> > drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 +
> > 3 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
> > b/drivers/gpu/drm/panfrost/panfrost_gem.c
> > index 7d8f83d20539..4365434b48db 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> > @@ -208,6 +208,20 @@ static enum drm_gem_object_status
> > panfrost_gem_status(struct drm_gem_object *obj
> > return res;
> > }
> >
> > +static size_t panfrost_gem_rss(struct drm_gem_object *obj)
> > +{
> > + struct panfrost_gem_object *bo = to_panfrost_bo(obj);
> > +
> > + if (bo->is_heap) {
> > + return bo->heap_rss_size;
> > + } else if (bo->base.pages) {
> > + WARN_ON(bo->heap_rss_size);
> > + return bo->base.base.size;
> > + } else {
> > + return 0;
> > + }
> > +}
> > +
> > static const struct drm_gem_object_funcs panfrost_gem_funcs = {
> > .free = panfrost_gem_free_object,
> > .open = panfrost_gem_open,
> > @@ -220,6 +234,7 @@ static const struct drm_gem_object_funcs
> > panfrost_gem_funcs = {
> > .vunmap = drm_gem_shmem_object_vunmap,
> > .mmap = drm_gem_shmem_object_mmap,
> > .status = panfrost_gem_status,
> > + .rss = panfrost_gem_rss,
> > .vm_ops = _gem_shmem_vm_ops,
> > };
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h
> > b/drivers/gpu/drm/panfrost/panfrost_gem.h
> > index ad2877eeeccd..13c0a8149c3a 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_gem.h
> > +++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
> > @@ -36,6 +36,11 @@ struct panfrost_gem_object {
> > */
> > atomic_t gpu_usecount;
> >
> > + /*
> > +* Object chunk size currently mapped onto physical memory
> > +*/
> > + size_t heap_rss_size;
> > +
> > bool noexec :1;
> > bool is_heap:1;
> > };
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > index d54d4e7b2195..7b1490cdaa48 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > @@ -522,6 +522,7 @@ static int panfrost_mmu_map_fault_addr(struct
> > panfrost_device *pfdev, int as,
> >IOMMU_WRITE | IOMMU_READ | IOMMU_NOEXEC, sgt);
> >
> > bomapping->active = true;
> > + bo->heap_rss_size += SZ_2;
> >
> > dev_dbg(pfdev->dev, "mapped page fault @ AS%d %llx", as, addr);
> >
>
Re: [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP
On Tue, 2023-09-12 at 10:53 -0500, Rob Herring wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Tue, Sep 12, 2023 at 11:13:50AM +0100, Robin Murphy wrote: > > On 12/09/2023 9:28 am, Krzysztof Kozlowski wrote: > > > On 12/09/2023 08:16, Yong Wu (吴勇) wrote: > > > > Hi Rob, > > > > > > > > Thanks for your review. > > > > > > > > On Mon, 2023-09-11 at 10:44 -0500, Rob Herring wrote: > > > > > > > > > > External email : Please do not click links or open > attachments until > > > > > you have verified the sender or the content. > > > > > On Mon, Sep 11, 2023 at 10:30:37AM +0800, Yong Wu wrote: > > > > > > This adds the binding for describing a CMA memory for > MediaTek > > > > > SVP(Secure > > > > > > Video Path). > > > > > > > > > > CMA is a Linux thing. How is this related to CMA? > > > > > > > > > > > > > > > > Signed-off-by: Yong Wu > > > > > > --- > > > > > > .../mediatek,secure_cma_chunkmem.yaml | 42 > > > > > +++ > > > > > > 1 file changed, 42 insertions(+) > > > > > > create mode 100644 > Documentation/devicetree/bindings/reserved- > > > > > memory/mediatek,secure_cma_chunkmem.yaml > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/reserved- > > > > > memory/mediatek,secure_cma_chunkmem.yaml > > > > > b/Documentation/devicetree/bindings/reserved- > > > > > memory/mediatek,secure_cma_chunkmem.yaml > > > > > > new file mode 100644 > > > > > > index ..cc10e00d35c4 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/reserved- > > > > > memory/mediatek,secure_cma_chunkmem.yaml > > > > > > @@ -0,0 +1,42 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: > > > > > > http://devicetree.org/schemas/reserved-memory/mediatek,secure_cma_chunkmem.yaml# > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > + > > > > > > +title: MediaTek Secure Video Path Reserved Memory > > > > > > > > > > What makes this specific to Mediatek? Secure video path is > fairly > > > > > common, right? > > > > > > > > Here we just reserve a buffer and would like to create a dma- > buf secure > > > > heap for SVP, then the secure engines(Vcodec and DRM) could > prepare > > > > secure buffer through it. > > > > But the heap driver is pure SW driver, it is not platform > device and > > > > > > All drivers are pure SW. > > > > > > > we don't have a corresponding HW unit for it. Thus I don't > think I > > > > could create a platform dtsi node and use "memory-region" > pointer to > > > > the region. I used RESERVEDMEM_OF_DECLARE currently(The code is > in > > > > [9/9]). Sorry if this is not right. > > > > > > If this is not for any hardware and you already understand this > (since > > > you cannot use other bindings) then you cannot have custom > bindings for > > > it either. > > > > > > > > > > > Then in our usage case, is there some similar method to do > this? or > > > > any other suggestion? > > > > > > Don't stuff software into DTS. > > > > Aren't most reserved-memory bindings just software policy if you > look at it > > that way, though? IIUC this is a pool of memory that is visible and > > available to the Non-Secure OS, but is fundamentally owned by the > Secure > > TEE, and pages that the TEE allocates from it will become > physically > > inaccessible to the OS. Thus the platform does impose constraints > on how the > > Non-Secure OS may use it, and per the rest of the reserved-memory > bindings, > > describing it as a "reusable" reservation seems entirely > appropriate. If > > anything that's *more* platform-related and so DT-relevant than > typical > > arbitrary reservations which just represent "save some memory to > dedicate to > > a particular driver" and don't actually bear any relationship to > firmware or > > hardware at all. > > Yes, a memory range defined by hardware or firmware is within scope > of > DT. (CMA at aribitrary address was questionable.) I guess the memory range is not "defined" by HW in our case, but this reserve buffer is indeed prepared for and used by HW. If this is a normal reserved buffer for some device, we could define a reserved-memory with "shared-dma-pool", then the device use it via "memory-region" property, is this right? Here it is a secure buffer case and this usage relationship is indirect. We create a new heap for this new secure type memory, other users such as VCODEC and DRM allocate secure memory through the new heap. About the aribitrary address is because we have HW register for it. As long as this is a legal dram address, it is fine. When this address is passed into TEE, it will be protected by HW. > > My issue here is more that 'secure video memory' is not any way > Mediatek > specific. Sorry, I don't know if there already is an SVP case in the current kernel. If so, could you
Re: [PATCH 3/9] dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps
On Tue, 2023-09-12 at 11:05 -0400, Nicolas Dufresne wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > Le mardi 12 septembre 2023 à 08:47 +, Yong Wu (吴勇) a écrit : > > On Mon, 2023-09-11 at 12:12 -0400, Nicolas Dufresne wrote: > > > > > > External email : Please do not click links or open attachments > until > > > you have verified the sender or the content. > > > Hi, > > > > > > Le lundi 11 septembre 2023 à 10:30 +0800, Yong Wu a écrit : > > > > From: John Stultz > > > > > > > > This allows drivers who don't want to create their own > > > > DMA-BUF exporter to be able to allocate DMA-BUFs directly > > > > from existing DMA-BUF Heaps. > > > > > > > > There is some concern that the premise of DMA-BUF heaps is > > > > that userland knows better about what type of heap memory > > > > is needed for a pipeline, so it would likely be best for > > > > drivers to import and fill DMA-BUFs allocated by userland > > > > instead of allocating one themselves, but this is still > > > > up for debate. > > > > > > > > > Would be nice for the reviewers to provide the information about > the > > > user of > > > this new in-kernel API. I noticed it because I was CCed, but > > > strangely it didn't > > > make it to the mailing list yet and its not clear in the cover > what > > > this is used > > > with. > > > > > > I can explain in my words though, my read is that this is used to > > > allocate both > > > user visible and driver internal memory segments in MTK VCODEC > > > driver. > > > > > > I'm somewhat concerned that DMABuf objects are used to abstract > > > secure memory > > > allocation from tee. For framebuffers that are going to be > exported > > > and shared > > > its probably fair use, but it seems that internal shared memory > and > > > codec > > > specific reference buffers also endup with a dmabuf fd (often > called > > > a secure fd > > > in the v4l2 patchset) for data that is not being shared, and > requires > > > a 1:1 > > > mapping to a tee handle anyway. Is that the design we'd like to > > > follow ? > > > > Yes. basically this is right. > > > > > Can't > > > we directly allocate from the tee, adding needed helper to make > this > > > as simple > > > as allocating from a HEAP ? > > > > If this happens, the memory will always be inside TEE. Here we > create a > > new _CMA heap, it will cma_alloc/free dynamically. Reserve it > before > > SVP start, and release to kernel after SVP done. > > Ok, I see the benefit of having a common driver then. It would add to > the > complexity, but having a driver for the tee allocator and v4l2/heaps > would be > another option? It's ok for v4l2. But our DRM also use this new heap and it will be sent upstream in the next few days. > > > > > Secondly. the v4l2/drm has the mature driver control flow, like > > drm_gem_prime_import_dev that always use dma_buf ops. So we can use > the > > current flow as much as possible without having to re-plan a flow > in > > the TEE. > > From what I've read from Yunfei series, this is only partially true > for V4L2. > The vb2 queue MMAP feature have dmabuf exportation as optional, but > its not a > problem to always back it up with a dmabuf object. But for internal > SHM buffers > used for firmware communication, I've never seen any driver use a > DMABuf. > > Same applies for primary decode buffers when frame buffer compression > or post- > processing it used (or reconstruction buffer in encoders), these are > not user > visible and are usually not DMABuf. If they aren't dmabuf, of course it is ok. I guess we haven't used these. The SHM buffer is got by tee_shm_register_kernel_buf in this case and we just use the existed dmabuf ops to complete SVP. In our case, the vcodec input/output/working buffers and DRM input buffer all use this new secure heap during secure video play. > > > > > > > > > Nicolas > > > > > > > > > > > Signed-off-by: John Stultz > > > > Signed-off-by: T.J. Mercier > > > > Signed-off-by: Yong Wu > > > > [Yong: Fix the checkpatch alignment warning] > > > > --- > > > > drivers/dma-buf/dma-heap.c | 60 > > > > -- > > > > include/linux/dma-heap.h | 25 > > > > 2 files changed, 69 insertions(+), 16 deletions(-) > > > > > > [snip] >
Re: [PATCH v3 1/4] drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
On 18.09.2023 13:48, Karolina Stolarek wrote:
On 12.09.2023 14:54, Christian König wrote:
Am 12.09.23 um 13:49 schrieb Karolina Stolarek:
Test initialization of ttm_resource using different memory domains.
Add tests for a system memory manager and functions that can be
tested without a fully-featured resource manager. Update
ttm_bo_kunit_init() to initialize BO's kref and reservation object.
Export ttm_resource_alloc symbol for test purposes only.
Signed-off-by: Karolina Stolarek
---
drivers/gpu/drm/ttm/tests/Makefile | 1 +
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 23 ++
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 4 +
drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 ++
drivers/gpu/drm/ttm/ttm_resource.c | 3 +
5 files changed, 366 insertions(+)
create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
diff --git a/drivers/gpu/drm/ttm/tests/Makefile
b/drivers/gpu/drm/ttm/tests/Makefile
index ec87c4fc1ad5..c92fe2052ef6 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -3,4 +3,5 @@
obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
ttm_device_test.o \
ttm_pool_test.o \
+ ttm_resource_test.o \
ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 81661d8827aa..eccc59b981f8 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -38,10 +38,33 @@ struct ttm_buffer_object
*ttm_bo_kunit_init(struct kunit *test,
bo->base = gem_obj;
bo->bdev = devs->ttm_dev;
+ kref_init(>kref);
+
+ dma_resv_init(>base._resv);
+ bo->base.resv = >base._resv;
+
I'm really wondering if we shouldn't now initialize the GEM object
properly?
That would also initialize the reservation object if I remember
correctly.
Do you mean by using drm_gem_object_init()?
I tried initializing bo.base with drm_gem_object_init() and it's looking
good, but one check in that function makes testing of "Misaligned size"
subtest of ttm_tt_init_basic impossible:
BUG_ON((size & (PAGE_SIZE - 1)) != 0);
I wanted to test if ttm_tt_init properly calculates the number of pages,
but it looks like in the normal circuimstances it already gets a GEM
object of a size that is page-aligned. Would you prefer to write this
subtest as a separate test with a dummy misaligned GEM object, or to
delete this subtest altogether?
Many thanks,
Karolina
The solution with EXPORT_SYMBOL_FOR_TESTS_ONLY looks really nice I
think and apart from that I can't see anything obviously wrong either,
but I only skimmed over the code.
I'm also glad with EXPORT_SYMBOL_FOR_TESTS_ONLY solution, it's much
better now. Right, you can take a closer look at the next version. I'll
try to get an actual GEM object here, if you think that's feasible.
All the best,
Karolina
Regards,
Christian.
return bo;
}
EXPORT_SYMBOL_GPL(ttm_bo_kunit_init);
+struct ttm_place *ttm_place_kunit_init(struct kunit *test,
+ uint32_t mem_type, uint32_t flags,
+ size_t size)
+{
+ struct ttm_place *place;
+
+ place = kunit_kzalloc(test, sizeof(*place), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, place);
+
+ place->mem_type = mem_type;
+ place->flags = flags;
+ place->fpfn = size >> PAGE_SHIFT;
+ place->lpfn = place->fpfn + (size >> PAGE_SHIFT);
+
+ return place;
+}
+EXPORT_SYMBOL_GPL(ttm_place_kunit_init);
+
struct ttm_test_devices *ttm_test_devices_basic(struct kunit *test)
{
struct ttm_test_devices *devs;
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
index e261e3660d0b..f38140f93c05 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,6 +29,9 @@ int ttm_device_kunit_init(struct ttm_test_devices
*priv,
struct ttm_buffer_object *ttm_bo_kunit_init(struct kunit *test,
struct ttm_test_devices *devs,
size_t size);
+struct ttm_place *ttm_place_kunit_init(struct kunit *test,
+ uint32_t mem_type, uint32_t flags,
+ size_t size);
struct ttm_test_devices *ttm_test_devices_basic(struct kunit *test);
struct ttm_test_devices *ttm_test_devices_all(struct kunit *test);
diff --git a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
new file mode 100644
index ..851cdc43dc37
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
@@ -0,0 +1,335 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include
+
+#include "ttm_kunit_helpers.h"
+
+#define RES_SIZE SZ_4K
+#define
Re: [V11 1/8] ACPI: Add support for AMD ACPI based Wifi band RFI mitigation feature
On 8/31/2023 01:20, Evan Quan wrote:
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced a mechanism that devices can use to
notify active use of particular frequencies so that other devices can make
relative internal adjustments as necessary to avoid this resonance.
Signed-off-by: Evan Quan
--
v10->v11:
- fix typo(Simon)
Rafael,
Friendly ping on reviewing patch 1 from v11.
Thank you,
---
drivers/acpi/Kconfig | 17 ++
drivers/acpi/Makefile | 2 +
drivers/acpi/amd_wbrf.c | 414 ++
include/linux/acpi_amd_wbrf.h | 140
4 files changed, 573 insertions(+)
create mode 100644 drivers/acpi/amd_wbrf.c
create mode 100644 include/linux/acpi_amd_wbrf.h
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 00dd309b6682..a092ea72d152 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -594,6 +594,23 @@ config ACPI_PRMT
substantially increase computational overhead related to the
initialization of some server systems.
+config WBRF_AMD_ACPI
+ bool "ACPI based WBRF mechanism introduced by AMD"
+ depends on ACPI
+ default n
+ help
+ Wifi band RFI mitigation mechanism allows multiple drivers from
+ different domains to notify the frequencies in use so that hardware
+ can be reconfigured to avoid harmonic conflicts.
+
+ AMD has introduced an ACPI based mechanism to support WBRF for some
+ platforms with AMD dGPU and WLAN. This needs support from BIOS
equipped
+ with necessary AML implementations and dGPU firmwares.
+
+ Before enabling this ACPI based mechanism, it is suggested to confirm
+ with the hardware designer/provider first whether your platform
+ equipped with necessary BIOS and firmwares.
+
endif # ACPI
config X86_PM_TIMER
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index eaa09bf52f17..a3d2f259d0a5 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -132,3 +132,5 @@ obj-$(CONFIG_ARM64) += arm64/
obj-$(CONFIG_ACPI_VIOT) += viot.o
obj-$(CONFIG_RISCV) += riscv/
+
+obj-$(CONFIG_WBRF_AMD_ACPI)+= amd_wbrf.o
diff --git a/drivers/acpi/amd_wbrf.c b/drivers/acpi/amd_wbrf.c
new file mode 100644
index ..8ee0e2977a30
--- /dev/null
+++ b/drivers/acpi/amd_wbrf.c
@@ -0,0 +1,414 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Wifi Band Exclusion Interface (AMD ACPI Implementation)
+ * Copyright (C) 2023 Advanced Micro Devices
+ *
+ */
+
+#include
+#include
+
+#define ACPI_AMD_WBRF_METHOD "\\WBRF"
+
+/*
+ * Functions bit vector for WBRF method
+ *
+ * Bit 0: Supported for any functions other than function 0.
+ * Bit 1: Function 1 (Add / Remove frequency) is supported.
+ * Bit 2: Function 2 (Get frequency list) is supported.
+ */
+#define WBRF_ENABLED 0x0
+#define WBRF_RECORD0x1
+#define WBRF_RETRIEVE 0x2
+
+/* record actions */
+#define WBRF_RECORD_ADD0x0
+#define WBRF_RECORD_REMOVE 0x1
+
+#define WBRF_REVISION 0x1
+
+/*
+ * The data structure used for WBRF_RETRIEVE is not naturally aligned.
+ * And unfortunately the design has been settled down.
+ */
+struct amd_wbrf_ranges_out {
+ u32 num_of_ranges;
+ struct exclusion_range band_list[MAX_NUM_OF_WBRF_RANGES];
+} __packed;
+
+static const guid_t wifi_acpi_dsm_guid =
+ GUID_INIT(0x7b7656cf, 0xdc3d, 0x4c1c,
+ 0x83, 0xe9, 0x66, 0xe7, 0x21, 0xde, 0x30, 0x70);
+
+static BLOCKING_NOTIFIER_HEAD(wbrf_chain_head);
+
+static int wbrf_dsm(struct acpi_device *adev,
+ u8 fn,
+ union acpi_object *argv4)
+{
+ union acpi_object *obj;
+ int rc;
+
+ obj = acpi_evaluate_dsm(adev->handle, _acpi_dsm_guid,
+ WBRF_REVISION, fn, argv4);
+ if (!obj)
+ return -ENXIO;
+
+ switch (obj->type) {
+ case ACPI_TYPE_INTEGER:
+ rc = obj->integer.value ? -EINVAL : 0;
+ break;
+ default:
+ rc = -EOPNOTSUPP;
+ }
+
+ ACPI_FREE(obj);
+
+ return rc;
+}
+
+static int wbrf_record(struct acpi_device *adev, uint8_t action,
+ struct wbrf_ranges_in_out *in)
+{
+ union acpi_object argv4;
+ union acpi_object *tmp;
+ u32 num_of_ranges = 0;
+ u32 num_of_elements;
+ u32 arg_idx = 0;
+ u32 loop_idx;
+ int ret;
+
+ if (!in)
+ return -EINVAL;
+
+ for (loop_idx = 0; loop_idx < ARRAY_SIZE(in->band_list);
+loop_idx++)
+ if (in->band_list[loop_idx].start &&
Re: [PATCH v2 2/2] drivers/tidss: Add support for AM62A7 DSS
On 18/08/2023 17:21, Aradhya Bhatia wrote:
Add support for the DSS controller on TI's AM62A7 SoC in the tidss
driver.
This contrller has 2 video pipelines that can render 2 video planes on
"controller".
over a screen, using the overlay managers. The output of the DSS comes
from video port 2 (VP2) in the form of RGB88 DPI signals, while the VP1
is tied off inside the SoC.
If the VP1 is tied off, I think we should somehow mark it in the feats
below. Maybe just a comment, or perhaps a new DISPC_VP_* flag.
Tomi
Signed-off-by: Aradhya Bhatia
---
Notes:
Changes from V1:
* Correctly sort DISPC_AM62A7 macro after DISPC_AM625.
drivers/gpu/drm/tidss/tidss_dispc.c | 53 +
drivers/gpu/drm/tidss/tidss_dispc.h | 2 ++
drivers/gpu/drm/tidss/tidss_drv.c | 1 +
3 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 9d9dee7abaef..5539ddb7f338 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -322,6 +322,54 @@ const struct dispc_features dispc_am625_feats = {
.vid_order = { 1, 0 },
};
+const struct dispc_features dispc_am62a7_feats = {
+ .max_pclk_khz = {
+ [DISPC_VP_DPI] = 165000,
+ },
+
+ .scaling = {
+ .in_width_max_5tap_rgb = 1280,
+ .in_width_max_3tap_rgb = 2560,
+ .in_width_max_5tap_yuv = 2560,
+ .in_width_max_3tap_yuv = 4096,
+ .upscale_limit = 16,
+ .downscale_limit_5tap = 4,
+ .downscale_limit_3tap = 2,
+ /*
+* The max supported pixel inc value is 255. The value
+* of pixel inc is calculated like this: 1+(xinc-1)*bpp.
+* The maximum bpp of all formats supported by the HW
+* is 8. So the maximum supported xinc value is 32,
+* because 1+(32-1)*8 < 255 < 1+(33-1)*4.
+*/
+ .xinc_max = 32,
+ },
+
+ .subrev = DISPC_AM62A7,
+
+ .common = "common",
+ .common_regs = tidss_am65x_common_regs,
+
+ .num_vps = 2,
+ .vp_name = { "vp1", "vp2" },
+ .ovr_name = { "ovr1", "ovr2" },
+ .vpclk_name = { "vp1", "vp2" },
+ .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI },
+
+ .vp_feat = { .color = {
+ .has_ctm = true,
+ .gamma_size = 256,
+ .gamma_type = TIDSS_GAMMA_8BIT,
+ },
+ },
+
+ .num_planes = 2,
+ /* note: vid is plane_id 0 and vidl1 is plane_id 1 */
+ .vid_name = { "vid", "vidl1" },
+ .vid_lite = { false, true, },
+ .vid_order = { 1, 0 },
+};
+
static const u16 *dispc_common_regmap;
struct dss_vp_data {
@@ -824,6 +872,7 @@ dispc_irq_t dispc_read_and_clear_irqstatus(struct
dispc_device *dispc)
case DISPC_K2G:
return dispc_k2g_read_and_clear_irqstatus(dispc);
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
case DISPC_J721E:
return dispc_k3_read_and_clear_irqstatus(dispc);
@@ -840,6 +889,7 @@ void dispc_set_irqenable(struct dispc_device *dispc,
dispc_irq_t mask)
dispc_k2g_set_irqenable(dispc, mask);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_set_irqenable(dispc, mask);
@@ -1331,6 +1381,7 @@ void dispc_ovr_set_plane(struct dispc_device *dispc, u32
hw_plane,
x, y, layer);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
dispc_am65x_ovr_set_plane(dispc, hw_plane, hw_videoport,
x, y, layer);
@@ -2250,6 +2301,7 @@ static void dispc_plane_init(struct dispc_device *dispc)
dispc_k2g_plane_init(dispc);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
case DISPC_J721E:
dispc_k3_plane_init(dispc);
@@ -2357,6 +2409,7 @@ static void dispc_vp_write_gamma_table(struct
dispc_device *dispc,
dispc_k2g_vp_write_gamma_table(dispc, hw_videoport);
break;
case DISPC_AM625:
+ case DISPC_AM62A7:
case DISPC_AM65X:
dispc_am65x_vp_write_gamma_table(dispc, hw_videoport);
break;
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h
b/drivers/gpu/drm/tidss/tidss_dispc.h
index 33ac5ad7a423..7f203f83559b 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc.h
@@ -60,6 +60,7 @@ enum dispc_vp_bus_type {
enum dispc_dss_subrevision {
DISPC_K2G,
DISPC_AM625,
+ DISPC_AM62A7,
DISPC_AM65X,
DISPC_J721E,
};
@@ -88,6 +89,7 @@ struct dispc_features
Re: [PATCH v3 0/4] Fix up the boe-tv101wum-nl6 panel driver
Hi, On Mon, Jul 3, 2023 at 6:21 AM Linus Walleij wrote: > > This is two patches fixing things I would normally complain about > in reviews, but alas I missed this one, so I go in and fix it up > myself. > > Discovering that a completely unrelated driver has been merged > into this panel driver I had to bite the bullet and break it out. > I am pretty suspicious of the other recently added panel as well. > > I am surprised that contributors from manufacturers do not seem > to have datasheets for the display controllers embedded in the > panels of their products. Can you take a second look? > > Signed-off-by: Linus Walleij > --- > Changes in v3: > - Rebase on drm-misc-next > - Convert the two newly added Starry panels as well. > - Break out the obvious ILI9882t-based panel into its own driver. > - Link to v2: > https://lore.kernel.org/r/20230615-fix-boe-tv101wum-nl6-v2-0-457d7ece4...@linaro.org > > Changes in v2: > - Fix a missed static keyword > - Link to v1: > https://lore.kernel.org/r/20230615-fix-boe-tv101wum-nl6-v1-0-8ac378405...@linaro.org > > --- > Linus Walleij (4): > drm/panel: boe-tv101wum-nl6: Drop macros and open code sequences > drm/panel: boe-tv101wum-nl6: Drop surplus prepare tracking > drm/panel: ili9882t: Break out as separate driver > drm/panel: ili9882t: Break out function for switching page > > drivers/gpu/drm/panel/Kconfig |9 + > drivers/gpu/drm/panel/Makefile |1 + > drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 3037 > ++-- > drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 759 ++ > 4 files changed, 2067 insertions(+), 1739 deletions(-) I'm curious what the latest on this patch series is. Is it abandoned, or is it still on your list to move forward with it? If it's abandoned, does that mean we've abandoned the idea of breaking ili9882t into a separate driver? >From looking at things that have landed downstream in the ChromeOS kernel trees it looks as if additional fixes are getting blocked from being posted/landed because of the limbo state that this is in. -Doug
[PATCH v2] drm/etnaviv: refactor deprecated strncpy
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy_pad` due to the fact that it guarantees NUL-termination on the destination buffer whilst maintaining the NUL-padding behavior that strncpy provides. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-harden...@vger.kernel.org Cc: Bo YU Signed-off-by: Justin Stitt --- Changes in v2: - use strscpy_pad (thanks Kees) - Link to v1: https://lore.kernel.org/r/20230914-strncpy-drivers-gpu-drm-etnaviv-etnaviv_perfmon-c-v1-1-3adc2d9bf...@google.com --- Similar to [2] which was never picked up. Let's prefer strscpy_pad to strlcpy, though [2]: https://lore.kernel.org/all/20190328080918.9290-1-tsu.y...@gmail.com/ --- drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c index bafdfe49c1d8..dc9dea664a28 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c @@ -511,7 +511,7 @@ int etnaviv_pm_query_dom(struct etnaviv_gpu *gpu, domain->id = domain->iter; domain->nr_signals = dom->nr_signals; - strncpy(domain->name, dom->name, sizeof(domain->name)); + strscpy_pad(domain->name, dom->name, sizeof(domain->name)); domain->iter++; if (domain->iter == nr_domains) @@ -540,7 +540,7 @@ int etnaviv_pm_query_sig(struct etnaviv_gpu *gpu, sig = >signal[signal->iter]; signal->id = signal->iter; - strncpy(signal->name, sig->name, sizeof(signal->name)); + strscpy_pad(signal->name, sig->name, sizeof(signal->name)); signal->iter++; if (signal->iter == dom->nr_signals) --- base-commit: 3669558bdf354cd352be955ef2764cde6a9bf5ec change-id: 20230914-strncpy-drivers-gpu-drm-etnaviv-etnaviv_perfmon-c-dd095491dfde Best regards, -- Justin Stitt
Re: WARNING: CPU: 14 PID: 125 at drivers/gpu/drm/drm_mode_object.c:45 drm_mode_object_add+0x80/0x90 [drm]
On Mon, Sep 18, 2023 at 3:17 AM Toralf Förster wrote: > > I do suffer since 1 or 2 weeks from amd gpu problems (6.1.53 and before) > like > > Sep 15 16:51:22 p14s kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* > ring sdma0 timeout, signaled seq=122011, emitted seq=122013 > Sep 15 16:51:22 p14s kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* > Process information: process pid 0 thread pid 0 > Sep 15 16:51:22 p14s kernel: amdgpu :04:00.0: amdgpu: GPU reset begin! > Sep 15 16:51:23 p14s kernel: amdgpu :04:00.0: amdgpu: free PSP TMR > buffer > Sep 15 16:51:23 p14s kernel: amdgpu :04:00.0: amdgpu: MODE2 reset > Sep 15 16:51:23 p14s kernel: amdgpu :04:00.0: amdgpu: GPU reset > succeeded, trying to resume > Sep 15 16:51:23 p14s kernel: [drm] PCIE GART of 1024M enabled (table at > 0x00F43FC0). > Sep 15 16:51:23 p14s kernel: [drm] PSP is resuming... > Sep 15 16:51:23 p14s kernel: [drm] reserve 0xa0 from 0xf43e00 > for PSP TMR > > and tried therefore 6.5.3. But dmesg gives: > > WARNING: CPU: 14 PID: 125 at drivers/gpu/drm/drm_mode_object.c:45 > drm_mode_object_add+0x80/0x90 [drm] > WARNING: CPU: 14 PID: 125 at drivers/gpu/drm/drm_mode_object.c:45 > drm_mode_object_add+0x80/0x90 [drm] > WARNING: CPU: 14 PID: 125 at drivers/gpu/drm/drm_mode_object.c:45 > drm_mode_object_add+0x80/0x90 [drm] > > Are those warning harmless ? Full dmesg and .config are attached. Yes. Fixed in this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=69a959610229 Alex > TIA > > -- > toralf
Re: [PATCH v3 11/13] drm/sched: Waiting for pending jobs to complete in scheduler kill
On 9/18/23 13:03, Christian König wrote:
Am 16.09.23 um 19:52 schrieb Danilo Krummrich:
On 9/12/23 16:47, Matthew Brost wrote:
On Tue, Sep 12, 2023 at 11:57:30AM +0200, Christian König wrote:
Am 12.09.23 um 04:16 schrieb Matthew Brost:
Wait for pending jobs to be complete before signaling queued jobs. This
ensures dma-fence signaling order correct and also ensures the entity is
not running on the hardware after drm_sched_entity_flush or
drm_sched_entity_fini returns.
Entities are *not* supposed to outlive the submissions they carry and we
absolutely *can't* wait for submissions to finish while killing the entity.
In other words it is perfectly expected that entities doesn't exists any
more while the submissions they carried are still running on the hardware.
I somehow better need to document how this working and especially why it is
working like that.
This approach came up like four or five times now and we already applied and
reverted patches doing this.
For now let's take a look at the source code of drm_sched_entity_kill():
/* The entity is guaranteed to not be used by the scheduler */
prev = rcu_dereference_check(entity->last_scheduled, true);
dma_fence_get(prev);
while ((job = to_drm_sched_job(spsc_queue_pop(>job_queue
{
struct drm_sched_fence *s_fence = job->s_fence;
dma_fence_get(_fence->finished);
if (!prev || dma_fence_add_callback(prev, >finish_cb,
drm_sched_entity_kill_jobs_cb))
drm_sched_entity_kill_jobs_cb(NULL,
>finish_cb);
prev = _fence->finished;
}
dma_fence_put(prev);
This ensures the dma-fence signaling order by delegating signaling of the
scheduler fences into callbacks.
Thanks for the explaination, this code makes more sense now. Agree this
patch is not correct.
This patch really is an RFC for something Nouveau needs, I can delete
this patch in the next rev and let Nouveau run with a slightly different
version if needed.
Maybe there was a misunderstanding, I do not see any need for this in Nouveau.
Instead, what I think we need is a way to wait for the pending_list being empty
(meaning all jobs on the pending_list are freed) before we call
drm_sched_fini().
Currently, if we call drm_sched_fini() there might still be pending jobs on the
pending_list (unless the driver implements something driver specific).
drm_sched_fini() stops the scheduler work though, hence pending jobs will never
be
freed up leaking their memory.
This might also be true for existing drivers, but since they call
drm_sched_fini()
from their driver remove callback, this race is extremely unlikely. However, it
definitely is an issue for drivers using the single entitiy policy calling
drm_sched_fini() from a context where it is much more likely pending jobs still
exist.
Yeah, that's exactly one of the reasons why I want to get away from the idea
that the scheduler is necessary for executing the commands.
What this component should do is to push jobs to the hardware and not overview
their execution, that's the job of the driver.
While, generally, I'd agree, I think we can't really get around having
something that
frees the job once it's fence got signaled. This "something" could be the
driver, but
once it ends up being the same code over and over again for every driver, we're
probably
back letting the scheduler do it instead in a common way.
In other words drivers should be able to call drm_sched_fini() while there are
jobs still pending on the hardware.
Unless we have a better idea on how to do this, I'd, as mentioned, suggest to
have something
like drm_sched_teardown() and/or drm_sched_teardown_timeout() waiting for
pending jobs.
Also keep in mind that you *can't* wait for all hw operations to finish in your
flush or file descriptor close callback or you create un-killable processes.
Right, that's why in Nouveau I try to wait for the channel (ring) being idle
and if this didn't
work in a "reasonable" amount of time, I kill the fence context, signalling all
fences with an
error code, and wait for the scheduler being idle, which comes down to only
wait for all free_job()
callbacks to finish, since all jobs are signaled already.
Regards,
Christian.
Matt
Regards,
Christian.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 7 ++-
drivers/gpu/drm/scheduler/sched_main.c | 50 ++---
include/drm/gpu_scheduler.h | 18
4 files changed, 70 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index fb5dad687168..7835c0da65c5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1873,7 +1873,7 @@ static void
[PATCH v5 14/14] media: platform: mtk-mdp3: add support for parallel pipe to improve FPS
In some chips, MDP3 has the ability to utilize two pipelines to
parallelly process a single frame.
To enable this feature, multiple CMDQ clients and packets need to
be configured at the same time.
Signed-off-by: Moudy Ho
---
.../platform/mediatek/mdp3/mdp_cfg_data.c | 8 +
.../platform/mediatek/mdp3/mtk-mdp3-cmdq.c| 188 +-
.../platform/mediatek/mdp3/mtk-mdp3-cmdq.h| 1 +
.../platform/mediatek/mdp3/mtk-mdp3-core.c| 18 +-
.../platform/mediatek/mdp3/mtk-mdp3-core.h| 12 +-
.../platform/mediatek/mdp3/mtk-mdp3-m2m.c | 15 ++
.../platform/mediatek/mdp3/mtk-mdp3-regs.c| 18 ++
.../platform/mediatek/mdp3/mtk-mdp3-regs.h| 1 +
.../platform/mediatek/mdp3/mtk-mdp3-vpu.c | 3 +-
9 files changed, 208 insertions(+), 56 deletions(-)
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index e23647c202c6..43ec37d34e38 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -1060,6 +1060,11 @@ static const struct mdp_pipe_info mt8195_pipe_info[] = {
[MDP_PIPE_VPP0_SOUT] = {MDP_PIPE_VPP0_SOUT, 1, 5},
};
+static const struct v4l2_rect mt8195_mdp_pp_criteria = {
+ .width = 1920,
+ .height = 1080,
+};
+
const struct mtk_mdp_driver_data mt8183_mdp_driver_data = {
.mdp_plat_id = MT8183,
.mdp_con_res = 0x14001000,
@@ -1074,6 +1079,7 @@ const struct mtk_mdp_driver_data mt8183_mdp_driver_data =
{
.def_limit = _mdp_def_limit,
.pipe_info = mt8183_pipe_info,
.pipe_info_len = ARRAY_SIZE(mt8183_pipe_info),
+ .pp_used = MDP_PP_USED_1,
};
const struct mtk_mdp_driver_data mt8195_mdp_driver_data = {
@@ -1090,6 +1096,8 @@ const struct mtk_mdp_driver_data mt8195_mdp_driver_data =
{
.def_limit = _mdp_def_limit,
.pipe_info = mt8195_pipe_info,
.pipe_info_len = ARRAY_SIZE(mt8195_pipe_info),
+ .pp_criteria = _mdp_pp_criteria,
+ .pp_used = MDP_PP_USED_2,
};
s32 mdp_cfg_get_id_inner(struct mdp_dev *mdp_dev, enum mtk_mdp_comp_id id)
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index 37964d230d9a..41bd5fe416af 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -62,6 +62,16 @@ static struct mtk_mutex *__get_mutex(const struct mdp_dev
*mdp_dev,
return m;
}
+static u8 __get_pp_num(enum mdp_stream_type type)
+{
+ switch (type) {
+ case MDP_STREAM_TYPE_DUAL_BITBLT:
+ return MDP_PP_USED_2;
+ default:
+ return MDP_PP_USED_1;
+ }
+}
+
static enum mdp_pipe_id __get_pipe(const struct mdp_dev *mdp_dev,
enum mtk_mdp_comp_id id)
{
@@ -99,6 +109,44 @@ static enum mdp_pipe_id __get_pipe(const struct mdp_dev
*mdp_dev,
return pipe_id;
}
+static struct img_config *__get_config_offset(struct mdp_dev *mdp,
+ struct mdp_cmdq_param *param,
+ u8 pp_idx)
+{
+ const int p_id = mdp->mdp_data->mdp_plat_id;
+ struct device *dev = >pdev->dev;
+ void *cfg_c, *cfg_n;
+ long bound = mdp->vpu.config_size;
+
+ if (pp_idx >= mdp->mdp_data->pp_used)
+ goto err_param;
+
+ if (CFG_CHECK(MT8183, p_id))
+ cfg_c = CFG_OFST(MT8183, param->config, pp_idx);
+ else if (CFG_CHECK(MT8195, p_id))
+ cfg_c = CFG_OFST(MT8195, param->config, pp_idx);
+ else
+ goto err_param;
+
+ if (CFG_CHECK(MT8183, p_id))
+ cfg_n = CFG_OFST(MT8183, param->config, pp_idx + 1);
+ else if (CFG_CHECK(MT8195, p_id))
+ cfg_n = CFG_OFST(MT8195, param->config, pp_idx + 1);
+ else
+ goto err_param;
+
+ if ((long)cfg_n - (long)mdp->vpu.config > bound) {
+ dev_err(dev, "config offset %ld OOB %ld\n", (long)cfg_n, bound);
+ cfg_c = ERR_PTR(-EFAULT);
+ }
+
+ return (struct img_config *)cfg_c;
+
+err_param:
+ cfg_c = ERR_PTR(-EINVAL);
+ return (struct img_config *)cfg_c;
+}
+
static int mdp_path_subfrm_require(const struct mdp_path *path,
struct mdp_cmdq_cmd *cmd,
struct mdp_pipe_info *p, u32 count)
@@ -483,8 +531,19 @@ static void mdp_auto_release_work(struct work_struct *work)
mdp_comp_clocks_off(>pdev->dev, cmd->comps,
cmd->num_comps);
- atomic_dec(>job_count);
- wake_up(>callback_wq);
+ if (atomic_dec_and_test(>job_count)) {
+ if (cmd->mdp_ctx)
+ mdp_m2m_job_finish(cmd->mdp_ctx);
+
+ if (cmd->user_cmdq_cb) {
+ struct cmdq_cb_data user_cb_data;
+
+
[PATCH v5 05/14] media: platform: mtk-mdp3: introduce more pipelines from MT8195
Increasing the number of sets built by MMSYS and MUTEX in MT8195
will enable the creation of more pipelines in MDP3.
Signed-off-by: Moudy Ho
---
.../platform/mediatek/mdp3/mtk-mdp3-cmdq.c| 80 ---
.../platform/mediatek/mdp3/mtk-mdp3-core.h| 7 ++
2 files changed, 60 insertions(+), 27 deletions(-)
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index 606651687465..6d04f72cf86f 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -57,6 +57,43 @@ static struct mtk_mutex *__get_mutex(const struct mdp_dev
*mdp_dev,
return m;
}
+static enum mdp_pipe_id __get_pipe(const struct mdp_dev *mdp_dev,
+ enum mtk_mdp_comp_id id)
+{
+ enum mdp_pipe_id pipe_id;
+
+ switch (id) {
+ case MDP_COMP_RDMA0:
+ pipe_id = MDP_PIPE_RDMA0;
+ break;
+ case MDP_COMP_ISP_IMGI:
+ pipe_id = MDP_PIPE_IMGI;
+ break;
+ case MDP_COMP_WPEI:
+ pipe_id = MDP_PIPE_WPEI;
+ break;
+ case MDP_COMP_WPEI2:
+ pipe_id = MDP_PIPE_WPEI2;
+ break;
+ case MDP_COMP_RDMA1:
+ pipe_id = MDP_PIPE_RDMA1;
+ break;
+ case MDP_COMP_RDMA2:
+ pipe_id = MDP_PIPE_RDMA2;
+ break;
+ case MDP_COMP_RDMA3:
+ pipe_id = MDP_PIPE_RDMA3;
+ break;
+ default:
+ /* Avoid exceptions when operating MUTEX */
+ pipe_id = MDP_PIPE_RDMA0;
+ dev_err(_dev->pdev->dev, "Unknown pipeline id %d", id);
+ break;
+ }
+
+ return pipe_id;
+}
+
static int mdp_path_subfrm_require(const struct mdp_path *path,
struct mdp_cmdq_cmd *cmd,
struct mdp_pipe_info *p, u32 count)
@@ -64,7 +101,6 @@ static int mdp_path_subfrm_require(const struct mdp_path
*path,
const int p_id = path->mdp_dev->mdp_data->mdp_plat_id;
const struct mdp_comp_ctx *ctx;
const struct mtk_mdp_driver_data *data = path->mdp_dev->mdp_data;
- struct device *dev = >mdp_dev->pdev->dev;
struct mtk_mutex *mutex;
int id, index;
u32 num_comp = 0;
@@ -73,23 +109,7 @@ static int mdp_path_subfrm_require(const struct mdp_path
*path,
num_comp = CFG_GET(MT8183, path->config, num_components);
/* Decide which mutex to use based on the current pipeline */
- switch (path->comps[0].comp->public_id) {
- case MDP_COMP_RDMA0:
- index = MDP_PIPE_RDMA0;
- break;
- case MDP_COMP_ISP_IMGI:
- index = MDP_PIPE_IMGI;
- break;
- case MDP_COMP_WPEI:
- index = MDP_PIPE_WPEI;
- break;
- case MDP_COMP_WPEI2:
- index = MDP_PIPE_WPEI2;
- break;
- default:
- dev_err(dev, "Unknown pipeline and no mutex is assigned");
- return -EINVAL;
- }
+ index = __get_pipe(path->mdp_dev, path->comps[0].comp->public_id);
memcpy(p, >pipe_info[index], sizeof(struct mdp_pipe_info));
mutex = __get_mutex(path->mdp_dev, p);
@@ -343,11 +363,13 @@ static void mdp_auto_release_work(struct work_struct
*work)
struct mdp_cmdq_cmd *cmd;
struct mdp_dev *mdp;
struct mtk_mutex *mutex;
+ enum mdp_pipe_id pipe_id;
cmd = container_of(work, struct mdp_cmdq_cmd, auto_release_work);
mdp = cmd->mdp;
- mutex = __get_mutex(mdp, >mdp_data->pipe_info[MDP_PIPE_RDMA0]);
+ pipe_id = __get_pipe(mdp, cmd->comps[0].public_id);
+ mutex = __get_mutex(mdp, >mdp_data->pipe_info[pipe_id]);
mtk_mutex_unprepare(mutex);
mdp_comp_clocks_off(>pdev->dev, cmd->comps,
cmd->num_comps);
@@ -368,6 +390,7 @@ static void mdp_handle_cmdq_callback(struct mbox_client
*cl, void *mssg)
struct cmdq_cb_data *data;
struct mdp_dev *mdp;
struct device *dev;
+ enum mdp_pipe_id pipe_id;
if (!mssg) {
pr_info("%s:no callback data\n", __func__);
@@ -395,7 +418,8 @@ static void mdp_handle_cmdq_callback(struct mbox_client
*cl, void *mssg)
struct mtk_mutex *mutex;
dev_err(dev, "%s:queue_work fail!\n", __func__);
- mutex = __get_mutex(mdp,
>mdp_data->pipe_info[MDP_PIPE_RDMA0]);
+ pipe_id = __get_pipe(mdp, cmd->comps[0].public_id);
+ mutex = __get_mutex(mdp, >mdp_data->pipe_info[pipe_id]);
mtk_mutex_unprepare(mutex);
mdp_comp_clocks_off(>pdev->dev, cmd->comps,
cmd->num_comps);
@@ -419,6 +443,7 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct
mdp_cmdq_param
[PATCH v5 13/14] media: platform: mtk-mdp3: add mt8195 MDP3 component settings
Extend the component settings used in MT8195 MDP3.
Additionally, it is crucial to read all component settings in
a specific manner to ensure that shared memory data structure lengths
are aligned across different platforms.
Signed-off-by: Moudy Ho
---
.../platform/mediatek/mdp3/mtk-mdp3-cmdq.c| 57 ++
.../platform/mediatek/mdp3/mtk-mdp3-comp.c| 787 +-
2 files changed, 840 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index 9c2afd002e7c..37964d230d9a 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -40,6 +40,10 @@ static bool is_output_disabled(int p_id, const struct
img_compparam *param, u32
num = CFG_COMP(MT8183, param, num_subfrms);
dis_output = CFG_COMP(MT8183, param, frame.output_disable);
dis_tile = CFG_COMP(MT8183, param, frame.output_disable);
+ } else if (CFG_CHECK(MT8195, p_id)) {
+ num = CFG_COMP(MT8195, param, num_subfrms);
+ dis_output = CFG_COMP(MT8195, param, frame.output_disable);
+ dis_tile = CFG_COMP(MT8195, param, frame.output_disable);
}
return (count < num) ? (dis_output || dis_tile) : true;
@@ -108,6 +112,8 @@ static int mdp_path_subfrm_require(const struct mdp_path
*path,
if (CFG_CHECK(MT8183, p_id))
num_comp = CFG_GET(MT8183, path->config, num_components);
+ else if (CFG_CHECK(MT8195, p_id))
+ num_comp = CFG_GET(MT8195, path->config, num_components);
/* Decide which mutex to use based on the current pipeline */
index = __get_pipe(path->mdp_dev, path->comps[0].comp->public_id);
@@ -122,6 +128,9 @@ static int mdp_path_subfrm_require(const struct mdp_path
*path,
if (CFG_CHECK(MT8183, p_id))
inner_id = CFG_GET(MT8183, path->config,
components[index].type);
+ else if (CFG_CHECK(MT8195, p_id))
+ inner_id = CFG_GET(MT8195, path->config,
components[index].type);
+
if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
continue;
@@ -163,12 +172,17 @@ static int mdp_path_subfrm_run(const struct mdp_path
*path,
if (CFG_CHECK(MT8183, p_id))
num_comp = CFG_GET(MT8183, path->config, num_components);
+ else if (CFG_CHECK(MT8195, p_id))
+ num_comp = CFG_GET(MT8195, path->config, num_components);
/* Wait WROT SRAM shared to DISP RDMA */
/* Clear SOF event for each engine */
for (index = 0; index < num_comp; index++) {
if (CFG_CHECK(MT8183, p_id))
inner_id = CFG_GET(MT8183, path->config,
components[index].type);
+ else if (CFG_CHECK(MT8195, p_id))
+ inner_id = CFG_GET(MT8195, path->config,
components[index].type);
+
if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
continue;
ctx = >comps[index];
@@ -187,6 +201,9 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
for (index = 0; index < num_comp; index++) {
if (CFG_CHECK(MT8183, p_id))
inner_id = CFG_GET(MT8183, path->config,
components[index].type);
+ else if (CFG_CHECK(MT8195, p_id))
+ inner_id = CFG_GET(MT8195, path->config,
components[index].type);
+
if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
continue;
ctx = >comps[index];
@@ -209,6 +226,8 @@ static int mdp_path_ctx_init(struct mdp_dev *mdp, struct
mdp_path *path)
if (CFG_CHECK(MT8183, p_id))
num_comp = CFG_GET(MT8183, path->config, num_components);
+ else if (CFG_CHECK(MT8195, p_id))
+ num_comp = CFG_GET(MT8195, path->config, num_components);
if (num_comp < 1)
return -EINVAL;
@@ -218,10 +237,15 @@ static int mdp_path_ctx_init(struct mdp_dev *mdp, struct
mdp_path *path)
if (CFG_CHECK(MT8183, p_id))
inner_id = CFG_GET(MT8183, path->config,
components[index].type);
+ else if (CFG_CHECK(MT8195, p_id))
+ inner_id = CFG_GET(MT8195, path->config,
components[index].type);
+
if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
continue;
if (CFG_CHECK(MT8183, p_id))
param = (void *)CFG_ADDR(MT8183, path->config,
components[index]);
+ else if (CFG_CHECK(MT8195, p_id))
+ param = (void *)CFG_ADDR(MT8195, path->config,
components[index]);
ret = mdp_comp_ctx_config(mdp, >comps[index],
param, path->param);
Re: [PATCH v5 02/14] arm64: dts: mediatek: mt8195: add MDP3 nodes
On Tue, 2023-09-12 at 10:23 +0200, Krzysztof Kozlowski wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 12/09/2023 09:57, Moudy Ho wrote: > > Add device nodes for Media Data Path 3 (MDP3) modules. > > > > Signed-off-by: Moudy Ho > > --- > > arch/arm64/boot/dts/mediatek/mt8195.dtsi | 378 > +++ > > 1 file changed, 378 insertions(+) > > Why is this targeting media? No, don't. DTS goes via SoC, not media. > Don't mix patches. > > Best regards, > Krzysztof > Hi Krzysztof, My apologies. I'll split these DTS into separate series. Sincerely, Moudy
[PATCH v2 2/2] backlight: mp3309c: Add support for MPS MP3309C
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
programmable switching frequency to optimize efficiency.
The brightness can be controlled either by I2C commands (called "analog"
mode) or by a PWM input signal (PWM mode).
This driver supports both modes.
For DT configuration details, please refer to:
- Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
The datasheet is available at:
- https://www.monolithicpower.com/en/mp3309c.html
Signed-off-by: Flavio Suligoi
---
v2:
- fix dependecies in Kconfig
- fix Kconfig MP3309C entry order
- remove switch-on-delay-ms property
- remove optional gpio property to reset external devices
- remove dimming-mode property (the analog-i2c dimming mode is the default; the
presence of the pwms property, in DT, selects automatically the pwm dimming
mode)
- substitute three boolean properties, used for the overvoltage-protection
values, with a single enum property
- drop simple tracing messages
- use dev_err_probe() in probe function
- change device name from mp3309c_bl to the simple mp3309c
- remove shutdown function
v1:
- first version
MAINTAINERS | 6 +
drivers/video/backlight/Kconfig | 11 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/mp3309c.c | 395 ++
4 files changed, 413 insertions(+)
create mode 100644 drivers/video/backlight/mp3309c.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 3be1bdfe8ecc..f779df433af1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14333,6 +14333,12 @@ S: Maintained
F: Documentation/driver-api/tty/moxa-smartio.rst
F: drivers/tty/mxser.*
+MP3309C BACKLIGHT DRIVER
+M: Flavio Suligoi
+S: Maintained
+F: Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
+F: drivers/video/backlight/mp3309c.c
+
MR800 AVERMEDIA USB FM RADIO DRIVER
M: Alexey Klimov
L: linux-me...@vger.kernel.org
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 51387b1ef012..1144a54a35c0 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -402,6 +402,17 @@ config BACKLIGHT_LP8788
help
This supports TI LP8788 backlight driver.
+config BACKLIGHT_MP3309C
+ tristate "Backlight Driver for MPS MP3309C"
+ depends on I2C && PWM
+ select REGMAP_I2C
+ help
+ This supports MPS MP3309C backlight WLED driver in both PWM and
+ analog/I2C dimming modes.
+
+ To compile this driver as a module, choose M here: the module will
+ be called mp3309c.
+
config BACKLIGHT_PANDORA
tristate "Backlight driver for Pandora console"
depends on TWL4030_CORE
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index f72e1c3c59e9..1af583de665b 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_BACKLIGHT_LP855X)+= lp855x_bl.o
obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
obj-$(CONFIG_BACKLIGHT_LV5207LP) += lv5207lp.o
obj-$(CONFIG_BACKLIGHT_MAX8925)+= max8925_bl.o
+obj-$(CONFIG_BACKLIGHT_MP3309C)+= mp3309c.o
obj-$(CONFIG_BACKLIGHT_MT6370) += mt6370-backlight.o
obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
diff --git a/drivers/video/backlight/mp3309c.c
b/drivers/video/backlight/mp3309c.c
new file mode 100644
index ..470c960d7438
--- /dev/null
+++ b/drivers/video/backlight/mp3309c.c
@@ -0,0 +1,395 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for MPS MP3309C White LED driver with I2C interface
+ *
+ * Copyright (C) 2023 ASEM Srl
+ * Author: Flavio Suligoi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_I2C_0 0x00
+#define REG_I2C_1 0x01
+
+#define REG_I2C_0_EN 0x80
+#define REG_I2C_0_D0 0x40
+#define REG_I2C_0_D1 0x20
+#define REG_I2C_0_D2 0x10
+#define REG_I2C_0_D3 0x08
+#define REG_I2C_0_D4 0x04
+#define REG_I2C_0_RSRV10x02
+#define REG_I2C_0_RSRV20x01
+
+#define REG_I2C_1_RSRV10x80
+#define REG_I2C_1_DIMS 0x40
+#define REG_I2C_1_SYNC 0x20
+#define REG_I2C_1_OVP0 0x10
+#define REG_I2C_1_OVP1 0x08
+#define REG_I2C_1_VOS 0x04
+#define REG_I2C_1_LEDO 0x02
+#define REG_I2C_1_OTP 0x01
+
+#define ANALOG_MAX_VAL 31
+#define ANALOG_REG_MASK 0x7c
+
+enum mp3309c_status_value {
+ FIRST_POWER_ON,
+ BACKLIGHT_OFF,
+ BACKLIGHT_ON,
+};
+
+enum mp3309c_dimming_mode_value {
+ DIMMING_PWM,
+ DIMMING_ANALOG_I2C,
+};
+
+struct mp3309c_platform_data {
+ u32 max_brightness;
+ u32 default_brightness;
+ u8 dimming_mode;
+ u8 over_voltage_protection;
+ bool sync_mode;
+ u8 status;
+};
+
+struct mp3309c_chip {
+ struct device *dev;
+ struct mp3309c_platform_data
[PATCH v5 08/14] media: platform: mtk-mdp3: avoid multiple driver registrations
The amount of MDP3 driver probes is determined by the registered
clocks of MMSYS.
Since MT8195 MDP3 utilizes VPPSYS0 and VPPSYS1, it's necessary to
prevent multiple driver registrations.
Signed-off-by: Moudy Ho
---
drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c | 1 +
drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c | 8
drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h | 1 +
3 files changed, 10 insertions(+)
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index b7efdafb1620..8eac09f9d3dd 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -410,6 +410,7 @@ static const struct mdp_pipe_info mt8183_pipe_info[] = {
const struct mtk_mdp_driver_data mt8183_mdp_driver_data = {
.mdp_plat_id = MT8183,
+ .mdp_con_res = 0x14001000,
.mdp_probe_infra = mt8183_mdp_probe_infra,
.mdp_cfg = _plat_cfg,
.mdp_mutex_table_idx = mt8183_mutex_idx,
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
index 239f496b7a30..06b7d2b0b814 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
@@ -161,6 +161,7 @@ static int mdp_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct mdp_dev *mdp;
struct platform_device *mm_pdev, *mm2_pdev;
+ struct resource *res;
int ret, i, mutex_id;
mdp = kzalloc(sizeof(*mdp), GFP_KERNEL);
@@ -172,6 +173,12 @@ static int mdp_probe(struct platform_device *pdev)
mdp->pdev = pdev;
mdp->mdp_data = of_device_get_match_data(>dev);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res->start != mdp->mdp_data->mdp_con_res) {
+ platform_set_drvdata(pdev, mdp);
+ goto success_return;
+ }
+
mm_pdev = __get_pdev_by_id(pdev, NULL, MDP_INFRA_MMSYS);
if (IS_ERR_OR_NULL(mm_pdev)) {
ret = -ENODEV;
@@ -279,6 +286,7 @@ static int mdp_probe(struct platform_device *pdev)
goto err_unregister_device;
}
+success_return:
dev_dbg(dev, "mdp-%d registered successfully\n", pdev->id);
return 0;
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
index e4ffa25b9271..a063a655248c 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
@@ -61,6 +61,7 @@ enum mdp_pipe_id {
struct mtk_mdp_driver_data {
const int mdp_plat_id;
+ const resource_size_t mdp_con_res;
const struct of_device_id *mdp_probe_infra;
const struct mdp_platform_config *mdp_cfg;
const u32 *mdp_mutex_table_idx;
--
2.18.0
Re: [PATCH v5 3/3] dt-binding: mediatek: add MediaTek mt8195 MDP3 components
Hi Krzysztof, On Tue, 2023-09-12 at 10:19 +0200, Krzysztof Kozlowski wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 12/09/2023 09:56, Moudy Ho wrote: > > Introduce more MDP3 components present in MT8195. > > Please use subject prefixes matching the subsystem. You can get them > for > example with `git log --oneline -- DIRECTORY_OR_FILE` on the > directory > your patch is touching. > > > > > Signed-off-by: Moudy Ho > > --- > > .../display/mediatek/mediatek,aal.yaml| 2 +- > > .../display/mediatek/mediatek,color.yaml | 2 +- > > .../display/mediatek/mediatek,merge.yaml | 1 + > > .../display/mediatek/mediatek,ovl.yaml| 2 +- > > .../display/mediatek/mediatek,split.yaml | 1 + > > .../bindings/media/mediatek,mdp3-fg.yaml | 61 > +++ > > .../bindings/media/mediatek,mdp3-hdr.yaml | 60 > ++ > > .../bindings/media/mediatek,mdp3-pad.yaml | 61 > +++ > > .../bindings/media/mediatek,mdp3-rdma.yaml| 16 ++--- > > .../bindings/media/mediatek,mdp3-stitch.yaml | 61 > +++ > > .../bindings/media/mediatek,mdp3-tcc.yaml | 60 > ++ > > .../bindings/media/mediatek,mdp3-tdshp.yaml | 61 > +++ > > 12 files changed, 378 insertions(+), 10 deletions(-) > > create mode 100644 > Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml > > create mode 100644 > Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml > > create mode 100644 > Documentation/devicetree/bindings/media/mediatek,mdp3-pad.yaml > > create mode 100644 > Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml > > create mode 100644 > Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml > > create mode 100644 > Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml > > > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yam > l > b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yam > l > > index 7fd42c8fdc32..04b1314d00f2 100644 > > --- > a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yam > l > > +++ > b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yam > l > > @@ -24,6 +24,7 @@ properties: > >- enum: > >- mediatek,mt8173-disp-aal > >- mediatek,mt8183-disp-aal > > + - mediatek,mt8195-mdp3-aal > >- items: > >- enum: > >- mediatek,mt2712-disp-aal > > @@ -63,7 +64,6 @@ properties: > > required: > >- compatible > >- reg > > - - interrupts > > Why? commit msg tells nothing about it. Why interrupt is not erquired > in > mt8173? How dropping such requirement is anyhow related to mt8195? > > The signals of the MDP engines are completely controlled by MTK's MUTEX for starting and stopping frame processing, eliminating the need for additional interrupts. Considering the discussion in the previous version, it is advisable to merge it into the existing display binding files. Therefore, I tried removing the required conditions to facilitate file merging. However, for file integrity purposes, I should revert these changes and set the corresponding settings in DTS(even if they are not used). The other YAML files - color, merge and ovl - mentioned below will also be rectified in the next version. > >- power-domains > >- clocks > > > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.y > aml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.y > aml > > index f21e44092043..8e97b0a6a7b3 100644 > > --- > a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.y > aml > > +++ > b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.y > aml > > @@ -26,6 +26,7 @@ properties: > >- mediatek,mt2701-disp-color > >- mediatek,mt8167-disp-color > >- mediatek,mt8173-disp-color > > + - mediatek,mt8195-mdp3-color > >- items: > >- enum: > >- mediatek,mt7623-disp-color > > @@ -66,7 +67,6 @@ properties: > > required: > >- compatible > >- reg > > - - interrupts > > Why? > > >- power-domains > >- clocks > > > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.y > aml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.y > aml > > index eead5cb8636e..401498523404 100644 > > --- > a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.y > aml > > +++ > b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.y > aml > > @@ -24,6 +24,7 @@ properties: > >- enum: > >- mediatek,mt8173-disp-merge > >- mediatek,mt8195-disp-merge > > + - mediatek,mt8195-mdp3-merge > >- items: > >- const: mediatek,mt6795-disp-merge
Re: [RFC PATCH 5/8] drm/panel: nv3052c: Allow specifying registers per panel
On Wed, Sep 13, 2023 at 02:34:38PM -0700, Jessica Zhang wrote: > Hi John, > > Having a separate panel_regs_len field seems a bit unnecessary to me. > > Looks like it's only being called in the panel prepare() and I don't seen > any reason why we shouldn't just call the ARRAY_SIZE() macro there. Can you call ARRAY_SIZE on an an array pointer? > > Thanks, > > Jessica Zhang John.
[PATCH v2 1/2] dt-bindings: backlight: Add MPS MP3309C
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
programmable switching frequency to optimize efficiency.
The brightness can be controlled either by I2C commands (called "analog"
mode) or by a PWM input signal (PWM mode).
This driver supports both modes.
For device driver details, please refer to:
- drivers/video/backlight/mp3309c_bl.c
The datasheet is available at:
- https://www.monolithicpower.com/en/mp3309c.html
Signed-off-by: Flavio Suligoi
---
v2:
- remove useless properties (dimming-mode, pinctrl-names, pinctrl-0,
switch-on-delay-ms, switch-off-delay-ms, reset-gpios, reset-on-delay-ms,
reset-on-length-ms)
- add common.yaml#
- remove already included properties (default-brightness, max-brightness)
- substitute three boolean properties, used for the overvoltage-protection
values, with a single enum property
- remove some conditional definitions
- remove the 2nd example
v1:
- first version
.../bindings/leds/backlight/mps,mp3309c.yaml | 73 +++
1 file changed, 73 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
diff --git a/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
new file mode 100644
index ..99ccdba2c08f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/mps,mp3309c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MPS MP3309C backlight
+
+maintainers:
+ - Flavio Suligoi
+
+description: |
+ The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
+ programmable switching frequency to optimize efficiency.
+ It supports two different dimming modes:
+
+ - analog mode, via I2C commands (default)
+ - PWM controlled mode.
+
+ The datasheet is available at:
+ https://www.monolithicpower.com/en/mp3309c.html
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+const: mps,mp3309c
+
+ reg:
+maxItems: 1
+
+ pwms:
+description: if present, the backlight is controlled in PWM mode.
+maxItems: 1
+
+ enable-gpios:
+description: GPIO used to enable the backlight in "analog-i2c" dimming
mode.
+maxItems: 1
+
+ mps,overvoltage-protection-microvolt:
+description: Overvoltage protection (13.5V, 24V or 35.5V). If missing, the
+ hardware default of 35.5V is used.
+enum: [ 1350, 2400, 3550 ]
+
+ mps,no-sync-mode:
+description: disable synchronous rectification mode
+type: boolean
+
+required:
+ - compatible
+ - reg
+ - max-brightness
+ - default-brightness
+
+unevaluatedProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+/* Backlight with PWM control */
+backlight_pwm: backlight@17 {
+compatible = "mps,mp3309c-backlight";
+reg = <0x17>;
+pwms = < 0 333 0>; /* 300 Hz --> (1/f) * 1*10^9 */
+max-brightness = <100>;
+default-brightness = <80>;
+overvoltage-protection-microvolt = <2400>;
+};
+};
--
2.34.1
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bit.c and bus.c with a series of the non-existing config "NOUVEAU_I2C_INTERNAL"
In the source files drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bit.c:26 and drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c:214 refer to configuration options "CONFIG_NOUVEAU_I2C_INTERNAL" and "CONFIG_NOUVEAU_I2C_INTERNAL_DEFAULT" for conditional compilation, but these configuration options are not defined in any kconfig files, which means the "#ifdef CONFIG_NOUVEAU_I2C_INTERNAL_xxx" condition contains dead code. Do these configuration options need to be retained and added later? Or can we simply drop the dead code? Best regards, Yanjie Ren Ying Sun
[PATCH v5 12/14] media: platform: mtk-mdp3: add mt8195 shared memory configurations
The configuration of the MT8195 components in the shared memory
is defined in the header file "mdp_sm_mt8195.h".
Signed-off-by: Moudy Ho
---
.../platform/mediatek/mdp3/mdp_sm_mt8195.h| 283 ++
.../platform/mediatek/mdp3/mtk-img-ipi.h | 4 +
2 files changed, 287 insertions(+)
create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h
b/drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h
new file mode 100644
index ..b09f48222d24
--- /dev/null
+++ b/drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h
@@ -0,0 +1,283 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Ping-Hsun Wu
+ */
+
+#ifndef __MDP_SM_MT8195_H__
+#define __MDP_SM_MT8195_H__
+
+#include "mtk-mdp3-type.h"
+
+/*
+ * ISP-MDP generic output information
+ * MD5 of the target SCP prebuild:
+ * a49ec487e458b5971880f1b63dc2a9d5
+ */
+
+#define IMG_MAX_SUBFRAMES_8195 20
+
+struct img_comp_frame_8195 {
+ u32 output_disable;
+ u32 bypass;
+ u32 in_width;
+ u32 in_height;
+ u32 out_width;
+ u32 out_height;
+ struct img_crop crop;
+ u32 in_total_width;
+ u32 out_total_width;
+} __packed;
+
+struct img_comp_subfrm_8195 {
+ u32 tile_disable;
+ struct img_region in;
+ struct img_region out;
+ struct img_offset luma;
+ struct img_offset chroma;
+ s32 out_vertical; /* Output vertical index */
+ s32 out_horizontal; /* Output horizontal index */
+} __packed;
+
+struct mdp_rdma_subfrm_8195 {
+ u32 offset[IMG_MAX_PLANES];
+ u32 offset_0_p;
+ u32 src;
+ u32 clip;
+ u32 clip_ofst;
+ u32 in_tile_xleft;
+ u32 in_tile_ytop;
+} __packed;
+
+struct mdp_rdma_data_8195 {
+ u32 src_ctrl;
+ u32 comp_ctrl;
+ u32 control;
+ u32 iova[IMG_MAX_PLANES];
+ u32 iova_end[IMG_MAX_PLANES];
+ u32 mf_bkgd;
+ u32 mf_bkgd_in_pxl;
+ u32 sf_bkgd;
+ u32 ufo_dec_y;
+ u32 ufo_dec_c;
+ u32 transform;
+ u32 dmabuf_con0;
+ u32 ultra_th_high_con0;
+ u32 ultra_th_low_con0;
+ u32 dmabuf_con1;
+ u32 ultra_th_high_con1;
+ u32 ultra_th_low_con1;
+ u32 dmabuf_con2;
+ u32 ultra_th_high_con2;
+ u32 ultra_th_low_con2;
+ u32 dmabuf_con3;
+ struct mdp_rdma_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_fg_subfrm_8195 {
+ u32 info_0;
+ u32 info_1;
+} __packed;
+
+struct mdp_fg_data_8195 {
+ u32 ctrl_0;
+ u32 ck_en;
+ struct mdp_fg_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_hdr_subfrm_8195 {
+ u32 win_size;
+ u32 src;
+ u32 clip_ofst0;
+ u32 clip_ofst1;
+ u32 hist_ctrl_0;
+ u32 hist_ctrl_1;
+ u32 hdr_top;
+ u32 hist_addr;
+} __packed;
+
+struct mdp_hdr_data_8195 {
+ u32 top;
+ u32 relay;
+ struct mdp_hdr_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_aal_subfrm_8195 {
+ u32 src;
+ u32 clip;
+ u32 clip_ofst;
+} __packed;
+
+struct mdp_aal_data_8195 {
+ u32 cfg_main;
+ u32 cfg;
+ struct mdp_aal_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_rsz_subfrm_8195 {
+ u32 control2;
+ u32 src;
+ u32 clip;
+ u32 hdmirx_en;
+ u32 luma_h_int_ofst;
+ u32 luma_h_sub_ofst;
+ u32 luma_v_int_ofst;
+ u32 luma_v_sub_ofst;
+ u32 chroma_h_int_ofst;
+ u32 chroma_h_sub_ofst;
+ u32 rsz_switch;
+ u32 merge_cfg;
+} __packed;
+
+struct mdp_rsz_data_8195 {
+ u32 coeff_step_x;
+ u32 coeff_step_y;
+ u32 control1;
+ u32 control2;
+ u32 etc_control;
+ u32 prz_enable;
+ u32 ibse_softclip;
+ u32 tap_adapt;
+ u32 ibse_gaincontrol1;
+ u32 ibse_gaincontrol2;
+ u32 ibse_ylevel_1;
+ u32 ibse_ylevel_2;
+ u32 ibse_ylevel_3;
+ u32 ibse_ylevel_4;
+ u32 ibse_ylevel_5;
+ struct mdp_rsz_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_tdshp_subfrm_8195 {
+ u32 src;
+ u32 clip;
+ u32 clip_ofst;
+ u32 hist_cfg_0;
+ u32 hist_cfg_1;
+} __packed;
+
+struct mdp_tdshp_data_8195 {
+ u32 cfg;
+ struct mdp_tdshp_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_color_subfrm_8195 {
+ u32 in_hsize;
+ u32 in_vsize;
+} __packed;
+
+struct mdp_color_data_8195 {
+ u32 start;
+ struct mdp_color_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_ovl_subfrm_8195 {
+ u32 L0_src_size;
+ u32 roi_size;
+} __packed;
+
+struct mdp_ovl_data_8195 {
+ u32 L0_con;
+ u32 src_con;
+ struct mdp_ovl_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_pad_subfrm_8195 {
[PATCH v5 04/14] media: platform: mtk-mdp3: add support second sets of MUTEX
After setting up the second set of MMSYS (VPPSYS1), it is necessary
to have a corresponding second set of MUTEX (MUTEX2) to assist in
handling SOF/EOF.
Signed-off-by: Moudy Ho
---
.../platform/mediatek/mdp3/mtk-mdp3-cmdq.c| 64 ---
.../platform/mediatek/mdp3/mtk-mdp3-core.c| 34 --
.../platform/mediatek/mdp3/mtk-mdp3-core.h| 2 +
3 files changed, 70 insertions(+), 30 deletions(-)
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index 3177592490be..606651687465 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -44,15 +44,28 @@ static bool is_output_disabled(int p_id, const struct
img_compparam *param, u32
return (count < num) ? (dis_output || dis_tile) : true;
}
+static struct mtk_mutex *__get_mutex(const struct mdp_dev *mdp_dev,
+const struct mdp_pipe_info *p)
+{
+ struct mtk_mutex *m;
+
+ if (p->mmsys_id)
+ m = mdp_dev->mdp_mutex2[p->mutex_id];
+ else
+ m = mdp_dev->mdp_mutex[p->mutex_id];
+
+ return m;
+}
+
static int mdp_path_subfrm_require(const struct mdp_path *path,
struct mdp_cmdq_cmd *cmd,
- s32 *mutex_id, u32 count)
+ struct mdp_pipe_info *p, u32 count)
{
const int p_id = path->mdp_dev->mdp_data->mdp_plat_id;
const struct mdp_comp_ctx *ctx;
const struct mtk_mdp_driver_data *data = path->mdp_dev->mdp_data;
struct device *dev = >mdp_dev->pdev->dev;
- struct mtk_mutex **mutex = path->mdp_dev->mdp_mutex;
+ struct mtk_mutex *mutex;
int id, index;
u32 num_comp = 0;
@@ -77,7 +90,8 @@ static int mdp_path_subfrm_require(const struct mdp_path
*path,
dev_err(dev, "Unknown pipeline and no mutex is assigned");
return -EINVAL;
}
- *mutex_id = data->pipe_info[index].mutex_id;
+ memcpy(p, >pipe_info[index], sizeof(struct mdp_pipe_info));
+ mutex = __get_mutex(path->mdp_dev, p);
/* Set mutex mod */
for (index = 0; index < num_comp; index++) {
@@ -85,29 +99,28 @@ static int mdp_path_subfrm_require(const struct mdp_path
*path,
if (is_output_disabled(p_id, ctx->param, count))
continue;
id = ctx->comp->public_id;
- mtk_mutex_write_mod(mutex[*mutex_id],
- data->mdp_mutex_table_idx[id], false);
+ mtk_mutex_write_mod(mutex, data->mdp_mutex_table_idx[id],
false);
+
}
- mtk_mutex_write_sof(mutex[*mutex_id],
- MUTEX_SOF_IDX_SINGLE_MODE);
+ mtk_mutex_write_sof(mutex, MUTEX_SOF_IDX_SINGLE_MODE);
return 0;
}
static int mdp_path_subfrm_run(const struct mdp_path *path,
struct mdp_cmdq_cmd *cmd,
- s32 *mutex_id, u32 count)
+ struct mdp_pipe_info *p, u32 count)
{
const int p_id = path->mdp_dev->mdp_data->mdp_plat_id;
const struct mdp_comp_ctx *ctx;
struct device *dev = >mdp_dev->pdev->dev;
- struct mtk_mutex **mutex = path->mdp_dev->mdp_mutex;
+ struct mtk_mutex *mutex;
int index;
u32 num_comp = 0;
s32 event;
- if (-1 == *mutex_id) {
+ if (-1 == p->mutex_id) {
dev_err(dev, "Incorrect mutex id");
return -EINVAL;
}
@@ -127,7 +140,8 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
}
/* Enable the mutex */
- mtk_mutex_enable_by_cmdq(mutex[*mutex_id], (void *)>pkt);
+ mutex = __get_mutex(path->mdp_dev, p);
+ mtk_mutex_enable_by_cmdq(mutex, (void *)>pkt);
/* Wait SOF events and clear mutex modules (optional) */
for (index = 0; index < num_comp; index++) {
@@ -174,7 +188,7 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
const struct img_mmsys_ctrl *ctrl = NULL;
const struct img_mux *set;
struct mdp_comp_ctx *ctx;
- s32 mutex_id;
+ struct mdp_pipe_info pipe;
int index, ret;
u32 num_comp = 0;
@@ -185,7 +199,7 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
ctrl = CFG_ADDR(MT8183, path->config, ctrls[count]);
/* Acquire components */
- ret = mdp_path_subfrm_require(path, cmd, _id, count);
+ ret = mdp_path_subfrm_require(path, cmd, , count);
if (ret)
return ret;
/* Enable mux settings */
@@ -204,7 +218,7 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
return ret;
}
/* Run components */
- ret = mdp_path_subfrm_run(path, cmd, _id, count);
+ ret =
[PATCH] drm/tests: provide exit function
Similarly to the drm_exec_test module, the drm_modes_test shows the following output on dmesg on load: [ 5556.674834] KTAP version 1 [ 5556.674841] 1..1 [ 5556.675317] KTAP version 1 [ 5556.675321] # Subtest: drm_modes_analog_tv [ 5556.675323] # module: drm_modes_test [ 5556.675327] 1..4 [ 5556.683731] == [ 5556.683777] BUG: KASAN: slab-use-after-free in drm_dev_put.part.0+0x4b/0x90 [drm] [ 5556.683882] Read of size 8 at addr 88812db30428 by task kunit_try_catch/75921 [ 5556.683882] [ 5556.683882] CPU: 1 PID: 75921 Comm: kunit_try_catch Tainted: GW N 6.6.0-rc1-dirty #2 [ 5556.683882] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 5556.683882] Call Trace: [ 5556.683882] [ 5556.683882] dump_stack_lvl+0x43/0x60 [ 5556.683882] print_report+0xcf/0x660 [ 5556.683882] ? __virt_addr_valid+0xd9/0x160 [ 5556.683882] ? drm_dev_put.part.0+0x4b/0x90 [drm] [ 5556.683882] kasan_report+0xda/0x110 [ 5556.683882] ? drm_dev_put.part.0+0x4b/0x90 [drm] [ 5556.683882] drm_dev_put.part.0+0x4b/0x90 [drm] [ 5556.683882] release_nodes+0x83/0x160 [ 5556.683882] devres_release_all+0xe6/0x130 [ 5556.683882] ? __pfx_devres_release_all+0x10/0x10 [ 5556.683882] ? mutex_unlock+0x80/0xd0 [ 5556.683882] ? __pfx_mutex_unlock+0x10/0x10 [ 5556.683882] device_unbind_cleanup+0x16/0xc0 [ 5556.683882] device_release_driver_internal+0x28b/0x2e0 [ 5556.683882] bus_remove_device+0x124/0x1d0 [ 5556.683882] device_del+0x23d/0x580 [ 5556.683882] ? __pfx_device_del+0x10/0x10 [ 5556.683882] ? kasan_set_track+0x21/0x30 [ 5556.683882] ? _raw_spin_lock_irqsave+0x98/0xf0 [ 5556.683882] platform_device_del.part.0+0x19/0xe0 [ 5556.683882] kunit_remove_resource+0xfa/0x140 [kunit] [ 5556.683882] kunit_cleanup+0x47/0xa0 [kunit] [ 5556.683882] ? __pfx_kunit_try_run_case_cleanup+0x10/0x10 [kunit] [ 5556.683882] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] [ 5556.683882] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] [ 5556.683882] kthread+0x184/0x1c0 [ 5556.683882] ? __pfx_kthread+0x10/0x10 [ 5556.683882] ret_from_fork+0x30/0x50 [ 5556.683882] ? __pfx_kthread+0x10/0x10 [ 5556.683882] ret_from_fork_asm+0x1b/0x30 [ 5556.683882] [ 5556.683882] [ 5556.683882] Allocated by task 75920: [ 5556.683882] kasan_save_stack+0x2f/0x50 [ 5556.683882] kasan_set_track+0x21/0x30 [ 5556.683882] __kasan_kmalloc+0xa6/0xb0 [ 5556.683882] __kmalloc+0x5d/0x160 [ 5556.683882] kunit_kmalloc_array+0x1c/0x50 [kunit] [ 5556.683882] drm_test_modes_init+0xda/0x260 [drm_modes_test] [ 5556.683882] kunit_try_run_case+0x6e/0x100 [kunit] [ 5556.683882] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] [ 5556.683882] kthread+0x184/0x1c0 [ 5556.683882] ret_from_fork+0x30/0x50 [ 5556.683882] ret_from_fork_asm+0x1b/0x30 [ 5556.683882] [ 5556.683882] Freed by task 75921: [ 5556.683882] kasan_save_stack+0x2f/0x50 [ 5556.683882] kasan_set_track+0x21/0x30 [ 5556.683882] kasan_save_free_info+0x27/0x40 [ 5556.683882] kasan_slab_free+0x166/0x1c0 [ 5556.683882] slab_free_freelist_hook+0x9f/0x1e0 [ 5556.683882] __kmem_cache_free+0x187/0x2d0 [ 5556.683882] kunit_remove_resource+0xfa/0x140 [kunit] [ 5556.683882] kunit_cleanup+0x47/0xa0 [kunit] [ 5556.683882] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] [ 5556.683882] kthread+0x184/0x1c0 [ 5556.683882] ret_from_fork+0x30/0x50 [ 5556.683882] ret_from_fork_asm+0x1b/0x30 [ 5556.683882] [ 5556.683882] The buggy address belongs to the object at 88812db30400 [ 5556.683882] which belongs to the cache kmalloc-256 of size 256 [ 5556.683882] The buggy address is located 40 bytes inside of [ 5556.683882] freed 256-byte region [88812db30400, 88812db30500) [ 5556.683882] [ 5556.683882] The buggy address belongs to the physical page: [ 5556.683882] page:b3a5f157 refcount:1 mapcount:0 mapping: index:0x0 pfn:0x12db30 [ 5556.683882] head:b3a5f157 order:2 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 5556.683882] ksm flags: 0x17c840(slab|head|node=0|zone=2|lastcpupid=0x1f) [ 5556.683882] page_type: 0x() [ 5556.683882] raw: 0017c840 888100042b40 ea00053e2000 dead0003 [ 5556.683882] raw: 80200020 0001 [ 5556.683882] page dumped because: kasan: bad access detected [ 5556.683882] [ 5556.683882] Memory state around the buggy address: [ 5556.683882] 88812db30300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 5556.683882] 88812db30380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 5556.683882] >88812db30400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 5556.683882] ^ [ 5556.683882] 88812db30480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 5556.683882] 88812db30500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 5556.683882]
[PATCH v5 0/3] introduce more MDP3 components in mt8195
Changes since v4: - Rebase on v6.6-rc1 - Organize identical hardware components into their respective files. Hi, The purpose of this patch is to separate the MDP3-related bindings from the original mailing list mentioned below: https://lore.kernel.org/all/20230208092209.19472-1-moudy...@mediatek.com/ Those binding files describe additional components that are present in the mt8195. Moudy Ho (3): dt-binding: mediatek: correct MDP3 node with generic names dt-binding: mediatek: integrate MDP RDMA to one binding dt-binding: mediatek: add MediaTek mt8195 MDP3 components .../display/mediatek/mediatek,aal.yaml| 2 +- .../display/mediatek/mediatek,color.yaml | 2 +- .../display/mediatek/mediatek,mdp-rdma.yaml | 88 --- .../display/mediatek/mediatek,merge.yaml | 1 + .../display/mediatek/mediatek,ovl.yaml| 2 +- .../display/mediatek/mediatek,split.yaml | 1 + .../bindings/media/mediatek,mdp3-fg.yaml | 61 + .../bindings/media/mediatek,mdp3-hdr.yaml | 60 + .../bindings/media/mediatek,mdp3-pad.yaml | 61 + .../bindings/media/mediatek,mdp3-rdma.yaml| 50 ++- .../bindings/media/mediatek,mdp3-stitch.yaml | 61 + .../bindings/media/mediatek,mdp3-tcc.yaml | 60 + .../bindings/media/mediatek,mdp3-tdshp.yaml | 61 + .../bindings/media/mediatek,mdp3-wrot.yaml| 23 +++-- 14 files changed, 412 insertions(+), 121 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-pad.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml -- 2.18.0
Re: [PATCH v5 03/14] media: platform: mtk-mdp3: add support second sets of MMSYS
Hi Angelo,
On Tue, 2023-09-12 at 11:18 +0200, AngeloGioacchino Del Regno wrote:
> Il 12/09/23 09:57, Moudy Ho ha scritto:
> > MT8195 has two MMSYS sets, VPPSYS0 and VPPSYS1.
> > These sets coordinate and control the clock, power, and
> > register settings needed for the components of MDP3.
> >
> > Signed-off-by: Moudy Ho
> > ---
> > .../platform/mediatek/mdp3/mdp_cfg_data.c | 44 +-
> > -
> > .../platform/mediatek/mdp3/mtk-mdp3-comp.h| 1 +
> > .../platform/mediatek/mdp3/mtk-mdp3-core.c| 40 +++---
> > ---
> > .../platform/mediatek/mdp3/mtk-mdp3-core.h| 3 ++
> > 4 files changed, 53 insertions(+), 35 deletions(-)
(snip)
> > diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
> > b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
> > index cc44be10fdb7..9c33d3aaf9cd 100644
> > --- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
> > +++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
> > @@ -26,39 +26,45 @@ static const struct of_device_id mdp_of_ids[] =
> > {
> > MODULE_DEVICE_TABLE(of, mdp_of_ids);
> >
> > static struct platform_device *__get_pdev_by_id(struct
> > platform_device *pdev,
> > + struct platform_device
> > *from,
> > enum mdp_infra_id id)
> > {
> > - struct device_node *node;
> > + struct device_node *node, *f = NULL;
> > struct platform_device *mdp_pdev = NULL;
> > const struct mtk_mdp_driver_data *mdp_data;
> > const char *compat;
> >
> > if (!pdev)
> > - return NULL;
> > + return ERR_PTR(-ENODEV);
> >
>
> Fixing the error handling shall be done in a different commit, which
> shall also
> have a Fixes tag: this is both for backporting purposes and because
> those fixes
> are not relevant to adding support for secondary sets of MMSYS (so,
> those are
> not relevant for this specific commit).
>
Thanks forreminding me. I will address this error handing separately in
a dedicated fix patch.
> > if (id < MDP_INFRA_MMSYS || id >= MDP_INFRA_MAX) {
> > dev_err(>dev, "Illegal infra id %d\n", id);
> > - return NULL;
> > + return ERR_PTR(-ENODEV);
> > }
> >
> > mdp_data = of_device_get_match_data(>dev);
> > if (!mdp_data) {
> > dev_err(>dev, "have no driver data to find
> > node\n");
> > - return NULL;
> > + return ERR_PTR(-ENODEV);
> > }
> > +
> > compat = mdp_data->mdp_probe_infra[id].compatible;
> > + if (strlen(compat) == 0)
> > + return NULL;
> >
> > - node = of_find_compatible_node(NULL, NULL, compat);
> > + if (from)
> > + f = from->dev.of_node;
> > + node = of_find_compatible_node(f, NULL, compat);
> > if (WARN_ON(!node)) {
> > dev_err(>dev, "find node from id %d failed\n",
> > id);
> > - return NULL;
> > + return ERR_PTR(-ENODEV);
> > }
> >
> > mdp_pdev = of_find_device_by_node(node);
> > of_node_put(node);
> > if (WARN_ON(!mdp_pdev)) {
> > dev_err(>dev, "find pdev from id %d failed\n",
> > id);
> > - return NULL;
> > + return ERR_PTR(-ENODEV);
> > }
> >
> > return mdp_pdev;
> > @@ -152,7 +158,7 @@ static int mdp_probe(struct platform_device
> > *pdev)
> > {
> > struct device *dev = >dev;
> > struct mdp_dev *mdp;
> > - struct platform_device *mm_pdev;
> > + struct platform_device *mm_pdev, *mm2_pdev;
> > int ret, i, mutex_id;
> >
> > mdp = kzalloc(sizeof(*mdp), GFP_KERNEL);
> > @@ -164,15 +170,23 @@ static int mdp_probe(struct platform_device
> > *pdev)
> > mdp->pdev = pdev;
> > mdp->mdp_data = of_device_get_match_data(>dev);
> >
> > - mm_pdev = __get_pdev_by_id(pdev, MDP_INFRA_MMSYS);
> > - if (!mm_pdev) {
> > + mm_pdev = __get_pdev_by_id(pdev, NULL, MDP_INFRA_MMSYS);
> > + if (IS_ERR_OR_NULL(mm_pdev)) {
> > ret = -ENODEV;
> > goto err_destroy_device;
> > }
> > mdp->mdp_mmsys = _pdev->dev;
> >
> > - mm_pdev = __get_pdev_by_id(pdev, MDP_INFRA_MUTEX);
> > - if (WARN_ON(!mm_pdev)) {
> > + /* MMSYS2 is not available on all chips, so the config may be
> > null. */
> > + mm2_pdev = __get_pdev_by_id(pdev, mm_pdev, MDP_INFRA_MMSYS2);
> > + if (IS_ERR(mm2_pdev)) {
> > + ret = PTR_ERR(mm2_pdev);
> > + goto err_destroy_device;
> > + }
> > + mdp->mdp_mmsys2 = _pdev->dev;
> > +
> > + mm_pdev = __get_pdev_by_id(pdev, NULL, MDP_INFRA_MUTEX);
> > + if (IS_ERR_OR_NULL(mm_pdev)) {
> > ret = -ENODEV;
> > goto err_destroy_device;
> > }
> > @@ -208,7 +222,7 @@ static int mdp_probe(struct platform_device
> > *pdev)
> > goto err_destroy_job_wq;
> > }
> >
> > - mm_pdev = __get_pdev_by_id(pdev, MDP_INFRA_SCP);
> > + mm_pdev = __get_pdev_by_id(pdev, NULL, MDP_INFRA_SCP);
> > if (WARN_ON(!mm_pdev)) {
> >
[PATCH v5 2/3] dt-binding: mediatek: integrate MDP RDMA to one binding
Due to the same hardware design, MDP RDMA needs to
be integrated into the same binding.
Signed-off-by: Moudy Ho
---
.../display/mediatek/mediatek,mdp-rdma.yaml | 88 ---
.../bindings/media/mediatek,mdp3-rdma.yaml| 5 +-
2 files changed, 3 insertions(+), 90 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
deleted file mode 100644
index dd12e2ff685c..
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
+++ /dev/null
@@ -1,88 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
-$id: http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: MediaTek MDP RDMA
-
-maintainers:
- - Chun-Kuang Hu
- - Philipp Zabel
-
-description:
- The MediaTek MDP RDMA stands for Read Direct Memory Access.
- It provides real time data to the back-end panel driver, such as DSI,
- DPI and DP_INTF.
- It contains one line buffer to store the sufficient pixel data.
- RDMA device node must be siblings to the central MMSYS_CONFIG node.
- For a description of the MMSYS_CONFIG binding, see
- Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for
details.
-
-properties:
- compatible:
-const: mediatek,mt8195-vdo1-rdma
-
- reg:
-maxItems: 1
-
- interrupts:
-maxItems: 1
-
- power-domains:
-maxItems: 1
-
- clocks:
-items:
- - description: RDMA Clock
-
- iommus:
-maxItems: 1
-
- mediatek,gce-client-reg:
-description:
- The register of display function block to be set by gce. There are 4
arguments,
- such as gce node, subsys id, offset and register size. The subsys id
that is
- mapping to the register of display function blocks is defined in the gce
header
- include/dt-bindings/gce/-gce.h of each chips.
-$ref: /schemas/types.yaml#/definitions/phandle-array
-items:
- items:
-- description: phandle of GCE
-- description: GCE subsys id
-- description: register offset
-- description: register size
-maxItems: 1
-
-required:
- - compatible
- - reg
- - power-domains
- - clocks
- - iommus
- - mediatek,gce-client-reg
-
-additionalProperties: false
-
-examples:
- - |
-#include
-#include
-#include
-#include
-#include
-
-soc {
-#address-cells = <2>;
-#size-cells = <2>;
-
-rdma@1c104000 {
-compatible = "mediatek,mt8195-vdo1-rdma";
-reg = <0 0x1c104000 0 0x1000>;
-interrupts = ;
-clocks = < CLK_VDO1_MDP_RDMA0>;
-power-domains = < MT8195_POWER_DOMAIN_VDOSYS1>;
-iommus = <_vdo M4U_PORT_L2_MDP_RDMA0>;
-mediatek,gce-client-reg = < SUBSYS_1c10 0x4000 0x1000>;
-};
-};
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
index 3e128733ef53..0c22571d8c22 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -20,8 +20,9 @@ description: |
properties:
compatible:
-items:
- - const: mediatek,mt8183-mdp3-rdma
+enum:
+ - mediatek,mt8183-mdp3-rdma
+ - mediatek,mt8195-vdo1-rdma
reg:
maxItems: 1
--
2.18.0
Re: [RFC PATCH 8/8] dt-bindings: display: panel: add Fascontek FS035VG158 panel
On Tue, Sep 12, 2023 at 08:55:31AM +0200, Krzysztof Kozlowski wrote: > On 11/09/2023 18:47, John Watts wrote: > > On Mon, Sep 11, 2023 at 01:49:39PM +0200, Krzysztof Kozlowski wrote: > >> If the other panel has exactly the same case, then yes, you can do like > >> this. But it depends on the bindings - to which ones do you refer as > >> your tmeplate? > > > > Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml > > The file is indeed serving as poor example. I'm happy to fix it up according to your response and include it in v2 of the RFC. Should this be split in to two RFCs- one for cleanup, one for the new panel? > > Best regards, > Krzysztof > John.
[PATCH v5 03/14] media: platform: mtk-mdp3: add support second sets of MMSYS
MT8195 has two MMSYS sets, VPPSYS0 and VPPSYS1.
These sets coordinate and control the clock, power, and
register settings needed for the components of MDP3.
Signed-off-by: Moudy Ho
---
.../platform/mediatek/mdp3/mdp_cfg_data.c | 44 +--
.../platform/mediatek/mdp3/mtk-mdp3-comp.h| 1 +
.../platform/mediatek/mdp3/mtk-mdp3-core.c| 40 +++--
.../platform/mediatek/mdp3/mtk-mdp3-core.h| 3 ++
4 files changed, 53 insertions(+), 35 deletions(-)
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index 502eeae0bfdc..58792902abb5 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -73,75 +73,75 @@ static const u32 mt8183_mutex_idx[MDP_MAX_COMP_COUNT] = {
static const struct mdp_comp_data mt8183_mdp_comp_data[MDP_MAX_COMP_COUNT] = {
[MDP_COMP_WPEI] = {
- {MDP_COMP_TYPE_WPEI, 0, MT8183_MDP_COMP_WPEI},
+ {MDP_COMP_TYPE_WPEI, 0, MT8183_MDP_COMP_WPEI, 0},
{0, 0, 0}
},
[MDP_COMP_WPEO] = {
- {MDP_COMP_TYPE_EXTO, 2, MT8183_MDP_COMP_WPEO},
+ {MDP_COMP_TYPE_EXTO, 2, MT8183_MDP_COMP_WPEO, 0},
{0, 0, 0}
},
[MDP_COMP_WPEI2] = {
- {MDP_COMP_TYPE_WPEI, 1, MT8183_MDP_COMP_WPEI2},
+ {MDP_COMP_TYPE_WPEI, 1, MT8183_MDP_COMP_WPEI2, 0},
{0, 0, 0}
},
[MDP_COMP_WPEO2] = {
- {MDP_COMP_TYPE_EXTO, 3, MT8183_MDP_COMP_WPEO2},
+ {MDP_COMP_TYPE_EXTO, 3, MT8183_MDP_COMP_WPEO2, 0},
{0, 0, 0}
},
[MDP_COMP_ISP_IMGI] = {
- {MDP_COMP_TYPE_IMGI, 0, MT8183_MDP_COMP_ISP_IMGI},
+ {MDP_COMP_TYPE_IMGI, 0, MT8183_MDP_COMP_ISP_IMGI, 0},
{0, 0, 4}
},
[MDP_COMP_ISP_IMGO] = {
- {MDP_COMP_TYPE_EXTO, 0, MT8183_MDP_COMP_ISP_IMGO},
+ {MDP_COMP_TYPE_EXTO, 0, MT8183_MDP_COMP_ISP_IMGO, 0},
{0, 0, 4}
},
[MDP_COMP_ISP_IMG2O] = {
- {MDP_COMP_TYPE_EXTO, 1, MT8183_MDP_COMP_ISP_IMG2O},
+ {MDP_COMP_TYPE_EXTO, 1, MT8183_MDP_COMP_ISP_IMG2O, 0},
{0, 0, 0}
},
[MDP_COMP_CAMIN] = {
- {MDP_COMP_TYPE_DL_PATH, 0, MT8183_MDP_COMP_CAMIN},
+ {MDP_COMP_TYPE_DL_PATH, 0, MT8183_MDP_COMP_CAMIN, 0},
{2, 2, 1}
},
[MDP_COMP_CAMIN2] = {
- {MDP_COMP_TYPE_DL_PATH, 1, MT8183_MDP_COMP_CAMIN2},
+ {MDP_COMP_TYPE_DL_PATH, 1, MT8183_MDP_COMP_CAMIN2, 0},
{2, 4, 1}
},
[MDP_COMP_RDMA0] = {
- {MDP_COMP_TYPE_RDMA, 0, MT8183_MDP_COMP_RDMA0},
+ {MDP_COMP_TYPE_RDMA, 0, MT8183_MDP_COMP_RDMA0, 0},
{2, 0, 0}
},
[MDP_COMP_CCORR0] = {
- {MDP_COMP_TYPE_CCORR, 0, MT8183_MDP_COMP_CCORR0},
+ {MDP_COMP_TYPE_CCORR, 0, MT8183_MDP_COMP_CCORR0, 0},
{1, 0, 0}
},
[MDP_COMP_RSZ0] = {
- {MDP_COMP_TYPE_RSZ, 0, MT8183_MDP_COMP_RSZ0},
+ {MDP_COMP_TYPE_RSZ, 0, MT8183_MDP_COMP_RSZ0, 0},
{1, 0, 0}
},
[MDP_COMP_RSZ1] = {
- {MDP_COMP_TYPE_RSZ, 1, MT8183_MDP_COMP_RSZ1},
+ {MDP_COMP_TYPE_RSZ, 1, MT8183_MDP_COMP_RSZ1, 0},
{1, 0, 0}
},
[MDP_COMP_TDSHP0] = {
- {MDP_COMP_TYPE_TDSHP, 0, MT8183_MDP_COMP_TDSHP0},
+ {MDP_COMP_TYPE_TDSHP, 0, MT8183_MDP_COMP_TDSHP0, 0},
{0, 0, 0}
},
[MDP_COMP_PATH0_SOUT] = {
- {MDP_COMP_TYPE_PATH, 0, MT8183_MDP_COMP_PATH0_SOUT},
+ {MDP_COMP_TYPE_PATH, 0, MT8183_MDP_COMP_PATH0_SOUT, 0},
{0, 0, 0}
},
[MDP_COMP_PATH1_SOUT] = {
- {MDP_COMP_TYPE_PATH, 1, MT8183_MDP_COMP_PATH1_SOUT},
+ {MDP_COMP_TYPE_PATH, 1, MT8183_MDP_COMP_PATH1_SOUT, 0},
{0, 0, 0}
},
[MDP_COMP_WROT0] = {
- {MDP_COMP_TYPE_WROT, 0, MT8183_MDP_COMP_WROT0},
+ {MDP_COMP_TYPE_WROT, 0, MT8183_MDP_COMP_WROT0, 0},
{1, 0, 0}
},
[MDP_COMP_WDMA] = {
- {MDP_COMP_TYPE_WDMA, 0, MT8183_MDP_COMP_WDMA},
+ {MDP_COMP_TYPE_WDMA, 0, MT8183_MDP_COMP_WDMA, 0},
{1, 0, 0}
},
};
@@ -402,10 +402,10 @@ static const struct mdp_limit mt8183_mdp_def_limit = {
};
static const struct mdp_pipe_info mt8183_pipe_info[] = {
- [MDP_PIPE_WPEI] = {MDP_PIPE_WPEI, 0},
- [MDP_PIPE_WPEI2] = {MDP_PIPE_WPEI2, 1},
- [MDP_PIPE_IMGI] = {MDP_PIPE_IMGI, 2},
- [MDP_PIPE_RDMA0] = {MDP_PIPE_RDMA0, 3}
+ [MDP_PIPE_WPEI] = {MDP_PIPE_WPEI, 0, 0},
+ [MDP_PIPE_WPEI2] = {MDP_PIPE_WPEI2, 0, 1},
+ [MDP_PIPE_IMGI] =
[PATCH] drm/msm/adreno: Add support for SM7150 SoC machine
SM7150 has 5 power levels which correspond to 5 speed-bin values: 0,
128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up
to zero decimal places.
The vendor's FW GMU is called a618_gmu.bin. And also a618 on SM7150 uses
a615 zapfw.
Add this as machine = "qcom,sm7150", because speed-bin values are
different from atoll (sc7180/sm7125).
Signed-off-by: Danila Tikhonov
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index fa527935ffd4..64ef9813e9ae 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -293,6 +293,28 @@ static const struct adreno_info gpulist[] = {
{ 157, 3 },
{ 127, 4 },
),
+ }, {
+ .machine = "qcom,sm7150",
+ .chip_ids = ADRENO_CHIP_IDS(0x06010800),
+ .family = ADRENO_6XX_GEN1,
+ .revn = 618,
+ .fw = {
+ [ADRENO_FW_SQE] = "a630_sqe.fw",
+ [ADRENO_FW_GMU] = "a618_gmu.bin",
+ },
+ .gmem = SZ_512K,
+ .inactive_period = DRM_MSM_INACTIVE_PERIOD,
+ .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT,
+ .init = a6xx_gpu_init,
+ .zapfw = "a615_zap.mdt",
+ .hwcg = a615_hwcg,
+ .speedbins = ADRENO_SPEEDBINS(
+ { 0, 0 },
+ { 128, 1 },
+ { 146, 2 },
+ { 167, 3 },
+ { 172, 4 },
+ ),
}, {
.chip_ids = ADRENO_CHIP_IDS(0x06010800),
.family = ADRENO_6XX_GEN1,
@@ -507,6 +529,10 @@ MODULE_FIRMWARE("qcom/a530_zap.b00");
MODULE_FIRMWARE("qcom/a530_zap.b01");
MODULE_FIRMWARE("qcom/a530_zap.b02");
MODULE_FIRMWARE("qcom/a540_gpmu.fw2");
+MODULE_FIRMWARE("qcom/a615_zap.mbt");
+MODULE_FIRMWARE("qcom/a615_zap.b00");
+MODULE_FIRMWARE("qcom/a615_zap.b01");
+MODULE_FIRMWARE("qcom/a615_zap.b02");
MODULE_FIRMWARE("qcom/a619_gmu.bin");
MODULE_FIRMWARE("qcom/a630_sqe.fw");
MODULE_FIRMWARE("qcom/a630_gmu.bin");
--
2.41.0
[PATCH v5 3/3] dt-binding: mediatek: add MediaTek mt8195 MDP3 components
Introduce more MDP3 components present in MT8195. Signed-off-by: Moudy Ho --- .../display/mediatek/mediatek,aal.yaml| 2 +- .../display/mediatek/mediatek,color.yaml | 2 +- .../display/mediatek/mediatek,merge.yaml | 1 + .../display/mediatek/mediatek,ovl.yaml| 2 +- .../display/mediatek/mediatek,split.yaml | 1 + .../bindings/media/mediatek,mdp3-fg.yaml | 61 +++ .../bindings/media/mediatek,mdp3-hdr.yaml | 60 ++ .../bindings/media/mediatek,mdp3-pad.yaml | 61 +++ .../bindings/media/mediatek,mdp3-rdma.yaml| 16 ++--- .../bindings/media/mediatek,mdp3-stitch.yaml | 61 +++ .../bindings/media/mediatek,mdp3-tcc.yaml | 60 ++ .../bindings/media/mediatek,mdp3-tdshp.yaml | 61 +++ 12 files changed, 378 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-pad.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index 7fd42c8fdc32..04b1314d00f2 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -24,6 +24,7 @@ properties: - enum: - mediatek,mt8173-disp-aal - mediatek,mt8183-disp-aal + - mediatek,mt8195-mdp3-aal - items: - enum: - mediatek,mt2712-disp-aal @@ -63,7 +64,6 @@ properties: required: - compatible - reg - - interrupts - power-domains - clocks diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index f21e44092043..8e97b0a6a7b3 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt2701-disp-color - mediatek,mt8167-disp-color - mediatek,mt8173-disp-color + - mediatek,mt8195-mdp3-color - items: - enum: - mediatek,mt7623-disp-color @@ -66,7 +67,6 @@ properties: required: - compatible - reg - - interrupts - power-domains - clocks diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index eead5cb8636e..401498523404 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -24,6 +24,7 @@ properties: - enum: - mediatek,mt8173-disp-merge - mediatek,mt8195-disp-merge + - mediatek,mt8195-mdp3-merge - items: - const: mediatek,mt6795-disp-merge - const: mediatek,mt8173-disp-merge diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index 3e1069b00b56..10d4d4f64e09 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt8173-disp-ovl - mediatek,mt8183-disp-ovl - mediatek,mt8192-disp-ovl + - mediatek,mt8195-mdp3-ovl - items: - enum: - mediatek,mt7623-disp-ovl @@ -76,7 +77,6 @@ properties: required: - compatible - reg - - interrupts - power-domains - clocks - iommus diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml index a8a5c9608598..a96b271e3240 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml @@ -23,6 +23,7 @@ properties: oneOf: - enum: - mediatek,mt8173-disp-split + - mediatek,mt8195-mdp3-split - items: - const: mediatek,mt6795-disp-split - const: mediatek,mt8173-disp-split diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml new file mode 100644 index ..71fd449de8b4 ---
[PATCH v5 07/14] media: platform: mtk-mdp3: add checks for dummy components
Some components act as bridges only and do not require full configuration.
Signed-off-by: Moudy Ho
---
.../platform/mediatek/mdp3/mdp_cfg_data.c | 8 +++
.../platform/mediatek/mdp3/mtk-mdp3-cfg.h | 1 +
.../platform/mediatek/mdp3/mtk-mdp3-cmdq.c| 58 ++-
3 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index 58792902abb5..b7efdafb1620 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -451,3 +451,11 @@ enum mtk_mdp_comp_id mdp_cfg_get_id_public(struct mdp_dev
*mdp_dev, s32 inner_id
err_public_id:
return public_id;
}
+
+bool mdp_cfg_comp_is_dummy(struct mdp_dev *mdp_dev, s32 inner_id)
+{
+ enum mtk_mdp_comp_id id = mdp_cfg_get_id_public(mdp_dev, inner_id);
+ enum mdp_comp_type type = mdp_dev->mdp_data->comp_data[id].match.type;
+
+ return (type == MDP_COMP_TYPE_DUMMY);
+}
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
index dee57cc4a954..dfffc72868e4 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
@@ -16,5 +16,6 @@ enum mtk_mdp_comp_id;
s32 mdp_cfg_get_id_inner(struct mdp_dev *mdp_dev, enum mtk_mdp_comp_id id);
enum mtk_mdp_comp_id mdp_cfg_get_id_public(struct mdp_dev *mdp_dev, s32 id);
+bool mdp_cfg_comp_is_dummy(struct mdp_dev *mdp_dev, s32 inner_id);
#endif /* __MTK_MDP3_CFG_H__ */
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index 6d04f72cf86f..6204173ecc5d 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -6,6 +6,7 @@
#include
#include
+#include "mtk-mdp3-cfg.h"
#include "mtk-mdp3-cmdq.h"
#include "mtk-mdp3-comp.h"
#include "mtk-mdp3-core.h"
@@ -115,6 +116,12 @@ static int mdp_path_subfrm_require(const struct mdp_path
*path,
/* Set mutex mod */
for (index = 0; index < num_comp; index++) {
+ s32 inner_id = MDP_COMP_NONE;
+
+ if (CFG_CHECK(MT8183, p_id))
+ inner_id = CFG_GET(MT8183, path->config,
components[index].type);
+ if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+ continue;
ctx = >comps[index];
if (is_output_disabled(p_id, ctx->param, count))
continue;
@@ -139,6 +146,7 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
int index;
u32 num_comp = 0;
s32 event;
+ s32 inner_id = MDP_COMP_NONE;
if (-1 == p->mutex_id) {
dev_err(dev, "Incorrect mutex id");
@@ -151,6 +159,10 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
/* Wait WROT SRAM shared to DISP RDMA */
/* Clear SOF event for each engine */
for (index = 0; index < num_comp; index++) {
+ if (CFG_CHECK(MT8183, p_id))
+ inner_id = CFG_GET(MT8183, path->config,
components[index].type);
+ if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+ continue;
ctx = >comps[index];
if (is_output_disabled(p_id, ctx->param, count))
continue;
@@ -165,6 +177,10 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
/* Wait SOF events and clear mutex modules (optional) */
for (index = 0; index < num_comp; index++) {
+ if (CFG_CHECK(MT8183, p_id))
+ inner_id = CFG_GET(MT8183, path->config,
components[index].type);
+ if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+ continue;
ctx = >comps[index];
if (is_output_disabled(p_id, ctx->param, count))
continue;
@@ -190,6 +206,12 @@ static int mdp_path_ctx_init(struct mdp_dev *mdp, struct
mdp_path *path)
return -EINVAL;
for (index = 0; index < num_comp; index++) {
+ s32 inner_id = MDP_COMP_NONE;
+
+ if (CFG_CHECK(MT8183, p_id))
+ inner_id = CFG_GET(MT8183, path->config,
components[index].type);
+ if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+ continue;
if (CFG_CHECK(MT8183, p_id))
param = (void *)CFG_ADDR(MT8183, path->config,
components[index]);
ret = mdp_comp_ctx_config(mdp, >comps[index],
@@ -211,6 +233,7 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
struct mdp_pipe_info pipe;
int index, ret;
u32 num_comp = 0;
+ s32 inner_id = MDP_COMP_NONE;
if (CFG_CHECK(MT8183, p_id))
Re: [PATCH v5 2/3] dt-binding: mediatek: integrate MDP RDMA to one binding
On Tue, 2023-09-12 at 10:16 +0200, Krzysztof Kozlowski wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 12/09/2023 09:56, Moudy Ho wrote: > > Due to the same hardware design, MDP RDMA needs to > > be integrated into the same binding. > > > > Please use subject prefixes matching the subsystem. You can get them > for > example with `git log --oneline -- DIRECTORY_OR_FILE` on the > directory > your patch is touching. > > This applies to entire patchset. It is not dt-binding, but dt- > bindings. > > > Signed-off-by: Moudy Ho > > --- > > .../display/mediatek/mediatek,mdp-rdma.yaml | 88 - > -- > > .../bindings/media/mediatek,mdp3-rdma.yaml| 5 +- > > 2 files changed, 3 insertions(+), 90 deletions(-) > > delete mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- > rdma.yaml > > > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- > rdma.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- > rdma.yaml > > deleted file mode 100644 > > index dd12e2ff685c.. > > --- > a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- > rdma.yaml > > +++ /dev/null > > @@ -1,88 +0,0 @@ > > -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > -%YAML 1.2 > > > > -$id: > http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml# > > -$schema: http://devicetree.org/meta-schemas/core.yaml# > > - > > -title: MediaTek MDP RDMA > > - > > -maintainers: > > - - Chun-Kuang Hu > > - - Philipp Zabel > > - > > -description: > > - The MediaTek MDP RDMA stands for Read Direct Memory Access. > > - It provides real time data to the back-end panel driver, such as > DSI, > > - DPI and DP_INTF. > > - It contains one line buffer to store the sufficient pixel data. > > - RDMA device node must be siblings to the central MMSYS_CONFIG > node. > > - For a description of the MMSYS_CONFIG binding, see > > > - Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > for details. > > - > > -properties: > > - compatible: > > -const: mediatek,mt8195-vdo1-rdma > > - > > - reg: > > -maxItems: 1 > > - > > - interrupts: > > -maxItems: 1 > > - > > - power-domains: > > -maxItems: 1 > > - > > - clocks: > > -items: > > - - description: RDMA Clock > > This is different and you did not explain it in commit msg. > > Another difference - mboxes. Looks like you did not test your DTS... > > Best regards, > Krzysztof > Hi Krzysztof, Sorry for the inconvenience. The property you mentioned was removed on [3/3]. This incorrect configuration went unnoticed because I passed the test with the entire series. It will be recified in the next version. Sincerely, Moudy
[PATCH v5 06/14] media: platform: mtk-mdp3: introduce more MDP3 components
Add configuration of more components in MT8195 MDP3. Signed-off-by: Moudy Ho --- .../platform/mediatek/mdp3/mdp_reg_aal.h | 25 ++ .../platform/mediatek/mdp3/mdp_reg_color.h| 31 +++ .../media/platform/mediatek/mdp3/mdp_reg_fg.h | 23 + .../platform/mediatek/mdp3/mdp_reg_hdr.h | 31 +++ .../platform/mediatek/mdp3/mdp_reg_merge.h| 25 ++ .../platform/mediatek/mdp3/mdp_reg_ovl.h | 25 ++ .../platform/mediatek/mdp3/mdp_reg_pad.h | 21 + .../platform/mediatek/mdp3/mdp_reg_rdma.h | 24 ++ .../platform/mediatek/mdp3/mdp_reg_rsz.h | 2 + .../platform/mediatek/mdp3/mdp_reg_tdshp.h| 34 .../platform/mediatek/mdp3/mdp_reg_wrot.h | 8 ++ .../platform/mediatek/mdp3/mtk-mdp3-comp.h| 85 +++ 12 files changed, 318 insertions(+), 16 deletions(-) create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_color.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_hdr.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_merge.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_ovl.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_pad.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_tdshp.h diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h new file mode 100644 index ..4b9513e54543 --- /dev/null +++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h @@ -0,0 +1,25 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2022 MediaTek Inc. + * Author: Ping-Hsun Wu + */ + +#ifndef __MDP_REG_AAL_H__ +#define __MDP_REG_AAL_H__ + +#define MDP_AAL_EN (0x000) +#define MDP_AAL_CFG(0x020) +#define MDP_AAL_SIZE (0x030) +#define MDP_AAL_OUTPUT_SIZE(0x034) +#define MDP_AAL_OUTPUT_OFFSET (0x038) +#define MDP_AAL_CFG_MAIN (0x200) + +/* MASK */ +#define MDP_AAL_EN_MASK(0x01) +#define MDP_AAL_CFG_MASK (0x70FF00B3) +#define MDP_AAL_SIZE_MASK (0x1FFF1FFF) +#define MDP_AAL_OUTPUT_SIZE_MASK (0x1FFF1FFF) +#define MDP_AAL_OUTPUT_OFFSET_MASK (0x0FF00FF) +#define MDP_AAL_CFG_MAIN_MASK (0x0FE) + +#endif // __MDP_REG_AAL_H__ diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_color.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_color.h new file mode 100644 index ..f72503975b24 --- /dev/null +++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_color.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2022 MediaTek Inc. + * Author: Ping-Hsun Wu + */ + +#ifndef __MDP_REG_COLOR_H__ +#define __MDP_REG_COLOR_H__ + +#define MDP_COLOR_WIN_X_MAIN (0x40C) +#define MDP_COLOR_WIN_Y_MAIN (0x410) +#define MDP_COLOR_START(0xC00) +#define MDP_COLOR_INTEN(0xC04) +#define MDP_COLOR_OUT_SEL (0xC0C) +#define MDP_COLOR_INTERNAL_IP_WIDTH(0xC50) +#define MDP_COLOR_INTERNAL_IP_HEIGHT (0xC54) +#define MDP_COLOR_CM1_EN (0xC60) +#define MDP_COLOR_CM2_EN (0xCA0) + +/* MASK */ +#define MDP_COLOR_WIN_X_MAIN_MASK (0x) +#define MDP_COLOR_WIN_Y_MAIN_MASK (0x) +#define MDP_COLOR_START_MASK (0x0FF013F) +#define MDP_COLOR_INTEN_MASK (0x07) +#define MDP_COLOR_OUT_SEL_MASK (0x0777) +#define MDP_COLOR_INTERNAL_IP_WIDTH_MASK (0x03FFF) +#define MDP_COLOR_INTERNAL_IP_HEIGHT_MASK (0x03FFF) +#define MDP_COLOR_CM1_EN_MASK (0x03) +#define MDP_COLOR_CM2_EN_MASK (0x017) + +#endif // __MDP_REG_COLOR_H__ diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h new file mode 100644 index ..d90bcad33a59 --- /dev/null +++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h @@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2022 MediaTek Inc. + * Author: Ping-Hsun Wu + */ + +#ifndef __MDP_REG_FG_H__ +#define __MDP_REG_FG_H__ + +#define MDP_FG_TRIGGER (0x0) +#define MDP_FG_FG_CTRL_0 (0x20) +#define MDP_FG_FG_CK_EN(0x24) +#define MDP_FG_TILE_INFO_0 (0x418) +#define MDP_FG_TILE_INFO_1 (0x41c) + +/* MASK */ +#define MDP_FG_TRIGGER_MASK(0x0007) +#define MDP_FG_FG_CTRL_0_MASK (0x0033) +#define MDP_FG_FG_CK_EN_MASK (0x000F) +#define MDP_FG_TILE_INFO_0_MASK(0x) +#define MDP_FG_TILE_INFO_1_MASK
[PATCH v5 00/14] add support MDP3 on MT8195 platform
Changes since v4: - Rebase on v6.6-rc1 - Remove any unnecessary DTS settings. - Adjust the usage of MOD and clock in blending components. Changes since v3: - Depend on : [1] https://patchwork.kernel.org/project/linux-media/list/?series=719841 - Suggested by Krzysztof, integrating all newly added bindings for the mt8195 MDP3 into the file "mediatek,mt8195-mdp3.yaml". - Revise MDP3 nodes with generic names. Changes since v2: - Depend on : [1] MMSYS/MUTEX: https://patchwork.kernel.org/project/linux-mediatek/list/?series=711592 [2] MDP3: https://patchwork.kernel.org/project/linux-mediatek/list/?series=711618 - Suggested by Rob to revise MDP3 bindings to pass dtbs check - Add parallel paths feature. - Add blended components settings. Changes since v1: - Depend on : [1] MDP3 : https://patchwork.kernel.org/project/linux-mediatek/list/?series=698872 [2] MMSYS/MUTEX: https://patchwork.kernel.org/project/linux-mediatek/list/?series=684959 - Fix compilation failure due to use of undeclared identifier in file "mtk-mdp3-cmdq.c" Hello, This patch is used to add support for MDP3 on the MT8195 platform that contains more picture quality components, and can arrange more pipelines through two sets of MMSYS and MUTEX respectively. Moudy Ho (14): arm64: dts: mediatek: mt8183: correct MDP3 DMA-related nodes arm64: dts: mediatek: mt8195: add MDP3 nodes media: platform: mtk-mdp3: add support second sets of MMSYS media: platform: mtk-mdp3: add support second sets of MUTEX media: platform: mtk-mdp3: introduce more pipelines from MT8195 media: platform: mtk-mdp3: introduce more MDP3 components media: platform: mtk-mdp3: add checks for dummy components media: platform: mtk-mdp3: avoid multiple driver registrations media: platform: mtk-mdp3: extend GCE event waiting in RDMA and WROT media: platform: mtk-mdp3: add support for blending multiple components media: platform: mtk-mdp3: add mt8195 platform configuration media: platform: mtk-mdp3: add mt8195 shared memory configurations media: platform: mtk-mdp3: add mt8195 MDP3 component settings media: platform: mtk-mdp3: add support for parallel pipe to improve FPS arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 +- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 378 .../platform/mediatek/mdp3/mdp_cfg_data.c | 729 ++- .../platform/mediatek/mdp3/mdp_reg_aal.h | 25 + .../platform/mediatek/mdp3/mdp_reg_color.h| 31 + .../media/platform/mediatek/mdp3/mdp_reg_fg.h | 23 + .../platform/mediatek/mdp3/mdp_reg_hdr.h | 31 + .../platform/mediatek/mdp3/mdp_reg_merge.h| 25 + .../platform/mediatek/mdp3/mdp_reg_ovl.h | 25 + .../platform/mediatek/mdp3/mdp_reg_pad.h | 21 + .../platform/mediatek/mdp3/mdp_reg_rdma.h | 24 + .../platform/mediatek/mdp3/mdp_reg_rsz.h | 2 + .../platform/mediatek/mdp3/mdp_reg_tdshp.h| 34 + .../platform/mediatek/mdp3/mdp_reg_wrot.h | 8 + .../platform/mediatek/mdp3/mdp_sm_mt8195.h| 283 ++ .../platform/mediatek/mdp3/mtk-img-ipi.h | 4 + .../platform/mediatek/mdp3/mtk-mdp3-cfg.h | 2 + .../platform/mediatek/mdp3/mtk-mdp3-cmdq.c| 447 +++-- .../platform/mediatek/mdp3/mtk-mdp3-cmdq.h| 1 + .../platform/mediatek/mdp3/mtk-mdp3-comp.c| 860 +- .../platform/mediatek/mdp3/mtk-mdp3-comp.h| 93 +- .../platform/mediatek/mdp3/mtk-mdp3-core.c| 103 ++- .../platform/mediatek/mdp3/mtk-mdp3-core.h| 33 +- .../platform/mediatek/mdp3/mtk-mdp3-m2m.c | 15 + .../platform/mediatek/mdp3/mtk-mdp3-regs.c| 18 + .../platform/mediatek/mdp3/mtk-mdp3-regs.h| 1 + .../platform/mediatek/mdp3/mtk-mdp3-vpu.c | 3 +- 27 files changed, 3051 insertions(+), 174 deletions(-) create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_color.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_hdr.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_merge.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_ovl.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_pad.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_tdshp.h create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h -- 2.18.0
Re: [PATCH] drm/tests: provide exit function
On 2023-09-14 15:00, Maxime Ripard wrote: On Wed, Sep 13, 2023 at 07:35:57PM +0300, José Pekkarinen wrote: On 2023-09-13 17:41, mrip...@kernel.org wrote: > On Wed, Sep 13, 2023 at 05:01:40PM +0300, José Pekkarinen wrote: > > On 2023-09-13 12:50, Maxime Ripard wrote: > > > Hi, > > > > > > On Wed, Sep 13, 2023 at 11:32:23AM +0300, José Pekkarinen wrote: > > > > Running drm_exec_test by modprobing the module I > > > > observe the following output: > > > > > > > > [ 424.471936] KTAP version 1 > > > > [ 424.471942] 1..1 > > > > [ 424.472446] KTAP version 1 > > > > [ 424.472450] # Subtest: drm_exec > > > > [ 424.472453] # module: drm_exec_test > > > > [ 424.472459] 1..7 > > > > [ 424.479082] > > > > == > > > > [ 424.479095] BUG: KASAN: slab-use-after-free in > > > > drm_dev_put.part.0+0x4b/0x90 [drm] > > > > [ 424.479426] Read of size 8 at addr 888132d3e028 by task > > > > kunit_try_catch/1866 > > > > [ 424.479436] > > > > [ 424.479442] CPU: 1 PID: 1866 Comm: kunit_try_catch Tainted: G > > > > N 6.6.0-rc1-dirty #2 > > > > > > That's suspicious > > > > > > > [ 424.479446] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), > > > > BIOS 0.0.0 02/06/2015 > > > > [ 424.479446] Call Trace: > > > > [ 424.479446] > > > > [ 424.479446] dump_stack_lvl+0x43/0x60 > > > > [ 424.479446] print_report+0xcf/0x660 > > > > [ 424.479446] ? __virt_addr_valid+0xd9/0x160 > > > > [ 424.479446] ? drm_dev_put.part.0+0x4b/0x90 [drm] > > > > [ 424.479446] kasan_report+0xda/0x110 > > > > [ 424.479446] ? drm_dev_put.part.0+0x4b/0x90 [drm] > > > > [ 424.479446] drm_dev_put.part.0+0x4b/0x90 [drm] > > > > [ 424.479446] release_nodes+0x83/0x160 > > > > [ 424.479446] devres_release_all+0xe6/0x130 > > > > [ 424.479446] ? __pfx_devres_release_all+0x10/0x10 > > > > [ 424.479446] ? mutex_unlock+0x80/0xd0 > > > > [ 424.479446] ? __pfx_mutex_unlock+0x10/0x10 > > > > [ 424.479446] device_unbind_cleanup+0x16/0xc0 > > > > [ 424.479446] device_release_driver_internal+0x28b/0x2e0 > > > > [ 424.479446] bus_remove_device+0x124/0x1d0 > > > > [ 424.479446] device_del+0x23d/0x580 > > > > [ 424.479446] ? __pfx_device_del+0x10/0x10 > > > > [ 424.479446] ? kasan_set_track+0x21/0x30 > > > > [ 424.479446] ? _raw_spin_lock_irqsave+0x98/0xf0 > > > > [ 424.479446] platform_device_del.part.0+0x19/0xe0 > > > > [ 424.479446] kunit_remove_resource+0xfa/0x140 [kunit] > > > > [ 424.479446] kunit_cleanup+0x47/0xa0 [kunit] > > > > [ 424.479446] ? __pfx_kunit_try_run_case_cleanup+0x10/0x10 [kunit] > > > > [ 424.479446] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 > > > > [kunit] > > > > [ 424.479446] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] > > > > [ 424.479446] kthread+0x184/0x1c0 > > > > [ 424.479446] ? __pfx_kthread+0x10/0x10 > > > > [ 424.479446] ret_from_fork+0x30/0x50 > > > > [ 424.479446] ? __pfx_kthread+0x10/0x10 > > > > [ 424.479446] ret_from_fork_asm+0x1b/0x30 > > > > [ 424.479446] > > > > [ 424.479446] > > > > [ 424.479446] Allocated by task 1865: > > > > [ 424.479446] kasan_save_stack+0x2f/0x50 > > > > [ 424.479446] kasan_set_track+0x21/0x30 > > > > [ 424.479446] __kasan_kmalloc+0xa6/0xb0 > > > > [ 424.479446] __kmalloc+0x5d/0x160 > > > > [ 424.479446] kunit_kmalloc_array+0x1c/0x50 [kunit] > > > > [ 424.479446] drm_exec_test_init+0xef/0x260 [drm_exec_test] > > > > [ 424.479446] kunit_try_run_case+0x6e/0x100 [kunit] > > > > [ 424.479446] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] > > > > [ 424.479446] kthread+0x184/0x1c0 > > > > [ 424.479446] ret_from_fork+0x30/0x50 > > > > [ 424.479446] ret_from_fork_asm+0x1b/0x30 > > > > [ 424.479446] > > > > [ 424.479446] Freed by task 1866: > > > > [ 424.479446] kasan_save_stack+0x2f/0x50 > > > > [ 424.479446] kasan_set_track+0x21/0x30 > > > > [ 424.479446] kasan_save_free_info+0x27/0x40 > > > > [ 424.479446] kasan_slab_free+0x166/0x1c0 > > > > [ 424.479446] slab_free_freelist_hook+0x9f/0x1e0 > > > > [ 424.479446] __kmem_cache_free+0x187/0x2d0 > > > > [ 424.479446] kunit_remove_resource+0xfa/0x140 [kunit] > > > > [ 424.479446] kunit_cleanup+0x47/0xa0 [kunit] > > > > [ 424.479446] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] > > > > [ 424.479446] kthread+0x184/0x1c0 > > > > [ 424.479446] ret_from_fork+0x30/0x50 > > > > [ 424.479446] ret_from_fork_asm+0x1b/0x30 > > > > [ 424.479446] > > > > [ 424.479446] The buggy address belongs to the object at > > > > 888132d3e000 > > > > [ 424.479446] which belongs to the cache kmalloc-256 of size 256 > > > > [ 424.479446] The buggy address is located 40 bytes inside of > > > > [ 424.479446] freed 256-byte region [888132d3e000, > > > > 888132d3e100) > > > > [ 424.479446] > > > > [ 424.479446] The buggy address belongs to the physical page: > > > > [ 424.479446] page:92ff6551 refcount:1 mapcount:0 > > > >
[PATCH] staging: fbtft: Removed unnecessary parenthesis around conditions to comply with the checkpatch coding style.
---
drivers/staging/fbtft/fb_ra8875.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ra8875.c
b/drivers/staging/fbtft/fb_ra8875.c
index 398bdbf53c9a..658f915b8528 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -50,7 +50,7 @@ static int init_display(struct fbtft_par *par)
par->fbtftops.reset(par);
- if ((par->info->var.xres == 320) && (par->info->var.yres == 240)) {
+ if (par->info->var.xres == 320 && par->info->var.yres == 240) {
/* PLL clock frequency */
write_reg(par, 0x88, 0x0A);
write_reg(par, 0x89, 0x02);
@@ -74,8 +74,7 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0x1D, 0x0E);
write_reg(par, 0x1E, 0x00);
write_reg(par, 0x1F, 0x02);
- } else if ((par->info->var.xres == 480) &&
- (par->info->var.yres == 272)) {
+ } else if (par->info->var.xres == 480 && par->info->var.yres == 272) {
/* PLL clock frequency */
write_reg(par, 0x88, 0x0A);
write_reg(par, 0x89, 0x02);
@@ -99,8 +98,7 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0x1D, 0x07);
write_reg(par, 0x1E, 0x00);
write_reg(par, 0x1F, 0x09);
- } else if ((par->info->var.xres == 640) &&
- (par->info->var.yres == 480)) {
+ } else if (par->info->var.xres == 640 && par->info->var.yres == 480) {
/* PLL clock frequency */
write_reg(par, 0x88, 0x0B);
write_reg(par, 0x89, 0x02);
@@ -124,8 +122,7 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0x1D, 0x0E);
write_reg(par, 0x1E, 0x00);
write_reg(par, 0x1F, 0x01);
- } else if ((par->info->var.xres == 800) &&
- (par->info->var.yres == 480)) {
+ } else if (par->info->var.xres == 800 && par->info->var.yres == 480) {
/* PLL clock frequency */
write_reg(par, 0x88, 0x0B);
write_reg(par, 0x89, 0x02);
--
2.40.1
Re: [PATCH 1/1] drm/mediatek: Add missing plane settings when async update
Il 18/09/23 09:00, Hsiao Chien Sung ha scritto:
Fix an issue that plane coordinate was not saved when
calling async update.
Fixes: 920fffcc8912 ("drm/mediatek: update cursors by using async atomic
update")
Signed-off-by: Hsiao Chien Sung
Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v2 04/11] drm/mediatek: Add OVL compatible name for MT8195
Re: [PATCH v5 6/6] drm/drm-file: Show finer-grained BO sizes in drm_show_memory_stats
On 14/09/2023 23:38, Adrián Larumbe wrote:
> The current implementation will try to pick the highest available size
> display unit as soon as the BO size exceeds that of the previous
> multiplier. That can lead to loss of precision in contexts of low memory
> usage.
>
> The new selection criteria try to preserve precision, whilst also
> increasing the display unit selection threshold to render more accurate
> values.
>
> Signed-off-by: Adrián Larumbe
I have to admit I find it odd to be "pretty printing" this value in the
first place. But this is clearly an improvement.
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/drm_file.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 762965e3d503..34cfa128ffe5 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -872,6 +872,8 @@ void drm_send_event(struct drm_device *dev, struct
> drm_pending_event *e)
> }
> EXPORT_SYMBOL(drm_send_event);
>
> +#define UPPER_UNIT_THRESHOLD 100
> +
> static void print_size(struct drm_printer *p, const char *stat,
> const char *region, u64 sz)
> {
> @@ -879,7 +881,8 @@ static void print_size(struct drm_printer *p, const char
> *stat,
> unsigned u;
>
> for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> - if (sz < SZ_1K)
> + if ((sz & (SZ_1K - 1)) &&
> + sz < UPPER_UNIT_THRESHOLD * SZ_1K)
> break;
> sz = div_u64(sz, SZ_1K);
> }
[PATCH][V3] drm/amd/display: Remove unwanted drm edid references
[WHY]
edid_override and drm_edid_override_connector_update, according to drm
documentation, should not be referred outside drm_edid.
[HOW]
Remove and replace them accordingly. This can tested by IGT's
kms_hdmi_inject test.
Signed-off-by: Alex Hung
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 42 ++-
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5efebc06296b..3968dd9cef7f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6444,15 +6444,23 @@ amdgpu_dm_connector_late_register(struct drm_connector
*connector)
static void amdgpu_dm_connector_funcs_force(struct drm_connector *connector)
{
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
+ struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
struct dc_link *dc_link = aconnector->dc_link;
struct dc_sink *dc_em_sink = aconnector->dc_em_sink;
struct edid *edid;
- if (!connector->edid_override)
+ /*
+* Note: drm_get_edid gets edid in the following order:
+* 1) override EDID if set via edid_override debugfs,
+* 2) firmware EDID if set via edid_firmware module parameter
+* 3) regular DDC read.
+*/
+ edid = drm_get_edid(connector, _connector->ddc_bus->aux.ddc);
+ if (!edid) {
+ DRM_ERROR("No EDID found on connector: %s.\n", connector->name);
return;
+ }
- drm_edid_override_connector_update(>base);
- edid = aconnector->base.edid_blob_ptr->data;
aconnector->edid = edid;
/* Update emulated (virtual) sink's EDID */
@@ -6487,30 +6495,26 @@ static int get_modes(struct drm_connector *connector)
static void create_eml_sink(struct amdgpu_dm_connector *aconnector)
{
+ struct drm_connector *connector = >base;
+ struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(>base);
struct dc_sink_init_data init_params = {
.link = aconnector->dc_link,
.sink_signal = SIGNAL_TYPE_VIRTUAL
};
struct edid *edid;
- if (!aconnector->base.edid_blob_ptr) {
- /* if connector->edid_override valid, pass
-* it to edid_override to edid_blob_ptr
-*/
-
- drm_edid_override_connector_update(>base);
-
- if (!aconnector->base.edid_blob_ptr) {
- DRM_ERROR("No EDID firmware found on connector: %s
,forcing to OFF!\n",
- aconnector->base.name);
-
- aconnector->base.force = DRM_FORCE_OFF;
- return;
- }
+ /*
+* Note: drm_get_edid gets edid in the following order:
+* 1) override EDID if set via edid_override debugfs,
+* 2) firmware EDID if set via edid_firmware module parameter
+* 3) regular DDC read.
+*/
+ edid = drm_get_edid(connector, _connector->ddc_bus->aux.ddc);
+ if (!edid) {
+ DRM_ERROR("No EDID found on connector: %s.\n", connector->name);
+ return;
}
- edid = (struct edid *) aconnector->base.edid_blob_ptr->data;
-
aconnector->edid = edid;
aconnector->dc_em_sink = dc_link_add_remote_sink(
--
2.42.0
[PATCH] drm/bridge: panel: Fix device link for DRM_BRIDGE_ATTACH_NO_CONNECTOR
When external bridges are attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR,
the panel bridge may also get the same flag, but in the .attach()
callback for the panel bridge a device link is added only when this
flag is not present; To make things worse, the .detach() callback
tries to delete the device link unconditionally and without checking
if it was created in the first place, crashing the kernel with a NULL
pointer kernel panic upon calling panel_bridge_detach().
Fix that by moving the device_link_add() call before checking if the
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is present.
Fixes: 199cf07ebd2b ("drm/bridge: panel: Add a device link between drm device
and panel device")
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/bridge/panel.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index e00d2e94c751..8c507dfd589e 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -67,14 +67,6 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
struct drm_device *drm_dev = bridge->dev;
int ret;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
- return 0;
-
- if (!bridge->encoder) {
- DRM_ERROR("Missing encoder\n");
- return -ENODEV;
- }
-
panel_bridge->link = device_link_add(drm_dev->dev, panel->dev,
DL_FLAG_STATELESS);
if (!panel_bridge->link) {
@@ -83,6 +75,14 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
return -EINVAL;
}
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Missing encoder\n");
+ return -ENODEV;
+ }
+
drm_connector_helper_add(connector,
_bridge_connector_helper_funcs);
--
2.42.0
Re: [PATCH v5 5/6] drm/panfrost: Implement generic DRM object RSS reporting function
On 18/09/2023 11:32, Boris Brezillon wrote:
> On Mon, 18 Sep 2023 11:01:43 +0100
> Steven Price wrote:
>
>> On 14/09/2023 23:38, Adrián Larumbe wrote:
>>> BO's RSS is updated every time new pages are allocated on demand and mapped
>>> for the object at GPU page fault's IRQ handler, but only for heap buffers.
>>> The reason this is unnecessary for non-heap buffers is that they are mapped
>>> onto the GPU's VA space and backed by physical memory in their entirety at
>>> BO creation time.
>>>
>>> This calculation is unnecessary for imported PRIME objects, since heap
>>> buffers cannot be exported by our driver, and the actual BO RSS size is the
>>> one reported in its attached dmabuf structure.
>>>
>>> Signed-off-by: Adrián Larumbe
>>> Reviewed-by: Boris Brezillon
>>
>> Am I missing something, or are we missing a way of resetting
>> heap_rss_size when the shrinker purges? It looks like after several
>> grow/purge cycles, heap_rss_size could actually grow to be larger than
>> the BO which is clearly wrong.
>
> Didn't even consider this case since we don't flag heap BOs purgeable
> in mesa(panfrost), but let's assume we did. If the BO is purged, I'd
> expect the core to report 0MB of resident memory anyway. And purged BOs
> are not supposed to be re-used if MADVISE(WILL_NEED) returns
> retained=false, they should be destroyed. Not 100% sure this is
> enforced everywhere though (we might actually miss tests to make sure
> users don't pass purged BOs to jobs, or make the alloc-on-fault logic
> doesn't try to grow a purged GEM).
>
> If we want to implement transparent BO swap{out,in} (Dmitry's
> patchset), that's be a different story, and we'll indeed have to set
> heap_rss_size back to zero on eviction.
Ah, ok. So we should be safe as things stand - but this is something to
remember about in the future. Looking more closely at the code I can see
an madvise(WILL_NEED) will fail if retained=false
(drm_gem_shmem_madvise() only updates the state it shmem->madv >= 0).
In which case:
Reviewed-by: Steven Price
>>
>> Steve
>>
>>> ---
>>> drivers/gpu/drm/panfrost/panfrost_gem.c | 15 +++
>>> drivers/gpu/drm/panfrost/panfrost_gem.h | 5 +
>>> drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 +
>>> 3 files changed, 21 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
>>> b/drivers/gpu/drm/panfrost/panfrost_gem.c
>>> index 7d8f83d20539..4365434b48db 100644
>>> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
>>> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
>>> @@ -208,6 +208,20 @@ static enum drm_gem_object_status
>>> panfrost_gem_status(struct drm_gem_object *obj
>>> return res;
>>> }
>>>
>>> +static size_t panfrost_gem_rss(struct drm_gem_object *obj)
>>> +{
>>> + struct panfrost_gem_object *bo = to_panfrost_bo(obj);
>>> +
>>> + if (bo->is_heap) {
>>> + return bo->heap_rss_size;
>>> + } else if (bo->base.pages) {
>>> + WARN_ON(bo->heap_rss_size);
>>> + return bo->base.base.size;
>>> + } else {
>>> + return 0;
>>> + }
>>> +}
>>> +
>>> static const struct drm_gem_object_funcs panfrost_gem_funcs = {
>>> .free = panfrost_gem_free_object,
>>> .open = panfrost_gem_open,
>>> @@ -220,6 +234,7 @@ static const struct drm_gem_object_funcs
>>> panfrost_gem_funcs = {
>>> .vunmap = drm_gem_shmem_object_vunmap,
>>> .mmap = drm_gem_shmem_object_mmap,
>>> .status = panfrost_gem_status,
>>> + .rss = panfrost_gem_rss,
>>> .vm_ops = _gem_shmem_vm_ops,
>>> };
>>>
>>> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h
>>> b/drivers/gpu/drm/panfrost/panfrost_gem.h
>>> index ad2877eeeccd..13c0a8149c3a 100644
>>> --- a/drivers/gpu/drm/panfrost/panfrost_gem.h
>>> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
>>> @@ -36,6 +36,11 @@ struct panfrost_gem_object {
>>> */
>>> atomic_t gpu_usecount;
>>>
>>> + /*
>>> +* Object chunk size currently mapped onto physical memory
>>> +*/
>>> + size_t heap_rss_size;
>>> +
>>> bool noexec :1;
>>> bool is_heap:1;
>>> };
>>> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> index d54d4e7b2195..7b1490cdaa48 100644
>>> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> @@ -522,6 +522,7 @@ static int panfrost_mmu_map_fault_addr(struct
>>> panfrost_device *pfdev, int as,
>>>IOMMU_WRITE | IOMMU_READ | IOMMU_NOEXEC, sgt);
>>>
>>> bomapping->active = true;
>>> + bo->heap_rss_size += SZ_2;
>>>
>>> dev_dbg(pfdev->dev, "mapped page fault @ AS%d %llx", as, addr);
>>>
>>
>
[PATCH 05/10] accel/habanalabs: set hl_dmabuf_priv.device_address only when needed
From: Tomer Tayar
The device_address member of 'struct hl_dmabuf_priv' is used only when
virtual device memory is not supported and dma-buf is exported from
address.
Set the value of this field only when it is relevant, and add "phys" to
its name so it would be clearer that it can't be a device virtual
address.
Signed-off-by: Tomer Tayar
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/habanalabs.h | 8
drivers/accel/habanalabs/common/memory.c | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index 7c2da8cfe844..43e682cdeb75 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -1811,16 +1811,16 @@ struct hl_cs_counters_atomic {
* @phys_pg_pack: pointer to physical page pack if the dma-buf was exported
*where virtual memory is supported.
* @memhash_hnode: pointer to the memhash node. this object holds the export
count.
- * @device_address: physical address of the device's memory. Relevant only
- * if phys_pg_pack is NULL (dma-buf was exported from
address).
- * The total size can be taken from the dmabuf object.
+ * device_phys_addr: physical address of the device's memory. Relevant only
+ * if phys_pg_pack is NULL (dma-buf was exported from
address).
+ * The total size can be taken from the dmabuf object.
*/
struct hl_dmabuf_priv {
struct dma_buf *dmabuf;
struct hl_ctx *ctx;
struct hl_vm_phys_pg_pack *phys_pg_pack;
struct hl_vm_hash_node *memhash_hnode;
- uint64_tdevice_address;
+ u64 device_phys_addr;
};
#define HL_CS_OUTCOME_HISTORY_LEN 256
diff --git a/drivers/accel/habanalabs/common/memory.c
b/drivers/accel/habanalabs/common/memory.c
index 5c1e98e73a47..dc5ff3e74c39 100644
--- a/drivers/accel/habanalabs/common/memory.c
+++ b/drivers/accel/habanalabs/common/memory.c
@@ -1730,7 +1730,7 @@ static struct sg_table *hl_map_dmabuf(struct
dma_buf_attachment *attachment,
npages = phys_pg_pack->npages;
page_size = phys_pg_pack->page_size;
} else {
- pages = _dmabuf->device_address;
+ pages = _dmabuf->device_phys_addr;
npages = 1;
page_size = hl_dmabuf->dmabuf->size;
}
@@ -2063,9 +2063,9 @@ static int export_dmabuf_from_addr(struct hl_ctx *ctx,
u64 addr, u64 size, u64 o
rc = validate_export_params_no_mmu(hdev, export_addr, size);
if (rc)
goto err_free_dmabuf_wrapper;
- }
- hl_dmabuf->device_address = export_addr;
+ hl_dmabuf->device_phys_addr = export_addr;
+ }
rc = export_dmabuf(ctx, hl_dmabuf, size, flags, dmabuf_fd);
if (rc)
--
2.34.1
[PATCH 09/10] accel/habanalabs: extend preboot timeout when preboot might take longer
From: Dafna Hirschfeld
There are cases such when FW runs MBIST, that preboot is expected to take
longer than the usual. In such cases the firmware reports status
SECURITY_READY/IN_PREBOOT and we extend the timeout waiting for it.
This is currently implemented for Gaudi2 only.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/firmware_if.c | 26 ---
drivers/accel/habanalabs/common/habanalabs.h | 3 +++
drivers/accel/habanalabs/gaudi2/gaudi2.c | 2 ++
drivers/accel/habanalabs/gaudi2/gaudi2P.h | 1 +
4 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/accel/habanalabs/common/firmware_if.c
b/drivers/accel/habanalabs/common/firmware_if.c
index 2a6dfea3d27d..0fb360cca9cc 100644
--- a/drivers/accel/habanalabs/common/firmware_if.c
+++ b/drivers/accel/habanalabs/common/firmware_if.c
@@ -1474,8 +1474,9 @@ static void detect_cpu_boot_status(struct hl_device
*hdev, u32 status)
int hl_fw_wait_preboot_ready(struct hl_device *hdev)
{
struct pre_fw_load_props *pre_fw_load = >fw_loader.pre_fw_load;
- u32 status;
- int rc;
+ u32 status = 0, timeout;
+ int rc, tries = 1;
+ bool preboot_still_runs;
/* Need to check two possible scenarios:
*
@@ -1485,6 +1486,8 @@ int hl_fw_wait_preboot_ready(struct hl_device *hdev)
* All other status values - for older firmwares where the uboot was
* loaded from the FLASH
*/
+ timeout = pre_fw_load->wait_for_preboot_timeout;
+retry:
rc = hl_poll_timeout(
hdev,
pre_fw_load->cpu_boot_status_reg,
@@ -1493,7 +1496,24 @@ int hl_fw_wait_preboot_ready(struct hl_device *hdev)
(status == CPU_BOOT_STATUS_READY_TO_BOOT) ||
(status == CPU_BOOT_STATUS_WAITING_FOR_BOOT_FIT),
hdev->fw_poll_interval_usec,
- pre_fw_load->wait_for_preboot_timeout);
+ timeout);
+ /*
+* if F/W reports "security-ready" it means preboot might take longer.
+* If the field 'wait_for_preboot_extended_timeout' is non 0 we wait
again
+* with that timeout
+*/
+ preboot_still_runs = (status == CPU_BOOT_STATUS_SECURITY_READY ||
+ status == CPU_BOOT_STATUS_IN_PREBOOT ||
+ status == CPU_BOOT_STATUS_FW_SHUTDOWN_PREP ||
+ status == CPU_BOOT_STATUS_DRAM_RDY);
+
+ if (rc && tries && preboot_still_runs) {
+ tries--;
+ if (pre_fw_load->wait_for_preboot_extended_timeout) {
+ timeout =
pre_fw_load->wait_for_preboot_extended_timeout;
+ goto retry;
+ }
+ }
if (rc) {
detect_cpu_boot_status(hdev, status);
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index 874ae76cbd78..3c224942a758 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -1410,6 +1410,8 @@ struct dynamic_fw_load_mgr {
* @boot_err0_reg: boot_err0 register address
* @boot_err1_reg: boot_err1 register address
* @wait_for_preboot_timeout: timeout to poll for preboot ready
+ * @wait_for_preboot_extended_timeout: timeout to pull for preboot ready in
case where we know
+ * preboot needs longer time.
*/
struct pre_fw_load_props {
u32 cpu_boot_status_reg;
@@ -1418,6 +1420,7 @@ struct pre_fw_load_props {
u32 boot_err0_reg;
u32 boot_err1_reg;
u32 wait_for_preboot_timeout;
+ u32 wait_for_preboot_extended_timeout;
};
/**
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index 867175431418..35db02e5010b 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -4825,6 +4825,8 @@ static void gaudi2_init_firmware_preload_params(struct
hl_device *hdev)
pre_fw_load->boot_err0_reg = mmCPU_BOOT_ERR0;
pre_fw_load->boot_err1_reg = mmCPU_BOOT_ERR1;
pre_fw_load->wait_for_preboot_timeout = GAUDI2_PREBOOT_REQ_TIMEOUT_USEC;
+ pre_fw_load->wait_for_preboot_extended_timeout =
+ GAUDI2_PREBOOT_EXTENDED_REQ_TIMEOUT_USEC;
}
static void gaudi2_init_firmware_loader(struct hl_device *hdev)
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2P.h
b/drivers/accel/habanalabs/gaudi2/gaudi2P.h
index 14e281fd9895..9b9eef0d97d6 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2P.h
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2P.h
@@ -84,6 +84,7 @@
#define CORESIGHT_TIMEOUT_USEC 10 /* 100 ms */
#define GAUDI2_PREBOOT_REQ_TIMEOUT_USEC2500/* 25s
*/
+#define GAUDI2_PREBOOT_EXTENDED_REQ_TIMEOUT_USEC 8500 /* 85s */
#define GAUDI2_BOOT_FIT_REQ_TIMEOUT_USEC
[PATCH 10/10] accel/habanalabs: update boot status print
From: Ariel Suller FW shutdown preparation status was added to spec. Signed-off-by: Ariel Suller Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- drivers/accel/habanalabs/common/firmware_if.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/accel/habanalabs/common/firmware_if.c b/drivers/accel/habanalabs/common/firmware_if.c index 0fb360cca9cc..47e8384134aa 100644 --- a/drivers/accel/habanalabs/common/firmware_if.c +++ b/drivers/accel/habanalabs/common/firmware_if.c @@ -1464,6 +1464,10 @@ static void detect_cpu_boot_status(struct hl_device *hdev, u32 status) dev_err(hdev->dev, "Device boot progress - Stuck in preboot after security initialization\n"); break; + case CPU_BOOT_STATUS_FW_SHUTDOWN_PREP: + dev_err(hdev->dev, + "Device boot progress - Stuck in preparation for shutdown\n"); + break; default: dev_err(hdev->dev, "Device boot progress - Invalid or unexpected status code %d\n", status); -- 2.34.1
[PATCH 04/10] accel/habanalabs: fix SG table creation for dma-buf mapping
From: Tomer Tayar
In some cases the calculated number of required entries for the dma-buf
SG table is wrong. For example, if the page size is larger than both the
dma max segment size of the importer device and from the exported side,
or if the exported size is part of a phys_pg_pack that is composed of
several pages.
In these cases, redundant entries will be added to the SG table.
Modify the method that the number of entries is calculated, and the way
they are prepared.
Signed-off-by: Tomer Tayar
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/memory.c | 199 ---
1 file changed, 104 insertions(+), 95 deletions(-)
diff --git a/drivers/accel/habanalabs/common/memory.c
b/drivers/accel/habanalabs/common/memory.c
index d0edbe4b4210..5c1e98e73a47 100644
--- a/drivers/accel/habanalabs/common/memory.c
+++ b/drivers/accel/habanalabs/common/memory.c
@@ -1535,21 +1535,17 @@ static struct sg_table
*alloc_sgt_from_device_pages(struct hl_device *hdev, u64
u64 page_size, u64
exported_size,
struct device *dev, enum
dma_data_direction dir)
{
- u64 chunk_size, bar_address, dma_max_seg_size, cur_size_to_export,
cur_npages;
- struct asic_fixed_properties *prop;
- int rc, i, j, nents, cur_page;
+ u64 dma_max_seg_size, curr_page, size, chunk_size, left_size_to_export,
left_size_in_page,
+ left_size_in_dma_seg, device_address, bar_address;
+ struct asic_fixed_properties *prop = >asic_prop;
struct scatterlist *sg;
+ unsigned int nents, i;
struct sg_table *sgt;
+ bool next_sg_entry;
+ int rc;
- prop = >asic_prop;
-
- dma_max_seg_size = dma_get_max_seg_size(dev);
-
- /* We would like to align the max segment size to PAGE_SIZE, so the
-* SGL will contain aligned addresses that can be easily mapped to
-* an MMU
-*/
- dma_max_seg_size = ALIGN_DOWN(dma_max_seg_size, PAGE_SIZE);
+ /* Align max segment size to PAGE_SIZE to fit the minimal IOMMU mapping
granularity */
+ dma_max_seg_size = ALIGN_DOWN(dma_get_max_seg_size(dev), PAGE_SIZE);
if (dma_max_seg_size < PAGE_SIZE) {
dev_err_ratelimited(hdev->dev,
"dma_max_seg_size %llu can't be smaller than
PAGE_SIZE\n",
@@ -1561,120 +1557,133 @@ static struct sg_table
*alloc_sgt_from_device_pages(struct hl_device *hdev, u64
if (!sgt)
return ERR_PTR(-ENOMEM);
- cur_size_to_export = exported_size;
+ /* Calculate the required number of entries for the SG table */
+ curr_page = 0;
+ nents = 1;
+ left_size_to_export = exported_size;
+ left_size_in_page = page_size;
+ left_size_in_dma_seg = dma_max_seg_size;
+ next_sg_entry = false;
+
+ while (true) {
+ size = min3(left_size_to_export, left_size_in_page,
left_size_in_dma_seg);
+ left_size_to_export -= size;
+ left_size_in_page -= size;
+ left_size_in_dma_seg -= size;
+
+ if (!left_size_to_export)
+ break;
- /* If the size of each page is larger than the dma max segment size,
-* then we can't combine pages and the number of entries in the SGL
-* will just be the
-* *
-*/
- if (page_size > dma_max_seg_size) {
- /* we should limit number of pages according to the exported
size */
- cur_npages = DIV_ROUND_UP_SECTOR_T(cur_size_to_export,
page_size);
- nents = cur_npages * DIV_ROUND_UP_SECTOR_T(page_size,
dma_max_seg_size);
- } else {
- cur_npages = npages;
-
- /* Get number of non-contiguous chunks */
- for (i = 1, nents = 1, chunk_size = page_size ; i < cur_npages
; i++) {
- if (pages[i - 1] + page_size != pages[i] ||
- chunk_size + page_size >
dma_max_seg_size) {
- nents++;
- chunk_size = page_size;
- continue;
- }
+ if (!left_size_in_page) {
+ /* left_size_to_export is not zero so there must be
another page */
+ if (pages[curr_page] + page_size != pages[curr_page +
1])
+ next_sg_entry = true;
+
+ ++curr_page;
+ left_size_in_page = page_size;
+ }
- chunk_size += page_size;
+ if (!left_size_in_dma_seg) {
+ next_sg_entry = true;
+ left_size_in_dma_seg = dma_max_seg_size;
+ }
+
+ if (next_sg_entry) {
+ ++nents;
+
[PATCH 07/10] accel/habanalabs: add debug prints to dump content of SG table for dma-buf
From: Tomer Tayar Add debug prints to dump the content of the SG table which is prepared when the dma-buf map op is called. Signed-off-by: Tomer Tayar Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- drivers/accel/habanalabs/common/memory.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/accel/habanalabs/common/memory.c b/drivers/accel/habanalabs/common/memory.c index 00e73b5573be..33fb78aba812 100644 --- a/drivers/accel/habanalabs/common/memory.c +++ b/drivers/accel/habanalabs/common/memory.c @@ -1679,6 +1679,13 @@ static struct sg_table *alloc_sgt_from_device_pages(struct hl_device *hdev, u64 */ sgt->orig_nents = 0; + dev_dbg(hdev->dev, "prepared SG table with %u entries for importer %s\n", + nents, dev_name(dev)); + for_each_sgtable_dma_sg(sgt, sg, i) + dev_dbg(hdev->dev, + "SG entry %d: address %#llx, length %#x\n", + i, sg_dma_address(sg), sg_dma_len(sg)); + return sgt; err_unmap: -- 2.34.1
[PATCH 03/10] accel/habanalabs: split user interrupts pending list
From: farah kassabri
Currently driver maintain one list for both pending user interrupts
which seeks to wait till CQ reaches it's target value and also the ones
that seeks to get timestamp records when the CQ reaches it's target
value.
This causes delay in handling the waiters which gets higher priority
than the timestamp records.
In order to solve this, let's split the list into two,
one for each case and each one is protected by it's own spinlock.
Waiters will be handled within the interrupt context first,
then the timestamp records will be set.
Freeing the timestamp related memory will be handled in a workqueue.
Signed-off-by: farah kassabri
Reviewed-by: Tomer Tayar
Signed-off-by: Oded Gabbay
---
.../habanalabs/common/command_submission.c| 235 ++
drivers/accel/habanalabs/common/habanalabs.h | 12 +-
drivers/accel/habanalabs/common/irq.c | 89 ---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 20 +-
4 files changed, 209 insertions(+), 147 deletions(-)
diff --git a/drivers/accel/habanalabs/common/command_submission.c
b/drivers/accel/habanalabs/common/command_submission.c
index 02049bd26356..751d2c7d3fb8 100644
--- a/drivers/accel/habanalabs/common/command_submission.c
+++ b/drivers/accel/habanalabs/common/command_submission.c
@@ -1098,19 +1098,22 @@ static void
wake_pending_user_interrupt_threads(struct hl_user_interrupt *interrupt)
{
struct hl_user_pending_interrupt *pend, *temp;
+ unsigned long flags;
- spin_lock(>wait_list_lock);
- list_for_each_entry_safe(pend, temp, >wait_list_head,
wait_list_node) {
- if (pend->ts_reg_info.buf) {
- list_del(>wait_list_node);
- hl_mmap_mem_buf_put(pend->ts_reg_info.buf);
- hl_cb_put(pend->ts_reg_info.cq_cb);
- } else {
- pend->fence.error = -EIO;
- complete_all(>fence.completion);
- }
+ spin_lock_irqsave(>wait_list_lock, flags);
+ list_for_each_entry_safe(pend, temp, >wait_list_head,
list_node) {
+ pend->fence.error = -EIO;
+ complete_all(>fence.completion);
}
- spin_unlock(>wait_list_lock);
+ spin_unlock_irqrestore(>wait_list_lock, flags);
+
+ spin_lock_irqsave(>ts_list_lock, flags);
+ list_for_each_entry_safe(pend, temp, >ts_list_head,
list_node) {
+ list_del(>list_node);
+ hl_mmap_mem_buf_put(pend->ts_reg_info.buf);
+ hl_cb_put(pend->ts_reg_info.cq_cb);
+ }
+ spin_unlock_irqrestore(>ts_list_lock, flags);
}
void hl_release_pending_user_interrupts(struct hl_device *hdev)
@@ -3251,18 +3254,19 @@ static void unregister_timestamp_node(struct hl_device
*hdev,
{
struct hl_user_interrupt *interrupt = record->ts_reg_info.interrupt;
bool ts_rec_found = false;
+ unsigned long flags;
if (need_lock)
- spin_lock(>wait_list_lock);
+ spin_lock_irqsave(>ts_list_lock, flags);
if (record->ts_reg_info.in_use) {
record->ts_reg_info.in_use = false;
- list_del(>wait_list_node);
+ list_del(>list_node);
ts_rec_found = true;
}
if (need_lock)
- spin_unlock(>wait_list_lock);
+ spin_unlock_irqrestore(>ts_list_lock, flags);
/* Put refcounts that were taken when we registered the event */
if (ts_rec_found) {
@@ -3272,7 +3276,7 @@ static void unregister_timestamp_node(struct hl_device
*hdev,
}
static int ts_get_and_handle_kernel_record(struct hl_device *hdev, struct
hl_ctx *ctx,
- struct wait_interrupt_data *data,
+ struct wait_interrupt_data *data,
unsigned long *flags,
struct hl_user_pending_interrupt **pend)
{
struct hl_user_pending_interrupt *req_offset_record;
@@ -3302,13 +3306,13 @@ static int ts_get_and_handle_kernel_record(struct
hl_device *hdev, struct hl_ctx
req_offset_record->ts_reg_info.interrupt->interrupt_id) {
need_lock = true;
- spin_unlock(>interrupt->wait_list_lock);
+ spin_unlock_irqrestore(>interrupt->ts_list_lock,
*flags);
}
unregister_timestamp_node(hdev, req_offset_record, need_lock);
if (need_lock)
- spin_lock(>interrupt->wait_list_lock);
+ spin_lock_irqsave(>interrupt->ts_list_lock,
*flags);
}
/* Fill up the new registration node info and add it to the list */
@@ -3325,18 +3329,14 @@ static int ts_get_and_handle_kernel_record(struct
hl_device *hdev, struct hl_ctx
return rc;
}
-static int _hl_interrupt_wait_ioctl(struct hl_device *hdev, struct hl_ctx *ctx,
+static
[PATCH 02/10] accel/habanalabs: optimize timestamp registration handler
From: farah kassabri
Currently we use dynamic allocation inside the irq handler
in order to allocate free node to be used for the free jobs.
This operation is expensive, especially when we deal with large
burst of events records that get released at the same time.
The alternative is to have pre allocated pool of free nodes
and just fetch nodes from this pool at irq handling time instead
of allocating them.
In case the pool becomes full, then the driver will fallback to
dynamic allocations.
As part of the optimization also update the unregister flow
upon re-using a timestamp record, by making the operation much
simpler and quicker. We already have the record in the registration
flow and now we just seek to re-use with different interrupt.
Therefore, no need to look for buffer according to the user handle.
Signed-off-by: farah kassabri
Reviewed-by: Tomer Tayar
Signed-off-by: Oded Gabbay
---
.../habanalabs/common/command_submission.c| 83 +++
drivers/accel/habanalabs/common/device.c | 59 -
drivers/accel/habanalabs/common/habanalabs.h | 27 ++
drivers/accel/habanalabs/common/irq.c | 77 ++---
4 files changed, 179 insertions(+), 67 deletions(-)
diff --git a/drivers/accel/habanalabs/common/command_submission.c
b/drivers/accel/habanalabs/common/command_submission.c
index daaa3cbe0b12..02049bd26356 100644
--- a/drivers/accel/habanalabs/common/command_submission.c
+++ b/drivers/accel/habanalabs/common/command_submission.c
@@ -3246,60 +3246,29 @@ static int validate_and_get_ts_record(struct device
*dev,
return 0;
}
-static int unregister_timestamp_node(struct hl_device *hdev, struct hl_ctx
*ctx,
- struct hl_mem_mgr *mmg, u64 ts_handle, u64 ts_offset,
- struct hl_user_interrupt *interrupt)
+static void unregister_timestamp_node(struct hl_device *hdev,
+ struct hl_user_pending_interrupt *record, bool
need_lock)
{
- struct hl_user_pending_interrupt *req_event_record, *pend, *temp_pend;
- struct hl_mmap_mem_buf *buff;
- struct hl_ts_buff *ts_buff;
+ struct hl_user_interrupt *interrupt = record->ts_reg_info.interrupt;
bool ts_rec_found = false;
- int rc;
-
- buff = hl_mmap_mem_buf_get(mmg, ts_handle);
- if (!buff) {
- dev_err(hdev->dev, "invalid TS buff handle!\n");
- return -EINVAL;
- }
-
- ts_buff = buff->private;
-
- rc = validate_and_get_ts_record(hdev->dev, ts_buff, ts_offset,
_event_record);
- if (rc)
- goto put_buf;
- /*
-* Note: we don't use the ts in_use field here, but we rather scan the
list
-* because we cannot rely on the user to keep the order of
register/unregister calls
-* and since we might have races here all the time between the irq and
register/unregister
-* calls so it safer to lock the list and scan it to find the node.
-* If the node found on the list we mark it as not in use and delete it
from the list,
-* if it's not here then the node was handled already in the irq before
we get into
-* this ioctl.
-*/
- spin_lock(>wait_list_lock);
+ if (need_lock)
+ spin_lock(>wait_list_lock);
- list_for_each_entry_safe(pend, temp_pend, >wait_list_head,
wait_list_node) {
- if (pend == req_event_record) {
- pend->ts_reg_info.in_use = false;
- list_del(>wait_list_node);
- ts_rec_found = true;
- break;
- }
+ if (record->ts_reg_info.in_use) {
+ record->ts_reg_info.in_use = false;
+ list_del(>wait_list_node);
+ ts_rec_found = true;
}
- spin_unlock(>wait_list_lock);
+ if (need_lock)
+ spin_unlock(>wait_list_lock);
/* Put refcounts that were taken when we registered the event */
if (ts_rec_found) {
- hl_mmap_mem_buf_put(pend->ts_reg_info.buf);
- hl_cb_put(pend->ts_reg_info.cq_cb);
+ hl_mmap_mem_buf_put(record->ts_reg_info.buf);
+ hl_cb_put(record->ts_reg_info.cq_cb);
}
-
-put_buf:
- hl_mmap_mem_buf_put(buff);
-
- return rc;
}
static int ts_get_and_handle_kernel_record(struct hl_device *hdev, struct
hl_ctx *ctx,
@@ -3308,6 +3277,7 @@ static int ts_get_and_handle_kernel_record(struct
hl_device *hdev, struct hl_ctx
{
struct hl_user_pending_interrupt *req_offset_record;
struct hl_ts_buff *ts_buff = data->buf->private;
+ bool need_lock = false;
int rc;
rc = validate_and_get_ts_record(data->buf->mmg->dev, ts_buff,
data->ts_offset,
@@ -3315,21 +3285,30 @@ static int ts_get_and_handle_kernel_record(struct
hl_device *hdev, struct hl_ctx
if (rc)
return rc;
- /* In case the node
[PATCH 06/10] accel/habanalabs: add missing offset handling for dma-buf
From: Tomer Tayar
On devices with virtual device memory (Gaudi2 onwards), user can provide
an offset within an allocated device memory from which he wants to
export a dma-buf object.
The offset value is verified by driver, but it is not taken into
consideration when the importer driver maps the dma-buf and the SG table
it prepared.
Add the missing offset handling.
Signed-off-by: Tomer Tayar
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/habanalabs.h | 3 +
drivers/accel/habanalabs/common/memory.c | 75 +++-
2 files changed, 43 insertions(+), 35 deletions(-)
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index 43e682cdeb75..874ae76cbd78 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -1811,6 +1811,8 @@ struct hl_cs_counters_atomic {
* @phys_pg_pack: pointer to physical page pack if the dma-buf was exported
*where virtual memory is supported.
* @memhash_hnode: pointer to the memhash node. this object holds the export
count.
+ * @offset: the offset into the buffer from which the memory is exported.
+ * Relevant only if virtual memory is supported and phys_pg_pack is
being used.
* device_phys_addr: physical address of the device's memory. Relevant only
* if phys_pg_pack is NULL (dma-buf was exported from
address).
* The total size can be taken from the dmabuf object.
@@ -1820,6 +1822,7 @@ struct hl_dmabuf_priv {
struct hl_ctx *ctx;
struct hl_vm_phys_pg_pack *phys_pg_pack;
struct hl_vm_hash_node *memhash_hnode;
+ u64 offset;
u64 device_phys_addr;
};
diff --git a/drivers/accel/habanalabs/common/memory.c
b/drivers/accel/habanalabs/common/memory.c
index dc5ff3e74c39..00e73b5573be 100644
--- a/drivers/accel/habanalabs/common/memory.c
+++ b/drivers/accel/habanalabs/common/memory.c
@@ -1532,11 +1532,11 @@ static int set_dma_sg(struct scatterlist *sg, u64
bar_address, u64 chunk_size,
}
static struct sg_table *alloc_sgt_from_device_pages(struct hl_device *hdev,
u64 *pages, u64 npages,
- u64 page_size, u64
exported_size,
+ u64 page_size, u64
exported_size, u64 offset,
struct device *dev, enum
dma_data_direction dir)
{
u64 dma_max_seg_size, curr_page, size, chunk_size, left_size_to_export,
left_size_in_page,
- left_size_in_dma_seg, device_address, bar_address;
+ left_size_in_dma_seg, device_address, bar_address, start_page;
struct asic_fixed_properties *prop = >asic_prop;
struct scatterlist *sg;
unsigned int nents, i;
@@ -1557,11 +1557,20 @@ static struct sg_table
*alloc_sgt_from_device_pages(struct hl_device *hdev, u64
if (!sgt)
return ERR_PTR(-ENOMEM);
+ /* Use the offset to move to the actual first page that is exported */
+ for (start_page = 0 ; start_page < npages ; ++start_page) {
+ if (offset < page_size)
+ break;
+
+ /* The offset value was validated so there can't be an
underflow */
+ offset -= page_size;
+ }
+
/* Calculate the required number of entries for the SG table */
- curr_page = 0;
+ curr_page = start_page;
nents = 1;
left_size_to_export = exported_size;
- left_size_in_page = page_size;
+ left_size_in_page = page_size - offset;
left_size_in_dma_seg = dma_max_seg_size;
next_sg_entry = false;
@@ -1599,10 +1608,10 @@ static struct sg_table
*alloc_sgt_from_device_pages(struct hl_device *hdev, u64
goto err_free_sgt;
/* Prepare the SG table entries */
- curr_page = 0;
- device_address = pages[curr_page];
+ curr_page = start_page;
+ device_address = pages[curr_page] + offset;
left_size_to_export = exported_size;
- left_size_in_page = page_size;
+ left_size_in_page = page_size - offset;
left_size_in_dma_seg = dma_max_seg_size;
next_sg_entry = false;
@@ -1708,7 +1717,7 @@ static int hl_dmabuf_attach(struct dma_buf *dmabuf,
static struct sg_table *hl_map_dmabuf(struct dma_buf_attachment *attachment,
enum dma_data_direction dir)
{
- u64 *pages, npages, page_size, exported_size;
+ u64 *pages, npages, page_size, exported_size, offset;
struct dma_buf *dma_buf = attachment->dmabuf;
struct hl_vm_phys_pg_pack *phys_pg_pack;
struct hl_dmabuf_priv *hl_dmabuf;
@@ -1723,6 +1732,7 @@ static struct sg_table *hl_map_dmabuf(struct
dma_buf_attachment *attachment,
hl_dmabuf =
[PATCH 08/10] accel/habanalabs: add fw status SHUTDOWN_PREP
From: Dafna Hirschfeld
update hl_boot_if.h from specs to include
CPU_BOOT_STATUS_FW_SHUTDOWN_PREP
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
include/linux/habanalabs/hl_boot_if.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/habanalabs/hl_boot_if.h
b/include/linux/habanalabs/hl_boot_if.h
index 7de8a5786a36..93366d5621fd 100644
--- a/include/linux/habanalabs/hl_boot_if.h
+++ b/include/linux/habanalabs/hl_boot_if.h
@@ -394,6 +394,8 @@ enum cpu_boot_status {
CPU_BOOT_STATUS_WAITING_FOR_BOOT_FIT = 16,
/* Internal Security has been initialized, device can be accessed */
CPU_BOOT_STATUS_SECURITY_READY = 17,
+ /* FW component is preparing to shutdown and communication with host is
not available */
+ CPU_BOOT_STATUS_FW_SHUTDOWN_PREP = 18,
};
enum kmd_msg {
--
2.34.1
[PATCH 01/10] accel/habanalabs: fix bug in timestamp interrupt handling
From: farah kassabri There is a potential race between user thread seeking to re-use a timestamp record with new interrupt id, while this record is still in the middle of interrupt handling and it is about to be freed. Imagine the driver set the record in_use to 0 and only then fill the free_node information. This might lead to unpleasant scenario where the new registration thread detects the record as free to use, and change the cq buff address. That will cause the free_node to get the wrong buffer address to put refcount to. Signed-off-by: farah kassabri Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- drivers/accel/habanalabs/common/irq.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/accel/habanalabs/common/irq.c b/drivers/accel/habanalabs/common/irq.c index f6b6c54bc868..058f27040805 100644 --- a/drivers/accel/habanalabs/common/irq.c +++ b/drivers/accel/habanalabs/common/irq.c @@ -259,8 +259,6 @@ static int handle_registration_node(struct hl_device *hdev, struct hl_user_pendi dev_dbg(hdev->dev, "Irq handle: Timestamp record (%p) ts cb address (%p), interrupt_id: %u\n", pend, pend->ts_reg_info.timestamp_kernel_addr, interrupt_id); - /* Mark kernel CB node as free */ - pend->ts_reg_info.in_use = false; list_del(>wait_list_node); /* Putting the refcount for ts_buff and cq_cb objects will be handled @@ -270,6 +268,9 @@ static int handle_registration_node(struct hl_device *hdev, struct hl_user_pendi free_node->cq_cb = pend->ts_reg_info.cq_cb; list_add(_node->free_objects_node, *free_list); + /* Mark TS record as free */ + pend->ts_reg_info.in_use = false; + return 0; } -- 2.34.1
Re: ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/dp_mst: Fix NULL dereference during payload addition
On Thu, Sep 14, 2023 at 06:01:49AM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/4] drm/dp_mst: Fix NULL dereference during
> payload addition
> URL : https://patchwork.freedesktop.org/series/123652/
> State : failure
Thanks for the reviews, patches 1-3 are pushed to drm-misc-next and
patch 4 to drm-intel-next.
All the failures below are unrelated, since none of the affected
platforms has MST sinks.
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_13627_full -> Patchwork_123652v1_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_123652v1_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_123652v1_full, please notify your bug team
> (lgci.bug.fil...@intel.com) to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (9 -> 10)
> --
>
> Additional (1): shard-rkl0
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_123652v1_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gen9_exec_parse@allowed-all:
> - shard-apl: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13627/shard-apl3/igt@gen9_exec_pa...@allowed-all.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123652v1/shard-apl6/igt@gen9_exec_pa...@allowed-all.html
>
> * igt@gen9_exec_parse@allowed-single:
> - shard-glk: [PASS][3] -> [INCOMPLETE][4]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13627/shard-glk7/igt@gen9_exec_pa...@allowed-single.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123652v1/shard-glk6/igt@gen9_exec_pa...@allowed-single.html
>
> * igt@kms_plane_cursor@overlay@pipe-b-edp-1-size-64:
> - shard-mtlp: [PASS][5] -> [FAIL][6]
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13627/shard-mtlp-6/igt@kms_plane_cursor@over...@pipe-b-edp-1-size-64.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123652v1/shard-mtlp-5/igt@kms_plane_cursor@over...@pipe-b-edp-1-size-64.html
>
> * igt@kms_rotation_crc@sprite-rotation-90:
> - shard-rkl: [PASS][7] -> [INCOMPLETE][8] +1 other test
> incomplete
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13627/shard-rkl-4/igt@kms_rotation_...@sprite-rotation-90.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123652v1/shard-rkl-7/igt@kms_rotation_...@sprite-rotation-90.html
>
> * igt@perf_pmu@rc6-all-gts:
> - shard-mtlp: NOTRUN -> [ABORT][9]
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123652v1/shard-mtlp-6/igt@perf_...@rc6-all-gts.html
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@kms_feature_discovery@display-4x}:
> - shard-mtlp: NOTRUN -> [SKIP][10]
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123652v1/shard-mtlp-6/igt@kms_feature_discov...@display-4x.html
>
> * {igt@kms_feature_discovery@dp-mst}:
> - shard-dg2: NOTRUN -> [SKIP][11]
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123652v1/shard-dg2-11/igt@kms_feature_discov...@dp-mst.html
>
>
> New tests
> -
>
> New tests have been introduced between CI_DRM_13627_full and
> Patchwork_123652v1_full:
>
> ### New IGT tests (4) ###
>
> *
> igt@kms_atomic_transition@plane-all-transition-nonblocking@pipe-a-hdmi-a-4:
> - Statuses : 1 pass(s)
> - Exec time: [0.0] s
>
> *
> igt@kms_atomic_transition@plane-all-transition-nonblocking@pipe-b-hdmi-a-4:
> - Statuses : 1 pass(s)
> - Exec time: [0.0] s
>
> * igt@kms_cursor_crc@cursor-onscreen-128x128@pipe-a-hdmi-a-4:
> - Statuses : 1 pass(s)
> - Exec time: [0.0] s
>
> * igt@kms_cursor_crc@cursor-onscreen-128x128@pipe-d-hdmi-a-4:
> - Statuses : 1 pass(s)
> - Exec time: [0.0] s
>
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_123652v1_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@drm_fdinfo@most-busy-check-all@bcs0:
> - shard-dg2: NOTRUN -> [SKIP][12] ([i915#8414]) +21 other tests
> skip
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123652v1/shard-dg2-7/igt@drm_fdinfo@most-busy-check-...@bcs0.html
>
> * igt@drm_fdinfo@virtual-busy-hang:
> - shard-mtlp: NOTRUN -> [SKIP][13] ([i915#8414]) +1 other test
> skip
>[13]:
>
Re: [PATCH] drm/ssd130x: Drop _helper prefix from struct drm_*_helper_funcs callbacks
Hi
Am 14.09.23 um 21:51 schrieb Javier Martinez Canillas:
The driver uses a naming convention where functions for struct drm_*_funcs
callbacks are named ssd130x_$object_$operation, while the callbacks for
struct drm_*_helper_funcs are named ssd130x_$object_helper_$operation.
The idea is that this helper_ prefix in the function names denote that are
for struct drm_*_helper_funcs callbacks. This convention was copied from
other drivers, when ssd130x was written but Maxime pointed out that is the
exception rather than the norm.
I guess you found this in my code. I want to point out that I use the
_helper infix to signal that these are callback for
drm_primary_plane_helper_funcs and *not* drm_primary_plane_funcs. The
naming is intentional.
Best regards
Thomas
So let's get rid of the _helper prefixes from the function handlers names.
Suggested-by: Maxime Ripard
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.c | 46 +++
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index 8ab02724f65f..245e4ba1c041 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -630,8 +630,8 @@ static int ssd130x_fb_blit_rect(struct drm_framebuffer *fb,
return ret;
}
-static int ssd130x_primary_plane_helper_atomic_check(struct drm_plane *plane,
-struct drm_atomic_state
*state)
+static int ssd130x_primary_plane_atomic_check(struct drm_plane *plane,
+ struct drm_atomic_state *state)
{
struct drm_device *drm = plane->dev;
struct ssd130x_device *ssd130x = drm_to_ssd130x(drm);
@@ -667,8 +667,8 @@ static int ssd130x_primary_plane_helper_atomic_check(struct
drm_plane *plane,
return 0;
}
-static void ssd130x_primary_plane_helper_atomic_update(struct drm_plane *plane,
- struct drm_atomic_state
*state)
+static void ssd130x_primary_plane_atomic_update(struct drm_plane *plane,
+ struct drm_atomic_state *state)
{
struct drm_plane_state *plane_state =
drm_atomic_get_new_plane_state(state, plane);
struct drm_plane_state *old_plane_state =
drm_atomic_get_old_plane_state(state, plane);
@@ -701,8 +701,8 @@ static void
ssd130x_primary_plane_helper_atomic_update(struct drm_plane *plane,
drm_dev_exit(idx);
}
-static void ssd130x_primary_plane_helper_atomic_disable(struct drm_plane *plane,
- struct drm_atomic_state
*state)
+static void ssd130x_primary_plane_atomic_disable(struct drm_plane *plane,
+struct drm_atomic_state *state)
{
struct drm_device *drm = plane->dev;
struct ssd130x_device *ssd130x = drm_to_ssd130x(drm);
@@ -777,9 +777,9 @@ static void ssd130x_primary_plane_destroy_state(struct
drm_plane *plane,
static const struct drm_plane_helper_funcs ssd130x_primary_plane_helper_funcs = {
DRM_GEM_SHADOW_PLANE_HELPER_FUNCS,
- .atomic_check = ssd130x_primary_plane_helper_atomic_check,
- .atomic_update = ssd130x_primary_plane_helper_atomic_update,
- .atomic_disable = ssd130x_primary_plane_helper_atomic_disable,
+ .atomic_check = ssd130x_primary_plane_atomic_check,
+ .atomic_update = ssd130x_primary_plane_atomic_update,
+ .atomic_disable = ssd130x_primary_plane_atomic_disable,
};
static const struct drm_plane_funcs ssd130x_primary_plane_funcs = {
@@ -791,8 +791,8 @@ static const struct drm_plane_funcs
ssd130x_primary_plane_funcs = {
.destroy = drm_plane_cleanup,
};
-static enum drm_mode_status ssd130x_crtc_helper_mode_valid(struct drm_crtc *crtc,
- const struct
drm_display_mode *mode)
+static enum drm_mode_status ssd130x_crtc_mode_valid(struct drm_crtc *crtc,
+ const struct
drm_display_mode *mode)
{
struct ssd130x_device *ssd130x = drm_to_ssd130x(crtc->dev);
@@ -807,8 +807,8 @@ static enum drm_mode_status ssd130x_crtc_helper_mode_valid(struct drm_crtc *crtc
return MODE_OK;
}
-static int ssd130x_crtc_helper_atomic_check(struct drm_crtc *crtc,
- struct drm_atomic_state *state)
+static int ssd130x_crtc_atomic_check(struct drm_crtc *crtc,
+struct drm_atomic_state *state)
{
struct drm_device *drm = crtc->dev;
struct ssd130x_device *ssd130x = drm_to_ssd130x(drm);
@@ -882,8 +882,8 @@ static void ssd130x_crtc_destroy_state(struct drm_crtc
*crtc,
* the screen in the primary plane's atomic_disable function.
*/
static const struct drm_crtc_helper_funcs
Re: [PATCH] drm/ssd130x: Drop _helper prefix from struct drm_*_helper_funcs callbacks
Thomas Zimmermann writes: > Hi > > Am 14.09.23 um 21:51 schrieb Javier Martinez Canillas: >> The driver uses a naming convention where functions for struct drm_*_funcs >> callbacks are named ssd130x_$object_$operation, while the callbacks for >> struct drm_*_helper_funcs are named ssd130x_$object_helper_$operation. >> >> The idea is that this helper_ prefix in the function names denote that are >> for struct drm_*_helper_funcs callbacks. This convention was copied from >> other drivers, when ssd130x was written but Maxime pointed out that is the >> exception rather than the norm. > > I guess you found this in my code. I want to point out that I use the > _helper infix to signal that these are callback for > drm_primary_plane_helper_funcs and *not* drm_primary_plane_funcs. The > naming is intentional. > Yes, that's what tried to say in the commit message and indeed I got the convention from drivers in drivers/gpu/drm/tiny. In fact I believe these function names are since first iteration of the driver, when was meant to be a tiny driver. According to Maxime it's the exception rather than the rule and suggested to change it, I don't really have a strong opinion on either naming TBH. > Best regards > Thomas > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v9 4/7] drm/mediatek: Add encoder_index function to mtk_ddp_comp_funcs for dpi
Re: [PATCH] drm: fix up fbdev Kconfig defaults
Hi
Am 11.09.23 um 22:52 schrieb Arnd Bergmann:
From: Arnd Bergmann
As a result of the recent Kconfig reworks, the default settings for the
framebuffer interfaces changed in unexpected ways:
Configurations that leave CONFIG_FB disabled but use DRM now get
DRM_FBDEV_EMULATION by default. This also turns on the deprecated /dev/fb
device nodes for machines that don't actually want it.
In turn, configurations that previously had DRM_FBDEV_EMULATION enabled
now only get the /dev/fb front-end but not the more useful framebuffer
console, which is not selected any more.
We had previously decided that any combination of the three frontends
(FB_DEVICE, FRAMEBUFFER_CONSOLE and LOGO) should be selectable, but the
new default settings mean that a lot of defconfig files would have to
get adapted.
Change the defaults back to what they were in Linux 6.5:
- Leave DRM_FBDEV_EMULATION turned off unless CONFIG_FB
is enabled. Previously this was a hard dependency but now the two are
independent. However, configurations that enable CONFIG_FB probably
also want to keep the emulation for DRM, while those without FB
presumably did that intentionally in the past.
- Leave FB_DEVICE turned off for FB=n. Following the same
logic, the deprecated option should not automatically get enabled
here, most users that had FB turned off in the past do not want it,
even if they want the console
- Turn the FRAMEBUFFER_CONSOLE option on if
DRM_FBDEV_EMULATION is set to avoid having to change defconfig
files that relied on it being selected unconditionally in the past.
This also makes sense since both LOGO and FB_DEVICE are now disabled
by default for builds without CONFIG_FB, but DRM_FBDEV_EMULATION
would make no sense if all three are disabled.
Fixes: a5ae331edb02b ("drm: Drop select FRAMEBUFFER_CONSOLE for
DRM_FBDEV_EMULATION")
Fixes: 701d2054fa317 ("fbdev: Make support for userspace interfaces
configurable")
Reported-by: Geert Uytterhoeven
Signed-off-by: Arnd Bergmann
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/video/console/Kconfig| 1 +
drivers/video/fbdev/core/Kconfig | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 7df8b6875b121..144a9a1d31cea 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -135,7 +135,7 @@ config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
- default y
+ default FB
help
Choose this option if you have a need for the legacy fbdev
support. Note that this support also provides the linux console
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index b575cf54174af..83c2d7329ca58 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -74,6 +74,7 @@ config DUMMY_CONSOLE_ROWS
config FRAMEBUFFER_CONSOLE
bool "Framebuffer Console support"
depends on FB_CORE && !UML
+ default DRM_FBDEV_EMULATION
select VT_HW_CONSOLE_BINDING
select CRC32
select FONT_SUPPORT
diff --git a/drivers/video/fbdev/core/Kconfig b/drivers/video/fbdev/core/Kconfig
index 114cb8aa6c8fd..804c2bec9b43c 100644
--- a/drivers/video/fbdev/core/Kconfig
+++ b/drivers/video/fbdev/core/Kconfig
@@ -28,7 +28,7 @@ config FIRMWARE_EDID
config FB_DEVICE
bool "Provide legacy /dev/fb* device"
depends on FB_CORE
- default y
+ default FB
help
Say Y here if you want the legacy /dev/fb* device file and
interfaces within sysfs anc procfs. It is only required if you
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH] accel/habanalabs: refactor deprecated strncpy
On Fri, Aug 25, 2023 at 12:19 PM Stanislaw Gruszka wrote: > > On Wed, Aug 23, 2023 at 12:23:08AM +, Justin Stitt wrote: > > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > > > A suitable replacement is `strscpy` [2] due to the fact that it > > guarantees NUL-termination on its destination buffer argument which is > > _not_ the case for `strncpy`! > > > > There is likely no bug happening in this case since HL_STR_MAX is > > strictly larger than all source strings. Nonetheless, prefer a safer and > > more robust interface. > > > > It should also be noted that `strscpy` will not pad like `strncpy`. If > > this NUL-padding behavior is _required_ we should use `strscpy_pad` > > instead of `strscpy`. > > > > Link: > > www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings[1] > > Link: > > https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > > Link: https://github.com/KSPP/linux/issues/90 > > Cc: linux-harden...@vger.kernel.org > > Signed-off-by: Justin Stitt > Reviewed-by: Stanislaw Gruszka > Applied to -next Thanks, Oded
Re: [PATCH for-next v2 02/10] PM: Update EXPORT_*_DEV_PM_OPS() to EXPORT_*_RUNTIME_PM_OPS()
Hi Raag,
Le lundi 18 septembre 2023 à 13:39 +0530, Raag Jadav a écrit :
> Rename EXPORT_*_DEV_PM_OPS() macros to EXPORT_*_RUNTIME_PM_OPS()
> and while at it, move them to pm_runtime.h.
> This is done in conjunction with the introduction of
> EXPORT_*_SIMPLE_PM_OPS() set of macros, to make things less
> confusing.
> This makes both _RUNTIME_ and _SIMPLE_ variants of export macros more
> distinguishable and self explanatory.
Well I don't really agree with this one. The EXPORT_*_DEV_PM_OPS() can
be used with any callback you need, not just the typical runtime-PM
callbacks. They are generic PM macros.
Cheers,
-Paul
>
> Signed-off-by: Raag Jadav
> ---
> include/linux/pm.h | 5 -
> include/linux/pm_runtime.h | 13 +
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/pm.h b/include/linux/pm.h
> index 6e7ab6950ad1..9ab051f3a351 100644
> --- a/include/linux/pm.h
> +++ b/include/linux/pm.h
> @@ -398,11 +398,6 @@ const struct dev_pm_ops name = { \
> #define _EXPORT_SIMPLE_PM_OPS(name, license, ns) _PM_OPS(name,
> license, ns)
> #endif
>
> -#define
> EXPORT_DEV_PM_OPS(name)_EXPORT_RUNTIM
> E_PM_OPS(name, "", "")
> -#define
> EXPORT_GPL_DEV_PM_OPS(name)_EXPORT_RUNTIME_PM_OPS
> (name, "GPL", "")
> -#define EXPORT_NS_DEV_PM_OPS(name,
> ns) _EXPORT_RUNTIME_PM_OPS(name, "", #ns)
> -#define EXPORT_NS_GPL_DEV_PM_OPS(name,
> ns) _EXPORT_RUNTIME_PM_OPS(name, "GPL", #ns)
> -
> #define
> EXPORT_SIMPLE_PM_OPS(name) _EXPORT_SIMPLE_PM_OPS(
> name, "", "")
> #define
> EXPORT_GPL_SIMPLE_PM_OPS(name) _EXPORT_SIMPLE_PM_OPS(
> name, "GPL", "")
> #define EXPORT_NS_SIMPLE_PM_OPS(name,
> ns) _EXPORT_SIMPLE_PM_OPS(name, "", #ns)
> diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
> index 7c9b35448563..0b73b00bd59f 100644
> --- a/include/linux/pm_runtime.h
> +++ b/include/linux/pm_runtime.h
> @@ -22,6 +22,11 @@
> usage_count */
> #define RPM_AUTO 0x08/* Use autosuspend_delay */
>
> +#define
> EXPORT_RUNTIME_PM_OPS(name)_EXPORT_RUNTIME_PM_OPS
> (name, "", "")
> +#define
> EXPORT_GPL_RUNTIME_PM_OPS(name)_EXPORT_RUNTIM
> E_PM_OPS(name, "GPL", "")
> +#define EXPORT_NS_RUNTIME_PM_OPS(name,
> ns) _EXPORT_RUNTIME_PM_OPS(name, "", #ns)
> +#define EXPORT_NS_GPL_RUNTIME_PM_OPS(name,
> ns) _EXPORT_RUNTIME_PM_OPS(name, "GPL", #ns)
> +
> /*
> * Use this for defining a set of PM operations to be used in all
> situations
> * (system suspend, hibernation or runtime PM).
> @@ -40,19 +45,19 @@
> resume_fn, idle_fn)
>
> #define EXPORT_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn,
> idle_fn) \
> - EXPORT_DEV_PM_OPS(name) = { \
> + EXPORT_RUNTIME_PM_OPS(name) = { \
> RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \
> }
> #define EXPORT_GPL_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn,
> idle_fn) \
> - EXPORT_GPL_DEV_PM_OPS(name) = { \
> + EXPORT_GPL_RUNTIME_PM_OPS(name) = { \
> RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \
> }
> #define EXPORT_NS_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn,
> idle_fn, ns) \
> - EXPORT_NS_DEV_PM_OPS(name, ns) = { \
> + EXPORT_NS_RUNTIME_PM_OPS(name, ns) = { \
> RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \
> }
> #define EXPORT_NS_GPL_RUNTIME_DEV_PM_OPS(name, suspend_fn,
> resume_fn, idle_fn, ns) \
> - EXPORT_NS_GPL_DEV_PM_OPS(name, ns) = { \
> + EXPORT_NS_GPL_RUNTIME_PM_OPS(name, ns) = { \
> RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \
> }
>
Re: [PATCH v3 1/4] drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
On 12.09.2023 14:54, Christian König wrote:
Am 12.09.23 um 13:49 schrieb Karolina Stolarek:
Test initialization of ttm_resource using different memory domains.
Add tests for a system memory manager and functions that can be
tested without a fully-featured resource manager. Update
ttm_bo_kunit_init() to initialize BO's kref and reservation object.
Export ttm_resource_alloc symbol for test purposes only.
Signed-off-by: Karolina Stolarek
---
drivers/gpu/drm/ttm/tests/Makefile | 1 +
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 23 ++
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 4 +
drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 ++
drivers/gpu/drm/ttm/ttm_resource.c | 3 +
5 files changed, 366 insertions(+)
create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
diff --git a/drivers/gpu/drm/ttm/tests/Makefile
b/drivers/gpu/drm/ttm/tests/Makefile
index ec87c4fc1ad5..c92fe2052ef6 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -3,4 +3,5 @@
obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
ttm_device_test.o \
ttm_pool_test.o \
+ ttm_resource_test.o \
ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 81661d8827aa..eccc59b981f8 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -38,10 +38,33 @@ struct ttm_buffer_object *ttm_bo_kunit_init(struct
kunit *test,
bo->base = gem_obj;
bo->bdev = devs->ttm_dev;
+ kref_init(>kref);
+
+ dma_resv_init(>base._resv);
+ bo->base.resv = >base._resv;
+
I'm really wondering if we shouldn't now initialize the GEM object
properly?
That would also initialize the reservation object if I remember correctly.
Do you mean by using drm_gem_object_init()?
The solution with EXPORT_SYMBOL_FOR_TESTS_ONLY looks really nice I think
and apart from that I can't see anything obviously wrong either, but I
only skimmed over the code.
I'm also glad with EXPORT_SYMBOL_FOR_TESTS_ONLY solution, it's much
better now. Right, you can take a closer look at the next version. I'll
try to get an actual GEM object here, if you think that's feasible.
All the best,
Karolina
Regards,
Christian.
return bo;
}
EXPORT_SYMBOL_GPL(ttm_bo_kunit_init);
+struct ttm_place *ttm_place_kunit_init(struct kunit *test,
+ uint32_t mem_type, uint32_t flags,
+ size_t size)
+{
+ struct ttm_place *place;
+
+ place = kunit_kzalloc(test, sizeof(*place), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, place);
+
+ place->mem_type = mem_type;
+ place->flags = flags;
+ place->fpfn = size >> PAGE_SHIFT;
+ place->lpfn = place->fpfn + (size >> PAGE_SHIFT);
+
+ return place;
+}
+EXPORT_SYMBOL_GPL(ttm_place_kunit_init);
+
struct ttm_test_devices *ttm_test_devices_basic(struct kunit *test)
{
struct ttm_test_devices *devs;
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
index e261e3660d0b..f38140f93c05 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,6 +29,9 @@ int ttm_device_kunit_init(struct ttm_test_devices
*priv,
struct ttm_buffer_object *ttm_bo_kunit_init(struct kunit *test,
struct ttm_test_devices *devs,
size_t size);
+struct ttm_place *ttm_place_kunit_init(struct kunit *test,
+ uint32_t mem_type, uint32_t flags,
+ size_t size);
struct ttm_test_devices *ttm_test_devices_basic(struct kunit *test);
struct ttm_test_devices *ttm_test_devices_all(struct kunit *test);
diff --git a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
new file mode 100644
index ..851cdc43dc37
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
@@ -0,0 +1,335 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include
+
+#include "ttm_kunit_helpers.h"
+
+#define RES_SIZE SZ_4K
+#define TTM_PRIV_DUMMY_REG (TTM_NUM_MEM_TYPES - 1)
+
+struct ttm_resource_test_case {
+ const char *description;
+ uint32_t mem_type;
+ uint32_t flags;
+};
+
+struct ttm_resource_test_priv {
+ struct ttm_test_devices *devs;
+ struct ttm_buffer_object *bo;
+ struct ttm_place *place;
+};
+
+static const struct ttm_resource_manager_func
ttm_resource_manager_mock_funcs = { };
+
+static int ttm_resource_test_init(struct kunit *test)
+{
+ struct ttm_resource_test_priv *priv;
+
+ priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, priv);
+
+ priv->devs =
Re: [PATCH v2 02/11] soc: mediatek: Support GCE jump to absolute
Re: [PATCH 1/1] drm/mediatek: Fix errors when reporting rotation capability
Il 18/09/23 09:10, Hsiao Chien Sung ha scritto:
For CRTCs that doesn't support rotation should still return
DRM_MODE_ROTATE_0. Since both OVL and OVL adaptor on MTK chip
doesn't support rotation, return the capability of the
hardware accordingly.
Fixes: df577118 ("drm/mediatek: Support 180 degree rotation")
Fixes: 84d805753983 ("drm/mediatek: Support reflect-y plane rotation")
Signed-off-by: Hsiao Chien Sung
Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v2 04/11] drm/mediatek: Add OVL compatible name for MT8195
Il 18/09/23 11:09, CK Hu (胡俊光) ha scritto:
On Mon, 2023-09-18 at 16:42 +0800, Hsiao Chien Sung wrote:
Add OVL compatible name for MT8195.
Reviewed-by: CK Hu
but it's weird to put this patch into IGT series. Without this patch,
mt8195 drm driver does not work not only IGT.
The driver does work because the devicetree node declares two compatibles,
"mediatek,mt8195-disp-ovl", "mediatek,mt8183-disp-ovl" where the second
compatible is matched in mtk_drm_drv, and the first is matched in mtk_disp_ovl
as both are platform_driver.
This commit is not necessary, even... :-)
Regards,
Angelo
Regards,
CK
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 93552d76b6e7..7759a06e5c0e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -715,6 +715,8 @@ static const struct of_device_id
mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DISP_OVL },
{ .compatible = "mediatek,mt8192-disp-ovl",
.data = (void *)MTK_DISP_OVL },
+ { .compatible = "mediatek,mt8195-disp-ovl",
+ .data = (void *)MTK_DISP_OVL },
{ .compatible = "mediatek,mt8183-disp-ovl-2l",
.data = (void *)MTK_DISP_OVL_2L },
{ .compatible = "mediatek,mt8192-disp-ovl-2l",
Re: [PATCH v2 04/11] drm/mediatek: Add OVL compatible name for MT8195
Re: [PATCH v5 2/6] drm/panfrost: Add fdinfo support GPU load metrics
On 14/09/2023 23:38, Adrián Larumbe wrote:
> The drm-stats fdinfo tags made available to user space are drm-engine,
> drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
>
> This deviates from standard practice in other DRM drivers, where a single
> set of key:value pairs is provided for the whole render engine. However,
> Panfrost has separate queues for fragment and vertex/tiler jobs, so a
> decision was made to calculate bus cycles and workload times separately.
>
> Maximum operating frequency is calculated at devfreq initialisation time.
> Current frequency is made available to user space because nvtop uses it
> when performing engine usage calculations.
>
> It is important to bear in mind that both GPU cycle and kernel time numbers
> provided are at best rough estimations, and always reported in excess from
> the actual figure because of two reasons:
> - Excess time because of the delay between the end of a job processing,
>the subsequent job IRQ and the actual time of the sample.
> - Time spent in the engine queue waiting for the GPU to pick up the next
>job.
>
> To avoid race conditions during enablement/disabling, a reference counting
> mechanism was introduced, and a job flag that tells us whether a given job
> increased the refcount. This is necessary, because user space can toggle
> cycle counting through a debugfs file, and a given job might have been in
> flight by the time cycle counting was disabled.
>
> The main goal of the debugfs cycle counter knob is letting tools like nvtop
> or IGT's gputop switch it at any time, to avoid power waste in case no
> engine usage measuring is necessary.
>
> Signed-off-by: Adrián Larumbe
> Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/Makefile | 2 +
> drivers/gpu/drm/panfrost/panfrost_debugfs.c | 20
> drivers/gpu/drm/panfrost/panfrost_debugfs.h | 13 +
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8 +++
> drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 ++
> drivers/gpu/drm/panfrost/panfrost_device.c | 2 +
> drivers/gpu/drm/panfrost/panfrost_device.h | 13 +
> drivers/gpu/drm/panfrost/panfrost_drv.c | 57 -
> drivers/gpu/drm/panfrost/panfrost_gpu.c | 41 +++
> drivers/gpu/drm/panfrost/panfrost_gpu.h | 4 ++
> drivers/gpu/drm/panfrost/panfrost_job.c | 24 +
> drivers/gpu/drm/panfrost/panfrost_job.h | 5 ++
> 12 files changed, 191 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c
> create mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h
>
> diff --git a/drivers/gpu/drm/panfrost/Makefile
> b/drivers/gpu/drm/panfrost/Makefile
> index 7da2b3f02ed9..2c01c1e7523e 100644
> --- a/drivers/gpu/drm/panfrost/Makefile
> +++ b/drivers/gpu/drm/panfrost/Makefile
> @@ -12,4 +12,6 @@ panfrost-y := \
> panfrost_perfcnt.o \
> panfrost_dump.o
>
> +panfrost-$(CONFIG_DEBUG_FS) += panfrost_debugfs.o
> +
> obj-$(CONFIG_DRM_PANFROST) += panfrost.o
> diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.c
> b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
> new file mode 100644
> index ..cc14eccba206
> --- /dev/null
> +++ b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright 2023 Collabora ltd. */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "panfrost_device.h"
> +#include "panfrost_gpu.h"
> +#include "panfrost_debugfs.h"
> +
> +void panfrost_debugfs_init(struct drm_minor *minor)
> +{
> + struct drm_device *dev = minor->dev;
> + struct panfrost_device *pfdev =
> platform_get_drvdata(to_platform_device(dev->dev));
> +
> + debugfs_create_atomic_t("profile", 0600, minor->debugfs_root,
> >profile_mode);
> +}
> diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.h
> b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
> new file mode 100644
> index ..db1c158bcf2f
> --- /dev/null
> +++ b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2023 Collabora ltd.
> + */
> +
> +#ifndef PANFROST_DEBUGFS_H
> +#define PANFROST_DEBUGFS_H
> +
> +#ifdef CONFIG_DEBUG_FS
> +void panfrost_debugfs_init(struct drm_minor *minor);
> +#endif
> +
> +#endif /* PANFROST_DEBUGFS_H */
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 58dfb15a8757..28caffc689e2 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -58,6 +58,7 @@ static int panfrost_devfreq_get_dev_status(struct device
> *dev,
> spin_lock_irqsave(>lock, irqflags);
>
> panfrost_devfreq_update_utilization(pfdevfreq);
> + pfdevfreq->current_frequency = status->current_frequency;
>
> status->total_time = ktime_to_ns(ktime_add(pfdevfreq->busy_time,
>
Re: [PATCH for-next v2 03/10] iio: accel: fxls8962af: convert to EXPORT_NS_GPL_RUNTIME_PM_OPS()
On 18/9/23 09:09, Raag Jadav wrote:
With original macro being renamed to EXPORT_NS_GPL_RUNTIME_PM_OPS(),
use the new macro.
Signed-off-by: Raag Jadav
---
drivers/iio/accel/fxls8962af-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/accel/fxls8962af-core.c
b/drivers/iio/accel/fxls8962af-core.c
index be8a15cb945f..69e73c54047e 100644
--- a/drivers/iio/accel/fxls8962af-core.c
+++ b/drivers/iio/accel/fxls8962af-core.c
@@ -1282,7 +1282,7 @@ static int fxls8962af_resume(struct device *dev)
return 0;
}
-EXPORT_NS_GPL_DEV_PM_OPS(fxls8962af_pm_ops, IIO_FXLS8962AF) = {
+EXPORT_NS_GPL_RUNTIME_PM_OPS(fxls8962af_pm_ops, IIO_FXLS8962AF) = {
SYSTEM_SLEEP_PM_OPS(fxls8962af_suspend, fxls8962af_resume)
RUNTIME_PM_OPS(fxls8962af_runtime_suspend, fxls8962af_runtime_resume,
NULL)
};
This change doesn't make sense. It changes the struct definition to use
a EXPORT_*_RUNTIME_PM_OPS() macro, which leads me to expect this is
exporting runtime pm ops. But then the struct has both SYSTEM and
RUNTIME functions.
Maybe the underlying implementations of the macros result in "doing the
right thing", but the source reads like it must be a mistake.
Re: [RFC PATCH 8/8] dt-bindings: display: panel: add Fascontek FS035VG158 panel
On 17/09/2023 22:24, John Watts wrote: > On Mon, Sep 11, 2023 at 11:41:12AM +0200, Krzysztof Kozlowski wrote: >> Missing reg. Probably also port. > > Hello again, > > I've been working on v2 of this series and done some initial cleanup. > > Right now it looks a bit like this: > >> allOf: >> - $ref: panel-common.yaml# >> - $ref: /schemas/spi/spi-peripheral-props.yaml# >> >> properties: >> compatible: >> const: fascontek,fs035vg158 >> >> spi-3wire: true >> >> required: >> - compatible >> - reg >> - port >> - power-supply >> - reset-gpios > > Does this seem correct? > - reg is required by spi-controller > - port is listed in panel-common > - power-supply is listed in panel-common > > I'm guessing that the required section just lists the minimal > properties needed for this specific device tree yaml? > There's nothing implied by allOf? Ah, then it is fine. Best regards, Krzysztof
Re: [PATCH v2] drm/simpledrm: Add support for multiple "power-domains"
Hi
Am 12.09.23 um 22:22 schrieb Janne Grunau via B4 Relay:
From: Janne Grunau
Multiple power domains need to be handled explicitly in each driver. The
driver core can not handle it automatically since it is not aware of
power sequencing requirements the hardware might have. This is not a
problem for simpledrm since everything is expected to be powered on by
the bootloader. simpledrm has just ensure it remains powered on during
its lifetime.
This is required on Apple silicon M2 and M2 Pro/Max/Ultra desktop
systems. The HDMI output initialized by the bootloader requires keeping
the display controller and a DP phy power domain on.
Signed-off-by: Janne Grunau
As a simpledrm patch:
Reviewed-by: Thomas Zimmermann
Do you want to wait for another review from someone with
power-management expertise?
Do we need a similar patch for ofdrm?
Best regards
Thomas
---
Changes in v2:
- removed broken drm_err() log statement only ment for debugging
- removed commented cast
- use correct format spcifier for 'int' in log statement
- add 'continue;' after failure to get device for power_domain
- use drm_warn() in non fatal error cases
- removed duplicate PTR_ERR conversion
- Link to v1:
https://lore.kernel.org/r/20230910-simpledrm-multiple-power-domains-v1-1-f8718aefc...@jannau.net
---
drivers/gpu/drm/tiny/simpledrm.c | 105 +++
1 file changed, 105 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index ff86ba1ae1b8..9c597461d1e2 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -227,6 +228,12 @@ struct simpledrm_device {
unsigned int regulator_count;
struct regulator **regulators;
#endif
+ /* power-domains */
+#if defined CONFIG_OF && defined CONFIG_PM_GENERIC_DOMAINS
+ int pwr_dom_count;
+ struct device **pwr_dom_devs;
+ struct device_link **pwr_dom_links;
+#endif
/* simplefb settings */
struct drm_display_mode mode;
@@ -468,6 +475,101 @@ static int simpledrm_device_init_regulators(struct
simpledrm_device *sdev)
}
#endif
+#if defined CONFIG_OF && defined CONFIG_PM_GENERIC_DOMAINS
+/*
+ * Generic power domain handling code.
+ *
+ * Here we handle the power-domains properties of our "simple-framebuffer"
+ * dt node. This is only necessary if there is more than one power-domain.
+ * A single power-domains is handled automatically by the driver core. Multiple
+ * power-domains have to be handled by drivers since the driver core can't know
+ * the correct power sequencing. Power sequencing is not an issue for simpledrm
+ * since the bootloader has put the power domains already in the correct state.
+ * simpledrm has only to ensure they remain active for its lifetime.
+ *
+ * When the driver unloads, we detach from the power-domains.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up the "simple-framebuffer" dt node, and the PM domain providers in the
+ * device tree. Chances are that there are no adverse effects, and if there
are,
+ * a clean teardown of the fb probe will not help us much either. So just
+ * complain and carry on, and hope that the user actually gets a working fb at
+ * the end of things.
+ */
+static void simpledrm_device_detach_genpd(void *res)
+{
+ int i;
+ struct simpledrm_device *sdev = res;
+
+ if (sdev->pwr_dom_count <= 1)
+ return;
+
+ for (i = sdev->pwr_dom_count - 1; i >= 0; i--) {
+ if (!sdev->pwr_dom_links[i])
+ device_link_del(sdev->pwr_dom_links[i]);
+ if (!IS_ERR_OR_NULL(sdev->pwr_dom_devs[i]))
+ dev_pm_domain_detach(sdev->pwr_dom_devs[i], true);
+ }
+}
+
+static int simpledrm_device_attach_genpd(struct simpledrm_device *sdev)
+{
+ struct device *dev = sdev->dev.dev;
+ int i;
+
+ sdev->pwr_dom_count = of_count_phandle_with_args(dev->of_node,
"power-domains",
+"#power-domain-cells");
+ /*
+* Single power-domain devices are handled by driver core nothing to do
+* here. The same for device nodes without "power-domains" property.
+*/
+ if (sdev->pwr_dom_count <= 1)
+ return 0;
+
+ sdev->pwr_dom_devs = devm_kcalloc(dev, sdev->pwr_dom_count,
+ sizeof(*sdev->pwr_dom_devs),
+ GFP_KERNEL);
+ if (!sdev->pwr_dom_devs)
+ return -ENOMEM;
+
+ sdev->pwr_dom_links = devm_kcalloc(dev, sdev->pwr_dom_count,
+ sizeof(*sdev->pwr_dom_links),
+ GFP_KERNEL);
+
Re: [PATCH v9 6/7] drm/mediatek: dsi: Support dynamic connector selection
Re: [PATCH v4 0/5] ppc, fbdev: Clean up fbdev mmap helper
Ping for a review. I'd like to get at least the first two patches into the DRM git tree. The PPC patches could later be merged through another tree. Best regards Thomas Am 12.09.23 um 15:48 schrieb Thomas Zimmermann: Clean up and rename fb_pgprotect() to work without struct file. Then refactor the implementation for PowerPC. This change has been discussed at [1] in the context of refactoring fbdev's mmap code. The first two patches update fbdev and replace fbdev's fb_pgprotect() with pgprot_framebuffer() on all architectures. The new helper's stream- lined interface enables more refactoring within fbdev's mmap implementation. Patches 3 to 5 adapt PowerPC's internal interfaces to provide phys_mem_access_prot() that works without struct file. Neither the architecture code or fbdev helpers need the parameter. v4: * fix commit message (Christophe) v3: * rename fb_pgrotect() to pgprot_framebuffer() (Arnd) v2: * reorder patches to simplify merging (Michael) [1] https://lore.kernel.org/linuxppc-dev/5501ba80-bdb0-6344-16b0-0466a950f...@suse.com/ Thomas Zimmermann (5): fbdev: Avoid file argument in fb_pgprotect() fbdev: Replace fb_pgprotect() with pgprot_framebuffer() arch/powerpc: Remove trailing whitespaces arch/powerpc: Remove file parameter from phys_mem_access_prot code arch/powerpc: Call internal __phys_mem_access_prot() in fbdev code arch/ia64/include/asm/fb.h| 15 +++ arch/m68k/include/asm/fb.h| 19 ++- arch/mips/include/asm/fb.h| 11 +-- arch/powerpc/include/asm/book3s/pgtable.h | 10 -- arch/powerpc/include/asm/fb.h | 13 + arch/powerpc/include/asm/machdep.h| 13 ++--- arch/powerpc/include/asm/nohash/pgtable.h | 10 -- arch/powerpc/include/asm/pci.h| 4 +--- arch/powerpc/kernel/pci-common.c | 3 +-- arch/powerpc/mm/mem.c | 8 arch/sparc/include/asm/fb.h | 15 +-- arch/x86/include/asm/fb.h | 10 ++ arch/x86/video/fbdev.c| 15 --- drivers/video/fbdev/core/fb_chrdev.c | 3 ++- include/asm-generic/fb.h | 12 ++-- 15 files changed, 86 insertions(+), 75 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature.asc Description: OpenPGP digital signature
[PATCH 07/14] accel/habanalabs/gaudi2: print power-mode changes
From: Moti Haimovski
Print to kernel log any device power mode changes events reported by
the FW.
Signed-off-by: Moti Haimovski
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 12
.../habanalabs/include/gaudi2/gaudi2_async_events.h | 7 +++
.../include/gaudi2/gaudi2_async_ids_map_extended.h | 12
3 files changed, 31 insertions(+)
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index dca19be42d5f..677900e18519 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -7798,6 +7798,7 @@ static inline bool is_info_event(u32 event)
switch (event) {
case GAUDI2_EVENT_CPU_CPLD_SHUTDOWN_CAUSE:
case GAUDI2_EVENT_CPU_FIX_POWER_ENV_S ...
GAUDI2_EVENT_CPU_FIX_THERMAL_ENV_E:
+ case GAUDI2_EVENT_ARC_PWR_BRK_ENTRY ... GAUDI2_EVENT_ARC_PWR_RD_MODE3:
/* return in case of NIC status event - these events are received
periodically and not as
* an indication to an error.
@@ -10178,6 +10179,17 @@ static void gaudi2_handle_eqe(struct hl_device *hdev,
struct hl_eq_entry *eq_ent
is_critical = true;
break;
+ case GAUDI2_EVENT_ARC_PWR_BRK_ENTRY:
+ case GAUDI2_EVENT_ARC_PWR_BRK_EXT:
+ case GAUDI2_EVENT_ARC_PWR_RD_MODE0:
+ case GAUDI2_EVENT_ARC_PWR_RD_MODE1:
+ case GAUDI2_EVENT_ARC_PWR_RD_MODE2:
+ case GAUDI2_EVENT_ARC_PWR_RD_MODE3:
+ error_count = GAUDI2_NA_EVENT_CAUSE;
+ dev_info_ratelimited(hdev->dev, "%s event received\n",
+ gaudi2_irq_map_table[event_type].name);
+ break;
+
default:
if (gaudi2_irq_map_table[event_type].valid) {
dev_err_ratelimited(hdev->dev, "Cannot find handler for
event %d\n",
diff --git a/drivers/accel/habanalabs/include/gaudi2/gaudi2_async_events.h
b/drivers/accel/habanalabs/include/gaudi2/gaudi2_async_events.h
index f661068d0c5f..a426410139af 100644
--- a/drivers/accel/habanalabs/include/gaudi2/gaudi2_async_events.h
+++ b/drivers/accel/habanalabs/include/gaudi2/gaudi2_async_events.h
@@ -959,6 +959,13 @@ enum gaudi2_async_event_id {
GAUDI2_EVENT_ARC_DCCM_FULL = 1319,
GAUDI2_EVENT_CPU_FP32_NOT_SUPPORTED = 1320,
GAUDI2_EVENT_CPU_DEV_RESET_REQ = 1321,
+ GAUDI2_EVENT_ARC_PWR_BRK_ENTRY = 1322,
+ GAUDI2_EVENT_ARC_PWR_BRK_EXT = 1323,
+ GAUDI2_EVENT_ARC_PWR_RD_MODE0 = 1324,
+ GAUDI2_EVENT_ARC_PWR_RD_MODE1 = 1325,
+ GAUDI2_EVENT_ARC_PWR_RD_MODE2 = 1326,
+ GAUDI2_EVENT_ARC_PWR_RD_MODE3 = 1327,
+ GAUDI2_EVENT_ARC_EQ_HEARTBEAT = 1328,
GAUDI2_EVENT_SIZE,
};
diff --git
a/drivers/accel/habanalabs/include/gaudi2/gaudi2_async_ids_map_extended.h
b/drivers/accel/habanalabs/include/gaudi2/gaudi2_async_ids_map_extended.h
index ad01fc4e9940..6cb0f615fc3e 100644
--- a/drivers/accel/habanalabs/include/gaudi2/gaudi2_async_ids_map_extended.h
+++ b/drivers/accel/habanalabs/include/gaudi2/gaudi2_async_ids_map_extended.h
@@ -2673,6 +2673,18 @@ static struct gaudi2_async_events_ids_map
gaudi2_irq_map_table[] = {
.name = "FP32_NOT_SUPPORTED" },
{ .fc_id = 1321, .cpu_id = 627, .valid = 1, .msg = 1, .reset =
EVENT_RESET_TYPE_HARD,
.name = "DEV_RESET_REQ" },
+ { .fc_id = 1322, .cpu_id = 628, .valid = 1, .msg = 1, .reset =
EVENT_RESET_TYPE_NONE,
+.name = "PWR_BRK_ENTRY" },
+ { .fc_id = 1323, .cpu_id = 629, .valid = 1, .msg = 1, .reset =
EVENT_RESET_TYPE_NONE,
+.name = "PWR_BRK_EXT" },
+ { .fc_id = 1324, .cpu_id = 630, .valid = 1, .msg = 1, .reset =
EVENT_RESET_TYPE_NONE,
+.name = "PWR_RD_MODE0" },
+ { .fc_id = 1325, .cpu_id = 631, .valid = 1, .msg = 1, .reset =
EVENT_RESET_TYPE_NONE,
+.name = "PWR_RD_MODE1" },
+ { .fc_id = 1326, .cpu_id = 632, .valid = 1, .msg = 1, .reset =
EVENT_RESET_TYPE_NONE,
+.name = "PWR_RD_MODE2" },
+ { .fc_id = 1327, .cpu_id = 633, .valid = 1, .msg = 1, .reset =
EVENT_RESET_TYPE_NONE,
+.name = "PWR_RD_MODE3" },
};
#endif /* __GAUDI2_ASYNC_IDS_MAP_EVENTS_EXT_H_ */
--
2.34.1
[PATCH 12/14] accel/habanalabs: use exported size from dma_buf and not from phys_pg_pack
From: Tomer Tayar
The 'exported_size' member in 'struct hl_vm_phys_pg_pack' is used to
keep the exported dma-buf size, to be later used when the buffer is
mapped.
However it is possible that the same phys_pg_pack will be exported more
than once, and independently of when the mapping takes place.
Remove this member from the phys_pg_pack structure, and simply use the
size in the dma-buf object as the exported size when mapping.
Signed-off-by: Tomer Tayar
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/habanalabs.h | 2 --
drivers/accel/habanalabs/common/memory.c | 3 +--
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index 6f2cbd3c2e95..4c5d55c9109d 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -2159,7 +2159,6 @@ struct hl_vm_hw_block_list_node {
* @pages: the physical page array.
* @npages: num physical pages in the pack.
* @total_size: total size of all the pages in this list.
- * @exported_size: buffer exported size.
* @node: used to attach to deletion list that is used when all the
allocations are cleared
*at the teardown of the context.
* @mapping_cnt: number of shared mappings.
@@ -2176,7 +2175,6 @@ struct hl_vm_phys_pg_pack {
u64 *pages;
u64 npages;
u64 total_size;
- u64 exported_size;
struct list_headnode;
atomic_tmapping_cnt;
u32 asid;
diff --git a/drivers/accel/habanalabs/common/memory.c
b/drivers/accel/habanalabs/common/memory.c
index c7e49cb383cf..27ab176c55c1 100644
--- a/drivers/accel/habanalabs/common/memory.c
+++ b/drivers/accel/habanalabs/common/memory.c
@@ -1719,7 +1719,7 @@ static struct sg_table *hl_map_dmabuf(struct
dma_buf_attachment *attachment,
phys_pg_pack->pages,
phys_pg_pack->npages,
phys_pg_pack->page_size,
- phys_pg_pack->exported_size,
+ hl_dmabuf->dmabuf->size,
attachment->dev,
dir);
else
@@ -2044,7 +2044,6 @@ static int export_dmabuf_from_addr(struct hl_ctx *ctx,
u64 addr, u64 size, u64 o
if (rc)
goto dec_memhash_export_cnt;
- phys_pg_pack->exported_size = size;
hl_dmabuf->phys_pg_pack = phys_pg_pack;
hl_dmabuf->memhash_hnode = hnode;
} else {
--
2.34.1
[PATCH 03/14] accel/habanalabs: move cpucp interface to linux/habanalabs
From: David Meriin
The CPUCP interface is moved to a shared folder outside of accel as
a pre-requisite to upstream the NIC drivers that will also include
this file.
Signed-off-by: David Meriin
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
MAINTAINERS | 1 +
drivers/accel/habanalabs/common/firmware_if.c | 2 +-
drivers/accel/habanalabs/common/habanalabs.h| 2 +-
drivers/accel/habanalabs/gaudi/gaudiP.h | 2 +-
drivers/accel/habanalabs/gaudi2/gaudi2P.h | 2 +-
drivers/accel/habanalabs/goya/goyaP.h | 2 +-
.../common => include/linux/habanalabs}/cpucp_if.h | 13 +
.../linux/habanalabs}/hl_boot_if.h | 0
8 files changed, 15 insertions(+), 9 deletions(-)
rename {drivers/accel/habanalabs/include/common =>
include/linux/habanalabs}/cpucp_if.h (99%)
rename {drivers/accel/habanalabs/include/common =>
include/linux/habanalabs}/hl_boot_if.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 90f13281d297..a9dad911add9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9067,6 +9067,7 @@ T:git
https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git
F: Documentation/ABI/testing/debugfs-driver-habanalabs
F: Documentation/ABI/testing/sysfs-driver-habanalabs
F: drivers/accel/habanalabs/
+F: include/linux/habanalabs/
F: include/trace/events/habanalabs.h
F: include/uapi/drm/habanalabs_accel.h
diff --git a/drivers/accel/habanalabs/common/firmware_if.c
b/drivers/accel/habanalabs/common/firmware_if.c
index 2bc775d29854..2a6dfea3d27d 100644
--- a/drivers/accel/habanalabs/common/firmware_if.c
+++ b/drivers/accel/habanalabs/common/firmware_if.c
@@ -6,7 +6,7 @@
*/
#include "habanalabs.h"
-#include "../include/common/hl_boot_if.h"
+#include
#include
#include
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index efb046370f2e..8b5fd2b92676 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -8,7 +8,7 @@
#ifndef HABANALABSP_H_
#define HABANALABSP_H_
-#include "../include/common/cpucp_if.h"
+#include
#include "../include/common/qman_if.h"
#include "../include/hw_ip/mmu/mmu_general.h"
#include
diff --git a/drivers/accel/habanalabs/gaudi/gaudiP.h
b/drivers/accel/habanalabs/gaudi/gaudiP.h
index b8fa724be5a1..831be53bb9d7 100644
--- a/drivers/accel/habanalabs/gaudi/gaudiP.h
+++ b/drivers/accel/habanalabs/gaudi/gaudiP.h
@@ -10,7 +10,7 @@
#include
#include "../common/habanalabs.h"
-#include "../include/common/hl_boot_if.h"
+#include
#include "../include/gaudi/gaudi_packets.h"
#include "../include/gaudi/gaudi.h"
#include "../include/gaudi/gaudi_async_events.h"
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2P.h
b/drivers/accel/habanalabs/gaudi2/gaudi2P.h
index 5f3ce086928e..4535aa5ab561 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2P.h
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2P.h
@@ -10,7 +10,7 @@
#include
#include "../common/habanalabs.h"
-#include "../include/common/hl_boot_if.h"
+#include
#include "../include/gaudi2/gaudi2.h"
#include "../include/gaudi2/gaudi2_packets.h"
#include "../include/gaudi2/gaudi2_fw_if.h"
diff --git a/drivers/accel/habanalabs/goya/goyaP.h
b/drivers/accel/habanalabs/goya/goyaP.h
index 5df3d30b91fd..194c2ae157cd 100644
--- a/drivers/accel/habanalabs/goya/goyaP.h
+++ b/drivers/accel/habanalabs/goya/goyaP.h
@@ -9,8 +9,8 @@
#define GOYAP_H_
#include
+#include
#include "../common/habanalabs.h"
-#include "../include/common/hl_boot_if.h"
#include "../include/goya/goya_packets.h"
#include "../include/goya/goya.h"
#include "../include/goya/goya_async_events.h"
diff --git a/drivers/accel/habanalabs/include/common/cpucp_if.h
b/include/linux/habanalabs/cpucp_if.h
similarity index 99%
rename from drivers/accel/habanalabs/include/common/cpucp_if.h
rename to include/linux/habanalabs/cpucp_if.h
index ef7d32224066..4cdedb603ecb 100644
--- a/drivers/accel/habanalabs/include/common/cpucp_if.h
+++ b/include/linux/habanalabs/cpucp_if.h
@@ -668,7 +668,11 @@ enum pq_init_status {
* Packet to register interrupts indicating LKD is ready to receive
events from FW.
*
* CPUCP_PACKET_SOFT_RESET -
- * Packet to perform soft-reset.
+ * Packet to perform soft-reset.
+ *
+ * CPUCP_PACKET_INTS_REGISTER -
+ * Packet to inform FW that queues have been established and LKD is
ready to receive
+ * EQ events.
*/
enum cpucp_packet_id {
@@ -734,9 +738,10 @@ enum cpucp_packet_id {
CPUCP_PACKET_RESERVED10,/* not used */
CPUCP_PACKET_RESERVED11,/* not used */
CPUCP_PACKET_RESERVED12,/* internal */
- CPUCP_PACKET_REGISTER_INTERRUPTS, /* internal */
- CPUCP_PACKET_SOFT_RESET,/* internal */
- CPUCP_PACKET_ID_MAX /* must be
[PATCH 09/14] accel/habanalabs/gaudi2: add eq health check using irq
From: farah kassabri
This is the second patch for applying the eq health check mechanism
which will add support for the interrupt flow for gaudi2 asic.
More info about the interrupt mechanism:
set a dedicated msix for the eq error interrupt, and add
interrupt handler for it.
when FW detects some issue with EQ like EQ_FULL, it'll
raise that interrupt and driver should reset the device.
Driver will inform the FW which msix index to use through
the already existing handshake mechanism which will
send msix info message to fw.
Signed-off-by: farah kassabri
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/habanalabs.h | 1 +
drivers/accel/habanalabs/common/irq.c| 12
drivers/accel/habanalabs/gaudi2/gaudi2.c | 16
drivers/accel/habanalabs/gaudi2/gaudi2P.h| 1 +
include/linux/habanalabs/cpucp_if.h | 1 +
5 files changed, 31 insertions(+)
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index e5b416852996..6f2cbd3c2e95 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -3689,6 +3689,7 @@ irqreturn_t hl_irq_handler_eq(int irq, void *arg);
irqreturn_t hl_irq_handler_dec_abnrm(int irq, void *arg);
irqreturn_t hl_irq_handler_user_interrupt(int irq, void *arg);
irqreturn_t hl_irq_user_interrupt_thread_handler(int irq, void *arg);
+irqreturn_t hl_irq_eq_error_interrupt_thread_handler(int irq, void *arg);
u32 hl_cq_inc_ptr(u32 ptr);
int hl_asid_init(struct hl_device *hdev);
diff --git a/drivers/accel/habanalabs/common/irq.c
b/drivers/accel/habanalabs/common/irq.c
index 10ac100bf9e2..f6b6c54bc868 100644
--- a/drivers/accel/habanalabs/common/irq.c
+++ b/drivers/accel/habanalabs/common/irq.c
@@ -401,6 +401,18 @@ irqreturn_t hl_irq_user_interrupt_thread_handler(int irq,
void *arg)
return IRQ_HANDLED;
}
+irqreturn_t hl_irq_eq_error_interrupt_thread_handler(int irq, void *arg)
+{
+ u64 event_mask = HL_NOTIFIER_EVENT_DEVICE_RESET |
HL_NOTIFIER_EVENT_DEVICE_UNAVAILABLE;
+ struct hl_device *hdev = arg;
+
+ dev_err(hdev->dev, "EQ error interrupt received\n");
+
+ hl_device_cond_reset(hdev, HL_DRV_RESET_HARD, event_mask);
+
+ return IRQ_HANDLED;
+}
+
/**
* hl_irq_handler_eq - irq handler for event queue
*
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index e507847bf460..b0ba62b691ec 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -4175,6 +4175,8 @@ static const char *gaudi2_irq_name(u16 irq_number)
return "gaudi2 unexpected error";
case GAUDI2_IRQ_NUM_USER_FIRST ... GAUDI2_IRQ_NUM_USER_LAST:
return "gaudi2 user completion";
+ case GAUDI2_IRQ_NUM_EQ_ERROR:
+ return "gaudi2 eq error";
default:
return "invalid";
}
@@ -4317,6 +4319,15 @@ static int gaudi2_enable_msix(struct hl_device *hdev)
}
}
+ irq = pci_irq_vector(hdev->pdev, GAUDI2_IRQ_NUM_EQ_ERROR);
+ rc = request_threaded_irq(irq, NULL,
hl_irq_eq_error_interrupt_thread_handler,
+ IRQF_ONESHOT,
gaudi2_irq_name(GAUDI2_IRQ_NUM_EQ_ERROR),
+ hdev);
+ if (rc) {
+ dev_err(hdev->dev, "Failed to request IRQ %d", irq);
+ goto free_user_irq;
+ }
+
gaudi2->hw_cap_initialized |= HW_CAP_MSIX;
return 0;
@@ -4376,6 +4387,7 @@ static void gaudi2_sync_irqs(struct hl_device *hdev)
}
synchronize_irq(pci_irq_vector(hdev->pdev, GAUDI2_IRQ_NUM_EVENT_QUEUE));
+ synchronize_irq(pci_irq_vector(hdev->pdev, GAUDI2_IRQ_NUM_EQ_ERROR));
}
static void gaudi2_disable_msix(struct hl_device *hdev)
@@ -4412,6 +4424,9 @@ static void gaudi2_disable_msix(struct hl_device *hdev)
cq = >completion_queue[GAUDI2_RESERVED_CQ_CS_COMPLETION];
free_irq(irq, cq);
+ irq = pci_irq_vector(hdev->pdev, GAUDI2_IRQ_NUM_EQ_ERROR);
+ free_irq(irq, hdev);
+
pci_free_irq_vectors(hdev->pdev);
gaudi2->hw_cap_initialized &= ~HW_CAP_MSIX;
@@ -11345,6 +11360,7 @@ static int
gaudi2_ack_mmu_page_fault_or_access_error(struct hl_device *hdev, u64
static void gaudi2_get_msi_info(__le32 *table)
{
table[CPUCP_EVENT_QUEUE_MSI_TYPE] =
cpu_to_le32(GAUDI2_EVENT_QUEUE_MSIX_IDX);
+ table[CPUCP_EVENT_QUEUE_ERR_MSI_TYPE] =
cpu_to_le32(GAUDI2_IRQ_NUM_EQ_ERROR);
}
static int gaudi2_map_pll_idx_to_fw_idx(u32 pll_idx)
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2P.h
b/drivers/accel/habanalabs/gaudi2/gaudi2P.h
index 4535aa5ab561..14e281fd9895 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2P.h
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2P.h
@@ -419,6 +419,7 @@ enum gaudi2_irq_num {
[PATCH 02/14] accel/habanalabs/gaudi2: include block id in ECC error reporting
From: Ofir Bitton
During ECC event handling, Memory wrapper id was mistakenly
printed as block id. Fix the print and in addition fetch the actual
block-id from firmware.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 23 +++
.../habanalabs/include/common/cpucp_if.h | 3 ++-
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index d60389b6700f..dca19be42d5f 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -7834,16 +7834,29 @@ static void gaudi2_print_event(struct hl_device *hdev,
u16 event_type,
static bool gaudi2_handle_ecc_event(struct hl_device *hdev, u16 event_type,
struct hl_eq_ecc_data *ecc_data)
{
- u64 ecc_address = 0, ecc_syndrom = 0;
+ u64 ecc_address = 0, ecc_syndrome = 0;
u8 memory_wrapper_idx = 0;
+ bool has_block_id = false;
+ u16 block_id;
+
+ if (!hl_is_fw_sw_ver_below(hdev, 1, 12))
+ has_block_id = true;
ecc_address = le64_to_cpu(ecc_data->ecc_address);
- ecc_syndrom = le64_to_cpu(ecc_data->ecc_syndrom);
+ ecc_syndrome = le64_to_cpu(ecc_data->ecc_syndrom);
memory_wrapper_idx = ecc_data->memory_wrapper_idx;
- gaudi2_print_event(hdev, event_type, !ecc_data->is_critical,
- "ECC error detected. address: %#llx. Syndrom: %#llx. block id
%u. critical %u.",
- ecc_address, ecc_syndrom, memory_wrapper_idx,
ecc_data->is_critical);
+ if (has_block_id) {
+ block_id = le16_to_cpu(ecc_data->block_id);
+ gaudi2_print_event(hdev, event_type, !ecc_data->is_critical,
+ "ECC error detected. address: %#llx. Syndrome: %#llx.
wrapper id %u. block id %#x. critical %u.",
+ ecc_address, ecc_syndrome, memory_wrapper_idx, block_id,
+ ecc_data->is_critical);
+ } else {
+ gaudi2_print_event(hdev, event_type, !ecc_data->is_critical,
+ "ECC error detected. address: %#llx. Syndrome: %#llx.
wrapper id %u. critical %u.",
+ ecc_address, ecc_syndrome, memory_wrapper_idx,
ecc_data->is_critical);
+ }
return !!ecc_data->is_critical;
}
diff --git a/drivers/accel/habanalabs/include/common/cpucp_if.h
b/drivers/accel/habanalabs/include/common/cpucp_if.h
index 33807b839c37..ef7d32224066 100644
--- a/drivers/accel/habanalabs/include/common/cpucp_if.h
+++ b/drivers/accel/habanalabs/include/common/cpucp_if.h
@@ -69,7 +69,8 @@ struct hl_eq_ecc_data {
__le64 ecc_syndrom;
__u8 memory_wrapper_idx;
__u8 is_critical;
- __u8 pad[6];
+ __le16 block_id;
+ __u8 pad[4];
};
enum hl_sm_sei_cause {
--
2.34.1
[PATCH 01/14] accel/habanalabs: improve etf configuration
From: Benjamin Dotan
coresight ETF blocks have different size. As a result, sync packets
need to be aligned based on fifo size.
Signed-off-by: Benjamin Dotan
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2_coresight.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2_coresight.c
b/drivers/accel/habanalabs/gaudi2/gaudi2_coresight.c
index 32e0f1a85b35..14a855cdc96b 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2_coresight.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2_coresight.c
@@ -2125,10 +2125,17 @@ static int gaudi2_config_etf(struct hl_device *hdev,
struct hl_debug_params *par
if (!input)
return -EINVAL;
+ val = RREG32(base_reg + mmETF_RSZ_OFFSET) << 2;
+ if (val) {
+ val = ffs(val);
+ WREG32(base_reg + mmETF_PSCR_OFFSET, val);
+ } else {
+ WREG32(base_reg + mmETF_PSCR_OFFSET, 0x10);
+ }
+
WREG32(base_reg + mmETF_BUFWM_OFFSET, 0x3FFC);
WREG32(base_reg + mmETF_MODE_OFFSET, input->sink_mode);
WREG32(base_reg + mmETF_FFCR_OFFSET, 0x4001);
- WREG32(base_reg + mmETF_PSCR_OFFSET, 0x10);
WREG32(base_reg + mmETF_CTL_OFFSET, 1);
} else {
WREG32(base_reg + mmETF_BUFWM_OFFSET, 0);
--
2.34.1
[PATCH 04/14] accel/habanalabs: disable events ioctls on control device
From: Dafna Hirschfeld
Because it is not used and also, for graceful reset to work
those ioctls should run on the compute device.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 13 -
drivers/accel/habanalabs/common/habanalabs_drv.c | 1 -
drivers/accel/habanalabs/common/habanalabs_ioctl.c | 11 +++
3 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index 5293ac3c7988..2d12c197e165 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -572,11 +572,6 @@ static int hl_device_release_ctrl(struct inode *inode,
struct file *filp)
list_del(>dev_node);
mutex_unlock(>fpriv_ctrl_list_lock);
out:
- /* release the eventfd */
- if (hpriv->notifier_event.eventfd)
- eventfd_ctx_put(hpriv->notifier_event.eventfd);
-
- mutex_destroy(>notifier_event.lock);
put_pid(hpriv->taskpid);
kfree(hpriv);
@@ -1995,14 +1990,6 @@ void hl_notifier_event_send_all(struct hl_device *hdev,
u64 event_mask)
hl_notifier_event_send(>notifier_event, event_mask);
mutex_unlock(>fpriv_list_lock);
-
- /* control device */
- mutex_lock(>fpriv_ctrl_list_lock);
-
- list_for_each_entry(hpriv, >fpriv_ctrl_list, dev_node)
- hl_notifier_event_send(>notifier_event, event_mask);
-
- mutex_unlock(>fpriv_ctrl_list_lock);
}
/*
diff --git a/drivers/accel/habanalabs/common/habanalabs_drv.c
b/drivers/accel/habanalabs/common/habanalabs_drv.c
index 5db9af7e2daf..306a5bc9bf89 100644
--- a/drivers/accel/habanalabs/common/habanalabs_drv.c
+++ b/drivers/accel/habanalabs/common/habanalabs_drv.c
@@ -296,7 +296,6 @@ int hl_device_open_ctrl(struct inode *inode, struct file
*filp)
hpriv->hdev = hdev;
filp->private_data = hpriv;
- mutex_init(>notifier_event.lock);
nonseekable_open(inode, filp);
hpriv->taskpid = get_task_pid(current, PIDTYPE_PID);
diff --git a/drivers/accel/habanalabs/common/habanalabs_ioctl.c
b/drivers/accel/habanalabs/common/habanalabs_ioctl.c
index 87a6a0c0c48a..8c3f1e2de2fe 100644
--- a/drivers/accel/habanalabs/common/habanalabs_ioctl.c
+++ b/drivers/accel/habanalabs/common/habanalabs_ioctl.c
@@ -1104,6 +1104,17 @@ int hl_info_ioctl(struct drm_device *ddev, void *data,
struct drm_file *file_pri
static int hl_info_ioctl_control(struct hl_fpriv *hpriv, void *data)
{
+ struct hl_info_args *args = data;
+
+ switch (args->op) {
+ case HL_INFO_GET_EVENTS:
+ case HL_INFO_UNREGISTER_EVENTFD:
+ case HL_INFO_REGISTER_EVENTFD:
+ return -EOPNOTSUPP;
+ default:
+ break;
+ }
+
return _hl_info_ioctl(hpriv, data, hpriv->hdev->dev_ctrl);
}
--
2.34.1
[PATCH 05/14] accel/habanalabs: fix inline doc typos
From: Dafna Hirschfeld
Fix two typos
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 2 +-
drivers/accel/habanalabs/common/habanalabs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index 2d12c197e165..bf1b53f7fce9 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -639,7 +639,7 @@ static void device_release_func(struct device *dev)
* @hdev: pointer to habanalabs device structure
* @class: pointer to the class object of the device
* @minor: minor number of the specific device
- * @fpos: file operations to install for this device
+ * @fops: file operations to install for this device
* @name: name of the device as it will appear in the filesystem
* @cdev: pointer to the char device object that will be initialized
* @dev: pointer to the device object that will be initialized
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index 8b5fd2b92676..f8c597903cac 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -2261,7 +2261,7 @@ struct hl_notifier_event {
/**
* struct hl_fpriv - process information stored in FD private data.
* @hdev: habanalabs device structure.
- * @filp: pointer to the DRM file private data structure.
+ * @file_priv: pointer to the DRM file private data structure.
* @taskpid: current process ID.
* @ctx: current executing context. TODO: remove for multiple ctx per process
* @ctx_mgr: context manager to handle multiple context for this FD.
--
2.34.1
[PATCH 06/14] accel/habanalabs: add tsc clock sampling to clock sync info
From: Hen Alon
Add tsc clock to clock sync info, to enable using this clock for
sampling and sync it with device time.
Signed-off-by: Hen Alon
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/habanalabs_ioctl.c | 1 +
include/uapi/drm/habanalabs_accel.h| 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/accel/habanalabs/common/habanalabs_ioctl.c
b/drivers/accel/habanalabs/common/habanalabs_ioctl.c
index 8c3f1e2de2fe..a428226a0425 100644
--- a/drivers/accel/habanalabs/common/habanalabs_ioctl.c
+++ b/drivers/accel/habanalabs/common/habanalabs_ioctl.c
@@ -320,6 +320,7 @@ static int time_sync_info(struct hl_device *hdev, struct
hl_info_args *args)
time_sync.device_time = hdev->asic_funcs->get_device_time(hdev);
time_sync.host_time = ktime_get_raw_ns();
+ time_sync.tsc_time = rdtsc();
return copy_to_user(out, _sync,
min((size_t) max_size, sizeof(time_sync))) ? -EFAULT : 0;
diff --git a/include/uapi/drm/habanalabs_accel.h
b/include/uapi/drm/habanalabs_accel.h
index e7893b082bf8..dfe47db24ae6 100644
--- a/include/uapi/drm/habanalabs_accel.h
+++ b/include/uapi/drm/habanalabs_accel.h
@@ -991,6 +991,7 @@ struct hl_info_reset_count {
struct hl_info_time_sync {
__u64 device_time;
__u64 host_time;
+ __u64 tsc_time;
};
/**
--
2.34.1
[PATCH 11/14] accel/habanalabs: always pass exported size to alloc_sgt_from_device_pages()
From: Tomer Tayar For Gaudi1 the exported dma-buf is always composed of a single page, and therefore the exported size is equal to this page's size. When calling alloc_sgt_from_device_pages(), we pass 0 as the exported size and internally calculate it as "number of pages * page size". This makes alloc_sgt_from_device_pages() less clear, because the exported size parameter is not understood as a restriction on the pages' size. Modify to always pass the exported size explicitly. Signed-off-by: Tomer Tayar Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- drivers/accel/habanalabs/common/memory.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/accel/habanalabs/common/memory.c b/drivers/accel/habanalabs/common/memory.c index 1b1b4256b011..c7e49cb383cf 100644 --- a/drivers/accel/habanalabs/common/memory.c +++ b/drivers/accel/habanalabs/common/memory.c @@ -1561,8 +1561,7 @@ static struct sg_table *alloc_sgt_from_device_pages(struct hl_device *hdev, u64 if (!sgt) return ERR_PTR(-ENOMEM); - /* remove export size restrictions in case not explicitly defined */ - cur_size_to_export = exported_size ? exported_size : (npages * page_size); + cur_size_to_export = exported_size; /* If the size of each page is larger than the dma max segment size, * then we can't combine pages and the number of entries in the SGL @@ -1728,7 +1727,7 @@ static struct sg_table *hl_map_dmabuf(struct dma_buf_attachment *attachment, _dmabuf->device_address, 1, hl_dmabuf->dmabuf->size, - 0, + hl_dmabuf->dmabuf->size, attachment->dev, dir); -- 2.34.1
[PATCH 10/14] accel/habanalabs: prevent sending heartbeat before events are enabled
From: farah kassabri
After the heartbeat mechanism is now expanded to be used also
for EQ health check, we shouldn't send heartbeat messages
to FW before driver allow events to be received from FW.
Because if the driver will send two heartbeats before it enables
events to be received from FW, then the EQ health check
will fail and reset the device.
Signed-off-by: farah kassabri
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index 1d68d2233171..13f14b80a7d4 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -994,12 +994,7 @@ static void hl_device_eq_heartbeat(struct hl_device *hdev)
u64 event_mask = HL_NOTIFIER_EVENT_DEVICE_RESET |
HL_NOTIFIER_EVENT_DEVICE_UNAVAILABLE;
struct asic_fixed_properties *prop = >asic_prop;
-/*
- * This feature supported in FW version 1.12.0 45.2.0 and above,
- * only on those FW versions eq_health_check_supported will be set.
- * Start checking eq health only after driver has enabled events from
FW.
- */
- if (!prop->cpucp_info.eq_health_check_supported || !hdev->init_done)
+ if (!prop->cpucp_info.eq_health_check_supported)
return;
if (hdev->eq_heartbeat_received)
@@ -1015,7 +1010,8 @@ static void hl_device_heartbeat(struct work_struct *work)
struct hl_info_fw_err_info info = {0};
u64 event_mask = HL_NOTIFIER_EVENT_DEVICE_RESET |
HL_NOTIFIER_EVENT_DEVICE_UNAVAILABLE;
- if (!hl_device_operational(hdev, NULL))
+ /* Start heartbeat checks only after driver has enabled events from FW
*/
+ if (!hl_device_operational(hdev, NULL) || !hdev->init_done)
goto reschedule;
/*
--
2.34.1
Re: [PATCH] fbdev/sh7760fb: Depend on FB=y
Thomas Zimmermann writes: Hello Thomas, > Fix linker error if FB=m about missing fb_io_read and fb_io_write. The > linker's error message suggests that this config setting has already > been broken for other symbols. > > All errors (new ones prefixed by >>): > > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function > `sh7760fb_probe': > sh7760fb.c:(.text+0x374): undefined reference to `framebuffer_alloc' > sh4-linux-ld: sh7760fb.c:(.text+0x394): undefined reference to > `fb_videomode_to_var' > sh4-linux-ld: sh7760fb.c:(.text+0x39c): undefined reference to > `fb_alloc_cmap' > sh4-linux-ld: sh7760fb.c:(.text+0x3a4): undefined reference to > `register_framebuffer' > sh4-linux-ld: sh7760fb.c:(.text+0x3ac): undefined reference to > `fb_dealloc_cmap' > sh4-linux-ld: sh7760fb.c:(.text+0x434): undefined reference to > `framebuffer_release' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function > `sh7760fb_remove': > sh7760fb.c:(.text+0x800): undefined reference to `unregister_framebuffer' > sh4-linux-ld: sh7760fb.c:(.text+0x804): undefined reference to > `fb_dealloc_cmap' > sh4-linux-ld: sh7760fb.c:(.text+0x814): undefined reference to > `framebuffer_release' > >> sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0xc): undefined > reference to `fb_io_read' > >> sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x10): undefined > reference to `fb_io_write' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x2c): undefined > reference to `cfb_fillrect' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x30): undefined > reference to `cfb_copyarea' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x34): undefined > reference to `cfb_imageblit' > > Suggested-by: Randy Dunlap > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202309130632.ls04cpwu-...@intel.com/ > Signed-off-by: Thomas Zimmermann > --- Agreed with your change. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [Nouveau] [PATCH drm-misc-next v3 6/7] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
On 9/14/23 19:15, Danilo Krummrich wrote:
On 9/14/23 19:13, Thomas Hellström wrote:
On Thu, 2023-09-14 at 17:27 +0200, Danilo Krummrich wrote:
On 9/14/23 13:32, Thomas Hellström wrote:
On 9/14/23 12:57, Danilo Krummrich wrote:
On 9/13/23 14:16, Danilo Krummrich wrote:
And validate() can remove it while still holding all dma-
resv locks,
neat!
However, what if two tasks are trying to lock the VA space
concurrently? What
do we do when the drm_gpuvm_bo's refcount drops to zero in
drm_gpuva_unlink()?
Are we guaranteed that at this point of time the
drm_gpuvm_bo is not
on the
evicted list? Because otherwise we would call
drm_gpuvm_bo_destroy()
with the
dma-resv lock held, which wouldn't be allowed, since
drm_gpuvm_bo_destroy()
might drop the last reference to the drm_gem_object and
hence we'd
potentially
free the dma-resv lock while holding it, at least if it's
an external
object.
Easiest way in this scheme is to think of the lists as being
protected
by the vm's resv lock. That means anybody calling unlink()
must also
hold the vm's resv lock. (Which is OK from an UAF point of
view, but
perhaps not from a locking inversion POW from an async list
update).
This would mean that on unlink() we'd need to hold the VM's
resv lock and the
corresponding GEM's resv lock (in case they're not the same
anyways) because the
VM's resv lock would protect the external / evicted object
lists and the GEM
objects resv lock protects the GEM's list of drm_gpuvm_bos and
the
drm_gpuvm_bo's list of drm_gpuvas.
As mentioned below the same applies for drm_gpuvm_bo_put() since
it might
destroy the vm_bo, which includes removing the vm_bo from
external / evicted
object lists and the GEMs list of vm_bos.
As mentioned, if the GEM's dma-resv is different from the VM's
dma-resv we need
to take both locks. Ultimately, this would mean we need a
drm_exec loop, because
we can't know the order in which to take these locks. Doing a
full drm_exec loop
just to put() a vm_bo doesn't sound reasonable to me.
Can we instead just have an internal mutex for locking the lists
such that we
avoid taking and dropping the spinlocks, which we use currently,
in a loop?
You'd have the same locking inversion problem with a mutex, right?
Since in the eviction path you have resv->mutex, from exec you have
resv->mutex->resv because validate would attempt to grab resv.
Both lists, evict and extobj, would need to have a separate mutex,
not a common one.
We'd also need a dedicated GEM gpuva lock. Then the only rule would
be that you can't
hold the dma-resv lock when calling put(). Which I admit is not that
nice.
With the current spinlock solution drivers wouldn't need to worry
about anything locking
related though. So maybe I come back to your proposal of having a
switch for external
locking with dma-resv locks entirely. Such that with external dma-
resv locking I skip
all the spinlocks and add lockdep checks instead.
I think that makes the most sense in terms of taking advantage of
external dma-resv locking
where possible and on the other hand having a self-contained solution
if not. This should
get all concerns out of the way, yours, Christian's and Boris'.
If we need additional locks yes, I'd prefer the opt-in/opt-out spinlock
solution, and check back after a while to see if we can remove either
option once most pitfalls are hit.
Sounds good, I'll prepare this for a V4.
I was considering getting rid of the spinlocks using srcu for both external and
evicted objects instead. This would get us rid of taking/dropping the spinlock
in
every iteration step of the lists, limiting it to a single
srcu_read_{lock,unlock}
call per list walk. Plus, obviously the list_add_rcu() and list_del_rcu()
variants
as accessors. The accessors, would probably still need a spinlock to protect
against
concurrent list_add_rcu()/list_del_rcu() calls, but I think those are not a
concern.
Any concerns from your side with variant?
- Danilo
Thanks,
/Thomas
That said, xe currently indeed does the vm+bo exec dance on vma
put.
One reason why that seemingly horrible construct is good, is that
when evicting an extobj and you need to access individual vmas to
Zap page table entries or TLB flush, those VMAs are not allowed to
go away (we're not refcounting them). Holding the bo resv on gpuva
put prevents that from happening. Possibly one could use another
mutex to protect the gem->vm_bo list to achieve the same, but we'd
need to hold it on gpuva put.
/Thomas
- Danilo
For extobjs an outer lock would be enough in case of
Xe, but I
really would not
like to add even more complexity just to get the
spinlock out of
the way in case
the driver already has an outer lock protecting this
path.
I must disagree here. These spinlocks and atomic
operations are
pretty
costly and as discussed earlier this type of locking was
the reason
(at
least according to the commit message) that made
Christian drop the
XArray
use in drm_exec for the same set of objects:
Re: [PATCH v9 5/7] drm/mediatek: Add connector dynamic selection capability for mt8188
Re: [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v2)
On Sat, Sep 16, 2023 at 02:54:51PM +0200, Hans de Goede wrote: > Hi All, > > Some vlv/chv tablets ship with Android as factory OS. The factory OS > BSP style kernel on these tablets does not use the normal x86 hw > autodetection instead it hardcodes a whole bunch of things including > using panel drivers instead of relying on VBT MIPI sequences to > turn the panel/backlight on/off. > > The normal i915 driver (which does not use panel drivers) mostly works > since the VBT still needs to contain valid info for the GOP, but because > of the Android kernel relying on panel drivers with various things > hardcoded some DMI quirks are necessary to fix some issues on these > devices. > > Some of these issues also are related to which I2C bus to use for > MIPI sequence elements which do I2C transfers. This series also > includes a patch adding some extra debugging to mipi_exec_i2c() to > help with debugging similar issues in the future. > > These patches have been posted before but back then I did not get around > to follow up on the series: > https://lore.kernel.org/intel-gfx/20220225214934.383168-1-hdego...@redhat.com/ > > Changes compared to this old version: > - Drop the changes how the I2C bus number is found, instead just have > the quirks set the right number directly where necessary. This should > avoid any chances of causing regressions on devices where the quirks > do not apply. > > - New quirk for backlight control issues on Lenovo Yoga Tab 3 > > - Address Jani Nikula's remark about __func__ being redundant when using > drm_dbg_kms() > > > Regards, > > Hans > > > > Hans de Goede (4): > drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on > Asus TF103C (v2) > drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on > Lenovo Yoga Tablet 2 series (v2) > drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo > Yoga Tab 3 Please file a bug for each of these and attach the usual drm.debug=0xe dmesg + VBT + any other relevant information there. Otherwise a few years from now I'll be cursing at these commits as well for not leaving a decent papertrail... > drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2) > > drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 + > drivers/gpu/drm/i915/display/vlv_dsi.c | 124 +++ > 2 files changed, 127 insertions(+) > > -- > 2.41.0 -- Ville Syrjälä Intel
[PATCH for-next v2 09/10] mfd: cs42l43: convert to EXPORT_NS_GPL_RUNTIME_PM_OPS()
With original macro being renamed to EXPORT_NS_GPL_RUNTIME_PM_OPS(),
use the new macro.
Signed-off-by: Raag Jadav
---
drivers/mfd/cs42l43.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/cs42l43.c b/drivers/mfd/cs42l43.c
index 37b23e9bae82..b84adde9f89e 100644
--- a/drivers/mfd/cs42l43.c
+++ b/drivers/mfd/cs42l43.c
@@ -1177,7 +1177,7 @@ static int cs42l43_runtime_resume(struct device *dev)
return ret;
}
-EXPORT_NS_GPL_DEV_PM_OPS(cs42l43_pm_ops, MFD_CS42L43) = {
+EXPORT_NS_GPL_RUNTIME_PM_OPS(cs42l43_pm_ops, MFD_CS42L43) = {
SET_SYSTEM_SLEEP_PM_OPS(cs42l43_suspend, cs42l43_resume)
SET_RUNTIME_PM_OPS(cs42l43_runtime_suspend, cs42l43_runtime_resume,
NULL)
};
--
2.17.1
[PATCH for-next v2 10/10] ASoC: cs35l41: convert to EXPORT_GPL_RUNTIME_PM_OPS()
With original macro being renamed to EXPORT_GPL_RUNTIME_PM_OPS(),
use the new macro.
Signed-off-by: Raag Jadav
---
sound/soc/codecs/cs35l41.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/cs35l41.c b/sound/soc/codecs/cs35l41.c
index 4bc64ba71cd6..651aeaa6a5c4 100644
--- a/sound/soc/codecs/cs35l41.c
+++ b/sound/soc/codecs/cs35l41.c
@@ -1454,7 +1454,7 @@ static int cs35l41_sys_resume(struct device *dev)
return 0;
}
-EXPORT_GPL_DEV_PM_OPS(cs35l41_pm_ops) = {
+EXPORT_GPL_RUNTIME_PM_OPS(cs35l41_pm_ops) = {
RUNTIME_PM_OPS(cs35l41_runtime_suspend, cs35l41_runtime_resume, NULL)
SYSTEM_SLEEP_PM_OPS(cs35l41_sys_suspend, cs35l41_sys_resume)
--
2.17.1
[PATCH for-next v2 07/10] drm/imx/dcss: convert to EXPORT_GPL_RUNTIME_PM_OPS()
With original macro being renamed to EXPORT_GPL_RUNTIME_PM_OPS(),
use the new macro.
Signed-off-by: Raag Jadav
---
drivers/gpu/drm/imx/dcss/dcss-dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c
b/drivers/gpu/drm/imx/dcss/dcss-dev.c
index 4f3af0dfb344..8544c2db4187 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
@@ -318,7 +318,7 @@ static int dcss_dev_runtime_resume(struct device *dev)
return 0;
}
-EXPORT_GPL_DEV_PM_OPS(dcss_dev_pm_ops) = {
+EXPORT_GPL_RUNTIME_PM_OPS(dcss_dev_pm_ops) = {
RUNTIME_PM_OPS(dcss_dev_runtime_suspend, dcss_dev_runtime_resume, NULL)
SYSTEM_SLEEP_PM_OPS(dcss_dev_suspend, dcss_dev_resume)
};
--
2.17.1
[PATCH for-next v2 08/10] mfd: arizona: convert to EXPORT_GPL_RUNTIME_PM_OPS()
With original macro being renamed to EXPORT_GPL_RUNTIME_PM_OPS(),
use the new macro.
Signed-off-by: Raag Jadav
---
drivers/mfd/arizona-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 19a0adf8ce3d..1d36deb1b79f 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -781,7 +781,7 @@ static int arizona_resume(struct device *dev)
return 0;
}
-EXPORT_GPL_DEV_PM_OPS(arizona_pm_ops) = {
+EXPORT_GPL_RUNTIME_PM_OPS(arizona_pm_ops) = {
RUNTIME_PM_OPS(arizona_runtime_suspend,
arizona_runtime_resume,
NULL)
--
2.17.1
Re: [PATCH v3 1/4] drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
Am 18.09.23 um 13:48 schrieb Karolina Stolarek:
On 12.09.2023 14:54, Christian König wrote:
Am 12.09.23 um 13:49 schrieb Karolina Stolarek:
Test initialization of ttm_resource using different memory domains.
Add tests for a system memory manager and functions that can be
tested without a fully-featured resource manager. Update
ttm_bo_kunit_init() to initialize BO's kref and reservation object.
Export ttm_resource_alloc symbol for test purposes only.
Signed-off-by: Karolina Stolarek
---
drivers/gpu/drm/ttm/tests/Makefile | 1 +
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 23 ++
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 4 +
drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335
++
drivers/gpu/drm/ttm/ttm_resource.c | 3 +
5 files changed, 366 insertions(+)
create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
diff --git a/drivers/gpu/drm/ttm/tests/Makefile
b/drivers/gpu/drm/ttm/tests/Makefile
index ec87c4fc1ad5..c92fe2052ef6 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -3,4 +3,5 @@
obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
ttm_device_test.o \
ttm_pool_test.o \
+ ttm_resource_test.o \
ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 81661d8827aa..eccc59b981f8 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -38,10 +38,33 @@ struct ttm_buffer_object
*ttm_bo_kunit_init(struct kunit *test,
bo->base = gem_obj;
bo->bdev = devs->ttm_dev;
+ kref_init(>kref);
+
+ dma_resv_init(>base._resv);
+ bo->base.resv = >base._resv;
+
I'm really wondering if we shouldn't now initialize the GEM object
properly?
That would also initialize the reservation object if I remember
correctly.
Do you mean by using drm_gem_object_init()?
I think drm_gem_private_object_init is the right function for this, but
not 100% sure.
The solution with EXPORT_SYMBOL_FOR_TESTS_ONLY looks really nice I
think and apart from that I can't see anything obviously wrong
either, but I only skimmed over the code.
I'm also glad with EXPORT_SYMBOL_FOR_TESTS_ONLY solution, it's much
better now. Right, you can take a closer look at the next version.
I'll try to get an actual GEM object here, if you think that's feasible.
I can't promise it, but going to take a look when I have time.
Regards,
Christian.
All the best,
Karolina
Regards,
Christian.
return bo;
}
EXPORT_SYMBOL_GPL(ttm_bo_kunit_init);
+struct ttm_place *ttm_place_kunit_init(struct kunit *test,
+ uint32_t mem_type, uint32_t flags,
+ size_t size)
+{
+ struct ttm_place *place;
+
+ place = kunit_kzalloc(test, sizeof(*place), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, place);
+
+ place->mem_type = mem_type;
+ place->flags = flags;
+ place->fpfn = size >> PAGE_SHIFT;
+ place->lpfn = place->fpfn + (size >> PAGE_SHIFT);
+
+ return place;
+}
+EXPORT_SYMBOL_GPL(ttm_place_kunit_init);
+
struct ttm_test_devices *ttm_test_devices_basic(struct kunit *test)
{
struct ttm_test_devices *devs;
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
index e261e3660d0b..f38140f93c05 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,6 +29,9 @@ int ttm_device_kunit_init(struct ttm_test_devices
*priv,
struct ttm_buffer_object *ttm_bo_kunit_init(struct kunit *test,
struct ttm_test_devices *devs,
size_t size);
+struct ttm_place *ttm_place_kunit_init(struct kunit *test,
+ uint32_t mem_type, uint32_t flags,
+ size_t size);
struct ttm_test_devices *ttm_test_devices_basic(struct kunit *test);
struct ttm_test_devices *ttm_test_devices_all(struct kunit *test);
diff --git a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
new file mode 100644
index ..851cdc43dc37
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
@@ -0,0 +1,335 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include
+
+#include "ttm_kunit_helpers.h"
+
+#define RES_SIZE SZ_4K
+#define TTM_PRIV_DUMMY_REG (TTM_NUM_MEM_TYPES - 1)
+
+struct ttm_resource_test_case {
+ const char *description;
+ uint32_t mem_type;
+ uint32_t flags;
+};
+
+struct ttm_resource_test_priv {
+ struct ttm_test_devices *devs;
+ struct ttm_buffer_object *bo;
+ struct ttm_place *place;
+};
+
+static const struct ttm_resource_manager_func
ttm_resource_manager_mock_funcs = { };
+
+static int
Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570
On Wed, Sep 13, 2023 at 03:02:26PM +0300, Jaak Ristioja wrote:
> Hello,
>
> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank screen
> after boot until the display manager starts... if it does start at all.
> Using the nomodeset kernel parameter seems to be a workaround.
>
> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> ("drivers/firmware: Move sysfb_init() from device_initcall to
> subsys_initcall_sync").
>
Thanks for the regression report. I'm adding it to regzbot:
#regzbot ^introduced: 60aebc9559492c
--
An old man doll... just what I always wanted! - Clara
signature.asc
Description: PGP signature
[PATCH] fbdev/sh7760fb: Depend on FB=y
Fix linker error if FB=m about missing fb_io_read and fb_io_write. The linker's error message suggests that this config setting has already been broken for other symbols. All errors (new ones prefixed by >>): sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_probe': sh7760fb.c:(.text+0x374): undefined reference to `framebuffer_alloc' sh4-linux-ld: sh7760fb.c:(.text+0x394): undefined reference to `fb_videomode_to_var' sh4-linux-ld: sh7760fb.c:(.text+0x39c): undefined reference to `fb_alloc_cmap' sh4-linux-ld: sh7760fb.c:(.text+0x3a4): undefined reference to `register_framebuffer' sh4-linux-ld: sh7760fb.c:(.text+0x3ac): undefined reference to `fb_dealloc_cmap' sh4-linux-ld: sh7760fb.c:(.text+0x434): undefined reference to `framebuffer_release' sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_remove': sh7760fb.c:(.text+0x800): undefined reference to `unregister_framebuffer' sh4-linux-ld: sh7760fb.c:(.text+0x804): undefined reference to `fb_dealloc_cmap' sh4-linux-ld: sh7760fb.c:(.text+0x814): undefined reference to `framebuffer_release' >> sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0xc): undefined reference to `fb_io_read' >> sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x10): undefined reference to `fb_io_write' sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x2c): undefined reference to `cfb_fillrect' sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x30): undefined reference to `cfb_copyarea' sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x34): undefined reference to `cfb_imageblit' Suggested-by: Randy Dunlap Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202309130632.ls04cpwu-...@intel.com/ Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 4455bfd57f0ec..64ccb34d882dd 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -1756,7 +1756,7 @@ config FB_COBALT config FB_SH7760 bool "SH7760/SH7763/SH7720/SH7721 LCDC support" - depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \ + depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \ || CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721) select FB_IOMEM_HELPERS help -- 2.42.0
[PATCH 08/14] accel/habanalabs/gaudi2: handle eq health heartbeat check
From: farah kassabri
Add mechanism for fw eq health check. this will be done using two flows:
using the heartbeat mechanism and raising a dedicated interrupt to
indicate an eq failure like EQ full.
This patch will add implementation for the eq heartbeat for gaudi2 asic.
More info about the heartbeat mechanism:
Expand the heartbeat mechanism to monitor a new event that
will be sent from FW upon receiving heartbeat message.
that way driver can know that the eq is working or not.
Signed-off-by: farah kassabri
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 37 ++-
drivers/accel/habanalabs/common/habanalabs.h | 2 +
drivers/accel/habanalabs/gaudi2/gaudi2.c | 10 +
.../gaudi2/gaudi2_async_ids_map_extended.h| 14 ---
include/linux/habanalabs/cpucp_if.h | 14 ++-
5 files changed, 68 insertions(+), 9 deletions(-)
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index bf1b53f7fce9..1d68d2233171 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -989,6 +989,25 @@ static bool is_pci_link_healthy(struct hl_device *hdev)
return (vendor_id == PCI_VENDOR_ID_HABANALABS);
}
+static void hl_device_eq_heartbeat(struct hl_device *hdev)
+{
+ u64 event_mask = HL_NOTIFIER_EVENT_DEVICE_RESET |
HL_NOTIFIER_EVENT_DEVICE_UNAVAILABLE;
+ struct asic_fixed_properties *prop = >asic_prop;
+
+/*
+ * This feature supported in FW version 1.12.0 45.2.0 and above,
+ * only on those FW versions eq_health_check_supported will be set.
+ * Start checking eq health only after driver has enabled events from
FW.
+ */
+ if (!prop->cpucp_info.eq_health_check_supported || !hdev->init_done)
+ return;
+
+ if (hdev->eq_heartbeat_received)
+ hdev->eq_heartbeat_received = false;
+ else
+ hl_device_cond_reset(hdev, HL_DRV_RESET_HARD, event_mask);
+}
+
static void hl_device_heartbeat(struct work_struct *work)
{
struct hl_device *hdev = container_of(work, struct hl_device,
@@ -999,6 +1018,12 @@ static void hl_device_heartbeat(struct work_struct *work)
if (!hl_device_operational(hdev, NULL))
goto reschedule;
+ /*
+* For EQ health check need to check if driver received the heartbeat
eq event
+* in order to validate the eq is working.
+*/
+ hl_device_eq_heartbeat(hdev);
+
if (!hdev->asic_funcs->send_heartbeat(hdev))
goto reschedule;
@@ -1055,7 +1080,15 @@ static int device_late_init(struct hl_device *hdev)
hdev->high_pll = hdev->asic_prop.high_pll;
if (hdev->heartbeat) {
+ /*
+* Before scheduling the heartbeat driver will check if eq
event has received.
+* for the first schedule we need to set the indication as true
then for the next
+* one this indication will be true only if eq event was sent
by FW.
+*/
+ hdev->eq_heartbeat_received = true;
+
INIT_DELAYED_WORK(>work_heartbeat, hl_device_heartbeat);
+
schedule_delayed_work(>work_heartbeat,
usecs_to_jiffies(HL_HEARTBEAT_PER_USEC));
}
@@ -2235,8 +2268,6 @@ int hl_device_init(struct hl_device *hdev)
"Successfully added device %s to habanalabs driver\n",
dev_name(&(hdev)->pdev->dev));
- hdev->init_done = true;
-
/* After initialization is done, we are ready to receive events from
* the F/W. We can't do it before because we will ignore events and if
* those events are fatal, we won't know about it and the device will
@@ -2244,6 +2275,8 @@ int hl_device_init(struct hl_device *hdev)
*/
hdev->asic_funcs->enable_events_from_fw(hdev);
+ hdev->init_done = true;
+
return 0;
cb_pool_fini:
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index f8c597903cac..e5b416852996 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -3314,6 +3314,7 @@ struct hl_reset_info {
* device.
* @supports_ctx_switch: true if a ctx switch is required upon first
submission.
* @support_preboot_binning: true if we support read binning info from preboot.
+ * @eq_heartbeat_received: indication that eq heartbeat event has received
from FW.
* @nic_ports_mask: Controls which NIC ports are enabled. Used only for
testing.
* @fw_components: Controls which f/w components to load to the device. There
are multiple f/w
* stages and sometimes we want to stop at a certain stage.
Used only for testing.
@@ -3474,6 +3475,7 @@ struct hl_device {
u8
Re: [PATCH v2 1/5] string.h: add array-wrappers for (v)memdup_user()
On Sat, 2023-09-16 at 17:32 +0300, Dan Carpenter wrote:
> On Fri, Sep 08, 2023 at 09:59:40PM +0200, Philipp Stanner wrote:
> > +static inline void *memdup_array_user(const void __user *src,
> > size_t n, size_t size)
> > +{
> > + size_t nbytes;
> > +
> > + if (unlikely(check_mul_overflow(n, size, )))
> > + return ERR_PTR(-EOVERFLOW);
>
> No need for an unlikely() because check_mul_overflow() already has
> one
> inside.
ACK. I overlooked that as it was hidden in the callstack.
> I feel like -ENOMEM is more traditional but I doubt
> anyone/userspace
> cares.
I agree with Andy here. We're not allocating, so -ENOMEM makes no sense
IMO.
P.
>
> > +
> > + return memdup_user(src, nbytes);
> > +}
>
> regards,
> dan carpenter
>
[PATCH 14/14] accel/habanalabs: tiny refactor of hl_map_dmabuf()
From: Tomer Tayar
alloc_sgt_from_device_pages() includes relatively many parameters, and
in a subsequent change another offset parameter is going to be added.
Using structure fields directly when calling this function, and in
hl_map_dmabuf() it is done twice, makes it a little bit difficult to
understand the meaning of the parameters.
To make it clearer, assign the required values into local variables with
explicit names, and use the variables when calling the function.
Signed-off-by: Tomer Tayar
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/memory.c | 37 +++-
1 file changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/accel/habanalabs/common/memory.c
b/drivers/accel/habanalabs/common/memory.c
index b4a9ff692ebc..d0edbe4b4210 100644
--- a/drivers/accel/habanalabs/common/memory.c
+++ b/drivers/accel/habanalabs/common/memory.c
@@ -1699,38 +1699,35 @@ static int hl_dmabuf_attach(struct dma_buf *dmabuf,
static struct sg_table *hl_map_dmabuf(struct dma_buf_attachment *attachment,
enum dma_data_direction dir)
{
+ u64 *pages, npages, page_size, exported_size;
struct dma_buf *dma_buf = attachment->dmabuf;
struct hl_vm_phys_pg_pack *phys_pg_pack;
struct hl_dmabuf_priv *hl_dmabuf;
struct hl_device *hdev;
struct sg_table *sgt;
- hl_dmabuf = dma_buf->priv;
- hdev = hl_dmabuf->ctx->hdev;
- phys_pg_pack = hl_dmabuf->phys_pg_pack;
-
if (!attachment->peer2peer) {
dev_dbg(hdev->dev, "Failed to map dmabuf because p2p is
disabled\n");
return ERR_PTR(-EPERM);
}
- if (phys_pg_pack)
- sgt = alloc_sgt_from_device_pages(hdev,
- phys_pg_pack->pages,
- phys_pg_pack->npages,
- phys_pg_pack->page_size,
- hl_dmabuf->dmabuf->size,
- attachment->dev,
- dir);
- else
- sgt = alloc_sgt_from_device_pages(hdev,
- _dmabuf->device_address,
- 1,
- hl_dmabuf->dmabuf->size,
- hl_dmabuf->dmabuf->size,
- attachment->dev,
- dir);
+ hl_dmabuf = dma_buf->priv;
+ hdev = hl_dmabuf->ctx->hdev;
+ exported_size = hl_dmabuf->dmabuf->size;
+ phys_pg_pack = hl_dmabuf->phys_pg_pack;
+
+ if (phys_pg_pack) {
+ pages = phys_pg_pack->pages;
+ npages = phys_pg_pack->npages;
+ page_size = phys_pg_pack->page_size;
+ } else {
+ pages = _dmabuf->device_address;
+ npages = 1;
+ page_size = hl_dmabuf->dmabuf->size;
+ }
+ sgt = alloc_sgt_from_device_pages(hdev, pages, npages, page_size,
exported_size,
+ attachment->dev, dir);
if (IS_ERR(sgt))
dev_err(hdev->dev, "failed (%ld) to initialize sgt for
dmabuf\n", PTR_ERR(sgt));
--
2.34.1
