[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
