[GIT PULL] fbdev fixes and updates for v6.7-rc3
Hi Linus, please pull some small fbdev fixes for 6.7-rc3. A left margin fix and code cleanups in imxfb, and one sparse warning fix in fsl-diu-fb. Thanks, Helge --- The following changes since commit ffc253263a1375a65fa6c9f62a893e9767fbebfa: Linux 6.6 (2023-10-29 16:31:08 -1000) are available in the Git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-6.7-rc3 for you to fetch changes up to 64a1aed0aa07698d12deca9b7821ea77762ff328: fbdev: mmp: Fix typo and wording in code comment (2023-11-25 09:54:41 +0100) fbdev fixes and cleanups for 6.7-rc3: - fix left margin settings in imxfb - sparse warning fix in fsl-diu-fb - lots of code cleanups in imxfb Dario Binacchi (11): fbdev: imxfb: fix left margin setting fbdev: imxfb: move PCR bitfields near their offset fbdev: imxfb: use BIT, FIELD_{GET,PREP} and GENMASK macros fbdev: imxfb: replace some magic numbers with constants fbdev: imxfb: add missing SPDX tag fbdev: imxfb: drop ftrace-like logging fbdev: imxfb: add missing spaces after ',' fbdev: imxfb: Fix style warnings relating to printk() fbdev: imxfb: use __func__ for function name fbdev: imxfb: add '*/' on a separate line in block comment fbdev: mmp: Fix typo and wording in code comment Stanislav Kinsburskii (1): fbdev: fsl-diu-fb: Fix sparse warning due to virt_to_phys() prototype change drivers/video/fbdev/fsl-diu-fb.c | 2 +- drivers/video/fbdev/imxfb.c | 179 --- drivers/video/fbdev/mmp/hw/mmp_spi.c | 2 +- 3 files changed, 104 insertions(+), 79 deletions(-)
Re: [PATCH V4 2/6] drm/panel: nv3051d: Hold panel in reset for unprepare
On Fri, Nov 17, 2023 at 02:25:32PM -0600, Chris Morgan wrote: > From: Chris Morgan > > Improve the panel's ability to restore from suspend by holding the > panel in suspend after unprepare. Now I have confirmation this does fix a bug for some users, and a somewhat serious bug at that. A user had their device suspended for approximately 12 hours and when they returned the screen was not displaying correctly, even after a reboot. This patch was recommended for troubleshooting, and confirmed to fix the problem (note, the screen did eventually "right" itself after several hours of being off prior to testing this fix). So now knowing it's really a bug as there was some question previously if there were actual issues, is there a way this can be added to the 6.6 and older supported kernels? Thanks to brooksytech for the bug report and confirmation of fixes. Might be a bit late for this, but: Tested-by: brooksytech > > Fixes: b1d39f0f4264 ("drm/panel: Add NewVision NV3051D MIPI-DSI LCD panel") > Signed-off-by: Chris Morgan > Reviewed-by: Jessica Zhang > --- > drivers/gpu/drm/panel/panel-newvision-nv3051d.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c > b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c > index 79de6c886292..c44c6945662f 100644 > --- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c > +++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c > @@ -261,6 +261,8 @@ static int panel_nv3051d_unprepare(struct drm_panel > *panel) > > usleep_range(1, 15000); > > + gpiod_set_value_cansleep(ctx->reset_gpio, 1); > + > regulator_disable(ctx->vdd); > > return 0; > -- > 2.34.1 >
[PATCH] drm/mxsfb: Switch to drmm_mode_config_init
Switch from deprecated unmanaged drm_mode_config_init() to managed drmm_mode_config_init(). No functional change. Signed-off-by: Marek Vasut --- Cc: Daniel Vetter Cc: David Airlie Cc: Fabio Estevam Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: NXP Linux Team Cc: Pengutronix Kernel Team Cc: Sascha Hauer Cc: Shawn Guo Cc: Stefan Agner Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org --- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index 3bfa369b2507e..9f746852b8ff2 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -248,7 +248,11 @@ static int mxsfb_load(struct drm_device *drm, pm_runtime_enable(drm->dev); /* Modeset init */ - drm_mode_config_init(drm); + ret = drmm_mode_config_init(drm); + if (ret) { + dev_err(drm->dev, "Failed to initialize mode config\n"); + goto err_vblank; + } ret = mxsfb_kms_init(mxsfb); if (ret < 0) { -- 2.42.0
[PATCH] drm/mxsfb: Drop extra space in request_irq args
Drop extra space, no functional change. Signed-off-by: Marek Vasut --- Cc: Daniel Vetter Cc: David Airlie Cc: Fabio Estevam Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: NXP Linux Team Cc: Pengutronix Kernel Team Cc: Sascha Hauer Cc: Shawn Guo Cc: Stefan Agner Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org --- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index 625c1bfc41733..3bfa369b2507e 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -197,7 +197,7 @@ static int mxsfb_irq_install(struct drm_device *dev, int irq) mxsfb_irq_disable(dev); - return request_irq(irq, mxsfb_irq_handler, 0, dev->driver->name, dev); + return request_irq(irq, mxsfb_irq_handler, 0, dev->driver->name, dev); } static void mxsfb_irq_uninstall(struct drm_device *dev) -- 2.42.0
Re: [PATCH v2 2/2] drm/msm/a690: Fix reg values for a690
On 25.11.2023 20:11, Rob Clark wrote: > From: Danylo Piliaiev > > KGSL doesn't support a690 so all reg values were the same as > on a660. Now we know the values and they are different from the > windows driver. > > This fixes hangs on D3D12 games and some CTS tests. > > Signed-off-by: Danylo Piliaiev > Signed-off-by: Rob Clark > --- Looks sane Acked-by: Konrad Dybcio Konrad
Re: [PATCH v2 1/2] drm/msm/a6xx: Add missing BIT(7) to REG_A6XX_UCHE_CLIENT_PF
On 25.11.2023 20:11, Rob Clark wrote: > From: Danylo Piliaiev > > Downstream always set BIT(7) > > Signed-off-by: Danylo Piliaiev > Signed-off-by: Rob Clark > --- FWIW this was only introduced in: https://git.codelinaro.org/clo/la/platform/vendor/qcom/opensource/graphics-kernel/-/commit/704575ac510a6de3ae7813a851c942d19fbcb20d (around msm-5.15 / sm8550) Konrad
[PATCH 2/2] drm/panfrost: Fix incorrect updating of current device frequency
It was noticed when setting the Panfrost's DVFS device to the performant governor, GPU frequency as reported by fdinfo had dropped to 0 permamently. There are two separate issues causing this behaviour: - Not initialising the device's current_frequency variable to its original value during device probe(). - Updating said variable in Panfrost devfreq's get_dev_status() rather than after the new OPP's frequency had been retrieved in target(), which meant the old frequency would be assigned instead. Signed-off-by: Adrián Larumbe Fixes: f11b0417eec2 ("drm/panfrost: Add fdinfo support GPU load metrics") --- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c index f59c82ea8870..2d30da38c2c3 100644 --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c @@ -29,14 +29,20 @@ static void panfrost_devfreq_update_utilization(struct panfrost_devfreq *pfdevfr static int panfrost_devfreq_target(struct device *dev, unsigned long *freq, u32 flags) { + struct panfrost_device *ptdev = dev_get_drvdata(dev); struct dev_pm_opp *opp; + int err; opp = devfreq_recommended_opp(dev, freq, flags); if (IS_ERR(opp)) return PTR_ERR(opp); dev_pm_opp_put(opp); - return dev_pm_opp_set_rate(dev, *freq); + err = dev_pm_opp_set_rate(dev, *freq); + if (!err) + ptdev->pfdevfreq.current_frequency = *freq; + + return err; } static void panfrost_devfreq_reset(struct panfrost_devfreq *pfdevfreq) @@ -58,7 +64,6 @@ static int panfrost_devfreq_get_dev_status(struct device *dev, spin_lock_irqsave(>lock, irqflags); panfrost_devfreq_update_utilization(pfdevfreq); - pfdevfreq->current_frequency = status->current_frequency; status->total_time = ktime_to_ns(ktime_add(pfdevfreq->busy_time, pfdevfreq->idle_time)); @@ -164,6 +169,14 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev) panfrost_devfreq_profile.initial_freq = cur_freq; + /* +* We could wait until panfrost_devfreq_target() to set this value, but +* since the simple_ondemand governor works asynchronously, there's a +* chance by the time someone opens the device's fdinfo file, current +* frequency hasn't been updated yet, so let's just do an early set. +*/ + pfdevfreq->current_frequency = cur_freq; + /* * Set the recommend OPP this will enable and configure the regulator * if any and will avoid a switch off by regulator_late_cleanup() -- 2.42.0
[PATCH 0/2] Panfrost devfreq and GEM status fixes
During recent development of the Mali CSF GPU Panthor driver, a user noticed that GPU frequency values as reported by fdinfo were incorrect. This was traced back to incorrect handling of frequency value updates. The same problem was seen in Panfrost. Also one should consider GEM objects from a dma-buf import as being resident in system memory, so that this can be reflected on fdinfo. Adrián Larumbe (2): drm/panfrost: Consider dma-buf imported objects as resident drm/panfrost: Fix incorrect updating of current device frequency drivers/gpu/drm/panfrost/panfrost_devfreq.c | 17 +++-- drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +- 2 files changed, 16 insertions(+), 3 deletions(-) base-commit: 38f922a563aac3148ac73e73689805917f034cb5 -- 2.42.0
[PATCH 1/2] drm/panfrost: Consider dma-buf imported objects as resident
A GEM object constructed from a dma-buf imported sgtable should be regarded as being memory resident, because the dma-buf API mandates backing storage to be allocated when attachment succeeds. Signed-off-by: Adrián Larumbe Fixes: 9ccdac7aa822 ("drm/panfrost: Add fdinfo support for memory stats") Reported-by: Boris Brezillon --- drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c index 0cf64456e29a..d47b40b82b0b 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gem.c +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c @@ -200,7 +200,7 @@ static enum drm_gem_object_status panfrost_gem_status(struct drm_gem_object *obj struct panfrost_gem_object *bo = to_panfrost_bo(obj); enum drm_gem_object_status res = 0; - if (bo->base.pages) + if (bo->base.base.import_attach || bo->base.pages) res |= DRM_GEM_OBJECT_RESIDENT; if (bo->base.madv == PANFROST_MADV_DONTNEED) -- 2.42.0
Re: [PATCH 10/17] dt-bindings: iio: samsung,exynos-adc: add specific compatibles for existing SoC
On Wed, 8 Nov 2023 11:43:36 +0100 Krzysztof Kozlowski wrote: > Samsung Exynos SoC reuses several devices from older designs, thus > historically we kept the old (block's) compatible only. This works fine > and there is no bug here, however guidelines expressed in > Documentation/devicetree/bindings/writing-bindings.rst state that: > 1. Compatibles should be specific. > 2. We should add new compatibles in case of bugs or features. > > Add compatibles specific to each SoC in front of all old-SoC-like > compatibles. > > Signed-off-by: Krzysztof Kozlowski Acked-by: Jonathan Cameron > > --- > > I propose to take the patch through Samsung SoC (me). See cover letter > for explanation. > --- > .../bindings/iio/adc/samsung,exynos-adc.yaml | 29 +++ > 1 file changed, 17 insertions(+), 12 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml > b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml > index 582d0a03b814..4e40f6bed5db 100644 > --- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml > @@ -11,18 +11,23 @@ maintainers: > > properties: >compatible: > -enum: > - - samsung,exynos-adc-v1 # Exynos5250 > - - samsung,exynos-adc-v2 > - - samsung,exynos3250-adc > - - samsung,exynos4212-adc# Exynos4212 and Exynos4412 > - - samsung,exynos7-adc > - - samsung,s3c2410-adc > - - samsung,s3c2416-adc > - - samsung,s3c2440-adc > - - samsung,s3c2443-adc > - - samsung,s3c6410-adc > - - samsung,s5pv210-adc > +oneOf: > + - enum: > + - samsung,exynos-adc-v1 # Exynos5250 > + - samsung,exynos-adc-v2 > + - samsung,exynos3250-adc > + - samsung,exynos4212-adc# Exynos4212 and Exynos4412 > + - samsung,exynos7-adc > + - samsung,s3c2410-adc > + - samsung,s3c2416-adc > + - samsung,s3c2440-adc > + - samsung,s3c2443-adc > + - samsung,s3c6410-adc > + - samsung,s5pv210-adc > + - items: > + - enum: > + - samsung,exynos5433-adc > + - const: samsung,exynos7-adc > >reg: > maxItems: 1
Re: drm scheduler redesign causes deadlocks [extended repost]
On 2023-11-24 04:38, Bert Karwatzki wrote: > Am Mittwoch, dem 22.11.2023 um 18:02 -0500 schrieb Luben Tuikov: >> On 2023-11-21 04:00, Bert Karwatzki wrote: >>> Since linux-next-20231115 my linux system (debian sid on msi alpha 15 >>> laptop) >>> suffers from random deadlocks which can occur after 30 - 180min of usage. >>> These >>> deadlocks can be actively provoked by creating high system load (usually by >>> compiling a kernel with make -j NRCPUS) and the opening instances of >>> libreoffice >>> --writer until the system GUI locks (the mouse cursor can still be moved but >>> the >>> screen is frozen). In this state ssh'ing into the machine is still possible >>> and >>> at least sometimes log messages about hung tasks appear in >>> /var/log/kern.log. >>> >>> More info can be found here: >>> https://gitlab.freedesktop.org/drm/amd/-/issues/2994 >>> >>> Using the method described to trigger the bug I bisected the problem in the >>> linux-next and drm-misc trees to give commit f3123c2590005 as the problem. >>> As this simple patch fixes the problem >>> >>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c >>> b/drivers/gpu/drm/scheduler/sched_main.c >>> index 044a8c4875ba..25b97db1b623 100644 >>> --- a/drivers/gpu/drm/scheduler/sched_main.c >>> +++ b/drivers/gpu/drm/scheduler/sched_main.c >>> @@ -1029,9 +1029,8 @@ EXPORT_SYMBOL(drm_sched_job_cleanup); >>> void drm_sched_wakeup(struct drm_gpu_scheduler *sched, >>> struct drm_sched_entity *entity) >>> { >>> - if (drm_sched_entity_is_ready(entity)) >>> - if (drm_sched_can_queue(sched, entity)) >>> - drm_sched_run_job_queue(sched); >>> + if (drm_sched_can_queue(sched, entity)) >>> + drm_sched_run_job_queue(sched); >>> } >>> >>> /** >>> >>> there might be in the entity->dependency branch of drm_sched_entity_is_ready >>> (some kind of circular dependencies ...). >>> >>> To see if the change to drm_sched_wakeup is the actual cause of the problem >>> or >>> if this problem has been cause by the redesign of the drm scheduler in linux >>> next-20231115+, I created the following patch for linux-6.6.0: >>> >>> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c >>> b/drivers/gpu/drm/scheduler/sched_entity.c >>> index a42763e1429d..dc2abd299aeb 100644 >>> --- a/drivers/gpu/drm/scheduler/sched_entity.c >>> +++ b/drivers/gpu/drm/scheduler/sched_entity.c >>> @@ -358,7 +358,7 @@ static void drm_sched_entity_wakeup(struct dma_fence *f, >>> container_of(cb, struct drm_sched_entity, cb); >>> >>> drm_sched_entity_clear_dep(f, cb); >>> - drm_sched_wakeup_if_can_queue(entity->rq->sched); >>> + drm_sched_wakeup_if_can_queue(entity->rq->sched, entity); >>> } >>> >>> /** >>> @@ -590,7 +590,7 @@ void drm_sched_entity_push_job(struct drm_sched_job >>> *sched_job) >>> if (drm_sched_policy == DRM_SCHED_POLICY_FIFO) >>> drm_sched_rq_update_fifo(entity, submit_ts); >>> >>> - drm_sched_wakeup_if_can_queue(entity->rq->sched); >>> + drm_sched_wakeup_if_can_queue(entity->rq->sched, entity); >>> } >>> } >>> EXPORT_SYMBOL(drm_sched_entity_push_job); >>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c >>> b/drivers/gpu/drm/scheduler/sched_main.c >>> index 5a3a622fc672..bbe06403b33d 100644 >>> --- a/drivers/gpu/drm/scheduler/sched_main.c >>> +++ b/drivers/gpu/drm/scheduler/sched_main.c >>> @@ -865,10 +865,11 @@ static bool drm_sched_can_queue(struct >>> drm_gpu_scheduler >>> *sched) >>> * >>> * Wake up the scheduler if we can queue jobs. >>> */ >>> -void drm_sched_wakeup_if_can_queue(struct drm_gpu_scheduler *sched) >>> +void drm_sched_wakeup_if_can_queue(struct drm_gpu_scheduler *sched, struct >>> drm_sched_entity *entity) >>> { >>> - if (drm_sched_can_queue(sched)) >>> - wake_up_interruptible(>wake_up_worker); >>> + if(drm_sched_entity_is_ready(entity)) >>> + if (drm_sched_can_queue(sched)) >>> + wake_up_interruptible(>wake_up_worker); >>> } >>> >>> /** >>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h >>> index ac65f0626cfc..6cfe3d193e69 100644 >>> --- a/include/drm/gpu_scheduler.h >>> +++ b/include/drm/gpu_scheduler.h >>> @@ -548,7 +548,7 @@ void drm_sched_entity_modify_sched(struct >>> drm_sched_entity >>> *entity, >>> unsigned int num_sched_list); >>> >>> void drm_sched_job_cleanup(struct drm_sched_job *job); >>> -void drm_sched_wakeup_if_can_queue(struct drm_gpu_scheduler *sched); >>> +void drm_sched_wakeup_if_can_queue(struct drm_gpu_scheduler *sched, struct >>> drm_sched_entity *entity); >>> void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job >>> *bad); >>> void drm_sched_start(struct drm_gpu_scheduler *sched, bool full_recovery); >>> void drm_sched_resubmit_jobs(struct drm_gpu_scheduler *sched); >>> >>> This brings the extra check to the old scheduler and has so far not caused >>> any >>> trouble (using the same stress test described above), so chances are that >>> the >>> error is
[PATCH] drm/sched: Fix compilation issues with DRM priority rename
Fix compilation issues with DRM scheduler priority rename MIN to LOW. Signed-off-by: Luben Tuikov Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202311252109.wgbjsskg-...@intel.com/ Cc: Danilo Krummrich Cc: Frank Binns Cc: Donald Robson Cc: Matt Coster Cc: Direct Rendering Infrastructure - Development Fixes: fe375c74806dbd ("drm/sched: Rename priority MIN to LOW") Fixes: 5f03a507b29e44 ("drm/nouveau: implement 1:1 scheduler - entity relationship") --- drivers/gpu/drm/imagination/pvr_queue.c | 2 +- drivers/gpu/drm/nouveau/nouveau_sched.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/imagination/pvr_queue.c b/drivers/gpu/drm/imagination/pvr_queue.c index d65c3fbedf5ac4..5ed9c98fb599c8 100644 --- a/drivers/gpu/drm/imagination/pvr_queue.c +++ b/drivers/gpu/drm/imagination/pvr_queue.c @@ -1292,7 +1292,7 @@ struct pvr_queue *pvr_queue_create(struct pvr_context *ctx, goto err_release_ufo; err = drm_sched_entity_init(>entity, - DRM_SCHED_PRIORITY_MIN, + DRM_SCHED_PRIORITY_KERNEL, , 1, >faulty); if (err) goto err_sched_fini; diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c b/drivers/gpu/drm/nouveau/nouveau_sched.c index 3393647bd94423..dd98f6910f9cab 100644 --- a/drivers/gpu/drm/nouveau/nouveau_sched.c +++ b/drivers/gpu/drm/nouveau/nouveau_sched.c @@ -18,7 +18,7 @@ * index to the run-queue array. */ enum nouveau_sched_priority { - NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN, + NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_KERNEL, NOUVEAU_SCHED_PRIORITY_COUNT, }; @@ -423,7 +423,7 @@ nouveau_sched_init(struct nouveau_sched *sched, struct nouveau_drm *drm, if (ret) goto fail_wq; - /* Using DRM_SCHED_PRIORITY_MIN, since that's what we're required to use + /* Using DRM_SCHED_PRIORITY_KERNEL, since that's what we're required to use * when we want to have a single run-queue only. * * It's not documented, but one will find out when trying to use any @@ -433,7 +433,7 @@ nouveau_sched_init(struct nouveau_sched *sched, struct nouveau_drm *drm, * Can't use NOUVEAU_SCHED_PRIORITY_SINGLE either, because it's not * matching the enum type used in drm_sched_entity_init(). */ - ret = drm_sched_entity_init(entity, DRM_SCHED_PRIORITY_MIN, + ret = drm_sched_entity_init(entity, DRM_SCHED_PRIORITY_KERNEL, _sched, 1, NULL); if (ret) goto fail_sched; base-commit: 38f922a563aac3148ac73e73689805917f034cb5 -- 2.43.0
[PATCH v2 2/2] drm/msm/a690: Fix reg values for a690
From: Danylo Piliaiev KGSL doesn't support a690 so all reg values were the same as on a660. Now we know the values and they are different from the windows driver. This fixes hangs on D3D12 games and some CTS tests. Signed-off-by: Danylo Piliaiev Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index d10b22eeda74..7784d7d39192 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -1312,6 +1312,7 @@ static void a6xx_set_ubwc_config(struct msm_gpu *gpu) if (adreno_is_a650(adreno_gpu) || adreno_is_a660(adreno_gpu) || + adreno_is_a690(adreno_gpu) || adreno_is_a730(adreno_gpu) || adreno_is_a740_family(adreno_gpu)) { /* TODO: get ddr type from bootloader and use 2 for LPDDR4 */ @@ -1321,13 +1322,6 @@ static void a6xx_set_ubwc_config(struct msm_gpu *gpu) uavflagprd_inv = 2; } - if (adreno_is_a690(adreno_gpu)) { - hbb_lo = 2; - amsbc = 1; - rgb565_predicator = 1; - uavflagprd_inv = 2; - } - if (adreno_is_7c3(adreno_gpu)) { hbb_lo = 1; amsbc = 1; @@ -1741,7 +1735,9 @@ static int hw_init(struct msm_gpu *gpu) /* Setting the primFifo thresholds default values, * and vccCacheSkipDis=1 bit (0x200) for A640 and newer */ - if (adreno_is_a650(adreno_gpu) || adreno_is_a660(adreno_gpu) || adreno_is_a690(adreno_gpu)) + if (adreno_is_a690(adreno_gpu)) + gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00800200); + else if (adreno_is_a650(adreno_gpu) || adreno_is_a660(adreno_gpu)) gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00300200); else if (adreno_is_a640_family(adreno_gpu) || adreno_is_7c3(adreno_gpu)) gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00200200); @@ -1775,6 +1771,8 @@ static int hw_init(struct msm_gpu *gpu) if (adreno_is_a730(adreno_gpu) || adreno_is_a740_family(adreno_gpu)) gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30) | 0xcf); + else if (adreno_is_a690(adreno_gpu)) + gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30) | 0x4f); else if (adreno_is_a619(adreno_gpu)) gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30) | 0x3f); else if (adreno_is_a610(adreno_gpu)) @@ -1808,12 +1806,17 @@ static int hw_init(struct msm_gpu *gpu) a6xx_set_cp_protect(gpu); if (adreno_is_a660_family(adreno_gpu)) { - gpu_write(gpu, REG_A6XX_CP_CHICKEN_DBG, 0x1); + if (adreno_is_a690(adreno_gpu)) + gpu_write(gpu, REG_A6XX_CP_CHICKEN_DBG, 0x00028801); + else + gpu_write(gpu, REG_A6XX_CP_CHICKEN_DBG, 0x1); gpu_write(gpu, REG_A6XX_RBBM_GBIF_CLIENT_QOS_CNTL, 0x0); } + if (adreno_is_a690(adreno_gpu)) + gpu_write(gpu, REG_A6XX_UCHE_CMDQ_CONFIG, 0x90); /* Set dualQ + disable afull for A660 GPU */ - if (adreno_is_a660(adreno_gpu)) + else if (adreno_is_a660(adreno_gpu)) gpu_write(gpu, REG_A6XX_UCHE_CMDQ_CONFIG, 0x66906); else if (adreno_is_a7xx(adreno_gpu)) gpu_write(gpu, REG_A6XX_UCHE_CMDQ_CONFIG, -- 2.42.0
[PATCH v2 1/2] drm/msm/a6xx: Add missing BIT(7) to REG_A6XX_UCHE_CLIENT_PF
From: Danylo Piliaiev Downstream always set BIT(7) Signed-off-by: Danylo Piliaiev Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index 8176ea8da7a7..d10b22eeda74 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -1782,7 +1782,7 @@ static int hw_init(struct msm_gpu *gpu) else gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30) | 0x1f); - gpu_write(gpu, REG_A6XX_UCHE_CLIENT_PF, 1); + gpu_write(gpu, REG_A6XX_UCHE_CLIENT_PF, BIT(7) | 0x1); /* Set weights for bicubic filtering */ if (adreno_is_a650_family(adreno_gpu)) { -- 2.42.0
Re: [PATCH] drm/mediatek/dp: Add the HDCP feature for DisplayPort
Hi mac.shen, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v6.7-rc2 next-20231124] [cannot apply to pza/reset/next pza/imx-drm/next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/mac-shen/drm-mediatek-dp-Add-the-HDCP-feature-for-DisplayPort/20231125-152640 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20231124085346.26602-1-mac.shen%40mediatek.com patch subject: [PATCH] drm/mediatek/dp: Add the HDCP feature for DisplayPort config: arm-allmodconfig (https://download.01.org/0day-ci/archive/20231125/202311252346.ybtdeecp-...@intel.com/config) compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231125/202311252346.ybtdeecp-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202311252346.ybtdeecp-...@intel.com/ All warnings (new ones prefixed by >>): >> drivers/gpu/drm/mediatek/mtk_dp.c:349:5: warning: no previous prototype for >> 'mtk_dp_read' [-Wmissing-prototypes] 349 | u32 mtk_dp_read(struct mtk_dp *mtk_dp, u32 offset) | ^~~ >> drivers/gpu/drm/mediatek/mtk_dp.c:376:5: warning: no previous prototype for >> 'mtk_dp_update_bits' [-Wmissing-prototypes] 376 | int mtk_dp_update_bits(struct mtk_dp *mtk_dp, u32 offset, | ^~ In file included from include/linux/device.h:15, from include/drm/display/drm_dp_aux_bus.h:13, from drivers/gpu/drm/mediatek/mtk_dp.c:7: drivers/gpu/drm/mediatek/mtk_dp.c: In function 'mtk_dp_hpd_sink_event': >> include/drm/drm_print.h:456:54: warning: format '%ld' expects argument of >> type 'long int', but argument 3 has type 'ssize_t' {aka 'int'} [-Wformat=] 456 | dev_##level##type((drm) ? (drm)->dev : NULL, "[drm] " fmt, ##__VA_ARGS__) | ^~~~ include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap' 110 | _p_func(dev, fmt, ##__VA_ARGS__); \ | ^~~ include/linux/dev_printk.h:150:58: note: in expansion of macro 'dev_fmt' 150 | dev_printk_index_wrap(_dev_info, KERN_INFO, dev, dev_fmt(fmt), ##__VA_ARGS__) | ^~~ include/drm/drm_print.h:456:9: note: in expansion of macro 'dev_info' 456 | dev_##level##type((drm) ? (drm)->dev : NULL, "[drm] " fmt, ##__VA_ARGS__) | ^~~~ include/drm/drm_print.h:460:9: note: in expansion of macro '__drm_printk' 460 | __drm_printk((drm), info,, fmt, ##__VA_ARGS__) | ^~~~ drivers/gpu/drm/mediatek/mtk_dp.c:1905:17: note: in expansion of macro 'drm_info' 1905 | drm_info(mtk_dp->drm_dev, "Read sink count failed: %ld\n", ret); | ^~~~ >> include/drm/drm_print.h:456:54: warning: format '%ld' expects argument of >> type 'long int', but argument 3 has type 'ssize_t' {aka 'int'} [-Wformat=] 456 | dev_##level##type((drm) ? (drm)->dev : NULL, "[drm] " fmt, ##__VA_ARGS__) | ^~~~ include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap' 110 | _p_func(dev, fmt, ##__VA_ARGS__); \ | ^~~ include/linux/dev_printk.h:150:58: note: in expansion of macro 'dev_fmt' 150 | dev_printk_index_wrap(_dev_info, KERN_INFO, dev, dev_fmt(fmt), ##__VA_ARGS__) | ^~~ include/drm/drm_print.h:456:9: note: in expansion of macro 'dev_info' 456 | dev_##level##type((drm) ? (drm)->dev : NULL, "[drm] " fmt, ##__VA_ARGS__) | ^~~~ include/drm/drm_print.h:460:9: note: in expansion of macro '__drm_printk' 460 | __drm_printk((drm), info,, fmt, ##__VA_ARGS__) | ^~~~ drivers/gpu/drm/mediatek/mtk_dp.c:1911:17: note: in expansion of macro 'drm_info' 1911 | drm_info(mtk_dp->drm_dev, | ^~~~ drivers/gpu/drm/mediatek/mtk_dp.c: At top level: >> dr
Re: [PATCH] drm/mediatek/dp: Add the HDCP feature for DisplayPort
Hi mac.shen, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v6.7-rc2] [cannot apply to pza/reset/next pza/imx-drm/next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/mac-shen/drm-mediatek-dp-Add-the-HDCP-feature-for-DisplayPort/20231125-152640 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20231124085346.26602-1-mac.shen%40mediatek.com patch subject: [PATCH] drm/mediatek/dp: Add the HDCP feature for DisplayPort config: arm64-allyesconfig (https://download.01.org/0day-ci/archive/20231125/202311252324.ttpd9ixz-...@intel.com/config) compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231125/202311252324.ttpd9ixz-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202311252324.ttpd9ixz-...@intel.com/ All warnings (new ones prefixed by >>): >> drivers/gpu/drm/mediatek/mtk_dp.c:349:5: warning: no previous prototype for >> function 'mtk_dp_read' [-Wmissing-prototypes] 349 | u32 mtk_dp_read(struct mtk_dp *mtk_dp, u32 offset) | ^ drivers/gpu/drm/mediatek/mtk_dp.c:349:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 349 | u32 mtk_dp_read(struct mtk_dp *mtk_dp, u32 offset) | ^ | static >> drivers/gpu/drm/mediatek/mtk_dp.c:376:5: warning: no previous prototype for >> function 'mtk_dp_update_bits' [-Wmissing-prototypes] 376 | int mtk_dp_update_bits(struct mtk_dp *mtk_dp, u32 offset, | ^ drivers/gpu/drm/mediatek/mtk_dp.c:376:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 376 | int mtk_dp_update_bits(struct mtk_dp *mtk_dp, u32 offset, | ^ | static >> drivers/gpu/drm/mediatek/mtk_dp.c:2663:6: warning: no previous prototype for >> function 'mtk_dp_check_hdcp_version' [-Wmissing-prototypes] 2663 | void mtk_dp_check_hdcp_version(struct mtk_dp *mtk_dp, bool only_hdcp1x) | ^ drivers/gpu/drm/mediatek/mtk_dp.c:2663:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 2663 | void mtk_dp_check_hdcp_version(struct mtk_dp *mtk_dp, bool only_hdcp1x) | ^ | static 3 warnings generated. vim +/mtk_dp_read +349 drivers/gpu/drm/mediatek/mtk_dp.c 348 > 349 u32 mtk_dp_read(struct mtk_dp *mtk_dp, u32 offset) 350 { 351 return mtk_dp_reg_read(mtk_dp->regs, offset); 352 } 353 354 static int mtk_dp_write(struct mtk_dp *mtk_dp, u32 offset, u32 val) 355 { 356 int ret = regmap_write(mtk_dp->regs, offset, val); 357 358 if (ret) 359 dev_err(mtk_dp->dev, 360 "Failed to write register 0x%x with value 0x%x\n", 361 offset, val); 362 return ret; 363 } 364 365 int mtk_dp_reg_update_bits(struct regmap *regs, u32 offset, 366 u32 val, u32 mask) 367 { 368 int ret = regmap_update_bits(regs, offset, mask, val); 369 370 if (ret) 371 pr_err("Failed to update register 0x%x with value 0x%x, mask 0x%x\n", 372 offset, val, mask); 373 return ret; 374 } 375 > 376 int mtk_dp_update_bits(struct mtk_dp *mtk_dp, u32 offset, 377 u32 val, u32 mask) 378 { 379 return mtk_dp_reg_update_bits(mtk_dp->regs, offset, val, mask); 380 } 381 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[drm-misc:for-linux-next 2/3] drivers/gpu/drm/nouveau/nouveau_sched.c:21:34: error: use of undeclared identifier 'DRM_SCHED_PRIORITY_MIN'
Hi Luben, FYI, the error/warning was bisected to this commit, please ignore it if it's irrelevant. tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next head: 38f922a563aac3148ac73e73689805917f034cb5 commit: fe375c74806dbd30b00ec038a80a5b7bf4653ab7 [2/3] drm/sched: Rename priority MIN to LOW config: x86_64-randconfig-123-20231125 (https://download.01.org/0day-ci/archive/20231125/202311252109.wgbjsskg-...@intel.com/config) compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231125/202311252109.wgbjsskg-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202311252109.wgbjsskg-...@intel.com/ All errors (new ones prefixed by >>): >> drivers/gpu/drm/nouveau/nouveau_sched.c:21:34: error: use of undeclared >> identifier 'DRM_SCHED_PRIORITY_MIN' NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN, ^ drivers/gpu/drm/nouveau/nouveau_sched.c:436:38: error: use of undeclared identifier 'DRM_SCHED_PRIORITY_MIN' ret = drm_sched_entity_init(entity, DRM_SCHED_PRIORITY_MIN, ^ 2 errors generated. vim +/DRM_SCHED_PRIORITY_MIN +21 drivers/gpu/drm/nouveau/nouveau_sched.c b88baab828713c Danilo Krummrich 2023-08-04 16 5f03a507b29e44 Danilo Krummrich 2023-11-14 17 /* Starts at 0, since the DRM scheduler interprets those parameters as (initial) 5f03a507b29e44 Danilo Krummrich 2023-11-14 18 * index to the run-queue array. 5f03a507b29e44 Danilo Krummrich 2023-11-14 19 */ 5f03a507b29e44 Danilo Krummrich 2023-11-14 20 enum nouveau_sched_priority { 5f03a507b29e44 Danilo Krummrich 2023-11-14 @21 NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN, 5f03a507b29e44 Danilo Krummrich 2023-11-14 22 NOUVEAU_SCHED_PRIORITY_COUNT, 5f03a507b29e44 Danilo Krummrich 2023-11-14 23 }; 5f03a507b29e44 Danilo Krummrich 2023-11-14 24 :: The code at line 21 was first introduced by commit :: 5f03a507b29e44a848f315c7240c19894dd8be4f drm/nouveau: implement 1:1 scheduler - entity relationship :: TO: Danilo Krummrich :: CC: Danilo Krummrich -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[PATCH 08/12] arm64: dts: qcom: qcm2290: Add display nodes
Add the required nodes to support display on QCM2290. Signed-off-by: Konrad Dybcio --- arch/arm64/boot/dts/qcom/qcm2290.dtsi | 214 ++ 1 file changed, 214 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/qcm2290.dtsi b/arch/arm64/boot/dts/qcom/qcm2290.dtsi index d46e591e72b5..a3edc4667cc5 100644 --- a/arch/arm64/boot/dts/qcom/qcm2290.dtsi +++ b/arch/arm64/boot/dts/qcom/qcm2290.dtsi @@ -5,6 +5,7 @@ * Based on sm6115.dtsi and previous efforts by Shawn Guo & Loic Poulain. */ +#include #include #include #include @@ -1105,6 +1106,219 @@ usb_dwc3: usb@4e0 { }; }; + mdss: display-subsystem@5e0 { + compatible = "qcom,qcm2290-mdss"; + reg = <0x0 0x05e0 0x0 0x1000>; + reg-names = "mdss"; + interrupts = ; + interrupt-controller; + #interrupt-cells = <1>; + + clocks = < GCC_DISP_AHB_CLK>, +< GCC_DISP_HF_AXI_CLK>, +< DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", + "bus", + "core"; + + resets = < DISP_CC_MDSS_CORE_BCR>; + + power-domains = < MDSS_GDSC>; + + iommus = <_smmu 0x420 0x2>, +<_smmu 0x421 0x0>; + + #address-cells = <2>; + #size-cells = <2>; + ranges; + + status = "disabled"; + + mdp: display-controller@5e01000 { + compatible = "qcom,qcm2290-dpu"; + reg = <0x0 0x05e01000 0x0 0x8f000>, + <0x0 0x05eb 0x0 0x2008>; + reg-names = "mdp", + "vbif"; + + interrupt-parent = <>; + interrupts = <0>; + + clocks = < GCC_DISP_HF_AXI_CLK>, +< DISP_CC_MDSS_AHB_CLK>, +< DISP_CC_MDSS_MDP_CLK>, +< DISP_CC_MDSS_MDP_LUT_CLK>, +< DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", + "iface", + "core", + "lut", + "vsync"; + + operating-points-v2 = <_opp_table>; + power-domains = < QCM2290_VDDCX>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <_dsi0_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-1920 { + opp-hz = /bits/ 64 <1920>; + required-opps = <_opp_min_svs>; + }; + + opp-19200 { + opp-hz = /bits/ 64 <19200>; + required-opps = <_opp_low_svs>; + }; + + opp-25600 { + opp-hz = /bits/ 64 <25600>; + required-opps = <_opp_svs>; + }; + + opp-30720 { + opp-hz = /bits/ 64 <30720>; + required-opps = <_opp_svs_plus>; + }; + + opp-38400 { + opp-hz = /bits/ 64 <38400>; + required-opps = <_opp_nom>; + }; + }; + }; + +
[PATCH 12/12] arm64: dts: qcom: qrb2210-rb1: add wifi variant property
From: Dmitry Baryshkov The RB1 platform doesn't have board-specific board-id programmed, it uses generic 0xff. Thus add the property with the 'variant' of the calibration data. Note: the driver will check for the calibration data for the following IDs, so existing board-2.bin files will continue to work. - 'bus=snoc,qmi-board-id=ff,qmi-chip-id=120,variant=Thundercomm_RB1' - 'bus=snoc,qmi-board-id=ff,qmi-chip-id=120' - 'bus=snoc,qmi-board-id=ff' For the reference, the board is identified by the driver in the following way: ath10k_snoc c80.wifi: qmi chip_id 0x120 chip_family 0x4007 board_id 0xff soc_id 0x4067 ath10k_snoc c80.wifi: qmi fw_version 0x337302d3 fw_build_timestamp 2023-01-06 01:50 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.3.7.c2-00723-QCAHLSWMTPLZ-1 ath10k_snoc c80.wifi: wcn3990 hw1.0 target 0x0008 chip_id 0x sub : ath10k_snoc c80.wifi: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0 ath10k_snoc c80.wifi: firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790 ath10k_snoc c80.wifi: htt-ver 3.114 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1 Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio --- arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts index ac597eb3fe9d..bd7bcf803654 100644 --- a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts +++ b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts @@ -535,6 +535,7 @@ { vdd-1.8-xo-supply = <_l13>; vdd-1.3-rfa-supply = <_l10>; vdd-3.3-ch0-supply = <_l22>; + qcom,ath10k-calibration-variant = "Thundercomm_RB1"; status = "okay"; }; -- 2.43.0
[PATCH 11/12] arm64: dts: qcom: qrb2210-rb1: Enable CAN bus controller
Enable the Microchip mcp2518fd hosted on the SPI5 bus. Signed-off-by: Konrad Dybcio --- arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 22 ++ 1 file changed, 22 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts index ac6584164058..ac597eb3fe9d 100644 --- a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts +++ b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts @@ -23,6 +23,14 @@ chosen { stdout-path = "serial0:115200n8"; }; + clocks { + clk40M: can-clk { + compatible = "fixed-clock"; + clock-frequency = <4000>; + #clock-cells = <0>; + }; + }; + gpio-keys { compatible = "gpio-keys"; label = "gpio-keys"; @@ -449,6 +457,20 @@ _2 { status = "okay"; }; + { + status = "okay"; + + can@0 { + compatible = "microchip,mcp2518fd"; + reg = <0>; + interrupts-extended = < 39 IRQ_TYPE_LEVEL_LOW>; + clocks = <>; + spi-max-frequency = <1000>; + vdd-supply = <_5v>; + xceiver-supply = <_5v>; + }; +}; + { lt9611_rst_pin: lt9611-rst-state { pins = "gpio41"; -- 2.43.0
[PATCH 10/12] arm64: dts: qcom: qrb2210-rb1: Set up HDMI
Add the required nodes to support display output via the HDMI port. Signed-off-by: Konrad Dybcio --- arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 86 1 file changed, 86 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts index 94885b9c21c8..ac6584164058 100644 --- a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts +++ b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts @@ -40,6 +40,17 @@ key-volume-up { }; }; + hdmi-connector { + compatible = "hdmi-connector"; + type = "a"; + + port { + hdmi_con: endpoint { + remote-endpoint = <_out>; + }; + }; + }; + leds { compatible = "gpio-leds"; @@ -158,6 +169,68 @@ vph_pwr: regulator-vph-pwr { }; }; +_dma0 { + status = "okay"; +}; + + { + clock-frequency = <40>; + status = "okay"; + + lt9611_codec: hdmi-bridge@2b { + compatible = "lontium,lt9611uxc"; + reg = <0x2b>; + interrupts-extended = < 46 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = < 41 GPIO_ACTIVE_HIGH>; + + vdd-supply = <_hdmi_out_1p2>; + vcc-supply = <_3v3>; + + pinctrl-0 = <_irq_pin _rst_pin>; + pinctrl-names = "default"; + #sound-dai-cells = <1>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + lt9611_a: endpoint { + remote-endpoint = <_dsi0_out>; + }; + }; + + port@2 { + reg = <2>; + + lt9611_out: endpoint { + remote-endpoint = <_con>; + }; + }; + }; + }; +}; + + { + status = "okay"; +}; + +_dsi0 { + vdda-supply = <_l5>; + status = "okay"; +}; + +_dsi0_out { + remote-endpoint = <_a>; + data-lanes = <0 1 2 3>; +}; + +_dsi0_phy { + status = "okay"; +}; + _resin { linux,code = ; status = "okay"; @@ -377,6 +450,19 @@ _2 { }; { + lt9611_rst_pin: lt9611-rst-state { + pins = "gpio41"; + function = "gpio"; + input-disable; + output-high; + }; + + lt9611_irq_pin: lt9611-irq-state { + pins = "gpio46"; + function = "gpio"; + bias-disable; + }; + sd_det_in_on: sd-det-in-on-state { pins = "gpio88"; function = "gpio"; -- 2.43.0
[PATCH 09/12] arm64: dts: qcom: qcm2290: Hook up interconnects
Add interconnect provider nodes and hook up interconnects to consumer devices, including bwmon. Signed-off-by: Konrad Dybcio --- arch/arm64/boot/dts/qcom/qcm2290.dtsi | 248 ++ 1 file changed, 248 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/qcm2290.dtsi b/arch/arm64/boot/dts/qcom/qcm2290.dtsi index a3edc4667cc5..ce04d0acdede 100644 --- a/arch/arm64/boot/dts/qcom/qcm2290.dtsi +++ b/arch/arm64/boot/dts/qcom/qcm2290.dtsi @@ -12,6 +12,8 @@ #include #include #include +#include +#include #include / { @@ -151,6 +153,8 @@ scm: scm { clocks = < RPM_SMD_CE1_CLK>; clock-names = "core"; #reset-cells = <1>; + interconnects = <_noc MASTER_CRYPTO_CORE0 RPM_ALWAYS_TAG + SLAVE_EBI1 RPM_ALWAYS_TAG>; }; }; @@ -669,6 +673,33 @@ usb_qmpphy: phy@1615000 { status = "disabled"; }; + system_noc: interconnect@188 { + compatible = "qcom,qcm2290-snoc"; + reg = <0x0 0x0188 0x0 0x60200>; + #interconnect-cells = <2>; + + qup_virt: interconnect-qup { + compatible = "qcom,qcm2290-qup-virt"; + #interconnect-cells = <2>; + }; + + mmnrt_virt: interconnect-mmnrt { + compatible = "qcom,qcm2290-mmnrt-virt"; + #interconnect-cells = <2>; + }; + + mmrt_virt: interconnect-mmrt { + compatible = "qcom,qcm2290-mmrt-virt"; + #interconnect-cells = <2>; + }; + }; + + config_noc: interconnect@190 { + compatible = "qcom,qcm2290-cnoc"; + reg = <0x0 0x0190 0x0 0x8200>; + #interconnect-cells = <2>; + }; + qfprom@1b44000 { compatible = "qcom,qcm2290-qfprom", "qcom,qfprom"; reg = <0x0 0x01b44000 0x0 0x3000>; @@ -681,6 +712,60 @@ qusb2_hstx_trim: hstx-trim@25b { }; }; + pmu@1b8e300 { + compatible = "qcom,qcm2290-cpu-bwmon", "qcom,sdm845-bwmon"; + reg = <0x0 0x01b8e300 0x0 0x600>; + interrupts = ; + + operating-points-v2 = <_bwmon_opp_table>; + interconnects = < MASTER_APPSS_PROC RPM_ACTIVE_TAG + SLAVE_EBI1 RPM_ACTIVE_TAG>; + + cpu_bwmon_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-0 { + opp-peak-kBps = <(200 * 4 * 1000)>; + }; + + opp-1 { + opp-peak-kBps = <(300 * 4 * 1000)>; + }; + + opp-2 { + opp-peak-kBps = <(451 * 4 * 1000)>; + }; + + opp-3 { + opp-peak-kBps = <(547 * 4 * 1000)>; + }; + + opp-4 { + opp-peak-kBps = <(681 * 4 * 1000)>; + }; + + opp-5 { + opp-peak-kBps = <(768 * 4 * 1000)>; + }; + + opp-6 { + opp-peak-kBps = <(1017 * 4 * 1000)>; + }; + + opp-7 { + opp-peak-kBps = <(1353 * 4 * 1000)>; + }; + + opp-8 { + opp-peak-kBps = <(1555 * 4 * 1000)>; + }; + + opp-9 { + opp-peak-kBps = <(1804 * 4 * 1000)>; + }; + }; + }; + spmi_bus: spmi@1c4 { compatible = "qcom,spmi-pmic-arb"; reg = <0x0 0x01c4 0x0 0x1100>, @@ -721,6 +806,12 @@ rng: rng@4453000 { clock-names = "core"; }; + bimc: interconnect@448 { + compatible = "qcom,qcm2290-bimc"; + reg = <0x0 0x0448 0x0 0x8>; +
[PATCH 07/12] iommu/arm-smmu-qcom: Add QCM2290 DPU compatible
Add the QCM2290 DPU compatible to clients compatible list, as it also needs the workarounds. Signed-off-by: Konrad Dybcio --- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c index 549ae4dba3a6..aea5e85b20ff 100644 --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c @@ -245,6 +245,7 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = { { .compatible = "qcom,adreno" }, { .compatible = "qcom,mdp4" }, { .compatible = "qcom,mdss" }, + { .compatible = "qcom,qcm2290-mdss" }, { .compatible = "qcom,sc7180-mdss" }, { .compatible = "qcom,sc7180-mss-pil" }, { .compatible = "qcom,sc7280-mdss" }, -- 2.43.0
[PATCH 06/12] dt-bindings: firmware: qcom,scm: Allow interconnect for everyone
Every Qualcomm SoC physically has a "CRYPTO0<->DDR" interconnect lane. Allow this property to be present, no matter the SoC. Signed-off-by: Konrad Dybcio --- Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 15 --- 1 file changed, 15 deletions(-) diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml index 0613a37a851a..f3a87a8426d0 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml @@ -178,21 +178,6 @@ allOf: minItems: 3 maxItems: 3 - # Interconnects - - if: - not: -properties: - compatible: -contains: - enum: -- qcom,scm-qdu1000 -- qcom,scm-sc8280xp -- qcom,scm-sm8450 -- qcom,scm-sm8550 -then: - properties: -interconnects: false - # Interrupts - if: not: -- 2.43.0
[PATCH 01/12] dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat
The "qcom,dsi-ctrl-6g-qcm2290" has been deprecated in commit 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC"), but the example hasn't been updated to reflect that. Fix that. Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC") Signed-off-by: Konrad Dybcio --- Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml index 5ad155612b6c..3d82c00a9f85 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml @@ -56,7 +56,9 @@ patternProperties: properties: compatible: -const: qcom,dsi-ctrl-6g-qcm2290 +items: + - const: qcom,qcm2290-dsi-ctrl + - const: qcom,mdss-dsi-ctrl "^phy@[0-9a-f]+$": type: object -- 2.43.0
[PATCH 04/12] dt-bindings: display: msm: sm8450-mdss: Allow 3 interconnects
In addition to MDP01, the cpu-cfg interconnect is also necessary. Allow it. Signed-off-by: Konrad Dybcio --- Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml index 001b26e65301..e94e8630cc85 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml @@ -30,10 +30,10 @@ properties: maxItems: 1 interconnects: -maxItems: 2 +maxItems: 3 interconnect-names: -maxItems: 2 +maxItems: 3 patternProperties: "^display-controller@[0-9a-f]+$": -- 2.43.0
[PATCH 05/12] dt-bindings: interconnect: qcom,msm8998-bwmon: Add QCM2290 bwmon instance
QCM2290 has a single BWMONv4 intance for CPU. Document it. Signed-off-by: Konrad Dybcio --- Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml index 7cb8df757477..a88cea732370 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml @@ -25,6 +25,7 @@ properties: - const: qcom,msm8998-bwmon # BWMON v4 - items: - enum: + - qcom,qcm2290-cpu-bwmon - qcom,sc7180-cpu-bwmon - qcom,sc7280-cpu-bwmon - qcom,sc8280xp-cpu-bwmon -- 2.43.0
[PATCH 03/12] dt-bindings: display: msm: qcm2290-mdss: Allow 2 interconnects
In addition to MDP0, the cpu-cfg interconnect is also necessary. Allow it. Signed-off-by: Konrad Dybcio --- Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml index 3d82c00a9f85..51f3e9c34dfb 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml @@ -36,10 +36,10 @@ properties: maxItems: 2 interconnects: -maxItems: 1 +maxItems: 2 interconnect-names: -maxItems: 1 +maxItems: 2 patternProperties: "^display-controller@[0-9a-f]+$": -- 2.43.0
[PATCH 00/12] RB1/QCM2290 features
This series brings: - interconnect plumbing - display setup for QCM2290/QRB2210 and - CAN bus controller - HDMI display - wifi fw variant name for QTI RB1 and the necessary bindings changes Patch 1-4 is for Dmitry/freedreno Patch 5 for Georgi/icc Patch 7 for Will/iommu the rest are for Bjorn/qcom Signed-off-by: Konrad Dybcio --- Dmitry Baryshkov (1): arm64: dts: qcom: qrb2210-rb1: add wifi variant property Konrad Dybcio (11): dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat dt-bindings: display: msm: Add reg bus and rotator interconnects dt-bindings: display: msm: qcm2290-mdss: Allow 2 interconnects dt-bindings: display: msm: sm8450-mdss: Allow 3 interconnects dt-bindings: interconnect: qcom,msm8998-bwmon: Add QCM2290 bwmon instance dt-bindings: firmware: qcom,scm: Allow interconnect for everyone iommu/arm-smmu-qcom: Add QCM2290 DPU compatible arm64: dts: qcom: qcm2290: Add display nodes arm64: dts: qcom: qcm2290: Hook up interconnects arm64: dts: qcom: qrb2210-rb1: Set up HDMI arm64: dts: qcom: qrb2210-rb1: Enable CAN bus controller .../bindings/display/msm/mdss-common.yaml | 18 +- .../bindings/display/msm/qcom,qcm2290-mdss.yaml| 8 +- .../bindings/display/msm/qcom,sm8450-mdss.yaml | 4 +- .../devicetree/bindings/firmware/qcom,scm.yaml | 15 - .../bindings/interconnect/qcom,msm8998-bwmon.yaml | 1 + arch/arm64/boot/dts/qcom/qcm2290.dtsi | 462 + arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 109 + drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 + 8 files changed, 594 insertions(+), 24 deletions(-) --- base-commit: 8c9660f6515396aba78d1168d2e17951d653ebf2 change-id: 20231125-topic-rb1_feat-dd510532621b Best regards, -- Konrad Dybcio
[PATCH 02/12] dt-bindings: display: msm: Add reg bus and rotator interconnects
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are other connection paths: - a path that connects rotator block to the DDR. - a path that needs to be handled to ensure MDSS register access functions properly, namely the "reg bus", a.k.a the CPU-MDSS CFG interconnect. Describe these paths bindings to allow using them in device trees and in the driver Signed-off-by: Dmitry Baryshkov [Konrad: rework for one vs two MDP paths] Signed-off-by: Konrad Dybcio --- .../devicetree/bindings/display/msm/mdss-common.yaml | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml index f69196e4cc76..c6305a6e0334 100644 --- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml +++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml @@ -61,17 +61,27 @@ properties: ranges: true + # This is not a perfect description, but it's impossible to discern and match + # the entries like we do with interconnect-names interconnects: minItems: 1 items: - description: Interconnect path from mdp0 (or a single mdp) port to the data bus - description: Interconnect path from mdp1 port to the data bus + - description: Interconnect path from CPU to the reg bus interconnect-names: -minItems: 1 -items: - - const: mdp0-mem - - const: mdp1-mem +oneOf: + - minItems: 1 +items: + - const: mdp0-mem + - const: cpu-cfg + + - minItems: 2 +items: + - const: mdp0-mem + - const: mdp1-mem + - const: cpu-cfg resets: items: -- 2.43.0
[drm-misc:for-linux-next 2/3] drivers/gpu/drm/nouveau/nouveau_sched.c:21:34: error: 'DRM_SCHED_PRIORITY_MIN' undeclared here (not in a function); did you mean 'DRM_SCHED_PRIORITY_HIGH'?
Hi Luben, FYI, the error/warning was bisected to this commit, please ignore it if it's irrelevant. tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next head: 38f922a563aac3148ac73e73689805917f034cb5 commit: fe375c74806dbd30b00ec038a80a5b7bf4653ab7 [2/3] drm/sched: Rename priority MIN to LOW config: i386-buildonly-randconfig-001-20231125 (https://download.01.org/0day-ci/archive/20231125/202311251951.tdzber5f-...@intel.com/config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231125/202311251951.tdzber5f-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202311251951.tdzber5f-...@intel.com/ All errors (new ones prefixed by >>): >> drivers/gpu/drm/nouveau/nouveau_sched.c:21:34: error: >> 'DRM_SCHED_PRIORITY_MIN' undeclared here (not in a function); did you mean >> 'DRM_SCHED_PRIORITY_HIGH'? 21 | NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN, | ^~ | DRM_SCHED_PRIORITY_HIGH vim +21 drivers/gpu/drm/nouveau/nouveau_sched.c b88baab828713c Danilo Krummrich 2023-08-04 16 5f03a507b29e44 Danilo Krummrich 2023-11-14 17 /* Starts at 0, since the DRM scheduler interprets those parameters as (initial) 5f03a507b29e44 Danilo Krummrich 2023-11-14 18 * index to the run-queue array. 5f03a507b29e44 Danilo Krummrich 2023-11-14 19 */ 5f03a507b29e44 Danilo Krummrich 2023-11-14 20 enum nouveau_sched_priority { 5f03a507b29e44 Danilo Krummrich 2023-11-14 @21 NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN, 5f03a507b29e44 Danilo Krummrich 2023-11-14 22 NOUVEAU_SCHED_PRIORITY_COUNT, 5f03a507b29e44 Danilo Krummrich 2023-11-14 23 }; 5f03a507b29e44 Danilo Krummrich 2023-11-14 24 :: The code at line 21 was first introduced by commit :: 5f03a507b29e44a848f315c7240c19894dd8be4f drm/nouveau: implement 1:1 scheduler - entity relationship :: TO: Danilo Krummrich :: CC: Danilo Krummrich -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH v2] drm/virtio: Add suppport for non-native buffer formats
On 25 November 2023 at 01:22 pm, Christian Zigotzky wrote: On 25 November 2023 at 12:09 pm, John Paul Adrian Glaubitz wrote: On Sat, 2023-11-25 at 11:06 +0100, Christian Zigotzky wrote: Could you please revert the v2 patch because of the issue with the virtio-mouse-pci cursor? I will try to use the v1 patch for the RC3 of kernel 6.7. I don't understand why the v2 patch should yield any different results as the only change compared to v1 is the fixed patch subject. There are no functional differences, I just diffed the patches against each other: --- geert-patch-v1.patch 2023-11-25 12:09:19.122936658 +0100 +++ geert-patch-v2.patch 2023-11-25 12:09:36.313039085 +0100 @@ -34,6 +34,9 @@ Suggested-by: Gerd Hoffmann Signed-off-by: Geert Uytterhoeven --- +v2: + - Fix truncated one-line summary. +--- drivers/gpu/drm/virtio/virtgpu_display.c | 11 +-- drivers/gpu/drm/virtio/virtgpu_plane.c | 6 -- 2 files changed, 13 insertions(+), 4 deletions(-) Adrian Hi Adrian, Thank you for the hint. I think you are right. I use the following patch. --- a/drivers/gpu/drm/drm_client.c 2023-11-13 01:19:07.0 +0100 +++ b/drivers/gpu/drm/drm_client.c 2023-11-14 09:45:44.964199272 +0100 @@ -400,6 +400,16 @@ static int drm_client_buffer_addfb(struc fb_req.width = width; fb_req.height = height; + if (client->dev->mode_config.quirk_addfb_prefer_host_byte_order) { + if (format == DRM_FORMAT_XRGB) + format = DRM_FORMAT_HOST_XRGB; + if (format == DRM_FORMAT_ARGB) + format = DRM_FORMAT_HOST_ARGB; + if (format == DRM_FORMAT_RGB565) + format = DRM_FORMAT_HOST_RGB565; + if (format == DRM_FORMAT_XRGB1555) + format = DRM_FORMAT_HOST_XRGB1555; + } fb_req.pixel_format = format; fb_req.handles[0] = handle; fb_req.pitches[0] = buffer->pitch; This patch solved the issue. Christian This was the first solution and it works without any problems. Christian
Re: [PATCH v2] drm/virtio: Add suppport for non-native buffer formats
On 25 November 2023 at 12:09 pm, John Paul Adrian Glaubitz wrote: On Sat, 2023-11-25 at 11:06 +0100, Christian Zigotzky wrote: Could you please revert the v2 patch because of the issue with the virtio-mouse-pci cursor? I will try to use the v1 patch for the RC3 of kernel 6.7. I don't understand why the v2 patch should yield any different results as the only change compared to v1 is the fixed patch subject. There are no functional differences, I just diffed the patches against each other: --- geert-patch-v1.patch2023-11-25 12:09:19.122936658 +0100 +++ geert-patch-v2.patch2023-11-25 12:09:36.313039085 +0100 @@ -34,6 +34,9 @@ Suggested-by: Gerd Hoffmann Signed-off-by: Geert Uytterhoeven --- +v2: + - Fix truncated one-line summary. +--- drivers/gpu/drm/virtio/virtgpu_display.c | 11 +-- drivers/gpu/drm/virtio/virtgpu_plane.c | 6 -- 2 files changed, 13 insertions(+), 4 deletions(-) Adrian Hi Adrian, Thank you for the hint. I think you are right. I use the the following patch. --- a/drivers/gpu/drm/drm_client.c 2023-11-13 01:19:07.0 +0100 +++ b/drivers/gpu/drm/drm_client.c 2023-11-14 09:45:44.964199272 +0100 @@ -400,6 +400,16 @@ static int drm_client_buffer_addfb(struc fb_req.width = width; fb_req.height = height; + if (client->dev->mode_config.quirk_addfb_prefer_host_byte_order) { + if (format == DRM_FORMAT_XRGB) + format = DRM_FORMAT_HOST_XRGB; + if (format == DRM_FORMAT_ARGB) + format = DRM_FORMAT_HOST_ARGB; + if (format == DRM_FORMAT_RGB565) + format = DRM_FORMAT_HOST_RGB565; + if (format == DRM_FORMAT_XRGB1555) + format = DRM_FORMAT_HOST_XRGB1555; + } fb_req.pixel_format = format; fb_req.handles[0] = handle; fb_req.pitches[0] = buffer->pitch; This patch solved the issue. Christian
Re: [PATCH v2] drm/virtio: Add suppport for non-native buffer formats
On Sat, 2023-11-25 at 11:06 +0100, Christian Zigotzky wrote: > Could you please revert the v2 patch because of the issue with the > virtio-mouse-pci cursor? I will try to use the v1 patch for the RC3 of > kernel 6.7. I don't understand why the v2 patch should yield any different results as the only change compared to v1 is the fixed patch subject. There are no functional differences, I just diffed the patches against each other: --- geert-patch-v1.patch2023-11-25 12:09:19.122936658 +0100 +++ geert-patch-v2.patch2023-11-25 12:09:36.313039085 +0100 @@ -34,6 +34,9 @@ Suggested-by: Gerd Hoffmann Signed-off-by: Geert Uytterhoeven --- +v2: + - Fix truncated one-line summary. +--- drivers/gpu/drm/virtio/virtgpu_display.c | 11 +-- drivers/gpu/drm/virtio/virtgpu_plane.c | 6 -- 2 files changed, 13 insertions(+), 4 deletions(-) Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2] drm/virtio: Add suppport for non-native buffer formats
On 19 November 2023 at 07:33 pm, Geert Uytterhoeven wrote: Hi Christian, On Sun, Nov 19, 2023 at 5:28 PM Christian Zigotzky wrote: On 16 November 2023 at 03:44 pm, Gerd Hoffmann wrote: On Thu, Nov 16, 2023 at 02:16:54PM +0100, Geert Uytterhoeven wrote: When using virtgpu on a big-endian machine, e.g. powerpc QEMU: virtio-pci :00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2) or m68k/virt: virtio-mmio virtio-mmio.125: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2) and the graphical display fails to come up. Before, the call to drm_mode_addfb() caused a translation from a fourcc format (XR24) to a bpp/depth pair (32/24) to a potentially different fourcc format (BX24 on big-endian), due to the quirk processing in drm_driver_legacy_fb_format(). After, the original fourcc format (XR24) is passed unmodified. However, the virtgpu DRM driver supports only a single format for its main plane: DRM_FORMAT_HOST_XRGB, which is XR24 on little-endian, and BX24 on big-endian. I.e. on big-endian, virtgpu does not support XR24, which is the default DRM format, and must be supported by all drivers. Before, this was reported, but didn't lead to a failure: virtio-mmio virtio-mmio.125: [drm] bpp/depth value of 32/24 not supported virtio-mmio virtio-mmio.125: [drm] No compatible format found As the core virtgpu driver and device support both XR24 and BX24 on both little-endian and big-endian just fine, fix this extending the list of supported formats for main plane and cursor plane to XR24/BX24 resp. AR24/BA24. Fixes: 6ae2ff23aa43a0c4 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()") Reported-by: Christian Zigotzky Closes: https://lore.kernel.org/r/c47fba21-3ae9-4021-9f4a-09c2670eb...@xenosoft.de Suggested-by: Gerd Hoffmann Signed-off-by: Geert Uytterhoeven Reviewed-by: Gerd Hoffmann The new patch works but I don't see the virtio-mouse-pci pointer anymore. I see the pointer with -device usb-tablet. Please check the second patch. I will use the first patch for the RC2 of kernel 6.7. That's probably partially explained by commit 99748ab64fcc8578 ("drm: virtio: fix virtio_gpu_cursor_formats"), which forced BA24 for the cursor plane on big-endian, but unfortunately linked thread doesn't contain the full picture. Where is the default cursor format defined? I see virtio_gpu_mode_dumb_create() still defaults to DRM_FORMAT_HOST_XRGB. However, that can't be the cause, as the cursor formats require an alpha channel. Gr{oetje,eeting}s, Geert Hi Geert, Could you please revert the v2 patch because of the issue with the virtio-mouse-pci cursor? I will try to use the v1 patch for the RC3 of kernel 6.7. Thanks, Christian
Re: [PATCH v2] fbdev/fsl-diu-fb: Fix srapse warning due to virt_to_phys() prototype change
On 11/21/23 01:01, Stanislav Kinsburskii wrote: Explicitly cast __iomem pointer to const void* with __force to fix the following warning: incorrect type in argument 1 (different address spaces) expected void const volatile *address got char [noderef] __iomem *screen_base Signed-off-by: Stanislav Kinsburskii Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202311161120.bgyxtbmq-...@intel.com/ --- drivers/video/fbdev/fsl-diu-fb.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c index 7fbd9f069ac2..b0fda5bd1964 100644 --- a/drivers/video/fbdev/fsl-diu-fb.c +++ b/drivers/video/fbdev/fsl-diu-fb.c @@ -877,7 +877,7 @@ static int map_video_memory(struct fb_info *info) } mutex_lock(>mm_lock); info->screen_base = p; - info->fix.smem_start = virt_to_phys(info->screen_base); + info->fix.smem_start = virt_to_phys((__force const void *)info->screen_base); info->fix.smem_len = smem_len; mutex_unlock(>mm_lock); info->screen_size = info->fix.smem_len; applied to fbdev git tree (with some typos corrected). Helge
Re: [PATCH] video: fbdev: mmp: Fix typo in code comment
On 11/24/23 16:34, Randy Dunlap wrote: Hi, On 11/24/23 01:52, Dario Binacchi wrote: s/singals/signals/ Fixes: 641b4b1b6a7c ("video: mmpdisp: add spi port in display controller") Signed-off-by: Dario Binacchi --- drivers/video/fbdev/mmp/hw/mmp_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/mmp/hw/mmp_spi.c b/drivers/video/fbdev/mmp/hw/mmp_spi.c index 16401eb95c6c..64e34b7e739e 100644 --- a/drivers/video/fbdev/mmp/hw/mmp_spi.c +++ b/drivers/video/fbdev/mmp/hw/mmp_spi.c @@ -91,7 +91,7 @@ static int lcd_spi_setup(struct spi_device *spi) writel(tmp, reg_base + LCD_SPU_SPI_CTRL); /* -* After set mode it need a time to pull up the spi singals, +* After set mode it need a time to pull up the spi signals, Also: it needs time or it needs some time I've fixed it up and applied that patch to fbdev git tree. Thanks! Helge