[PULL] drm-misc-fixes
Hi Dave and Daniel, here are the 2 fixes from this week's drm-misc-next. Best regards Thomas drm-misc-fixes-2021-01-27: * drm/vc4: Fix LBM size calculation; Fix high resolutions for hvs5 The following changes since commit a37eef63bc9e16e06361b539e528058146af80ab: drm/syncobj: Fix use-after-free (2021-01-20 10:28:39 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-01-27 for you to fetch changes up to f6b57101a6b31277a4bde1d8028c46e898bd2ff2: drm/vc4: Correct POS1_SCL for hvs5 (2021-01-25 11:53:44 +0100) Short summary of fixes pull (less than what git shortlog provides): * drm/vc4: Fix LBM size calculation; Fix high resolutions for hvs5 Dom Cobley (2): drm/vc4: Correct lbm size and calculation drm/vc4: Correct POS1_SCL for hvs5 drivers/gpu/drm/vc4/vc4_hvs.c | 8 drivers/gpu/drm/vc4/vc4_plane.c | 11 --- 2 files changed, 12 insertions(+), 7 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] nouveau-fixes 5.11
Hey Dave, Mostly a regression fixes here, a couple of which could lead to display hanging, and have been affecting a number of users. Ben. The following changes since commit 8ef23b6f6a79e6fa2a169081d2d76011fffa0482: drm/nouveau/disp/ga10[24]: initial support (2021-01-15 10:25:24 +1000) are available in the Git repository at: git://github.com/skeggsb/linux 04.01-ampere-lite for you to fetch changes up to d2be5ff9f287b8815c36e95ea34dc4b09f313c3b: drm/nouveau/kms/gk104-gp1xx: Fix > 64x64 cursors (2021-01-27 16:36:13 +1000) Bastian Beranek (1): drm/nouveau/dispnv50: Restore pushing of all data. Ben Skeggs (1): drm/nouveau/nvif: fix method count when pushing an array Karol Herbst (1): drm/nouveau/svm: fail NOUVEAU_SVM_INIT ioctl on unsupported devices Lyude Paul (3): drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes drm/nouveau/kms/nv50-: Report max cursor size to userspace drm/nouveau/kms/gk104-gp1xx: Fix > 64x64 cursors drivers/gpu/drm/nouveau/dispnv50/base507c.c | 6 ++- drivers/gpu/drm/nouveau/dispnv50/base827c.c | 6 ++- drivers/gpu/drm/nouveau/dispnv50/disp.c | 8 drivers/gpu/drm/nouveau/dispnv50/head917d.c | 28 ++- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 17 +-- drivers/gpu/drm/nouveau/include/nvhw/class/cl917d.h | 4 ++ drivers/gpu/drm/nouveau/include/nvif/push.h | 216 ++-- drivers/gpu/drm/nouveau/nouveau_svm.c | 4 ++ 8 files changed, 174 insertions(+), 115 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/5] amba: Make the remove callback return void
On Tue, 26 Jan 2021 17:58:34 +0100, Uwe Kleine-König wrote: > > All amba drivers return 0 in their remove callback. Together with the > driver core ignoring the return value anyhow, it doesn't make sense to > return a value here. > > Change the remove prototype to return void, which makes it explicit that > returning an error value doesn't work as expected. This simplifies changing > the core remove callback to return void, too. > > Reviewed-by: Ulf Hansson > Reviewed-by: Arnd Bergmann > Acked-by: Alexandre Belloni > Acked-by: Dmitry Torokhov > Acked-by: Krzysztof Kozlowski # for drivers/memory > Acked-by: Mark Brown > Acked-by: Dmitry Torokhov > Acked-by: Linus Walleij > Signed-off-by: Uwe Kleine-König > --- > drivers/amba/bus.c | 5 ++--- > drivers/char/hw_random/nomadik-rng.c | 3 +-- > drivers/dma/pl330.c| 3 +-- > drivers/gpu/drm/pl111/pl111_drv.c | 4 +--- > drivers/hwtracing/coresight/coresight-catu.c | 3 +-- > drivers/hwtracing/coresight/coresight-cpu-debug.c | 4 +--- > drivers/hwtracing/coresight/coresight-cti-core.c | 4 +--- > drivers/hwtracing/coresight/coresight-etb10.c | 4 +--- > drivers/hwtracing/coresight/coresight-etm3x-core.c | 4 +--- > drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 +--- > drivers/hwtracing/coresight/coresight-funnel.c | 4 ++-- > drivers/hwtracing/coresight/coresight-replicator.c | 4 ++-- > drivers/hwtracing/coresight/coresight-stm.c| 4 +--- > drivers/hwtracing/coresight/coresight-tmc-core.c | 4 +--- > drivers/hwtracing/coresight/coresight-tpiu.c | 4 +--- > drivers/i2c/busses/i2c-nomadik.c | 4 +--- > drivers/input/serio/ambakmi.c | 3 +-- > drivers/memory/pl172.c | 4 +--- > drivers/memory/pl353-smc.c | 4 +--- > drivers/mmc/host/mmci.c| 4 +--- > drivers/rtc/rtc-pl030.c| 4 +--- > drivers/rtc/rtc-pl031.c| 4 +--- > drivers/spi/spi-pl022.c| 5 ++--- > drivers/tty/serial/amba-pl010.c| 4 +--- > drivers/tty/serial/amba-pl011.c| 3 +-- > drivers/vfio/platform/vfio_amba.c | 3 +-- > drivers/video/fbdev/amba-clcd.c| 4 +--- > drivers/watchdog/sp805_wdt.c | 4 +--- > include/linux/amba/bus.h | 2 +- > sound/arm/aaci.c | 4 +--- For the sound/*: Acked-by: Takashi Iwai thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 02:19:27PM +0800, carlis wrote:
> hi,i will fix it like below:
> par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0,
> GPIOD_IN); if (IS_ERR(par->gpio.te)) {
> rc = PTR_ERR(par->gpio.te);
> pr_err("Failed to request te gpio: %d\n", rc);
> par->gpio.te = NULL;
> }
I wish you would just copy and paste the code that I sent you instead,
but this also fixes the crash...
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/5] amba: Make the remove callback return void
On Tue, Jan 26, 2021 at 05:58:34PM +0100, Uwe Kleine-König wrote: > All amba drivers return 0 in their remove callback. Together with the > driver core ignoring the return value anyhow, it doesn't make sense to > return a value here. > > Change the remove prototype to return void, which makes it explicit that > returning an error value doesn't work as expected. This simplifies changing > the core remove callback to return void, too. > > Reviewed-by: Ulf Hansson > Reviewed-by: Arnd Bergmann > Acked-by: Alexandre Belloni > Acked-by: Dmitry Torokhov > Acked-by: Krzysztof Kozlowski # for drivers/memory > Acked-by: Mark Brown > Acked-by: Dmitry Torokhov > Acked-by: Linus Walleij > Signed-off-by: Uwe Kleine-König Acked-by: Wolfram Sang # for I2C signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 09:32:20AM +0800, Carlis wrote:
> @@ -82,6 +111,29 @@ enum st7789v_command {
> */
> static int init_display(struct fbtft_par *par)
> {
> + int rc;
> + struct device *dev = par->info->device;
> +
> + par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
> + if (par->gpio.te) {
> + init_completion(_panel_te);
> + mutex_init(_mutex);
> + rc = devm_request_irq(dev,
> + gpiod_to_irq(par->gpio.te),
> + spi_panel_te_handler, IRQF_TRIGGER_RISING,
> + "TE_GPIO", par);
> + if (rc) {
> + pr_err("TE request_irq failed.\n");
> + devm_gpiod_put(dev, par->gpio.te);
> + par->gpio.te = NULL;
> + } else {
> + disable_irq_nosync(gpiod_to_irq(par->gpio.te));
> + pr_info("TE request_irq completion.\n");
This printk adds no value.
Don't print anything on the success path. You should add that to your
code while your debugging the feature, but don't push it to the upstream
kernel.
> + }
> + } else {
> + pr_info("%s:%d, TE gpio not specified\n",
> + __func__, __LINE__);
> + }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 09:32:20AM +0800, Carlis wrote:
> @@ -82,6 +111,29 @@ enum st7789v_command {
> */
> static int init_display(struct fbtft_par *par)
> {
> + int rc;
> + struct device *dev = par->info->device;
> +
> + par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
> + if (par->gpio.te) {
> + init_completion(_panel_te);
> + mutex_init(_mutex);
> + rc = devm_request_irq(dev,
> + gpiod_to_irq(par->gpio.te),
> + spi_panel_te_handler, IRQF_TRIGGER_RISING,
> + "TE_GPIO", par);
> + if (rc) {
> + pr_err("TE request_irq failed.\n");
> + devm_gpiod_put(dev, par->gpio.te);
> + par->gpio.te = NULL;
> + } else {
> + disable_irq_nosync(gpiod_to_irq(par->gpio.te));
> + pr_info("TE request_irq completion.\n");
> + }
> + } else {
> + pr_info("%s:%d, TE gpio not specified\n",
> + __func__, __LINE__);
> + }
I'm sorry that I was not clear before. This code will crash if
devm_gpiod_get_index_optional() returns an error. You *NEED* to check
for error pointers and return the error code. Write it exactly like
this:
par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
if (IS_ERR(par->gpio.te))
return PTR_ERR(par->gpio.te);
if (par->gpio.te) {
init_completion(_panel_te);
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=211277 --- Comment #5 from Jerome C (m...@jeromec.com) --- Created attachment 294879 --> https://bugzilla.kernel.org/attachment.cgi?id=294879=edit Kernel log Unfortunately it crashed again although I've noticed it's been crashing a lot less (4-5 days) since I set kernel parameter "init_on_free=0". I've attached a kernel log for 5.10.10 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211033] [bisected][regression] amdgpu: *ERROR* Restoring old state failed with -12
https://bugzilla.kernel.org/show_bug.cgi?id=211033 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #15 from Alex Deucher (alexdeuc...@gmail.com) --- already reverted in stable: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=261f4d03ad23c63964a6e1dd7b3611b108b1cb57 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: dma-fence: Document recoverable page fault implications
Am 2021-01-21 um 2:40 p.m. schrieb Daniel Vetter: > Recently there was a fairly long thread about recoreable hardware page > faults, how they can deadlock, and what to do about that. > > While the discussion is still fresh I figured good time to try and > document the conclusions a bit. > > References: > https://lore.kernel.org/dri-devel/20210107030127.20393-1-felix.kuehl...@amd.com/ > Cc: Maarten Lankhorst > Cc: Thomas Hellström > Cc: "Christian König" > Cc: Jerome Glisse > Cc: Felix Kuehling > Signed-off-by: Daniel Vetter > Cc: Sumit Semwal > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > -- > I'll be away next week, but figured I'll type this up quickly for some > comments and to check whether I got this all roughly right. > > Critique very much wanted on this, so that we can make sure hw which > can't preempt (with pagefaults pending) like gfx10 has a clear path to > support page faults in upstream. So anything I missed, got wrong or > like that would be good. > -Daniel > --- > Documentation/driver-api/dma-buf.rst | 66 > 1 file changed, 66 insertions(+) > > diff --git a/Documentation/driver-api/dma-buf.rst > b/Documentation/driver-api/dma-buf.rst > index a2133d69872c..e924c1e4f7a3 100644 > --- a/Documentation/driver-api/dma-buf.rst > +++ b/Documentation/driver-api/dma-buf.rst > @@ -257,3 +257,69 @@ fences in the kernel. This means: >userspace is allowed to use userspace fencing or long running compute >workloads. This also means no implicit fencing for shared buffers in these >cases. > + > +Recoverable Hardware Page Faults Implications > +~ > + > +Modern hardware supports recoverable page faults, which has a lot of > +implications for DMA fences. > + > +First, a pending page fault obviously holds up the work that's running on the > +accelerator and a memory allocation is usually required to resolve the fault. > +But memory allocations are not allowed to gate completion of DMA fences, > which > +means any workload using recoverable page faults cannot use DMA fences for > +synchronization. Synchronization fences controlled by userspace must be used > +instead. > + > +On GPUs this poses a problem, because current desktop compositor protocols on > +Linus rely on DMA fences, which means without an entirely new userspace stack > +built on top of userspace fences, they cannot benefit from recoverable page > +faults. The exception is when page faults are only used as migration hints > and > +never to on-demand fill a memory request. For now this means recoverable page > +faults on GPUs are limited to pure compute workloads. > + > +Furthermore GPUs usually have shared resources between the 3D rendering and > +compute side, like compute units or command submission engines. If both a 3D > +job with a DMA fence and a compute workload using recoverable page faults are > +pending they could deadlock: > + > +- The 3D workload might need to wait for the compute job to finish and > release > + hardware resources first. > + > +- The compute workload might be stuck in a page fault, because the memory > + allocation is waiting for the DMA fence of the 3D workload to complete. > + > +There are a few ways to prevent this problem: > + > +- Compute workloads can always be preempted, even when a page fault is > pending > + and not yet repaired. Not all hardware supports this. > + > +- DMA fence workloads and workloads which need page fault handling have > + independent hardware resources to guarantee forward progress. This could be > + achieved through e.g. through dedicated engines and minimal compute unit > + reservations for DMA fence workloads. > + > +- The reservation approach could be further refined by only reserving the > + hardware resources for DMA fence workloads when they are in-flight. This > must > + cover the time from when the DMA fence is visible to other threads up to > + moment when fence is completed through dma_fence_signal(). > + > +- As a last resort, if the hardware provides no useful reservation mechanics, > + all workloads must be flushed from the GPU when switching between jobs > + requiring DMA fences or jobs requiring page fault handling: This means all > DMA > + fences must complete before a compute job with page fault handling can be > + inserted into the scheduler queue. And vice versa, before a DMA fence can > be > + made visible anywhere in the system, all compute workloads must be > preempted > + to guarantee all pending GPU page faults are flushed. I thought of another possible workaround: * Partition the memory. Servicing of page faults will use a separate memory pool that can always be allocated from without waiting for fences. This includes memory for page tables and memory for migrating data to. You may steal memory from other processes that can page fault, so no fence waiting is necessary. Being able to steal memory at
[Bug 211033] [bisected][regression] amdgpu: *ERROR* Restoring old state failed with -12
https://bugzilla.kernel.org/show_bug.cgi?id=211033 Shawn Anastasio (sh...@anastas.io) changed: What|Removed |Added CC||sh...@anastas.io --- Comment #14 from Shawn Anastasio (sh...@anastas.io) --- I can confirm the same issue on 5.10.4 with a 2x 4K KVM setup on an AMD Radeon Pro WX 5100 (Talos II POWER9 host). -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1
On Tue, Jan 26, 2021 at 9:53 PM Andy Shevchenko wrote: > > On Tue, Jan 26, 2021 at 8:33 PM Hans de Goede wrote: > > On 1/26/21 6:14 PM, Andy Shevchenko wrote: > > > On Tue, Jan 26, 2021 at 6:55 PM Patrik Jakobsson > > > wrote: > > >> On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko > > >> wrote: > > >>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > > >>> wrote: > > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > > wrote: > > > > > > Hi guys, > > > > > > This is first part of Intel MID outdated platforms removal. It's > > > collected into > > > immutable branch with a given tag, please pull to yours subsystems. > > > > Hi Andy, > > Do you plan on eventually removing X86_INTEL_MID completely? If so, > > then I should probably start looking at removing the corresponding > > parts in GMA500. > > >>> > > >>> Nope. It is related to only Medfield / Clovertrail platforms. > > >>> > > >>> There are other (MID) platforms that may / might utilize this driver > > >>> in the future. > > >> > > >> Right, there's still Oaktrail / Moorestown with hardware in the wild. > > > > > > Actually Moorestown had to be removed a few years ago (kernel won't > > > boot on them anyway from that date when Alan removed support under > > > arch/x86 for it). Ok. I lump Moorestown and Oaktrail together since they have the same Z6xx series CPU/GPU (GMA600). I still have a working Oaktrail device so that support should stay in gma500. > > > > > > I'm talking about Merrifield and Moorefield that can utilize it and > > > also some other platforms that are not SFI based (Cedar something... > > > IIRC). > > > > Yes at least there are some 64 bit capable SoCs with GMA500 which were > > used in NAS like devices. These NAS-es actually have a VGA output > > (and maybe also DVI?) which is attached to the GMA500. Yes these should be Cedarview/Cedartrail. Some of them are 64-bit and some are 32-bit. I think it came down to if bios enabled it or not. Cedarview comes with VGA, DVI and eDP/DP. Quite a few Cedarview devices exist in the wild. > > Since you are talking about 64-bit, definitely they are *not* > Moorestown, Medfield, Clovertrail since the mentioned never were > 64-bit. But it would be nice to see the CPU model number to be sure. > > > I know people are running Fedora on these, so we should at least keep > > these supported. > > Is it possible to gather the CPU model number from them? (Or at least > the exact device/box name) Yes, it would be interesting to know more about Clovertrail. gma500 only supports up to the Cedarview GPUs but Clovertrail might also use a Cedarview GPU. -Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 9/9] drm/i915: Use memory cgroup for enforcing device memory limit
To charge device memory allocations, we need to (1) identify appropriate
cgroup to charge (currently decided at object creation time), and (2)
make the charging call at the time that memory pages are being allocated.
For (1), see prior DRM patch which associates current task's cgroup with
GEM objects as they are created. That cgroup will be charged/uncharged
for all paging activity against the GEM object.
For (2), we call drm_get_object_charge_mem() in .get_pages callback
for the GEM object type. Uncharging is done in .put_pages when the
memory is marked such that it can be evicted. The try_charge() call will
fail with -ENOMEM if the current memory allocation will exceed the cgroup
device memory maximum, and allow for driver to perform memory reclaim.
We also set the total device memory reported by DRM cgroup by storing
in drm_device.drmcg_props after initializing LMEM memory regions.
FIXME: to release drm cgroup reference requires this additional patch:
https://patchwork.freedesktop.org/patch/349029
Signed-off-by: Brian Welty
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_region.c | 23 ++
drivers/gpu/drm/i915/intel_memory_region.c | 13 ++--
drivers/gpu/drm/i915/intel_memory_region.h | 2 +-
4 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index ec28a6cde49b..9fbe91d4d2f1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -16,6 +16,7 @@
#include "i915_gem_gtt.h"
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"
+#include "i915_gem_lmem.h"
#include "i915_gem_mman.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 3e3dad22a683..690b36b25984 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -12,11 +12,14 @@ void
i915_gem_object_put_pages_buddy(struct drm_i915_gem_object *obj,
struct sg_table *pages)
{
- __intel_memory_region_put_pages_buddy(obj->mm.region, >mm.blocks);
+ u64 freed;
+ freed = __intel_memory_region_put_pages_buddy(obj->mm.region,
+ >mm.blocks);
obj->mm.dirty = false;
sg_free_table(pages);
kfree(pages);
+ drm_gem_object_uncharge_mem(>base, freed);
}
int
@@ -25,7 +28,7 @@ i915_gem_object_get_pages_buddy(struct drm_i915_gem_object
*obj)
const u64 max_segment = i915_sg_segment_size();
struct intel_memory_region *mem = obj->mm.region;
struct list_head *blocks = >mm.blocks;
- resource_size_t size = obj->base.size;
+ resource_size_t charged, size = obj->base.size;
resource_size_t prev_end;
struct i915_buddy_block *block;
unsigned int flags;
@@ -44,12 +47,22 @@ i915_gem_object_get_pages_buddy(struct drm_i915_gem_object
*obj)
}
flags = I915_ALLOC_MIN_PAGE_SIZE;
- if (obj->flags & I915_BO_ALLOC_CONTIGUOUS)
+ if (obj->flags & I915_BO_ALLOC_CONTIGUOUS) {
flags |= I915_ALLOC_CONTIGUOUS;
+ charged = roundup_pow_of_two(size);
+ } else {
+ charged = size;
+ }
+
+ ret = drm_gem_object_charge_mem(>base, charged);
+ if (ret) {
+ DRM_DEBUG("DRMCG: charge_mem failed for %lld\n", charged);
+ goto err_free_sg;
+ }
ret = __intel_memory_region_get_pages_buddy(mem, size, flags, blocks);
if (ret)
- goto err_free_sg;
+ goto err_uncharge;
GEM_BUG_ON(list_empty(blocks));
@@ -99,6 +112,8 @@ i915_gem_object_get_pages_buddy(struct drm_i915_gem_object
*obj)
return 0;
+err_uncharge:
+ drm_gem_object_uncharge_mem(>base, charged);
err_free_sg:
sg_free_table(st);
kfree(st);
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index 1bfcdd89b241..9b1edbf4361c 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -46,13 +46,18 @@ intel_memory_region_free_pages(struct intel_memory_region
*mem,
return size;
}
-void
+u64
__intel_memory_region_put_pages_buddy(struct intel_memory_region *mem,
struct list_head *blocks)
{
+ u64 freed;
+
mutex_lock(>mm_lock);
- mem->avail += intel_memory_region_free_pages(mem, blocks);
+ freed = intel_memory_region_free_pages(mem, blocks);
+ mem->avail += freed;
mutex_unlock(>mm_lock);
+
+ return freed;
}
void
@@ -241,6 +246,7 @@ void intel_memory_region_put(struct intel_memory_region
*mem)
int intel_memory_regions_hw_probe(struct drm_i915_private *i915)
{
+
[RFC PATCH 6/9] drmcg: Add memory.total file
Following control is introduced in order to display total memory that
exists for the DRM device. DRM drivers can advertise this value by
writing to drm_device.drmcg_props. This is needed in order to effectively
use the other memory controls.
Normally for system memory this is available to the user using procfs.
memory.total
Read-only value, displays total memory for a device, shown
only in root cgroup.
Signed-off-by: Brian Welty
---
Documentation/admin-guide/cgroup-v2.rst | 4
include/drm/drm_cgroup.h| 2 ++
kernel/cgroup/drm.c | 10 ++
3 files changed, 16 insertions(+)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index 405912710b3a..ccc25f03a898 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2189,6 +2189,10 @@ MEM controller. All memory amounts are in bytes.
DRM device memory. If memory usage reaches this limit,
subsequent device memory allocations will fail.
+ memory.total
+Read-only value, displays total memory for a device, shown only in
+root cgroup.
+
While some DRM devices may be capable to present multiple memory segments
to the user, the intent with above controls is to aggregate all user
allocatable backing store. Any support for multiple memory segments is
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index 8b4c4e798b11..9ba0e372 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -15,11 +15,13 @@ struct drmcg;
* of storing per device defaults
*/
struct drmcg_props {
+ u64 memory_total;
};
enum drmcg_res_type {
DRMCG_TYPE_MEM_CURRENT,
DRMCG_TYPE_MEM_MAX,
+ DRMCG_TYPE_MEM_TOTAL,
__DRMCG_TYPE_LAST,
};
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index bec41f343208..08e75eb67593 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -283,6 +283,10 @@ static int drmcg_seq_show_fn(int id, void *ptr, void *data)
else
seq_printf(sf, "%ld\n", ddr->memory.max * PAGE_SIZE);
break;
+ case DRMCG_TYPE_MEM_TOTAL:
+ seq_printf(sf, "%d:%d %llu\n", DRM_MAJOR, minor->index,
+ minor->dev->drmcg_props.memory_total);
+ break;
default:
seq_printf(sf, "%d:%d\n", DRM_MAJOR, minor->index);
break;
@@ -374,6 +378,12 @@ struct cftype files[] = {
.private = DRMCG_TYPE_MEM_MAX,
.flags = CFTYPE_NOT_ON_ROOT
},
+ {
+ .name = "memory.total",
+ .seq_show = drmcg_seq_show,
+ .private = DRMCG_TYPE_MEM_TOTAL,
+ .flags = CFTYPE_ONLY_ON_ROOT,
+ },
{ } /* terminate */
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 4/9] drmcg: Add skeleton seq_show and write for drmcg files
Add basic .seq_show and .write functions for use with DRM cgroup control
files. This is based on original work from Kenny Ho and extracted from
patches [1] and [2]. Has been simplified to remove having different file
types and functions for each.
[1] https://lists.freedesktop.org/archives/dri-devel/2020-February/254986.html
[2] https://lists.freedesktop.org/archives/dri-devel/2020-February/254990.html
Co-developed-by: Kenny Ho
Signed-off-by: Brian Welty
---
include/drm/drm_cgroup.h | 5 ++
kernel/cgroup/drm.c | 102 +++
2 files changed, 107 insertions(+)
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index 43caf1b6a0de..12526def9fbf 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: MIT
* Copyright 2019 Advanced Micro Devices, Inc.
+ * Copyright © 2021 Intel Corporation
*/
#ifndef __DRM_CGROUP_H__
#define __DRM_CGROUP_H__
@@ -15,6 +16,10 @@ struct drm_device;
struct drmcg_props {
};
+enum drmcg_res_type {
+ __DRMCG_TYPE_LAST,
+};
+
#ifdef CONFIG_CGROUP_DRM
void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 836929c27de8..aece11faa0bc 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -5,6 +5,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -12,6 +13,7 @@
#include
#include
#include
+#include
static struct drmcg *root_drmcg __read_mostly;
@@ -222,6 +224,106 @@ drmcg_css_alloc(struct cgroup_subsys_state *parent_css)
return >css;
}
+static int drmcg_apply_value(struct drmcg_device_resource *ddr,
+enum drmcg_res_type type, char *buf)
+{
+ int ret = 0;
+ unsigned long val;
+
+ switch (type) {
+ default:
+ break;
+ }
+
+ return ret;
+}
+
+static int drmcg_seq_show_fn(int id, void *ptr, void *data)
+{
+ struct drm_minor *minor = ptr;
+ struct seq_file *sf = data;
+ struct drmcg *drmcg = css_to_drmcg(seq_css(sf));
+ enum drmcg_res_type type = seq_cft(sf)->private;
+ struct drmcg_device_resource *ddr;
+
+ if (minor->type != DRM_MINOR_PRIMARY)
+ return 0;
+
+ ddr = drmcg->dev_resources[minor->index];
+ if (ddr == NULL)
+ return 0;
+
+ seq_printf(sf, "%d:%d ", DRM_MAJOR, minor->index);
+ switch (type) {
+ default:
+ seq_puts(sf, "\n");
+ break;
+ }
+
+ return 0;
+}
+
+static int drmcg_seq_show(struct seq_file *sf, void *v)
+{
+ return drm_minor_for_each(_seq_show_fn, sf);
+}
+
+static ssize_t drmcg_write(struct kernfs_open_file *of, char *buf,
+ size_t nbytes, loff_t off)
+{
+ struct drmcg *drmcg = css_to_drmcg(of_css(of));
+ enum drmcg_res_type type = of_cft(of)->private;
+ char *cft_name = of_cft(of)->name;
+ char *limits = strstrip(buf);
+ struct drmcg_device_resource *ddr;
+ struct drm_minor *dm;
+ char *line;
+ char sattr[256];
+ int minor, ret = 0;
+
+ while (!ret && limits != NULL) {
+ line = strsep(, "\n");
+
+ if (sscanf(line,
+ __stringify(DRM_MAJOR)":%u %255[^\t\n]",
+ , sattr) != 2) {
+ pr_err("drmcg: error parsing %s ", cft_name);
+ pr_cont_cgroup_name(drmcg->css.cgroup);
+ pr_cont("\n");
+
+ continue;
+ }
+
+ mutex_lock(_mutex);
+ if (acquire_drm_minor)
+ dm = acquire_drm_minor(minor);
+ else
+ dm = NULL;
+ mutex_unlock(_mutex);
+
+ if (IS_ERR_OR_NULL(dm)) {
+ pr_err("drmcg: invalid minor %d for %s ",
+ minor, cft_name);
+ pr_cont_cgroup_name(drmcg->css.cgroup);
+ pr_cont("\n");
+
+ continue;
+ }
+
+ mutex_lock(>dev->drmcg_mutex);
+ ddr = drmcg->dev_resources[minor];
+ ret = drmcg_apply_value(ddr, type, sattr);
+ mutex_unlock(>dev->drmcg_mutex);
+
+ mutex_lock(_mutex);
+ if (put_drm_dev)
+ put_drm_dev(dm->dev); /* release from acquire_drm_minor
*/
+ mutex_unlock(_mutex);
+ }
+
+ return ret ?: nbytes;
+}
+
struct cftype files[] = {
{ } /* terminate */
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 3/9] drm, cgroup: Initialize drmcg properties
From: Kenny Ho
drmcg initialization involves allocating a per cgroup, per device data
structure and setting the defaults. There are two entry points for
drmcg init:
1) When struct drmcg is created via css_alloc, initialization is done
for each device
2) When DRM devices are created after drmcgs are created, per
device drmcg data structure is allocated at the beginning of
DRM device creation such that drmcg can begin tracking usage
statistics
Entry point #2 usually applies to the root cgroup since it can be
created before DRM devices are available. The drmcg controller will go
through all existing drm cgroups and initialize them with the new device
accordingly.
Extending Kenny's original work, this has been simplified some and
the custom_init callback has been removed. (Brian)
Signed-off-by Kenny Ho
Signed-off-by: Brian Welty
---
drivers/gpu/drm/drm_drv.c | 3 ++
include/drm/drm_cgroup.h | 17 +++
include/drm/drm_device.h | 7 +++
include/linux/cgroup_drm.h | 13 ++
kernel/cgroup/drm.c| 95 +-
5 files changed, 134 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 3b940926d672..dac742445b38 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -570,6 +570,7 @@ static void drm_dev_init_release(struct drm_device *dev,
void *res)
/* Prevent use-after-free in drm_managed_release when debugging is
* enabled. Slightly awkward, but can't really be helped. */
dev->dev = NULL;
+ mutex_destroy(>drmcg_mutex);
mutex_destroy(>master_mutex);
mutex_destroy(>clientlist_mutex);
mutex_destroy(>filelist_mutex);
@@ -612,6 +613,7 @@ static int drm_dev_init(struct drm_device *dev,
mutex_init(>filelist_mutex);
mutex_init(>clientlist_mutex);
mutex_init(>master_mutex);
+ mutex_init(>drmcg_mutex);
ret = drmm_add_action(dev, drm_dev_init_release, NULL);
if (ret)
@@ -652,6 +654,7 @@ static int drm_dev_init(struct drm_device *dev,
if (ret)
goto err;
+ drmcg_device_early_init(dev);
return 0;
err:
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index 530c9a0b3238..43caf1b6a0de 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -4,6 +4,17 @@
#ifndef __DRM_CGROUP_H__
#define __DRM_CGROUP_H__
+#include
+
+struct drm_device;
+
+/**
+ * Per DRM device properties for DRM cgroup controller for the purpose
+ * of storing per device defaults
+ */
+struct drmcg_props {
+};
+
#ifdef CONFIG_CGROUP_DRM
void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
@@ -15,6 +26,8 @@ void drmcg_register_dev(struct drm_device *dev);
void drmcg_unregister_dev(struct drm_device *dev);
+void drmcg_device_early_init(struct drm_device *device);
+
#else
static inline void drmcg_bind(
@@ -35,5 +48,9 @@ static inline void drmcg_unregister_dev(struct drm_device
*dev)
{
}
+static inline void drmcg_device_early_init(struct drm_device *device)
+{
+}
+
#endif /* CONFIG_CGROUP_DRM */
#endif /* __DRM_CGROUP_H__ */
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index d647223e8390..1cdccc9a653c 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -8,6 +8,7 @@
#include
#include
+#include
struct drm_driver;
struct drm_minor;
@@ -318,6 +319,12 @@ struct drm_device {
*/
struct drm_fb_helper *fb_helper;
+/** \name DRM Cgroup */
+ /*@{ */
+ struct mutex drmcg_mutex;
+ struct drmcg_props drmcg_props;
+ /*@} */
+
/* Everything below here is for legacy driver, never use! */
/* private: */
#if IS_ENABLED(CONFIG_DRM_LEGACY)
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index 307bb75db248..50f055804400 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -12,11 +12,19 @@
#ifdef CONFIG_CGROUP_DRM
+/**
+ * Per DRM cgroup, per device resources (such as statistics and limits)
+ */
+struct drmcg_device_resource {
+ /* for per device stats */
+};
+
/**
* The DRM cgroup controller data structure.
*/
struct drmcg {
struct cgroup_subsys_state css;
+ struct drmcg_device_resource*dev_resources[MAX_DRM_DEV];
};
/**
@@ -40,6 +48,8 @@ static inline struct drmcg *css_to_drmcg(struct
cgroup_subsys_state *css)
*/
static inline struct drmcg *drmcg_get(struct task_struct *task)
{
+ if (!cgroup_subsys_enabled(gpu_cgrp_subsys))
+ return NULL;
return css_to_drmcg(task_get_css(task, gpu_cgrp_id));
}
@@ -70,6 +80,9 @@ static inline struct drmcg *drmcg_parent(struct drmcg *cg)
#else /* CONFIG_CGROUP_DRM */
+struct drmcg_device_resource {
+};
+
struct drmcg {
};
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 061bb9c458e4..836929c27de8 100644
--- a/kernel/cgroup/drm.c
+++
[RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup
This patch adds tracking of which cgroup to make charges against for a
given GEM object. We associate the current task's cgroup with GEM objects
as they are created. First user of this is for charging DRM cgroup for
device memory allocations. The intended behavior is for device drivers to
make the cgroup charging calls at the time that backing store is allocated
or deallocated for the object.
Exported functions are provided for charging memory allocations for a
GEM object to DRM cgroup. To aid in debugging, we store how many bytes
have been charged inside the GEM object. Add helpers for setting and
clearing the object's associated cgroup which will check that charges are
not being leaked.
For shared objects, this may make the charge against a cgroup that is
potentially not the same cgroup as the process using the memory. Based
on the memory cgroup's discussion of "memory ownership", this seems
acceptable [1].
[1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory Ownership"
Signed-off-by: Brian Welty
---
drivers/gpu/drm/drm_gem.c | 89 +++
include/drm/drm_gem.h | 17
2 files changed, 106 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index c2ce78c4edc3..a12da41eaafe 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -112,6 +113,89 @@ drm_gem_init(struct drm_device *dev)
return drmm_add_action(dev, drm_gem_init_release, NULL);
}
+/**
+ * drm_gem_object_set_cgroup - associate GEM object with a cgroup
+ * @obj: GEM object which is being associated with a cgroup
+ * @task: task associated with process control group to use
+ *
+ * This will acquire a reference on cgroup and use for charging GEM
+ * memory allocations.
+ * This helper could be extended in future to migrate charges to another
+ * cgroup, print warning if this usage occurs.
+ */
+void drm_gem_object_set_cgroup(struct drm_gem_object *obj,
+ struct task_struct *task)
+{
+ /* if object has existing cgroup, we migrate the charge... */
+ if (obj->drmcg) {
+ pr_warn("DRM: need to migrate cgroup charge of %lld\n",
+ atomic64_read(>drmcg_bytes_charged));
+ }
+ obj->drmcg = drmcg_get(task);
+}
+EXPORT_SYMBOL(drm_gem_object_set_cgroup);
+
+/**
+ * drm_gem_object_unset_cgroup - clear GEM object's associated cgroup
+ * @obj: GEM object
+ *
+ * This will release a reference on cgroup.
+ */
+void drm_gem_object_unset_cgroup(struct drm_gem_object *obj)
+{
+ WARN_ON(atomic64_read(>drmcg_bytes_charged));
+ drmcg_put(obj->drmcg);
+}
+EXPORT_SYMBOL(drm_gem_object_unset_cgroup);
+
+/**
+ * drm_gem_object_charge_mem - try charging size bytes to DRM cgroup
+ * @obj: GEM object which is being charged
+ * @size: number of bytes to charge
+ *
+ * Try to charge @size bytes to GEM object's associated DRM cgroup. This
+ * will fail if a successful charge would cause the current device memory
+ * usage to go above the cgroup's GPU memory maximum limit.
+ *
+ * Returns 0 on success. Otherwise, an error code is returned.
+ */
+int drm_gem_object_charge_mem(struct drm_gem_object *obj, u64 size)
+{
+ int ret;
+
+ ret = drm_cgroup_try_charge(obj->drmcg, obj->dev,
+ DRMCG_TYPE_MEM_CURRENT, size);
+ if (!ret)
+ atomic64_add(size, >drmcg_bytes_charged);
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_object_charge_mem);
+
+/**
+ * drm_gem_object_uncharge_mem - uncharge size bytes from DRM cgroup
+ * @obj: GEM object which is being uncharged
+ * @size: number of bytes to uncharge
+ *
+ * Uncharge @size bytes from the DRM cgroup associated with specified
+ * GEM object.
+ *
+ * Returns 0 on success. Otherwise, an error code is returned.
+ */
+void drm_gem_object_uncharge_mem(struct drm_gem_object *obj, u64 size)
+{
+ u64 charged = atomic64_read(>drmcg_bytes_charged);
+
+ if (WARN_ON(!charged))
+ return;
+ if (WARN_ON(size > charged))
+ size = charged;
+
+ atomic64_sub(size, >drmcg_bytes_charged);
+ drm_cgroup_uncharge(obj->drmcg, obj->dev, DRMCG_TYPE_MEM_CURRENT,
+ size);
+}
+EXPORT_SYMBOL(drm_gem_object_uncharge_mem);
+
/**
* drm_gem_object_init - initialize an allocated shmem-backed GEM object
* @dev: drm_device the object should be initialized for
@@ -156,6 +240,8 @@ void drm_gem_private_object_init(struct drm_device *dev,
obj->dev = dev;
obj->filp = NULL;
+ drm_gem_object_set_cgroup(obj, current);
+
kref_init(>refcount);
obj->handle_count = 0;
obj->size = size;
@@ -950,6 +1036,9 @@ drm_gem_object_release(struct drm_gem_object *obj)
dma_resv_fini(>_resv);
drm_gem_free_mmap_offset(obj);
+
+ /* Release reference on cgroup used
[RFC PATCH 0/9] cgroup support for GPU devices
We'd like to revisit the proposal of a GPU cgroup controller for managing GPU devices but with just a basic set of controls. This series is based on the prior patch series from Kenny Ho [1]. We take Kenny's base patches which implement the basic framework for the controller, but we propose an alternate set of control files. Here we've taken a subset of the controls proposed in earlier discussion on ML here [2]. This series proposes a set of device memory controls (gpu.memory.current, gpu.memory.max, and gpu.memory.total) and accounting of GPU time usage (gpu.sched.runtime). GPU time sharing controls are left as future work. These are implemented within the GPU controller along with integration/usage of the device memory controls by the i915 device driver. As an accelerator or GPU device is similar in many respects to a CPU with (or without) attached system memory, the basic principle here is try to copy the semantics of existing controls from other controllers when possible and where these controls serve the same underlying purpose. For example, the memory.max and memory.current controls are based on same controls from MEMCG controller. Following with the implementation used by the existing RDMA controller, here we introduce a general purpose drm_cgroup_try_charge and uncharge pair of exported functions. These functions are to be used for charging and uncharging all current and future DRM resource controls. Patches 1 - 4 are part original work and part refactoring of the prior work from Kenny Ho from his series for GPU / DRM controller v2 [1]. Patches 5 - 7 introduce new controls to the GPU / DRM controller for device memory accounting and GPU time tracking. Patch 8 introduces DRM support for associating GEM objects with a cgroup. Patch 9 implements i915 changes to use cgroups for device memory charging and enforcing device memory allocation limit. [1] https://lists.freedesktop.org/archives/dri-devel/2020-February/257052.html [2] https://lists.freedesktop.org/archives/dri-devel/2019-November/242599.html Brian Welty (6): drmcg: Add skeleton seq_show and write for drmcg files drmcg: Add support for device memory accounting via page counter drmcg: Add memory.total file drmcg: Add initial support for tracking gpu time usage drm/gem: Associate GEM objects with drm cgroup drm/i915: Use memory cgroup for enforcing device memory limit Kenny Ho (3): cgroup: Introduce cgroup for drm subsystem drm, cgroup: Bind drm and cgroup subsystem drm, cgroup: Initialize drmcg properties Documentation/admin-guide/cgroup-v2.rst| 58 ++- Documentation/cgroup-v1/drm.rst| 1 + drivers/gpu/drm/drm_drv.c | 11 + drivers/gpu/drm/drm_gem.c | 89 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 + drivers/gpu/drm/i915/gem/i915_gem_region.c | 23 +- drivers/gpu/drm/i915/intel_memory_region.c | 13 +- drivers/gpu/drm/i915/intel_memory_region.h | 2 +- include/drm/drm_cgroup.h | 85 include/drm/drm_device.h | 7 + include/drm/drm_gem.h | 17 + include/linux/cgroup_drm.h | 113 + include/linux/cgroup_subsys.h | 4 + init/Kconfig | 5 + kernel/cgroup/Makefile | 1 + kernel/cgroup/drm.c| 533 + 16 files changed, 954 insertions(+), 9 deletions(-) create mode 100644 Documentation/cgroup-v1/drm.rst create mode 100644 include/drm/drm_cgroup.h create mode 100644 include/linux/cgroup_drm.h create mode 100644 kernel/cgroup/drm.c -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/9] cgroup: Introduce cgroup for drm subsystem
From: Kenny Ho
With the increased importance of machine learning, data science and
other cloud-based applications, GPUs are already in production use in
data centers today. Existing GPU resource management is very coarse
grain, however, as sysadmins are only able to distribute workload on a
per-GPU basis. An alternative is to use GPU virtualization (with or
without SRIOV) but it generally acts on the entire GPU instead of the
specific resources in a GPU. With a drm cgroup controller, we can
enable alternate, fine-grain, sub-GPU resource management (in addition
to what may be available via GPU virtualization.)
Signed-off-by: Kenny Ho
---
Documentation/admin-guide/cgroup-v2.rst | 18 -
Documentation/cgroup-v1/drm.rst | 1 +
include/linux/cgroup_drm.h | 92 +
include/linux/cgroup_subsys.h | 4 ++
init/Kconfig| 5 ++
kernel/cgroup/Makefile | 1 +
kernel/cgroup/drm.c | 42 +++
7 files changed, 161 insertions(+), 2 deletions(-)
create mode 100644 Documentation/cgroup-v1/drm.rst
create mode 100644 include/linux/cgroup_drm.h
create mode 100644 kernel/cgroup/drm.c
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index 63521cd36ce5..b099e1d71098 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -63,8 +63,10 @@ v1 is available under
:ref:`Documentation/admin-guide/cgroup-v1/index.rst
+
+#ifdef CONFIG_CGROUP_DRM
+
+/**
+ * The DRM cgroup controller data structure.
+ */
+struct drmcg {
+ struct cgroup_subsys_state css;
+};
+
+/**
+ * css_to_drmcg - get the corresponding drmcg ref from a cgroup_subsys_state
+ * @css: the target cgroup_subsys_state
+ *
+ * Return: DRM cgroup that contains the @css
+ */
+static inline struct drmcg *css_to_drmcg(struct cgroup_subsys_state *css)
+{
+ return css ? container_of(css, struct drmcg, css) : NULL;
+}
+
+/**
+ * drmcg_get - get the drmcg reference that a task belongs to
+ * @task: the target task
+ *
+ * This increase the reference count of the css that the @task belongs to
+ *
+ * Return: reference to the DRM cgroup the task belongs to
+ */
+static inline struct drmcg *drmcg_get(struct task_struct *task)
+{
+ return css_to_drmcg(task_get_css(task, gpu_cgrp_id));
+}
+
+/**
+ * drmcg_put - put a drmcg reference
+ * @drmcg: the target drmcg
+ *
+ * Put a reference obtained via drmcg_get
+ */
+static inline void drmcg_put(struct drmcg *drmcg)
+{
+ if (drmcg)
+ css_put(>css);
+}
+
+/**
+ * drmcg_parent - find the parent of a drm cgroup
+ * @cg: the target drmcg
+ *
+ * This does not increase the reference count of the parent cgroup
+ *
+ * Return: parent DRM cgroup of @cg
+ */
+static inline struct drmcg *drmcg_parent(struct drmcg *cg)
+{
+ return css_to_drmcg(cg->css.parent);
+}
+
+#else /* CONFIG_CGROUP_DRM */
+
+struct drmcg {
+};
+
+static inline struct drmcg *css_to_drmcg(struct cgroup_subsys_state *css)
+{
+ return NULL;
+}
+
+static inline struct drmcg *drmcg_get(struct task_struct *task)
+{
+ return NULL;
+}
+
+static inline void drmcg_put(struct drmcg *drmcg)
+{
+}
+
+static inline struct drmcg *drmcg_parent(struct drmcg *cg)
+{
+ return NULL;
+}
+
+#endif /* CONFIG_CGROUP_DRM */
+#endif /* _CGROUP_DRM_H */
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index acb77dcff3b4..f4e627942115 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -61,6 +61,10 @@ SUBSYS(pids)
SUBSYS(rdma)
#endif
+#if IS_ENABLED(CONFIG_CGROUP_DRM)
+SUBSYS(gpu)
+#endif
+
/*
* The following subsystems are not supported on the default hierarchy.
*/
diff --git a/init/Kconfig b/init/Kconfig
index b77c60f8b963..bee29f51e380 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1027,6 +1027,11 @@ config CGROUP_RDMA
Attaching processes with active RDMA resources to the cgroup
hierarchy is allowed even if can cross the hierarchy's limit.
+config CGROUP_DRM
+ bool "DRM controller (EXPERIMENTAL)"
+ help
+ Provides accounting and enforcement of resources in the DRM subsystem.
+
config CGROUP_FREEZER
bool "Freezer controller"
help
diff --git a/kernel/cgroup/Makefile b/kernel/cgroup/Makefile
index 5d7a76bfbbb7..31f186f58121 100644
--- a/kernel/cgroup/Makefile
+++ b/kernel/cgroup/Makefile
@@ -4,5 +4,6 @@ obj-y := cgroup.o rstat.o namespace.o cgroup-v1.o freezer.o
obj-$(CONFIG_CGROUP_FREEZER) += legacy_freezer.o
obj-$(CONFIG_CGROUP_PIDS) += pids.o
obj-$(CONFIG_CGROUP_RDMA) += rdma.o
+obj-$(CONFIG_CGROUP_DRM) += drm.o
obj-$(CONFIG_CPUSETS) += cpuset.o
obj-$(CONFIG_CGROUP_DEBUG) += debug.o
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
new file mode 100644
index ..5e38a8230922
--- /dev/null
+++ b/kernel/cgroup/drm.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: MIT
+//
[RFC PATCH 5/9] drmcg: Add support for device memory accounting via page counter
Here we introduce a general purpose drm_cgroup_try_charge and uncharge
pair of functions. This is modelled after the existing RDMA cgroup controller,
and the idea is for these functions to be used for charging/uncharging all
current and future DRM resource controls.
Two new controls are added in order to allow DRM device drivers to expose
memories attached to the device for purposes of memory accounting and
enforcing allocation limit.
Following controls are introduced and are intended to provide equivalent
behavior and functionality where possible as the MEM controller:
memory.current
Read-only value, displays current device memory usage for all DRM
device memory in terms of allocated physical backing store.
memory.max
Read-write value, displays the maximum memory usage limit of device
memory. If memory usage reaches this limit, then subsequent memory
allocations will fail.
The expectation is that the DRM device driver simply lets allocations fail
when memory.max is reached. Future work might be to introduce the device
memory concept of memory.high or memory.low controls, such that DRM device
might be able to invoke memory eviction when these lower threshold are hit.
With provided charging functions, support for memory accounting/charging
is functional. The intent is for DRM device drivers to charge against
memory.current as device memory is physically allocated. Implementation is
simplified by making use of page counters underneath. Nested cgroups will
correctly maintain the parent for the memory page counters, such that
hierarchial charging to parent's memory.current is supported.
Note, this is only for tracking of allocations from device-backed memory.
Memory charging for objects that are backed by system memory is already
handled by the mm subsystem and existing memory accounting controls.
Signed-off-by: Brian Welty
---
Documentation/admin-guide/cgroup-v2.rst | 29 -
include/drm/drm_cgroup.h| 20
include/linux/cgroup_drm.h | 4 +-
kernel/cgroup/drm.c | 145 +++-
4 files changed, 191 insertions(+), 7 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index b099e1d71098..405912710b3a 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2171,8 +2171,35 @@ of GPU-related resources.
GPU Interface Files
-TODO
+GPU controller supports usage of multiple DRM devices within a cgroup.
+As such, for all interface files, output is keyed by device major:minor
+and is not ordered.
+The first set of control files are for regulating the accounting and
+allocation of memories attached to DRM devices. The controls are intended
+to provide equivalent behavior and functionality where possible as the
+MEM controller. All memory amounts are in bytes.
+
+ memory.current
+Read-only value, displays current device memory usage for the DRM
+device memory in terms of allocated physical backing store.
+
+ memory.max
+Read-write value, displays the maximum memory usage limit for the
+DRM device memory. If memory usage reaches this limit,
+subsequent device memory allocations will fail.
+
+While some DRM devices may be capable to present multiple memory segments
+to the user, the intent with above controls is to aggregate all user
+allocatable backing store. Any support for multiple memory segments is
+left as future work.
+
+The expectation is that the DRM device driver simply lets allocations fail
+when memory.max is reached. Future work might be to introduce the device
+memory concept of memory.high or memory.low controls. When these lower
+thresholds are hit, this would then allow the DRM device driver to invoke
+some equivalent to OOM-killer or forced memory eviction for the device
+backed memory in order to attempt to free additional space.
Misc
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index 12526def9fbf..8b4c4e798b11 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -8,6 +8,7 @@
#include
struct drm_device;
+struct drmcg;
/**
* Per DRM device properties for DRM cgroup controller for the purpose
@@ -17,6 +18,8 @@ struct drmcg_props {
};
enum drmcg_res_type {
+ DRMCG_TYPE_MEM_CURRENT,
+ DRMCG_TYPE_MEM_MAX,
__DRMCG_TYPE_LAST,
};
@@ -33,6 +36,11 @@ void drmcg_unregister_dev(struct drm_device *dev);
void drmcg_device_early_init(struct drm_device *device);
+int drm_cgroup_try_charge(struct drmcg *drmcg, struct drm_device *dev,
+ enum drmcg_res_type type, u64 usage);
+void drm_cgroup_uncharge(struct drmcg *drmcg, struct drm_device *dev,
+enum drmcg_res_type type, u64 usage);
+
#else
static inline void drmcg_bind(
@@ -57,5 +65,17 @@ static inline void
[RFC PATCH 2/9] drm, cgroup: Bind drm and cgroup subsystem
From: Kenny Ho
Since the drm subsystem can be compiled as a module and drm devices can
be added and removed during run time, add several functions to bind the
drm subsystem as well as drm devices with drmcg.
Two pairs of functions:
drmcg_bind/drmcg_unbind - used to bind/unbind the drm subsystem to the
cgroup subsystem as the drm core initialize/exit.
drmcg_register_dev/drmcg_unregister_dev - used to register/unregister
drm devices to the cgroup subsystem as the devices are presented/removed
from userspace.
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/drm_drv.c | 8 +++
include/drm/drm_cgroup.h | 39 +++
include/linux/cgroup_drm.h | 4 ++
kernel/cgroup/drm.c| 131 +
4 files changed, 182 insertions(+)
create mode 100644 include/drm/drm_cgroup.h
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 20d22e41d7ce..3b940926d672 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -893,6 +894,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
+ drmcg_register_dev(dev);
+
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
driver->name, driver->major, driver->minor,
driver->patchlevel, driver->date,
@@ -928,6 +931,8 @@ EXPORT_SYMBOL(drm_dev_register);
*/
void drm_dev_unregister(struct drm_device *dev)
{
+ drmcg_unregister_dev(dev);
+
if (drm_core_check_feature(dev, DRIVER_LEGACY))
drm_lastclose(dev);
@@ -1030,6 +1035,7 @@ static const struct file_operations drm_stub_fops = {
static void drm_core_exit(void)
{
+ drmcg_unbind();
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
@@ -1056,6 +1062,8 @@ static int __init drm_core_init(void)
if (ret < 0)
goto error;
+ drmcg_bind(_minor_acquire, _dev_put);
+
drm_core_init_complete = true;
DRM_DEBUG("Initialized\n");
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
new file mode 100644
index ..530c9a0b3238
--- /dev/null
+++ b/include/drm/drm_cgroup.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2019 Advanced Micro Devices, Inc.
+ */
+#ifndef __DRM_CGROUP_H__
+#define __DRM_CGROUP_H__
+
+#ifdef CONFIG_CGROUP_DRM
+
+void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
+ void (*put_ddev)(struct drm_device *dev));
+
+void drmcg_unbind(void);
+
+void drmcg_register_dev(struct drm_device *dev);
+
+void drmcg_unregister_dev(struct drm_device *dev);
+
+#else
+
+static inline void drmcg_bind(
+ struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
+ void (*put_ddev)(struct drm_device *dev))
+{
+}
+
+static inline void drmcg_unbind(void)
+{
+}
+
+static inline void drmcg_register_dev(struct drm_device *dev)
+{
+}
+
+static inline void drmcg_unregister_dev(struct drm_device *dev)
+{
+}
+
+#endif /* CONFIG_CGROUP_DRM */
+#endif /* __DRM_CGROUP_H__ */
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index 345af54a5d41..307bb75db248 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -5,6 +5,10 @@
#define _CGROUP_DRM_H
#include
+#include
+
+/* limit defined per the way drm_minor_alloc operates */
+#define MAX_DRM_DEV (64 * DRM_MINOR_RENDER)
#ifdef CONFIG_CGROUP_DRM
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 5e38a8230922..061bb9c458e4 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -1,11 +1,142 @@
// SPDX-License-Identifier: MIT
// Copyright 2019 Advanced Micro Devices, Inc.
+#include
+#include
#include
#include
#include
+#include
+#include
+#include
static struct drmcg *root_drmcg __read_mostly;
+/* global mutex for drmcg across all devices */
+static DEFINE_MUTEX(drmcg_mutex);
+
+static DECLARE_BITMAP(known_devs, MAX_DRM_DEV);
+
+static struct drm_minor (*(*acquire_drm_minor)(unsigned int minor_id));
+
+static void (*put_drm_dev)(struct drm_device *dev);
+
+/**
+ * drmcg_bind - Bind DRM subsystem to cgroup subsystem
+ * @acq_dm: function pointer to the drm_minor_acquire function
+ * @put_ddev: function pointer to the drm_dev_put function
+ *
+ * This function binds some functions from the DRM subsystem and make
+ * them available to the drmcg subsystem.
+ *
+ * drmcg_unbind does the opposite of this function
+ */
+void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
+ void (*put_ddev)(struct drm_device *dev))
+{
+ mutex_lock(_mutex);
+ acquire_drm_minor = acq_dm;
+ put_drm_dev = put_ddev;
+ mutex_unlock(_mutex);
+}
+EXPORT_SYMBOL(drmcg_bind);
+
+/**
+ *
[RFC PATCH 7/9] drmcg: Add initial support for tracking gpu time usage
Single control below is added to DRM cgroup controller in order to track
user execution time for GPU devices. It is up to device drivers to
charge execution time to the cgroup via drm_cgroup_try_charge().
sched.runtime
Read-only value, displays current user execution time for each DRM
device. The expectation is that this is incremented by DRM device
driver's scheduler upon user context completion or context switch.
Units of time are in microseconds for consistency with cpu.stats.
Signed-off-by: Brian Welty
---
Documentation/admin-guide/cgroup-v2.rst | 9 +
include/drm/drm_cgroup.h| 2 ++
include/linux/cgroup_drm.h | 2 ++
kernel/cgroup/drm.c | 20
4 files changed, 33 insertions(+)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index ccc25f03a898..f1d0f333a49e 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2205,6 +2205,15 @@ thresholds are hit, this would then allow the DRM device
driver to invoke
some equivalent to OOM-killer or forced memory eviction for the device
backed memory in order to attempt to free additional space.
+The below set of control files are for time accounting of DRM devices. Units
+of time are in microseconds.
+
+ sched.runtime
+Read-only value, displays current user execution time for each DRM
+device. The expectation is that this is incremented by DRM device
+driver's scheduler upon user context completion or context switch.
+
+
Misc
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index 9ba0e372..315dab8a93b8 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -22,6 +22,7 @@ enum drmcg_res_type {
DRMCG_TYPE_MEM_CURRENT,
DRMCG_TYPE_MEM_MAX,
DRMCG_TYPE_MEM_TOTAL,
+ DRMCG_TYPE_SCHED_RUNTIME,
__DRMCG_TYPE_LAST,
};
@@ -79,5 +80,6 @@ void drm_cgroup_uncharge(struct drmcg *drmcg,struct
drm_device *dev,
enum drmcg_res_type type, u64 usage)
{
}
+
#endif /* CONFIG_CGROUP_DRM */
#endif /* __DRM_CGROUP_H__ */
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index 3570636473cf..0fafa663321e 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -19,6 +19,8 @@
*/
struct drmcg_device_resource {
struct page_counter memory;
+ seqlock_t sched_lock;
+ u64 exec_runtime;
};
/**
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 08e75eb67593..64e9d0dbe8c8 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -81,6 +81,7 @@ static inline int init_drmcg_single(struct drmcg *drmcg,
struct drm_device *dev)
/* set defaults here */
page_counter_init(>memory,
parent_ddr ? _ddr->memory : NULL);
+ seqlock_init(>sched_lock);
drmcg->dev_resources[minor] = ddr;
return 0;
@@ -287,6 +288,10 @@ static int drmcg_seq_show_fn(int id, void *ptr, void *data)
seq_printf(sf, "%d:%d %llu\n", DRM_MAJOR, minor->index,
minor->dev->drmcg_props.memory_total);
break;
+ case DRMCG_TYPE_SCHED_RUNTIME:
+ seq_printf(sf, "%d:%d %llu\n", DRM_MAJOR, minor->index,
+ ktime_to_us(ddr->exec_runtime));
+ break;
default:
seq_printf(sf, "%d:%d\n", DRM_MAJOR, minor->index);
break;
@@ -384,6 +389,12 @@ struct cftype files[] = {
.private = DRMCG_TYPE_MEM_TOTAL,
.flags = CFTYPE_ONLY_ON_ROOT,
},
+ {
+ .name = "sched.runtime",
+ .seq_show = drmcg_seq_show,
+ .private = DRMCG_TYPE_SCHED_RUNTIME,
+ .flags = CFTYPE_NOT_ON_ROOT,
+ },
{ } /* terminate */
};
@@ -440,6 +451,10 @@ EXPORT_SYMBOL(drmcg_device_early_init);
* choose to enact some form of memory reclaim, but the exact behavior is left
* to the DRM device driver to define.
*
+ * For @res type of DRMCG_TYPE_SCHED_RUNTIME:
+ * For GPU time accounting, add @usage amount of GPU time to @drmcg for
+ * the given device.
+ *
* Returns 0 on success. Otherwise, an error code is returned.
*/
int drm_cgroup_try_charge(struct drmcg *drmcg, struct drm_device *dev,
@@ -466,6 +481,11 @@ int drm_cgroup_try_charge(struct drmcg *drmcg, struct
drm_device *dev,
err = 0;
}
break;
+ case DRMCG_TYPE_SCHED_RUNTIME:
+ write_seqlock(>sched_lock);
+ res->exec_runtime = ktime_add(res->exec_runtime, usage);
+ write_sequnlock(>sched_lock);
+ break;
default:
err = -EINVAL;
break;
--
2.20.1
___
dri-devel mailing list
[PATCH] backlight: ktd253: Bring up in a known state
The KTD253 backlight might already be on when the driver
is probed: then we don't really know what the current
ratio is and all light intensity settings will be off
relative to what it was at boot.
To fix this, bring up the backlight OFF then move it to
the default backlight from there so we know the state.
Signed-off-by: Linus Walleij
---
drivers/video/backlight/ktd253-backlight.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/backlight/ktd253-backlight.c
b/drivers/video/backlight/ktd253-backlight.c
index e3fee3f1f582..d7b287cffd5c 100644
--- a/drivers/video/backlight/ktd253-backlight.c
+++ b/drivers/video/backlight/ktd253-backlight.c
@@ -137,15 +137,7 @@ static int ktd253_backlight_probe(struct platform_device
*pdev)
brightness = max_brightness;
}
- if (brightness)
- /* This will be the default ratio when the KTD253 is enabled */
- ktd253->ratio = KTD253_MAX_RATIO;
- else
- ktd253->ratio = 0;
-
- ktd253->gpiod = devm_gpiod_get(dev, "enable",
- brightness ? GPIOD_OUT_HIGH :
- GPIOD_OUT_LOW);
+ ktd253->gpiod = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
if (IS_ERR(ktd253->gpiod)) {
ret = PTR_ERR(ktd253->gpiod);
if (ret != -EPROBE_DEFER)
@@ -153,6 +145,8 @@ static int ktd253_backlight_probe(struct platform_device
*pdev)
return ret;
}
gpiod_set_consumer_name(ktd253->gpiod, dev_name(dev));
+ /* Bring backlight to a known off state */
+ msleep(KTD253_T_OFF_MS);
bl = devm_backlight_device_register(dev, dev_name(dev), dev, ktd253,
_backlight_ops, NULL);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: dsi: fix unreachable code in dsi_vc_send_short()
Hi,
On Tue, Jan 26, 2021 at 05:55:11AM -0800, menglong8.d...@gmail.com wrote:
> From: Menglong Dong
>
> The 'r' in dsi_vc_send_short() is of type 'unsigned int', so the
> 'r < 0' can't be true.
>
> Fix this by introducing a 'err' insteaded.
>
> Fixes: 1ed6253856cb
> ("drm/omap: dsi: switch dsi_vc_send_long/short to mipi_dsi_msg")
Documentation/process/submitting-patches.rst:
If your patch fixes a bug in a specific commit, e.g. you found an
issue using ``git bisect``, please use the 'Fixes:' tag with the
first 12 characters of the SHA-1 ID, and the one line summary. Do
not split the tag across multiple lines, tags are exempt from the
"wrap at 75 columns" rule in order to simplify parsing scripts.
Otherwise:
Reviewed-by: Sebastian Reichel
-- Sebastian
> Signed-off-by: Menglong Dong
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 8e11612f5fe1..febcc87ddfe1 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -2149,11 +2149,12 @@ static int dsi_vc_send_short(struct dsi_data *dsi,
> int vc,
>const struct mipi_dsi_msg *msg)
> {
> struct mipi_dsi_packet pkt;
> + int err;
> u32 r;
>
> - r = mipi_dsi_create_packet(, msg);
> - if (r < 0)
> - return r;
> + err = mipi_dsi_create_packet(, msg);
> + if (err)
> + return err;
>
> WARN_ON(!dsi_bus_is_locked(dsi));
>
> --
> 2.25.1
>
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1
On Tue, Jan 26, 2021 at 8:33 PM Hans de Goede wrote: > On 1/26/21 6:14 PM, Andy Shevchenko wrote: > > On Tue, Jan 26, 2021 at 6:55 PM Patrik Jakobsson > > wrote: > >> On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko > >> wrote: > >>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > >>> wrote: > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > wrote: > > > > Hi guys, > > > > This is first part of Intel MID outdated platforms removal. It's > > collected into > > immutable branch with a given tag, please pull to yours subsystems. > > Hi Andy, > Do you plan on eventually removing X86_INTEL_MID completely? If so, > then I should probably start looking at removing the corresponding > parts in GMA500. > >>> > >>> Nope. It is related to only Medfield / Clovertrail platforms. > >>> > >>> There are other (MID) platforms that may / might utilize this driver > >>> in the future. > >> > >> Right, there's still Oaktrail / Moorestown with hardware in the wild. > > > > Actually Moorestown had to be removed a few years ago (kernel won't > > boot on them anyway from that date when Alan removed support under > > arch/x86 for it). > > > > I'm talking about Merrifield and Moorefield that can utilize it and > > also some other platforms that are not SFI based (Cedar something... > > IIRC). > > Yes at least there are some 64 bit capable SoCs with GMA500 which were > used in NAS like devices. These NAS-es actually have a VGA output > (and maybe also DVI?) which is attached to the GMA500. Since you are talking about 64-bit, definitely they are *not* Moorestown, Medfield, Clovertrail since the mentioned never were 64-bit. But it would be nice to see the CPU model number to be sure. > I know people are running Fedora on these, so we should at least keep > these supported. Is it possible to gather the CPU model number from them? (Or at least the exact device/box name) -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] fbtft: add tearing signal detect
Hi Carlis,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v5.11-rc5 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Carlis/fbtft-add-tearing-signal-detect/20210125-210428
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
ec52736c35f29ed96a45e641dd6aad61bc9cb6f7
config: x86_64-randconfig-r034-20210126 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
925ae8c790c7e354f12ec14a6cac6aa49fc75b29)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/480797ed48b87555bb31a8a07b600959b53fe643
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Carlis/fbtft-add-tearing-signal-detect/20210125-210428
git checkout 480797ed48b87555bb31a8a07b600959b53fe643
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/staging/fbtft/fb_st7789v.c:216:5: warning: no previous prototype for
>> function 'st7789v_write_vmem16_bus8' [-Wmissing-prototypes]
int st7789v_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t
len)
^
drivers/staging/fbtft/fb_st7789v.c:216:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
int st7789v_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t
len)
^
static
1 warning generated.
vim +/st7789v_write_vmem16_bus8 +216 drivers/staging/fbtft/fb_st7789v.c
208
209
/*
210 *
211 * int (*write_vmem)(struct fbtft_par *par);
212 *
213
*/
214
215 /* 16 bit pixel over 8-bit databus */
> 216 int st7789v_write_vmem16_bus8(struct fbtft_par *par, size_t offset,
> size_t len)
217 {
218 u16 *vmem16;
219 __be16 *txbuf16 = par->txbuf.buf;
220 size_t remain;
221 size_t to_copy;
222 size_t tx_array_size;
223 int i;
224 int rc, ret = 0;
225 size_t startbyte_size = 0;
226
227 fbtft_par_dbg(DEBUG_WRITE_VMEM, par, "st7789v ---%s(offset=%zu,
len=%zu)\n",
228__func__, offset, len);
229
230 remain = len / 2;
231 vmem16 = (u16 *)(par->info->screen_buffer + offset);
232
233 if (par->gpio.dc)
234 gpiod_set_value(par->gpio.dc, 1);
235
236 /* non buffered write */
237 if (!par->txbuf.buf)
238 return par->fbtftops.write(par, vmem16, len);
239
240 /* buffered write */
241 tx_array_size = par->txbuf.len / 2;
242
243 if (par->startbyte) {
244 txbuf16 = par->txbuf.buf + 1;
245 tx_array_size -= 2;
246 *(u8 *)(par->txbuf.buf) = par->startbyte | 0x2;
247 startbyte_size = 1;
248 }
249
250 while (remain) {
251 to_copy = min(tx_array_size, remain);
252 dev_dbg(par->info->device, "to_copy=%zu,
remain=%zu\n",
253 to_copy, remain - to_copy);
254
255 for (i = 0; i < to_copy; i++)
256 txbuf16[i] = cpu_to_be16(vmem16[i]);
257
258 vmem16 = vmem16 + to_copy;
259 if (par->gpio.te) {
260 enable_spi_panel_te_irq(par, true);
261 reinit_completion(_panel_te);
262 rc = wait_for_completion_timeout(_panel_te,
263
msecs_to_jiffies(SPI_PANEL_TE_TIMEOUT));
264 if (rc == 0)
265 pr_err("wait panel TE time out\n");
266 }
267 ret = par->fbtftops.write(par, par->txbuf.buf,
268
Re: [PATCH v3 4/5] amba: Make the remove callback return void
On Tue, Jan 26, 2021 at 06:56:52PM +0100, Uwe Kleine-König wrote:
> I'm surprised to see that the remove callback introduced in 2952ecf5df33
> ("coresight: etm4x: Refactor probing routine") has an __exit annotation.
In general, remove callbacks should not have an __exit annotation.
__exit _can_ be discarded at link time for built-in stuff.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] kbuild: use always-y instead of extra-y
On Thu, Jan 21, 2021 at 6:39 AM Rob Herring wrote:
>
> On Wed, Jan 20, 2021 at 03:23:51PM +0900, Masahiro Yamada wrote:
> > As commit d0e628cd817f ("kbuild: doc: clarify the difference between
> > extra-y and always-y") explained, extra-y should be used for listing
> > the prerequsites of vmlinux. always-y is a better fix here.
>
> prerequisites
Thanks.
I fixed it up, and applied to linux-kbuild.
> Glad to see this clarified. I think just tried both and picked one.
>
> Reviewed-by: Rob Herring
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > Documentation/devicetree/bindings/Makefile | 8
> > drivers/gpu/drm/i915/Makefile | 2 +-
> > scripts/Makefile.lib | 10 +-
> > scripts/gdb/linux/Makefile | 2 +-
> > 4 files changed, 11 insertions(+), 11 deletions(-)
--
Best Regards
Masahiro Yamada
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1
Hi, On 1/26/21 6:14 PM, Andy Shevchenko wrote: > On Tue, Jan 26, 2021 at 6:55 PM Patrik Jakobsson > wrote: >> On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko >> wrote: >>> >>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson >>> wrote: On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko wrote: > > Hi guys, > > This is first part of Intel MID outdated platforms removal. It's > collected into > immutable branch with a given tag, please pull to yours subsystems. Hi Andy, Do you plan on eventually removing X86_INTEL_MID completely? If so, then I should probably start looking at removing the corresponding parts in GMA500. >>> >>> Nope. It is related to only Medfield / Clovertrail platforms. >>> >>> There are other (MID) platforms that may / might utilize this driver >>> in the future. >> >> Right, there's still Oaktrail / Moorestown with hardware in the wild. > > Actually Moorestown had to be removed a few years ago (kernel won't > boot on them anyway from that date when Alan removed support under > arch/x86 for it). > > I'm talking about Merrifield and Moorefield that can utilize it and > also some other platforms that are not SFI based (Cedar something... > IIRC). Yes at least there are some 64 bit capable SoCs with GMA500 which were used in NAS like devices. These NAS-es actually have a VGA output (and maybe also DVI?) which is attached to the GMA500. I know people are running Fedora on these, so we should at least keep these supported. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/2] mm: simplify free_highmem_page() and free_reserved_page()
adjust_managed_page_count() as called by free_reserved_page() properly
handles pages in a highmem zone, so we can reuse it for
free_highmem_page().
We can now get rid of totalhigh_pages_inc() and simplify
free_reserved_page().
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: "Peter Zijlstra (Intel)"
Cc: Mike Rapoport
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: Wei Yang
Signed-off-by: David Hildenbrand
---
include/linux/highmem-internal.h | 5 -
include/linux/mm.h | 16 ++--
mm/page_alloc.c | 11 ---
3 files changed, 2 insertions(+), 30 deletions(-)
diff --git a/include/linux/highmem-internal.h b/include/linux/highmem-internal.h
index 1bbe96dc8be6..7902c7d8b55f 100644
--- a/include/linux/highmem-internal.h
+++ b/include/linux/highmem-internal.h
@@ -127,11 +127,6 @@ static inline unsigned long totalhigh_pages(void)
return (unsigned long)atomic_long_read(&_totalhigh_pages);
}
-static inline void totalhigh_pages_inc(void)
-{
- atomic_long_inc(&_totalhigh_pages);
-}
-
static inline void totalhigh_pages_add(long count)
{
atomic_long_add(count, &_totalhigh_pages);
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a5d618d08506..494c69433a34 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2303,32 +2303,20 @@ extern void free_initmem(void);
extern unsigned long free_reserved_area(void *start, void *end,
int poison, const char *s);
-#ifdef CONFIG_HIGHMEM
-/*
- * Free a highmem page into the buddy system, adjusting totalhigh_pages
- * and totalram_pages.
- */
-extern void free_highmem_page(struct page *page);
-#endif
-
extern void adjust_managed_page_count(struct page *page, long count);
extern void mem_init_print_info(const char *str);
extern void reserve_bootmem_region(phys_addr_t start, phys_addr_t end);
/* Free the reserved page into the buddy system, so it gets managed. */
-static inline void __free_reserved_page(struct page *page)
+static inline void free_reserved_page(struct page *page)
{
ClearPageReserved(page);
init_page_count(page);
__free_page(page);
-}
-
-static inline void free_reserved_page(struct page *page)
-{
- __free_reserved_page(page);
adjust_managed_page_count(page, 1);
}
+#define free_highmem_page(page) free_reserved_page(page)
static inline void mark_page_reserved(struct page *page)
{
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b031a5ae0bd5..b2e42f10d4d4 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7711,17 +7711,6 @@ unsigned long free_reserved_area(void *start, void *end,
int poison, const char
return pages;
}
-#ifdef CONFIG_HIGHMEM
-void free_highmem_page(struct page *page)
-{
- __free_reserved_page(page);
- totalram_pages_inc();
- atomic_long_inc(_zone(page)->managed_pages);
- totalhigh_pages_inc();
-}
-#endif
-
-
void __init mem_init_print_info(const char *str)
{
unsigned long physpages, codesize, datasize, rosize, bss_size;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/2] mm: simplify free_highmem_page() and free_reserved_page()
Let's simplify and unify free_highmem_page() and free_reserved_page(). Gave it a quick test in i386 QEMU with 4G of RAM - seems to work just fine. David Hildenbrand (2): video: fbdev: acornfb: remove free_unused_pages() mm: simplify free_highmem_page() and free_reserved_page() drivers/video/fbdev/acornfb.c| 34 include/linux/highmem-internal.h | 5 - include/linux/mm.h | 16 ++- mm/page_alloc.c | 11 --- 4 files changed, 2 insertions(+), 64 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] video: fbdev: acornfb: remove free_unused_pages()
This function is never used and it is one of the last remaining user of
__free_reserved_page(). Let's just drop it.
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: "Peter Zijlstra (Intel)"
Cc: Mike Rapoport
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: Wei Yang
Cc: "Gustavo A. R. Silva"
Cc: Sam Ravnborg
Signed-off-by: David Hildenbrand
---
drivers/video/fbdev/acornfb.c | 34 --
1 file changed, 34 deletions(-)
diff --git a/drivers/video/fbdev/acornfb.c b/drivers/video/fbdev/acornfb.c
index bcc92aecf666..1b72edc01cfb 100644
--- a/drivers/video/fbdev/acornfb.c
+++ b/drivers/video/fbdev/acornfb.c
@@ -921,40 +921,6 @@ static int acornfb_detect_monitortype(void)
return 4;
}
-/*
- * This enables the unused memory to be freed on older Acorn machines.
- * We are freeing memory on behalf of the architecture initialisation
- * code here.
- */
-static inline void
-free_unused_pages(unsigned int virtual_start, unsigned int virtual_end)
-{
- int mb_freed = 0;
-
- /*
-* Align addresses
-*/
- virtual_start = PAGE_ALIGN(virtual_start);
- virtual_end = PAGE_ALIGN(virtual_end);
-
- while (virtual_start < virtual_end) {
- struct page *page;
-
- /*
-* Clear page reserved bit,
-* set count to 1, and free
-* the page.
-*/
- page = virt_to_page(virtual_start);
- __free_reserved_page(page);
-
- virtual_start += PAGE_SIZE;
- mb_freed += PAGE_SIZE / 1024;
- }
-
- printk("acornfb: freed %dK memory\n", mb_freed);
-}
-
static int acornfb_probe(struct platform_device *dev)
{
unsigned long size;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/5] amba: Make the remove callback return void
Hello,
On Tue, Jan 26, 2021 at 05:08:40PM +, Suzuki K Poulose wrote:
> On 1/26/21 4:58 PM, Uwe Kleine-König wrote:
> > All amba drivers return 0 in their remove callback. Together with the
> > driver core ignoring the return value anyhow, it doesn't make sense to
> > return a value here.
> >
> > Change the remove prototype to return void, which makes it explicit that
> > returning an error value doesn't work as expected. This simplifies changing
> > the core remove callback to return void, too.
> >
> > Reviewed-by: Ulf Hansson
> > Reviewed-by: Arnd Bergmann
> > Acked-by: Alexandre Belloni
> > Acked-by: Dmitry Torokhov
> > Acked-by: Krzysztof Kozlowski # for drivers/memory
> > Acked-by: Mark Brown
> > Acked-by: Dmitry Torokhov
> > Acked-by: Linus Walleij
> > Signed-off-by: Uwe Kleine-König
>
>
> > drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 +---
>
> You are most likely to have a conflict for the above file, with what is
> in coresight/next. It should be easy to resolve.
I'm surprised to see that the remove callback introduced in 2952ecf5df33
("coresight: etm4x: Refactor probing routine") has an __exit annotation.
With .suppress_bind_attrs = true you don't need a remove callback at
all. (And without .suppress_bind_attrs = true the remove callback must
have no __exit annotation.)
This make me looking at commit 45fe7befe0db ("coresight: remove broken
__exit annotations") by Arnd. Unless I miss something the better change
would have been to remove the unused remove callbacks instead of dropping
their __exit annotation?!
Anyhow, my conflict resolution looks as follows:
diff --cc drivers/hwtracing/coresight/coresight-etm4x-core.c
index 82787cba537d,473ab7480a36..
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@@ -1703,6 -1903,28 +1903,27 @@@ static int __exit etm4_remove_dev(struc
cpus_read_unlock();
coresight_unregister(drvdata->csdev);
+
+ return 0;
+ }
+
-static int __exit etm4_remove_amba(struct amba_device *adev)
++static void __exit etm4_remove_amba(struct amba_device *adev)
+ {
+ struct etmv4_drvdata *drvdata = dev_get_drvdata(>dev);
+
+ if (drvdata)
- return etm4_remove_dev(drvdata);
- return 0;
++ etm4_remove_dev(drvdata);
+ }
+
+ static int __exit etm4_remove_platform_dev(struct platform_device *pdev)
+ {
+ int ret = 0;
+ struct etmv4_drvdata *drvdata = dev_get_drvdata(>dev);
+
+ if (drvdata)
+ ret = etm4_remove_dev(drvdata);
+ pm_runtime_disable(>dev);
+ return ret;
}
static const struct amba_id etm4_ids[] = {
If this series should make it in for 5.12 we probably need an immutable
branch between hwtracing and amba.
> Otherwise, the changes look good for the drivers/hwtracing/coresight/*
>
> Acked-by: Suzuki K Poulose
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] fbtft: add tearing signal detect
On Tue, Jan 26, 2021 at 08:40:35PM +0800, Carlis wrote:
> @@ -82,6 +111,29 @@ enum st7789v_command {
> */
> static int init_display(struct fbtft_par *par)
> {
> + int rc;
> + struct device *dev = par->info->device;
> +
> + par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
> + if (par->gpio.te) {
I explained in my earlier review that devm_gpiod_get_index_optional()
can return error pointers... There was quite a bit of detail about how
to handle this correctly in my earlier review, but I think you might
not have noticed it. Please read it again.
> + init_completion(_panel_te);
> + mutex_init(_mutex);
> + rc = devm_request_irq(dev,
> + gpiod_to_irq(par->gpio.te),
> + spi_panel_te_handler, IRQF_TRIGGER_RISING,
> + "TE_GPIO", par);
> + if (rc) {
> + pr_err("TE request_irq failed.\n");
> + devm_gpiod_put(dev, par->gpio.te);
> + par->gpio.te = NULL;
> + } else {
> + disable_irq_nosync(gpiod_to_irq(par->gpio.te));
> + pr_info("TE request_irq completion.\n");
> + }
> + } else {
> + pr_err("%s:%d, TE gpio not specified\n",
> +__func__, __LINE__);
> + }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #11 from bola...@163.com --- No HSA_AMD option, it's only for 64bit kernel -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #10 from Alex Deucher (alexdeuc...@gmail.com) --- does setting CONFIG_HSA_AMD=n fix it? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #9 from bola...@163.com --- (In reply to Alex Deucher from comment #8) > (In reply to bolando from comment #7) > > Yes,maybe Ubuntu kernel applyed some patch? Otherwise AMDGPU driver only > > worked on X86_64 ? The radeon drivers worked well on 32bit kernel. I have > > Caicos and Oland chipset radeon graphic cards,all be drived perfect on > > LFS-10.0 i686 arch! > > It should work in theory. That said, we don't do regular validation of 32 > bit any more. Thanks for you relay,depend on general-purpose of drivers development,AMDGPU should work on 32bit arch.But I don't know what wrong with it.The AMDGPU driver for me lack of kfd ,APU node topology and amdgpudrmfb(fb0 interface),I want to know how to fix it. The firmware and kernel is nearly newest ,but 5.10.9 do more things on resetting the GPU, show more debug information than 5.8.0. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/5] amba: Make the remove callback return void
All amba drivers return 0 in their remove callback. Together with the
driver core ignoring the return value anyhow, it doesn't make sense to
return a value here.
Change the remove prototype to return void, which makes it explicit that
returning an error value doesn't work as expected. This simplifies changing
the core remove callback to return void, too.
Reviewed-by: Ulf Hansson
Reviewed-by: Arnd Bergmann
Acked-by: Alexandre Belloni
Acked-by: Dmitry Torokhov
Acked-by: Krzysztof Kozlowski # for drivers/memory
Acked-by: Mark Brown
Acked-by: Dmitry Torokhov
Acked-by: Linus Walleij
Signed-off-by: Uwe Kleine-König
---
drivers/amba/bus.c | 5 ++---
drivers/char/hw_random/nomadik-rng.c | 3 +--
drivers/dma/pl330.c| 3 +--
drivers/gpu/drm/pl111/pl111_drv.c | 4 +---
drivers/hwtracing/coresight/coresight-catu.c | 3 +--
drivers/hwtracing/coresight/coresight-cpu-debug.c | 4 +---
drivers/hwtracing/coresight/coresight-cti-core.c | 4 +---
drivers/hwtracing/coresight/coresight-etb10.c | 4 +---
drivers/hwtracing/coresight/coresight-etm3x-core.c | 4 +---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 +---
drivers/hwtracing/coresight/coresight-funnel.c | 4 ++--
drivers/hwtracing/coresight/coresight-replicator.c | 4 ++--
drivers/hwtracing/coresight/coresight-stm.c| 4 +---
drivers/hwtracing/coresight/coresight-tmc-core.c | 4 +---
drivers/hwtracing/coresight/coresight-tpiu.c | 4 +---
drivers/i2c/busses/i2c-nomadik.c | 4 +---
drivers/input/serio/ambakmi.c | 3 +--
drivers/memory/pl172.c | 4 +---
drivers/memory/pl353-smc.c | 4 +---
drivers/mmc/host/mmci.c| 4 +---
drivers/rtc/rtc-pl030.c| 4 +---
drivers/rtc/rtc-pl031.c| 4 +---
drivers/spi/spi-pl022.c| 5 ++---
drivers/tty/serial/amba-pl010.c| 4 +---
drivers/tty/serial/amba-pl011.c| 3 +--
drivers/vfio/platform/vfio_amba.c | 3 +--
drivers/video/fbdev/amba-clcd.c| 4 +---
drivers/watchdog/sp805_wdt.c | 4 +---
include/linux/amba/bus.h | 2 +-
sound/arm/aaci.c | 4 +---
30 files changed, 34 insertions(+), 80 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 8c4a42df47c6..48b5d4b4e889 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -300,11 +300,10 @@ static int amba_remove(struct device *dev)
{
struct amba_device *pcdev = to_amba_device(dev);
struct amba_driver *drv = to_amba_driver(dev->driver);
- int ret = 0;
pm_runtime_get_sync(dev);
if (drv->remove)
- ret = drv->remove(pcdev);
+ drv->remove(pcdev);
pm_runtime_put_noidle(dev);
/* Undo the runtime PM settings in amba_probe() */
@@ -315,7 +314,7 @@ static int amba_remove(struct device *dev)
amba_put_disable_pclk(pcdev);
dev_pm_domain_detach(dev, true);
- return ret;
+ return 0;
}
static void amba_shutdown(struct device *dev)
diff --git a/drivers/char/hw_random/nomadik-rng.c
b/drivers/char/hw_random/nomadik-rng.c
index b0ded41eb865..67947a19aa22 100644
--- a/drivers/char/hw_random/nomadik-rng.c
+++ b/drivers/char/hw_random/nomadik-rng.c
@@ -69,11 +69,10 @@ static int nmk_rng_probe(struct amba_device *dev, const
struct amba_id *id)
return ret;
}
-static int nmk_rng_remove(struct amba_device *dev)
+static void nmk_rng_remove(struct amba_device *dev)
{
amba_release_regions(dev);
clk_disable(rng_clk);
- return 0;
}
static const struct amba_id nmk_rng_ids[] = {
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index bc0f66af0f11..fd8d2bc3be9f 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -3195,7 +3195,7 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
return ret;
}
-static int pl330_remove(struct amba_device *adev)
+static void pl330_remove(struct amba_device *adev)
{
struct pl330_dmac *pl330 = amba_get_drvdata(adev);
struct dma_pl330_chan *pch, *_p;
@@ -3235,7 +3235,6 @@ static int pl330_remove(struct amba_device *adev)
if (pl330->rstc)
reset_control_assert(pl330->rstc);
- return 0;
}
static const struct amba_id pl330_ids[] = {
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index 40e6708fbbe2..1fb5eacefd2d 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -320,7 +320,7 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
return ret;
}
-static int pl111_amba_remove(struct amba_device *amba_dev)
+static void
Re: [PATCH v3 4/5] amba: Make the remove callback return void
On 26-01-21, 17:58, Uwe Kleine-König wrote: > All amba drivers return 0 in their remove callback. Together with the > driver core ignoring the return value anyhow, it doesn't make sense to > return a value here. > > Change the remove prototype to return void, which makes it explicit that > returning an error value doesn't work as expected. This simplifies changing > the core remove callback to return void, too. > > Reviewed-by: Ulf Hansson > Reviewed-by: Arnd Bergmann > Acked-by: Alexandre Belloni > Acked-by: Dmitry Torokhov > Acked-by: Krzysztof Kozlowski # for drivers/memory > Acked-by: Mark Brown > Acked-by: Dmitry Torokhov > Acked-by: Linus Walleij > Signed-off-by: Uwe Kleine-König > --- > drivers/amba/bus.c | 5 ++--- > drivers/char/hw_random/nomadik-rng.c | 3 +-- > drivers/dma/pl330.c| 3 +-- For dmaengine: Acked-By: Vinod Koul -- ~Vinod ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1
On Tue, Jan 26, 2021 at 6:55 PM Patrik Jakobsson wrote: > On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko > wrote: > > > > On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > > wrote: > > > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > > > wrote: > > > > > > > > Hi guys, > > > > > > > > This is first part of Intel MID outdated platforms removal. It's > > > > collected into > > > > immutable branch with a given tag, please pull to yours subsystems. > > > > > > Hi Andy, > > > Do you plan on eventually removing X86_INTEL_MID completely? If so, > > > then I should probably start looking at removing the corresponding > > > parts in GMA500. > > > > Nope. It is related to only Medfield / Clovertrail platforms. > > > > There are other (MID) platforms that may / might utilize this driver > > in the future. > > Right, there's still Oaktrail / Moorestown with hardware in the wild. Actually Moorestown had to be removed a few years ago (kernel won't boot on them anyway from that date when Alan removed support under arch/x86 for it). I'm talking about Merrifield and Moorefield that can utilize it and also some other platforms that are not SFI based (Cedar something... IIRC). > > I.o.w. we probably can remove the oldest stuff in the driver WRT above > > mentioned platforms, but leave the driver for the rest. > > I wouldn't be in a hurry with this though, display drivers are easy to > > remove, but really hard to get back on velocity after that. > > Ok, I'll have a look at removing Medfield. That code should have been > removed a long time ago. -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to bolando from comment #7) > Yes,maybe Ubuntu kernel applyed some patch? Otherwise AMDGPU driver only > worked on X86_64 ? The radeon drivers worked well on 32bit kernel. I have > Caicos and Oland chipset radeon graphic cards,all be drived perfect on > LFS-10.0 i686 arch! It should work in theory. That said, we don't do regular validation of 32 bit any more. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/5] amba: minor fix and various cleanups
From: Uwe Kleine-König https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/5] drm/qxl: properly free qxl releases
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 1 +
drivers/gpu/drm/qxl/qxl_kms.c | 22 --
drivers/gpu/drm/qxl/qxl_release.c | 2 ++
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 01354b43c413..1c57b587b6a7 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -214,6 +214,7 @@ struct qxl_device {
spinlock_t release_lock;
struct idr release_idr;
uint32_trelease_seqno;
+ atomic_trelease_count;
spinlock_t release_idr_lock;
struct mutexasync_io_mutex;
unsigned int last_sent_io_cmd;
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 4a60a52ab62e..f177f72bfc12 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
@@ -286,8 +287,25 @@ int qxl_device_init(struct qxl_device *qdev,
void qxl_device_fini(struct qxl_device *qdev)
{
- qxl_bo_unref(>current_release_bo[0]);
- qxl_bo_unref(>current_release_bo[1]);
+ int cur_idx, try;
+
+ for (cur_idx = 0; cur_idx < 3; cur_idx++) {
+ if (!qdev->current_release_bo[cur_idx])
+ continue;
+ qxl_bo_unpin(qdev->current_release_bo[cur_idx]);
+ qxl_bo_unref(>current_release_bo[cur_idx]);
+ qdev->current_release_bo_offset[cur_idx] = 0;
+ qdev->current_release_bo[cur_idx] = NULL;
+ }
+
+ /*
+* Ask host to release resources (+fill release ring),
+* then wait for the release actually happening.
+*/
+ qxl_io_notify_oom(qdev);
+ for (try = 0; try < 20 && atomic_read(>release_count) > 0; try++)
+ msleep(20);
+
qxl_gem_fini(qdev);
qxl_bo_fini(qdev);
flush_work(>gc_work);
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 28013fd1f8ea..43a5436853b7 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -196,6 +196,7 @@ qxl_release_free(struct qxl_device *qdev,
qxl_release_free_list(release);
kfree(release);
}
+ atomic_dec(>release_count);
}
static int qxl_release_bo_alloc(struct qxl_device *qdev,
@@ -344,6 +345,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev,
unsigned long size,
*rbo = NULL;
return idr_ret;
}
+ atomic_inc(>release_count);
mutex_lock(>release_mutex);
if (qdev->current_release_bo_offset[cur_idx] + 1 >=
releases_per_bo[cur_idx]) {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] drm/qxl: use drmm_mode_config_init
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 012bce0cdb65..38d6b596094d 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1195,7 +1195,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
int i;
int ret;
- drm_mode_config_init(>ddev);
+ ret = drmm_mode_config_init(>ddev);
+ if (ret)
+ return ret;
ret = qxl_create_monitors_object(qdev);
if (ret)
@@ -1228,5 +1230,4 @@ int qxl_modeset_init(struct qxl_device *qdev)
void qxl_modeset_fini(struct qxl_device *qdev)
{
qxl_destroy_monitors_object(qdev);
- drm_mode_config_cleanup(>ddev);
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/5] drm/qxl: handle shadow in primary destroy
qxl_primary_atomic_disable must check whenever the framebuffer bo has a
shadow surface and in case it has check the shadow primary status.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 60331e31861a..f5ee8cd72b5b 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -562,6 +562,8 @@ static void qxl_primary_atomic_disable(struct drm_plane
*plane,
if (old_state->fb) {
struct qxl_bo *bo = gem_to_qxl_bo(old_state->fb->obj[0]);
+ if (bo->shadow)
+ bo = bo->shadow;
if (bo->is_primary) {
qxl_io_destroy_primary(qdev);
bo->is_primary = false;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/5] drm/qxl: unpin release objects
Balances the qxl_create_bo(..., pinned=true, ...);
call in qxl_release_bo_alloc().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_release.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index c52412724c26..28013fd1f8ea 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -347,6 +347,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev,
unsigned long size,
mutex_lock(>release_mutex);
if (qdev->current_release_bo_offset[cur_idx] + 1 >=
releases_per_bo[cur_idx]) {
+ qxl_bo_unpin(qdev->current_release_bo[cur_idx]);
qxl_bo_unref(>current_release_bo[cur_idx]);
qdev->current_release_bo_offset[cur_idx] = 0;
qdev->current_release_bo[cur_idx] = NULL;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] drm/qxl: release shadow on shutdown
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 38d6b596094d..60331e31861a 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1229,5 +1229,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
void qxl_modeset_fini(struct qxl_device *qdev)
{
+ if (qdev->dumb_shadow_bo) {
+ drm_gem_object_put(>dumb_shadow_bo->tbo.base);
+ qdev->dumb_shadow_bo = NULL;
+ }
qxl_destroy_monitors_object(qdev);
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/5] drm/qxl: fix driver shutdown issues.
Almost there. Still getting this on driver unbind: kobject: '(null)' ((ptrval)): is not initialized, yet kobject_put(= ) is being called [ ... ] Call Trace: ttm_device_fini+0x133/0x1b0 [ttm] qxl_ttm_fini+0x2f/0x40 [qxl] qxl_device_fini+0x88/0x120 [qxl] drm_minor_release+0x3d/0x60 but I don't think this is the qxl driver's fault. Gerd Hoffmann (5): drm/qxl: use drmm_mode_config_init drm/qxl: unpin release objects drm/qxl: release shadow on shutdown drm/qxl: handle shadow in primary destroy drm/qxl: properly free qxl releases drivers/gpu/drm/qxl/qxl_drv.h | 1 + drivers/gpu/drm/qxl/qxl_display.c | 11 +-- drivers/gpu/drm/qxl/qxl_kms.c | 22 -- drivers/gpu/drm/qxl/qxl_release.c | 3 +++ 4 files changed, 33 insertions(+), 4 deletions(-) --=20 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/ttm: move memory accounting into vmwgfx
Hi "Christian, I love your patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] [also build test ERROR on next-20210125] [cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.11-rc5] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit-v3/20210126-140030 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip config: arm-defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/8bdbdb659aa407a4f3e28dab6d6465304d326888 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit-v3/20210126-140030 git checkout 8bdbdb659aa407a4f3e28dab6d6465304d326888 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/ttm/ttm.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1
On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko wrote: > > On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > wrote: > > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > > wrote: > > > > > > Hi guys, > > > > > > This is first part of Intel MID outdated platforms removal. It's > > > collected into > > > immutable branch with a given tag, please pull to yours subsystems. > > > > Hi Andy, > > Do you plan on eventually removing X86_INTEL_MID completely? If so, > > then I should probably start looking at removing the corresponding > > parts in GMA500. > > Nope. It is related to only Medfield / Clovertrail platforms. > > There are other (MID) platforms that may / might utilize this driver > in the future. Right, there's still Oaktrail / Moorestown with hardware in the wild. > > I.o.w. we probably can remove the oldest stuff in the driver WRT above > mentioned platforms, but leave the driver for the rest. > I wouldn't be in a hurry with this though, display drivers are easy to > remove, but really hard to get back on velocity after that. Ok, I'll have a look at removing Medfield. That code should have been removed a long time ago. -Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #7 from bola...@163.com --- Yes,maybe Ubuntu kernel applyed some patch? Otherwise AMDGPU driver only worked on X86_64 ? The radeon drivers worked well on 32bit kernel. I have Caicos and Oland chipset radeon graphic cards,all be drived perfect on LFS-10.0 i686 arch! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1
On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson wrote: > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > wrote: > > > > Hi guys, > > > > This is first part of Intel MID outdated platforms removal. It's collected > > into > > immutable branch with a given tag, please pull to yours subsystems. > > Hi Andy, > Do you plan on eventually removing X86_INTEL_MID completely? If so, > then I should probably start looking at removing the corresponding > parts in GMA500. Nope. It is related to only Medfield / Clovertrail platforms. There are other (MID) platforms that may / might utilize this driver in the future. I.o.w. we probably can remove the oldest stuff in the driver WRT above mentioned platforms, but leave the driver for the rest. I wouldn't be in a hurry with this though, display drivers are easy to remove, but really hard to get back on velocity after that. -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1
On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko wrote: > > Hi guys, > > This is first part of Intel MID outdated platforms removal. It's collected > into > immutable branch with a given tag, please pull to yours subsystems. Hi Andy, Do you plan on eventually removing X86_INTEL_MID completely? If so, then I should probably start looking at removing the corresponding parts in GMA500. Thanks Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915/gt: use new tasklet API for execution list
Quoting Emil Renner Berthing (2021-01-26 15:01:55)
> This converts the driver to use the new tasklet API introduced in
> commit 12cc923f1ccc ("tasklet: Introduce new initialization API")
>
> Signed-off-by: Emil Renner Berthing
>
> ---
> v2: Rebased on drm-intel-next
Ta. Saves me having to do the fixup.
Reviewed-by: Chris Wilson
Will be applied to drm-intel-gt-next which is scheduled for inclusion in
5.13. It should apply against the 5.12 merge window if there's a tree
through which you want to migrate the tasklet API faster.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) --- Does it work properly on 64bit? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Hi Hridya,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.11-rc5]
[cannot apply to next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Hridya-Valsaraju/dmabuf-Add-the-capability-to-expose-DMA-BUF-stats-in-sysfs/20210120-172216
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
45dfb8a5659ad286c28fa59008271dbc4e5e3f2d
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/1ce52d5b375d9055a8ca6a7d78f7f1c256680190
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Hridya-Valsaraju/dmabuf-Add-the-capability-to-expose-DMA-BUF-stats-in-sysfs/20210120-172216
git checkout 1ce52d5b375d9055a8ca6a7d78f7f1c256680190
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/dma-buf/dma-buf-sysfs-stats.c:144:6: warning: no previous prototype
>> for 'dma_buf_attach_stats_teardown' [-Wmissing-prototypes]
144 | void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach)
| ^
>> drivers/dma-buf/dma-buf-sysfs-stats.c:158:5: warning: no previous prototype
>> for 'dma_buf_attach_stats_setup' [-Wmissing-prototypes]
158 | int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach,
| ^~
>> drivers/dma-buf/dma-buf-sysfs-stats.c:199:6: warning: no previous prototype
>> for 'dma_buf_stats_teardown' [-Wmissing-prototypes]
199 | void dma_buf_stats_teardown(struct dma_buf *dmabuf)
| ^~
>> drivers/dma-buf/dma-buf-sysfs-stats.c:214:5: warning: no previous prototype
>> for 'dma_buf_init_sysfs_statistics' [-Wmissing-prototypes]
214 | int dma_buf_init_sysfs_statistics(void)
| ^
>> drivers/dma-buf/dma-buf-sysfs-stats.c:230:6: warning: no previous prototype
>> for 'dma_buf_uninit_sysfs_statistics' [-Wmissing-prototypes]
230 | void dma_buf_uninit_sysfs_statistics(void)
| ^~~
>> drivers/dma-buf/dma-buf-sysfs-stats.c:236:5: warning: no previous prototype
>> for 'dma_buf_stats_setup' [-Wmissing-prototypes]
236 | int dma_buf_stats_setup(struct dma_buf *dmabuf)
| ^~~
vim +/dma_buf_attach_stats_teardown +144 drivers/dma-buf/dma-buf-sysfs-stats.c
143
> 144 void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach)
145 {
146 struct dma_buf_attach_sysfs_entry *sysfs_entry;
147
148 sysfs_entry = attach->sysfs_entry;
149 if (!sysfs_entry)
150 return;
151
152 sysfs_delete_link(_entry->kobj, >dev->kobj,
"device");
153
154 kobject_del(_entry->kobj);
155 kobject_put(_entry->kobj);
156 }
157
> 158 int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach,
159 unsigned int uid)
160 {
161 struct dma_buf_attach_sysfs_entry *sysfs_entry;
162 int ret;
163 struct dma_buf *dmabuf;
164
165 if (!attach)
166 return -EINVAL;
167
168 dmabuf = attach->dmabuf;
169
170 sysfs_entry = kzalloc(sizeof(struct dma_buf_attach_sysfs_entry),
171GFP_KERNEL);
172 if (!sysfs_entry)
173 return -ENOMEM;
174
175 sysfs_entry->kobj.kset = dmabuf->sysfs_entry->attach_stats_kset;
176
177 attach->sysfs_entry = sysfs_entry;
178
179 ret = kobject_init_and_add(_entry->kobj,
_buf_attach_ktype,
180 NULL, "%u", uid);
181 if (ret)
182 goto kobj_err;
183
184 ret = sysfs_create_link(_entry->kobj, >dev->kobj,
185 "device");
186 if (ret)
187 goto link_err;
188
189 return 0;
190
191 link_err:
192 kobject_del(_entry->kobj);
193 kobj_err:
194 kobject_put(_entry->kobj);
195 attach->sysfs_entry = NULL;
196
197 return ret;
198 }
> 199 void dma_buf_stats_teardown(struct dma_buf *dmabuf)
200 {
201 struct dma_buf_sysfs_entry *sysfs_entry;
202
203 sysfs_entry = dmabuf->sysfs_entry;
204 if
[PATCH 3/3] drm/ttm: drop sysfs directory
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_module.c | 50
drivers/gpu/drm/ttm/ttm_module.h | 2 --
2 files changed, 52 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_module.c b/drivers/gpu/drm/ttm/ttm_module.c
index f6566603a60f..56b0efdba1a9 100644
--- a/drivers/gpu/drm/ttm/ttm_module.c
+++ b/drivers/gpu/drm/ttm/ttm_module.c
@@ -37,66 +37,16 @@
#include "ttm_module.h"
-static DECLARE_WAIT_QUEUE_HEAD(exit_q);
-static atomic_t device_released;
struct dentry *ttm_debugfs_root;
-static struct device_type ttm_drm_class_type = {
- .name = "ttm",
- /**
-* Add pm ops here.
-*/
-};
-
-static void ttm_drm_class_device_release(struct device *dev)
-{
- atomic_set(_released, 1);
- wake_up_all(_q);
-}
-
-static struct device ttm_drm_class_device = {
- .type = _drm_class_type,
- .release = _drm_class_device_release
-};
-
-struct kobject *ttm_get_kobj(void)
-{
- struct kobject *kobj = _drm_class_device.kobj;
- BUG_ON(kobj == NULL);
- return kobj;
-}
-
static int __init ttm_init(void)
{
- int ret;
-
- ret = dev_set_name(_drm_class_device, "ttm");
- if (unlikely(ret != 0))
- return ret;
-
- atomic_set(_released, 0);
- ret = drm_class_device_register(_drm_class_device);
- if (unlikely(ret != 0))
- goto out_no_dev_reg;
-
ttm_debugfs_root = debugfs_create_dir("ttm", NULL);
return 0;
-out_no_dev_reg:
- atomic_set(_released, 1);
- wake_up_all(_q);
- return ret;
}
static void __exit ttm_exit(void)
{
- drm_class_device_unregister(_drm_class_device);
-
- /**
-* Refuse to unload until the TTM device is released.
-* Not sure this is 100% needed.
-*/
-
- wait_event(exit_q, atomic_read(_released) == 1);
debugfs_remove(ttm_debugfs_root);
}
diff --git a/drivers/gpu/drm/ttm/ttm_module.h b/drivers/gpu/drm/ttm/ttm_module.h
index 2f03c2fcf570..d7cac5d4b835 100644
--- a/drivers/gpu/drm/ttm/ttm_module.h
+++ b/drivers/gpu/drm/ttm/ttm_module.h
@@ -33,10 +33,8 @@
#define TTM_PFX "[TTM] "
-struct kobject;
struct dentry;
-extern struct kobject *ttm_get_kobj(void);
extern struct dentry *ttm_debugfs_root;
#endif /* _TTM_MODULE_H_ */
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/ttm: move memory accounting into vmwgfx v2
This is just another feature which is only used by VMWGFX, so move
it into the driver instead.
I've tried to add the accounting sysfs file to the kobject of the drm
minor, but I'm not 100% sure if this works as expected.
v2: fix typo in KFD and avoid 64bit divide
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 16 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 8 ++---
drivers/gpu/drm/drm_gem_vram_helper.c | 6 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 7 ++--
drivers/gpu/drm/nouveau/nouveau_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_object.c | 4 +--
drivers/gpu/drm/radeon/radeon_object.c| 8 ++---
drivers/gpu/drm/ttm/Makefile | 7 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 33 +--
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_device.c | 22 ++---
drivers/gpu/drm/ttm/ttm_pool.c| 13 +---
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/{ttm => vmwgfx}/ttm_memory.c | 19 ---
.../gpu/drm/vmwgfx}/ttm_memory.h | 5 +--
drivers/gpu/drm/vmwgfx/ttm_object.h | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 22 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 +++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 28 +++-
include/drm/ttm/ttm_bo_api.h | 13 ++--
include/drm/ttm/ttm_bo_driver.h | 1 -
include/drm/ttm/ttm_tt.h | 1 +
22 files changed, 110 insertions(+), 115 deletions(-)
rename drivers/gpu/drm/{ttm => vmwgfx}/ttm_memory.c (97%)
rename {include/drm/ttm => drivers/gpu/drm/vmwgfx}/ttm_memory.h (97%)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 0849b68e784f..e440af37dde8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -118,6 +118,16 @@ void amdgpu_amdkfd_gpuvm_init_mem_limits(void)
*/
#define ESTIMATE_PT_SIZE(mem_size) ((mem_size) >> 14)
+static size_t amdgpu_amdkfd_acc_size(uint64_t size)
+{
+ size >>= PAGE_SHIFT;
+ size *= sizeof(dma_addr_t) + sizeof(void *);
+
+ return __roundup_pow_of_two(sizeof(struct amdgpu_bo)) +
+ __roundup_pow_of_two(sizeof(struct ttm_tt)) +
+ PAGE_ALIGN(size);
+}
+
static int amdgpu_amdkfd_reserve_mem_limit(struct amdgpu_device *adev,
uint64_t size, u32 domain, bool sg)
{
@@ -126,8 +136,7 @@ static int amdgpu_amdkfd_reserve_mem_limit(struct
amdgpu_device *adev,
size_t acc_size, system_mem_needed, ttm_mem_needed, vram_needed;
int ret = 0;
- acc_size = ttm_bo_dma_acc_size(>mman.bdev, size,
- sizeof(struct amdgpu_bo));
+ acc_size = amdgpu_amdkfd_acc_size(size);
vram_needed = 0;
if (domain == AMDGPU_GEM_DOMAIN_GTT) {
@@ -174,8 +183,7 @@ static void unreserve_mem_limit(struct amdgpu_device *adev,
{
size_t acc_size;
- acc_size = ttm_bo_dma_acc_size(>mman.bdev, size,
- sizeof(struct amdgpu_bo));
+ acc_size = amdgpu_amdkfd_acc_size(size);
spin_lock(_mem_limit.mem_limit_lock);
if (domain == AMDGPU_GEM_DOMAIN_GTT) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 6cc9919b12cc..599c9a132eb6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -523,7 +523,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
- size_t acc_size;
int r;
/* Note that GDS/GWS/OA allocates 1 page per byte/resource. */
@@ -546,9 +545,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
*bo_ptr = NULL;
- acc_size = ttm_bo_dma_acc_size(>mman.bdev, size,
- sizeof(struct amdgpu_bo));
-
bo = kzalloc(sizeof(struct amdgpu_bo), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
@@ -577,8 +573,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo->tbo.priority = 1;
r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, bp->type,
->placement, page_align, , acc_size,
-NULL, bp->resv, _bo_destroy);
+>placement, page_align, , NULL,
+bp->resv, _bo_destroy);
if (unlikely(r != 0))
return r;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 0b13c8507688..a0992f0b8afd 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++
[PATCH 1/3] drm/ttm: rework ttm_tt page limit v3
TTM implements a rather extensive accounting of allocated memory.
There are two reasons for this:
1. It tries to block userspace allocating a huge number of very small
BOs without accounting for the kmalloced memory.
2. Make sure we don't over allocate and run into an OOM situation
during swapout while trying to handle the memory shortage.
This is only partially a good idea. First of all it is perfectly
valid for an application to use all of system memory, limiting it to
50% is not really acceptable.
What we need to take care of is that the application is held
accountable for the memory it allocated. This is what control
mechanisms like memcg and the normal Linux page accounting already do.
Making sure that we don't run into an OOM situation while trying to
cope with a memory shortage is still a good idea, but this is also
not very well implemented since it means another opportunity of
recursion from the driver back into TTM.
So start to rework all of this by implementing a shrinker callback which
allows for TT object to be swapped out if necessary.
v2: Switch from limit to shrinker callback.
v3: fix gfp mask handling, use atomic for swapable_pages, add debugfs
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 4 +-
drivers/gpu/drm/ttm/ttm_memory.c| 7 +-
drivers/gpu/drm/ttm/ttm_tt.c| 111 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/ttm/ttm_bo_api.h| 2 +-
include/drm/ttm/ttm_tt.h| 6 +-
6 files changed, 117 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 20256797f3a6..643befc1a6f2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1219,7 +1219,7 @@ EXPORT_SYMBOL(ttm_bo_wait);
* A buffer object shrink method that tries to swap out the first
* buffer object on the bo_global::swap_lru list.
*/
-int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
+int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
{
struct ttm_global *glob = _glob;
struct ttm_buffer_object *bo;
@@ -1302,7 +1302,7 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
if (bo->bdev->funcs->swap_notify)
bo->bdev->funcs->swap_notify(bo);
- ret = ttm_tt_swapout(bo->bdev, bo->ttm);
+ ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
out:
/**
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index a3bfbd9cea68..634a85c2dc4c 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "ttm_module.h"
@@ -276,9 +277,9 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool
from_wq,
while (ttm_zones_above_swap_target(glob, from_wq, extra)) {
spin_unlock(>lock);
- ret = ttm_bo_swapout(ctx);
+ ret = ttm_bo_swapout(ctx, GFP_KERNEL);
spin_lock(>lock);
- if (unlikely(ret != 0))
+ if (unlikely(ret < 0))
break;
}
@@ -453,6 +454,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
zone->name, (unsigned long long)zone->max_mem >> 10);
}
ttm_pool_mgr_init(glob->zone_kernel->max_mem/(2*PAGE_SIZE));
+ ttm_tt_mgr_init();
return 0;
out_no_zone:
ttm_mem_global_release(glob);
@@ -466,6 +468,7 @@ void ttm_mem_global_release(struct ttm_mem_global *glob)
/* let the page allocator first stop the shrink work. */
ttm_pool_mgr_fini();
+ ttm_tt_mgr_fini();
flush_workqueue(glob->swap_queue);
destroy_workqueue(glob->swap_queue);
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 7782d5393c7c..b67795de228d 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -38,6 +38,11 @@
#include
#include
+#include "ttm_module.h"
+
+static struct shrinker mm_shrinker;
+static atomic_long_t swapable_pages;
+
/*
* Allocates a ttm structure for the given BO.
*/
@@ -223,32 +228,41 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
return ret;
}
-int ttm_tt_swapout(struct ttm_device *bdev, struct ttm_tt *ttm)
+/**
+ * ttm_tt_swapout - swap out tt object
+ *
+ * @bdev: TTM device structure.
+ * @ttm: The struct ttm_tt.
+ * @gfp_flags: Flags to use for memory allocation.
+ *
+ * Swapout a TT object to a shmem_file, return number of pages swapped out or
+ * negative error code.
+ */
+int ttm_tt_swapout(struct ttm_device *bdev, struct ttm_tt *ttm,
+ gfp_t gfp_flags)
{
+ loff_t size = (loff_t)ttm->num_pages << PAGE_SHIFT;
struct address_space *swap_space;
struct file *swap_storage;
struct page *from_page;
struct page *to_page;
- gfp_t gfp_mask;
int i, ret;
- swap_storage = shmem_file_setup("ttm
Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1
On Tue, Jan 26, 2021 at 4:23 PM Hans de Goede wrote: > > Hi, > > On 1/26/21 1:38 PM, Andy Shevchenko wrote: > > Hi guys, > > > > This is first part of Intel MID outdated platforms removal. It's collected > > into > > immutable branch with a given tag, please pull to yours subsystems. > > > > (All changes are tagged by the respective maintainers) ... > > platform/x86: intel_mid_thermal: Remove driver for deprecated platform > > platform/x86: intel_mid_powerbtn: Remove driver for deprecated > > platform > > Erm, I already have this 2 in platform-drivers-x86/for-next since you said > that > these 2 could be merged independently. Yes, you may merge this on top, shouldn't be any conflicts. But this mail originally was sent a couple of days ago, I had a problem with my email setup. > Anyways I just did a test-merge and there is no conflict, so everything is ok. Yep. That's how it works :) > From my pov this looks good and I plan to merge this into > platform-drivers-x86/for-next > before the merge-window. > > I'm going to hold off on doing that for a bit for now in case one of the other > subsys maintainers has any objections. Noted and thanks! -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/13] livepatch: move klp_find_object_module to module.c
+++ Christoph Hellwig [21/01/21 08:49 +0100]:
To uncouple the livepatch code from module loader internals move a
slightly refactored version of klp_find_object_module to module.c
This allows to mark find_module static and removes one of the last
users of module_mutex outside of module.c.
Signed-off-by: Christoph Hellwig
---
include/linux/module.h | 3 +--
kernel/livepatch/core.c | 39 +--
kernel/module.c | 17 -
3 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index b4654f8a408134..8588482bde4116 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -586,8 +586,7 @@ static inline bool within_module(unsigned long addr, const
struct module *mod)
return within_module_init(addr, mod) || within_module_core(addr, mod);
}
-/* Search for module by name: must hold module_mutex. */
-struct module *find_module(const char *name);
+struct module *find_klp_module(const char *name);
/* Check if a module is loaded. */
bool module_loaded(const char *name);
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index a7f625dc24add3..878759baadd81c 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -49,30 +49,6 @@ static bool klp_is_module(struct klp_object *obj)
return obj->name;
}
-/* sets obj->mod if object is not vmlinux and module is found */
-static void klp_find_object_module(struct klp_object *obj)
-{
- struct module *mod;
-
- mutex_lock(_mutex);
- /*
-* We do not want to block removal of patched modules and therefore
-* we do not take a reference here. The patches are removed by
-* klp_module_going() instead.
-*/
- mod = find_module(obj->name);
- /*
-* Do not mess work of klp_module_coming() and klp_module_going().
-* Note that the patch might still be needed before klp_module_going()
-* is called. Module functions can be called even in the GOING state
-* until mod->exit() finishes. This is especially important for
-* patches that modify semantic of the functions.
-*/
- if (mod && mod->klp_alive)
- obj->mod = mod;
- mutex_unlock(_mutex);
-}
Hmm, I am not a huge fan of moving more livepatch code into module.c, I
wonder if we can keep them separate.
Why not have module_is_loaded() kill two birds with one stone? That
is, just have it return a module pointer to signify that the module is
loaded, NULL if not. Then we don't need an extra find_klp_module()
function just to call find_module() and return a pointer, as
module_is_loaded() can just do that for us.
As for the mod->klp_alive check, I believe this function
(klp_find_object_module()) is called with klp_mutex held, and
mod->klp_alive is only modified under klp_mutex. Also, if klp_alive is
true, the module is at least COMING and cannot be GOING until it
acquires the klp_mutex again in klp_module_going(). So does that hunk
really need to be under module_mutex? It has been a long time since
I've looked at livepatch code so it would be great if someone could
double check.
Jessica
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1
Hi, On 1/26/21 1:38 PM, Andy Shevchenko wrote: > Hi guys, > > This is first part of Intel MID outdated platforms removal. It's collected > into > immutable branch with a given tag, please pull to yours subsystems. > > (All changes are tagged by the respective maintainers) > > Thanks, > > With Best Regards, > Andy Shevchenko > > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > are available in the Git repository at: > > git://git.infradead.org/linux-platform-drivers-x86.git > tags/ib-drm-gpio-pdx86-rtc-wdt-v5.12-1 > > for you to fetch changes up to a507e5d90f3d6846a02d9c2c79e6f6395982db92: > > platform/x86: intel_scu_wdt: Get rid of custom x86 model comparison > (2021-01-25 20:05:32 +0200) > > > ib-drm-gpio-pdx86-rtc-wdt for v5.12-1 > > First part of Intel MID outdated platforms removal. > > The following is an automated git shortlog grouped by driver: > > drm/gma500: > - Get rid of duplicate NULL checks > - Convert to use new SCU IPC API > > gpio: > - msic: Remove driver for deprecated platform > - intel-mid: Remove driver for deprecated platform > > intel_mid_powerbtn: > - Remove driver for deprecated platform > > intel_mid_thermal: > - Remove driver for deprecated platform > > intel_scu_wdt: > - Get rid of custom x86 model comparison > - Drop SCU notification > - Move driver from arch/x86 > > rtc: > - mrst: Remove driver for deprecated platform > > watchdog: > - intel-mid_wdt: Postpone IRQ handler registration till SCU is ready > - intel_scu_watchdog: Remove driver for deprecated platform > > > Andy Shevchenko (12): > drm/gma500: Convert to use new SCU IPC API > drm/gma500: Get rid of duplicate NULL checks > gpio: intel-mid: Remove driver for deprecated platform > gpio: msic: Remove driver for deprecated platform > platform/x86: intel_mid_thermal: Remove driver for deprecated platform > platform/x86: intel_mid_powerbtn: Remove driver for deprecated platform Erm, I already have this 2 in platform-drivers-x86/for-next since you said that these 2 could be merged independently. Anyways I just did a test-merge and there is no conflict, so everything is ok. >From my pov this looks good and I plan to merge this into >platform-drivers-x86/for-next before the merge-window. I'm going to hold off on doing that for a bit for now in case one of the other subsys maintainers has any objections. Regards, Hans > rtc: mrst: Remove driver for deprecated platform > watchdog: intel_scu_watchdog: Remove driver for deprecated platform > watchdog: intel-mid_wdt: Postpone IRQ handler registration till SCU is > ready > platform/x86: intel_scu_wdt: Move driver from arch/x86 > platform/x86: intel_scu_wdt: Drop SCU notification > platform/x86: intel_scu_wdt: Get rid of custom x86 model comparison > > MAINTAINERS| 2 - > arch/x86/platform/intel-mid/device_libs/Makefile | 1 - > drivers/gpio/Kconfig | 14 - > drivers/gpio/Makefile | 1 - > drivers/gpio/TODO | 2 +- > drivers/gpio/gpio-intel-mid.c | 414 --- > drivers/gpio/gpio-msic.c | 314 > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/gma500/mdfld_device.c | 2 - > drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 - > drivers/gpu/drm/gma500/mdfld_output.c | 8 +- > drivers/gpu/drm/gma500/oaktrail_device.c | 3 - > drivers/gpu/drm/gma500/psb_drv.h | 3 + > drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 30 +- > drivers/platform/x86/Kconfig | 23 +- > drivers/platform/x86/Makefile | 3 +- > drivers/platform/x86/intel_mid_powerbtn.c | 233 - > drivers/platform/x86/intel_mid_thermal.c | 560 > - > .../platform/x86/intel_scu_wdt.c | 41 +- > drivers/rtc/Kconfig| 12 - > drivers/rtc/Makefile | 1 - > drivers/rtc/rtc-mrst.c | 521 --- > drivers/watchdog/Kconfig | 9 - > drivers/watchdog/Makefile | 1 - > drivers/watchdog/intel-mid_wdt.c | 8 +- > drivers/watchdog/intel_scu_watchdog.c | 533 > drivers/watchdog/intel_scu_watchdog.h | 50 -- > 27 files changed, 54 insertions(+), 2738 deletions(-) > delete mode 100644 drivers/gpio/gpio-intel-mid.c > delete mode 100644
Re: [PATCH RESEND v3 1/6] drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order
Hi Maxime,
On Wed, Nov 18, 2020 at 06:48:05PM +0100, Maxime Ripard wrote:
> On Mon, Oct 12, 2020 at 02:00:30AM +0300, Laurent Pinchart wrote:
> > > -static int drm_of_lvds_get_remote_pixels_type(
> > > - const struct device_node *port_node)
> > > +static int drm_of_lvds_get_remote_pixels_type(const struct device_node
> > > *endpoint)
> > > {
> > > - struct device_node *endpoint = NULL;
> > > - int pixels_type = -EPIPE;
> > > + struct device_node *remote_port;
> > > + int pixels_type;
> > >
> > > - for_each_child_of_node(port_node, endpoint) {
> > > - struct device_node *remote_port;
> > > - int current_pt;
> > > -
> > > - if (!of_node_name_eq(endpoint, "endpoint"))
> > > - continue;
> > > -
> > > - remote_port = of_graph_get_remote_port(endpoint);
> > > - if (!remote_port) {
> > > - of_node_put(remote_port);
> > > - return -EPIPE;
> > > - }
> > > -
> > > - current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
> > > + remote_port = of_graph_get_remote_port(endpoint);
> > > + if (!remote_port) {
> > > of_node_put(remote_port);
> >
> > You can drop this line.
> >
> > > - if (pixels_type < 0)
> > > - pixels_type = current_pt;
> > > -
> > > - /*
> > > - * Sanity check, ensure that all remote endpoints have the same
> > > - * pixel type. We may lift this restriction later if we need to
> > > - * support multiple sinks with different dual-link
> > > - * configurations by passing the endpoints explicitly to
> > > - * drm_of_lvds_get_dual_link_pixel_order().
> > > - */
> >
> > Shouldn't we keep this check when endpoint_id is -1 in
> > drm_of_lvds_get_dual_link_pixel_order() ?
>
> I tried to do that, and I'm not quite really sure how to go around it.
>
> This scans all the endpoints in a given port.
>
> However, now that we have the device, port id and endpoint id, we need
> to use of_graph_get_port_by_id to get the port matching the device and
> port id, and iterate over all its endpoint as done here.
>
> The trouble is that of_graph_get_port_by_id expects a !const
> device_node, yet drm_of_lvds_get_dual_link_pixel_order (and seems to be
> doing so rightfully), so that creates a warning because we drop the
> const there.
of_graph_get_port_by_id() doesn't seem to modify the device_node passed
to it, couldn't it be modified to take a const pointer ?
> Changing the prototype to passing only the port device_node doesn't
> really work either, since it would be const, and we would need to call
> of_graph_get_endpoint_by_regs (so having the parent device_node, through
> of_graph_get_port_parent) and of_graph_get_port_parent takes a !const
> port device_node.
>
> I guess we could drop const entirely from our function, but that doesn't
> look right either..
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/ttm: move memory accounting into vmwgfx
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20210125]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.11-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit-v3/20210126-140030
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a003-20210126 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
925ae8c790c7e354f12ec14a6cac6aa49fc75b29)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/8bdbdb659aa407a4f3e28dab6d6465304d326888
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit-v3/20210126-140030
git checkout 8bdbdb659aa407a4f3e28dab6d6465304d326888
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1515:44: warning: variable 'vmw' is
>> uninitialized when used here [-Wuninitialized]
ret = ttm_mem_global_init(_mem_glob, >drm);
^~~
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1504:25: note: initialize the variable
'vmw' to silence this warning
struct vmw_private *vmw;
^
= NULL
1 warning generated.
vim +/vmw +1515 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
1501
1502 static int vmw_probe(struct pci_dev *pdev, const struct pci_device_id
*ent)
1503 {
1504 struct vmw_private *vmw;
1505 int ret;
1506
1507 ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
"svgadrmfb");
1508 if (ret)
1509 return ret;
1510
1511 ret = pcim_enable_device(pdev);
1512 if (ret)
1513 return ret;
1514
> 1515 ret = ttm_mem_global_init(_mem_glob, >drm);
1516 if (ret)
1517 return ret;
1518
1519 vmw = devm_drm_dev_alloc(>dev, ,
1520 struct vmw_private, drm);
1521 if (IS_ERR(vmw))
1522 return PTR_ERR(vmw);
1523
1524 pci_set_drvdata(pdev, >drm);
1525
1526 ret = vmw_driver_load(vmw, ent->device);
1527 if (ret)
1528 return ret;
1529
1530 ret = drm_dev_register(>drm, 0);
1531 if (ret) {
1532 vmw_driver_unload(>drm);
1533 return ret;
1534 }
1535
1536 return 0;
1537 }
1538
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm: Extend color correction to support 3D-CLU
Hi Laurent and Kieran,
Do you forget to attach cubic_lut_property with crtc?
drm_object_attach_property(>base, config->cubic_lut_property,
cubic_lut_size);
在 2020/12/21 9:57, Laurent Pinchart 写道:
From: Kieran Bingham
Extend the existing color management properties to support provision
of a 3D cubic look up table, allowing for color specific adjustments.
Signed-off-by: Kieran Bingham
Co-developed-by: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_atomic_helper.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 3 ++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
drivers/gpu/drm/drm_color_mgmt.c | 41 +++
drivers/gpu/drm/drm_mode_config.c | 14
include/drm/drm_crtc.h| 9 +
include/drm/drm_mode_config.h | 11 ++
7 files changed, 82 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ba1507036f26..0f54897d3c8d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3558,6 +3558,7 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
replaced = drm_property_replace_blob(_state->degamma_lut, NULL);
replaced |= drm_property_replace_blob(_state->ctm, NULL);
replaced |= drm_property_replace_blob(_state->gamma_lut, blob);
+ replaced |= drm_property_replace_blob(_state->cubic_lut, NULL);
crtc_state->color_mgmt_changed |= replaced;
ret = drm_atomic_commit(state);
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index ddcf5c2c8e6a..61c685b50677 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -141,6 +141,8 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
drm_property_blob_get(state->ctm);
if (state->gamma_lut)
drm_property_blob_get(state->gamma_lut);
+ if (state->cubic_lut)
+ drm_property_blob_get(state->cubic_lut);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -213,6 +215,7 @@ void __drm_atomic_helper_crtc_destroy_state(struct
drm_crtc_state *state)
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
drm_property_blob_put(state->gamma_lut);
+ drm_property_blob_put(state->cubic_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 268bb69c2e2f..07229acab71c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -471,6 +471,14 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == config->cubic_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ >cubic_lut,
+ val,
+ -1, sizeof(struct drm_color_lut),
+ );
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (property == config->prop_out_fence_ptr) {
s32 __user *fence_ptr = u64_to_user_ptr(val);
@@ -516,6 +524,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? state->ctm->base.id : 0;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
+ else if (property == config->cubic_lut_property)
+ *val = (state->cubic_lut) ? state->cubic_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
else if (property == crtc->scaling_filter_property)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 3bcabc2f6e0e..85bbbc8ce8e5 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -33,7 +33,7 @@
/**
* DOC: overview
*
- * Color management or color space adjustments is supported through a set of 5
+ * Color management or color space adjustments is supported through a set of 7
* properties on the _crtc object. They are set up by calling
* drm_crtc_enable_color_mgmt().
*
@@ -60,7 +60,7 @@
* “CTM”:
*Blob property to set the current transformation matrix (CTM) apply to
*pixel data after the lookup through the degamma LUT and before the
- * lookup through the gamma LUT. The data is interpreted as a struct
+ * lookup through the cubic LUT. The data is interpreted as a struct
*_color_ctm.
*
*
Re: [PATCH 3/4] drm: Extend color correction to support 3D-CLU
Hi Laurent and Kieran,
Do you forget to attach cubic_lut_property with crtc?
drm_object_attach_property(>base, config->cubic_lut_property,
cubic_lut_size);
在 2020/12/21 9:57, Laurent Pinchart 写道:
From: Kieran Bingham
Extend the existing color management properties to support provision
of a 3D cubic look up table, allowing for color specific adjustments.
Signed-off-by: Kieran Bingham
Co-developed-by: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_atomic_helper.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 3 ++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
drivers/gpu/drm/drm_color_mgmt.c | 41 +++
drivers/gpu/drm/drm_mode_config.c | 14
include/drm/drm_crtc.h| 9 +
include/drm/drm_mode_config.h | 11 ++
7 files changed, 82 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ba1507036f26..0f54897d3c8d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3558,6 +3558,7 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
replaced = drm_property_replace_blob(_state->degamma_lut, NULL);
replaced |= drm_property_replace_blob(_state->ctm, NULL);
replaced |= drm_property_replace_blob(_state->gamma_lut, blob);
+ replaced |= drm_property_replace_blob(_state->cubic_lut, NULL);
crtc_state->color_mgmt_changed |= replaced;
ret = drm_atomic_commit(state);
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index ddcf5c2c8e6a..61c685b50677 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -141,6 +141,8 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
drm_property_blob_get(state->ctm);
if (state->gamma_lut)
drm_property_blob_get(state->gamma_lut);
+ if (state->cubic_lut)
+ drm_property_blob_get(state->cubic_lut);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -213,6 +215,7 @@ void __drm_atomic_helper_crtc_destroy_state(struct
drm_crtc_state *state)
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
drm_property_blob_put(state->gamma_lut);
+ drm_property_blob_put(state->cubic_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 268bb69c2e2f..07229acab71c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -471,6 +471,14 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == config->cubic_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ >cubic_lut,
+ val,
+ -1, sizeof(struct drm_color_lut),
+ );
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (property == config->prop_out_fence_ptr) {
s32 __user *fence_ptr = u64_to_user_ptr(val);
@@ -516,6 +524,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? state->ctm->base.id : 0;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
+ else if (property == config->cubic_lut_property)
+ *val = (state->cubic_lut) ? state->cubic_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
else if (property == crtc->scaling_filter_property)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 3bcabc2f6e0e..85bbbc8ce8e5 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -33,7 +33,7 @@
/**
* DOC: overview
*
- * Color management or color space adjustments is supported through a set of 5
+ * Color management or color space adjustments is supported through a set of 7
* properties on the _crtc object. They are set up by calling
* drm_crtc_enable_color_mgmt().
*
@@ -60,7 +60,7 @@
* “CTM”:
*Blob property to set the current transformation matrix (CTM) apply to
*pixel data after the lookup through the degamma LUT and before the
- * lookup through the gamma LUT. The data is interpreted as a struct
+ * lookup through the cubic LUT. The data is interpreted as a struct
*_color_ctm.
*
*
Re: [PATCH v2 10/11] drm: Use state helper instead of the plane state pointer
On Thu, Jan 21, 2021 at 05:35:35PM +0100, Maxime Ripard wrote:
> Many drivers reference the plane->state pointer in order to get the
> current plane state in their atomic_update or atomic_disable hooks,
> which would be the new plane state in the global atomic state since
> _swap_state happened when those hooks are run.
>
> Use the drm_atomic_get_new_plane_state helper to get that state to make it
> more obvious.
>
> This was made using the coccinelle script below:
>
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
>
> (
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_disable = func,
> ...,
> };
> |
> static const struct drm_plane_helper_funcs helpers = {
> ...,
> .atomic_update = func,
> ...,
> };
> )
>
> @ adds_new_state @
> identifier plane_atomic_func.func;
> identifier plane, state;
> identifier new_state;
> @@
>
> func(struct drm_plane *plane, struct drm_atomic_state *state)
> {
> ...
> - struct drm_plane_state *new_state = plane->state;
> + struct drm_plane_state *new_state =
> drm_atomic_get_new_plane_state(state, plane);
> ...
> }
>
> @ include depends on adds_new_state @
> @@
>
> #include
>
> @ no_include depends on !include && adds_new_state @
> @@
>
> + #include
> #include
>
> Signed-off-by: Maxime Ripard
Looks great.
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #5 from bola...@163.com --- I have tested with many kernels and firmwares but failed ! To compare with Ubuntu 20.4 LTS kern log,my kern log lack of "kfd: added device" and "amdgpu :06:00.0: amdgpu: Topology: Add APU node [0x0:0x0]". It seems sdma0 and vcn bug,with some memoery faults. This is mail error log. Jan 26 09:58:07 Pink kernel: [ 69.141903] [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on sdma0 (-110). Jan 26 09:58:07 Pink kernel: [ 69.145985] amdgpu :06:00.0: amdgpu: [gfxhub0] no-retry page fault (src_id:0 ring:157 vmid:10 pasid:0, for process pid 0 thread pid 0) Jan 26 09:58:07 Pink kernel: [ 69.146002] amdgpu :06:00.0: amdgpu: in page starting at address 0x00f40021b000 from client 27 Jan 26 09:58:07 Pink kernel: [ 69.146012] amdgpu :06:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x00A00B3A Jan 26 09:58:07 Pink kernel: [ 69.146020] amdgpu :06:00.0: amdgpu: ^I Faulty UTCL2 client ID: CPC (0x5) Jan 26 09:58:07 Pink kernel: [ 69.146027] amdgpu :06:00.0: amdgpu: ^I MORE_FAULTS: 0x0 Jan 26 09:58:07 Pink kernel: [ 69.146033] amdgpu :06:00.0: amdgpu: ^I WALKER_ERROR: 0x5 Jan 26 09:58:07 Pink kernel: [ 69.146040] amdgpu :06:00.0: amdgpu: ^I PERMISSION_FAULTS: 0x3 Jan 26 09:58:07 Pink kernel: [ 69.146046] amdgpu :06:00.0: amdgpu: ^I MAPPING_ERROR: 0x1 Jan 26 09:58:07 Pink kernel: [ 69.146052] amdgpu :06:00.0: amdgpu: ^I RW: 0x0 Jan 26 09:58:07 Pink kernel: [ 69.146067] amdgpu :06:00.0: amdgpu: [gfxhub0] no-retry page fault (src_id:0 ring:157 vmid:10 pasid:0, for process pid 0 thread pid 0) Jan 26 09:58:07 Pink kernel: [ 69.146077] amdgpu :06:00.0: amdgpu: in page starting at address 0x00f40021b000 from client 27 Jan 26 09:58:07 Pink kernel: [ 69.146086] amdgpu :06:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x00A00B3A Jan 26 09:58:07 Pink kernel: [ 69.146094] amdgpu :06:00.0: amdgpu: ^I Faulty UTCL2 client ID: CPC (0x5) Jan 26 09:58:07 Pink kernel: [ 69.146100] amdgpu :06:00.0: amdgpu: ^I MORE_FAULTS: 0x0 Jan 26 09:58:07 Pink kernel: [ 69.146106] amdgpu :06:00.0: amdgpu: ^I WALKER_ERROR: 0x5 Jan 26 09:58:07 Pink kernel: [ 69.146112] amdgpu :06:00.0: amdgpu: ^I PERMISSION_FAULTS: 0x3 Jan 26 09:58:07 Pink kernel: [ 69.146118] amdgpu :06:00.0: amdgpu: ^I MAPPING_ERROR: 0x1 Jan 26 09:58:07 Pink kernel: [ 69.146124] amdgpu :06:00.0: amdgpu: ^I RW: 0x0 Jan 26 09:58:07 Pink kernel: [ 69.146514] mce: [Hardware Error]: Machine check events logged Jan 26 09:58:07 Pink kernel: [ 69.146526] mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 20: dc203001085b Jan 26 09:58:07 Pink kernel: [ 69.146533] mce: [Hardware Error]: TSC 52c0cc15a4 ADDR 7ffcff40 SYND 5b240204 IPID 2e Jan 26 09:58:07 Pink kernel: [ 69.146545] mce: [Hardware Error]: PROCESSOR 2:810f10 TIME 1611655087 SOCKET 0 APIC 0 microcode 8101016 Jan 26 09:58:08 Pink kernel: [ 70.150550] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, trying to reset the VCPU!!! Jan 26 09:58:10 Pink kernel: [ 71.172270] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, trying to reset the VCPU!!! Jan 26 09:58:11 Pink kernel: [ 72.193987] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, trying to reset the VCPU!!! Jan 26 09:58:12 Pink kernel: [ 73.215700] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, trying to reset the VCPU!!! Jan 26 09:58:13 Pink kernel: [ 74.237417] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, trying to reset the VCPU!!! Jan 26 09:58:14 Pink kernel: [ 75.259129] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, trying to reset the VCPU!!! Jan 26 09:58:15 Pink kernel: [ 76.280848] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, trying to reset the VCPU!!! Jan 26 09:58:16 Pink kernel: [ 77.302559] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, trying to reset the VCPU!!! Jan 26 09:58:17 Pink kernel: [ 78.324274] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, trying to reset the VCPU!!! Jan 26 09:58:18 Pink kernel: [ 79.345988] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, trying to reset the VCPU!!! Jan 26 09:58:18 Pink kernel: [ 79.366046] [drm:vcn_v1_0_set_powergating_state [amdgpu]] *ERROR* VCN decode not responding, giving up!!! Jan 26 09:58:18 Pink kernel: [ 79.366067] [drm:amdgpu_device_ip_set_powergating_state [amdgpu]] *ERROR* set_powergating_state of IP block failed -1 Jan 26 09:58:18 Pink kernel: [ 79.366137] amdgpu :06:00.0: amdgpu: [mmhub0] no-retry page fault (src_id:0 ring:16 vmid:0 pasid:0, for process pid 0 thread pid 0) Jan 26 09:58:18 Pink
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #4 from bola...@163.com --- Created attachment 294861 --> https://bugzilla.kernel.org/attachment.cgi?id=294861=edit GCC version -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #3 from bola...@163.com --- Created attachment 294859 --> https://bugzilla.kernel.org/attachment.cgi?id=294859=edit Kernel config file -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #2 from bola...@163.com --- Created attachment 294857 --> https://bugzilla.kernel.org/attachment.cgi?id=294857=edit Kernel log without kfd fd kfd: added device 1002:15dd and amdgpu: Topology: Add APU node [0x0:0x0] -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #1 from bola...@163.com --- Created attachment 294855 --> https://bugzilla.kernel.org/attachment.cgi?id=294855=edit Main Error -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] New: IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 Bug ID: 211349 Summary: IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs! Product: Drivers Version: 2.5 Kernel Version: 5.10.9 Hardware: i386 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: bola...@163.com Regression: No When load AMDGPU driver,it hangs everytime with IB test faild on sdma0.The AMDGPU drivers is not support on 32bit system? My linux is LFS-10.0,hardware is mainboard(Biostar B450GT with newest bios,update to 12/08/2020),cpu(Ryzen5 2400G),memery(32G DDR4 with duaul channel).I have test many version of kernels and amdgpu firmware,but hangs every time when modprobe amdgpu. I also have installed Ubuntu 20.4 TLS(with 5.8.0-25 kernel),AMDGPU worked very good on it. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/ttm: move memory accounting into vmwgfx
Hi "Christian, I love your patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] [also build test ERROR on next-20210125] [cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.11-rc5] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit-v3/20210126-140030 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip config: riscv-rv32_defconfig (attached as .config) compiler: riscv32-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/8bdbdb659aa407a4f3e28dab6d6465304d326888 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit-v3/20210126-140030 git checkout 8bdbdb659aa407a4f3e28dab6d6465304d326888 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): riscv32-linux-ld: drivers/gpu/drm/ttm/ttm_device.o: in function `.L20': >> ttm_device.c:(.text+0x330): undefined reference to `__udivdi3' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Mon, Jan 25, 2021 at 7:17 PM Oliver Graute wrote: > I would prefer mine, because I got a wrong colored penguin on bootup > with yours :-) I have originally passed .bpc = 8, but looking at the panel datasheet, this should be: .bpc = 6 instead. In your patch, you pass the timing parameters three times, but they are all the same. Usually, it is meant to be: minimal, typical, maximum values. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: rework ttm_tt page limit v3
Hi Daniel,
just in case you read that when you come back from vacation.
I've tested this quite extensively and apart from the typo in the KFD in
patch #3 it looks pretty solid now.
E.g. no lockdep or KASAN splat when I use the debugfs stuff. Is this
sufficient?
Thanks,
Christian.
Am 25.01.21 um 14:25 schrieb Christian König:
TTM implements a rather extensive accounting of allocated memory.
There are two reasons for this:
1. It tries to block userspace allocating a huge number of very small
BOs without accounting for the kmalloced memory.
2. Make sure we don't over allocate and run into an OOM situation
during swapout while trying to handle the memory shortage.
This is only partially a good idea. First of all it is perfectly
valid for an application to use all of system memory, limiting it to
50% is not really acceptable.
What we need to take care of is that the application is held
accountable for the memory it allocated. This is what control
mechanisms like memcg and the normal Linux page accounting already do.
Making sure that we don't run into an OOM situation while trying to
cope with a memory shortage is still a good idea, but this is also
not very well implemented since it means another opportunity of
recursion from the driver back into TTM.
So start to rework all of this by implementing a shrinker callback which
allows for TT object to be swapped out if necessary.
v2: Switch from limit to shrinker callback.
v3: fix gfp mask handling, use atomic for swapable_pages, add debugfs
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 4 +-
drivers/gpu/drm/ttm/ttm_memory.c| 7 +-
drivers/gpu/drm/ttm/ttm_tt.c| 111 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/ttm/ttm_bo_api.h| 2 +-
include/drm/ttm/ttm_tt.h| 6 +-
6 files changed, 117 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 20256797f3a6..643befc1a6f2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1219,7 +1219,7 @@ EXPORT_SYMBOL(ttm_bo_wait);
* A buffer object shrink method that tries to swap out the first
* buffer object on the bo_global::swap_lru list.
*/
-int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
+int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
{
struct ttm_global *glob = _glob;
struct ttm_buffer_object *bo;
@@ -1302,7 +1302,7 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
if (bo->bdev->funcs->swap_notify)
bo->bdev->funcs->swap_notify(bo);
- ret = ttm_tt_swapout(bo->bdev, bo->ttm);
+ ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
out:
/**
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index a3bfbd9cea68..634a85c2dc4c 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "ttm_module.h"
@@ -276,9 +277,9 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool from_wq,
while (ttm_zones_above_swap_target(glob, from_wq, extra)) {
spin_unlock(>lock);
- ret = ttm_bo_swapout(ctx);
+ ret = ttm_bo_swapout(ctx, GFP_KERNEL);
spin_lock(>lock);
- if (unlikely(ret != 0))
+ if (unlikely(ret < 0))
break;
}
@@ -453,6 +454,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
zone->name, (unsigned long long)zone->max_mem >> 10);
}
ttm_pool_mgr_init(glob->zone_kernel->max_mem/(2*PAGE_SIZE));
+ ttm_tt_mgr_init();
return 0;
out_no_zone:
ttm_mem_global_release(glob);
@@ -466,6 +468,7 @@ void ttm_mem_global_release(struct ttm_mem_global *glob)
/* let the page allocator first stop the shrink work. */
ttm_pool_mgr_fini();
+ ttm_tt_mgr_fini();
flush_workqueue(glob->swap_queue);
destroy_workqueue(glob->swap_queue);
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 7782d5393c7c..b67795de228d 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -38,6 +38,11 @@
#include
#include
+#include "ttm_module.h"
+
+static struct shrinker mm_shrinker;
+static atomic_long_t swapable_pages;
+
/*
* Allocates a ttm structure for the given BO.
*/
@@ -223,32 +228,41 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
return ret;
}
-int ttm_tt_swapout(struct ttm_device *bdev, struct ttm_tt *ttm)
+/**
+ * ttm_tt_swapout - swap out tt object
+ *
+ * @bdev: TTM device structure.
+ * @ttm: The struct ttm_tt.
+ * @gfp_flags: Flags to use for memory allocation.
+ *
+ * Swapout a TT object to a shmem_file, return number of pages swapped out or
+ * negative error code.
+ */
+int ttm_tt_swapout(struct ttm_device
Re: [PATCH v2 3/5] drm/panel-simple: Retry if we timeout waiting for HPD
Quoting Douglas Anderson (2021-01-15 14:44:18)
> On an Innolux N116BCA panel that I have in front of me, sometimes HPD
> simply doesn't assert no matter how long you wait for it. As per the
> very wise advice of The IT Crowd ("Have you tried turning it off and
> on again?") it appears that power cycling is enough to kick this panel
> back into a sane state.
>
> From tests on this panel, it appears that leaving it powered off for a
> while stimulates the problem. Adding a 6 second sleep at the start of
> panel_simple_prepare_once() makes it happen fairly reliably and, with
> this delay, I saw up to 3 retries needed sometimes. Without the 6
> second sleep, however, the panel came up much more reliably the first
> time or after only 1 retry.
>
> While it's unknown what the problems are with this panel (and probably
> the hardware should be debugged), adding a few retries to the power on
> routine doesn't seem insane. Even if this panel's problems are
> attributed to the fact that it's pre-production and/or can be fixed,
> retries clearly can help in some cases and really don't hurt.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
> @@ -440,6 +441,31 @@ static int panel_simple_prepare(struct drm_panel *panel)
> return err;
> }
>
> +/*
> + * Some panels simply don't always come up and need to be power cycled to
> + * work properly. We'll allow for a handful of retries.
> + */
> +#define MAX_PANEL_PREPARE_TRIES5
Is this define used anywhere else? Feels like it would be better to
inline the constant and move the comment above the loop, but I guess
this is OK too.
> +
> +static int panel_simple_prepare(struct drm_panel *panel)
> +{
> + int ret;
> + int try;
> +
> + for (try = 0; try < MAX_PANEL_PREPARE_TRIES; try++) {
> + ret = panel_simple_prepare_once(panel);
> + if (ret != -ETIMEDOUT)
> + break;
> + }
> +
> + if (ret == -ETIMEDOUT)
> + dev_err(panel->dev, "Prepare timeout after %d tries\n", try);
> + else if (try)
> + dev_warn(panel->dev, "Prepare needed %d retries\n", try);
> +
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] fbtft: add tearing signal detect
From: zhangxuezhi
For st7789v ic,add tearing signal detect to avoid screen tearing
Signed-off-by: zhangxuezhi
---
v3:modify author name
---
drivers/staging/fbtft/fb_st7789v.c | 134 -
drivers/staging/fbtft/fbtft.h | 1 +
2 files changed, 134 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fb_st7789v.c
b/drivers/staging/fbtft/fb_st7789v.c
index 3a280cc..5426276 100644
--- a/drivers/staging/fbtft/fb_st7789v.c
+++ b/drivers/staging/fbtft/fb_st7789v.c
@@ -9,9 +9,12 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
-
+#include
#include "fbtft.h"
#define DRVNAME "fb_st7789v"
@@ -66,6 +69,38 @@ enum st7789v_command {
#define MADCTL_MX BIT(6) /* bitmask for column address order */
#define MADCTL_MY BIT(7) /* bitmask for page address order */
+#define SPI_PANEL_TE_TIMEOUT 400
+static struct mutex te_mutex;/*mutex for tearing line*/
+static struct completion spi_panel_te;
+
+static irqreturn_t spi_panel_te_handler(int irq, void *data)
+{
+ complete(_panel_te);
+ return IRQ_HANDLED;
+}
+
+static void enable_spi_panel_te_irq(struct fbtft_par *par, bool enable)
+{
+ static int te_irq_count;
+
+ if (!par->gpio.te) {
+ pr_err("%s:%d,SPI panel TE GPIO not configured\n",
+ __func__, __LINE__);
+ return;
+ }
+
+ mutex_lock(_mutex);
+
+ if (enable) {
+ if (++te_irq_count == 1)
+ enable_irq(gpiod_to_irq(par->gpio.te));
+ } else {
+ if (--te_irq_count == 0)
+ disable_irq(gpiod_to_irq(par->gpio.te));
+ }
+ mutex_unlock(_mutex);
+}
+
/**
* init_display() - initialize the display controller
*
@@ -82,6 +117,29 @@ enum st7789v_command {
*/
static int init_display(struct fbtft_par *par)
{
+ int rc;
+ struct device *dev = par->info->device;
+
+ par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
+ if (par->gpio.te) {
+ init_completion(_panel_te);
+ mutex_init(_mutex);
+ rc = devm_request_irq(dev,
+ gpiod_to_irq(par->gpio.te),
+spi_panel_te_handler, IRQF_TRIGGER_RISING,
+"TE_GPIO", par);
+ if (rc) {
+ pr_err("TE request_irq failed.\n");
+ devm_gpiod_put(dev, par->gpio.te);
+ par->gpio.te = NULL;
+ } else {
+ disable_irq_nosync(gpiod_to_irq(par->gpio.te));
+ pr_info("TE request_irq completion.\n");
+ }
+ } else {
+ pr_err("%s:%d, TE gpio not specified\n",
+ __func__, __LINE__);
+ }
/* turn off sleep mode */
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
mdelay(120);
@@ -137,6 +195,9 @@ static int init_display(struct fbtft_par *par)
*/
write_reg(par, PWCTRL1, 0xA4, 0xA1);
+/*Tearing Effect Line On*/
+ if (par->gpio.te)
+ write_reg(par, 0x35, 0x00);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
if (HSD20_IPS)
@@ -145,6 +206,76 @@ static int init_display(struct fbtft_par *par)
return 0;
}
+/*
+ *
+ * int (*write_vmem)(struct fbtft_par *par);
+ *
+ */
+
+/* 16 bit pixel over 8-bit databus */
+int st7789v_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
+{
+ u16 *vmem16;
+ __be16 *txbuf16 = par->txbuf.buf;
+ size_t remain;
+ size_t to_copy;
+ size_t tx_array_size;
+ int i;
+ int rc, ret = 0;
+ size_t startbyte_size = 0;
+
+ fbtft_par_dbg(DEBUG_WRITE_VMEM, par, "st7789v ---%s(offset=%zu,
len=%zu)\n",
+ __func__, offset, len);
+
+ remain = len / 2;
+ vmem16 = (u16 *)(par->info->screen_buffer + offset);
+
+ if (par->gpio.dc)
+ gpiod_set_value(par->gpio.dc, 1);
+
+ /* non buffered write */
+ if (!par->txbuf.buf)
+ return par->fbtftops.write(par, vmem16, len);
+
+ /* buffered write */
+ tx_array_size = par->txbuf.len / 2;
+
+ if (par->startbyte) {
+ txbuf16 = par->txbuf.buf + 1;
+ tx_array_size -= 2;
+ *(u8 *)(par->txbuf.buf) = par->startbyte | 0x2;
+ startbyte_size = 1;
+ }
+
+ while (remain) {
+ to_copy = min(tx_array_size, remain);
+ dev_dbg(par->info->device, "to_copy=%zu, remain=%zu\n",
+ to_copy, remain - to_copy);
+
+ for (i = 0; i < to_copy; i++)
+ txbuf16[i] = cpu_to_be16(vmem16[i]);
+
+
Re: [PATCH v2 2/5] drm/panel-simple: Don't wait longer for HPD than hpd_absent_delay
Quoting Douglas Anderson (2021-01-15 14:44:17) > If a panel has an hpd_absent_delay specified then we know exactly how > long the maximum time is before HPD must be asserted. That means we > can use it as a timeout for polling the HPD pin instead of using an > arbitrary timeout. This is especially useful for dealing with panels > that periodically fail to power on and need to be retried. We can > detect the problem sooner. > > Signed-off-by: Douglas Anderson > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 5/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM
On Mon, 2021-01-25 at 15:48 +0200, Laurentiu Palcu wrote: > Hi Liu Ying, > > Just some minor comments below. > > On Thu, Jan 21, 2021 at 03:14:22PM +0800, Liu Ying wrote: > > This patch introduces i.MX8qm/qxp Display Processing Unit(DPU) DRM support. > > > > DPU is comprised of two main components that include a blit engine for > > 2D graphics accelerations(with composition support) and a display controller > > for display output processing, as well as a command sequencer. Outside of > > DPU, optional prefetch engines, a.k.a, Prefetch Resolve Gasket(PRG) and > > Display Prefetch Resolve(DPR), can fetch data from memory prior to some DPU > > fetchunits of blit engine and display controller. The prefetch engines > > support reading linear formats and resolving Vivante GPU tile formats. > > > > This patch adds kernel modesetting support for the display controller part. > > The driver supports two CRTCs per display controller, planes backed by > > four fetchunits(decode0/1, fetchlayer, fetchwarp), fetchunit allocation > > logic for the two CRTCs, prefetch engines(with tile resolving supported), > > plane upscaling/deinterlacing/yuv2rgb CSC/alpha blending and CRTC gamma > > correction. The registers of the controller is accessed without command > > sequencer involved, instead just by using CPU. > > > > Reference manual can be found at: > > https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM > > > > Signed-off-by: Liu Ying > > --- > > v5->v6: > > * Do not use macros where possible. (Laurentiu) > > * Break dpu_plane_atomic_check() into some smaller functions. (Laurentiu) > > * Address some minor comments from Laurentiu. > > * Add dpu_crtc_err() helper marco to tell dmesg which CRTC generates error. > > * Drop calling dev_set_drvdata() from dpu_drm_bind/unbind() as it is done > > in dpu_drm_probe(). > > * Some trivial tweaks. > > > > v4->v5: > > * Rebase up onto the latest drm-misc-next branch and remove the hook to > > drm_atomic_helper_legacy_gamma_set(), because it was dropped by the newly > > landed commit 'drm: automatic legacy gamma support'. > > * Remove a redundant blank line from dpu_plane_atomic_update(). > > > > v3->v4: > > * No change. > > > > v2->v3: > > * Fix build warnings Reported-by: kernel test robot . > > * Drop build dependency on IMX_SCU, as dummy SCU functions have been added > > in > > header files by the patch 'firmware: imx: add dummy functions' which has > > landed in linux-next/master branch. > > > > v1->v2: > > * Add compatible for i.MX8qm DPU, as this is tested with i.MX8qm LVDS > > displays. > > (Laurentiu) > > * Fix PRG burst size and stride. (Laurentiu) > > * Put 'ports' OF node to fix the bail-out logic in dpu_drm_probe(). > > (Laurentiu) > > > > drivers/gpu/drm/imx/Kconfig |1 + > > drivers/gpu/drm/imx/Makefile |1 + > > drivers/gpu/drm/imx/dpu/Kconfig | 10 + > > drivers/gpu/drm/imx/dpu/Makefile | 10 + > > drivers/gpu/drm/imx/dpu/dpu-constframe.c | 171 + > > drivers/gpu/drm/imx/dpu/dpu-core.c| 1094 > > + > > drivers/gpu/drm/imx/dpu/dpu-crtc.c| 967 + > > drivers/gpu/drm/imx/dpu/dpu-crtc.h| 66 ++ > > drivers/gpu/drm/imx/dpu/dpu-disengcfg.c | 117 +++ > > drivers/gpu/drm/imx/dpu/dpu-dprc.c| 718 +++ > > drivers/gpu/drm/imx/dpu/dpu-dprc.h| 40 ++ > > drivers/gpu/drm/imx/dpu/dpu-drv.c | 292 > > drivers/gpu/drm/imx/dpu/dpu-drv.h | 28 + > > drivers/gpu/drm/imx/dpu/dpu-extdst.c | 299 > > drivers/gpu/drm/imx/dpu/dpu-fetchdecode.c | 294 > > drivers/gpu/drm/imx/dpu/dpu-fetcheco.c| 224 ++ > > drivers/gpu/drm/imx/dpu/dpu-fetchlayer.c | 154 > > drivers/gpu/drm/imx/dpu/dpu-fetchunit.c | 609 > > drivers/gpu/drm/imx/dpu/dpu-fetchunit.h | 191 + > > drivers/gpu/drm/imx/dpu/dpu-fetchwarp.c | 250 +++ > > drivers/gpu/drm/imx/dpu/dpu-framegen.c| 395 +++ > > drivers/gpu/drm/imx/dpu/dpu-gammacor.c| 223 ++ > > drivers/gpu/drm/imx/dpu/dpu-hscaler.c | 275 > > drivers/gpu/drm/imx/dpu/dpu-kms.c | 540 ++ > > drivers/gpu/drm/imx/dpu/dpu-kms.h | 23 + > > drivers/gpu/drm/imx/dpu/dpu-layerblend.c | 348 + > > drivers/gpu/drm/imx/dpu/dpu-plane.c | 799 + > > drivers/gpu/drm/imx/dpu/dpu-plane.h | 56 ++ > > drivers/gpu/drm/imx/dpu/dpu-prg.c | 433 > > drivers/gpu/drm/imx/dpu/dpu-prg.h | 45 ++ > > drivers/gpu/drm/imx/dpu/dpu-prv.h | 233 ++ > > drivers/gpu/drm/imx/dpu/dpu-tcon.c| 250 +++ > > drivers/gpu/drm/imx/dpu/dpu-vscaler.c | 308 > > drivers/gpu/drm/imx/dpu/dpu.h | 385 ++ > > 34 files changed, 9849 insertions(+) > > create mode 100644 drivers/gpu/drm/imx/dpu/Kconfig > >
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
On 16/01/21, Fabio Estevam wrote: > On Sat, Jan 16, 2021 at 9:49 AM Oliver Graute wrote: > > > > power-supply = <_touch_3v3> is not correct, as the reg_touch_3v3 > > > does not power the LCD. > > > > yes, but how is the LCD correctly powered then? > > J4 is powered by VCC_5V and VCC_3V#. > > > [7.795980] pwm-backlight backlight: supply power not found, using dummy > > regulator > > [7.804436] OF: /backlight: #pwm-cells = 3 found -1 > > [7.806563] of_pwm_get(): can't parse "pwms" property > > [7.812026] pwm-backlight backlight: unable to request PWM > > [7.822929] pwm-backlight: probe of backlight failed with error -22 > > You need to fix this. > > > [7.876831] imx-sdma 20ec000.sdma: Direct firmware load for > > imx/sdma/sdma-imx6q.bin failed with error -2 > > [7.884231] imx-sdma 20ec000.sdma: Falling back to sysfs fallback for: > > imx/sdma/sdma-imx6q.bin > > [7.916013] printk: console [ttymxc0] enabled > > [7.916013] printk: console [ttymxc0] enabled > > [7.922351] printk: bootconsole [ec_imx6q0] disabled > > [7.922351] printk: bootconsole [ec_imx6q0] disabled > > [7.952397] 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 68, > > base_baud = 500) is a IMX > > [7.970794] 21ec000.serial: ttymxc2 at MMIO 0x21ec000 (irq = 69, > > base_baud = 500) is a IMX > > [8.033015] [ cut here ] > > [8.037826] WARNING: CPU: 0 PID: 1 at > > ../drivers/gpu/drm/panel/panel-simple.c:577 panel_simple_probe+0x5dc/0x6b8 > > And this too > > > [8.846104] imx6ul-pinctrl 20e.pinctrl: pin MX6UL_PAD_NAND_CE0_B > > already requested by regulator-gpio; cannot claim for > > 1806000.nand-controller > > [8.859641] imx6ul-pinctrl 20e.pinctrl: pin-107 > > (1806000.nand-controller) status -22 > > [8.867851] imx6ul-pinctrl 20e.pinctrl: could not request pin 107 > > (MX6UL_PAD_NAND_CE0_B) from group gpminandgrp on device 20e.pinctrl > > [8.880930] gpmi-nand 1806000.nand-controller: Error applying setting, > > reverse things back > > [8.889726] gpmi-nand: probe of 1806000.nand-controller failed with > > error -22 > > And this pin conflict too. Ok I fixed the pin conflict with regulator-gpio and added a 5V regulator node in my dts file. Now the display is working fine! I'll post the dts files soon and check if there is something to improve for this patch. Many thanks for your help, Oliver ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/kms: Make a lock_class_key for each crtc mutex
Lockdep complains about an AA deadlock when rebooting the device.
WARNING: possible recursive locking detected
5.4.91 #1 Not tainted
reboot/5213 is trying to acquire lock:
ff80d13391b0 (>commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4
but task is already holding lock:
ff80d1339110 (>commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(>commit_lock[i]);
lock(>commit_lock[i]);
*** DEADLOCK ***
May be due to missing lock nesting notation
6 locks held by reboot/5213:
__arm64_sys_reboot+0x148/0x2a0
device_shutdown+0x10c/0x2c4
drm_atomic_helper_shutdown+0x48/0xfc
modeset_lock+0x120/0x24c
lock_crtcs+0x60/0xa4
stack backtrace:
CPU: 4 PID: 5213 Comm: reboot Not tainted 5.4.91 #1
Hardware name: Google Pompom (rev1) with LTE (DT)
Call trace:
dump_backtrace+0x0/0x1dc
show_stack+0x24/0x30
dump_stack+0xfc/0x1a8
__lock_acquire+0xcd0/0x22b8
lock_acquire+0x1ec/0x240
__mutex_lock_common+0xe0/0xc84
mutex_lock_nested+0x48/0x58
lock_crtcs+0x60/0xa4
msm_atomic_commit_tail+0x348/0x570
commit_tail+0xdc/0x178
drm_atomic_helper_commit+0x160/0x168
drm_atomic_commit+0x68/0x80
This is because lockdep thinks all the locks taken in lock_crtcs() are
the same lock, when they actually aren't. That's because we call
mutex_init() in msm_kms_init() and that assigns on static key for every
lock initialized in this loop. Let's allocate a dynamic number of
lock_class_keys and assign them to each lock so that lockdep can figure
out an AA deadlock isn't possible here.
Fixes: b3d91800d9ac ("drm/msm: Fix race condition in msm driver with async
layer updates")
Cc: Krishna Manikandan
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/msm_kms.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index d8151a89e163..4735251a394d 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -157,6 +157,7 @@ struct msm_kms {
* from the crtc's pending_timer close to end of the frame:
*/
struct mutex commit_lock[MAX_CRTCS];
+ struct lock_class_key commit_lock_keys[MAX_CRTCS];
unsigned pending_crtc_mask;
struct msm_pending_timer pending_timers[MAX_CRTCS];
};
@@ -166,8 +167,11 @@ static inline int msm_kms_init(struct msm_kms *kms,
{
unsigned i, ret;
- for (i = 0; i < ARRAY_SIZE(kms->commit_lock); i++)
- mutex_init(>commit_lock[i]);
+ for (i = 0; i < ARRAY_SIZE(kms->commit_lock); i++) {
+ lockdep_register_key(>commit_lock_keys[i]);
+ __mutex_init(>commit_lock[i], ">commit_lock[i]",
+>commit_lock_keys[i]);
+ }
kms->funcs = funcs;
base-commit: 19c329f6808995b142b3966301f217c831e7cf31
--
https://chromeos.dev
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3, 05/15] drm/mediatek: add component POSTMASK
On Mon, Jan 11, 2021 at 3:44 PM Yongqiang Niu
wrote:
>
> This patch add component POSTMASK,
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/Makefile| 1 +
> drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 160
> +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> 6 files changed, 168 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_postmask.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index 17a08e2..ce5ad59 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -3,6 +3,7 @@
> mediatek-drm-y := mtk_disp_color.o \
> mtk_disp_gamma.o \
> mtk_disp_ovl.o \
> + mtk_disp_postmask.o \
> mtk_disp_rdma.o \
> mtk_drm_crtc.o \
> mtk_drm_ddp.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> new file mode 100644
> index 000..736224c
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> @@ -0,0 +1,160 @@
> +/*
> + * SPDX-License-Identifier:
> + *
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mtk_drm_crtc.h"
> +#include "mtk_drm_ddp_comp.h"
> +
> +#define DISP_POSTMASK_EN 0x
> +#define POSTMASK_ENBIT(0)
> +#define DISP_POSTMASK_CFG 0x0020
> +#define POSTMASK_RELAY_MODEBIT(0)
> +#define DISP_POSTMASK_SIZE 0x0030
> +
> +struct mtk_disp_postmask_data {
> + u32 reserved;
> +};
> +
Will there be more data and config for different soc in the future? If
not, it can be put in mtk_drm_ddp_comp.c and use struct
mtk_ddp_comp_dev, like ddp_dither or ddp_aal.
> +/**
> + * struct mtk_disp_postmask - DISP_postmask driver structure
> + * @ddp_comp - structure containing type enum and hardware resources
> + * @crtc - associated crtc to report irq events to
> + */
> +struct mtk_disp_postmask {
> + struct mtk_ddp_comp ddp_comp;
> + const struct mtk_disp_postmask_data *data;
> +};
> +
> +static inline struct mtk_disp_postmask *comp_to_postmask(struct mtk_ddp_comp
> *comp)
> +{
> + return container_of(comp, struct mtk_disp_postmask, ddp_comp);
> +}
> +
> +static void mtk_postmask_config(struct mtk_ddp_comp *comp, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> + mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_POSTMASK_SIZE);
> + mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, comp, DISP_POSTMASK_CFG);
> +}
> +
> +static void mtk_postmask_start(struct mtk_ddp_comp *comp)
> +{
> + writel(POSTMASK_EN, comp->regs + DISP_POSTMASK_EN);
> +}
> +
> +static void mtk_postmask_stop(struct mtk_ddp_comp *comp)
> +{
> + writel_relaxed(0x0, comp->regs + DISP_POSTMASK_EN);
> +}
> +
> +static const struct mtk_ddp_comp_funcs mtk_disp_postmask_funcs = {
> + .config = mtk_postmask_config,
> + .start = mtk_postmask_start,
> + .stop = mtk_postmask_stop,
> +};
> +
> +static int mtk_disp_postmask_bind(struct device *dev, struct device *master,
> void *data)
> +{
> + struct mtk_disp_postmask *priv = dev_get_drvdata(dev);
> + struct drm_device *drm_dev = data;
> + int ret;
> +
> + ret = mtk_ddp_comp_register(drm_dev, >ddp_comp);
> + if (ret < 0) {
> + dev_err(dev, "Failed to register component %pOF: %d\n",
> + dev->of_node, ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void mtk_disp_postmask_unbind(struct device *dev, struct device
> *master,
> + void *data)
> +{
> + struct mtk_disp_postmask *priv = dev_get_drvdata(dev);
> + struct drm_device *drm_dev = data;
> +
> + mtk_ddp_comp_unregister(drm_dev, >ddp_comp);
> +}
> +
> +static const struct component_ops mtk_disp_postmask_component_ops = {
> + .bind = mtk_disp_postmask_bind,
> + .unbind = mtk_disp_postmask_unbind,
> +};
> +
> +static int mtk_disp_postmask_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct mtk_disp_postmask *priv;
> + int comp_id;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_POSTMASK);
> + if (comp_id <
Re: [PATCH v2 06/11] drm: Use state helper instead of plane state pointer in atomic_check
Hi Ville,
On Fri, Jan 22, 2021 at 02:07:22PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 21, 2021 at 05:35:31PM +0100, Maxime Ripard wrote:
> > Many drivers reference the plane->state pointer in order to get the
> > current plane state in their atomic_check hook, which would be the old
> > plane state in the global atomic state since _swap_state hasn't happened
> > when atomic_check is run.
> >
> > Use the drm_atomic_get_old_plane_state helper to get that state to make
> > it more obvious.
> >
> > This was made using the coccinelle script below:
> >
> > @ plane_atomic_func @
> > identifier helpers;
> > identifier func;
> > @@
> >
> > static struct drm_plane_helper_funcs helpers = {
> > ...,
> > .atomic_check = func,
> > ...,
> > };
> >
> > @ replaces_old_state @
> > identifier plane_atomic_func.func;
> > identifier plane, state, plane_state;
> > @@
> >
> > func(struct drm_plane *plane, struct drm_atomic_state *state) {
> > ...
> > - struct drm_plane_state *plane_state = plane->state;
> > + struct drm_plane_state *plane_state =
> > drm_atomic_get_old_plane_state(state, plane);
> > ...
> > }
> >
> > @@
> > identifier plane_atomic_func.func;
> > identifier plane, state, plane_state;
> > @@
> >
> > func(struct drm_plane *plane, struct drm_atomic_state *state) {
> > struct drm_plane_state *plane_state =
> > drm_atomic_get_old_plane_state(state, plane);
> > ...
> > - plane->state
> > + plane_state
> > ...
>
> We don't need the <... ...> style here? It's been a while since
> I did any serious cocci so I'm getting a bit rusty on the details...
You're right, I've changed it and caught some more users (ingenic). I'll update
it.
> Otherwise looks great
> Reviewed-by: Ville Syrjälä
Thanks!
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/vc4: Correct POS1_SCL for hvs5
On Sat, Jan 23, 2021 at 08:14:03PM +0900, Ryutaroh Matsumoto wrote:
> From: Lucas Nussbaum
> Subject: Re: [PATCH 2/2] drm/vc4: Correct POS1_SCL for hvs5
> Date: Sat, 23 Jan 2021 09:05:48 +0100
>
> > On 21/01/21 at 11:57 +0100, Maxime Ripard wrote:
> >> From: Dom Cobley
> >>
> >> Fixes failure with 4096x1080 resolutions
> >>
> >> [ 284.315379] WARNING: CPU: 1 PID: 901 at
> >> drivers/gpu/drm/vc4/vc4_plane.c:981 vc4_plane_mode_set+0x1374/0x13c4
> >> [ 284.315385] Modules linked in: ir_rc5_decoder rpivid_hevc(C)
> >> bcm2835_codec(C) bcm2835_isp(C) bcm2835_mmal_vchiq(C) bcm2835_gpiomem
> >> v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2
> >> videobuf2_common videodev mc cdc_acm xpad ir_rc6_decoder rc_rc6_mce
> >> gpio_ir_recv fuse
> >> [ 284.315509] CPU: 1 PID: 901 Comm: kodi.bin Tainted: G C
> >> 5.10.7 #1
> >> [ 284.315514] Hardware name: BCM2711
> >> [ 284.315518] Backtrace:
> >> [ 284.315533] [] (dump_backtrace) from []
> >> (show_stack+0x20/0x24)
> >> [ 284.315540] r7: r6: r5:6813 r4:c18ecf1c
> >> [ 284.315549] [] (show_stack) from []
> >> (dump_stack+0xc4/0xf0)
> >> [ 284.315558] [] (dump_stack) from []
> >> (__warn+0xfc/0x158)
> >> [ 284.315564] r9: r8:0009 r7:03d5 r6:0009
> >> r5:c08cc7dc r4:c0fd09b8
> >> [ 284.315572] [] (__warn) from []
> >> (warn_slowpath_fmt+0x74/0xe4)
> >> [ 284.315577] r7:c08cc7dc r6:03d5 r5:c0fd09b8 r4:
> >> [ 284.315584] [] (warn_slowpath_fmt) from []
> >> (vc4_plane_mode_set+0x1374/0x13c4)
> >> [ 284.315589] r8: r7: r6:1000 r5:c404c600 r4:c2e34600
> >> [ 284.315596] [] (vc4_plane_mode_set) from []
> >> (vc4_plane_atomic_check+0x40/0x1c0)
> >> [ 284.315601] r10:0001 r9:c2e34600 r8:c0e67068 r7:c0fc44e0
> >> r6:c2ce3640 r5:c3d636c0
> >> [ 284.315605] r4:c2e34600
> >> [ 284.315614] [] (vc4_plane_atomic_check) from []
> >> (drm_atomic_helper_check_planes+0xec/0x1ec)
> >> [ 284.315620] r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640
> >> r5:c3d636c0 r4:0006
> >> [ 284.315627] [] (drm_atomic_helper_check_planes) from
> >> [] (drm_atomic_helper_check+0x54/0x9c)
> >> [ 284.315633] r9:c2e35400 r8:0006 r7: r6:c2ba7800
> >> r5:c3d636c0 r4:
> >> [ 284.315641] [] (drm_atomic_helper_check) from []
> >> (vc4_atomic_check+0x25c/0x454)
> >> [ 284.315645] r7: r6:c2ba7800 r5:0001 r4:c3d636c0
> >> [ 284.315652] [] (vc4_atomic_check) from []
> >> (drm_atomic_check_only+0x5cc/0x7e0)
> >> [ 284.315658] r10:c404c6c8 r9: r8:c472c480 r7:0003
> >> r6:c3d636c0 r5:
> >> [ 284.315662] r4:003c r3:c08b7a4c
> >> [ 284.315670] [] (drm_atomic_check_only) from []
> >> (drm_mode_atomic_ioctl+0x758/0xa7c)
> >> [ 284.315675] r10:c3d46000 r9:c3d636c0 r8:c2ce8a70 r7:027e3a54
> >> r6:0043 r5:c1fbb800
> >> [ 284.315679] r4:0281a858
> >> [ 284.315688] [] (drm_mode_atomic_ioctl) from []
> >> (drm_ioctl_kernel+0xc4/0x108)
> >> [ 284.315693] r10:c03864bc r9:c1fbb800 r8:c3d47e64 r7:c089b308
> >> r6:0002 r5:c2ba7800
> >> [ 284.315697] r4:
> >> [ 284.315705] [] (drm_ioctl_kernel) from []
> >> (drm_ioctl+0x1e8/0x3a0)
> >> [ 284.315711] r9:c1fbb800 r8:00bc r7:c3d47e64 r6:0038
> >> r5:c0e59570 r4:0038
> >> [ 284.315719] [] (drm_ioctl) from []
> >> (sys_ioctl+0x35c/0x914)
> >> [ 284.315724] r10:c2d08200 r9: r8:c36fa300 r7:befdd870
> >> r6:c03864bc r5:c36fa301
> >> [ 284.315728] r4:c03864bc
> >> [ 284.315735] [] (sys_ioctl) from []
> >> (ret_fast_syscall+0x0/0x28)
> >> [ 284.315739] Exception stack(0xc3d47fa8 to 0xc3d47ff0)
> >> [ 284.315745] 7fa0: 027eb750 befdd870 c03864bc
> >> befdd870
> >> [ 284.315750] 7fc0: 027eb750 befdd870 c03864bc 0036 027e3948 0281a640
> >> 0281a850 027e3a50
> >> [ 284.315756] 7fe0: b4b64100 befdd844 b4b5ba2c b49c994c
> >> [ 284.315762] r10:0036 r9:c3d46000 r8:c0200204 r7:0036
> >> r6:c03864bc r5:befdd870
> >> [ 284.315765] r4:027eb750
> >>
> >> Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
> >> Signed-off-by: Dom Cobley
> >> Signed-off-by: Maxime Ripard
> >
> > Tested-By: Lucas Nussbaum
>
> Tested-By: Ryutaroh Matsumoto
Applied both patches, thanks for testing!
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/bridge: anx7625: add MIPI DPI input feature support
Add MIPI rx DPI input support
Reported-by: kernel test robot
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 326 --
drivers/gpu/drm/bridge/analogix/anx7625.h | 20 +-
2 files changed, 285 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 04536cc..c7fc92b 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -150,18 +150,18 @@ static int anx7625_write_and(struct anx7625_data *ctx,
return anx7625_reg_write(ctx, client, offset, (val & (mask)));
}
-static int anx7625_write_and_or(struct anx7625_data *ctx,
- struct i2c_client *client,
- u8 offset, u8 and_mask, u8 or_mask)
+static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
{
- int val;
+ int i, ret;
- val = anx7625_reg_read(ctx, client, offset);
- if (val < 0)
- return val;
+ ret = anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CONTROL_REGISTER, 0x80);
+ for (i = 0; i < 13; i++)
+ ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
+VIDEO_BIT_MATRIX_12 + i,
+0x18 + i);
- return anx7625_reg_write(ctx, client,
-offset, (val & and_mask) | (or_mask));
+ return ret;
}
static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
@@ -195,6 +195,60 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
return 0;
}
+static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
+u8 addrh, u8 addrm, u8 addrl,
+u8 len, u8 *buf)
+{
+ struct device *dev = >client->dev;
+ int ret;
+ u8 cmd;
+
+ if (len > MAX_DPCD_BUFFER_SIZE) {
+ DRM_DEV_ERROR(dev, "exceed aux buffer len.\n");
+ return -EINVAL;
+ }
+
+ cmd = ((len - 1) << 4) | 0x09;
+
+ /* Set command and length */
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_COMMAND, cmd);
+
+ /* Set aux access address */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_7_0, addrl);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_15_8, addrm);
+ ret |= anx7625_write_and(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_19_16, addrh);
+
+ /* Enable aux access */
+ ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
+
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "cannot access aux related register.\n");
+ return -EIO;
+ }
+
+ usleep_range(2000, 2100);
+
+ ret = wait_aux_op_finish(ctx);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "aux IO error: wait aux op finish.\n");
+ return ret;
+ }
+
+ ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_BUFF_START, len, buf);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "read dpcd register failed\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int anx7625_video_mute_control(struct anx7625_data *ctx,
u8 status)
{
@@ -219,38 +273,6 @@ static int anx7625_video_mute_control(struct anx7625_data
*ctx,
return ret;
}
-static int anx7625_config_audio_input(struct anx7625_data *ctx)
-{
- struct device *dev = >client->dev;
- int ret;
-
- /* Channel num */
- ret = anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_6, I2S_CH_2 << 5);
-
- /* FS */
- ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_4,
- 0xf0, AUDIO_FS_48K);
- /* Word length */
- ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_5,
- 0xf0, AUDIO_W_LEN_24_24MAX);
- /* I2S */
- ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_6, I2S_SLAVE_MODE);
- ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
-AUDIO_CONTROL_REGISTER, ~TDM_TIMING_MODE);
- /* Audio change flag */
- ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
- AP_AV_STATUS, AP_AUDIO_CHG);
-
- if (ret < 0)
- DRM_DEV_ERROR(dev, "fail to config audio.\n");
-
- return ret;
-}
-
/* Reduction
[PATCH v7 2/6] dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v6->v7:
* No change.
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
new file mode 100644
index ..3ff46e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-prg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Gasket
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Prefetch Resolve Gasket (PRG) is a gasket interface between
+ RTRAM controller and Display Controller. The main function is to convert
+ the AXI interface to the RTRAM interface, which includes re-mapping the
+ ARADDR to a RTRAM address.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qxp-prg
+ - fsl,imx8qm-prg
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: rtram clock
+ - description: apb clock
+
+ clock-names:
+items:
+ - const: rtram
+ - const: apb
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+prg@5604 {
+compatible = "fsl,imx8qxp-prg";
+reg = <0x5604 0x1>;
+clocks = <_prg0_lpcg IMX_LPCG_CLK_0>,
+ <_prg0_lpcg IMX_LPCG_CLK_4>;
+clock-names = "rtram", "apb";
+power-domains = < IMX_SC_R_DC_0>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
This patch adds bindings for i.MX8qxp/qm Display Processing Unit. Reviewed-by: Rob Herring Signed-off-by: Liu Ying --- v6->v7: * Add Rob's R-b tag back. v5->v6: * Use graph schema. So, drop Rob's R-b tag as review is needed. v4->v5: * No change. v3->v4: * Improve compatible property by using enum instead of oneOf+const. (Rob) * Add Rob's R-b tag. v2->v3: * No change. v1->v2: * Fix yamllint warnings. * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the display controller subsystem spec does say that they exist. * Use new dt binding way to add clocks in the example. * Trivial tweaks for the example. .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 387 + 1 file changed, 387 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml new file mode 100644 index ..9da9560 --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml @@ -0,0 +1,387 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8qm/qxp Display Processing Unit + +maintainers: + - Liu Ying + +description: | + The Freescale i.MX8qm/qxp Display Processing Unit(DPU) is comprised of two + main components that include a blit engine for 2D graphics accelerations + and a display controller for display output processing, as well as a command + sequencer. + +properties: + compatible: +enum: + - fsl,imx8qxp-dpu + - fsl,imx8qm-dpu + + reg: +maxItems: 1 + + interrupts: +items: + - description: | + store9 shadow load interrupt(blit engine) + - description: | + store9 frame complete interrupt(blit engine) + - description: | + store9 sequence complete interrupt(blit engine) + - description: | + extdst0 shadow load interrupt + (display controller, content stream 0) + - description: | + extdst0 frame complete interrupt + (display controller, content stream 0) + - description: | + extdst0 sequence complete interrupt + (display controller, content stream 0) + - description: | + extdst4 shadow load interrupt + (display controller, safety stream 0) + - description: | + extdst4 frame complete interrupt + (display controller, safety stream 0) + - description: | + extdst4 sequence complete interrupt + (display controller, safety stream 0) + - description: | + extdst1 shadow load interrupt + (display controller, content stream 1) + - description: | + extdst1 frame complete interrupt + (display controller, content stream 1) + - description: | + extdst1 sequence complete interrupt + (display controller, content stream 1) + - description: | + extdst5 shadow load interrupt + (display controller, safety stream 1) + - description: | + extdst5 frame complete interrupt + (display controller, safety stream 1) + - description: | + extdst5 sequence complete interrupt + (display controller, safety stream 1) + - description: | + disengcfg0 shadow load interrupt + (display controller, display stream 0) + - description: | + disengcfg0 frame complete interrupt + (display controller, display stream 0) + - description: | + disengcfg0 sequence complete interrupt + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt0 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt1 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt2 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt3 + (display controller, display stream 0) + - description: | + signature0 shadow load interrupt + (display controller, display stream 0) + - description: | + signature0 measurement valid interrupt + (display controller, display stream 0) + - description: | + signature0 error condition interrupt + (display controller, display stream 0) + - description: | + disengcfg1 shadow load interrupt + (display controller, display stream 1) + - description: | + disengcfg1 frame complete interrupt + (display controller, display stream 1) + - description: | + disengcfg1 sequence complete
Re: [PATCH] ARM: multi_v7_defconfig: add STM32 CEC support
Hi Yannick On 1/15/21 3:32 PM, Yannick Fertre wrote: Enable CEC support for STMicroelectronics as loadable module. Signed-off-by: Yannick Fertre --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index c5f25710fedc..05cc0607a9ad 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -656,6 +656,7 @@ CONFIG_V4L_TEST_DRIVERS=y CONFIG_VIDEO_VIVID=m CONFIG_CEC_PLATFORM_DRIVERS=y CONFIG_CEC_SAMSUNG_S5P=m +CONFIG_CEC_STM32=m CONFIG_VIDEO_ADV7180=m CONFIG_VIDEO_ADV7604=m CONFIG_VIDEO_ADV7604_CEC=y Applied on stm32-next. Thanks. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 4/5] drm/tegra: dc: Support memory bandwidth management
28.12.2020 18:49, Dmitry Osipenko пишет: > Display controller (DC) performs isochronous memory transfers, and thus, > has a requirement for a minimum memory bandwidth that shall be fulfilled, > otherwise framebuffer data can't be fetched fast enough and this results > in a DC's data-FIFO underflow that follows by a visual corruption. > > The Memory Controller drivers provide facility for memory bandwidth > management via interconnect API. Let's wire up the interconnect API > support to the DC driver in order to fix the distorted display output > on T30 Ouya, T124 TK1 and other Tegra devices. > > Tested-by: Peter Geis > Tested-by: Nicolas Chauvet > Signed-off-by: Dmitry Osipenko > --- Thierry, I'm looking forward to yours review. Only DRM patches are left unmerged yet in this series. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm/panel-simple: Add N116BCA-EA1
Quoting Douglas Anderson (2021-01-15 14:44:20) > This panel is quite similar to the similarly named N116BGE panel (the > nominal timings are, in fact identical). However, let's add a new > entry because the full range of clocks listed for N116BGE aren't > supported for N116BCA-EA1, at least according to the datasheet. > > Signed-off-by: Douglas Anderson > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/11] drm: Rename plane->state variables in atomic update and disable
Hi Ville,
On Fri, Jan 22, 2021 at 02:15:07PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 21, 2021 at 05:35:33PM +0100, Maxime Ripard wrote:
> > Some drivers are storing the plane->state pointer in atomic_update and
> > atomic_disable in a variable simply called state, while the state passed
> > as an argument is called old_state.
> >
> > In order to ease subsequent reworks and to avoid confusing or
> > inconsistent names, let's rename those variables to new_state.
> >
> > This was done using the following coccinelle script, plus some manual
> > changes for mtk and tegra.
> >
> > @ plane_atomic_func @
> > identifier helpers;
> > identifier func;
> > @@
> >
> > (
> > static const struct drm_plane_helper_funcs helpers = {
> > ...,
> > .atomic_disable = func,
> > ...,
> > };
> > |
> > static const struct drm_plane_helper_funcs helpers = {
> > ...,
> > .atomic_update = func,
> > ...,
> > };
> > )
> >
> > @ moves_new_state_old_state @
> > identifier plane_atomic_func.func;
> > identifier plane;
> > symbol old_state;
> > symbol state;
> > @@
> >
> > func(struct drm_plane *plane, struct drm_plane_state *old_state)
> > {
> > ...
> > - struct drm_plane_state *state = plane->state;
> > + struct drm_plane_state *new_state = plane->state;
> > ...
> > }
> >
> > @ depends on moves_new_state_old_state @
> > identifier plane_atomic_func.func;
> > identifier plane;
> > identifier old_state;
> > symbol state;
> > @@
> >
> > func(struct drm_plane *plane, struct drm_plane_state *old_state)
> > {
> > <...
> > - state
> > + new_state
> > ...>
>
> Was going to say that this migh eat something else, but I guess
> the dependency prevents that?
Yeah, the dependency takes care of this
> Another way to avoid that I suppose would be to declare 'state'
> as
> symbol moves_new_state_old_state.state;
>
> That would probably make the intent a bit more obvious, even with
> the dependency. Or does a dependency somehow automagically imply
> that?
I'm not sure if it does, but it's a symbol here not an identifier or an
expression, so here moves_new_state_old_state.state would always resolve
to state (and only state) anyway
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/kms: Make a lock_class_key for each crtc mutex
Lockdep complains about an AA deadlock when rebooting the device.
WARNING: possible recursive locking detected
5.4.91 #1 Not tainted
reboot/5213 is trying to acquire lock:
ff80d13391b0 (>commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4
but task is already holding lock:
ff80d1339110 (>commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(>commit_lock[i]);
lock(>commit_lock[i]);
*** DEADLOCK ***
May be due to missing lock nesting notation
6 locks held by reboot/5213:
__arm64_sys_reboot+0x148/0x2a0
device_shutdown+0x10c/0x2c4
drm_atomic_helper_shutdown+0x48/0xfc
modeset_lock+0x120/0x24c
lock_crtcs+0x60/0xa4
stack backtrace:
CPU: 4 PID: 5213 Comm: reboot Not tainted 5.4.91 #1
Hardware name: Google Pompom (rev1) with LTE (DT)
Call trace:
dump_backtrace+0x0/0x1dc
show_stack+0x24/0x30
dump_stack+0xfc/0x1a8
__lock_acquire+0xcd0/0x22b8
lock_acquire+0x1ec/0x240
__mutex_lock_common+0xe0/0xc84
mutex_lock_nested+0x48/0x58
lock_crtcs+0x60/0xa4
msm_atomic_commit_tail+0x348/0x570
commit_tail+0xdc/0x178
drm_atomic_helper_commit+0x160/0x168
drm_atomic_commit+0x68/0x80
This is because lockdep thinks all the locks taken in lock_crtcs() are
the same lock, when they actually aren't. That's because we call
mutex_init() in msm_kms_init() and that assigns on static key for every
lock initialized in this loop. Let's allocate a dynamic number of
lock_class_keys and assign them to each lock so that lockdep can figure
out an AA deadlock isn't possible here.
Fixes: b3d91800d9ac ("drm/msm: Fix race condition in msm driver with async
layer updates")
Cc: Krishna Manikandan
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/msm_kms.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index d8151a89e163..4735251a394d 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -157,6 +157,7 @@ struct msm_kms {
* from the crtc's pending_timer close to end of the frame:
*/
struct mutex commit_lock[MAX_CRTCS];
+ struct lock_class_key commit_lock_keys[MAX_CRTCS];
unsigned pending_crtc_mask;
struct msm_pending_timer pending_timers[MAX_CRTCS];
};
@@ -166,8 +167,11 @@ static inline int msm_kms_init(struct msm_kms *kms,
{
unsigned i, ret;
- for (i = 0; i < ARRAY_SIZE(kms->commit_lock); i++)
- mutex_init(>commit_lock[i]);
+ for (i = 0; i < ARRAY_SIZE(kms->commit_lock); i++) {
+ lockdep_register_key(>commit_lock_keys[i]);
+ __mutex_init(>commit_lock[i], ">commit_lock[i]",
+>commit_lock_keys[i]);
+ }
kms->funcs = funcs;
base-commit: 19c329f6808995b142b3966301f217c831e7cf31
--
https://chromeos.dev
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/15] drm/vc4: hdmi: Add CEC support for the BCM2711
Hi, On Mon, 2021-01-11 at 15:22 +0100, Maxime Ripard wrote: > Hi, > > Here's a series introducing the CEC support for the BCM2711 found on the > RaspberryPi4. > > The BCM2711 HDMI controller uses a similar layout for the CEC registers, the > main difference being that the interrupt handling part is now shared between > both HDMI controllers. > > This series is mainly about fixing a couple of bugs, reworking the driver to > support having two different interrupts, one for each direction, provided by > an > external irqchip, and enables the irqchip driver for the controller we have. > > This has been tested on an RPi3 and RPi4, but requires the latest firmware. > It's is based on the 10 and 12 bpc series. I applied patches #1 and #14 for-next. I'm waiting on Hans' testing for #15. Regards, Nicolas signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: replace drm_modeset_lock_all() in drm_client_modeset_dpms_legacy()
This patch helps complete Use DRM_MODESET_LOCK_ALL* helpers instead of
boilerplate todo in Documentation/gpu/todo.rst
Signed-off-by: Joseph Schulte
---
drivers/gpu/drm/drm_client_modeset.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index b7e9e1c2564c..ced09c7c06f9 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -7,6 +7,7 @@
* Copyright (c) 2007 Dave Airlie
*/
+#include "drm/drm_modeset_lock.h"
#include
#include
#include
@@ -1181,9 +1182,11 @@ static void drm_client_modeset_dpms_legacy(struct
drm_client_dev *client, int dp
struct drm_device *dev = client->dev;
struct drm_connector *connector;
struct drm_mode_set *modeset;
+ struct drm_modeset_acquire_ctx ctx;
int j;
+ int ret;
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
drm_client_for_each_modeset(modeset, client) {
if (!modeset->crtc->enabled)
continue;
@@ -1195,7 +1198,7 @@ static void drm_client_modeset_dpms_legacy(struct
drm_client_dev *client, int dp
dev->mode_config.dpms_property, dpms_mode);
}
}
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
}
/**
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM
Hi, This is the v7 series to introduce i.MX8qm/qxp Display Processing Unit(DPU) DRM support. DPU is comprised of a blit engine for 2D graphics, a display controller and a command sequencer. Outside of DPU, optional prefetch engines can fetch data from memory prior to some DPU fetchunits of blit engine and display controller. The pre-fetchers support linear formats and Vivante GPU tile formats. Reference manual can be found at: https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM This patch set adds kernel modesetting support for the display controller part. It supports two CRTCs per display controller, several planes, prefetch engines and some properties of CRTC and plane. Currently, the registers of the controller is accessed without command sequencer involved, instead just by using CPU. DRM connectors would be created from the DPU KMS driver. If people want to try this series with i.MX8qxp, clock patches can be found at Shawn's i.MX for-next git branch, and power domain patches have already landed in 5.11-rc1. Version2 dropped the device tree patches because we'll use new dt binding way to support i.MX8qm/qxp clocks. It depends on the below series to do basic conversions for the platforms which has not landed yet: https://www.spinics.net/lists/linux-mmc/msg61965.html I've sent the below series to add downstream bridges(embedded in i.MX8qm/qxp) to support LVDS displays: https://www.spinics.net/lists/arm-kernel/msg868239.html Patch 1 ~ 3 add dt-bindings for DPU and prefetch engines. Patch 4 is a minor improvement of a macro to suppress warning as the KMS driver uses it. Patch 5 introduces the DPU DRM support. Patch 6 updates MAINTAINERS. Welcome comments, thanks. v6->v7: * Fix return value of dpu_get_irqs() if platform_get_irq() fails. (Laurentiu) * Use the function array dpu_irq_handler[] to store individual DPU irq handlers. (Laurentiu) * Call get/put() hooks directly to get/put DPU fetchunits for DPU plane groups. (Laurentiu) * Shorten the names of individual DPU irq handlers by using DPU unit abbrev names to make writing dpu_irq_handler[] easier. * Add Rob's R-b tag back on DPU dt-binding patch as change in v6 was reviewed. v5->v6: * Use graph schema in the DPU dt-binding. * Do not use macros where possible in the DPU DRM driver. (Laurentiu) * Break dpu_plane_atomic_check() into some smaller functions. (Laurentiu) * Address some minor comments from Laurentiu on the DPU DRM driver. * Add dpu_crtc_err() helper marco in the DPU DRM driver to tell dmesg which CRTC generates error. * Drop calling dev_set_drvdata() from dpu_drm_bind/unbind() in the DPU DRM driver as it is done in dpu_drm_probe(). * Some trivial tweaks. v4->v5: * Rebase up onto the latest drm-misc-next branch and remove the hook to drm_atomic_helper_legacy_gamma_set() from patch 5/6, because it was dropped by the newly landed commit 'drm: automatic legacy gamma support'. * Remove a redundant blank line from dpu_plane_atomic_update() in patch 5/6. v3->v4: * Improve compatible properties in DPU and prefetch engines' dt bindings by using enum instead of oneOf+const. * Add Rob's R-b tags on dt binding patches(patch 1/6, 2/6 and 3/6). * Add Daniel's A-b tag on patch 4/6. v2->v3: * Fix DPU DRM driver build warnings which are Reported-by: kernel test robot . * Drop DPU DRM driver build dependency on IMX_SCU, as dummy SCU functions have been added in header files by the patch 'firmware: imx: add dummy functions' which has landed in linux-next/master branch. * Add a missing blank line in include/drm/drm_atomic.h. v1->v2: * Test this patch set also with i.MX8qm LVDS displays. * Drop the device tree patches because we'll use new dt binding way to support i.MX8qm/qxp clocks. This depends on a not-yet-landed patch set to do basic conversions for the platforms. * Fix dt binding yamllint warnings. * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm in DPU's dt binding documentation. * Use new dt binding way to add clocks in the dt binding examples. * Address several comments from Laurentiu on the DPU DRM patch. Liu Ying (6): dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state drm/imx: Introduce i.MX8qm/qxp DPU DRM MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver .../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++ .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 387 +++ .../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 ++ MAINTAINERS|9 + drivers/gpu/drm/imx/Kconfig|1 + drivers/gpu/drm/imx/Makefile |1 + drivers/gpu/drm/imx/dpu/Kconfig| 10 + drivers/gpu/drm/imx/dpu/Makefile | 10 +
[PATCH v3 0/3] Add MIPI rx DPI support
Hi all, this patch series implement MIPI rx DPI feature. Please help to review. This is the v3 version, any mistakes, please let me know, I'll fix it in the next series. Change history: v3: Fix Rob Herring, Dan Carpenter, Nicolas comments - Split the patch, fix not correct return data - Fix several coding format - Split DP tx swing register setting to two property - Add HDCP support vender flag - remove 'analogix,swing-setting' and 'analogix,mipi-dpi-in' property v2: Fix Rob Herring comment - Fix yamllint warnings/errors in analogix,anx7625.yaml - Fix kernel robot compile warning v1: initial MIPI rx DPI feature support Xin Ji (3): dt-bindings:drm/bridge:anx7625:add HDCP support flag and swing reg drm/bridge: anx7625: fix not correct return value drm/bridge: anx7625: add MIPI DPI input feature support .../bindings/display/bridge/analogix,anx7625.yaml | 57 +++- drivers/gpu/drm/bridge/analogix/anx7625.c | 330 + drivers/gpu/drm/bridge/analogix/anx7625.h | 20 +- 3 files changed, 341 insertions(+), 66 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 6/6] MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver
Add myself as the maintainer of the i.MX8qxp DPU DRM driver. Signed-off-by: Liu Ying --- v6->v7: * No change. v5->v6: * No change. v4->v5: * No change. v3->v4: * No change. v2->v3: * No change. v1->v2: * No change. MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9d241b8..0fe4f0cc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5892,6 +5892,15 @@ F: Documentation/devicetree/bindings/display/imx/ F: drivers/gpu/drm/imx/ F: drivers/gpu/ipu-v3/ +DRM DRIVERS FOR FREESCALE i.MX8QXP +M: Liu Ying +L: dri-devel@lists.freedesktop.org +S: Maintained +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml +F: drivers/gpu/drm/imx/dpu/ + DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets) M: Patrik Jakobsson L: dri-devel@lists.freedesktop.org -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] dt-bindings:drm/bridge:anx7625:add HDCP support flag and swing reg
Add 'bus-type' and 'data-lanes' define for port0, add HDCP support
flag and DP tx lane0 and lane1 swing register array define.
Signed-off-by: Xin Ji
---
.../bindings/display/bridge/analogix,anx7625.yaml | 57 --
1 file changed, 54 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 60585a4..3b1cbe0 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -34,23 +34,69 @@ properties:
description: used for reset chip control, RESET_N pin B7.
maxItems: 1
+ analogix,lane0-swing:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description:
+ an array of swing register setting for DP tx lane0 PHY, please don't
+ add this property, or contact vendor.
+
+ analogix,lane1-swing:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description:
+ an array of swing register setting for DP tx lane1 PHY, please don't
+ add this property, or contact vendor.
+
+ analogix,hdcp-support:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: indicate the DP tx HDCP support or not.
+
ports:
type: object
+additionalProperties: false
properties:
port@0:
type: object
description:
- Video port for MIPI DSI input.
+ Video port for MIPI input.
+
+properties:
+ endpoint:
+type: object
+additionalProperties: false
+
+# Properties described in
+# Documentation/devicetree/bindings/media/video-interfaces.txt
+properties:
+ remote-endpoint: true
+ bus-type: true
+ data-lanes: true
+
+required:
+ - remote-endpoint
+
+required:
+ - endpoint
port@1:
type: object
description:
Video port for panel or connector.
+properties:
+ endpoint:
+type: object
+additionalProperties: false
+
+required:
+ - remote-endpoint
+
+required:
+ - endpoint
+
required:
-- port@0
-- port@1
+ - port@0
+ - port@1
required:
- compatible
@@ -73,6 +119,10 @@ examples:
enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
+analogix,lane0-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77 0x5b>;
+analogix,lane1-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77 0x5b>;
+analogix,hdcp-support = <0>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -81,6 +131,7 @@ examples:
reg = <0>;
anx7625_in: endpoint {
remote-endpoint = <_dsi>;
+bus-type = <5>;
};
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: fix NULL check before some freeing functions is not needed
fixed the below warning: ./drivers/gpu/drm/msm/msm_gem.c:991:3-9: WARNING: NULL check before some freeing functions is not needed. Signed-off-by: Tian Tao --- drivers/gpu/drm/msm/msm_gem.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 45e2312..8eb2c66 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -985,8 +985,7 @@ void msm_gem_free_object(struct drm_gem_object *obj) /* Don't drop the pages for imported dmabuf, as they are not * ours, just free the array we allocated: */ - if (msm_obj->pages) - kvfree(msm_obj->pages); + kvfree(msm_obj->pages); /* dma_buf_detach() grabs resv lock, so we need to unlock * prior to drm_prime_gem_destroy -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
