[PATCH v2] drm/sced: Add FIFO sched policy to rq
Poblem: Given many entities competing for same rq on
same scheduler an uncceptabliy long wait time for some
jobs waiting stuck in rq before being picked up are
observed (seen using GPUVis).
The issue is due to Round Robin policy used by scheduler
to pick up the next entity for execution. Under stress
of many entities and long job queus within entity some
jobs could be stack for very long time in it's entity's
queue before being popped from the queue and executed
while for other entites with samller job queues a job
might execute ealier even though that job arrived later
then the job in the long queue.
Fix:
Add FIFO selection policy to entites in RQ, chose next enitity
on rq in such order that if job on one entity arrived
ealrier then job on another entity the first job will start
executing ealier regardless of the length of the entity's job
queue.
v2:
Switch to rb tree structure for entites based on TS of
oldest job waiting in job queue of enitity. Improves next
enitity extraction to O(1). Enitity TS update
O(log(number of entites in rq))
Drop default option in module control parameter.
Signed-off-by: Andrey Grodzovsky
Tested-by: Li Yunxiang (Teddy)
---
drivers/gpu/drm/scheduler/sched_entity.c | 29 -
drivers/gpu/drm/scheduler/sched_main.c | 131 ++-
include/drm/gpu_scheduler.h | 29 +
3 files changed, 183 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 191c56064f19..65ae4be2248b 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -33,6 +33,8 @@
#define to_drm_sched_job(sched_job)\
container_of((sched_job), struct drm_sched_job, queue_node)
+extern int drm_sched_policy;
+
/**
* drm_sched_entity_init - Init a context entity used by scheduler when
* submit to HW ring.
@@ -73,6 +75,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
entity->priority = priority;
entity->sched_list = num_sched_list > 1 ? sched_list : NULL;
entity->last_scheduled = NULL;
+ RB_CLEAR_NODE(>rb_tree_node);
if(num_sched_list)
entity->rq = _list[0]->sched_rq[entity->priority];
@@ -417,14 +420,16 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct
drm_sched_entity *entity)
sched_job = to_drm_sched_job(spsc_queue_peek(>job_queue));
if (!sched_job)
- return NULL;
+ goto skip;
while ((entity->dependency =
drm_sched_job_dependency(sched_job, entity))) {
trace_drm_sched_job_wait_dep(sched_job, entity->dependency);
- if (drm_sched_entity_add_dependency_cb(entity))
- return NULL;
+ if (drm_sched_entity_add_dependency_cb(entity)) {
+ sched_job = NULL;
+ goto skip;
+ }
}
/* skip jobs from entity that marked guilty */
@@ -443,6 +448,17 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct
drm_sched_entity *entity)
smp_wmb();
spsc_queue_pop(>job_queue);
+
+ /*
+* It's when head job is extracted we can access the next job (or empty)
+* queue and update the entity location in the min heap accordingly.
+*/
+skip:
+ if (drm_sched_policy == 1)
+ drm_sched_rq_update_fifo(entity,
+(sched_job ? sched_job->submit_ts :
ktime_get()),
+false);
+
return sched_job;
}
@@ -502,11 +518,13 @@ void drm_sched_entity_push_job(struct drm_sched_job
*sched_job)
{
struct drm_sched_entity *entity = sched_job->entity;
bool first;
+ ktime_t ts = ktime_get();
trace_drm_sched_job(sched_job, entity);
atomic_inc(entity->rq->sched->score);
WRITE_ONCE(entity->last_user, current->group_leader);
first = spsc_queue_push(>job_queue, _job->queue_node);
+ sched_job->submit_ts = ts;
/* first job wakes up scheduler */
if (first) {
@@ -518,8 +536,13 @@ void drm_sched_entity_push_job(struct drm_sched_job
*sched_job)
DRM_ERROR("Trying to push to a killed entity\n");
return;
}
+
drm_sched_rq_add_entity(entity->rq, entity);
spin_unlock(>rq_lock);
+
+ if (drm_sched_policy == 1)
+ drm_sched_rq_update_fifo(entity, ts, false);
+
drm_sched_wakeup(entity->rq->sched);
}
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index c5437ee03e3f..4d2450b3f5bd 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -62,6 +62,62 @@
#define to_drm_sched_job(sched_job)\
Re: [PATCH V2 0/2] chrontel-ch7033: Add byteswap order option
Hi Rob, On Fri, Sep 02, 2022 at 06:21:50PM +0200, Robert Foss wrote: > On Fri, 2 Sept 2022 at 17:39, Chris Morgan wrote: > > > > From: Chris Morgan > > > > This series adds the ability to set the byteswap order in the chrontel > > ch7033 driver via an optional devicetree node. This is necessary > > because the HDMI DIP of the NTC CHIP requires a byteswap order that > > differs from the default value of the driver. > > > > Changes from V1: > > > > - Updated devicetree documentation to be easier to understand. > > > > Signed-off-by: Chris Morgan > > > > Chris Morgan (2): > > dt-bindings: Add byteswap order to chrontel ch7033 > > drm/bridge: chrontel-ch7033: Add byteswap order setting > > > > .../bindings/display/bridge/chrontel,ch7033.yaml | 13 + > > drivers/gpu/drm/bridge/chrontel-ch7033.c | 15 +-- > > 2 files changed, 26 insertions(+), 2 deletions(-) > > Applied to drm-misc-next. I've just reviewed the series, and I don't think this is right. Patch 2/2 has a small issue that could be fixed on top, but more importantly, I don't think this belongs to DT. See the reply to 1/2. -- Regards, Laurent Pinchart
Re: [PATCH V2 1/2] dt-bindings: Add byteswap order to chrontel ch7033
Hi Chris, Thank you for the patch. On Fri, Sep 02, 2022 at 10:39:05AM -0500, Chris Morgan wrote: > From: Chris Morgan > > Update dt-binding documentation to add support for setting byteswap of > chrontel ch7033. > > New property name of chrontel,byteswap added to set the byteswap order. > This property is optional. > > Signed-off-by: Chris Morgan > Reviewed-by: Robert Foss > --- > .../bindings/display/bridge/chrontel,ch7033.yaml| 13 + > 1 file changed, 13 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml > b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml > index bb6289c7d375..984b90893583 100644 > --- a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml > @@ -14,6 +14,19 @@ properties: >compatible: > const: chrontel,ch7033 > > + chrontel,byteswap: > +$ref: /schemas/types.yaml#/definitions/uint8 > +enum: > + - 0 # BYTE_SWAP_RGB > + - 1 # BYTE_SWAP_RBG > + - 2 # BYTE_SWAP_GRB > + - 3 # BYTE_SWAP_GBR > + - 4 # BYTE_SWAP_BRG > + - 5 # BYTE_SWAP_BGR > +description: | > + Set the byteswap value of the bridge. This is optional and if not > + set value of BYTE_SWAP_BGR is used. I don't think this belongs to the device tree. The source of data connected to the CH7033 input could use different formats. This shouldn't be hardcoded, but queried at runtime, using the input and output media bus formats infrastructure that the DRM bridge framework includes. > + >reg: > maxItems: 1 > description: I2C address of the device -- Regards, Laurent Pinchart
Re: [PATCH V2 2/2] drm/bridge: chrontel-ch7033: Add byteswap order setting
Hi Chris,
Thank you for the patch.
On Fri, Sep 02, 2022 at 10:39:06AM -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> Add the option to set the byteswap order in the devicetree. For the
> official HDMI DIP for the NTC CHIP the byteswap order needs to be
> RGB, however the driver sets it as BGR. With this patch the driver
> will remain at BGR unless manually specified via devicetree.
>
> Signed-off-by: Chris Morgan
> Reviewed-by: Robert Foss
> ---
> drivers/gpu/drm/bridge/chrontel-ch7033.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c
> b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> index ba060277c3fd..c5719908ce2d 100644
> --- a/drivers/gpu/drm/bridge/chrontel-ch7033.c
> +++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> @@ -68,6 +68,7 @@ enum {
> BYTE_SWAP_GBR = 3,
> BYTE_SWAP_BRG = 4,
> BYTE_SWAP_BGR = 5,
> + BYTE_SWAP_MAX = 6,
> };
>
> /* Page 0, Register 0x19 */
> @@ -355,6 +356,8 @@ static void ch7033_bridge_mode_set(struct drm_bridge
> *bridge,
> int hsynclen = mode->hsync_end - mode->hsync_start;
> int vbporch = mode->vsync_start - mode->vdisplay;
> int vsynclen = mode->vsync_end - mode->vsync_start;
> + u8 byte_swap;
> + int ret;
>
> /*
>* Page 4
> @@ -398,8 +401,16 @@ static void ch7033_bridge_mode_set(struct drm_bridge
> *bridge,
> regmap_write(priv->regmap, 0x15, vbporch);
> regmap_write(priv->regmap, 0x16, vsynclen);
>
> - /* Input color swap. */
> - regmap_update_bits(priv->regmap, 0x18, SWAP, BYTE_SWAP_BGR);
> + /* Input color swap. Byte order is optional and will default to
> + * BYTE_SWAP_BGR to preserve backwards compatibility with existing
> + * driver.
> + */
> + ret = of_property_read_u8(priv->bridge.of_node, "chrontel,byteswap",
> + _swap);
That's quite inefficient, please parse the device tree at probe time,
and cache the value.
> + if (!ret && byte_swap < BYTE_SWAP_MAX)
> + regmap_update_bits(priv->regmap, 0x18, SWAP, byte_swap);
> + else
> + regmap_update_bits(priv->regmap, 0x18, SWAP, BYTE_SWAP_BGR);
>
> /* Input clock and sync polarity. */
> regmap_update_bits(priv->regmap, 0x19, 0x1, mode->clock >> 16);
--
Regards,
Laurent Pinchart
[PATCH v2 08/12] drm/i915: Handle each GT on init/release and suspend/resume
In preparation for enabling a second GT, there are a number of GT/uncore
operations that happen during initialization or suspend flows that need
to be performed on each GT, not just the primary,
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 59 +-
1 file changed, 42 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index bb9ba1aed1bb..e5c3cf5045d4 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -310,8 +310,13 @@ static void intel_detect_preproduction_hw(struct
drm_i915_private *dev_priv)
static void sanitize_gpu(struct drm_i915_private *i915)
{
- if (!INTEL_INFO(i915)->gpu_reset_clobbers_display)
- __intel_gt_reset(to_gt(i915), ALL_ENGINES);
+ if (!INTEL_INFO(i915)->gpu_reset_clobbers_display) {
+ struct intel_gt *gt;
+ unsigned int i;
+
+ for_each_gt(gt, i915, i)
+ __intel_gt_reset(gt, ALL_ENGINES);
+ }
}
/**
@@ -730,6 +735,8 @@ static void i915_driver_hw_remove(struct drm_i915_private
*dev_priv)
static void i915_driver_register(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = _priv->drm;
+ struct intel_gt *gt;
+ unsigned int i;
i915_gem_driver_register(dev_priv);
i915_pmu_register(dev_priv);
@@ -749,7 +756,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
- intel_gt_driver_register(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_driver_register(gt);
intel_display_driver_register(dev_priv);
@@ -768,6 +776,9 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
*/
static void i915_driver_unregister(struct drm_i915_private *dev_priv)
{
+ struct intel_gt *gt;
+ unsigned int i;
+
i915_switcheroo_unregister(dev_priv);
intel_unregister_dsm_handler();
@@ -777,7 +788,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
intel_display_driver_unregister(dev_priv);
- intel_gt_driver_unregister(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_driver_unregister(gt);
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
@@ -799,6 +811,8 @@ static void i915_welcome_messages(struct drm_i915_private
*dev_priv)
{
if (drm_debug_enabled(DRM_UT_DRIVER)) {
struct drm_printer p = drm_debug_printer("i915 device info:");
+ struct intel_gt *gt;
+ unsigned int i;
drm_printf(, "pciid=0x%04x rev=0x%02x platform=%s
(subplatform=0x%x) gen=%i\n",
INTEL_DEVID(dev_priv),
@@ -811,7 +825,8 @@ static void i915_welcome_messages(struct drm_i915_private
*dev_priv)
intel_device_info_print(INTEL_INFO(dev_priv),
RUNTIME_INFO(dev_priv), );
i915_print_iommu_status(dev_priv, );
- intel_gt_info_print(_gt(dev_priv)->info, );
+ for_each_gt(gt, dev_priv, i)
+ intel_gt_info_print(>info, );
}
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
@@ -1230,13 +1245,15 @@ static int i915_drm_suspend_late(struct drm_device
*dev, bool hibernation)
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
struct intel_runtime_pm *rpm = _priv->runtime_pm;
- int ret;
+ struct intel_gt *gt;
+ int ret, i;
disable_rpm_wakeref_asserts(rpm);
i915_gem_suspend_late(dev_priv);
- intel_uncore_suspend(_priv->uncore);
+ for_each_gt(gt, dev_priv, i)
+ intel_uncore_suspend(gt->uncore);
intel_power_domains_suspend(dev_priv,
get_suspend_mode(dev_priv, hibernation));
@@ -1368,7 +1385,8 @@ static int i915_drm_resume_early(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
- int ret;
+ struct intel_gt *gt;
+ int ret, i;
/*
* We have a resume ordering issue with the snd-hda driver also
@@ -1422,9 +1440,10 @@ static int i915_drm_resume_early(struct drm_device *dev)
drm_err(_priv->drm,
"Resume prepare failed: %d, continuing anyway\n", ret);
- intel_uncore_resume_early(_priv->uncore);
-
- intel_gt_check_and_clear_faults(to_gt(dev_priv));
+ for_each_gt(gt, dev_priv, i) {
+ intel_uncore_resume_early(gt->uncore);
+ intel_gt_check_and_clear_faults(gt);
+ }
[PATCH v2 07/12] drm/i915: Initialize MMIO access for each GT
In a multi-GT system we need to initialize MMIO access for each GT, not
just the primary GT.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 27 ++-
drivers/gpu/drm/i915/intel_uncore.c | 5 -
drivers/gpu/drm/i915/intel_uncore.h | 3 ++-
3 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 1f46dd1ffaf7..bb9ba1aed1bb 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -431,7 +431,8 @@ static void i915_driver_late_release(struct
drm_i915_private *dev_priv)
*/
static int i915_driver_mmio_probe(struct drm_i915_private *dev_priv)
{
- int ret;
+ struct intel_gt *gt;
+ int ret, i;
if (i915_inject_probe_failure(dev_priv))
return -ENODEV;
@@ -440,17 +441,27 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
if (ret < 0)
return ret;
- ret = intel_uncore_init_mmio(_priv->uncore);
- if (ret)
- return ret;
+ for_each_gt(gt, dev_priv, i) {
+ ret = intel_uncore_init_mmio(gt->uncore);
+ if (ret)
+ return ret;
+
+ ret = drmm_add_action_or_reset(_priv->drm,
+ intel_uncore_fini_mmio,
+ gt->uncore);
+ if (ret)
+ return ret;
+ }
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
intel_device_info_runtime_init(dev_priv);
- ret = intel_gt_init_mmio(to_gt(dev_priv));
- if (ret)
- goto err_uncore;
+ for_each_gt(gt, dev_priv, i) {
+ ret = intel_gt_init_mmio(gt);
+ if (ret)
+ goto err_uncore;
+ }
/* As early as possible, scrub existing GPU state before clobbering */
sanitize_gpu(dev_priv);
@@ -459,7 +470,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
err_uncore:
intel_teardown_mchbar(dev_priv);
- intel_uncore_fini_mmio(_priv->uncore);
return ret;
}
@@ -471,7 +481,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
static void i915_driver_mmio_release(struct drm_i915_private *dev_priv)
{
intel_teardown_mchbar(dev_priv);
- intel_uncore_fini_mmio(_priv->uncore);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 6841f76533f9..33bdcbc77ab2 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2454,8 +2454,11 @@ void intel_uncore_prune_engine_fw_domains(struct
intel_uncore *uncore,
}
}
-void intel_uncore_fini_mmio(struct intel_uncore *uncore)
+/* Called via drm-managed action */
+void intel_uncore_fini_mmio(struct drm_device *dev, void *data)
{
+ struct intel_uncore *uncore = data;
+
if (intel_uncore_has_forcewake(uncore)) {
iosf_mbi_punit_acquire();
iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index 6100d0f4498a..4acb78a03233 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -33,6 +33,7 @@
#include "i915_reg_defs.h"
+struct drm_device;
struct drm_i915_private;
struct intel_runtime_pm;
struct intel_uncore;
@@ -220,7 +221,7 @@ void intel_uncore_prune_engine_fw_domains(struct
intel_uncore *uncore,
bool intel_uncore_unclaimed_mmio(struct intel_uncore *uncore);
bool intel_uncore_arm_unclaimed_mmio_detection(struct intel_uncore *uncore);
void intel_uncore_cleanup_mmio(struct intel_uncore *uncore);
-void intel_uncore_fini_mmio(struct intel_uncore *uncore);
+void intel_uncore_fini_mmio(struct drm_device *dev, void *data);
void intel_uncore_suspend(struct intel_uncore *uncore);
void intel_uncore_resume_early(struct intel_uncore *uncore);
void intel_uncore_runtime_resume(struct intel_uncore *uncore);
--
2.37.2
[PATCH v2 11/12] drm/i915/mtl: Use primary GT's irq lock for media GT
When we hook up interrupts (in the next patch), interrupts for the media
GT are still processed as part of the primary GT's interrupt flow. As
such, we should share the same IRQ lock with the primary GT. Let's
convert gt->irq_lock into a pointer and just point the media GT's
instance at the same lock the primary GT is using.
v2:
- Point media's gt->irq_lock at the primary GT lock properly. (Daniele)
- Fix jump target for intel_root_gt_init_early errors. (Daniele)
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +++---
drivers/gpu/drm/i915/gt/intel_gt.c| 15 +--
drivers/gpu/drm/i915/gt/intel_gt.h| 2 +-
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 16 ++--
drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 8 +++---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 26 +--
drivers/gpu/drm/i915/gt/intel_sa_media.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 24 -
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +--
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +--
drivers/gpu/drm/i915/i915_driver.c| 5 +++-
drivers/gpu/drm/i915/i915_irq.c | 4 +--
drivers/gpu/drm/i915/pxp/intel_pxp.c | 4 +--
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 14 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 4 +--
16 files changed, 78 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 41acc285e8bf..6e0122b3dca2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1688,9 +1688,9 @@ bool intel_engine_irq_enable(struct intel_engine_cs
*engine)
return false;
/* Caller disables interrupts */
- spin_lock(>gt->irq_lock);
+ spin_lock(engine->gt->irq_lock);
engine->irq_enable(engine);
- spin_unlock(>gt->irq_lock);
+ spin_unlock(engine->gt->irq_lock);
return true;
}
@@ -1701,9 +1701,9 @@ void intel_engine_irq_disable(struct intel_engine_cs
*engine)
return;
/* Caller disables interrupts */
- spin_lock(>gt->irq_lock);
+ spin_lock(engine->gt->irq_lock);
engine->irq_disable(engine);
- spin_unlock(>gt->irq_lock);
+ spin_unlock(engine->gt->irq_lock);
}
void intel_engines_reset_default_submission(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index a6ed11b933eb..b5c187eb9c2e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -37,7 +37,7 @@
void intel_gt_common_init_early(struct intel_gt *gt)
{
- spin_lock_init(>irq_lock);
+ spin_lock_init(gt->irq_lock);
INIT_LIST_HEAD(>closed_vma);
spin_lock_init(>closed_lock);
@@ -58,14 +58,19 @@ void intel_gt_common_init_early(struct intel_gt *gt)
}
/* Preliminary initialization of Tile 0 */
-void intel_root_gt_init_early(struct drm_i915_private *i915)
+int intel_root_gt_init_early(struct drm_i915_private *i915)
{
struct intel_gt *gt = to_gt(i915);
gt->i915 = i915;
gt->uncore = >uncore;
+ gt->irq_lock = drmm_kzalloc(>drm, sizeof(*gt->irq_lock),
GFP_KERNEL);
+ if (!gt->irq_lock)
+ return -ENOMEM;
intel_gt_common_init_early(gt);
+
+ return 0;
}
static int intel_gt_probe_lmem(struct intel_gt *gt)
@@ -792,12 +797,18 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
+ spinlock_t *irq_lock;
uncore = drmm_kzalloc(>i915->drm, sizeof(*uncore),
GFP_KERNEL);
if (!uncore)
return -ENOMEM;
+ irq_lock = drmm_kzalloc(>i915->drm, sizeof(*irq_lock),
GFP_KERNEL);
+ if (!irq_lock)
+ return -ENOMEM;
+
gt->uncore = uncore;
+ gt->irq_lock = irq_lock;
intel_gt_common_init_early(gt);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index c9a359f35d0f..2ee582e287c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -45,7 +45,7 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
}
void intel_gt_common_init_early(struct intel_gt *gt);
-void intel_root_gt_init_early(struct drm_i915_private *i915);
+int intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
int intel_gt_init_mmio(struct intel_gt *gt);
int __must_check intel_gt_init_hw(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index
[PATCH v2 10/12] drm/i915/xelpmp: Expose media as another GT
Xe_LPM+ platforms have "standalone media." I.e., the media unit is
designed as an additional GT with its own engine list, GuC, forcewake,
etc. Let's allow platforms to include media GTs in their device info.
v2:
- Simplify GSI register handling and split it out to a separate patch
for ease of review. (Daniele)
Cc: Aravind Iddamsetty
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 +
drivers/gpu/drm/i915/gt/intel_sa_media.c | 39
drivers/gpu/drm/i915/gt/intel_sa_media.h | 15 +
drivers/gpu/drm/i915/i915_pci.c | 15 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c | 4 +++
7 files changed, 83 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..e83e4cd46968 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -123,6 +123,7 @@ gt-y += \
gt/intel_ring.o \
gt/intel_ring_submission.o \
gt/intel_rps.o \
+ gt/intel_sa_media.o \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index d414785003cc..fb2c56777480 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1578,4 +1578,12 @@
#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
+/*
+ * Standalone Media's non-engine GT registers are located at their regular GT
+ * offsets plus 0x38. This extra offset is stored inside the intel_uncore
+ * structure so that the existing code can be used for both GTs without
+ * modification.
+ */
+#define MTL_MEDIA_GSI_BASE 0x38
+
#endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c
b/drivers/gpu/drm/i915/gt/intel_sa_media.c
new file mode 100644
index ..8c5c519457cc
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_sa_media.h"
+
+int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t phys_addr,
+ u32 gsi_offset)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_uncore *uncore;
+
+ uncore = drmm_kzalloc(>drm, sizeof(*uncore), GFP_KERNEL);
+ if (!uncore)
+ return -ENOMEM;
+
+ uncore->gsi_offset = gsi_offset;
+
+ intel_gt_common_init_early(gt);
+ intel_uncore_init_early(uncore, gt);
+
+ /*
+* Standalone media shares the general MMIO space with the primary
+* GT. We'll re-use the primary GT's mapping.
+*/
+ uncore->regs = i915->uncore.regs;
+ if (drm_WARN_ON(>drm, uncore->regs == NULL))
+ return -EIO;
+
+ gt->uncore = uncore;
+ gt->phys_addr = phys_addr;
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.h
b/drivers/gpu/drm/i915/gt/intel_sa_media.h
new file mode 100644
index ..3afb310de932
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+#ifndef __INTEL_SA_MEDIA__
+#define __INTEL_SA_MEDIA__
+
+#include
+
+struct intel_gt;
+
+int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t phys_addr,
+ u32 gsi_offset);
+
+#endif /* __INTEL_SA_MEDIA_H__ */
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 26b25d9434d6..18d3722331e4 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -26,6 +26,9 @@
#include
#include
+#include "gt/intel_gt_regs.h"
+#include "gt/intel_sa_media.h"
+
#include "i915_driver.h"
#include "i915_drv.h"
#include "i915_pci.h"
@@ -1115,6 +1118,17 @@ static const struct intel_device_info pvc_info = {
.display.has_cdclk_crawl = 1, \
.__runtime.fbc_mask = BIT(INTEL_FBC_A) | BIT(INTEL_FBC_B)
+static const struct intel_gt_definition xelpmp_extra_gt[] = {
+ {
+ .type = GT_MEDIA,
+ .name = "Standalone Media GT",
+ .setup = intel_sa_mediagt_setup,
+ .gsi_offset = MTL_MEDIA_GSI_BASE,
+ .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
+ },
+ {}
+};
+
__maybe_unused
static const struct intel_device_info mtl_info = {
XE_HP_FEATURES,
@@ -1128,6 +1142,7 @@ static const struct intel_device_info mtl_info = {
.media.ver = 13,
PLATFORM(INTEL_METEORLAKE),
[PATCH v2 04/12] drm/i915: Prepare more multi-GT initialization
We're going to introduce an additional intel_gt for MTL's media unit
soon. Let's provide a bit more multi-GT initialization framework in
preparation for that. The initialization will pull the list of GTs for
a platform from the device info structure. Although necessary for the
immediate MTL media enabling, this same framework will also be used
farther down the road when we enable remote tiles on xehpsdv and pvc.
v2:
- Re-add missing test for !HAS_EXTRA_GT_LIST in intel_gt_probe_all().
Cc: Aravind Iddamsetty
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 51 +--
drivers/gpu/drm/i915/gt/intel_gt.h| 1 -
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_device_info.h | 16 ++
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
7 files changed, 70 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 275ad72940c1..41acc285e8bf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -736,7 +736,7 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
u16 vdbox_mask;
u16 vebox_mask;
- info->engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
+ GEM_BUG_ON(!info->engine_mask);
if (GRAPHICS_VER(i915) < 11)
return info->engine_mask;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index cf7aab7adb30..7b880dbed6ce 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -807,17 +807,16 @@ static void
intel_gt_tile_cleanup(struct intel_gt *gt)
{
intel_uncore_cleanup_mmio(gt->uncore);
-
- if (!gt_is_root(gt))
- kfree(gt);
}
int intel_gt_probe_all(struct drm_i915_private *i915)
{
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct intel_gt *gt = >gt0;
+ const struct intel_gt_definition *gtdef;
phys_addr_t phys_addr;
unsigned int mmio_bar;
+ unsigned int i;
int ret;
mmio_bar = GRAPHICS_VER(i915) == 2 ? GEN2_GTTMMADR_BAR : GTTMMADR_BAR;
@@ -828,14 +827,58 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
* and it has been already initialized early during probe
* in i915_driver_probe()
*/
+ gt->i915 = i915;
+ gt->name = "Primary GT";
+ gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
+
+ drm_dbg(>drm, "Setting up %s\n", gt->name);
ret = intel_gt_tile_setup(gt, phys_addr);
if (ret)
return ret;
i915->gt[0] = gt;
- /* TODO: add more tiles */
+ if (!HAS_EXTRA_GT_LIST(i915))
+ return 0;
+
+ for (i = 1, gtdef = _INFO(i915)->extra_gt_list[i - 1];
+gtdef->setup != NULL;
+i++, gtdef = _INFO(i915)->extra_gt_list[i - 1]) {
+ gt = drmm_kzalloc(>drm, sizeof(*gt), GFP_KERNEL);
+ if (!gt) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ gt->i915 = i915;
+ gt->name = gtdef->name;
+ gt->type = gtdef->type;
+ gt->info.engine_mask = gtdef->engine_mask;
+ gt->info.id = i;
+
+ drm_dbg(>drm, "Setting up %s\n", gt->name);
+ if (GEM_WARN_ON(range_overflows_t(resource_size_t,
+ gtdef->mapping_base,
+ SZ_16M,
+ pci_resource_len(pdev,
mmio_bar {
+ ret = -ENODEV;
+ goto err;
+ }
+
+ ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
+ if (ret)
+ goto err;
+
+ i915->gt[i] = gt;
+ }
+
return 0;
+
+err:
+ i915_probe_error(i915, "Failed to initialize %s! (%d)\n", gtdef->name,
ret);
+ intel_gt_release_all(i915);
+
+ return ret;
}
int intel_gt_tiles_init(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 40b06adf509a..4d8779529cc2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -54,7 +54,6 @@ void intel_gt_driver_register(struct intel_gt *gt);
void intel_gt_driver_unregister(struct intel_gt *gt);
void intel_gt_driver_remove(struct intel_gt *gt);
void intel_gt_driver_release(struct intel_gt *gt);
-
void intel_gt_driver_late_release_all(struct drm_i915_private *i915);
int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
diff --git
[PATCH v2 12/12] drm/i915/mtl: Hook up interrupts for standalone media
Top-level handling of standalone media interrupts will be processed as
part of the primary GT's interrupt handler (since primary and media GTs
share an MMIO space, unlike remote tile setups). When we get down to
the point of handling engine interrupts, we need to take care to lookup
VCS and VECS engines in the media GT rather than the primary.
There are also a couple of additional "other" instance bits that
correspond to the media GT's GuC and media GT's power management
interrupts; we need to direct those to the media GT instance as well.
Bspec: 45605
Cc: Anusha Srivatsa
Signed-off-by: Matt Roper
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 19 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
drivers/gpu/drm/i915/gt/intel_sa_media.c | 7 +++
drivers/gpu/drm/i915/i915_drv.h | 3 +++
4 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 0dfd0c42d00d..f26882fdc24c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -59,11 +59,17 @@ static void
gen11_other_irq_handler(struct intel_gt *gt, const u8 instance,
const u16 iir)
{
+ struct intel_gt *media_gt = gt->i915->media_gt;
+
if (instance == OTHER_GUC_INSTANCE)
return guc_irq_handler(>uc.guc, iir);
+ if (instance == OTHER_MEDIA_GUC_INSTANCE && media_gt)
+ return guc_irq_handler(_gt->uc.guc, iir);
if (instance == OTHER_GTPM_INSTANCE)
return gen11_rps_irq_handler(>rps, iir);
+ if (instance == OTHER_MEDIA_GTPM_INSTANCE && media_gt)
+ return gen11_rps_irq_handler(_gt->rps, iir);
if (instance == OTHER_KCR_INSTANCE)
return intel_pxp_irq_handler(>pxp, iir);
@@ -81,6 +87,18 @@ gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
{
struct intel_engine_cs *engine;
+ /*
+* Platforms with standalone media have their media engines in another
+* GT.
+*/
+ if (MEDIA_VER(gt->i915) >= 13 &&
+ (class == VIDEO_DECODE_CLASS || class == VIDEO_ENHANCEMENT_CLASS)) {
+ if (!gt->i915->media_gt)
+ goto err;
+
+ gt = gt->i915->media_gt;
+ }
+
if (instance <= MAX_ENGINE_INSTANCE)
engine = gt->engine_class[class][instance];
else
@@ -89,6 +107,7 @@ gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
if (likely(engine))
return intel_engine_cs_irq(engine, iir);
+err:
WARN_ONCE(1, "unhandled engine interrupt class=0x%x, instance=0x%x\n",
class, instance);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index fb2c56777480..2275ee47da95 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1554,6 +1554,8 @@
#define OTHER_GTPM_INSTANCE 1
#define OTHER_KCR_INSTANCE 4
#define OTHER_GSC_INSTANCE 6
+#define OTHER_MEDIA_GUC_INSTANCE 16
+#define OTHER_MEDIA_GTPM_INSTANCE17
#define GEN11_IIR_REG_SELECTOR(x) _MMIO(0x190070 + ((x) * 4))
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c
b/drivers/gpu/drm/i915/gt/intel_sa_media.c
index 5516e9c363a4..e8f3d18c12b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_sa_media.c
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
@@ -36,5 +36,12 @@ int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t
phys_addr,
gt->uncore = uncore;
gt->phys_addr = phys_addr;
+ /*
+* For current platforms we can assume there's only a single
+* media GT and cache it for quick lookup.
+*/
+ drm_WARN_ON(>drm, i915->media_gt);
+ i915->media_gt = gt;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d4b45c7e931d..5a21242a6706 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -365,6 +365,9 @@ struct drm_i915_private {
struct kobject *sysfs_gt;
+ /* Quick lookup of media GT (current platforms only have one) */
+ struct intel_gt *media_gt;
+
struct {
struct i915_gem_contexts {
spinlock_t lock; /* locks list */
--
2.37.2
[PATCH v2 09/12] drm/i915/uncore: Add GSI offset to uncore
GT non-engine registers (referred to as "GSI" registers by the spec)
have the same relative offsets on standalone media as they do on the
primary GT, just with an additional "GSI offset" added to their MMIO
address. If we store this GSI offset in the standalone media's
intel_uncore structure, it can be automatically applied to all GSI reg
reads/writes that happen on that GT, allowing us to re-use our existing
GT code with minimal changes.
Forcewake and shadowed register tables for the media GT (which will be
added in a future patch) are listed as final addresses that already
include the GSI offset, so we also need to add the GSI offset before
doing lookups of registers in one of those tables.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 17 ++---
drivers/gpu/drm/i915/intel_device_info.h | 4 +++-
drivers/gpu/drm/i915/intel_uncore.c | 10 --
drivers/gpu/drm/i915/intel_uncore.h | 22 --
4 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index fbb5e32979a4..a6ed11b933eb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -776,10 +776,20 @@ void intel_gt_driver_late_release_all(struct
drm_i915_private *i915)
}
}
-static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)
+/*
+ * Note: the gsi_offset parameter here isn't used, but we want to keep the
+ * function signature equivalent to gtdef->setup() so that it can be plugged
+ * in when we enabled remote tiles in the future.
+ */
+static int intel_gt_tile_setup(struct intel_gt *gt,
+ phys_addr_t phys_addr,
+ u32 gsi_offset)
{
int ret;
+ /* GSI offset is only applicable for media GTs */
+ drm_WARN_ON(>i915->drm, gsi_offset);
+
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
@@ -832,7 +842,7 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
drm_dbg(>drm, "Setting up %s\n", gt->name);
- ret = intel_gt_tile_setup(gt, phys_addr);
+ ret = intel_gt_tile_setup(gt, phys_addr, 0);
if (ret)
return ret;
@@ -865,7 +875,8 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
goto err;
}
- ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
+ ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base,
+ gtdef->gsi_offset);
if (ret)
goto err;
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index b408ce384cd7..85e0ef0e91b1 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -254,8 +254,10 @@ struct intel_gt_definition {
enum intel_gt_type type;
char *name;
int (*setup)(struct intel_gt *gt,
-phys_addr_t phys_addr);
+phys_addr_t phys_addr,
+u32 gsi_offset);
u32 mapping_base;
+ u32 gsi_offset;
intel_engine_mask_t engine_mask;
};
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 33bdcbc77ab2..ecb02421502d 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -927,6 +927,9 @@ find_fw_domain(struct intel_uncore *uncore, u32 offset)
{
const struct intel_forcewake_range *entry;
+ if (IS_GSI_REG(offset))
+ offset += uncore->gsi_offset;
+
entry = BSEARCH(offset,
uncore->fw_domains_table,
uncore->fw_domains_table_entries,
@@ -1142,6 +1145,9 @@ static bool is_shadowed(struct intel_uncore *uncore, u32
offset)
if (drm_WARN_ON(>i915->drm, !uncore->shadowed_reg_table))
return false;
+ if (IS_GSI_REG(offset))
+ offset += uncore->gsi_offset;
+
return BSEARCH(offset,
uncore->shadowed_reg_table,
uncore->shadowed_reg_table_entries,
@@ -1994,8 +2000,8 @@ static int __fw_domain_init(struct intel_uncore *uncore,
d->uncore = uncore;
d->wake_count = 0;
- d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set);
- d->reg_ack = uncore->regs + i915_mmio_reg_offset(reg_ack);
+ d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set) +
uncore->gsi_offset;
+ d->reg_ack = uncore->regs + i915_mmio_reg_offset(reg_ack) +
uncore->gsi_offset;
d->id = domain_id;
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index 4acb78a03233..7f1d7903a8f3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++
[PATCH v2 05/12] drm/i915: Rename and expose common GT early init routine
The common early GT init is needed for initialization of all GT types
(root/primary, remote tile, standalone media). Since standalone media
(coming in the next patch) will be implemented in a separate file,
rename and expose the function for use.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt.c | 6 +++---
drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 7b880dbed6ce..fbb5e32979a4 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -35,7 +35,7 @@
#include "intel_uncore.h"
#include "shmem_utils.h"
-static void __intel_gt_init_early(struct intel_gt *gt)
+void intel_gt_common_init_early(struct intel_gt *gt)
{
spin_lock_init(>irq_lock);
@@ -65,7 +65,7 @@ void intel_root_gt_init_early(struct drm_i915_private *i915)
gt->i915 = i915;
gt->uncore = >uncore;
- __intel_gt_init_early(gt);
+ intel_gt_common_init_early(gt);
}
static int intel_gt_probe_lmem(struct intel_gt *gt)
@@ -789,7 +789,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
gt->uncore = uncore;
- __intel_gt_init_early(gt);
+ intel_gt_common_init_early(gt);
}
intel_uncore_init_early(gt->uncore, gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 4d8779529cc2..c9a359f35d0f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -44,6 +44,7 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
return container_of(gsc, struct intel_gt, gsc);
}
+void intel_gt_common_init_early(struct intel_gt *gt);
void intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
int intel_gt_init_mmio(struct intel_gt *gt);
--
2.37.2
[PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
Moving the locking for MMIO debug (and the final check for unclaimed
accesses when resuming debug after a userspace-initiated forcewake) will
make it simpler to completely skip MMIO debug handling on uncores that
don't support it in future patches.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 9b81b2543ce2..e717ea55484a 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
intel_uncore_mmio_debug *mmio_debug)
mmio_debug->unclaimed_mmio_check = 1;
}
-static void mmio_debug_suspend(struct intel_uncore_mmio_debug *mmio_debug)
+static void mmio_debug_suspend(struct intel_uncore *uncore)
{
- lockdep_assert_held(_debug->lock);
+ spin_lock(>debug->lock);
/* Save and disable mmio debugging for the user bypass */
- if (!mmio_debug->suspend_count++) {
- mmio_debug->saved_mmio_check = mmio_debug->unclaimed_mmio_check;
- mmio_debug->unclaimed_mmio_check = 0;
+ if (!uncore->debug->suspend_count++) {
+ uncore->debug->saved_mmio_check =
uncore->debug->unclaimed_mmio_check;
+ uncore->debug->unclaimed_mmio_check = 0;
}
+
+ spin_unlock(>debug->lock);
}
-static void mmio_debug_resume(struct intel_uncore_mmio_debug *mmio_debug)
+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
+
+static void mmio_debug_resume(struct intel_uncore *uncore)
{
- lockdep_assert_held(_debug->lock);
+ spin_lock(>debug->lock);
+
+ if (!--uncore->debug->suspend_count)
+ uncore->debug->unclaimed_mmio_check =
uncore->debug->saved_mmio_check;
- if (!--mmio_debug->suspend_count)
- mmio_debug->unclaimed_mmio_check = mmio_debug->saved_mmio_check;
+ if (check_for_unclaimed_mmio(uncore))
+ drm_info(>i915->drm,
+"Invalid mmio detected during user access\n");
+
+ spin_unlock(>debug->lock);
}
static const char * const forcewake_domain_names[] = {
@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct intel_uncore
*uncore)
spin_lock_irq(>lock);
if (!uncore->user_forcewake_count++) {
intel_uncore_forcewake_get__locked(uncore, FORCEWAKE_ALL);
- spin_lock(>debug->lock);
- mmio_debug_suspend(uncore->debug);
- spin_unlock(>debug->lock);
+ mmio_debug_suspend(uncore);
}
spin_unlock_irq(>lock);
}
@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct intel_uncore
*uncore)
{
spin_lock_irq(>lock);
if (!--uncore->user_forcewake_count) {
- spin_lock(>debug->lock);
- mmio_debug_resume(uncore->debug);
-
- if (check_for_unclaimed_mmio(uncore))
- drm_info(>i915->drm,
-"Invalid mmio detected during user access\n");
- spin_unlock(>debug->lock);
-
+ mmio_debug_resume(uncore);
intel_uncore_forcewake_put__locked(uncore, FORCEWAKE_ALL);
}
spin_unlock_irq(>lock);
--
2.37.2
[PATCH v2 02/12] drm/i915: Only hook up uncore->debug for primary uncore
The original intent of intel_uncore_mmio_debug as described in commit
0a9b26306d6a ("drm/i915: split out uncore_mmio_debug") was to be a
singleton structure that could be shared between multiple GTs' uncore
objects in a multi-tile system. Somehow we went off track and
started allocating separate instances of this structure for each GT,
which defeats that original goal.
But in reality, there isn't even a need to share the mmio_debug between
multiple GTs; on all modern platforms (i.e., everything after gen7)
unclaimed register accesses are something that can only be detected for
display registers. There's no point in grabbing the debug spinlock and
checking for unclaimed accesses on an uncore used by an xehpsdv or pvc
remote tile GT, or the uncore used by a mtl standalone media GT since
all of the display accesses go through the primary intel_uncore.
The simplest solution is to simply leave uncore->debug NULL on all
intel_uncore instances except for the primary one. This will allow us
to avoid the pointless debug spinlock acquisition we've been doing on
MMIO accesses coming in through these intel_uncores.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt.c | 9 -
drivers/gpu/drm/i915/i915_driver.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 23 ++-
drivers/gpu/drm/i915/intel_uncore.h | 3 +--
4 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index e4bac2431e41..a82b5e2e0d83 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -781,21 +781,13 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
int ret;
if (!gt_is_root(gt)) {
- struct intel_uncore_mmio_debug *mmio_debug;
struct intel_uncore *uncore;
uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
if (!uncore)
return -ENOMEM;
- mmio_debug = kzalloc(sizeof(*mmio_debug), GFP_KERNEL);
- if (!mmio_debug) {
- kfree(uncore);
- return -ENOMEM;
- }
-
gt->uncore = uncore;
- gt->uncore->debug = mmio_debug;
__intel_gt_init_early(gt);
}
@@ -817,7 +809,6 @@ intel_gt_tile_cleanup(struct intel_gt *gt)
intel_uncore_cleanup_mmio(gt->uncore);
if (!gt_is_root(gt)) {
- kfree(gt->uncore->debug);
kfree(gt->uncore);
kfree(gt);
}
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 56a2bcddb2af..18acba1bc3b0 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -326,7 +326,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
intel_device_info_subplatform_init(dev_priv);
intel_step_init(dev_priv);
- intel_uncore_mmio_debug_init_early(_priv->mmio_debug);
+ intel_uncore_mmio_debug_init_early(dev_priv);
spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->gpu_error.lock);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e717ea55484a..6841f76533f9 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -44,14 +44,19 @@ fw_domains_get(struct intel_uncore *uncore, enum
forcewake_domains fw_domains)
}
void
-intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug)
+intel_uncore_mmio_debug_init_early(struct drm_i915_private *i915)
{
- spin_lock_init(_debug->lock);
- mmio_debug->unclaimed_mmio_check = 1;
+ spin_lock_init(>mmio_debug.lock);
+ i915->mmio_debug.unclaimed_mmio_check = 1;
+
+ i915->uncore.debug = >mmio_debug;
}
static void mmio_debug_suspend(struct intel_uncore *uncore)
{
+ if (!uncore->debug)
+ return;
+
spin_lock(>debug->lock);
/* Save and disable mmio debugging for the user bypass */
@@ -67,6 +72,9 @@ static bool check_for_unclaimed_mmio(struct intel_uncore
*uncore);
static void mmio_debug_resume(struct intel_uncore *uncore)
{
+ if (!uncore->debug)
+ return;
+
spin_lock(>debug->lock);
if (!--uncore->debug->suspend_count)
@@ -1705,7 +1713,7 @@ unclaimed_reg_debug(struct intel_uncore *uncore,
const bool read,
const bool before)
{
- if (likely(!uncore->i915->params.mmio_debug))
+ if (likely(!uncore->i915->params.mmio_debug) || !uncore->debug)
return;
/* interrupts are disabled and re-enabled around uncore->lock usage */
@@ -2267,7 +2275,6 @@ void intel_uncore_init_early(struct intel_uncore *uncore,
uncore->i915 = gt->i915;
uncore->gt = gt;
uncore->rpm =
[PATCH v2 03/12] drm/i915: Use managed allocations for extra uncore objects
We're slowly transitioning the init-time kzalloc's of the driver over to
DRM-managed allocations; let's make sure the uncore objects allocated
for non-root GTs are thus allocated.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index a82b5e2e0d83..cf7aab7adb30 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -783,7 +783,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
- uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
+ uncore = drmm_kzalloc(>i915->drm, sizeof(*uncore),
GFP_KERNEL);
if (!uncore)
return -ENOMEM;
@@ -808,10 +808,8 @@ intel_gt_tile_cleanup(struct intel_gt *gt)
{
intel_uncore_cleanup_mmio(gt->uncore);
- if (!gt_is_root(gt)) {
- kfree(gt->uncore);
+ if (!gt_is_root(gt))
kfree(gt);
- }
}
int intel_gt_probe_all(struct drm_i915_private *i915)
--
2.37.2
[PATCH v2 00/12] i915: Add "standalone media" support for MTL
Starting with MTL, media functionality has moved into a new, second GT
at the hardware level. This new GT, referred to as "standalone media"
in the spec, has its own GuC, power management/forcewake, etc. The
general non-engine GT registers for standalone media start at 0x38,
but otherwise use the same MMIO offsets as the primary GT.
Standalone media has a lot of similarity to the remote tiles
present on platforms like xehpsdv and pvc, and our i915 implementation
can share much of the general "multi GT" infrastructure between the two
types of platforms. However there are a few notable differences
we must deal with:
- The 0x38 offset only applies to the non-engine GT registers
(which the specs refer to as "GSI" registers). The engine registers
remain at their usual locations (e.g., 0x1C for VCS0).
- Unlike platforms with remote tiles, all interrupt handling for
standalone media still happens via the primary GT.
v2:
- Added new patches to ensure each GT, not just the primary, is
handled properly during various init/suspend/resume/teardown flows.
- Simplified GSI offset handling and split it into its own patch.
- Correct gt->irq_lock assignment for media GT.
- Fix jump target for intel_root_gt_init_early() errors.
Cc: Radhakrishna Sripada
Cc: Daniele Ceraolo Spurio
Cc: Aravind Iddamsetty
Matt Roper (12):
drm/i915: Move locking and unclaimed check into
mmio_debug_{suspend,resume}
drm/i915: Only hook up uncore->debug for primary uncore
drm/i915: Use managed allocations for extra uncore objects
drm/i915: Prepare more multi-GT initialization
drm/i915: Rename and expose common GT early init routine
drm/i915: Use a DRM-managed action to release the PCI bridge device
drm/i915: Initialize MMIO access for each GT
drm/i915: Handle each GT on init/release and suspend/resume
drm/i915/uncore: Add GSI offset to uncore
drm/i915/xelpmp: Expose media as another GT
drm/i915/mtl: Use primary GT's irq lock for media GT
drm/i915/mtl: Hook up interrupts for standalone media
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 10 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 96
drivers/gpu/drm/i915/gt/intel_gt.h| 4 +-
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 35 --
drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 8 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 10 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 5 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 26 ++---
drivers/gpu/drm/i915/gt/intel_sa_media.c | 47
drivers/gpu/drm/i915/gt/intel_sa_media.h | 15 +++
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 24 ++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/i915_driver.c| 105 --
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_irq.c | 4 +-
drivers/gpu/drm/i915/i915_pci.c | 15 +++
drivers/gpu/drm/i915/intel_device_info.h | 19
drivers/gpu/drm/i915/intel_uncore.c | 83 +-
drivers/gpu/drm/i915/intel_uncore.h | 28 -
drivers/gpu/drm/i915/pxp/intel_pxp.c | 4 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 14 +--
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 4 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
25 files changed, 424 insertions(+), 147 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h
--
2.37.2
[PATCH v2 06/12] drm/i915: Use a DRM-managed action to release the PCI bridge device
As we start supporting multiple uncore structures in future patches, the
MMIO cleanup (which make also get called mid-init if there's a failure)
will become more complicated. Moving to DRM-managed actions will help
keep things simple.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 18acba1bc3b0..1f46dd1ffaf7 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -105,6 +105,12 @@ static const char irst_name[] = "INT3392";
static const struct drm_driver i915_drm_driver;
+static void i915_release_bridge_dev(struct drm_device *dev,
+ void *bridge)
+{
+ pci_dev_put(bridge);
+}
+
static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
{
int domain = pci_domain_nr(to_pci_dev(dev_priv->drm.dev)->bus);
@@ -115,7 +121,9 @@ static int i915_get_bridge_dev(struct drm_i915_private
*dev_priv)
drm_err(_priv->drm, "bridge device not found\n");
return -EIO;
}
- return 0;
+
+ return drmm_add_action_or_reset(_priv->drm, i915_release_bridge_dev,
+ dev_priv->bridge_dev);
}
/* Allocate space for the MCH regs if needed, return nonzero on error */
@@ -452,7 +460,6 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
err_uncore:
intel_teardown_mchbar(dev_priv);
intel_uncore_fini_mmio(_priv->uncore);
- pci_dev_put(dev_priv->bridge_dev);
return ret;
}
@@ -465,7 +472,6 @@ static void i915_driver_mmio_release(struct
drm_i915_private *dev_priv)
{
intel_teardown_mchbar(dev_priv);
intel_uncore_fini_mmio(_priv->uncore);
- pci_dev_put(dev_priv->bridge_dev);
}
/**
--
2.37.2
Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"
On 9/2/22 10:38, Michał Winiarski wrote: > On Fri, Sep 02, 2022 at 04:03:20PM +0300, Jani Nikula wrote: >> On Fri, 02 Sep 2022, Maxime Ripard wrote: >>> On Fri, Sep 02, 2022 at 11:04:14AM +0300, Jani Nikula wrote: On Thu, 01 Sep 2022, Maíra Canal wrote: > Hi Maxime, > > On 9/1/22 09:55, Maxime Ripard wrote: >> Hi, >> >> On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote: >>> With the introduction of KUnit, IGT is no longer the only option to run >>> the DRM unit tests, as the tests can be run through kunit-tool or on >>> real hardware with CONFIG_KUNIT. >>> >>> Therefore, remove the "igt_" prefix from the tests and replace it with >>> the "test_drm_" prefix, making the tests' names independent from the >>> tool >>> used. >>> >>> Signed-off-by: Maíra Canal >>> >>> --- >>> v1 -> v2: >>> https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/ >>> - Change "drm_" prefix to "test_drm_", as "drm_" can be a bit confusing >>> (Jani Nikula). >> >> I appreciate it's a bit of a bikeshed but I disagree with this. The >> majority of the kunit tests already out there start with the framework >> name, including *all* the examples in the kunit doc. Plus, it's fairly >> obvious that it's a test, kunit is only about running tests in the first >> place. > > Would it be better to keep it as "drm_"? That's not "keeping". That's renaming igt to drm. >>> >>> Well, there's like half the tests that are prefixed with drm, the other >>> with igt, so it's both really >>> > Currently, I don't think it is appropriate to hold the "igt_" prefix, as > the tests are not IGT exclusive, but I don't have a strong opinion on > using the "drm_" or the "test_drm" prefixes. I repeat my stance that "drm_" alone is confusing. >>> >>> What are you confusing it with? >>> For the reason alone that it pollutes the code tagging tools, mixing actual drm_ types and functions with unit test functions. >>> >>> I don't get it, I'm sorry. All these functions are static and not part >>> of any API, so I can't see how it would pollute a code tagging tool. Or >>> at least, not more than any driver does. >>> >>> And we're part of a larger project here, it's about consistency with the >>> rest of the ecosystem. >> >> Okay, so I'm just going to explain what I mean, but say "whatever" right >> after and move on. >> >> For example, drm_buddy_test.c includes drm_buddy.h so with the igt_ -> >> drm_ rename none of the test functions may clash with the drm_buddy_ >> prefixed existing functions. Ditto for all tests similarly. >> >> For example drm_buddy_alloc_range() as a name sounds like something that >> allocs a range, not something that tests range allocation. On the other >> hand, you have drm_buddy_alloc_blocks() which is actually a real >> drm_buddy function, not a test. What would you call a test that tests >> that? Here, we end up with names that are all prefixed drm_buddy and you >> won't know what's the actual function and what's the test unless you >> look it up. >> >> I use code tagging that I can use for finding and completing >> e.g. functions. Currently I have the following completions, for >> igt_buddy_ and drm_buddy_, respectively: >> >> Possible completions are: >> igt_buddy_alloc_limitigt_buddy_alloc_optimistic >> igt_buddy_alloc_pathological >> igt_buddy_alloc_pessimistic igt_buddy_alloc_range igt_buddy_alloc_smoke >> >> Possible completions are: >> drm_buddy_alloc_blocks drm_buddy_block >> drm_buddy_block_is_allocateddrm_buddy_block_is_free >> drm_buddy_block_is_split drm_buddy_block_offset drm_buddy_block_order >> drm_buddy_block_print >> drm_buddy_block_size drm_buddy_block_state drm_buddy_block_trim >> drm_buddy_fini >> drm_buddy_free_block drm_buddy_free_list drm_buddy_init >> drm_buddy_init_test >> drm_buddy_module_exitdrm_buddy_module_init drm_buddy_print >> >> With the patch at hand, they'll all be lumped under drm_buddy_ >> completions, and some of them will be actual drm buddy functions and >> some not. >> >> I just find it a very odd convention to name the tests in a way that's >> indistinguishable from the real things. Even *within* drm_buddy_test.c >> where you read the test code. Because currently you do have calls to >> igt_buddy_ prefixed functions from other igt_buddy_ prefixed functions, >> along with the drm_buddy_ prefixed calls. I think it's just going to be >> a mess. >> >> /rant >> >> Whatever. Moving on. > > KUnit docs [1] state: > https://docs.kernel.org/dev-tools/kunit/style.html#test-cases > "As tests are themselves functions, their names cannot conflict with other > C identifiers in the kernel. This may require some creative naming." > And give examples of names. But this should be local to individual test suite > - > as long as the test
[PATCH v4.1] drm/i915: Move display and media IP version to runtime info
Future platforms can read the IP version from a register and the
IP version numbers need not be hard coded in device info. Move the
ip version for media and display to runtime info.
On platforms where hard coding of IP version is required, update
the IP version in __runtime under device_info.
v2:
- Avoid name collision for ip versions(Jani)
v4.1:
- Fix build error in mock_gem_device.c
Suggested-by: Jani Nikula
Cc: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/i915_drv.h | 14 +++
drivers/gpu/drm/i915/i915_pci.c | 38 +--
drivers/gpu/drm/i915/intel_device_info.c | 28 +-
drivers/gpu/drm/i915/intel_device_info.h | 15 +---
.../gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
5 files changed, 54 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9cca165bf5d..f85a470397a5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -469,19 +469,19 @@ static inline struct intel_gt *to_gt(struct
drm_i915_private *i915)
#define IP_VER(ver, rel) ((ver) << 8 | (rel))
-#define GRAPHICS_VER(i915) (RUNTIME_INFO(i915)->graphics.ver)
-#define GRAPHICS_VER_FULL(i915)
IP_VER(RUNTIME_INFO(i915)->graphics.ver, \
- RUNTIME_INFO(i915)->graphics.rel)
+#define GRAPHICS_VER(i915)
(RUNTIME_INFO(i915)->graphics.version.ver)
+#define GRAPHICS_VER_FULL(i915)
IP_VER(RUNTIME_INFO(i915)->graphics.version.ver, \
+
RUNTIME_INFO(i915)->graphics.version.rel)
#define IS_GRAPHICS_VER(i915, from, until) \
(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
-#define MEDIA_VER(i915)(INTEL_INFO(i915)->media.ver)
-#define MEDIA_VER_FULL(i915) IP_VER(INTEL_INFO(i915)->media.ver, \
- INTEL_INFO(i915)->media.rel)
+#define MEDIA_VER(i915)
(RUNTIME_INFO(i915)->media.version.ver)
+#define MEDIA_VER_FULL(i915)
IP_VER(RUNTIME_INFO(i915)->media.version.ver, \
+
RUNTIME_INFO(i915)->media.version.rel)
#define IS_MEDIA_VER(i915, from, until) \
(MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))
-#define DISPLAY_VER(i915) (INTEL_INFO(i915)->display.ver)
+#define DISPLAY_VER(i915) (RUNTIME_INFO(i915)->display.version.ver)
#define IS_DISPLAY_VER(i915, from, until) \
(DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 26b25d9434d6..f6aaf938c53c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -34,9 +34,9 @@
#define PLATFORM(x) .platform = (x)
#define GEN(x) \
- .__runtime.graphics.ver = (x), \
- .media.ver = (x), \
- .display.ver = (x)
+ .__runtime.graphics.version.ver = (x), \
+ .__runtime.media.version.ver = (x), \
+ .__runtime.display.version.ver = (x)
#define I845_PIPE_OFFSETS \
.display.pipe_offsets = { \
@@ -740,7 +740,7 @@ static const struct intel_device_info bxt_info = {
static const struct intel_device_info glk_info = {
GEN9_LP_FEATURES,
PLATFORM(INTEL_GEMINILAKE),
- .display.ver = 10,
+ .__runtime.display.version.ver = 10,
.display.dbuf.size = 1024 - 4, /* 4 blocks for bypass path allocation */
GLK_COLORS,
};
@@ -919,7 +919,7 @@ static const struct intel_device_info rkl_info = {
static const struct intel_device_info dg1_info = {
GEN12_FEATURES,
DGFX_FEATURES,
- .__runtime.graphics.rel = 10,
+ .__runtime.graphics.version.rel = 10,
PLATFORM(INTEL_DG1),
.__runtime.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) |
BIT(PIPE_D),
.require_force_probe = 1,
@@ -962,7 +962,7 @@ static const struct intel_device_info adl_s_info = {
.display.has_hotplug = 1,
\
.display.has_ipc = 1,
\
.display.has_psr = 1,
\
- .display.ver = 13,
\
+ .__runtime.display.version.ver = 13,
\
.__runtime.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) |
BIT(PIPE_D), \
.display.pipe_offsets = {
\
[TRANSCODER_A] = PIPE_A_OFFSET,
\
@@ -1006,8 +1006,8 @@ static const struct intel_device_info adl_p_info = {
I915_GTT_PAGE_SIZE_2M
#define XE_HP_FEATURES \
- .__runtime.graphics.ver = 12, \
-
Re: [git pull] drm fixes for 6.0-rc4
The pull request you sent on Fri, 2 Sep 2022 11:48:36 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-09-02 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1e8e515edd6dbe15b86003d846fee005c12c0685 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] drm/dp: Avoid Reading DPCD_REV Before Native Aux Read
Reviewed-by: Lyude Paul
On Wed, 2022-08-31 at 18:13 -0400, Fangzhi Zuo wrote:
> The attempt to read DPCD_REV before any native aux read breaks
> majority of DP2 compliance.
>
> The spec. requires DP_SINK_STATUS to be polled for the reset status
> DP_INTRA_HOP_AUX_REPLY_INDICATION during the clear training stage.
>
> Polling DP_SINK_STATUS each time gets DPCD_REV read first
> that makes non link training regsiter DPCD_REV get read
> during UHBR link training. It violates DP2 compliance.
>
> Cc: Ville Syrjala
> Cc: Lyude Paul
> Signed-off-by: Fangzhi Zuo
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index e7c22c2ca90c..c7aa5bafa667 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -571,24 +571,6 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux,
> unsigned int offset,
> {
> int ret;
>
> - /*
> - * HP ZR24w corrupts the first DPCD access after entering power save
> - * mode. Eg. on a read, the entire buffer will be filled with the same
> - * byte. Do a throw away read to avoid corrupting anything we care
> - * about. Afterwards things will work correctly until the monitor
> - * gets woken up and subsequently re-enters power save mode.
> - *
> - * The user pressing any button on the monitor is enough to wake it
> - * up, so there is no particularly good place to do the workaround.
> - * We just have to do it before any DPCD access and hope that the
> - * monitor doesn't power down exactly after the throw away read.
> - */
> - if (!aux->is_remote) {
> - ret = drm_dp_dpcd_probe(aux, DP_DPCD_REV);
> - if (ret < 0)
> - return ret;
> - }
> -
> if (aux->is_remote)
> ret = drm_dp_mst_dpcd_read(aux, offset, buffer, size);
> else
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH 1/3] iommu/dma: Clean up Kconfig
On Tue, Aug 16, 2022 at 06:28:03PM +0100, Robin Murphy wrote: > Although iommu-dma is a per-architecture chonce, that is currently > implemented in a rather haphazard way. Selecting from the arch Kconfig > was the original logical approach, but is complicated by having to > manage dependencies; conversely, selecting from drivers ends up hiding > the architecture dependency *too* well. Instead, let's just have it > enable itself automatically when IOMMU API support is enabled for the > relevant architectures. It can't get much clearer than that. > > Signed-off-by: Robin Murphy > --- > arch/arm64/Kconfig | 1 - For this change: Acked-by: Catalin Marinas
Re: [PATCH 2/3] iommu/dma: Move public interfaces to linux/iommu.h
On Tue, Aug 16, 2022 at 06:28:04PM +0100, Robin Murphy wrote: > The iommu-dma layer is now mostly encapsulated by iommu_dma_ops, with > only a couple more public interfaces left pertaining to MSI integration. > Since these depend on the main IOMMU API header anyway, move their > declarations there, taking the opportunity to update the half-baked > comments to proper kerneldoc along the way. > > Signed-off-by: Robin Murphy > --- > > Note that iommu_setup_dma_ops() should also become internal in a future > phase of the great IOMMU API upheaval - for now as the last bit of true > arch code glue I consider it more "necessarily exposed" than "public". > > arch/arm64/mm/dma-mapping.c | 2 +- And here: Acked-by: Catalin Marinas
Re: [Freedreno] [PATCH v1 3/4] drm/msm/mdp4: move resource allocation to the _probe function
On 9/2/2022 12:05 PM, Dmitry Baryshkov wrote:
On Fri, 2 Sept 2022 at 21:07, Abhinav Kumar wrote:
On 9/1/2022 11:06 PM, Dmitry Baryshkov wrote:
On 2 September 2022 03:24:17 GMT+03:00, Abhinav Kumar
wrote:
On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:
To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
probe callback. While we are at it, replace irq_of_parse_and_map() with
platform_get_irq().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 107 +++
1 file changed, 51 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 41dc60784847..6499713eccf6 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -139,8 +139,6 @@ static void mdp4_destroy(struct msm_kms *kms)
pm_runtime_disable(dev);
mdp_kms_destroy(_kms->base);
-
- kfree(mdp4_kms);
}
static const struct mdp_kms_funcs kms_funcs = {
@@ -383,57 +381,27 @@ static int mdp4_kms_init(struct drm_device *dev)
{
struct platform_device *pdev = to_platform_device(dev->dev);
struct msm_drm_private *priv = dev->dev_private;
- struct mdp4_kms *mdp4_kms;
+ struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(priv->kms));
struct msm_kms *kms = NULL;
struct iommu_domain *iommu;
struct msm_gem_address_space *aspace;
- int irq, ret;
+ int ret;
u32 major, minor;
unsigned long max_clk;
/* TODO: Chips that aren't apq8064 have a 200 Mhz max_clk */
max_clk = 27000;
-mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
- if (!mdp4_kms) {
- DRM_DEV_ERROR(dev->dev, "failed to allocate kms\n");
- return -ENOMEM;
- }
-
ret = mdp_kms_init(_kms->base, _funcs);
if (ret) {
DRM_DEV_ERROR(dev->dev, "failed to init kms\n");
goto fail;
}
-priv->kms = _kms->base.base;
kms = priv->kms;
mdp4_kms->dev = dev;
-mdp4_kms->mmio = msm_ioremap(pdev, NULL);
- if (IS_ERR(mdp4_kms->mmio)) {
- ret = PTR_ERR(mdp4_kms->mmio);
- goto fail;
- }
-
- irq = platform_get_irq(pdev, 0);
- if (irq < 0) {
- ret = irq;
- DRM_DEV_ERROR(dev->dev, "failed to get irq: %d\n", ret);
- goto fail;
- }
-
- kms->irq = irq;
-
- /* NOTE: driver for this regulator still missing upstream.. use
-* _get_exclusive() and ignore the error if it does not exist
-* (and hope that the bootloader left it on for us)
-*/
- mdp4_kms->vdd = devm_regulator_get_exclusive(>dev, "vdd");
- if (IS_ERR(mdp4_kms->vdd))
- mdp4_kms->vdd = NULL;
-
if (mdp4_kms->vdd) {
ret = regulator_enable(mdp4_kms->vdd);
if (ret) {
@@ -442,24 +410,6 @@ static int mdp4_kms_init(struct drm_device *dev)
}
}
-mdp4_kms->clk = devm_clk_get(>dev, "core_clk");
- if (IS_ERR(mdp4_kms->clk)) {
- DRM_DEV_ERROR(dev->dev, "failed to get core_clk\n");
- ret = PTR_ERR(mdp4_kms->clk);
- goto fail;
- }
-
- mdp4_kms->pclk = devm_clk_get(>dev, "iface_clk");
- if (IS_ERR(mdp4_kms->pclk))
- mdp4_kms->pclk = NULL;
-
- mdp4_kms->axi_clk = devm_clk_get(>dev, "bus_clk");
- if (IS_ERR(mdp4_kms->axi_clk)) {
- DRM_DEV_ERROR(dev->dev, "failed to get axi_clk\n");
- ret = PTR_ERR(mdp4_kms->axi_clk);
- goto fail;
- }
-
clk_set_rate(mdp4_kms->clk, max_clk);
read_mdp_hw_revision(mdp4_kms, , );
@@ -474,10 +424,9 @@ static int mdp4_kms_init(struct drm_device *dev)
mdp4_kms->rev = minor;
if (mdp4_kms->rev >= 2) {
- mdp4_kms->lut_clk = devm_clk_get(>dev, "lut_clk");
- if (IS_ERR(mdp4_kms->lut_clk)) {
+ if (!mdp4_kms->lut_clk) {
DRM_DEV_ERROR(dev->dev, "failed to get lut_clk\n");
- ret = PTR_ERR(mdp4_kms->lut_clk);
+ ret = -ENODEV;
goto fail;
}
clk_set_rate(mdp4_kms->lut_clk, max_clk);
@@ -560,7 +509,53 @@ static const struct dev_pm_ops mdp4_pm_ops = {
static int mdp4_probe(struct platform_device *pdev)
{
- return msm_drv_probe(>dev, mdp4_kms_init, NULL);
+ struct device *dev = >dev;
+ struct mdp4_kms *mdp4_kms;
+ int irq;
+
+ mdp4_kms = devm_kzalloc(dev, sizeof(*mdp4_kms), GFP_KERNEL);
+ if (!mdp4_kms)
+ return dev_err_probe(dev, -ENOMEM, "failed to allocate kms\n");
+
+ mdp4_kms->mmio = msm_ioremap(pdev, NULL);
+ if (IS_ERR(mdp4_kms->mmio))
+ return PTR_ERR(mdp4_kms->mmio);
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return dev_err_probe(dev, irq, "failed to get irq\n");
+
+ mdp4_kms->base.base.irq = irq;
+
+ /* NOTE: driver for this
Re: [PATCH v1 3/4] drm/msm/mdp4: move resource allocation to the _probe function
On Fri, 2 Sept 2022 at 21:07, Abhinav Kumar wrote:
>
>
>
> On 9/1/2022 11:06 PM, Dmitry Baryshkov wrote:
> >
> >
> > On 2 September 2022 03:24:17 GMT+03:00, Abhinav Kumar
> > wrote:
> >>
> >>
> >> On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:
> >>> To let the probe function bail early if any of the resources is
> >>> unavailable, move resource allocattion from kms_init directly to the
> >>> probe callback. While we are at it, replace irq_of_parse_and_map() with
> >>> platform_get_irq().
> >>>
> >>> Signed-off-by: Dmitry Baryshkov
> >>> ---
> >>>drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 107 +++
> >>>1 file changed, 51 insertions(+), 56 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
> >>> b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
> >>> index 41dc60784847..6499713eccf6 100644
> >>> --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
> >>> +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
> >>> @@ -139,8 +139,6 @@ static void mdp4_destroy(struct msm_kms *kms)
> >>> pm_runtime_disable(dev);
> >>> mdp_kms_destroy(_kms->base);
> >>> -
> >>> - kfree(mdp4_kms);
> >>>}
> >>> static const struct mdp_kms_funcs kms_funcs = {
> >>> @@ -383,57 +381,27 @@ static int mdp4_kms_init(struct drm_device *dev)
> >>>{
> >>> struct platform_device *pdev = to_platform_device(dev->dev);
> >>> struct msm_drm_private *priv = dev->dev_private;
> >>> - struct mdp4_kms *mdp4_kms;
> >>> + struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(priv->kms));
> >>> struct msm_kms *kms = NULL;
> >>> struct iommu_domain *iommu;
> >>> struct msm_gem_address_space *aspace;
> >>> - int irq, ret;
> >>> + int ret;
> >>> u32 major, minor;
> >>> unsigned long max_clk;
> >>> /* TODO: Chips that aren't apq8064 have a 200 Mhz max_clk */
> >>> max_clk = 27000;
> >>>-mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
> >>> - if (!mdp4_kms) {
> >>> - DRM_DEV_ERROR(dev->dev, "failed to allocate kms\n");
> >>> - return -ENOMEM;
> >>> - }
> >>> -
> >>> ret = mdp_kms_init(_kms->base, _funcs);
> >>> if (ret) {
> >>> DRM_DEV_ERROR(dev->dev, "failed to init kms\n");
> >>> goto fail;
> >>> }
> >>>-priv->kms = _kms->base.base;
> >>> kms = priv->kms;
> >>> mdp4_kms->dev = dev;
> >>>-mdp4_kms->mmio = msm_ioremap(pdev, NULL);
> >>> - if (IS_ERR(mdp4_kms->mmio)) {
> >>> - ret = PTR_ERR(mdp4_kms->mmio);
> >>> - goto fail;
> >>> - }
> >>> -
> >>> - irq = platform_get_irq(pdev, 0);
> >>> - if (irq < 0) {
> >>> - ret = irq;
> >>> - DRM_DEV_ERROR(dev->dev, "failed to get irq: %d\n", ret);
> >>> - goto fail;
> >>> - }
> >>> -
> >>> - kms->irq = irq;
> >>> -
> >>> - /* NOTE: driver for this regulator still missing upstream.. use
> >>> -* _get_exclusive() and ignore the error if it does not exist
> >>> -* (and hope that the bootloader left it on for us)
> >>> -*/
> >>> - mdp4_kms->vdd = devm_regulator_get_exclusive(>dev, "vdd");
> >>> - if (IS_ERR(mdp4_kms->vdd))
> >>> - mdp4_kms->vdd = NULL;
> >>> -
> >>> if (mdp4_kms->vdd) {
> >>> ret = regulator_enable(mdp4_kms->vdd);
> >>> if (ret) {
> >>> @@ -442,24 +410,6 @@ static int mdp4_kms_init(struct drm_device *dev)
> >>> }
> >>> }
> >>>-mdp4_kms->clk = devm_clk_get(>dev, "core_clk");
> >>> - if (IS_ERR(mdp4_kms->clk)) {
> >>> - DRM_DEV_ERROR(dev->dev, "failed to get core_clk\n");
> >>> - ret = PTR_ERR(mdp4_kms->clk);
> >>> - goto fail;
> >>> - }
> >>> -
> >>> - mdp4_kms->pclk = devm_clk_get(>dev, "iface_clk");
> >>> - if (IS_ERR(mdp4_kms->pclk))
> >>> - mdp4_kms->pclk = NULL;
> >>> -
> >>> - mdp4_kms->axi_clk = devm_clk_get(>dev, "bus_clk");
> >>> - if (IS_ERR(mdp4_kms->axi_clk)) {
> >>> - DRM_DEV_ERROR(dev->dev, "failed to get axi_clk\n");
> >>> - ret = PTR_ERR(mdp4_kms->axi_clk);
> >>> - goto fail;
> >>> - }
> >>> -
> >>> clk_set_rate(mdp4_kms->clk, max_clk);
> >>> read_mdp_hw_revision(mdp4_kms, , );
> >>> @@ -474,10 +424,9 @@ static int mdp4_kms_init(struct drm_device *dev)
> >>> mdp4_kms->rev = minor;
> >>> if (mdp4_kms->rev >= 2) {
> >>> - mdp4_kms->lut_clk = devm_clk_get(>dev, "lut_clk");
> >>> - if (IS_ERR(mdp4_kms->lut_clk)) {
> >>> + if (!mdp4_kms->lut_clk) {
> >>> DRM_DEV_ERROR(dev->dev, "failed to get lut_clk\n");
> >>> - ret = PTR_ERR(mdp4_kms->lut_clk);
> >>> + ret = -ENODEV;
> >>> goto fail;
> >>> }
> >>> clk_set_rate(mdp4_kms->lut_clk, max_clk);
> >>> @@ -560,7 +509,53 @@ static const struct dev_pm_ops mdp4_pm_ops = {
> >>> static int mdp4_probe(struct platform_device
Re: [PATCH v1 3/4] drm/msm/mdp4: move resource allocation to the _probe function
On 9/1/2022 11:06 PM, Dmitry Baryshkov wrote:
On 2 September 2022 03:24:17 GMT+03:00, Abhinav Kumar
wrote:
On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:
To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
probe callback. While we are at it, replace irq_of_parse_and_map() with
platform_get_irq().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 107 +++
1 file changed, 51 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 41dc60784847..6499713eccf6 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -139,8 +139,6 @@ static void mdp4_destroy(struct msm_kms *kms)
pm_runtime_disable(dev);
mdp_kms_destroy(_kms->base);
-
- kfree(mdp4_kms);
}
static const struct mdp_kms_funcs kms_funcs = {
@@ -383,57 +381,27 @@ static int mdp4_kms_init(struct drm_device *dev)
{
struct platform_device *pdev = to_platform_device(dev->dev);
struct msm_drm_private *priv = dev->dev_private;
- struct mdp4_kms *mdp4_kms;
+ struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(priv->kms));
struct msm_kms *kms = NULL;
struct iommu_domain *iommu;
struct msm_gem_address_space *aspace;
- int irq, ret;
+ int ret;
u32 major, minor;
unsigned long max_clk;
/* TODO: Chips that aren't apq8064 have a 200 Mhz max_clk */
max_clk = 27000;
-mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
- if (!mdp4_kms) {
- DRM_DEV_ERROR(dev->dev, "failed to allocate kms\n");
- return -ENOMEM;
- }
-
ret = mdp_kms_init(_kms->base, _funcs);
if (ret) {
DRM_DEV_ERROR(dev->dev, "failed to init kms\n");
goto fail;
}
-priv->kms = _kms->base.base;
kms = priv->kms;
mdp4_kms->dev = dev;
-mdp4_kms->mmio = msm_ioremap(pdev, NULL);
- if (IS_ERR(mdp4_kms->mmio)) {
- ret = PTR_ERR(mdp4_kms->mmio);
- goto fail;
- }
-
- irq = platform_get_irq(pdev, 0);
- if (irq < 0) {
- ret = irq;
- DRM_DEV_ERROR(dev->dev, "failed to get irq: %d\n", ret);
- goto fail;
- }
-
- kms->irq = irq;
-
- /* NOTE: driver for this regulator still missing upstream.. use
-* _get_exclusive() and ignore the error if it does not exist
-* (and hope that the bootloader left it on for us)
-*/
- mdp4_kms->vdd = devm_regulator_get_exclusive(>dev, "vdd");
- if (IS_ERR(mdp4_kms->vdd))
- mdp4_kms->vdd = NULL;
-
if (mdp4_kms->vdd) {
ret = regulator_enable(mdp4_kms->vdd);
if (ret) {
@@ -442,24 +410,6 @@ static int mdp4_kms_init(struct drm_device *dev)
}
}
-mdp4_kms->clk = devm_clk_get(>dev, "core_clk");
- if (IS_ERR(mdp4_kms->clk)) {
- DRM_DEV_ERROR(dev->dev, "failed to get core_clk\n");
- ret = PTR_ERR(mdp4_kms->clk);
- goto fail;
- }
-
- mdp4_kms->pclk = devm_clk_get(>dev, "iface_clk");
- if (IS_ERR(mdp4_kms->pclk))
- mdp4_kms->pclk = NULL;
-
- mdp4_kms->axi_clk = devm_clk_get(>dev, "bus_clk");
- if (IS_ERR(mdp4_kms->axi_clk)) {
- DRM_DEV_ERROR(dev->dev, "failed to get axi_clk\n");
- ret = PTR_ERR(mdp4_kms->axi_clk);
- goto fail;
- }
-
clk_set_rate(mdp4_kms->clk, max_clk);
read_mdp_hw_revision(mdp4_kms, , );
@@ -474,10 +424,9 @@ static int mdp4_kms_init(struct drm_device *dev)
mdp4_kms->rev = minor;
if (mdp4_kms->rev >= 2) {
- mdp4_kms->lut_clk = devm_clk_get(>dev, "lut_clk");
- if (IS_ERR(mdp4_kms->lut_clk)) {
+ if (!mdp4_kms->lut_clk) {
DRM_DEV_ERROR(dev->dev, "failed to get lut_clk\n");
- ret = PTR_ERR(mdp4_kms->lut_clk);
+ ret = -ENODEV;
goto fail;
}
clk_set_rate(mdp4_kms->lut_clk, max_clk);
@@ -560,7 +509,53 @@ static const struct dev_pm_ops mdp4_pm_ops = {
static int mdp4_probe(struct platform_device *pdev)
{
- return msm_drv_probe(>dev, mdp4_kms_init, NULL);
+ struct device *dev = >dev;
+ struct mdp4_kms *mdp4_kms;
+ int irq;
+
+ mdp4_kms = devm_kzalloc(dev, sizeof(*mdp4_kms), GFP_KERNEL);
+ if (!mdp4_kms)
+ return dev_err_probe(dev, -ENOMEM, "failed to allocate kms\n");
+
+ mdp4_kms->mmio = msm_ioremap(pdev, NULL);
+ if (IS_ERR(mdp4_kms->mmio))
+ return PTR_ERR(mdp4_kms->mmio);
+
+ irq = platform_get_irq(pdev, 0);
+
[PATCH v2 10/10] drm: rcar-du: Add rcar_du_lib_vsp_init()
RZ/G2L does not have plane registers as well as it uses different
CRTC. The below functions are SoC specific
* rcar_du_crtc_finish_page_flip()
* __rcar_du_plane_setup
* __rcar_du_plane_atomic_check
All other function can be handled in common code. This patch introduces
rcar_du_lib_vsp_init() to share common_init, vsp_formats and vsp_plane_funcs().
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 157 +---
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 166 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 10 ++
3 files changed, 178 insertions(+), 155 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index fabb616d8853..d798d97b0dd4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
@@ -85,34 +84,6 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, );
}
-static const u32 rcar_du_vsp_formats[] = {
- DRM_FORMAT_RGB332,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB1555,
- DRM_FORMAT_XRGB1555,
- DRM_FORMAT_RGB565,
- DRM_FORMAT_BGR888,
- DRM_FORMAT_RGB888,
- DRM_FORMAT_BGRA,
- DRM_FORMAT_BGRX,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_UYVY,
- DRM_FORMAT_YUYV,
- DRM_FORMAT_YVYU,
- DRM_FORMAT_NV12,
- DRM_FORMAT_NV21,
- DRM_FORMAT_NV16,
- DRM_FORMAT_NV61,
- DRM_FORMAT_YUV420,
- DRM_FORMAT_YVU420,
- DRM_FORMAT_YUV422,
- DRM_FORMAT_YVU422,
- DRM_FORMAT_YUV444,
- DRM_FORMAT_YVU444,
-};
-
static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
{
struct rcar_du_vsp_plane_state *state =
@@ -234,133 +205,9 @@ static const struct drm_plane_helper_funcs
rcar_du_vsp_plane_helper_funcs = {
.atomic_update = rcar_du_vsp_plane_atomic_update,
};
-static struct drm_plane_state *
-rcar_du_vsp_plane_atomic_duplicate_state(struct drm_plane *plane)
-{
- struct rcar_du_vsp_plane_state *copy;
-
- if (WARN_ON(!plane->state))
- return NULL;
-
- copy = kzalloc(sizeof(*copy), GFP_KERNEL);
- if (copy == NULL)
- return NULL;
-
- __drm_atomic_helper_plane_duplicate_state(plane, >state);
-
- return >state;
-}
-
-static void rcar_du_vsp_plane_atomic_destroy_state(struct drm_plane *plane,
- struct drm_plane_state
*state)
-{
- __drm_atomic_helper_plane_destroy_state(state);
- kfree(to_rcar_vsp_plane_state(state));
-}
-
-static void rcar_du_vsp_plane_reset(struct drm_plane *plane)
-{
- struct rcar_du_vsp_plane_state *state;
-
- if (plane->state) {
- rcar_du_vsp_plane_atomic_destroy_state(plane, plane->state);
- plane->state = NULL;
- }
-
- state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (state == NULL)
- return;
-
- __drm_atomic_helper_plane_reset(plane, >state);
-}
-
-static const struct drm_plane_funcs rcar_du_vsp_plane_funcs = {
- .update_plane = drm_atomic_helper_update_plane,
- .disable_plane = drm_atomic_helper_disable_plane,
- .reset = rcar_du_vsp_plane_reset,
- .destroy = drm_plane_cleanup,
- .atomic_duplicate_state = rcar_du_vsp_plane_atomic_duplicate_state,
- .atomic_destroy_state = rcar_du_vsp_plane_atomic_destroy_state,
-};
-
-static void rcar_du_vsp_cleanup(struct drm_device *dev, void *res)
-{
- struct rcar_du_vsp *vsp = res;
- unsigned int i;
-
- for (i = 0; i < vsp->num_planes; ++i) {
- struct rcar_du_vsp_plane *plane = >planes[i];
-
- drm_plane_cleanup(>plane);
- }
-
- kfree(vsp->planes);
-
- put_device(vsp->vsp);
-}
-
int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs)
{
- struct rcar_du_device *rcdu = vsp->dev;
- struct platform_device *pdev;
- unsigned int num_crtcs = hweight32(crtcs);
- unsigned int num_planes;
- unsigned int i;
- int ret;
-
- /* Find the VSP device and initialize it. */
- pdev = of_find_device_by_node(np);
- if (!pdev)
- return -ENXIO;
-
- vsp->vsp = >dev;
-
- ret = drmm_add_action_or_reset(>ddev, rcar_du_vsp_cleanup, vsp);
- if (ret < 0)
- return ret;
-
- ret = vsp1_du_init(vsp->vsp);
- if (ret < 0)
- return ret;
-
- num_planes = rcdu->info->num_rpf;
-
- vsp->planes = kcalloc(num_planes, sizeof(*vsp->planes), GFP_KERNEL);
- if (!vsp->planes)
- return -ENOMEM;
-
- for (i = 0; i < num_planes; ++i) {
-
[PATCH v2 09/10] drm: rcar-du: Move rcar_du_gem_prime_import_sg_table()
Move rcar_du_gem_prime_import_sg_table() to RCar DU KMS lib.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 47 ---
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 8
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 46 ++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 7
4 files changed, 53 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 4b5511a20313..ae969f640bb6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -11,8 +11,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
@@ -36,51 +34,6 @@
* Frame buffer
*/
-static const struct drm_gem_object_funcs rcar_du_gem_funcs = {
- .free = drm_gem_dma_object_free,
- .print_info = drm_gem_dma_object_print_info,
- .get_sg_table = drm_gem_dma_object_get_sg_table,
- .vmap = drm_gem_dma_object_vmap,
- .mmap = drm_gem_dma_object_mmap,
- .vm_ops = _gem_dma_vm_ops,
-};
-
-struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device
*dev,
- struct dma_buf_attachment *attach,
- struct sg_table *sgt)
-{
- struct rcar_du_device *rcdu = to_rcar_du_device(dev);
- struct drm_gem_dma_object *dma_obj;
- struct drm_gem_object *gem_obj;
- int ret;
-
- if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
- return drm_gem_dma_prime_import_sg_table(dev, attach, sgt);
-
- /* Create a DMA GEM buffer. */
- dma_obj = kzalloc(sizeof(*dma_obj), GFP_KERNEL);
- if (!dma_obj)
- return ERR_PTR(-ENOMEM);
-
- gem_obj = _obj->base;
- gem_obj->funcs = _du_gem_funcs;
-
- drm_gem_private_object_init(dev, gem_obj, attach->dmabuf->size);
- dma_obj->map_noncoherent = false;
-
- ret = drm_gem_create_mmap_offset(gem_obj);
- if (ret) {
- drm_gem_object_release(gem_obj);
- kfree(dma_obj);
- return ERR_PTR(ret);
- }
-
- dma_obj->dma_addr = 0;
- dma_obj->sgt = sgt;
-
- return gem_obj;
-}
-
static struct drm_framebuffer *
rcar_du_fb_create(struct drm_device *dev, struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
index 821eac74077f..b47a9e464ef4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
@@ -12,16 +12,8 @@
#include "rcar_du_kms_lib.h"
-struct dma_buf_attachment;
-struct drm_device;
-struct drm_gem_object;
struct rcar_du_device;
-struct sg_table;
int rcar_du_modeset_init(struct rcar_du_device *rcdu);
-struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device
*dev,
- struct dma_buf_attachment *attach,
- struct sg_table *sgt);
-
#endif /* __RCAR_DU_KMS_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
index 0a2b1c6c1ea6..6b912fed8a8b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
@@ -311,6 +312,51 @@ const struct rcar_du_format_info *rcar_du_format_info(u32
fourcc)
* Frame buffer
*/
+static const struct drm_gem_object_funcs rcar_du_gem_funcs = {
+ .free = drm_gem_dma_object_free,
+ .print_info = drm_gem_dma_object_print_info,
+ .get_sg_table = drm_gem_dma_object_get_sg_table,
+ .vmap = drm_gem_dma_object_vmap,
+ .mmap = drm_gem_dma_object_mmap,
+ .vm_ops = _gem_dma_vm_ops,
+};
+
+struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device
*dev,
+ struct dma_buf_attachment *attach,
+ struct sg_table *sgt)
+{
+ struct rcar_du_device *rcdu = to_rcar_du_device(dev);
+ struct drm_gem_dma_object *dma_obj;
+ struct drm_gem_object *gem_obj;
+ int ret;
+
+ if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
+ return drm_gem_dma_prime_import_sg_table(dev, attach, sgt);
+
+ /* Create a DMA GEM buffer. */
+ dma_obj = kzalloc(sizeof(*dma_obj), GFP_KERNEL);
+ if (!dma_obj)
+ return ERR_PTR(-ENOMEM);
+
+ gem_obj = _obj->base;
+ gem_obj->funcs = _du_gem_funcs;
+
+ drm_gem_private_object_init(dev, gem_obj, attach->dmabuf->size);
+ dma_obj->map_noncoherent = false;
+
+ ret = drm_gem_create_mmap_offset(gem_obj);
+ if (ret) {
+ drm_gem_object_release(gem_obj);
+ kfree(dma_obj);
+ return ERR_PTR(ret);
+ }
+
+
[PATCH v2 08/10] drm: rcar-du: Move rcar_du_dumb_create()
Move rcar_du_dumb_create() to RCar DU KMS lib.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 -
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 5
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 28 +++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 7 ++
4 files changed, 35 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 3141d447e979..4b5511a20313 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -81,27 +81,6 @@ struct drm_gem_object
*rcar_du_gem_prime_import_sg_table(struct drm_device *dev,
return gem_obj;
}
-int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
- struct drm_mode_create_dumb *args)
-{
- struct rcar_du_device *rcdu = to_rcar_du_device(dev);
- unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
- unsigned int align;
-
- /*
-* The R8A7779 DU requires a 16 pixels pitch alignment as documented,
-* but the R8A7790 DU seems to require a 128 bytes pitch alignment.
-*/
- if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
- align = 128;
- else
- align = 16 * args->bpp / 8;
-
- args->pitch = roundup(min_pitch, align);
-
- return drm_gem_dma_dumb_create_internal(file, dev, args);
-}
-
static struct drm_framebuffer *
rcar_du_fb_create(struct drm_device *dev, struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
index 2d4b8e608989..821eac74077f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
@@ -13,18 +13,13 @@
#include "rcar_du_kms_lib.h"
struct dma_buf_attachment;
-struct drm_file;
struct drm_device;
struct drm_gem_object;
-struct drm_mode_create_dumb;
struct rcar_du_device;
struct sg_table;
int rcar_du_modeset_init(struct rcar_du_device *rcdu);
-int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
- struct drm_mode_create_dumb *args);
-
struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device
*dev,
struct dma_buf_attachment *attach,
struct sg_table *sgt);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
index 97c526dae521..0a2b1c6c1ea6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
@@ -7,10 +7,13 @@
* Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
*/
+#include
#include
+#include
#include
+#include "rcar_du_drv.h"
#include "rcar_du_kms.h"
#include "rcar_du_regs.h"
@@ -303,3 +306,28 @@ const struct rcar_du_format_info *rcar_du_format_info(u32
fourcc)
return NULL;
}
+
+/*
-
+ * Frame buffer
+ */
+
+int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+ struct rcar_du_device *rcdu = to_rcar_du_device(dev);
+ unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+ unsigned int align;
+
+ /*
+* The R8A7779 DU requires a 16 pixels pitch alignment as documented,
+* but the R8A7790 DU seems to require a 128 bytes pitch alignment.
+*/
+ if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
+ align = 128;
+ else
+ align = 16 * args->bpp / 8;
+
+ args->pitch = roundup(min_pitch, align);
+
+ return drm_gem_dma_dumb_create_internal(file, dev, args);
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
index 674a38d24917..33f96e96f6a2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
@@ -12,6 +12,10 @@
#include
+struct drm_device;
+struct drm_file;
+struct drm_mode_create_dumb;
+
struct rcar_du_format_info {
u32 fourcc;
u32 v4l2;
@@ -24,4 +28,7 @@ struct rcar_du_format_info {
const struct rcar_du_format_info *rcar_du_format_info(u32 fourcc);
+int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
+ struct drm_mode_create_dumb *args);
+
#endif /* __RCAR_DU_KMS_LIB_H__ */
--
2.25.1
[PATCH v2 07/10] drm: rcar-du: Move vsp rcar_du_vsp_{map,unmap}_fb()
Move vsp rcar_du_vsp_{map,unmap}_fb() to RCar DU VSP lib.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 78 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 18 -
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 84 +++
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 19 +
4 files changed, 103 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 870b72eda4da..fabb616d8853 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -11,11 +11,8 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include
#include
@@ -171,68 +168,6 @@ static void rcar_du_vsp_plane_setup(struct
rcar_du_vsp_plane *plane)
plane->index, );
}
-int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
- struct sg_table sg_tables[3])
-{
- struct rcar_du_device *rcdu = vsp->dev;
- unsigned int i, j;
- int ret;
-
- for (i = 0; i < fb->format->num_planes; ++i) {
- struct drm_gem_dma_object *gem = drm_fb_dma_get_gem_obj(fb, i);
- struct sg_table *sgt = _tables[i];
-
- if (gem->sgt) {
- struct scatterlist *src;
- struct scatterlist *dst;
-
- /*
-* If the GEM buffer has a scatter gather table, it has
-* been imported from a dma-buf and has no physical
-* address as it might not be physically contiguous.
-* Copy the original scatter gather table to map it to
-* the VSP.
-*/
- ret = sg_alloc_table(sgt, gem->sgt->orig_nents,
-GFP_KERNEL);
- if (ret)
- goto fail;
-
- src = gem->sgt->sgl;
- dst = sgt->sgl;
- for (j = 0; j < gem->sgt->orig_nents; ++j) {
- sg_set_page(dst, sg_page(src), src->length,
- src->offset);
- src = sg_next(src);
- dst = sg_next(dst);
- }
- } else {
- ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr,
- gem->dma_addr, gem->base.size);
- if (ret)
- goto fail;
- }
-
- ret = vsp1_du_map_sg(vsp->vsp, sgt);
- if (ret) {
- sg_free_table(sgt);
- goto fail;
- }
- }
-
- return 0;
-
-fail:
- while (i--) {
- struct sg_table *sgt = _tables[i];
-
- vsp1_du_unmap_sg(vsp->vsp, sgt);
- sg_free_table(sgt);
- }
-
- return ret;
-}
-
static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *state)
{
@@ -254,19 +189,6 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane
*plane,
return drm_gem_plane_helper_prepare_fb(plane, state);
}
-void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
- struct sg_table sg_tables[3])
-{
- unsigned int i;
-
- for (i = 0; i < fb->format->num_planes; ++i) {
- struct sg_table *sgt = _tables[i];
-
- vsp1_du_unmap_sg(vsp->vsp, sgt);
- sg_free_table(sgt);
- }
-}
-
static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
struct drm_plane_state *state)
{
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index b610e6b40304..4022ed014353 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -14,10 +14,7 @@
#include "rcar_du_vsp_lib.h"
-struct drm_framebuffer;
struct rcar_du_format_info;
-struct rcar_du_vsp;
-struct sg_table;
struct rcar_du_vsp_plane {
struct drm_plane plane;
@@ -61,10 +58,6 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs);
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
-int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
- struct sg_table sg_tables[3]);
-void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
- struct sg_table sg_tables[3]);
#else
static inline int rcar_du_vsp_init(struct
[PATCH v2 06/10] drm: rcar-du: Move rcar_du_vsp_atomic_flush()
Move rcar_du_vsp_atomic_flush() to RCar DU vsp lib.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 13 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 14 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 2 ++
4 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 685e3e8f6ddb..870b72eda4da 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -88,19 +88,6 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, );
}
-void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
-{
- struct vsp1_du_atomic_pipe_config cfg = { { 0, } };
- struct rcar_du_crtc_state *state;
-
- state = to_rcar_crtc_state(crtc->crtc.state);
- cfg.crc = state->crc;
-
- rcar_du_writeback_setup(crtc, );
-
- vsp1_du_atomic_flush(crtc->vsp->vsp, crtc->vsp_pipe, );
-}
-
static const u32 rcar_du_vsp_formats[] = {
DRM_FORMAT_RGB332,
DRM_FORMAT_ARGB,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 83a2f3e85860..b610e6b40304 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -61,7 +61,6 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs);
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
-void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
struct sg_table sg_tables[3]);
void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
@@ -74,7 +73,6 @@ static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp,
return -ENXIO;
}
static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
-static inline void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc) { };
static inline int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp,
struct drm_framebuffer *fb,
struct sg_table sg_tables[3])
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
index f6c0cae7c4af..89169dc7594a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
@@ -10,6 +10,7 @@
#include
#include "rcar_du_drv.h"
+#include "rcar_du_writeback.h"
void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
{
@@ -20,3 +21,16 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
{
vsp1_du_atomic_begin(crtc->vsp->vsp, crtc->vsp_pipe);
}
+
+void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
+{
+ struct vsp1_du_atomic_pipe_config cfg = { { 0, } };
+ struct rcar_du_crtc_state *state;
+
+ state = to_rcar_crtc_state(crtc->crtc.state);
+ cfg.crc = state->crc;
+
+ rcar_du_writeback_setup(crtc, );
+
+ vsp1_du_atomic_flush(crtc->vsp->vsp, crtc->vsp_pipe, );
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
index 8c22042d4a80..e8f16236be0a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
@@ -13,9 +13,11 @@
#ifdef CONFIG_DRM_RCAR_VSP
void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
+void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
#else
static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
+static inline void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc) { };
#endif
#endif /* __RCAR_DU_VSP_LIB_H__ */
--
2.25.1
[PATCH v2 05/10] drm: rcar-du: Move rcar_du_vsp_atomic_begin()
Move rcar_du_vsp_atomic_begin() to RCar DU VSP lib.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 5 +
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 2 ++
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index bed3f2a3c4a5..685e3e8f6ddb 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -88,11 +88,6 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, );
}
-void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
-{
- vsp1_du_atomic_begin(crtc->vsp->vsp, crtc->vsp_pipe);
-}
-
void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
{
struct vsp1_du_atomic_pipe_config cfg = { { 0, } };
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 8fbfa86c93e0..83a2f3e85860 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -61,7 +61,6 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs);
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
-void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
struct sg_table sg_tables[3]);
@@ -75,7 +74,6 @@ static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp,
return -ENXIO;
}
static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
-static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc) { };
static inline int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp,
struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
index e22d4e535268..f6c0cae7c4af 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
@@ -15,3 +15,8 @@ void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
{
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, NULL);
}
+
+void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
+{
+ vsp1_du_atomic_begin(crtc->vsp->vsp, crtc->vsp_pipe);
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
index d91c043bbced..8c22042d4a80 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
@@ -12,8 +12,10 @@
#ifdef CONFIG_DRM_RCAR_VSP
void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
+void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
#else
static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
+static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
#endif
#endif /* __RCAR_DU_VSP_LIB_H__ */
--
2.25.1
[PATCH v2 04/10] drm: rcar-du: Add vsp lib support
Add RCar DU vsp lib support by moving rcar_du_vsp_disable()
to the lib file so that same function can be used by both
RCar and RZ/G2L DU VSP drivers.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/Kconfig | 5 +
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 4 ++--
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 17 +
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 19 +++
6 files changed, 44 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 369af45b5ff9..64d47d9f9131 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -76,3 +76,8 @@ config DRM_RCAR_LIB
bool
default y
depends on DRM_RCAR_DU
+
+config DRM_RCAR_VSP_LIB
+ bool
+ default y
+ depends on DRM_RCAR_VSP
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 3ce410300334..8fc924cf37a7 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -10,6 +10,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LIB) += rcar_du_encoder_lib.o \
rcar_du_kms_lib.o
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
+rcar-du-drm-$(CONFIG_DRM_RCAR_VSP_LIB) += rcar_du_vsp_lib.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index e465aef41585..bed3f2a3c4a5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -88,11 +88,6 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, );
}
-void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
-{
- vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, NULL);
-}
-
void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
{
vsp1_du_atomic_begin(crtc->vsp->vsp, crtc->vsp_pipe);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 67630f0b6599..8fbfa86c93e0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -12,6 +12,8 @@
#include
+#include "rcar_du_vsp_lib.h"
+
struct drm_framebuffer;
struct rcar_du_format_info;
struct rcar_du_vsp;
@@ -59,7 +61,6 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs);
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
-void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
@@ -74,7 +75,6 @@ static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp,
return -ENXIO;
}
static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
-static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc) { };
static inline int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
new file mode 100644
index ..e22d4e535268
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * R-Car Display Unit VSP-Based Compositor Lib
+ *
+ * Copyright (C) 2015-2022 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ */
+
+#include
+
+#include "rcar_du_drv.h"
+
+void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
+{
+ vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, NULL);
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
new file mode 100644
index ..d91c043bbced
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * R-Car Display Unit VSP-Based Compositor Lib
+ *
+ * Copyright (C) 2015-2022 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ */
+
+#ifndef __RCAR_DU_VSP_LIB_H__
+#define __RCAR_DU_VSP_LIB_H__
+
+#ifdef CONFIG_DRM_RCAR_VSP
+void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
+#else
+static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
+#endif
+
+#endif /* __RCAR_DU_VSP_LIB_H__ */
[PATCH v2 03/10] drm: rcar-du: Add kms lib support
Add RCar DU kms lib support by moving rcar_du_format_infos table and
rcar_du_format_infos() to the lib file to share the common code between
RCar and RZ/G2L DU KMS drivers.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/Makefile | 3 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 290
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 16 +-
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 305 ++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 27 ++
5 files changed, 336 insertions(+), 305 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 479c8eebba5a..3ce410300334 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -6,7 +6,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_kms.o \
rcar_du_plane.o \
-rcar-du-drm-$(CONFIG_DRM_RCAR_LIB) += rcar_du_encoder_lib.o
+rcar-du-drm-$(CONFIG_DRM_RCAR_LIB) += rcar_du_encoder_lib.o \
+ rcar_du_kms_lib.o
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 8c2719efda2a..3141d447e979 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -32,296 +32,6 @@
#include "rcar_du_vsp.h"
#include "rcar_du_writeback.h"
-/*
-
- * Format helpers
- */
-
-static const struct rcar_du_format_info rcar_du_format_infos[] = {
- {
- .fourcc = DRM_FORMAT_RGB565,
- .v4l2 = V4L2_PIX_FMT_RGB565,
- .bpp = 16,
- .planes = 1,
- .hsub = 1,
- .pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_ARGB1555,
- .v4l2 = V4L2_PIX_FMT_ARGB555,
- .bpp = 16,
- .planes = 1,
- .hsub = 1,
- .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_XRGB1555,
- .v4l2 = V4L2_PIX_FMT_XRGB555,
- .bpp = 16,
- .planes = 1,
- .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_XRGB,
- .v4l2 = V4L2_PIX_FMT_XBGR32,
- .bpp = 32,
- .planes = 1,
- .hsub = 1,
- .pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
- .edf = PnDDCR4_EDF_RGB888,
- }, {
- .fourcc = DRM_FORMAT_ARGB,
- .v4l2 = V4L2_PIX_FMT_ABGR32,
- .bpp = 32,
- .planes = 1,
- .hsub = 1,
- .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_16BPP,
- .edf = PnDDCR4_EDF_ARGB,
- }, {
- .fourcc = DRM_FORMAT_UYVY,
- .v4l2 = V4L2_PIX_FMT_UYVY,
- .bpp = 16,
- .planes = 1,
- .hsub = 2,
- .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_YUYV,
- .v4l2 = V4L2_PIX_FMT_YUYV,
- .bpp = 16,
- .planes = 1,
- .hsub = 2,
- .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_NV12,
- .v4l2 = V4L2_PIX_FMT_NV12M,
- .bpp = 12,
- .planes = 2,
- .hsub = 2,
- .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_NV21,
- .v4l2 = V4L2_PIX_FMT_NV21M,
- .bpp = 12,
- .planes = 2,
- .hsub = 2,
- .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_NV16,
- .v4l2 = V4L2_PIX_FMT_NV16M,
- .bpp = 16,
- .planes = 2,
- .hsub = 2,
- .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
- .edf = PnDDCR4_EDF_NONE,
- },
- /*
-* The following formats are not supported on Gen2 and thus have no
-* associated .pnmr or .edf settings.
-*/
- {
- .fourcc = DRM_FORMAT_RGB332,
- .v4l2 = V4L2_PIX_FMT_RGB332,
- .bpp = 8,
- .planes = 1,
- .hsub = 1,
- }, {
-
[PATCH v2 02/10] drm: rcar-du: Add encoder lib support
Add RCar DU encoder lib support by moving rcar_du_encoder_count_ports()
and rcar_du_encoder_funcs to the lib file and added
rcar_du_encoder_funcs() to share the common code between RCar and
RZ/G2L DU encoder drivers.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
* Fixed the warning reported by bot.
---
drivers/gpu/drm/rcar-du/Kconfig | 5 +
drivers/gpu/drm/rcar-du/Makefile | 2 +
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 117 +--
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 14 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.c | 138 ++
drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.h | 30
6 files changed, 180 insertions(+), 126 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 58ffb8c2443b..369af45b5ff9 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -71,3 +71,8 @@ config DRM_RCAR_WRITEBACK
bool
default y if ARM64
depends on DRM_RCAR_DU
+
+config DRM_RCAR_LIB
+ bool
+ default y
+ depends on DRM_RCAR_DU
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index b8f2c82651d9..479c8eebba5a 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -6,6 +6,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_kms.o \
rcar_du_plane.o \
+rcar-du-drm-$(CONFIG_DRM_RCAR_LIB) += rcar_du_encoder_lib.o
+
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index b1787be31e92..444cc956f692 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -2,7 +2,7 @@
/*
* R-Car Display Unit Encoder
*
- * Copyright (C) 2013-2014 Renesas Electronics Corporation
+ * Copyright (C) 2013-2022 Renesas Electronics Corporation
*
* Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
*/
@@ -10,128 +10,17 @@
#include
#include
-#include
-#include
-#include
-
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
-#include "rcar_lvds.h"
/*
-
* Encoder
*/
-static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
-{
- struct device_node *ports;
- struct device_node *port;
- unsigned int num_ports = 0;
-
- ports = of_get_child_by_name(node, "ports");
- if (!ports)
- ports = of_node_get(node);
-
- for_each_child_of_node(ports, port) {
- if (of_node_name_eq(port, "port"))
- num_ports++;
- }
-
- of_node_put(ports);
-
- return num_ports;
-}
-
-static const struct drm_encoder_funcs rcar_du_encoder_funcs = {
-};
-
int rcar_du_encoder_init(struct rcar_du_device *rcdu,
enum rcar_du_output output,
struct device_node *enc_node)
{
- struct rcar_du_encoder *renc;
- struct drm_connector *connector;
- struct drm_bridge *bridge;
- int ret;
-
- /*
-* Locate the DRM bridge from the DT node. For the DPAD outputs, if the
-* DT node has a single port, assume that it describes a panel and
-* create a panel bridge.
-*/
- if ((output == RCAR_DU_OUTPUT_DPAD0 ||
-output == RCAR_DU_OUTPUT_DPAD1) &&
- rcar_du_encoder_count_ports(enc_node) == 1) {
- struct drm_panel *panel = of_drm_find_panel(enc_node);
-
- if (IS_ERR(panel))
- return PTR_ERR(panel);
-
- bridge = devm_drm_panel_bridge_add_typed(rcdu->dev, panel,
-
DRM_MODE_CONNECTOR_DPI);
- if (IS_ERR(bridge))
- return PTR_ERR(bridge);
- } else {
- bridge = of_drm_find_bridge(enc_node);
- if (!bridge)
- return -EPROBE_DEFER;
-
- if (output == RCAR_DU_OUTPUT_LVDS0 ||
- output == RCAR_DU_OUTPUT_LVDS1)
- rcdu->lvds[output - RCAR_DU_OUTPUT_LVDS0] = bridge;
-
- if (output == RCAR_DU_OUTPUT_DSI0 ||
- output == RCAR_DU_OUTPUT_DSI1)
- rcdu->dsi[output - RCAR_DU_OUTPUT_DSI0] = bridge;
- }
-
- /*
-* Create and initialize the encoder. On Gen3, skip the LVDS1 output if
-* the LVDS1 encoder is used as a companion for LVDS0 in dual-link
-* mode, or any LVDS output if it isn't connected. The latter may happen
-* on D3 or E3 as the LVDS encoders
[PATCH v2 01/10] drm: rcar-du: Add RZ/G2L reset and clocks to struct rcar_du_crtc
Add RZ/G2L reset and clocks to struct rcar_du_crtc, so that
we can share and optimize the common code between RCar and
RZ/G2L driver using RCar DU library.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index d0f38a8b3561..d2164ee6e599 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -43,6 +43,8 @@ struct rcar_du_vsp;
* @vsp: VSP feeding video to this CRTC
* @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
* @writeback: the writeback connector
+ * @rzg2l_clocks: the bus, main and video clock
+ * @rstc: reset controller
*/
struct rcar_du_crtc {
struct drm_crtc crtc;
@@ -73,6 +75,14 @@ struct rcar_du_crtc {
unsigned int sources_count;
struct drm_writeback_connector writeback;
+
+ /* RZ/G2L specific */
+ struct reset_control *rstc;
+ struct {
+ struct clk *aclk;
+ struct clk *pclk;
+ struct clk *dclk;
+ } rzg2l_clocks;
};
#define to_rcar_crtc(c)container_of(c, struct rcar_du_crtc,
crtc)
--
2.25.1
[PATCH v2 00/10] Add RCar DU lib support
Both RZ/G2L and RCar display system uses similar hardware pipeline for
display ie, it uses FCPV, VSPD and DU. Both FCPV and VSPD are almost
similar, but DU there are some differences like it does not have
plane/group registers.
Since the pipeline and software architecture are similar, we can reuse the
DU code for RCar to RZ/G2L as well.
This patch series adds RCar DU lib support(Encoder, vsp and KMS) by moving
common codes with some trivial changes to the lib.
The subsequent patch series will add support for RZ/G2L DU.
Note:
* This patch series is based on drm-misc-next and du-next
* The KConfig and Make file depend upon [1]
[1]
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220829091901.641784-3-biju.das...@bp.renesas.com/
v1->v2:
* Rebased on drm-misc-next and DU-next.
* Fixed the warning reported by bot for patch#2.
Biju Das (10):
drm: rcar-du: Add RZ/G2L reset and clocks to struct rcar_du_crtc
drm: rcar-du: Add encoder lib support
drm: rcar-du: Add kms lib support
drm: rcar-du: Add vsp lib support
drm: rcar-du: Move rcar_du_vsp_atomic_begin()
drm: rcar-du: Move rcar_du_vsp_atomic_flush()
drm: rcar-du: Move vsp rcar_du_vsp_{map,unmap}_fb()
drm: rcar-du: Move rcar_du_dumb_create()
drm: rcar-du: Move rcar_du_gem_prime_import_sg_table()
drm: rcar-du: Add rcar_du_lib_vsp_init()
drivers/gpu/drm/rcar-du/Kconfig | 10 +
drivers/gpu/drm/rcar-du/Makefile | 4 +
drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 10 +
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 117 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 14 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.c | 138 +++
drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.h | 30 ++
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 358 -
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 29 +-
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 379 ++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 41 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 258 +---
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 26 +-
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 286 +
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 52 +++
15 files changed, 961 insertions(+), 791 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.h
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
--
2.25.1
Re: [PATCH v4 01/11] drm/i915: Move display and media IP version to runtime info
Hi Radhakrishna,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20220901]
[cannot apply to drm-intel/for-linux-next drm/drm-next drm-misc/drm-misc-next
linus/master v6.0-rc3]
[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/Radhakrishna-Sripada/Initial-Meteorlake-Support/20220902-140730
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-allyesconfig
(https://download.01.org/0day-ci/archive/20220903/202209030003.ylxzpg2i-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-5) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/159b13997e25c824f0404a44fd47e559eb56b97d
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Radhakrishna-Sripada/Initial-Meteorlake-Support/20220902-140730
git checkout 159b13997e25c824f0404a44fd47e559eb56b97d
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/i915/i915_gem.c:1267:
drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function
'mock_gem_device':
>> drivers/gpu/drm/i915/selftests/mock_gem_device.c:175:37: error: 'struct
>> ' has no member named 'ver'
175 | RUNTIME_INFO(i915)->graphics.ver = -1;
| ^
vim +175 drivers/gpu/drm/i915/selftests/mock_gem_device.c
bec68cc9ea42d8 Tvrtko Ursulin 2022-03-19 119
66d9cb5d805af7 Chris Wilson 2017-02-13 120 struct drm_i915_private
*mock_gem_device(void)
66d9cb5d805af7 Chris Wilson 2017-02-13 121 {
01b9d4e21148c8 Joerg Roedel 2020-06-25 122 #if
IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
9f9f4101fc98db Chris Wilson 2020-09-16 123 static struct dev_iommu
fake_iommu = { .priv = (void *)-1 };
01b9d4e21148c8 Joerg Roedel 2020-06-25 124 #endif
9f9f4101fc98db Chris Wilson 2020-09-16 125 struct drm_i915_private
*i915;
9f9f4101fc98db Chris Wilson 2020-09-16 126 struct pci_dev *pdev;
d148738923fdb5 Thomas Hellström 2021-06-02 127 int ret;
66d9cb5d805af7 Chris Wilson 2017-02-13 128
7fb81e9d80738e Daniel Vetter 2020-03-23 129 pdev =
kzalloc(sizeof(*pdev), GFP_KERNEL);
66d9cb5d805af7 Chris Wilson 2017-02-13 130 if (!pdev)
7fb81e9d80738e Daniel Vetter 2020-03-23 131 return NULL;
66d9cb5d805af7 Chris Wilson 2017-02-13 132
device_initialize(>dev);
29f31623d7a830 Chris Wilson 2017-05-18 133 pdev->class =
PCI_BASE_CLASS_DISPLAY << 16;
66d9cb5d805af7 Chris Wilson 2017-02-13 134 pdev->dev.release =
release_dev;
66d9cb5d805af7 Chris Wilson 2017-02-13 135
dev_set_name(>dev, "mock");
d58f0083d39a17 Chris Wilson 2019-01-07 136
dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(64));
66d9cb5d805af7 Chris Wilson 2017-02-13 137
764d2997ec0edb Arnd Bergmann 2017-10-05 138 #if
IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
9f9f4101fc98db Chris Wilson 2020-09-16 139 /* HACK to disable
iommu for the fake device; force identity mapping */
9f9f4101fc98db Chris Wilson 2020-09-16 140 pdev->dev.iommu =
_iommu;
f46f156ea7704a Chris Wilson 2017-09-18 141 #endif
cd01269d11a352 Daniel Vetter 2020-09-19 142 if
(!devres_open_group(>dev, NULL, GFP_KERNEL)) {
cd01269d11a352 Daniel Vetter 2020-09-19 143
put_device(>dev);
cd01269d11a352 Daniel Vetter 2020-09-19 144 return NULL;
cd01269d11a352 Daniel Vetter 2020-09-19 145 }
cd01269d11a352 Daniel Vetter 2020-09-19 146
cd01269d11a352 Daniel Vetter 2020-09-19 147 i915 =
devm_drm_dev_alloc(>dev, _driver,
cd01269d11a352 Daniel Vetter 2020-09-19 148
struct drm_i915_private, drm);
cd01269d11a352 Daniel Vetter 2020-09-19 149 if (IS_ERR(i915)) {
cd01269d11a352 Daniel Vetter 2020-09-19 150 pr_err("Failed
to allocate mock GEM device: err=%ld\n", PTR_ERR(i915));
cd01269d11a352 Daniel Vetter 2020-09-19 151
devres_release_group(>dev, NULL);
cd01269d11a352 Daniel Vetter 2020-09-19 152
put_device(>dev);
cd01269d11a352 Daniel Vetter 2020-09-19
RE: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
>-Original Message- >From: Dmitry Osipenko >Sent: Friday, September 2, 2022 6:39 AM >To: Ruhl, Michael J ; Dmitry Osipenko >; Jani Nikula ; >Joonas Lahtinen ; Vivi, Rodrigo >; Tvrtko Ursulin ; >Thomas Hellström ; Christian König >; Chris Wilson >Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; linux- >me...@vger.kernel.org; linaro-mm-...@lists.linaro.org; amd- >g...@lists.freedesktop.org; intel-...@lists.freedesktop.org; >ker...@collabora.com; virtualizat...@lists.linux-foundation.org; linux- >r...@vger.kernel.org; linux-arm-...@vger.kernel.org; David Airlie >; Gerd Hoffmann ; Gurchetan Singh >; Chia-I Wu ; Daniel >Vetter ; Daniel Almeida ; >Gert Wollny ; Gustavo Padovan >; Daniel Stone ; >Tomeu Vizoso ; Maarten Lankhorst >; Maxime Ripard >; Thomas Zimmermann ; >Rob Clark ; Sumit Semwal >; Pan, Xinhui ; Thierry >Reding ; Tomasz Figa ; >Marek Szyprowski ; Mauro Carvalho Chehab >; Alex Deucher ; >Qiang Yu ; Srinivas Kandagatla >; Amol Maheshwari >; Jason Gunthorpe ; Leon >Romanovsky ; Gross, Jurgen ; Stefano >Stabellini ; Oleksandr Tyshchenko >; Tomi Valkeinen ; >Russell King ; Lucas Stach ; >Christian Gmeiner >Subject: Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking >specification > >02.09.2022 13:31, Dmitry Osipenko пишет: >> 01.09.2022 17:02, Ruhl, Michael J пишет: >> ... --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915, continue; } + /* + * dma_buf_unmap_attachment() requires reservation to be + * locked. The imported GEM shouldn't share reservation lock, + * so it's safe to take the lock. + */ + if (obj->base.import_attach) + i915_gem_object_lock(obj, NULL); >>> >>> There is a lot of stuff going here. Taking the lock may be premature... >>> __i915_gem_object_pages_fini(obj); >>> >>> The i915_gem_dmabuf.c:i915_gem_object_put_pages_dmabuf is where >>> unmap_attachment is actually called, would it make more sense to make >>> do the locking there? >> >> The __i915_gem_object_put_pages() is invoked with a held reservation >> lock, while freeing object is a special time when we know that GEM is >> unused. >> >> The __i915_gem_free_objects() was taking the lock two weeks ago until >> the change made Chris Wilson [1] reached linux-next. >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux- >next.git/commit/?id=2826d447fbd60e6a05e53d5f918bceb8c04e315c >> >> I don't think we can take the lock within >> i915_gem_object_put_pages_dmabuf(), it may/should deadlock other code >paths. > >On the other hand, we can check whether the GEM's refcount number is >zero in i915_gem_object_put_pages_dmabuf() and then take the lock if >it's zero. > >Also, seems it should be possible just to bail out from >i915_gem_object_put_pages_dmabuf() if refcount=0. The further >drm_prime_gem_destroy() will take care of unmapping. Perhaps this could >be the best option, I'll give it a test. i915_gem_object_put_pages() is uses the SG, and the usage for drm_prim_gem_destroy() from __i915_gem_free_objects() doesn't use the SG because it has been "freed" already, I am not sure if that would work... Hmm.. with that in mind, maybe moving the base.import_attach check to __i915_gem_object_put_pages with your attach check? atomic_set(>mm.pages_pin_count, 0); if (obj->base.import) i915_gem_object_lock(obj, NULL); __i915_gem_object_put_pages(obj); if (obj->base.import) i915_gem_object_unlock(obj, NULL); GEM_BUG_ON(i915_gem_object_has_pages(obj)); Pretty much one step up from the dmabuf interface, but we are guaranteed to not have any pinned pages? The other caller of __i915_gem_object_pages_fini is the i915_ttm move_notify which should not conflict (export side, not import side). Since it appears that not locking during the clean up is desirable, trying to make sure take the lock is taken at the last moment might be the right path? M
Re: [PATCH V2 0/2] chrontel-ch7033: Add byteswap order option
On Fri, 2 Sept 2022 at 17:39, Chris Morgan wrote: > > From: Chris Morgan > > This series adds the ability to set the byteswap order in the chrontel > ch7033 driver via an optional devicetree node. This is necessary > because the HDMI DIP of the NTC CHIP requires a byteswap order that > differs from the default value of the driver. > > Changes from V1: > > - Updated devicetree documentation to be easier to understand. > > Signed-off-by: Chris Morgan > > Chris Morgan (2): > dt-bindings: Add byteswap order to chrontel ch7033 > drm/bridge: chrontel-ch7033: Add byteswap order setting > > .../bindings/display/bridge/chrontel,ch7033.yaml | 13 + > drivers/gpu/drm/bridge/chrontel-ch7033.c | 15 +-- > 2 files changed, 26 insertions(+), 2 deletions(-) > > -- > 2.25.1 > Applied to drm-misc-next.
[PATCH V2 2/2] drm/bridge: chrontel-ch7033: Add byteswap order setting
From: Chris Morgan
Add the option to set the byteswap order in the devicetree. For the
official HDMI DIP for the NTC CHIP the byteswap order needs to be
RGB, however the driver sets it as BGR. With this patch the driver
will remain at BGR unless manually specified via devicetree.
Signed-off-by: Chris Morgan
Reviewed-by: Robert Foss
---
drivers/gpu/drm/bridge/chrontel-ch7033.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c
b/drivers/gpu/drm/bridge/chrontel-ch7033.c
index ba060277c3fd..c5719908ce2d 100644
--- a/drivers/gpu/drm/bridge/chrontel-ch7033.c
+++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
@@ -68,6 +68,7 @@ enum {
BYTE_SWAP_GBR = 3,
BYTE_SWAP_BRG = 4,
BYTE_SWAP_BGR = 5,
+ BYTE_SWAP_MAX = 6,
};
/* Page 0, Register 0x19 */
@@ -355,6 +356,8 @@ static void ch7033_bridge_mode_set(struct drm_bridge
*bridge,
int hsynclen = mode->hsync_end - mode->hsync_start;
int vbporch = mode->vsync_start - mode->vdisplay;
int vsynclen = mode->vsync_end - mode->vsync_start;
+ u8 byte_swap;
+ int ret;
/*
* Page 4
@@ -398,8 +401,16 @@ static void ch7033_bridge_mode_set(struct drm_bridge
*bridge,
regmap_write(priv->regmap, 0x15, vbporch);
regmap_write(priv->regmap, 0x16, vsynclen);
- /* Input color swap. */
- regmap_update_bits(priv->regmap, 0x18, SWAP, BYTE_SWAP_BGR);
+ /* Input color swap. Byte order is optional and will default to
+* BYTE_SWAP_BGR to preserve backwards compatibility with existing
+* driver.
+*/
+ ret = of_property_read_u8(priv->bridge.of_node, "chrontel,byteswap",
+ _swap);
+ if (!ret && byte_swap < BYTE_SWAP_MAX)
+ regmap_update_bits(priv->regmap, 0x18, SWAP, byte_swap);
+ else
+ regmap_update_bits(priv->regmap, 0x18, SWAP, BYTE_SWAP_BGR);
/* Input clock and sync polarity. */
regmap_update_bits(priv->regmap, 0x19, 0x1, mode->clock >> 16);
--
2.25.1
[PATCH V2 1/2] dt-bindings: Add byteswap order to chrontel ch7033
From: Chris Morgan Update dt-binding documentation to add support for setting byteswap of chrontel ch7033. New property name of chrontel,byteswap added to set the byteswap order. This property is optional. Signed-off-by: Chris Morgan Reviewed-by: Robert Foss --- .../bindings/display/bridge/chrontel,ch7033.yaml| 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml index bb6289c7d375..984b90893583 100644 --- a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml +++ b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml @@ -14,6 +14,19 @@ properties: compatible: const: chrontel,ch7033 + chrontel,byteswap: +$ref: /schemas/types.yaml#/definitions/uint8 +enum: + - 0 # BYTE_SWAP_RGB + - 1 # BYTE_SWAP_RBG + - 2 # BYTE_SWAP_GRB + - 3 # BYTE_SWAP_GBR + - 4 # BYTE_SWAP_BRG + - 5 # BYTE_SWAP_BGR +description: | + Set the byteswap value of the bridge. This is optional and if not + set value of BYTE_SWAP_BGR is used. + reg: maxItems: 1 description: I2C address of the device -- 2.25.1
[PATCH V2 0/2] chrontel-ch7033: Add byteswap order option
From: Chris Morgan This series adds the ability to set the byteswap order in the chrontel ch7033 driver via an optional devicetree node. This is necessary because the HDMI DIP of the NTC CHIP requires a byteswap order that differs from the default value of the driver. Changes from V1: - Updated devicetree documentation to be easier to understand. Signed-off-by: Chris Morgan Chris Morgan (2): dt-bindings: Add byteswap order to chrontel ch7033 drm/bridge: chrontel-ch7033: Add byteswap order setting .../bindings/display/bridge/chrontel,ch7033.yaml | 13 + drivers/gpu/drm/bridge/chrontel-ch7033.c | 15 +-- 2 files changed, 26 insertions(+), 2 deletions(-) -- 2.25.1
Re: [PATCH v2 2/2] drm/plane_helper: Split into parameterized test cases
On 9/2/22 11:53, Michał Winiarski wrote:
> On Thu, Sep 01, 2022 at 09:20:55AM -0300, Maíra Canal wrote:
>> Hi Michał
>>
>> On 8/31/22 17:45, Michał Winiarski wrote:
>>> The test was constructed as a single function (test case) which checks
>>> multiple conditions, calling the function that is tested multiple times
>>> with different arguments.
>>> This usually means that it can be easily converted into multiple test
>>> cases.
>>> Split igt_check_plane_state into two parameterized test cases,
>>> drm_check_plane_state and drm_check_invalid_plane_state.
>>>
>>> Passing output:
>>>
>>> == drm_plane_helper (2 subtests) ===
>>> == drm_check_plane_state ===
>>> [PASSED] clipping_simple
>>> [PASSED] clipping_rotate_reflect
>>> [PASSED] positioning_simple
>>> [PASSED] upscaling
>>> [PASSED] downscaling
>>> [PASSED] rounding1
>>> [PASSED] rounding2
>>> [PASSED] rounding3
>>> [PASSED] rounding4
>>> == [PASSED] drm_check_plane_state ==
>>> == drm_check_invalid_plane_state ===
>>> [PASSED] positioning_invalid
>>> [PASSED] upscaling_invalid
>>> [PASSED] downscaling_invalid
>>> == [PASSED] drm_check_invalid_plane_state ==
>>> [PASSED] drm_plane_helper =
>>>
>>> Testing complete. Ran 12 tests: passed: 12
>>>
>>> v2: Add missing EXPECT/ASSERT (Maíra)
>>>
>>> Signed-off-by: Michał Winiarski
>>> ---
>>> drivers/gpu/drm/tests/drm_plane_helper_test.c | 456 ++
>>> 1 file changed, 267 insertions(+), 189 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/tests/drm_plane_helper_test.c
>>> b/drivers/gpu/drm/tests/drm_plane_helper_test.c
>>> index 0bbd42d2d37b..505173b019d7 100644
>>> --- a/drivers/gpu/drm/tests/drm_plane_helper_test.c
>>> +++ b/drivers/gpu/drm/tests/drm_plane_helper_test.c
>>> @@ -12,59 +12,97 @@
>>> #include
>>> #include
>>>
>>> -static void set_src(struct drm_plane_state *plane_state,
>>> - unsigned int src_x, unsigned int src_y,
>>> - unsigned int src_w, unsigned int src_h)
>>> +static const struct drm_crtc_state crtc_state = {
>>> + .crtc = ZERO_SIZE_PTR,
>>> + .enable = true,
>>> + .active = true,
>>> + .mode = {
>>> + DRM_MODE("1024x768", 0, 65000, 1024, 1048,
>>> +1184, 1344, 0, 768, 771, 777, 806, 0,
>>> +DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC)
>>> + },
>>> +};
>>> +
>>> +struct drm_check_plane_state_test {
>>> + const char *name;
>>> + const char *msg;
>>> + struct {
>>> + unsigned int x;
>>> + unsigned int y;
>>> + unsigned int w;
>>> + unsigned int h;
>>> + } src, src_expected;
>>> + struct {
>>> + int x;
>>> + int y;
>>> + unsigned int w;
>>> + unsigned int h;
>>> + } crtc, crtc_expected;
>>> + unsigned int rotation;
>>> + int min_scale;
>>> + int max_scale;
>>> + bool can_position;
>>> +};
>>> +
>>> +static int drm_plane_helper_init(struct kunit *test)
>>> {
>>> - plane_state->src_x = src_x;
>>> - plane_state->src_y = src_y;
>>> - plane_state->src_w = src_w;
>>> - plane_state->src_h = src_h;
>>> + const struct drm_check_plane_state_test *params = test->param_value;
>>> + struct drm_plane *plane;
>>> + struct drm_framebuffer *fb;
>>> + struct drm_plane_state *mock;
>>> +
>>> + plane = kunit_kzalloc(test, sizeof(*plane), GFP_KERNEL);
>>> + KUNIT_ASSERT_NOT_NULL(test, plane);
>>> +
>>> + fb = kunit_kzalloc(test, sizeof(*fb), GFP_KERNEL);
>>> + KUNIT_ASSERT_NOT_NULL(test, fb);
>>> + fb->width = 2048;
>>> + fb->height = 2048;
>>> +
>>> + mock = kunit_kzalloc(test, sizeof(*mock), GFP_KERNEL);
>>> + KUNIT_ASSERT_NOT_NULL(test, mock);
>>> + mock->plane = plane;
>>> + mock->crtc = ZERO_SIZE_PTR;
>>> + mock->fb = fb;
>>> + mock->rotation = params->rotation;
>>> + mock->src_x = params->src.x;
>>> + mock->src_y = params->src.y;
>>> + mock->src_w = params->src.w;
>>> + mock->src_h = params->src.h;
>>> + mock->crtc_x = params->crtc.x;
>>> + mock->crtc_y = params->crtc.y;
>>> + mock->crtc_w = params->crtc.w;
>>> + mock->crtc_h = params->crtc.h;
>>> +
>>> + test->priv = mock;
>>> +
>>> + return 0;
>>> }
>>>
>>> -static bool check_src_eq(struct kunit *test, struct drm_plane_state
>>> *plane_state,
>>> +static void check_src_eq(struct kunit *test, struct drm_plane_state
>>> *plane_state,
>>> unsigned int src_x, unsigned int src_y,
>>> unsigned int src_w, unsigned int src_h)
>>> {
>>> struct drm_rect expected = DRM_RECT_INIT(src_x, src_y, src_w, src_h);
>>>
>>> - if (plane_state->src.x1 < 0) {
>>> - kunit_err(test,
>>> - "src x coordinate %x should never be below 0, src: "
>>>
Re: [PATCH linux-next] drm/i915: Remove the unneeded result variables
On Fri, 02 Sep 2022, Jani Nikula wrote:
> On Fri, 02 Sep 2022, cgel@gmail.com wrote:
>> From: zhang songyi
>>
>> Return the mul_u32_fixed16() and div_fixed16() directly instead of
>> redundant variables.
>>
>> Reported-by: Zeal Robot
>> Signed-off-by: zhang songyi
>
> NAK.
And to explain this rude reply to our friendly community:
There's never *any* response to my review comments from
cgel@gmail.com, so I can't be bothered to write anything more than
just "NAK".
>
>
> BR,
> Jani.
>
>
>> ---
>> drivers/gpu/drm/i915/intel_pm.c | 9 +++--
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 210c1f78cc90..a6757ed9081a 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -5272,7 +5272,6 @@ skl_wm_method2(u32 pixel_rate, u32 pipe_htotal, u32
>> latency,
>> uint_fixed_16_16_t plane_blocks_per_line)
>> {
>> u32 wm_intermediate_val;
>> -uint_fixed_16_16_t ret;
>>
>> if (latency == 0)
>> return FP_16_16_MAX;
>> @@ -5280,8 +5279,8 @@ skl_wm_method2(u32 pixel_rate, u32 pipe_htotal, u32
>> latency,
>> wm_intermediate_val = latency * pixel_rate;
>> wm_intermediate_val = DIV_ROUND_UP(wm_intermediate_val,
>> pipe_htotal * 1000);
>> -ret = mul_u32_fixed16(wm_intermediate_val, plane_blocks_per_line);
>> -return ret;
>> +
>> +return mul_u32_fixed16(wm_intermediate_val, plane_blocks_per_line);
>> }
>>
>> static uint_fixed_16_16_t
>> @@ -5290,7 +5289,6 @@ intel_get_linetime_us(const struct intel_crtc_state
>> *crtc_state)
>> struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
>> u32 pixel_rate;
>> u32 crtc_htotal;
>> -uint_fixed_16_16_t linetime_us;
>>
>> if (!crtc_state->hw.active)
>> return u32_to_fixed16(0);
>> @@ -5301,9 +5299,8 @@ intel_get_linetime_us(const struct intel_crtc_state
>> *crtc_state)
>> return u32_to_fixed16(0);
>>
>> crtc_htotal = crtc_state->hw.pipe_mode.crtc_htotal;
>> -linetime_us = div_fixed16(crtc_htotal * 1000, pixel_rate);
>>
>> -return linetime_us;
>> +return div_fixed16(crtc_htotal * 1000, pixel_rate);
>> }
>>
>> static int
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH linux-next] drm/i915: Remove the unneeded result variables
On Fri, 02 Sep 2022, cgel@gmail.com wrote:
> From: zhang songyi
>
> Return the mul_u32_fixed16() and div_fixed16() directly instead of
> redundant variables.
>
> Reported-by: Zeal Robot
> Signed-off-by: zhang songyi
NAK.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_pm.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 210c1f78cc90..a6757ed9081a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5272,7 +5272,6 @@ skl_wm_method2(u32 pixel_rate, u32 pipe_htotal, u32
> latency,
> uint_fixed_16_16_t plane_blocks_per_line)
> {
> u32 wm_intermediate_val;
> - uint_fixed_16_16_t ret;
>
> if (latency == 0)
> return FP_16_16_MAX;
> @@ -5280,8 +5279,8 @@ skl_wm_method2(u32 pixel_rate, u32 pipe_htotal, u32
> latency,
> wm_intermediate_val = latency * pixel_rate;
> wm_intermediate_val = DIV_ROUND_UP(wm_intermediate_val,
> pipe_htotal * 1000);
> - ret = mul_u32_fixed16(wm_intermediate_val, plane_blocks_per_line);
> - return ret;
> +
> + return mul_u32_fixed16(wm_intermediate_val, plane_blocks_per_line);
> }
>
> static uint_fixed_16_16_t
> @@ -5290,7 +5289,6 @@ intel_get_linetime_us(const struct intel_crtc_state
> *crtc_state)
> struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> u32 pixel_rate;
> u32 crtc_htotal;
> - uint_fixed_16_16_t linetime_us;
>
> if (!crtc_state->hw.active)
> return u32_to_fixed16(0);
> @@ -5301,9 +5299,8 @@ intel_get_linetime_us(const struct intel_crtc_state
> *crtc_state)
> return u32_to_fixed16(0);
>
> crtc_htotal = crtc_state->hw.pipe_mode.crtc_htotal;
> - linetime_us = div_fixed16(crtc_htotal * 1000, pixel_rate);
>
> - return linetime_us;
> + return div_fixed16(crtc_htotal * 1000, pixel_rate);
> }
>
> static int
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v2 2/2] drm/plane_helper: Split into parameterized test cases
On Thu, Sep 01, 2022 at 09:20:55AM -0300, Maíra Canal wrote:
> Hi Michał
>
> On 8/31/22 17:45, Michał Winiarski wrote:
> > The test was constructed as a single function (test case) which checks
> > multiple conditions, calling the function that is tested multiple times
> > with different arguments.
> > This usually means that it can be easily converted into multiple test
> > cases.
> > Split igt_check_plane_state into two parameterized test cases,
> > drm_check_plane_state and drm_check_invalid_plane_state.
> >
> > Passing output:
> >
> > == drm_plane_helper (2 subtests) ===
> > == drm_check_plane_state ===
> > [PASSED] clipping_simple
> > [PASSED] clipping_rotate_reflect
> > [PASSED] positioning_simple
> > [PASSED] upscaling
> > [PASSED] downscaling
> > [PASSED] rounding1
> > [PASSED] rounding2
> > [PASSED] rounding3
> > [PASSED] rounding4
> > == [PASSED] drm_check_plane_state ==
> > == drm_check_invalid_plane_state ===
> > [PASSED] positioning_invalid
> > [PASSED] upscaling_invalid
> > [PASSED] downscaling_invalid
> > == [PASSED] drm_check_invalid_plane_state ==
> > [PASSED] drm_plane_helper =
> >
> > Testing complete. Ran 12 tests: passed: 12
> >
> > v2: Add missing EXPECT/ASSERT (Maíra)
> >
> > Signed-off-by: Michał Winiarski
> > ---
> > drivers/gpu/drm/tests/drm_plane_helper_test.c | 456 ++
> > 1 file changed, 267 insertions(+), 189 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tests/drm_plane_helper_test.c
> > b/drivers/gpu/drm/tests/drm_plane_helper_test.c
> > index 0bbd42d2d37b..505173b019d7 100644
> > --- a/drivers/gpu/drm/tests/drm_plane_helper_test.c
> > +++ b/drivers/gpu/drm/tests/drm_plane_helper_test.c
> > @@ -12,59 +12,97 @@
> > #include
> > #include
> >
> > -static void set_src(struct drm_plane_state *plane_state,
> > - unsigned int src_x, unsigned int src_y,
> > - unsigned int src_w, unsigned int src_h)
> > +static const struct drm_crtc_state crtc_state = {
> > + .crtc = ZERO_SIZE_PTR,
> > + .enable = true,
> > + .active = true,
> > + .mode = {
> > + DRM_MODE("1024x768", 0, 65000, 1024, 1048,
> > +1184, 1344, 0, 768, 771, 777, 806, 0,
> > +DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC)
> > + },
> > +};
> > +
> > +struct drm_check_plane_state_test {
> > + const char *name;
> > + const char *msg;
> > + struct {
> > + unsigned int x;
> > + unsigned int y;
> > + unsigned int w;
> > + unsigned int h;
> > + } src, src_expected;
> > + struct {
> > + int x;
> > + int y;
> > + unsigned int w;
> > + unsigned int h;
> > + } crtc, crtc_expected;
> > + unsigned int rotation;
> > + int min_scale;
> > + int max_scale;
> > + bool can_position;
> > +};
> > +
> > +static int drm_plane_helper_init(struct kunit *test)
> > {
> > - plane_state->src_x = src_x;
> > - plane_state->src_y = src_y;
> > - plane_state->src_w = src_w;
> > - plane_state->src_h = src_h;
> > + const struct drm_check_plane_state_test *params = test->param_value;
> > + struct drm_plane *plane;
> > + struct drm_framebuffer *fb;
> > + struct drm_plane_state *mock;
> > +
> > + plane = kunit_kzalloc(test, sizeof(*plane), GFP_KERNEL);
> > + KUNIT_ASSERT_NOT_NULL(test, plane);
> > +
> > + fb = kunit_kzalloc(test, sizeof(*fb), GFP_KERNEL);
> > + KUNIT_ASSERT_NOT_NULL(test, fb);
> > + fb->width = 2048;
> > + fb->height = 2048;
> > +
> > + mock = kunit_kzalloc(test, sizeof(*mock), GFP_KERNEL);
> > + KUNIT_ASSERT_NOT_NULL(test, mock);
> > + mock->plane = plane;
> > + mock->crtc = ZERO_SIZE_PTR;
> > + mock->fb = fb;
> > + mock->rotation = params->rotation;
> > + mock->src_x = params->src.x;
> > + mock->src_y = params->src.y;
> > + mock->src_w = params->src.w;
> > + mock->src_h = params->src.h;
> > + mock->crtc_x = params->crtc.x;
> > + mock->crtc_y = params->crtc.y;
> > + mock->crtc_w = params->crtc.w;
> > + mock->crtc_h = params->crtc.h;
> > +
> > + test->priv = mock;
> > +
> > + return 0;
> > }
> >
> > -static bool check_src_eq(struct kunit *test, struct drm_plane_state
> > *plane_state,
> > +static void check_src_eq(struct kunit *test, struct drm_plane_state
> > *plane_state,
> > unsigned int src_x, unsigned int src_y,
> > unsigned int src_w, unsigned int src_h)
> > {
> > struct drm_rect expected = DRM_RECT_INIT(src_x, src_y, src_w, src_h);
> >
> > - if (plane_state->src.x1 < 0) {
> > - kunit_err(test,
> > - "src x coordinate %x should never be below 0, src: "
> > DRM_RECT_FP_FMT,
> > -
[PATCH] drm/vc4: Add module dependency on hdmi-codec
The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In
order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver
will register a device matching the HDMI codec driver, and then register
an ASoC card using that codec.
However, if vc4 is compiled as a module, chances are that the hdmi-codec
driver will be too. In such a case, the module loader will have a very
narrow window to load the module between the device registration and the
card registration.
If it fails to load the module in time, the card registration will fail
with EPROBE_DEFER, and we'll abort the audio initialisation,
unregistering the HDMI codec device in the process.
The next time the bind callback will be run, it's likely that we end up
missing that window again, effectively preventing vc4 to probe entirely.
In order to prevent this, we can create a soft dependency of the vc4
driver on the HDMI codec one so that we're sure the HDMI codec will be
loaded before the VC4 module is, and thus we'll never end up in the
previous situation.
Fixes: 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index ffbbb454c9e8..2027063fdc30 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -490,6 +490,7 @@ module_init(vc4_drm_register);
module_exit(vc4_drm_unregister);
MODULE_ALIAS("platform:vc4-drm");
+MODULE_SOFTDEP("pre: snd-soc-hdmi-codec");
MODULE_DESCRIPTION("Broadcom VC4 DRM Driver");
MODULE_AUTHOR("Eric Anholt ");
MODULE_LICENSE("GPL v2");
--
2.37.1
Re: [PATCH 2/2] drm/format: Split into more granular test cases
On 9/2/22 11:06, Michał Winiarski wrote:
On Wed, Aug 31, 2022 at 07:15:11PM -0300, Maíra Canal wrote:
Hi Michał
Some very minor nits inline, but either way:
Reviewed-by: Maíra Canal
On 8/31/22 18:56, Michał Winiarski wrote:
While we have multiple test cases, most of them check multiple
conditions, calling the function that is tested multiple times with
different arguments (with comments that indicate test case boundary).
This usually means that it can be easily converted into multiple test
cases.
Passing output:
= drm_format (18 subtests) =
[PASSED] drm_format_block_width_invalid
[PASSED] drm_format_block_width_one_plane
[PASSED] drm_format_block_width_two_plane
[PASSED] drm_format_block_width_three_plane
[PASSED] drm_format_block_width_tiled
[PASSED] drm_format_block_height_invalid
[PASSED] drm_format_block_height_one_plane
[PASSED] drm_format_block_height_two_plane
[PASSED] drm_format_block_height_three_plane
[PASSED] drm_format_block_height_tiled
[PASSED] drm_format_min_pitch_invalid
[PASSED] drm_format_min_pitch_one_plane_8bpp
[PASSED] drm_format_min_pitch_one_plane_16bpp
[PASSED] drm_format_min_pitch_one_plane_24bpp
[PASSED] drm_format_min_pitch_one_plane_32bpp
[PASSED] drm_format_min_pitch_two_plane
[PASSED] drm_format_min_pitch_three_plane_8bpp
[PASSED] drm_format_min_pitch_tiled
As Jani pointed out in [1], "drm_" prefix can be a bit confusing. I will
send a patch tomorrow using the prefix "test_drm_" on all tests to make the
naming more consistent. It would be nice if this patch already hold the new
naming, but anyway I can send a patch changing it later with the new prefix
gets approved.
[1]
https://lore.kernel.org/dri-devel/20220831104941.doc75juindcm5...@nostramo.hardline.pl/T/#m82b4e710063b47029a8bd4716d137e575640da9a
Sure - I can resend with different naming convention if needed.
The naming convention ended up being more complicated than I originally
thought, so I believe it is great as it is. If the patch doesn't get
other feedback and anyone pushes it, I can push in a couple of days.
Best Regards,
- Maíra Canal
=== [PASSED] drm_format
Testing complete. Ran 18 tests: passed: 18
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/tests/drm_format_test.c | 156
1 file changed, 108 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_format_test.c
b/drivers/gpu/drm/tests/drm_format_test.c
index 0efa88bf56a9..1936d2d59908 100644
--- a/drivers/gpu/drm/tests/drm_format_test.c
+++ b/drivers/gpu/drm/tests/drm_format_test.c
@@ -9,100 +9,133 @@
#include
-static void igt_check_drm_format_block_width(struct kunit *test)
+static void drm_format_block_width_invalid(struct kunit *test)
{
const struct drm_format_info *info = NULL;
- /* Test invalid arguments */
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 0), 0);
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, -1), 0);
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 1), 0);
+}
+
+static void drm_format_block_width_one_plane(struct kunit *test)
+{
+ const struct drm_format_info *info =
drm_format_info(DRM_FORMAT_XRGB);
- /* Test 1 plane format */
- info = drm_format_info(DRM_FORMAT_XRGB);
KUNIT_ASSERT_NOT_NULL(test, info);
+
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 0), 1);
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 1), 0);
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, -1), 0);
+}
+
+static void drm_format_block_width_two_plane(struct kunit *test)
s/plane/planes
NV12 format has two planes, therefore it's a two-plane format.
-Michał
Best Regards,
- Maíra Canal
+{
+ const struct drm_format_info *info = drm_format_info(DRM_FORMAT_NV12);
- /* Test 2 planes format */
- info = drm_format_info(DRM_FORMAT_NV12);
KUNIT_ASSERT_NOT_NULL(test, info);
+
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 0), 1);
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 1), 1);
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 2), 0);
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, -1), 0);
+}
+
+static void drm_format_block_width_three_plane(struct kunit *test)
+{
+ const struct drm_format_info *info = drm_format_info(DRM_FORMAT_YUV422);
- /* Test 3 planes format */
- info = drm_format_info(DRM_FORMAT_YUV422);
KUNIT_ASSERT_NOT_NULL(test, info);
+
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 0), 1);
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 1), 1);
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 2), 1);
KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 3), 0);
Re: [PATCH 3/3] drm: omapdrm: Do no allocate non-scanout GEMs through DMM/TILER
On 30.08.22 г. 21:23 ч., Tomi Valkeinen wrote: On 30/08/2022 21:08, Ivaylo Dimitrov wrote: flags &= ~OMAP_BO_TILED_MASK; flags |= 0x0008; flags |= OMAP_BO_WC; bo = omap_bo_new(dev, size, flags); As you can see we use 0x0008 (OMAP_BO_MEM_CONTIG) unconditionally. This was a hack added since even non-scanout buffers sometimes need to be contiguous (video decoder surfaces), but we had no way back Hmm, why would video decoder need linear memory? No MMU? Not sure about this case, but many/most IPs don't have MMU. E.g. CSI-2 or parallel capture. If you tell me what the code should look like, I can rebuild the lib and post a copy. Long term, I'd like to start using DMA-BUF Heaps for CMA memory allocations in gralloc and elsewhere, then drop out the DMM/TILER support from OMAPDRM, since it never really belonged there in the first place (being a IOMMU unrelated to the display/GPU). Umm, how will we rotate scanout buffers then? Didn't we discuss this earlier in this thread. Or some other thread. Related to VRFB... I'm not sure =). Yeah, I think so. VRFB is still on my list though, along with TE support for droid4 :). Anyway, neither VRFB nor DMM/TILER are part of the DSS. They're part of the memory subsystem. They can be used without DSS being in the setup. Thus the code for VRFB and DMM/TILER should not be in the DSS driver. Makes sense. The DSS driver should still, of course, support DMM/TILER (and maybe VRFB some day) in the "use" sense, i.e. so that DSS can use the DMM/TILER provided from another driver. Ah, this is what I was missing all the time, for some reason I was left with the impression that userland will have to know about those details. Now it is clear. But how exactly that's to be implemented, I don't know. Seems Andrew has an idea. Ivo Tomi
Re: [PATCH 2/2] drm/format: Split into more granular test cases
On Wed, Aug 31, 2022 at 07:15:11PM -0300, Maíra Canal wrote:
> Hi Michał
>
> Some very minor nits inline, but either way:
>
> Reviewed-by: Maíra Canal
>
> On 8/31/22 18:56, Michał Winiarski wrote:
> > While we have multiple test cases, most of them check multiple
> > conditions, calling the function that is tested multiple times with
> > different arguments (with comments that indicate test case boundary).
> > This usually means that it can be easily converted into multiple test
> > cases.
> >
> > Passing output:
> >
> > = drm_format (18 subtests) =
> > [PASSED] drm_format_block_width_invalid
> > [PASSED] drm_format_block_width_one_plane
> > [PASSED] drm_format_block_width_two_plane
> > [PASSED] drm_format_block_width_three_plane
> > [PASSED] drm_format_block_width_tiled
> > [PASSED] drm_format_block_height_invalid
> > [PASSED] drm_format_block_height_one_plane
> > [PASSED] drm_format_block_height_two_plane
> > [PASSED] drm_format_block_height_three_plane
> > [PASSED] drm_format_block_height_tiled
> > [PASSED] drm_format_min_pitch_invalid
> > [PASSED] drm_format_min_pitch_one_plane_8bpp
> > [PASSED] drm_format_min_pitch_one_plane_16bpp
> > [PASSED] drm_format_min_pitch_one_plane_24bpp
> > [PASSED] drm_format_min_pitch_one_plane_32bpp
> > [PASSED] drm_format_min_pitch_two_plane
> > [PASSED] drm_format_min_pitch_three_plane_8bpp
> > [PASSED] drm_format_min_pitch_tiled
>
> As Jani pointed out in [1], "drm_" prefix can be a bit confusing. I will
> send a patch tomorrow using the prefix "test_drm_" on all tests to make the
> naming more consistent. It would be nice if this patch already hold the new
> naming, but anyway I can send a patch changing it later with the new prefix
> gets approved.
>
> [1]
> https://lore.kernel.org/dri-devel/20220831104941.doc75juindcm5...@nostramo.hardline.pl/T/#m82b4e710063b47029a8bd4716d137e575640da9a
Sure - I can resend with different naming convention if needed.
>
> > === [PASSED] drm_format
> >
> > Testing complete. Ran 18 tests: passed: 18
> >
> > Signed-off-by: Michał Winiarski
> > ---
> > drivers/gpu/drm/tests/drm_format_test.c | 156
> > 1 file changed, 108 insertions(+), 48 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tests/drm_format_test.c
> > b/drivers/gpu/drm/tests/drm_format_test.c
> > index 0efa88bf56a9..1936d2d59908 100644
> > --- a/drivers/gpu/drm/tests/drm_format_test.c
> > +++ b/drivers/gpu/drm/tests/drm_format_test.c
> > @@ -9,100 +9,133 @@
> > #include
> > -static void igt_check_drm_format_block_width(struct kunit *test)
> > +static void drm_format_block_width_invalid(struct kunit *test)
> > {
> > const struct drm_format_info *info = NULL;
> > - /* Test invalid arguments */
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 0), 0);
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, -1), 0);
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 1), 0);
> > +}
> > +
> > +static void drm_format_block_width_one_plane(struct kunit *test)
> > +{
> > + const struct drm_format_info *info =
> > drm_format_info(DRM_FORMAT_XRGB);
> > - /* Test 1 plane format */
> > - info = drm_format_info(DRM_FORMAT_XRGB);
> > KUNIT_ASSERT_NOT_NULL(test, info);
> > +
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 0), 1);
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 1), 0);
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, -1), 0);
> > +}
> > +
> > +static void drm_format_block_width_two_plane(struct kunit *test)
>
> s/plane/planes
NV12 format has two planes, therefore it's a two-plane format.
-Michał
>
> Best Regards,
> - Maíra Canal
>
> > +{
> > + const struct drm_format_info *info = drm_format_info(DRM_FORMAT_NV12);
> > - /* Test 2 planes format */
> > - info = drm_format_info(DRM_FORMAT_NV12);
> > KUNIT_ASSERT_NOT_NULL(test, info);
> > +
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 0), 1);
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 1), 1);
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 2), 0);
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, -1), 0);
> > +}
> > +
> > +static void drm_format_block_width_three_plane(struct kunit *test)
> > +{
> > + const struct drm_format_info *info = drm_format_info(DRM_FORMAT_YUV422);
> > - /* Test 3 planes format */
> > - info = drm_format_info(DRM_FORMAT_YUV422);
> > KUNIT_ASSERT_NOT_NULL(test, info);
> > +
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 0), 1);
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 1), 1);
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 2), 1);
> > KUNIT_EXPECT_EQ(test, drm_format_info_block_width(info, 3), 0);
> >
Re: [Intel-gfx] [PATCH 08/11] drm/edid: Use the correct formula for standard timings
On Fri, Sep 02, 2022 at 04:41:36PM +0300, Jani Nikula wrote:
> On Sat, 27 Aug 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Prefer the timing formula indicated by the range
> > descriptor for generating the non-DMT standard timings.
> >
> > Previously we just used CVT for all EDID 1.4 continuous
> > frequency displays without even checking if the range
> > descriptor indicates otherwise. Now we check the range
> > descriptor first, and fall back to CVT if nothing else
> > was indicated. EDID 1.4 more or less deprecates GTF/GTF2
> > but there are still a lot of 1.4 EDIDs out there that
> > don't advertise CVT support, so seems safer to use the
> > formula the EDID actually reports as supported.
> >
> > For EDID 1.3 we use GTF2 if indicated (as before), and for
> > EDID 1.2+ we now just use GTF without even checking the
> > feature flag. There seem to be quite a few EDIDs out there that
> > don't set the GTF feature flag but still include a GTF range
> > descriptor and non-DMT standard timings.
> >
> > This to me seems to be roughly what appendix B of EDID 1.4
> > suggests should be done.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_edid.c | 49 +++---
> > 1 file changed, 41 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index fed2bdd55c09..c1c85b9e1208 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3077,20 +3077,53 @@ drm_gtf2_2j(const struct drm_edid *drm_edid)
> > return descriptor ?
> > descriptor->data.other_data.data.range.formula.gtf2.j : 0;
> > }
> >
> > +static void
> > +get_timing_level(const struct detailed_timing *descriptor, void *data)
> > +{
> > + int *res = data;
> > +
> > + if (!is_display_descriptor(descriptor, EDID_DETAIL_MONITOR_RANGE))
> > + return;
> > +
> > + BUILD_BUG_ON(offsetof(typeof(*descriptor),
> > data.other_data.data.range.flags) != 10);
> > +
> > + switch (descriptor->data.other_data.data.range.flags) {
> > + case DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG:
> > + *res = LEVEL_GTF;
> > + break;
> > + case DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG:
> > + *res = LEVEL_GTF2;
> > + break;
> > + case DRM_EDID_CVT_SUPPORT_FLAG:
> > + *res = LEVEL_CVT;
> > + break;
> > + default:
> > + break;
> > + }
> > +}
> > +
> > /* Get standard timing level (CVT/GTF/DMT). */
> > static int standard_timing_level(const struct drm_edid *drm_edid)
> > {
> > const struct edid *edid = drm_edid->edid;
> >
> > - if (edid->revision >= 2) {
> > - if (edid->revision >= 4 && (edid->features &
> > DRM_EDID_FEATURE_DEFAULT_GTF))
> > - return LEVEL_CVT;
> > - if (drm_gtf2_hbreak(drm_edid))
> > - return LEVEL_GTF2;
> > - if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF)
> > - return LEVEL_GTF;
> > + if (edid->revision >= 4) {
> > + /*
> > +* If the range descriptor doesn't
> > +* indicate otherwise default to CVT
> > +*/
> > + int ret = LEVEL_CVT;
> > +
> > + drm_for_each_detailed_block(drm_edid, get_timing_level, );
>
> Please remind me why it's okay to iterate all of them and pick the last?
> I mean ret gets overwritten by the last block.
I think there is an implied assumption that there is only
zero or one of these included in the EDID. While not explicitly
stated in the spec, there is no mention anywhere what it would
mean to have multiple different types of range descriptors.
And so far I didn't come across any EDIDs that would disagree with
that.
>
> Otherwise it all seems okay to me, though I admit my confidence level in
> this review is considerably lower than for the other patches.
>
> Reviewed-by: Jani Nikula
>
>
> > +
> > + return ret;
> > + } else if (edid->revision >= 3 && drm_gtf2_hbreak(drm_edid)) {
> > + return LEVEL_GTF2;
> > + } else if (edid->revision >= 2) {
> > + return LEVEL_GTF;
> > + } else {
> > + return LEVEL_DMT;
> > }
> > - return LEVEL_DMT;
> > }
> >
> > /*
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"
On Fri, 02 Sep 2022, Michał Winiarski wrote: > Having said that - I do believe that igt_* prefix don't belong here > (which is why I'm progressively trying to get rid of in the patches > that refactor some of the tests). Just clarifying that I'm not trying to defend igt_ prefix at all, and I agree we should get rid of it. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 01/11] drm/edid: Handle EDID 1.4 range descriptor h/vfreq offsets
On Fri, Aug 26, 2022 at 06:40:12PM -0700, Navare, Manasi wrote:
> On Sat, Aug 27, 2022 at 12:34:51AM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > EDID 1.4 introduced some extra flags in the range
> > descriptor to support min/max h/vfreq >= 255. Consult them
> > to correctly parse the vfreq limits.
> >
> > Note that some combinations of the flags are documented
> > as "reserved" (as are some other values in the descriptor)
> > but explicitly checking for those doesn't seem particularly
> > worthwile since we end up with bogus results whether we
> > decode them or not.
> >
> > v2: Increase the storage to u16 to make it work (Jani)
> > Note the "reserved" values situation (Jani)
> > v3: Document the EDID version number in the defines
> > Drop some bogus (u8) casts
> >
> > Cc: sta...@vger.kernel.org
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6519
> > Reviewed-by: Jani Nikula
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_debugfs.c | 4 ++--
> > drivers/gpu/drm/drm_edid.c| 24 ++--
> > include/drm/drm_connector.h | 4 ++--
> > include/drm/drm_edid.h| 5 +
> > 4 files changed, 27 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> > index 493922069c90..01ee3febb813 100644
> > --- a/drivers/gpu/drm/drm_debugfs.c
> > +++ b/drivers/gpu/drm/drm_debugfs.c
> > @@ -377,8 +377,8 @@ static int vrr_range_show(struct seq_file *m, void
> > *data)
> > if (connector->status != connector_status_connected)
> > return -ENODEV;
> >
> > - seq_printf(m, "Min: %u\n",
> > (u8)connector->display_info.monitor_range.min_vfreq);
> > - seq_printf(m, "Max: %u\n",
> > (u8)connector->display_info.monitor_range.max_vfreq);
> > + seq_printf(m, "Min: %u\n",
> > connector->display_info.monitor_range.min_vfreq);
> > + seq_printf(m, "Max: %u\n",
> > connector->display_info.monitor_range.max_vfreq);
> >
> > return 0;
> > }
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 90a5e26eafa8..4005dab6147d 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -6020,12 +6020,14 @@ static void drm_parse_cea_ext(struct drm_connector
> > *connector,
> > }
> >
> > static
> > -void get_monitor_range(const struct detailed_timing *timing,
> > - void *info_monitor_range)
> > +void get_monitor_range(const struct detailed_timing *timing, void *c)
> > {
> > - struct drm_monitor_range_info *monitor_range = info_monitor_range;
> > + struct detailed_mode_closure *closure = c;
> > + struct drm_display_info *info = >connector->display_info;
> > + struct drm_monitor_range_info *monitor_range = >monitor_range;
> > const struct detailed_non_pixel *data = >data.other_data;
> > const struct detailed_data_monitor_range *range = >data.range;
> > + const struct edid *edid = closure->drm_edid->edid;
> >
> > if (!is_display_descriptor(timing, EDID_DETAIL_MONITOR_RANGE))
> > return;
> > @@ -6041,18 +6043,28 @@ void get_monitor_range(const struct detailed_timing
> > *timing,
> >
> > monitor_range->min_vfreq = range->min_vfreq;
> > monitor_range->max_vfreq = range->max_vfreq;
> > +
> > + if (edid->revision >= 4) {
> > + if (data->pad2 & DRM_EDID_RANGE_OFFSET_MIN_VFREQ)
> > + monitor_range->min_vfreq += 255;
> > + if (data->pad2 & DRM_EDID_RANGE_OFFSET_MAX_VFREQ)
> > + monitor_range->max_vfreq += 255;
>
> Yes this makes sense. This looks like added for supporting HRR (high
> refresh rate) panels.
> Do you think we should mention that in the commit message or in the
> comment in the code itself?
Didn't really see any need for that. Should be fairly obvious
a single u8 alone can't represent big values.
>
> Other than that looks good to me:
>
> Reviewed-by: Manasi Navare
Thanks. Pushed this one to drm-misc-fixes.
>
> Manasi
>
> > + }
> > }
> >
> > static void drm_get_monitor_range(struct drm_connector *connector,
> > const struct drm_edid *drm_edid)
> > {
> > - struct drm_display_info *info = >display_info;
> > + const struct drm_display_info *info = >display_info;
> > + struct detailed_mode_closure closure = {
> > + .connector = connector,
> > + .drm_edid = drm_edid,
> > + };
> >
> > if (!version_greater(drm_edid, 1, 1))
> > return;
> >
> > - drm_for_each_detailed_block(drm_edid, get_monitor_range,
> > - >monitor_range);
> > + drm_for_each_detailed_block(drm_edid, get_monitor_range, );
> >
> > DRM_DEBUG_KMS("Supported Monitor Refresh rate range is %d Hz - %d Hz\n",
> > info->monitor_range.min_vfreq,
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 248206bbd975..56aee949c6fa 100644
> > ---
Re: [Intel-gfx] [PATCH 08/11] drm/edid: Use the correct formula for standard timings
On Sat, 27 Aug 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Prefer the timing formula indicated by the range
> descriptor for generating the non-DMT standard timings.
>
> Previously we just used CVT for all EDID 1.4 continuous
> frequency displays without even checking if the range
> descriptor indicates otherwise. Now we check the range
> descriptor first, and fall back to CVT if nothing else
> was indicated. EDID 1.4 more or less deprecates GTF/GTF2
> but there are still a lot of 1.4 EDIDs out there that
> don't advertise CVT support, so seems safer to use the
> formula the EDID actually reports as supported.
>
> For EDID 1.3 we use GTF2 if indicated (as before), and for
> EDID 1.2+ we now just use GTF without even checking the
> feature flag. There seem to be quite a few EDIDs out there that
> don't set the GTF feature flag but still include a GTF range
> descriptor and non-DMT standard timings.
>
> This to me seems to be roughly what appendix B of EDID 1.4
> suggests should be done.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 49 +++---
> 1 file changed, 41 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index fed2bdd55c09..c1c85b9e1208 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3077,20 +3077,53 @@ drm_gtf2_2j(const struct drm_edid *drm_edid)
> return descriptor ?
> descriptor->data.other_data.data.range.formula.gtf2.j : 0;
> }
>
> +static void
> +get_timing_level(const struct detailed_timing *descriptor, void *data)
> +{
> + int *res = data;
> +
> + if (!is_display_descriptor(descriptor, EDID_DETAIL_MONITOR_RANGE))
> + return;
> +
> + BUILD_BUG_ON(offsetof(typeof(*descriptor),
> data.other_data.data.range.flags) != 10);
> +
> + switch (descriptor->data.other_data.data.range.flags) {
> + case DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG:
> + *res = LEVEL_GTF;
> + break;
> + case DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG:
> + *res = LEVEL_GTF2;
> + break;
> + case DRM_EDID_CVT_SUPPORT_FLAG:
> + *res = LEVEL_CVT;
> + break;
> + default:
> + break;
> + }
> +}
> +
> /* Get standard timing level (CVT/GTF/DMT). */
> static int standard_timing_level(const struct drm_edid *drm_edid)
> {
> const struct edid *edid = drm_edid->edid;
>
> - if (edid->revision >= 2) {
> - if (edid->revision >= 4 && (edid->features &
> DRM_EDID_FEATURE_DEFAULT_GTF))
> - return LEVEL_CVT;
> - if (drm_gtf2_hbreak(drm_edid))
> - return LEVEL_GTF2;
> - if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF)
> - return LEVEL_GTF;
> + if (edid->revision >= 4) {
> + /*
> + * If the range descriptor doesn't
> + * indicate otherwise default to CVT
> + */
> + int ret = LEVEL_CVT;
> +
> + drm_for_each_detailed_block(drm_edid, get_timing_level, );
Please remind me why it's okay to iterate all of them and pick the last?
I mean ret gets overwritten by the last block.
Otherwise it all seems okay to me, though I admit my confidence level in
this review is considerably lower than for the other patches.
Reviewed-by: Jani Nikula
> +
> + return ret;
> + } else if (edid->revision >= 3 && drm_gtf2_hbreak(drm_edid)) {
> + return LEVEL_GTF2;
> + } else if (edid->revision >= 2) {
> + return LEVEL_GTF;
> + } else {
> + return LEVEL_DMT;
> }
> - return LEVEL_DMT;
> }
>
> /*
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"
On Fri, Sep 02, 2022 at 04:03:20PM +0300, Jani Nikula wrote: > On Fri, 02 Sep 2022, Maxime Ripard wrote: > > On Fri, Sep 02, 2022 at 11:04:14AM +0300, Jani Nikula wrote: > >> On Thu, 01 Sep 2022, Maíra Canal wrote: > >> > Hi Maxime, > >> > > >> > On 9/1/22 09:55, Maxime Ripard wrote: > >> >> Hi, > >> >> > >> >> On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote: > >> >>> With the introduction of KUnit, IGT is no longer the only option to run > >> >>> the DRM unit tests, as the tests can be run through kunit-tool or on > >> >>> real hardware with CONFIG_KUNIT. > >> >>> > >> >>> Therefore, remove the "igt_" prefix from the tests and replace it with > >> >>> the "test_drm_" prefix, making the tests' names independent from the > >> >>> tool > >> >>> used. > >> >>> > >> >>> Signed-off-by: Maíra Canal > >> >>> > >> >>> --- > >> >>> v1 -> v2: > >> >>> https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/ > >> >>> - Change "drm_" prefix to "test_drm_", as "drm_" can be a bit > >> >>> confusing (Jani Nikula). > >> >> > >> >> I appreciate it's a bit of a bikeshed but I disagree with this. The > >> >> majority of the kunit tests already out there start with the framework > >> >> name, including *all* the examples in the kunit doc. Plus, it's fairly > >> >> obvious that it's a test, kunit is only about running tests in the first > >> >> place. > >> > > >> > Would it be better to keep it as "drm_"? > >> > >> That's not "keeping". That's renaming igt to drm. > > > > Well, there's like half the tests that are prefixed with drm, the other > > with igt, so it's both really > > > >> > Currently, I don't think it is appropriate to hold the "igt_" prefix, as > >> > the tests are not IGT exclusive, but I don't have a strong opinion on > >> > using the "drm_" or the "test_drm" prefixes. > >> > >> I repeat my stance that "drm_" alone is confusing. > > > > What are you confusing it with? > > > >> For the reason alone that it pollutes the code tagging tools, mixing > >> actual drm_ types and functions with unit test functions. > > > > I don't get it, I'm sorry. All these functions are static and not part > > of any API, so I can't see how it would pollute a code tagging tool. Or > > at least, not more than any driver does. > > > > And we're part of a larger project here, it's about consistency with the > > rest of the ecosystem. > > Okay, so I'm just going to explain what I mean, but say "whatever" right > after and move on. > > For example, drm_buddy_test.c includes drm_buddy.h so with the igt_ -> > drm_ rename none of the test functions may clash with the drm_buddy_ > prefixed existing functions. Ditto for all tests similarly. > > For example drm_buddy_alloc_range() as a name sounds like something that > allocs a range, not something that tests range allocation. On the other > hand, you have drm_buddy_alloc_blocks() which is actually a real > drm_buddy function, not a test. What would you call a test that tests > that? Here, we end up with names that are all prefixed drm_buddy and you > won't know what's the actual function and what's the test unless you > look it up. > > I use code tagging that I can use for finding and completing > e.g. functions. Currently I have the following completions, for > igt_buddy_ and drm_buddy_, respectively: > > Possible completions are: > igt_buddy_alloc_limit igt_buddy_alloc_optimistic > igt_buddy_alloc_pathological > igt_buddy_alloc_pessimistic igt_buddy_alloc_range igt_buddy_alloc_smoke > > Possible completions are: > drm_buddy_alloc_blocksdrm_buddy_block > drm_buddy_block_is_allocateddrm_buddy_block_is_free > drm_buddy_block_is_split drm_buddy_block_offset drm_buddy_block_order > drm_buddy_block_print > drm_buddy_block_size drm_buddy_block_state drm_buddy_block_trim > drm_buddy_fini > drm_buddy_free_block drm_buddy_free_list drm_buddy_init > drm_buddy_init_test > drm_buddy_module_exit drm_buddy_module_init drm_buddy_print > > With the patch at hand, they'll all be lumped under drm_buddy_ > completions, and some of them will be actual drm buddy functions and > some not. > > I just find it a very odd convention to name the tests in a way that's > indistinguishable from the real things. Even *within* drm_buddy_test.c > where you read the test code. Because currently you do have calls to > igt_buddy_ prefixed functions from other igt_buddy_ prefixed functions, > along with the drm_buddy_ prefixed calls. I think it's just going to be > a mess. > > /rant > > Whatever. Moving on. KUnit docs [1] state: https://docs.kernel.org/dev-tools/kunit/style.html#test-cases "As tests are themselves functions, their names cannot conflict with other C identifiers in the kernel. This may require some creative naming." And give examples of names. But this should be local to individual test suite - as long as the test is readable, and the name describes what it is testing, we should be
Re: [PATCH] kernel/panic: Drop unblank_screen call
On Thu, Sep 01, 2022 at 09:26:27PM +0200, Daniel Vetter wrote:
> On Thu, 1 Sept 2022 at 13:35, Petr Mladek wrote:
> >
> > On Tue 2022-08-30 16:50:04, Daniel Vetter wrote:
> > > console_unblank() does this too (called in both places right after),
> > > and with a lot more confidence inspiring approach to locking.
> > >
> > > Reconstructing this story is very strange:
> > >
> > > In b61312d353da ("oops handling: ensure that any oops is flushed to
> > > the mtdoops console") it is claimed that a printk(" "); flushed out
> > > the console buffer, which was removed in e3e8a75d2acf ("[PATCH]
> > > Extract and use wake_up_klogd()"). In todays kernels this is done way
> > > earlier in console_flush_on_panic with some really nasty tricks. I
> > > didn't bother to fully reconstruct this all, least because the call to
> > > bust_spinlock(0); gets moved every few years, depending upon how the
> > > wind blows (or well, who screamed loudest about the various issue each
> > > call site caused).
> > >
> > > Before that commit the only calls to console_unblank() where in s390
> > > arch code.
> > >
> > > The other side here is the console->unblank callback, which was
> > > introduced in 2.1.31 for the vt driver. Which predates the
> > > console_unblank() function by a lot, which was added (without users)
> > > in 2.4.14.3. So pretty much impossible to guess at any motivation
> > > here. Also afaict the vt driver is the only (and always was the only)
> > > console driver implementing the unblank callback, so no idea why a
> > > call to console_unblank() was added for the mtdooops driver - the
> > > action actually flushing out the console buffers is done from
> > > console_unlock() only.
> >
> > My understanding is that mtdoops is not a real console. The commit
> > 4b23aff083649eafa141 ("[MTD] oops and panic message logging to MTD
> > device") suggests that it was just (mis)using the console
> > infrastructure.
> >
> > The commit 2e386e4bac90554887e73d ("mtd: mtdoops: refactor as a
> > kmsg_dumper") converted it to use the new kmsg_dumper API that
> > was created for this use case.
> >
> > So, I would consider all the mtdoops-related changes as a misuse
> > of the console API.
>
> Ah, that's a good piece of information that I didn't figure out.
>
> Greg, if you haven't baked in the patch yet, can you perhaps add the
> above information from Petr to the commit message?
It's already baked, sorry :(
Re: [PATCH v5 11/31] drm/i915: Call acpi_video_register_backlight() (v3)
On Thu, 25 Aug 2022, Hans de Goede wrote:
> On machins without an i915 opregion the acpi_video driver immediately
> probes the ACPI video bus and used to also immediately register
> acpi_video# backlight devices when supported.
>
> Once the drm/kms driver then loaded later and possibly registered
> a native backlight device then the drivers/acpi/video_detect.c code
> unregistered the acpi_video0 device to avoid there being 2 backlight
> devices (when acpi_video_get_backlight_type()==native).
>
> This means that userspace used to briefly see 2 devices and the
> disappearing of acpi_video0 after a brief time confuses the systemd
> backlight level save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
>
> To fix this the ACPI video code has been modified to make backlight class
> device registration a separate step, relying on the drm/kms driver to
> ask for the acpi_video backlight registration after it is done setting up
> its native backlight device.
>
> Add a call to the new acpi_video_register_backlight() after the i915 calls
> acpi_video_register() (after setting up the i915 opregion) so that the
> acpi_video backlight devices get registered on systems where the i915
> native backlight device is not registered.
>
> Changes in v2:
> -Only call acpi_video_register_backlight() when a panel is detected
>
> Changes in v3:
> -Add a new intel_acpi_video_register() helper which checks if a panel
> is present and then calls acpi_video_register_backlight()
>
> Signed-off-by: Hans de Goede
Apologies for the delay. I truly appreciate the effort you've put into
this series, and I'm looking forward to seeing the next steps in drm!
Reviewed-by: Jani Nikula
And ack for merging via whichever tree you think best.
> ---
> drivers/gpu/drm/i915/display/intel_acpi.c| 27
> drivers/gpu/drm/i915/display/intel_acpi.h| 3 +++
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> 3 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index e78430001f07..9df78e7caa2b 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -7,6 +7,7 @@
>
> #include
> #include
> +#include
>
> #include "i915_drv.h"
> #include "intel_acpi.h"
> @@ -331,3 +332,29 @@ void intel_acpi_assign_connector_fwnodes(struct
> drm_i915_private *i915)
>*/
> fwnode_handle_put(fwnode);
> }
> +
> +void intel_acpi_video_register(struct drm_i915_private *i915)
> +{
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *connector;
> +
> + acpi_video_register();
> +
> + /*
> + * If i915 is driving an internal panel without registering its native
> + * backlight handler try to register the acpi_video backlight.
> + * For panels not driven by i915 another GPU driver may still register
> + * a native backlight later and acpi_video_register_backlight() should
> + * only be called after any native backlights have been registered.
> + */
> + drm_connector_list_iter_begin(>drm, _iter);
> + drm_for_each_connector_iter(connector, _iter) {
> + struct intel_panel *panel =
> _intel_connector(connector)->panel;
> +
> + if (panel->backlight.funcs && !panel->backlight.device) {
> + acpi_video_register_backlight();
> + break;
> + }
> + }
> + drm_connector_list_iter_end(_iter);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h
> b/drivers/gpu/drm/i915/display/intel_acpi.h
> index 4a760a2baed9..6a0007452f95 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.h
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.h
> @@ -14,6 +14,7 @@ void intel_unregister_dsm_handler(void);
> void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
> void intel_acpi_device_id_update(struct drm_i915_private *i915);
> void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915);
> +void intel_acpi_video_register(struct drm_i915_private *i915);
> #else
> static inline void intel_register_dsm_handler(void) { return; }
> static inline void intel_unregister_dsm_handler(void) { return; }
> @@ -23,6 +24,8 @@ static inline
> void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
> static inline
> void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915) {
> return; }
> +static inline
> +void intel_acpi_video_register(struct drm_i915_private *i915) { return; }
> #endif /* CONFIG_ACPI */
>
> #endif /* __INTEL_ACPI_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6103b02c081f..129a13375101 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -9087,7 +9087,7 @@ void
Re: [PATCH] drm/amd/display: fix memory leak when using debugfs_lookup()
On Fri, Sep 02, 2022 at 03:01:05PM +0200, Greg Kroah-Hartman wrote: > When calling debugfs_lookup() the result must have dput() called on it, > otherwise the memory will leak over time. Fix this up by properly > calling dput(). > > Cc: Harry Wentland > Cc: Leo Li > Cc: Rodrigo Siqueira > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Wayne Lin > Cc: hersen wu > Cc: Wenjing Liu > Cc: Patrik Jakobsson > Cc: Thelford Williams > Cc: Fangzhi Zuo > Cc: Yongzhi Liu > Cc: Mikita Lipski > Cc: Jiapeng Chong > Cc: Bhanuprakash Modem > Cc: Sean Paul > Cc: amd-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Greg Kroah-Hartman > --- Despite a zillion cc: items, I forgot to cc: stable on this. Can the maintainer add that here, or do you all want me to resend it with that item added? thanks, greg k-h
Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"
On Fri, 02 Sep 2022, Maxime Ripard wrote: > On Fri, Sep 02, 2022 at 11:04:14AM +0300, Jani Nikula wrote: >> On Thu, 01 Sep 2022, Maíra Canal wrote: >> > Hi Maxime, >> > >> > On 9/1/22 09:55, Maxime Ripard wrote: >> >> Hi, >> >> >> >> On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote: >> >>> With the introduction of KUnit, IGT is no longer the only option to run >> >>> the DRM unit tests, as the tests can be run through kunit-tool or on >> >>> real hardware with CONFIG_KUNIT. >> >>> >> >>> Therefore, remove the "igt_" prefix from the tests and replace it with >> >>> the "test_drm_" prefix, making the tests' names independent from the tool >> >>> used. >> >>> >> >>> Signed-off-by: Maíra Canal >> >>> >> >>> --- >> >>> v1 -> v2: >> >>> https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/ >> >>> - Change "drm_" prefix to "test_drm_", as "drm_" can be a bit confusing >> >>> (Jani Nikula). >> >> >> >> I appreciate it's a bit of a bikeshed but I disagree with this. The >> >> majority of the kunit tests already out there start with the framework >> >> name, including *all* the examples in the kunit doc. Plus, it's fairly >> >> obvious that it's a test, kunit is only about running tests in the first >> >> place. >> > >> > Would it be better to keep it as "drm_"? >> >> That's not "keeping". That's renaming igt to drm. > > Well, there's like half the tests that are prefixed with drm, the other > with igt, so it's both really > >> > Currently, I don't think it is appropriate to hold the "igt_" prefix, as >> > the tests are not IGT exclusive, but I don't have a strong opinion on >> > using the "drm_" or the "test_drm" prefixes. >> >> I repeat my stance that "drm_" alone is confusing. > > What are you confusing it with? > >> For the reason alone that it pollutes the code tagging tools, mixing >> actual drm_ types and functions with unit test functions. > > I don't get it, I'm sorry. All these functions are static and not part > of any API, so I can't see how it would pollute a code tagging tool. Or > at least, not more than any driver does. > > And we're part of a larger project here, it's about consistency with the > rest of the ecosystem. Okay, so I'm just going to explain what I mean, but say "whatever" right after and move on. For example, drm_buddy_test.c includes drm_buddy.h so with the igt_ -> drm_ rename none of the test functions may clash with the drm_buddy_ prefixed existing functions. Ditto for all tests similarly. For example drm_buddy_alloc_range() as a name sounds like something that allocs a range, not something that tests range allocation. On the other hand, you have drm_buddy_alloc_blocks() which is actually a real drm_buddy function, not a test. What would you call a test that tests that? Here, we end up with names that are all prefixed drm_buddy and you won't know what's the actual function and what's the test unless you look it up. I use code tagging that I can use for finding and completing e.g. functions. Currently I have the following completions, for igt_buddy_ and drm_buddy_, respectively: Possible completions are: igt_buddy_alloc_limit igt_buddy_alloc_optimistic igt_buddy_alloc_pathological igt_buddy_alloc_pessimistic igt_buddy_alloc_range igt_buddy_alloc_smoke Possible completions are: drm_buddy_alloc_blocks drm_buddy_block drm_buddy_block_is_allocated drm_buddy_block_is_free drm_buddy_block_is_splitdrm_buddy_block_offset drm_buddy_block_order drm_buddy_block_print drm_buddy_block_sizedrm_buddy_block_state drm_buddy_block_trim drm_buddy_fini drm_buddy_free_blockdrm_buddy_free_list drm_buddy_init drm_buddy_init_test drm_buddy_module_exit drm_buddy_module_init drm_buddy_print With the patch at hand, they'll all be lumped under drm_buddy_ completions, and some of them will be actual drm buddy functions and some not. I just find it a very odd convention to name the tests in a way that's indistinguishable from the real things. Even *within* drm_buddy_test.c where you read the test code. Because currently you do have calls to igt_buddy_ prefixed functions from other igt_buddy_ prefixed functions, along with the drm_buddy_ prefixed calls. I think it's just going to be a mess. /rant Whatever. Moving on. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[PATCH] drm/amd/display: fix memory leak when using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. Fix this up by properly
calling dput().
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Wayne Lin
Cc: hersen wu
Cc: Wenjing Liu
Cc: Patrik Jakobsson
Cc: Thelford Williams
Cc: Fangzhi Zuo
Cc: Yongzhi Liu
Cc: Mikita Lipski
Cc: Jiapeng Chong
Cc: Bhanuprakash Modem
Cc: Sean Paul
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 0e48824f55e3..ee242d9d8b06 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -3288,6 +3288,7 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
_win_y_end_fops);
debugfs_create_file_unsafe("crc_win_update", 0644, dir, crtc,
_win_update_fops);
+ dput(dir);
#endif
debugfs_create_file("amdgpu_current_bpc", 0644, crtc->debugfs_entry,
crtc, _current_bpc_fops);
--
2.37.3
Re: [Intel-gfx] [PATCH 07/11] drm/edid: Use GTF2 for inferred modes
On Fri, Sep 02, 2022 at 03:25:39PM +0300, Jani Nikula wrote:
> On Sat, 27 Aug 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > For some resaon we only use the secondary GTF curve for the
> > standard timings. Use it for inferred modes as well.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_edid.c | 35 ++-
> > 1 file changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 0c7cbe9b44f5..fed2bdd55c09 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3546,6 +3546,35 @@ static int drm_gtf_modes_for_range(struct
> > drm_connector *connector,
> > return modes;
> > }
> >
> > +static int drm_gtf2_modes_for_range(struct drm_connector *connector,
> > + const struct drm_edid *drm_edid,
> > + const struct detailed_timing *timing)
> > +{
> > + int i, modes = 0;
> > + struct drm_display_mode *newmode;
> > + struct drm_device *dev = connector->dev;
> > +
> > + for (i = 0; i < ARRAY_SIZE(extra_modes); i++) {
> > + const struct minimode *m = _modes[i];
> > +
> > + newmode = drm_gtf2_mode(dev, drm_edid, m->w, m->h, m->r);
> > + if (!newmode)
> > + return modes;
> > +
> > + drm_mode_fixup_1366x768(newmode);
> > + if (!mode_in_range(newmode, drm_edid, timing) ||
> > + !valid_inferred_mode(connector, newmode)) {
> > + drm_mode_destroy(dev, newmode);
> > + continue;
> > + }
> > +
> > + drm_mode_probed_add(connector, newmode);
> > + modes++;
> > + }
> > +
> > + return modes;
> > +}
> > +
> > static int drm_cvt_modes_for_range(struct drm_connector *connector,
> >const struct drm_edid *drm_edid,
> >const struct detailed_timing *timing)
> > @@ -3594,7 +3623,11 @@ do_inferred_modes(const struct detailed_timing
> > *timing, void *c)
> > return; /* GTF not defined yet */
> >
> > switch (range->flags) {
> > - case DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG: /* XXX could do more */
> > + case DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG:
> > + closure->modes += drm_gtf2_modes_for_range(closure->connector,
> > + closure->drm_edid,
> > + timing);
> > + break;
> > case DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG:
>
> Additionally, per spec:
>
> * Default GTF supported if bit 0 in Feature Support Byte at address 18h = 1
>
> * Secondary GTF supported --- requires support for Default GTF
>
> So I guess both of these would need the edid->features &
> DRM_EDID_FEATURE_DEFAULT_GTF check?
There is one actually
if (drm_edid->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF)
num_modes += add_inferred_modes(connector, drm_edid);
Though as I think I mentioned in some of these patches a lot of
real world EDIDs don't set the default gtf/continuous frequency
bit but still include a range descriptor. While illegal, I think
a reasonable interpretation might be that they want us to use
the formula specified in the range descriptor for the non-DMT
standard timings, while still indicating that other timings
generated by said formula are not supported.
>
> Other than that,
>
> Reviewed-by: Jani Nikula
>
>
>
> > closure->modes += drm_gtf_modes_for_range(closure->connector,
> > closure->drm_edid,
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"
On Fri, Sep 02, 2022 at 11:04:14AM +0300, Jani Nikula wrote: > On Thu, 01 Sep 2022, Maíra Canal wrote: > > Hi Maxime, > > > > On 9/1/22 09:55, Maxime Ripard wrote: > >> Hi, > >> > >> On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote: > >>> With the introduction of KUnit, IGT is no longer the only option to run > >>> the DRM unit tests, as the tests can be run through kunit-tool or on > >>> real hardware with CONFIG_KUNIT. > >>> > >>> Therefore, remove the "igt_" prefix from the tests and replace it with > >>> the "test_drm_" prefix, making the tests' names independent from the tool > >>> used. > >>> > >>> Signed-off-by: Maíra Canal > >>> > >>> --- > >>> v1 -> v2: > >>> https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/ > >>> - Change "drm_" prefix to "test_drm_", as "drm_" can be a bit confusing > >>> (Jani Nikula). > >> > >> I appreciate it's a bit of a bikeshed but I disagree with this. The > >> majority of the kunit tests already out there start with the framework > >> name, including *all* the examples in the kunit doc. Plus, it's fairly > >> obvious that it's a test, kunit is only about running tests in the first > >> place. > > > > Would it be better to keep it as "drm_"? > > That's not "keeping". That's renaming igt to drm. Well, there's like half the tests that are prefixed with drm, the other with igt, so it's both really > > Currently, I don't think it is appropriate to hold the "igt_" prefix, as > > the tests are not IGT exclusive, but I don't have a strong opinion on > > using the "drm_" or the "test_drm" prefixes. > > I repeat my stance that "drm_" alone is confusing. What are you confusing it with? > For the reason alone that it pollutes the code tagging tools, mixing > actual drm_ types and functions with unit test functions. I don't get it, I'm sorry. All these functions are static and not part of any API, so I can't see how it would pollute a code tagging tool. Or at least, not more than any driver does. And we're part of a larger project here, it's about consistency with the rest of the ecosystem. Maxime signature.asc Description: PGP signature
Re: [PATCH 10/11] drm/edid: Make version checks less convoluted
On Sat, 27 Aug 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of the confusing version_greater() stuff and
> simply compare edid->revision directly everwhere. Half
> the places already did it this way, and since we actually
> reject any EDID with edid->version!=1 it's a perfectly
> sane thing to do.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 25 -
> 1 file changed, 8 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0fe06e5fd6e0..e7f46260dfe7 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1572,15 +1572,6 @@ struct drm_edid {
> const struct edid *edid;
> };
>
> -static bool version_greater(const struct drm_edid *drm_edid,
> - u8 version, u8 revision)
> -{
> - const struct edid *edid = drm_edid->edid;
> -
> - return edid->version > version ||
> - (edid->version == version && edid->revision > revision);
> -}
> -
> static int edid_hfeeodb_extension_block_count(const struct edid *edid);
>
> static int edid_hfeeodb_block_count(const struct edid *edid)
> @@ -3652,7 +3643,7 @@ do_inferred_modes(const struct detailed_timing *timing,
> void *c)
> closure->drm_edid,
> timing);
>
> - if (!version_greater(closure->drm_edid, 1, 1))
> + if (closure->drm_edid->edid->revision < 2)
> return; /* GTF not defined yet */
>
> switch (range->flags) {
> @@ -3667,7 +3658,7 @@ do_inferred_modes(const struct detailed_timing *timing,
> void *c)
> timing);
> break;
> case DRM_EDID_CVT_SUPPORT_FLAG:
> - if (!version_greater(closure->drm_edid, 1, 3))
> + if (closure->drm_edid->edid->revision < 4)
> break;
>
> closure->modes += drm_cvt_modes_for_range(closure->connector,
> @@ -3688,7 +3679,7 @@ static int add_inferred_modes(struct drm_connector
> *connector,
> .drm_edid = drm_edid,
> };
>
> - if (version_greater(drm_edid, 1, 0))
> + if (drm_edid->edid->revision >= 1)
> drm_for_each_detailed_block(drm_edid, do_inferred_modes,
> );
>
> return closure.modes;
> @@ -3765,7 +3756,7 @@ static int add_established_modes(struct drm_connector
> *connector,
> }
> }
>
> - if (version_greater(drm_edid, 1, 0))
> + if (edid->revision >= 1)
> drm_for_each_detailed_block(drm_edid, do_established_modes,
> );
>
> @@ -3820,7 +3811,7 @@ static int add_standard_modes(struct drm_connector
> *connector,
> }
> }
>
> - if (version_greater(drm_edid, 1, 0))
> + if (drm_edid->edid->revision >= 1)
> drm_for_each_detailed_block(drm_edid, do_standard_modes,
> );
>
> @@ -3900,7 +3891,7 @@ add_cvt_modes(struct drm_connector *connector, const
> struct drm_edid *drm_edid)
> .drm_edid = drm_edid,
> };
>
> - if (version_greater(drm_edid, 1, 2))
> + if (drm_edid->edid->revision >= 3)
> drm_for_each_detailed_block(drm_edid, do_cvt_mode, );
>
> /* XXX should also look for CVT codes in VTB blocks */
> @@ -3955,7 +3946,7 @@ static int add_detailed_modes(struct drm_connector
> *connector,
> .quirks = quirks,
> };
>
> - if (version_greater(drm_edid, 1, 3))
> + if (drm_edid->edid->revision >= 4)
> closure.preferred = true; /* first detailed timing is always
> preferred */
> else
> closure.preferred =
> @@ -6144,7 +6135,7 @@ static void drm_get_vrr_range(struct drm_connector
> *connector,
> .drm_edid = drm_edid,
> };
>
> - if (!version_greater(drm_edid, 1, 3))
> + if (drm_edid->edid->revision < 4)
> return;
>
> if (!(drm_edid->edid->features & DRM_EDID_FEATURE_CONTINUOUS_FREQ))
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 09/11] drm/edid: Unconfuse preferred timing stuff a bit
On Sat, 27 Aug 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For EDID 1.4 the first detailed timing is always preferred,
> for older EDIDs there was a feature flag to indicate the same.
> While correct, the code setting that up is rather confusing.
> Restate it in a slightly more straightforward manner.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c1c85b9e1208..0fe06e5fd6e0 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3952,13 +3952,14 @@ static int add_detailed_modes(struct drm_connector
> *connector,
> struct detailed_mode_closure closure = {
> .connector = connector,
> .drm_edid = drm_edid,
> - .preferred = true,
> .quirks = quirks,
> };
>
> - if (closure.preferred && !version_greater(drm_edid, 1, 3))
> + if (version_greater(drm_edid, 1, 3))
> + closure.preferred = true; /* first detailed timing is always
> preferred */
> + else
> closure.preferred =
> - (drm_edid->edid->features &
> DRM_EDID_FEATURE_PREFERRED_TIMING);
> + drm_edid->edid->features &
> DRM_EDID_FEATURE_PREFERRED_TIMING;
>
> drm_for_each_detailed_block(drm_edid, do_detailed_mode, );
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 07/11] drm/edid: Use GTF2 for inferred modes
On Sat, 27 Aug 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For some resaon we only use the secondary GTF curve for the
> standard timings. Use it for inferred modes as well.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 35 ++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0c7cbe9b44f5..fed2bdd55c09 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3546,6 +3546,35 @@ static int drm_gtf_modes_for_range(struct
> drm_connector *connector,
> return modes;
> }
>
> +static int drm_gtf2_modes_for_range(struct drm_connector *connector,
> + const struct drm_edid *drm_edid,
> + const struct detailed_timing *timing)
> +{
> + int i, modes = 0;
> + struct drm_display_mode *newmode;
> + struct drm_device *dev = connector->dev;
> +
> + for (i = 0; i < ARRAY_SIZE(extra_modes); i++) {
> + const struct minimode *m = _modes[i];
> +
> + newmode = drm_gtf2_mode(dev, drm_edid, m->w, m->h, m->r);
> + if (!newmode)
> + return modes;
> +
> + drm_mode_fixup_1366x768(newmode);
> + if (!mode_in_range(newmode, drm_edid, timing) ||
> + !valid_inferred_mode(connector, newmode)) {
> + drm_mode_destroy(dev, newmode);
> + continue;
> + }
> +
> + drm_mode_probed_add(connector, newmode);
> + modes++;
> + }
> +
> + return modes;
> +}
> +
> static int drm_cvt_modes_for_range(struct drm_connector *connector,
> const struct drm_edid *drm_edid,
> const struct detailed_timing *timing)
> @@ -3594,7 +3623,11 @@ do_inferred_modes(const struct detailed_timing
> *timing, void *c)
> return; /* GTF not defined yet */
>
> switch (range->flags) {
> - case DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG: /* XXX could do more */
> + case DRM_EDID_SECONDARY_GTF_SUPPORT_FLAG:
> + closure->modes += drm_gtf2_modes_for_range(closure->connector,
> +closure->drm_edid,
> +timing);
> + break;
> case DRM_EDID_DEFAULT_GTF_SUPPORT_FLAG:
Additionally, per spec:
* Default GTF supported if bit 0 in Feature Support Byte at address 18h = 1
* Secondary GTF supported --- requires support for Default GTF
So I guess both of these would need the edid->features &
DRM_EDID_FEATURE_DEFAULT_GTF check?
Other than that,
Reviewed-by: Jani Nikula
> closure->modes += drm_gtf_modes_for_range(closure->connector,
> closure->drm_edid,
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v2 00/41] drm: Analog TV Improvements
Den 01.09.2022 21.35, skrev Noralf Trønnes: > > > I have finally found a workaround for my kernel hangs. > > Dom had a look at my kernel and found that the VideoCore was fine, and > he said this: > >> That suggests cause of lockup was on arm side rather than VC side. >> >> But it's hard to diagnose further. Once you've had a peripheral not >> respond, the AXI bus locks up and no further operations are possible. >> Usual causes of this are required clocks being stopped or domains >> disabled and then trying to access the hardware. >> > > So when I got this on my 64-bit build: > > [ 166.702171] SError Interrupt on CPU1, code 0xbf02 -- SError > [ 166.702187] CPU: 1 PID: 8 Comm: kworker/u8:0 Tainted: GW > 5.19.0-rc6-00096-gba7973977976-dirty #1 > [ 166.702200] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) > [ 166.702206] Workqueue: events_freezable_power_ thermal_zone_device_check > [ 166.702231] pstate: 20c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > [ 166.702242] pc : regmap_mmio_read32le+0x10/0x28 > [ 166.702261] lr : regmap_mmio_read+0x44/0x70 > ... > [ 166.702606] bcm2711_get_temp+0x58/0xb0 [bcm2711_thermal] > > I wondered if that reg read was stalled due to a clock being stopped. > > Lo and behold, disabling runtime pm and keeping the vec clock running > all the time fixed it[1]. > > I don't know what the problem is, but at least I can now test this patchset. > > [1] https://gist.github.com/notro/23b984e7fa05cfbda2db50a421cac065 > It turns out I didn't have to disable runtime pm: https://gist.github.com/notro/0adcfcb12460b54e54458afe11dc8ea2 Noralf.
Re: [PATCH v7 1/3] drm/i915/hpd: suspend MST at the end of intel_modeset_driver_remove
On Fri, Aug 26, 2022 at 04:19:27PM +0200, Andrzej Hajda wrote: > i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler > called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst. > Since dp_mst is suspended after irq handler uninstall, a cleaner approach > is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk > use-after-free. > > It should fix following WARNINGS: > [283.405824] cpu_latency_qos_update_request called for unknown object > [283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 > cpu_latency_qos_update_request+0x2d/0x100 > [283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted > 5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1 > [283.405915] Hardware name: Intel Corporation Raptor Lake Client > Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 > 09/30/2021 > [283.405916] Workqueue: i915-dp i915_digport_work_func [i915] > [283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100 > ... > [283.406040] Call Trace: > [283.406041] > [283.406044] intel_dp_aux_xfer+0x60e/0x8e0 [i915] > [283.406131] ? finish_swait+0x80/0x80 > [283.406139] intel_dp_aux_transfer+0xc5/0x2b0 [i915] > [283.406218] drm_dp_dpcd_access+0x79/0x130 [drm_display_helper] > [283.406227] drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper] > [283.406233] intel_dp_hpd_pulse+0x134/0x570 [i915] > [283.406308] ? __down_killable+0x70/0x140 > [283.406313] i915_digport_work_func+0xba/0x150 [i915] > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4586 > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5558 > Signed-off-by: Andrzej Hajda > Reviewed-by: Arun R Murthy Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i915/display/intel_display.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index a0f84cbe974fc3..524c4580ae6bc9 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -9000,6 +9000,13 @@ void intel_modeset_driver_remove(struct > drm_i915_private *i915) > > flush_work(>atomic_helper.free_work); > drm_WARN_ON(>drm, !llist_empty(>atomic_helper.free_list)); > + > + /* > + * MST topology needs to be suspended so we don't have any calls to > + * fbdev after it's finalized. MST will be destroyed later as part of > + * drm_mode_config_cleanup() > + */ > + intel_dp_mst_suspend(i915); > } > > /* part #2: call after irq uninstall */ > @@ -9014,13 +9021,6 @@ void intel_modeset_driver_remove_noirq(struct > drm_i915_private *i915) >*/ > intel_hpd_poll_fini(i915); > > - /* > - * MST topology needs to be suspended so we don't have any calls to > - * fbdev after it's finalized. MST will be destroyed later as part of > - * drm_mode_config_cleanup() > - */ > - intel_dp_mst_suspend(i915); > - > /* poll work can call into fbdev, hence clean that up afterwards */ > intel_fbdev_fini(i915); > > -- > 2.25.1 >
Re: [v1] drm/msm/disp/dpu1: add support for hierarchical flush for dspp in sc7280
On Fri, 2 Sept 2022 at 12:35, Kalyan Thota wrote:
>
>
>
> >-Original Message-
> >From: Dmitry Baryshkov
> >Sent: Friday, August 26, 2022 5:02 PM
> >To: Kalyan Thota ; Kalyan Thota (QUIC)
> >; diand...@chromium.org
> >Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
> >freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
> >ker...@vger.kernel.org; robdcl...@gmail.com; swb...@chromium.org; Vinod
> >Polimera (QUIC) ; Abhinav Kumar (QUIC)
> >
> >Subject: Re: [v1] drm/msm/disp/dpu1: add support for hierarchical flush for
> >dspp
> >in sc7280
Ugh. I'd kindly ask to fix your email client to behave like a normal one.
> @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
> ops->setup_blendstage = dpu_hw_ctl_setup_blendstage;
> ops->get_bitmask_sspp = dpu_hw_ctl_get_bitmask_sspp;
> ops->get_bitmask_mixer = dpu_hw_ctl_get_bitmask_mixer;
> - ops->get_bitmask_dspp = dpu_hw_ctl_get_bitmask_dspp;
> + if (cap & BIT(DPU_CTL_HIERARCHICAL_FLUSH)) {
> + ops->get_bitmask_dspp =
> + dpu_hw_ctl_get_bitmask_dspp_v1;
> >>>
> >>> We have used _v1 for active CTLs. What is the relationship between
> >>> CTL_HIERARCHILCAL_FLUSH and active CTLs?
> >> Active CTL design replaces legacy CTL_MEM_SEL, CTL_OUT_SEL registers
> >> in grouping the resources such as WB, INTF, pingpong, DSC etc into the
> >> data path DSPP hierarchical flush will gives us a finer control on which
> >> post
> >processing blocks to be flushed as part of the composition ( like IGC, PCC,
> >GC ..
> >etc ) These blocks are contained in DSPP package.
> >
> >So, I assume that hierarchical DSPP flush does not exist on non-active CTL
> >SoCs.
> >Which supported SoCs do support the hierarchichal DSPP flush?
> >
> Dspp Sub-block flush is supported from the DPU 7-series, the only target in
> the catalogue is sc7280.
Ack, thanks.
--
With best wishes
Dmitry
Re: [v2] drm/msm/disp/dpu1: add support for dspp sub block flush in sc7280
On Fri, 2 Sept 2022 at 12:38, Kalyan Thota wrote:
>
> Flush mechanism for DSPP blocks has changed in sc7280 family, it
> allows individual sub blocks to be flushed in coordination with
> master flush control.
>
> Representation: master_flush && (PCC_flush | IGC_flush .. etc )
>
> This change adds necessary support for the above design.
>
> Changes in v1:
> - Few nits (Doug, Dmitry)
> - Restrict sub-block flush programming to dpu_hw_ctl file (Dmitry)
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 +++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 35
> +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 ++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h| 7 ++
> 6 files changed, 56 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 601d687..ab38a52 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -766,7 +766,7 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc
> *crtc)
>
> /* stage config flush mask */
> ctl->ops.update_pending_flush_dspp(ctl,
> - mixer[i].hw_dspp->idx);
> + mixer[i].hw_dspp->idx, DPU_DSPP_SUB_PCC);
> }
> }
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index 27f029f..0eecb2f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -65,7 +65,10 @@
> (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
>
> #define CTL_SC7280_MASK \
> - (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
> BIT(DPU_CTL_VM_CFG))
> + (BIT(DPU_CTL_ACTIVE_CFG) | \
> +BIT(DPU_CTL_FETCH_ACTIVE) | \
> +BIT(DPU_CTL_VM_CFG) | \
> +BIT(DPU_CTL_DSPP_SUB_BLOCK_FLUSH))
>
> #define MERGE_3D_SM8150_MASK (0)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index 38aa38a..6a0b784 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -191,6 +191,7 @@ enum {
> * @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
> * @DPU_CTL_FETCH_ACTIVE: Active CTL for fetch HW (SSPPs)
> * @DPU_CTL_VM_CFG:CTL config to support multiple VMs
> + * @DPU_CTL_DSPP_BLOCK_FLUSH: CTL config to support dspp sub-block flush
> * @DPU_CTL_MAX
> */
> enum {
> @@ -198,6 +199,7 @@ enum {
> DPU_CTL_ACTIVE_CFG,
> DPU_CTL_FETCH_ACTIVE,
> DPU_CTL_VM_CFG,
> + DPU_CTL_DSPP_SUB_BLOCK_FLUSH,
> DPU_CTL_MAX
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index a35ecb6..3b14c30 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -33,6 +33,7 @@
> #define CTL_INTF_FLUSH0x110
> #define CTL_INTF_MASTER 0x134
> #define CTL_FETCH_PIPE_ACTIVE 0x0FC
> +#define CTL_DSPP_n_FLUSH 0x13C
CTL_DSPP_n_FLUSH(n)
>
> #define CTL_MIXER_BORDER_OUTBIT(24)
> #define CTL_FLUSH_MASK_CTL BIT(17)
> @@ -82,6 +83,31 @@ static int _mixer_stages(const struct dpu_lm_cfg *mixer,
> int count,
> return stages;
> }
>
> +static u32 _set_dspp_sub_block_flush(struct dpu_hw_ctl *ctx,
> + enum dpu_dspp dspp, enum dpu_dspp_sub_blk dspp_sub_blk)
> +{
> + uint32_t flushbits = 0, active;
> +
> + switch (dspp_sub_blk) {
> + case DPU_DSPP_SUB_IGC:
> + flushbits = BIT(2);
> + break;
> + case DPU_DSPP_SUB_PCC:
> + flushbits = BIT(4);
> + break;
> + case DPU_DSPP_SUB_GC:
> + flushbits = BIT(5);
> + break;
> + default:
> + return 0;
> + }
> +
> + active = DPU_REG_READ(>hw, CTL_DSPP_n_FLUSH + ((dspp - 1) * 4));
> + DPU_REG_WRITE(>hw, CTL_DSPP_n_FLUSH + ((dspp - 1) * 4), active |
> flushbits);
> +
> + return BIT(29);
> +}
> +
> static inline u32 dpu_hw_ctl_get_flush_register(struct dpu_hw_ctl *ctx)
> {
> struct dpu_hw_blk_reg_map *c = >hw;
> @@ -287,8 +313,15 @@ static void
> dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct dpu_hw_ctl *ctx,
> }
>
> static void dpu_hw_ctl_update_pending_flush_dspp(struct dpu_hw_ctl *ctx,
> - enum dpu_dspp dspp)
> + enum dpu_dspp dspp, enum dpu_dspp_sub_blk dspp_sub_blk)
> {
> +
> + if ((test_bit(DPU_CTL_DSPP_SUB_BLOCK_FLUSH, >caps->features))) {
> + ctx->pending_flush_mask |=
> + _set_dspp_sub_block_flush(ctx, dspp,
RE: [Intel-gfx] [PATCH v2 4/4] drm/tests: Set also mock plane src_x, src_y, src_w and src_h
> -Original Message-
> From: Intel-gfx On Behalf Of Jouni
> Högander
> Sent: Tuesday, August 23, 2022 2:29 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 4/4] drm/tests: Set also mock plane src_x,
> src_y,
> src_w and src_h
>
> We need to set also src_x, src_y, src_w and src_h for the mock plane.
> After fix for drm_atomic_helper_damage_iter_init we are using these when
> iterating damage_clips.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/tests/drm_damage_helper_test.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/tests/drm_damage_helper_test.c
> b/drivers/gpu/drm/tests/drm_damage_helper_test.c
> index bf250bd08d7e..c608ae06f0e3 100644
> --- a/drivers/gpu/drm/tests/drm_damage_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_damage_helper_test.c
> @@ -59,6 +59,11 @@ static int drm_damage_helper_init(struct kunit *test)
> static void set_plane_src(struct drm_plane_state *state, int x1, int y1, int
> x2,
> int y2)
> {
> + state->src_x = x1;
> + state->src_y = y1;
> + state->src_w = x2 - x1;
> + state->src_h = y2 - y1;
> +
> state->src.x1 = x1;
> state->src.y1 = y1;
> state->src.x2 = x2;
> --
> 2.34.1
RE: [Intel-gfx] [PATCH v2 3/4] drm/i915/display: Use drm helper instead of own loop for damage clips
> -Original Message-
> From: Intel-gfx On Behalf Of Jouni
> Högander
> Sent: Tuesday, August 23, 2022 2:29 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 3/4] drm/i915/display: Use drm helper instead
> of
> own loop for damage clips
>
> Use existing drm_atomic_helper_damage_merged from generic drm code
> instead of implementing own loop to iterate over damage_clips.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 17 +
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 16985de24019..0ce8076be000 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1721,8 +1721,6 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
>new_plane_state, i) {
> struct drm_rect src, damaged_area = { .x1 = 0, .y1 = -1,
> .x2 = INT_MAX };
> - struct drm_atomic_helper_damage_iter iter;
> - struct drm_rect clip;
>
> if (new_plane_state->uapi.crtc != crtc_state->uapi.crtc)
> continue;
> @@ -1770,20 +1768,15 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
> src = drm_plane_state_src(_plane_state->uapi);
> drm_rect_fp_to_int(, );
>
> - drm_atomic_helper_damage_iter_init(,
> -_plane_state->uapi,
> -_plane_state->uapi);
> - drm_atomic_for_each_plane_damage(, ) {
> - if (drm_rect_intersect(, ))
> - clip_area_update(_area, ,
> - _state->pipe_src);
> - }
> -
> - if (damaged_area.y1 == -1)
> + if (!drm_atomic_helper_damage_merged(_plane_state-
> >uapi,
> + _plane_state->uapi,
> _area))
> continue;
>
> damaged_area.y1 += new_plane_state->uapi.dst.y1 - src.y1;
> damaged_area.y2 += new_plane_state->uapi.dst.y1 - src.y1;
> + damaged_area.x1 += new_plane_state->uapi.dst.x1 - src.x1;
> + damaged_area.x2 += new_plane_state->uapi.dst.x1 - src.x1;
> +
> clip_area_update(_clip, _area, _state-
> >pipe_src);
> }
>
> --
> 2.34.1
RE: [Intel-gfx] [PATCH v2 2/4] drm/i915/display: Use original src in psr2 sel fetch area calculation
> -Original Message- > From: Intel-gfx On Behalf Of Jouni > Högander > Sent: Tuesday, August 23, 2022 2:29 PM > To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 2/4] drm/i915/display: Use original src in > psr2 sel > fetch area calculation > > drm_plane_state->src is modified when offset is calculated: > > before calculation: > src.x1 = 8192, src.y1 = 8192 > > after calculation (pitch = 65536, cpp = 4, alignment = 262144) > src.x1 = 8192, src.y1 = 0, offset = 0x2000 > > Damage clips are relative to original coodrdinates provided by user-space. To > compare these against src coordinates we need to use original coordinates as > provided by user-space. These can be obtained by using drm_plane_state_src. > Reviewed-by: Mika Kahola > Signed-off-by: Jouni Högander > --- > drivers/gpu/drm/i915/display/intel_psr.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > b/drivers/gpu/drm/i915/display/intel_psr.c > index 98c3c8015a5c..16985de24019 100644 > --- a/drivers/gpu/drm/i915/display/intel_psr.c > +++ b/drivers/gpu/drm/i915/display/intel_psr.c > @@ -1767,7 +1767,8 @@ int intel_psr2_sel_fetch_update(struct > intel_atomic_state *state, > continue; > } > > - drm_rect_fp_to_int(, _plane_state->uapi.src); > + src = drm_plane_state_src(_plane_state->uapi); > + drm_rect_fp_to_int(, ); > > drm_atomic_helper_damage_iter_init(, > _plane_state->uapi, > -- > 2.34.1
RE: [PATCH v2 1/4] drm: Use original src rect while initializing damage iterator
> -Original Message-
> From: dri-devel On Behalf Of Jouni
> Högander
> Sent: Tuesday, August 23, 2022 2:29 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Hogander, Jouni
> Subject: [PATCH v2 1/4] drm: Use original src rect while initializing damage
> iterator
>
> drm_plane_state->src might be modified by the driver. This is done e.g. in
> i915
> driver when there is bigger framebuffer than the plane and there is some
> offset
> within framebuffer. I915 driver calculates separate offset and adjusts src
> rect
> coords to be relative to this offset. Damage clips are still relative to
> original src
> coords provided by user-space.
>
> This patch ensures original coordinates provided by user-space are used when
> initiliazing damage iterator.
>
Looks ok.
Reviewed-by: Mika Kahola
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/drm_damage_helper.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_damage_helper.c
> b/drivers/gpu/drm/drm_damage_helper.c
> index 937b699ac2a8..d8b2955e88fd 100644
> --- a/drivers/gpu/drm/drm_damage_helper.c
> +++ b/drivers/gpu/drm/drm_damage_helper.c
> @@ -224,6 +224,7 @@ drm_atomic_helper_damage_iter_init(struct
> drm_atomic_helper_damage_iter *iter,
> const struct drm_plane_state *old_state,
> const struct drm_plane_state *state) {
> + struct drm_rect src;
> memset(iter, 0, sizeof(*iter));
>
> if (!state || !state->crtc || !state->fb || !state->visible) @@ -233,10
> +234,12 @@ drm_atomic_helper_damage_iter_init(struct
> drm_atomic_helper_damage_iter *iter,
> iter->num_clips = drm_plane_get_damage_clips_count(state);
>
> /* Round down for x1/y1 and round up for x2/y2 to catch all pixels */
> - iter->plane_src.x1 = state->src.x1 >> 16;
> - iter->plane_src.y1 = state->src.y1 >> 16;
> - iter->plane_src.x2 = (state->src.x2 >> 16) + !!(state->src.x2 & 0x);
> - iter->plane_src.y2 = (state->src.y2 >> 16) + !!(state->src.y2 & 0x);
> + src = drm_plane_state_src(state);
> +
> + iter->plane_src.x1 = src.x1 >> 16;
> + iter->plane_src.y1 = src.y1 >> 16;
> + iter->plane_src.x2 = (src.x2 >> 16) + !!(src.x2 & 0x);
> + iter->plane_src.y2 = (src.y2 >> 16) + !!(src.y2 & 0x);
>
> if (!iter->clips || !drm_rect_equals(>src, _state->src)) {
> iter->clips = NULL;
> --
> 2.34.1
Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver
On 29.08.2022 20:40, Jagan Teki wrote: > Samsung MIPI DSIM controller is common DSI IP that can be used in various > SoCs like Exynos, i.MX8M Mini/Nano. > > In order to access this DSI controller between various platform SoCs, > the ideal way to incorporate this in the drm stack is via the drm bridge > driver. > > This patch is trying to differentiate platform-specific and bridge driver > code and keep maintaining the exynos_drm_dsi.c code as platform-specific > glue code and samsung-dsim.c as a common bridge driver code. > > - Exynos specific glue code is exynos specific te_irq, host_attach, and >detach code along with conventional component_ops. > > - Samsung DSIM is a bridge driver which is common across all platforms and >the respective platform-specific glue will initialize at the end of the >probe. The platform-specific operations and other glue calls will invoke >on associate code areas. > > v4: > * include Inki Dae in MAINTAINERS > * remove dsi_driver probe in exynos_drm_drv to support multi-arch build This breaks Exynos DRM completely as the Exynos DRM driver is not able to wait until the DSI driver is probed and registered as component. I will show how to rework this the way it is done in drivers/gpu/drm/exynos/exynos_dp.c and drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon... > v3: > * restore gpio related fixes > * restore proper bridge chain > * rework initialization issue > * fix header includes in proper way > > v2: > * fixed exynos dsi driver conversion (Marek Szyprowski) > * updated commit message > * updated MAINTAINERS file > > v1: > * don't maintain component_ops in bridge driver > * don't maintain platform glue code in bridge driver > * add platform-specific glue code and make a common bridge > > Signed-off-by: Marek Szyprowski > Signed-off-by: Jagan Teki > --- > MAINTAINERS |9 + > drivers/gpu/drm/bridge/Kconfig | 12 + > drivers/gpu/drm/bridge/Makefile |1 + > drivers/gpu/drm/bridge/samsung-dsim.c | 1686 ++ > drivers/gpu/drm/exynos/Kconfig |1 + > drivers/gpu/drm/exynos/exynos_drm_drv.c |3 - > drivers/gpu/drm/exynos/exynos_drm_drv.h |1 - > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1715 +-- > include/drm/bridge/samsung-dsim.h | 99 ++ > 9 files changed, 1868 insertions(+), 1659 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c > create mode 100644 include/drm/bridge/samsung-dsim.h > > ... Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
02.09.2022 13:31, Dmitry Osipenko пишет: > 01.09.2022 17:02, Ruhl, Michael J пишет: > ... >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >>> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct >>> drm_i915_private *i915, >>> continue; >>> } >>> >>> + /* >>> +* dma_buf_unmap_attachment() requires reservation to be >>> +* locked. The imported GEM shouldn't share reservation lock, >>> +* so it's safe to take the lock. >>> +*/ >>> + if (obj->base.import_attach) >>> + i915_gem_object_lock(obj, NULL); >> >> There is a lot of stuff going here. Taking the lock may be premature... >> >>> __i915_gem_object_pages_fini(obj); >> >> The i915_gem_dmabuf.c:i915_gem_object_put_pages_dmabuf is where >> unmap_attachment is actually called, would it make more sense to make >> do the locking there? > > The __i915_gem_object_put_pages() is invoked with a held reservation > lock, while freeing object is a special time when we know that GEM is > unused. > > The __i915_gem_free_objects() was taking the lock two weeks ago until > the change made Chris Wilson [1] reached linux-next. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=2826d447fbd60e6a05e53d5f918bceb8c04e315c > > I don't think we can take the lock within > i915_gem_object_put_pages_dmabuf(), it may/should deadlock other code paths. On the other hand, we can check whether the GEM's refcount number is zero in i915_gem_object_put_pages_dmabuf() and then take the lock if it's zero. Also, seems it should be possible just to bail out from i915_gem_object_put_pages_dmabuf() if refcount=0. The further drm_prime_gem_destroy() will take care of unmapping. Perhaps this could be the best option, I'll give it a test.
Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
01.09.2022 17:02, Ruhl, Michael J пишет: ... >> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct >> drm_i915_private *i915, >> continue; >> } >> >> +/* >> + * dma_buf_unmap_attachment() requires reservation to be >> + * locked. The imported GEM shouldn't share reservation lock, >> + * so it's safe to take the lock. >> + */ >> +if (obj->base.import_attach) >> +i915_gem_object_lock(obj, NULL); > > There is a lot of stuff going here. Taking the lock may be premature... > >> __i915_gem_object_pages_fini(obj); > > The i915_gem_dmabuf.c:i915_gem_object_put_pages_dmabuf is where > unmap_attachment is actually called, would it make more sense to make > do the locking there? The __i915_gem_object_put_pages() is invoked with a held reservation lock, while freeing object is a special time when we know that GEM is unused. The __i915_gem_free_objects() was taking the lock two weeks ago until the change made Chris Wilson [1] reached linux-next. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=2826d447fbd60e6a05e53d5f918bceb8c04e315c I don't think we can take the lock within i915_gem_object_put_pages_dmabuf(), it may/should deadlock other code paths.
[v2] drm/msm/disp/dpu1: add support for dspp sub block flush in sc7280
Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
Representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Changes in v1:
- Few nits (Doug, Dmitry)
- Restrict sub-block flush programming to dpu_hw_ctl file (Dmitry)
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 35 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h| 7 ++
6 files changed, 56 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 601d687..ab38a52 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -766,7 +766,7 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc *crtc)
/* stage config flush mask */
ctl->ops.update_pending_flush_dspp(ctl,
- mixer[i].hw_dspp->idx);
+ mixer[i].hw_dspp->idx, DPU_DSPP_SUB_PCC);
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 27f029f..0eecb2f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -65,7 +65,10 @@
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
#define CTL_SC7280_MASK \
- (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG))
+ (BIT(DPU_CTL_ACTIVE_CFG) | \
+BIT(DPU_CTL_FETCH_ACTIVE) | \
+BIT(DPU_CTL_VM_CFG) | \
+BIT(DPU_CTL_DSPP_SUB_BLOCK_FLUSH))
#define MERGE_3D_SM8150_MASK (0)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 38aa38a..6a0b784 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -191,6 +191,7 @@ enum {
* @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
* @DPU_CTL_FETCH_ACTIVE: Active CTL for fetch HW (SSPPs)
* @DPU_CTL_VM_CFG:CTL config to support multiple VMs
+ * @DPU_CTL_DSPP_BLOCK_FLUSH: CTL config to support dspp sub-block flush
* @DPU_CTL_MAX
*/
enum {
@@ -198,6 +199,7 @@ enum {
DPU_CTL_ACTIVE_CFG,
DPU_CTL_FETCH_ACTIVE,
DPU_CTL_VM_CFG,
+ DPU_CTL_DSPP_SUB_BLOCK_FLUSH,
DPU_CTL_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index a35ecb6..3b14c30 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -33,6 +33,7 @@
#define CTL_INTF_FLUSH0x110
#define CTL_INTF_MASTER 0x134
#define CTL_FETCH_PIPE_ACTIVE 0x0FC
+#define CTL_DSPP_n_FLUSH 0x13C
#define CTL_MIXER_BORDER_OUTBIT(24)
#define CTL_FLUSH_MASK_CTL BIT(17)
@@ -82,6 +83,31 @@ static int _mixer_stages(const struct dpu_lm_cfg *mixer, int
count,
return stages;
}
+static u32 _set_dspp_sub_block_flush(struct dpu_hw_ctl *ctx,
+ enum dpu_dspp dspp, enum dpu_dspp_sub_blk dspp_sub_blk)
+{
+ uint32_t flushbits = 0, active;
+
+ switch (dspp_sub_blk) {
+ case DPU_DSPP_SUB_IGC:
+ flushbits = BIT(2);
+ break;
+ case DPU_DSPP_SUB_PCC:
+ flushbits = BIT(4);
+ break;
+ case DPU_DSPP_SUB_GC:
+ flushbits = BIT(5);
+ break;
+ default:
+ return 0;
+ }
+
+ active = DPU_REG_READ(>hw, CTL_DSPP_n_FLUSH + ((dspp - 1) * 4));
+ DPU_REG_WRITE(>hw, CTL_DSPP_n_FLUSH + ((dspp - 1) * 4), active |
flushbits);
+
+ return BIT(29);
+}
+
static inline u32 dpu_hw_ctl_get_flush_register(struct dpu_hw_ctl *ctx)
{
struct dpu_hw_blk_reg_map *c = >hw;
@@ -287,8 +313,15 @@ static void
dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct dpu_hw_ctl *ctx,
}
static void dpu_hw_ctl_update_pending_flush_dspp(struct dpu_hw_ctl *ctx,
- enum dpu_dspp dspp)
+ enum dpu_dspp dspp, enum dpu_dspp_sub_blk dspp_sub_blk)
{
+
+ if ((test_bit(DPU_CTL_DSPP_SUB_BLOCK_FLUSH, >caps->features))) {
+ ctx->pending_flush_mask |=
+ _set_dspp_sub_block_flush(ctx, dspp, dspp_sub_blk);
+ return;
+ }
+
switch (dspp) {
case DSPP_0:
ctx->pending_flush_mask |= BIT(13);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index 96c012e..227f1bd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++
RE: [v1] drm/msm/disp/dpu1: add support for hierarchical flush for dspp in sc7280
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Friday, August 26, 2022 5:02 PM
>To: Kalyan Thota ; Kalyan Thota (QUIC)
>; diand...@chromium.org
>Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
>ker...@vger.kernel.org; robdcl...@gmail.com; swb...@chromium.org; Vinod
>Polimera (QUIC) ; Abhinav Kumar (QUIC)
>
>Subject: Re: [v1] drm/msm/disp/dpu1: add support for hierarchical flush for
>dspp
>in sc7280
>
>WARNING: This email originated from outside of Qualcomm. Please be wary of
>any links or attachments, and do not enable macros.
>
>On 08/08/2022 13:44, Kalyan Thota wrote:
>>
>>
>>> -Original Message-
>>> From: Dmitry Baryshkov
>>> Sent: Thursday, August 4, 2022 9:29 PM
>>> To: Kalyan Thota (QUIC)
>>> Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>>> freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
>>> ker...@vger.kernel.org; robdcl...@gmail.com; diand...@chromium.org;
>>> swb...@chromium.org; Vinod Polimera (QUIC)
>>> ; Abhinav Kumar (QUIC)
>>>
>>> Subject: Re: [v1] drm/msm/disp/dpu1: add support for hierarchical
>>> flush for dspp in sc7280
>>>
>>> WARNING: This email originated from outside of Qualcomm. Please be
>>> wary of any links or attachments, and do not enable macros.
>>>
>>> On Thu, 4 Aug 2022 at 13:29, Kalyan Thota
>wrote:
Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Signed-off-by: Kalyan Thota
>>>
>>> I'd like to land at least patches 6-8 from [1] next cycle. They clean
>>> up the CTL interface. Could you please rebase your patch on top of them?
>>>
>>
>> Sure I'll wait for the series to rebase. @Doug can you comment if this is
>> okay
>and this patch is not needed immediately ?
>
>The respective patches have been picked up for 6.1 and were pushed to
>https://gitlab.freedesktop.org/lumag/msm.git msm-next-lumag . Could you
>please rebase your patch on top of them?
>
>All other comments also needs addressing.
>
>>
>>> [1] https://patchwork.freedesktop.org/series/99909/
>>>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 40
>>> +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 3 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h| 7 +
6 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 7763558..4eca317 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -703,6 +703,10 @@ static void _dpu_crtc_setup_cp_blocks(struct
>>> drm_crtc *crtc)
mixer[i].flush_mask |= ctl->ops.get_bitmask_dspp(ctl,
mixer[i].hw_dspp->idx);
+ if(ctl->ops.set_dspp_hierarchical_flush)
+ ctl->ops.set_dspp_hierarchical_flush(ctl,
+
+ mixer[i].hw_dspp->idx, DSPP_SUB_PCC);
+
/* stage config flush mask */
ctl->ops.update_pending_flush(ctl,
mixer[i].flush_mask);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 021eb2f..3b27a87 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -58,7 +58,10 @@
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
#define CTL_SC7280_MASK \
- (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
>>> BIT(DPU_CTL_VM_CFG))
+ (BIT(DPU_CTL_ACTIVE_CFG) | \
+BIT(DPU_CTL_FETCH_ACTIVE) | \
+BIT(DPU_CTL_VM_CFG) | \
+BIT(DPU_CTL_HIERARCHICAL_FLUSH))
#define MERGE_3D_SM8150_MASK (0)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index b85b24b..7922f6c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -185,6 +185,7 @@ enum {
* @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
* @DPU_CTL_FETCH_ACTIVE: Active CTL for fetch HW (SSPPs)
* @DPU_CTL_VM_CFG:CTL config to support multiple VMs
+ * @DPU_CTL_HIERARCHICAL_FLUSH: CTL config to support hierarchical
+ flush
* @DPU_CTL_MAX
*/
enum {
Re: [PATCH v4 11/21] misc: fastrpc: Prepare to dynamic dma-buf locking specification
On 31/08/2022 16:37, Dmitry Osipenko wrote:
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
LGTM,
Incase you plan to take it via another tree.
Acked-by: Srinivas Kandagatla
--srini
drivers/misc/fastrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 93ebd174d848..6fcfb2e9f7a7 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -310,8 +310,8 @@ static void fastrpc_free_map(struct kref *ref)
return;
}
}
- dma_buf_unmap_attachment(map->attach, map->table,
-DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(map->attach, map->table,
+ DMA_BIDIRECTIONAL);
dma_buf_detach(map->buf, map->attach);
dma_buf_put(map->buf);
}
@@ -726,7 +726,7 @@ static int fastrpc_map_create(struct fastrpc_user *fl, int
fd,
goto attach_err;
}
- map->table = dma_buf_map_attachment(map->attach, DMA_BIDIRECTIONAL);
+ map->table = dma_buf_map_attachment_unlocked(map->attach,
DMA_BIDIRECTIONAL);
if (IS_ERR(map->table)) {
err = PTR_ERR(map->table);
goto map_err;
Re: [PATCH v4 11/21] misc: fastrpc: Prepare to dynamic dma-buf locking specification
On 31/08/2022 16:37, Dmitry Osipenko wrote:
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
LGTM,
Incase you plan to take it via another tree.
Acked-by: Srinivas Kandagatla
--srini
drivers/misc/fastrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 93ebd174d848..6fcfb2e9f7a7 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -310,8 +310,8 @@ static void fastrpc_free_map(struct kref *ref)
return;
}
}
- dma_buf_unmap_attachment(map->attach, map->table,
-DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(map->attach, map->table,
+ DMA_BIDIRECTIONAL);
dma_buf_detach(map->buf, map->attach);
dma_buf_put(map->buf);
}
@@ -726,7 +726,7 @@ static int fastrpc_map_create(struct fastrpc_user *fl, int
fd,
goto attach_err;
}
- map->table = dma_buf_map_attachment(map->attach, DMA_BIDIRECTIONAL);
+ map->table = dma_buf_map_attachment_unlocked(map->attach,
DMA_BIDIRECTIONAL);
if (IS_ERR(map->table)) {
err = PTR_ERR(map->table);
goto map_err;
[PATCH linux-next] drm/i915: Remove the unneeded result variables
From: zhang songyi
Return the mul_u32_fixed16() and div_fixed16() directly instead of
redundant variables.
Reported-by: Zeal Robot
Signed-off-by: zhang songyi
---
drivers/gpu/drm/i915/intel_pm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 210c1f78cc90..a6757ed9081a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5272,7 +5272,6 @@ skl_wm_method2(u32 pixel_rate, u32 pipe_htotal, u32
latency,
uint_fixed_16_16_t plane_blocks_per_line)
{
u32 wm_intermediate_val;
- uint_fixed_16_16_t ret;
if (latency == 0)
return FP_16_16_MAX;
@@ -5280,8 +5279,8 @@ skl_wm_method2(u32 pixel_rate, u32 pipe_htotal, u32
latency,
wm_intermediate_val = latency * pixel_rate;
wm_intermediate_val = DIV_ROUND_UP(wm_intermediate_val,
pipe_htotal * 1000);
- ret = mul_u32_fixed16(wm_intermediate_val, plane_blocks_per_line);
- return ret;
+
+ return mul_u32_fixed16(wm_intermediate_val, plane_blocks_per_line);
}
static uint_fixed_16_16_t
@@ -5290,7 +5289,6 @@ intel_get_linetime_us(const struct intel_crtc_state
*crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
u32 pixel_rate;
u32 crtc_htotal;
- uint_fixed_16_16_t linetime_us;
if (!crtc_state->hw.active)
return u32_to_fixed16(0);
@@ -5301,9 +5299,8 @@ intel_get_linetime_us(const struct intel_crtc_state
*crtc_state)
return u32_to_fixed16(0);
crtc_htotal = crtc_state->hw.pipe_mode.crtc_htotal;
- linetime_us = div_fixed16(crtc_htotal * 1000, pixel_rate);
- return linetime_us;
+ return div_fixed16(crtc_htotal * 1000, pixel_rate);
}
static int
--
2.25.1
Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"
On Fri, 02 Sep 2022, Maxime Ripard wrote: > On Thu, Sep 01, 2022 at 07:33:18PM -0300, Maíra Canal wrote: >> Hi Maxime, >> >> On 9/1/22 09:55, Maxime Ripard wrote: >> > Hi, >> > >> > On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote: >> >> With the introduction of KUnit, IGT is no longer the only option to run >> >> the DRM unit tests, as the tests can be run through kunit-tool or on >> >> real hardware with CONFIG_KUNIT. >> >> >> >> Therefore, remove the "igt_" prefix from the tests and replace it with >> >> the "test_drm_" prefix, making the tests' names independent from the tool >> >> used. >> >> >> >> Signed-off-by: Maíra Canal >> >> >> >> --- >> >> v1 -> v2: >> >> https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/ >> >> - Change "drm_" prefix to "test_drm_", as "drm_" can be a bit confusing >> >> (Jani Nikula). >> > >> > I appreciate it's a bit of a bikeshed but I disagree with this. The >> > majority of the kunit tests already out there start with the framework >> > name, including *all* the examples in the kunit doc. Plus, it's fairly >> > obvious that it's a test, kunit is only about running tests in the first >> > place. >> >> Would it be better to keep it as "drm_"? >> >> Currently, I don't think it is appropriate to hold the "igt_" prefix, as >> the tests are not IGT exclusive, but I don't have a strong opinion on >> using the "drm_" or the "test_drm" prefixes. > > Yes, using drm as our prefix everywhere seems like a good idea :) Disagreed for reasons explained in other mails. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH linux-next] drm/dp_helper: Remove the unneeded result variable
On Fri, 02 Sep 2022, cgel@gmail.com wrote:
> From: zhang songyi
>
> Return the drm_dp_dpcd_writeb() directly instead of storing it in another
> redundant variable.
Please just *stop* sending changes like this. See for example [1].
What's most offending to me is that I've replied to a lot of patches
from you, but I've *never* *even* *once* received a reply back on my
reviews.
If you want to participate in creating a better kernel, then please
*participate*. Just throwing random cleanup patches in our general
direction with one-way communication is not helping.
I'm seriously considering just ignoring *all* patches from you.
BR,
Jani.
[1] https://lore.kernel.org/r/8735dcepcv@intel.com
>
> Reported-by: Zeal Robot
> Signed-off-by: zhang songyi
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 92990a3d577a..09b282b704fa 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2925,16 +2925,13 @@ EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
> */
> int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool
> enable_frl_ready_hpd)
> {
> - int ret;
> u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
>DP_PCON_ENABLE_LINK_FRL_MODE;
>
> if (enable_frl_ready_hpd)
> buf |= DP_PCON_ENABLE_HPD_READY;
>
> - ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
> -
> - return ret;
> + return drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
> }
> EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH linux-next] drm/dp_helper: Remove the unneeded result variable
From: zhang songyi
Return the drm_dp_dpcd_writeb() directly instead of storing it in another
redundant variable.
Reported-by: Zeal Robot
Signed-off-by: zhang songyi
---
drivers/gpu/drm/display/drm_dp_helper.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 92990a3d577a..09b282b704fa 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2925,16 +2925,13 @@ EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
*/
int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
{
- int ret;
u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
DP_PCON_ENABLE_LINK_FRL_MODE;
if (enable_frl_ready_hpd)
buf |= DP_PCON_ENABLE_HPD_READY;
- ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
-
- return ret;
+ return drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
}
EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
--
2.25.1
Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"
On Thu, Sep 01, 2022 at 07:33:18PM -0300, Maíra Canal wrote: > Hi Maxime, > > On 9/1/22 09:55, Maxime Ripard wrote: > > Hi, > > > > On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote: > >> With the introduction of KUnit, IGT is no longer the only option to run > >> the DRM unit tests, as the tests can be run through kunit-tool or on > >> real hardware with CONFIG_KUNIT. > >> > >> Therefore, remove the "igt_" prefix from the tests and replace it with > >> the "test_drm_" prefix, making the tests' names independent from the tool > >> used. > >> > >> Signed-off-by: Maíra Canal > >> > >> --- > >> v1 -> v2: > >> https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/ > >> - Change "drm_" prefix to "test_drm_", as "drm_" can be a bit confusing > >> (Jani Nikula). > > > > I appreciate it's a bit of a bikeshed but I disagree with this. The > > majority of the kunit tests already out there start with the framework > > name, including *all* the examples in the kunit doc. Plus, it's fairly > > obvious that it's a test, kunit is only about running tests in the first > > place. > > Would it be better to keep it as "drm_"? > > Currently, I don't think it is appropriate to hold the "igt_" prefix, as > the tests are not IGT exclusive, but I don't have a strong opinion on > using the "drm_" or the "test_drm" prefixes. Yes, using drm as our prefix everywhere seems like a good idea :) Maxime signature.asc Description: PGP signature
Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"
On Thu, 01 Sep 2022, Maíra Canal wrote: > Hi Maxime, > > On 9/1/22 09:55, Maxime Ripard wrote: >> Hi, >> >> On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote: >>> With the introduction of KUnit, IGT is no longer the only option to run >>> the DRM unit tests, as the tests can be run through kunit-tool or on >>> real hardware with CONFIG_KUNIT. >>> >>> Therefore, remove the "igt_" prefix from the tests and replace it with >>> the "test_drm_" prefix, making the tests' names independent from the tool >>> used. >>> >>> Signed-off-by: Maíra Canal >>> >>> --- >>> v1 -> v2: >>> https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/ >>> - Change "drm_" prefix to "test_drm_", as "drm_" can be a bit confusing >>> (Jani Nikula). >> >> I appreciate it's a bit of a bikeshed but I disagree with this. The >> majority of the kunit tests already out there start with the framework >> name, including *all* the examples in the kunit doc. Plus, it's fairly >> obvious that it's a test, kunit is only about running tests in the first >> place. > > Would it be better to keep it as "drm_"? That's not "keeping". That's renaming igt to drm. > Currently, I don't think it is appropriate to hold the "igt_" prefix, as > the tests are not IGT exclusive, but I don't have a strong opinion on > using the "drm_" or the "test_drm" prefixes. I repeat my stance that "drm_" alone is confusing. For the reason alone that it pollutes the code tagging tools, mixing actual drm_ types and functions with unit test functions. BR, Jani. > > Best Regards, > - Maíra Canal > >> >> Maxime >> -- Jani Nikula, Intel Open Source Graphics Center
[PATCH linux-next] drm/amdgpu: Remove the unneeded result variable
From: zhang songyi
Return the sdma_v6_0_start() directly instead of storing it in another
redundant variable.
Reported-by: Zeal Robot
Signed-off-by: zhang songyi
---
drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c
index 2bc1407e885e..2cc2d851b4eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c
@@ -1373,12 +1373,9 @@ static int sdma_v6_0_sw_fini(void *handle)
static int sdma_v6_0_hw_init(void *handle)
{
- int r;
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- r = sdma_v6_0_start(adev);
-
- return r;
+ return sdma_v6_0_start(adev);
}
static int sdma_v6_0_hw_fini(void *handle)
--
2.25.1
[PATCH linux-next] drm/amd/display: Remove the unneeded result variable
From: zhang songyi
Return the enable_link_dp() directly instead of storing it in another
redundant variable.
Reported-by: Zeal Robot
Signed-off-by: zhang songyi
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index f9b798b7933c..4ab27e231337 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2077,11 +2077,7 @@ static enum dc_status enable_link_edp(
struct dc_state *state,
struct pipe_ctx *pipe_ctx)
{
- enum dc_status status;
-
- status = enable_link_dp(state, pipe_ctx);
-
- return status;
+ return enable_link_dp(state, pipe_ctx);
}
static enum dc_status enable_link_dp_mst(
--
2.25.1
Re: [PATCH v17 07/10] drm/mediatek: dp: Determine device of next_bridge
Hi, Bo-Chen: On Thu, 2022-09-01 at 12:41 +0800, Bo-Chen Chen wrote: > It's not necessary to have a next_bridge for DP device, so we add > this > patch to judge this. Reviewed-by: CK Hu > > Signed-off-by: Bo-Chen Chen > --- > drivers/gpu/drm/mediatek/mtk_dp.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c > b/drivers/gpu/drm/mediatek/mtk_dp.c > index 136e13150281..e37c9185e4ec 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dp.c > +++ b/drivers/gpu/drm/mediatek/mtk_dp.c > @@ -1886,7 +1886,10 @@ static int mtk_dp_probe(struct platform_device > *pdev) >"failed to request dp irq > resource\n"); > > mtk_dp->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, > 1, 0); > - if (IS_ERR(mtk_dp->next_bridge)) > + if (IS_ERR(mtk_dp->next_bridge) && > + PTR_ERR(mtk_dp->next_bridge) == -ENODEV) > + mtk_dp->next_bridge = NULL; > + else if (IS_ERR(mtk_dp->next_bridge)) > return dev_err_probe(dev, PTR_ERR(mtk_dp->next_bridge), >"Failed to get bridge\n"); >
Re: [PATCH v2 09/41] drm/connector: Add TV standard property
Hi Mateusz,
On Fri, Sep 2, 2022 at 12:00 AM Mateusz Kwiatkowski wrote:
> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze:
> > The TV mode property has been around for a while now to select and get the
> > current TV mode output on an analog TV connector.
> >
> > Despite that property name being generic, its content isn't and has been
> > driver-specific which makes it hard to build any generic behaviour on top
> > of it, both in kernel and user-space.
> >
> > Let's create a new bitmask tv norm property, that can contain any of the
> > analog TV standards currently supported by kernel drivers. Each driver can
> > then pass in a bitmask of the modes it supports.
>
> This is not a bitmask property anymore, you've just changed it to an enum.
> The commit message is now misleading.
>
> > +static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = {
> > +{ DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" },
> > +{ DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
> > +{ DRM_MODE_TV_MODE_NTSC_M, "NTSC-M" },
> > +{ DRM_MODE_TV_MODE_PAL_60, "PAL-60" },
> > +{ DRM_MODE_TV_MODE_PAL_B, "PAL-B" },
> > +{ DRM_MODE_TV_MODE_PAL_D, "PAL-D" },
> > +{ DRM_MODE_TV_MODE_PAL_G, "PAL-G" },
> > +{ DRM_MODE_TV_MODE_PAL_H, "PAL-H" },
> > +{ DRM_MODE_TV_MODE_PAL_I, "PAL-I" },
> > +{ DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
> > +{ DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
> > +{ DRM_MODE_TV_MODE_PAL_NC, "PAL-Nc" },
> > +{ DRM_MODE_TV_MODE_SECAM_60, "SECAM-60" },
> > +{ DRM_MODE_TV_MODE_SECAM_B, "SECAM-B" },
> > +{ DRM_MODE_TV_MODE_SECAM_D, "SECAM-D" },
> > +{ DRM_MODE_TV_MODE_SECAM_G, "SECAM-G" },
> > +{ DRM_MODE_TV_MODE_SECAM_K, "SECAM-K" },
> > +{ DRM_MODE_TV_MODE_SECAM_K1, "SECAM-K1" },
> > +{ DRM_MODE_TV_MODE_SECAM_L, "SECAM-L" },
> > +};
>
> I did not comment on it the last time, but this list looks a little bit
> random.
>
> Compared to the standards defined by V4L2, you also define SECAM-60 (a good
> thing to define, because why not), but don't define PAL-B1, PAL-D1, PAL-K,
> SECAM-H, SECAM-LC (whatever that is - probably just another name for SECAM-L,
> see my comment about PAL-Nc below), or NTSC-M-KR (a Korean variant of NTSC).
>
> Like I mentioned previously, I'm personally not a fan of including all those
> CCIR/ITU system variants, as they don't mean any difference to the output
> unless
> there is an RF modulator involved. But I get it that they have already been
> used
> and regressing probably wouldn't be a very good idea. But in that case keeping
> it consistent with the set of values used by V4L2 would be wise, I think.
Exactly. Anything outputting RGB (e.g. through a SCART or VGA connector)
doesn't care about the color subcarrier or modulator parts. Likewise,
anything outputting CVBS doesn't care about the modulator part.
Perhaps "generic" variants of NSTC and PAL/SECAM should be added, which
would really just mean 525/60 resp. 625/50.
Alternatively, the tv_mode field could be split in two parts (either
two separate fields, or bitwise), to maintain a clear separation between
lines/fields versus color encoding and RF modulation (with zero for the
latter meaning a generic version)? That would also keep the door open
for TV_MODE_405_50, TV_MODE_819_50, TV_MODE_750_50, TV_MODE_750_60, ...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 1/9] dt-bindings: usb: Add Type-C switch binding
Hi Rob,
On Jul 12 11:45, Rob Herring wrote:
>
> That's not the right interpretation. There should not be some Type-C
> specific child mux/switch node because the device has no such h/w within
> it. Assuming all the possibilities Stephen outlined are valid, it's
> clear this lane selection has nothing to do with Type-C. It does have an
> output port for its DP output already and using that to describe the
> connection to DP connector(s) and/or Type-C connector(s) should be
> handled.
> Rob
Below I've listed the proposal binding (for the Type-C connector) along
with 2 sample hardware diagrams and corresponding DT.
The updated binding in usb-c-connector would be as follows:
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml
b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index ae515651fc6b..a043b09cb8ec 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -183,6 +183,30 @@ properties:
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: Super Speed (SS), present in SS capable connectors.
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ "^endpoint@[0-1]$":
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ description:
+ Endpoints for the two SS lanes. endpoint@0 refers to SSTRX1
(A2,A3,B10,B11)
+ and endpoint@1 refers to SSTRX2 (B2,B3,A10,A11).
+ additionalProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+
+ remote-endpoint: true
+
+ required:
+ - reg
+ - remote-endpoint
port@2:
$ref: /schemas/graph.yaml#/properties/port
Here are 2 examples of how that would look on some existing hardware:
Example 1. 2 usb-c-connectors connecting to 1 drm bridge / DP switch:
Here is the diagram we are using on the MTK platform:
SOC
+-+ C0
| |+--+ 2 lane
++
| || +-/-+
SSTRX1 |
| || | |
|
|MIPI DPI || | 2 lane |
|
| ++ ANX 7625 +---/-+++
SSTRX2 |
| || | ||
++
| |+--+ ||
+-+ ||
| |+--+ 2 lane || C1
| || +/C+
++
|USB3 HC | 2 lane | | | |
SSTRX1 |
| +-/--+ USB3 HUB | +-+
|
| (host controller) || | 2 lane |
|
| || +-/-+
SSTRX2 |
+-+| | |
|
+--+
++
Some platforms use it6505, so that can be swapped in for anx7625
without any change to the rest of the hardware diagram.
>From the above, we can see that it is helpful to describe the
Type-C SS lines as 2 endpoints:
- 1 for SSTX1+SSRX1 (A2,A3 + B10,B11)
- 1 for SSTX2+SSRX2 (B2,B3 + A10, A11)
A device tree for this would look as follows:
// Type-C port driver
ec {
...
cros_ec_typec {
...
usb-c0 {
compatible = "usb-c-connector";
ports {
hs : port@0 {
...
};
ss: port@1 {
reg = <1>;
c0_sstrx1: endpoint@0 {
reg = <0>;
remote-endpoint = <_out0>;
};
c0_sstrx2: endpoint@0 {
reg = <0>;
remote-endpoint = <_out0>;
};
};
sbu : port@2 {
...
};
};
};
usb-c1 {
compatible = "usb-c-connector";
ports {
hs : port@0 {
...
};
ss: port@1 {
reg = <1>;
c1_sstrx1: endpoint@0 {
reg = <0>;
remote-endpoint = <_out1>;
};
[PATCH linux-next] drm/radeon: Remove the unneeded result variable
From: ye xingchen
Return the value radeon_drm_ioctl() directly instead of storing it in
another redundant variable.
Reported-by: Zeal Robot
Signed-off-by: ye xingchen
---
drivers/gpu/drm/radeon/radeon_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index a28d5ceab628..6cbe1ab81aba 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -512,14 +512,11 @@ long radeon_drm_ioctl(struct file *filp,
static long radeon_kms_compat_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
{
unsigned int nr = DRM_IOCTL_NR(cmd);
- int ret;
if (nr < DRM_COMMAND_BASE)
return drm_compat_ioctl(filp, cmd, arg);
- ret = radeon_drm_ioctl(filp, cmd, arg);
-
- return ret;
+ return radeon_drm_ioctl(filp, cmd, arg);
}
#endif
--
2.25.1
[PATCH linux-next] drm/radeon/ci_dpm: Remove the unneeded result variable
From: ye xingchen
Return the value ci_load_smc_ucode() directly instead of storing it in
another redundant variable.
Reported-by: Zeal Robot
Signed-off-by: ye xingchen
---
drivers/gpu/drm/radeon/ci_dpm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index ac006bed4743..8ef25ab305ae 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -2056,7 +2056,7 @@ static void ci_clear_vc(struct radeon_device *rdev)
static int ci_upload_firmware(struct radeon_device *rdev)
{
struct ci_power_info *pi = ci_get_pi(rdev);
- int i, ret;
+ int i;
for (i = 0; i < rdev->usec_timeout; i++) {
if (RREG32_SMC(RCU_UC_EVENTS) & BOOT_SEQ_DONE)
@@ -2067,9 +2067,7 @@ static int ci_upload_firmware(struct radeon_device *rdev)
ci_stop_smc_clock(rdev);
ci_reset_smc(rdev);
- ret = ci_load_smc_ucode(rdev, pi->sram_end);
-
- return ret;
+ return ci_load_smc_ucode(rdev, pi->sram_end);
}
--
2.25.1
Re: [RESEND PATCH libdrm v3 2/2] tests/modetest: Add support for writeback connector
On 2 September 2022 02:09:24 GMT+03:00, Jessica Zhang
wrote:
>From: Rohith Iyer
>
>Add writeback support to modetest with the below options:
>
>- Passing in -c will now also show the writeback connector
>
>- Test a built-in mode on writeback connector
>
>- Test a custom mode from user input on writeback connector
> Usage: "./modetest -M msm -x :
>-a -P @:+0+0@RG24."
> Refer to --help for exact syntax
>
>- Dump the writeback output buffer to bitstream
> Usage: "./modetest -M msm -s :
> -a -o
> -P @:+0+0@RG24"
>
>This currently supports a singular writeback connector.
>
>Changes made in V2:
>- Added helper method that checks if user pipe has writeback connector
>- Added error message for dump flag if no writeback connector is found
>- Polls on the writeback fence fd until writeback is complete
>
>Changes made in V3:
>- Resolved compiler warnings
>- Defined ETIME to ETIMEDOUT in cases where ETIME is undefined
>
>Co-developed-by: Rohith Iyer
>Signed-off-by: Jessica Zhang
>---
> tests/modetest/buffers.c | 19
> tests/modetest/buffers.h | 1 +
> tests/modetest/modetest.c | 183 ++
> 3 files changed, 184 insertions(+), 19 deletions(-)
>
>diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
>index 8a8d9e01..279d7b28 100644
>--- a/tests/modetest/buffers.c
>+++ b/tests/modetest/buffers.c
>@@ -353,3 +353,22 @@ void bo_destroy(struct bo *bo)
>
> free(bo);
> }
>+
>+void bo_dump(struct bo *bo, const char *filename)
>+{
>+ FILE *fp;
>+
>+ if (!bo || !filename)
>+ return;
>+
>+ fp = fopen(filename, "wb");
>+ if (fp) {
>+ void *addr;
>+
>+ bo_map(bo, );
>+ printf("Dumping buffer %p to file %s.\n", bo->ptr, filename);
>+ fwrite(bo->ptr, 1, bo->size, fp);
>+ bo_unmap(bo);
>+ fclose(fp);
Any chance of using libpng, libungif or at the very least implementing minimal
ppm or bmp support here? Dumping to the image file would help a lot.
>+ }
>+}
>diff --git a/tests/modetest/buffers.h b/tests/modetest/buffers.h
>index 7f95396b..cbd54e9e 100644
>--- a/tests/modetest/buffers.h
>+++ b/tests/modetest/buffers.h
>@@ -36,5 +36,6 @@ struct bo *bo_create(int fd, unsigned int format,
> unsigned int handles[4], unsigned int pitches[4],
> unsigned int offsets[4], enum util_fill_pattern pattern);
> void bo_destroy(struct bo *bo);
>+void bo_dump(struct bo *bo, const char *filename);
>
> #endif
>diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
>index 2c31c4fc..8073d143 100644
>--- a/tests/modetest/modetest.c
>+++ b/tests/modetest/modetest.c
>@@ -68,8 +68,13 @@
> #include "buffers.h"
> #include "cursor.h"
>
>+#ifndef ETIME
>+#define ETIME ETIMEDOUT
>+#endif
ETIME is on its way to obsolescence. Please use ETIMEDOUT. See
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html
>+
> static enum util_fill_pattern primary_fill = UTIL_PATTERN_SMPTE;
> static enum util_fill_pattern secondary_fill = UTIL_PATTERN_TILES;
>+static enum util_fill_pattern plain_fill = UTIL_PATTERN_PLAIN;
>
> struct crtc {
> drmModeCrtc *crtc;
>@@ -128,6 +133,7 @@ struct device {
>
> int use_atomic;
> drmModeAtomicReq *req;
>+ int32_t writeback_fence_fd;
> };
>
> static inline int64_t U642I64(uint64_t val)
>@@ -135,6 +141,11 @@ static inline int64_t U642I64(uint64_t val)
> return (int64_t)*((int64_t *));
> }
>
>+static inline uint64_t to_user_pointer(const void *ptr)
>+{
>+ return (uintptr_t)ptr;
>+}
>+
> static float mode_vrefresh(drmModeModeInfo *mode)
> {
> return mode->clock * 1000.00
>@@ -811,6 +822,10 @@ struct pipe_arg {
> struct crtc *crtc;
> unsigned int fb_id[2], current_fb_id;
> struct timeval start;
>+ unsigned int out_fb_id;
>+ struct bo *out_bo;
>+ bool custom;
>+ bool dump;
>
> int swap_count;
> };
>@@ -917,27 +932,43 @@ static struct crtc *pipe_find_crtc(struct device *dev,
>struct pipe_arg *pipe)
> return >resources->crtcs[crtc_idx - 1];
> }
>
>+static int parse_mode_string(char *mode_string, drmModeModeInfo *user_mode)
>+{
>+ return sscanf(mode_string,
>"%u,%hu,%hu,%hu,%hu,%hu,%hu,%hu,%hu,%hu,%hu,%u,%s",
>+ _mode->clock, _mode->hdisplay,
>_mode->hsync_start,
>+ _mode->hsync_end, _mode->htotal,
>_mode->hskew,
>+ _mode->vdisplay, _mode->vsync_start,
>_mode->vsync_end,
>+ _mode->vtotal, _mode->vscan,
>_mode->vrefresh,
>+ user_mode->name);
>+}
>+
> static int pipe_find_crtc_and_mode(struct device *dev, struct pipe_arg *pipe)
I'd instead rename this to pipe_find_crtc_and_builtin_mode to limit the indent
level to remain sane.
Then define new function supporting builtin and custom modes.
> {
> drmModeModeInfo *mode = NULL;
> int i;
>+ static
Re: [RESEND PATCH libdrm v3 1/2] tests/modetest: Allocate drmModeAtomicReq before setting properties
On 2 September 2022 02:09:23 GMT+03:00, Jessica Zhang
wrote:
>From: Rohith Iyer
>
>Fix null pointer deference caused by drmModeAtomicReq being
>allocated before set_property was called when modetest was run
>with the atomic flag.
... being allocated _after_ ...
Other than that:
Reviewed-by: Dmitry Baryshkov
>
>Reviewed-by: Rob Clark
>Signed-off-by: Rohith Iyer
>Signed-off-by: Jessica Zhang
>---
> tests/modetest/modetest.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
>index 42e2d1f4..2c31c4fc 100644
>--- a/tests/modetest/modetest.c
>+++ b/tests/modetest/modetest.c
>@@ -2186,11 +2186,13 @@ int main(int argc, char **argv)
> dump_resource(, planes);
> dump_resource(, framebuffers);
>
>+ if (dev.use_atomic)
>+ dev.req = drmModeAtomicAlloc();
>+
> for (i = 0; i < prop_count; ++i)
> set_property(, _args[i]);
>
> if (dev.use_atomic) {
>- dev.req = drmModeAtomicAlloc();
>
> if (set_preferred || (count && plane_count)) {
> uint64_t cap = 0;
--
With best wishes
Dmitry
Re: [PATCH v1 3/4] drm/msm/mdp4: move resource allocation to the _probe function
On 2 September 2022 03:24:17 GMT+03:00, Abhinav Kumar
wrote:
>
>
>On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:
>> To let the probe function bail early if any of the resources is
>> unavailable, move resource allocattion from kms_init directly to the
>> probe callback. While we are at it, replace irq_of_parse_and_map() with
>> platform_get_irq().
>>
>> Signed-off-by: Dmitry Baryshkov
>> ---
>> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 107 +++
>> 1 file changed, 51 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
>> b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
>> index 41dc60784847..6499713eccf6 100644
>> --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
>> +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
>> @@ -139,8 +139,6 @@ static void mdp4_destroy(struct msm_kms *kms)
>> pm_runtime_disable(dev);
>> mdp_kms_destroy(_kms->base);
>> -
>> -kfree(mdp4_kms);
>> }
>> static const struct mdp_kms_funcs kms_funcs = {
>> @@ -383,57 +381,27 @@ static int mdp4_kms_init(struct drm_device *dev)
>> {
>> struct platform_device *pdev = to_platform_device(dev->dev);
>> struct msm_drm_private *priv = dev->dev_private;
>> -struct mdp4_kms *mdp4_kms;
>> +struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(priv->kms));
>> struct msm_kms *kms = NULL;
>> struct iommu_domain *iommu;
>> struct msm_gem_address_space *aspace;
>> -int irq, ret;
>> +int ret;
>> u32 major, minor;
>> unsigned long max_clk;
>> /* TODO: Chips that aren't apq8064 have a 200 Mhz max_clk */
>> max_clk = 27000;
>> - mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
>> -if (!mdp4_kms) {
>> -DRM_DEV_ERROR(dev->dev, "failed to allocate kms\n");
>> -return -ENOMEM;
>> -}
>> -
>> ret = mdp_kms_init(_kms->base, _funcs);
>> if (ret) {
>> DRM_DEV_ERROR(dev->dev, "failed to init kms\n");
>> goto fail;
>> }
>> - priv->kms = _kms->base.base;
>> kms = priv->kms;
>> mdp4_kms->dev = dev;
>> - mdp4_kms->mmio = msm_ioremap(pdev, NULL);
>> -if (IS_ERR(mdp4_kms->mmio)) {
>> -ret = PTR_ERR(mdp4_kms->mmio);
>> -goto fail;
>> -}
>> -
>> -irq = platform_get_irq(pdev, 0);
>> -if (irq < 0) {
>> -ret = irq;
>> -DRM_DEV_ERROR(dev->dev, "failed to get irq: %d\n", ret);
>> -goto fail;
>> -}
>> -
>> -kms->irq = irq;
>> -
>> -/* NOTE: driver for this regulator still missing upstream.. use
>> - * _get_exclusive() and ignore the error if it does not exist
>> - * (and hope that the bootloader left it on for us)
>> - */
>> -mdp4_kms->vdd = devm_regulator_get_exclusive(>dev, "vdd");
>> -if (IS_ERR(mdp4_kms->vdd))
>> -mdp4_kms->vdd = NULL;
>> -
>> if (mdp4_kms->vdd) {
>> ret = regulator_enable(mdp4_kms->vdd);
>> if (ret) {
>> @@ -442,24 +410,6 @@ static int mdp4_kms_init(struct drm_device *dev)
>> }
>> }
>> - mdp4_kms->clk = devm_clk_get(>dev, "core_clk");
>> -if (IS_ERR(mdp4_kms->clk)) {
>> -DRM_DEV_ERROR(dev->dev, "failed to get core_clk\n");
>> -ret = PTR_ERR(mdp4_kms->clk);
>> -goto fail;
>> -}
>> -
>> -mdp4_kms->pclk = devm_clk_get(>dev, "iface_clk");
>> -if (IS_ERR(mdp4_kms->pclk))
>> -mdp4_kms->pclk = NULL;
>> -
>> -mdp4_kms->axi_clk = devm_clk_get(>dev, "bus_clk");
>> -if (IS_ERR(mdp4_kms->axi_clk)) {
>> -DRM_DEV_ERROR(dev->dev, "failed to get axi_clk\n");
>> -ret = PTR_ERR(mdp4_kms->axi_clk);
>> -goto fail;
>> -}
>> -
>> clk_set_rate(mdp4_kms->clk, max_clk);
>> read_mdp_hw_revision(mdp4_kms, , );
>> @@ -474,10 +424,9 @@ static int mdp4_kms_init(struct drm_device *dev)
>> mdp4_kms->rev = minor;
>> if (mdp4_kms->rev >= 2) {
>> -mdp4_kms->lut_clk = devm_clk_get(>dev, "lut_clk");
>> -if (IS_ERR(mdp4_kms->lut_clk)) {
>> +if (!mdp4_kms->lut_clk) {
>> DRM_DEV_ERROR(dev->dev, "failed to get lut_clk\n");
>> -ret = PTR_ERR(mdp4_kms->lut_clk);
>> +ret = -ENODEV;
>> goto fail;
>> }
>> clk_set_rate(mdp4_kms->lut_clk, max_clk);
>> @@ -560,7 +509,53 @@ static const struct dev_pm_ops mdp4_pm_ops = {
>> static int mdp4_probe(struct platform_device *pdev)
>> {
>> -return msm_drv_probe(>dev, mdp4_kms_init, NULL);
>> +struct device *dev = >dev;
>> +struct mdp4_kms *mdp4_kms;
>> +int irq;
>> +
>> +mdp4_kms = devm_kzalloc(dev, sizeof(*mdp4_kms), GFP_KERNEL);
>> +if (!mdp4_kms)
>> +return dev_err_probe(dev, -ENOMEM, "failed to allocate kms\n");
>> +
>> +mdp4_kms->mmio = msm_ioremap(pdev, NULL);
>> +if (IS_ERR(mdp4_kms->mmio))
>> +return
[PATCH v4 11/11] drm/i915/mtl: Do not update GV point, mask value
Display 14 and future platforms do not directly communicate to Pcode
via mailbox the SAGV bandwidth information. PM Demand registers are
used to communicate display power requirements to the PUnit which would
include GV point and mask value.
Skip programming GV point and mask values through legacy pcode mailbox
interface.
Bspec: 64636
Cc: Matt Roper
Original Author: Caz Yokoyama
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b19a1ecb010e..69efd613bbde 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3923,6 +3923,14 @@ void intel_sagv_pre_plane_update(struct
intel_atomic_state *state)
{
struct drm_i915_private *i915 = to_i915(state->base.dev);
+ /*
+* No need to update mask value/restrict because
+* "Pcode only wants to use GV bandwidth value, not the mask value."
+* for DISPLAY_VER() >= 14.
+*/
+ if (DISPLAY_VER(i915) >= 14)
+ return;
+
/*
* Just return if we can't control SAGV or don't have it.
* This is different from situation when we have SAGV but just can't
@@ -3943,6 +3951,16 @@ void intel_sagv_post_plane_update(struct
intel_atomic_state *state)
{
struct drm_i915_private *i915 = to_i915(state->base.dev);
+ /*
+* No need to update mask value/restrict because
+* "Pcode only wants to use GV bandwidth value, not the mask value."
+* for DISPLAY_VER() >= 14.
+*
+* GV bandwidth will be set by intel_pmdemand_post_plane_update()
+*/
+ if (DISPLAY_VER(i915) >= 14)
+ return;
+
/*
* Just return if we can't control SAGV or don't have it.
* This is different from situation when we have SAGV but just can't
--
2.34.1
[PATCH v4 06/11] drm/i915/mtl: Add display power wells
From: Imre Deak
Add support for display power wells on MTL. The differences from XE_LPD:
- The AUX HW block is moved to the PICA block, where the registers are on
an always-on power well and the functionality needs to be powered on/off
via the AUX_CH_CTL register: [1], [2]
- The DDI IO power on/off programming sequence is moved to the PHY PLL
enable/disable sequence. [3], [4], [5]
Bspec: [1] 49233, [2] 65247, [3] 64568, [4] 65451, [5] 65450
v2:
- Update the comment in aux power well enable
- Reuse the noop sync fn for aux sync.
- Use REG_BIT for new register bit definitions
Signed-off-by: Imre Deak
Signed-off-by: Radhakrishna Sripada
---
.../i915/display/intel_display_power_map.c| 115 +-
.../i915/display/intel_display_power_well.c | 44 +++
.../i915/display/intel_display_power_well.h | 4 +
drivers/gpu/drm/i915/display/intel_dp_aux.c | 8 ++
drivers/gpu/drm/i915/i915_reg.h | 21
5 files changed, 191 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 5ddd1b93751c..dc04afc6cc8f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1350,6 +1350,117 @@ static const struct i915_power_well_desc_list
xelpd_power_wells[] = {
I915_PW_DESCRIPTORS(xelpd_power_wells_main),
};
+/*
+ * MTL is based on XELPD power domains with the exception of power gating for:
+ * - DDI_IO (moved to PLL logic)
+ * - AUX and AUX_IO functionality and register access for USBC1-4 (PICA
always-on)
+ */
+#define XELPDP_PW_2_POWER_DOMAINS \
+ XELPD_PW_B_POWER_DOMAINS, \
+ XELPD_PW_C_POWER_DOMAINS, \
+ XELPD_PW_D_POWER_DOMAINS, \
+ POWER_DOMAIN_AUDIO_PLAYBACK, \
+ POWER_DOMAIN_VGA, \
+ POWER_DOMAIN_PORT_DDI_LANES_TC1, \
+ POWER_DOMAIN_PORT_DDI_LANES_TC2, \
+ POWER_DOMAIN_PORT_DDI_LANES_TC3, \
+ POWER_DOMAIN_PORT_DDI_LANES_TC4
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_pw_2,
+ XELPDP_PW_2_POWER_DOMAINS,
+ POWER_DOMAIN_INIT);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_dc_off,
+ XELPDP_PW_2_POWER_DOMAINS,
+ POWER_DOMAIN_AUDIO_MMIO,
+ POWER_DOMAIN_MODESET,
+ POWER_DOMAIN_AUX_A,
+ POWER_DOMAIN_AUX_B,
+ POWER_DOMAIN_INIT);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc1,
+ POWER_DOMAIN_AUX_USBC1,
+ POWER_DOMAIN_AUX_TBT1);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc2,
+ POWER_DOMAIN_AUX_USBC2,
+ POWER_DOMAIN_AUX_TBT2);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc3,
+ POWER_DOMAIN_AUX_USBC3,
+ POWER_DOMAIN_AUX_TBT3);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc4,
+ POWER_DOMAIN_AUX_USBC4,
+ POWER_DOMAIN_AUX_TBT4);
+
+static const struct i915_power_well_desc xelpdp_power_wells_main[] = {
+ {
+ .instances = _PW_INSTANCES(
+ I915_PW("DC_off", _pwdoms_dc_off,
+ .id = SKL_DISP_DC_OFF),
+ ),
+ .ops = _dc_off_power_well_ops,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("PW_2", _pwdoms_pw_2,
+ .hsw.idx = ICL_PW_CTL_IDX_PW_2,
+ .id = SKL_DISP_PW_2),
+ ),
+ .ops = _power_well_ops,
+ .has_vga = true,
+ .has_fuses = true,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("PW_A", _pwdoms_pw_a,
+ .hsw.idx = XELPD_PW_CTL_IDX_PW_A),
+ ),
+ .ops = _power_well_ops,
+ .irq_pipe_mask = BIT(PIPE_A),
+ .has_fuses = true,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("PW_B", _pwdoms_pw_b,
+ .hsw.idx = XELPD_PW_CTL_IDX_PW_B),
+ ),
+ .ops = _power_well_ops,
+ .irq_pipe_mask = BIT(PIPE_B),
+ .has_fuses = true,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("PW_C", _pwdoms_pw_c,
+ .hsw.idx = XELPD_PW_CTL_IDX_PW_C),
+ ),
+ .ops = _power_well_ops,
+ .irq_pipe_mask = BIT(PIPE_C),
+ .has_fuses = true,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("PW_D", _pwdoms_pw_d,
+ .hsw.idx = XELPD_PW_CTL_IDX_PW_D),
+ ),
+ .ops = _power_well_ops,
+ .irq_pipe_mask = BIT(PIPE_D),
+ .has_fuses = true,
+ }, {
+ .instances = _PW_INSTANCES(
+ I915_PW("AUX_A", _pwdoms_aux_a, .xelpdp.aux_ch =
AUX_CH_A),
+ I915_PW("AUX_B", _pwdoms_aux_b, .xelpdp.aux_ch =
AUX_CH_B),
+
[PATCH v4 10/11] drm/i915/mtl: Update CHICKEN_TRANS* register addresses
From: Madhumitha Tolakanahalli Pradeep
In Display version 14, Transcoder Chicken Registers have updated address.
This patch performs checks to use the right register when required.
v2: Omit display version check in i915_reg.h(Jani)
Bspec: 34387, 50054
Cc: Jani Nikula
Signed-off-by: Madhumitha Tolakanahalli Pradeep
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_display.c | 14 ---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +++-
drivers/gpu/drm/i915/display/intel_psr.c | 6 +++--
drivers/gpu/drm/i915/i915_reg.h | 25 +++-
4 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index be7cff722196..a3d0d12084a9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -618,7 +618,10 @@ void intel_disable_transcoder(const struct
intel_crtc_state *old_crtc_state)
if (!IS_I830(dev_priv))
val &= ~PIPECONF_ENABLE;
- if (DISPLAY_VER(dev_priv) >= 12)
+ if (DISPLAY_VER(dev_priv) >= 14)
+ intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(cpu_transcoder),
+FECSTALL_DIS_DPTSTREAM_DPTTG, 0);
+ else if (DISPLAY_VER(dev_priv) >= 12)
intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder),
FECSTALL_DIS_DPTSTREAM_DPTTG, 0);
@@ -1838,7 +1841,9 @@ static void hsw_set_frame_start_delay(const struct
intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- i915_reg_t reg = CHICKEN_TRANS(crtc_state->cpu_transcoder);
+ enum transcoder transcoder = crtc_state->cpu_transcoder;
+ i915_reg_t reg = DISPLAY_VER(dev_priv) >= 14 ?
MTL_CHICKEN_TRANS(transcoder) :
+CHICKEN_TRANS(transcoder);
u32 val;
val = intel_de_read(dev_priv, reg);
@@ -4033,6 +4038,7 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_display_power_domain_set power_domain_set = { };
+ i915_reg_t reg;
bool active;
u32 tmp;
@@ -4124,7 +4130,9 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
}
if (!transcoder_is_dsi(pipe_config->cpu_transcoder)) {
- tmp = intel_de_read(dev_priv,
CHICKEN_TRANS(pipe_config->cpu_transcoder));
+ reg = DISPLAY_VER(dev_priv) >= 14 ?
MTL_CHICKEN_TRANS(pipe_config->cpu_transcoder) :
+ CHICKEN_TRANS(pipe_config->cpu_transcoder);
+ tmp = intel_de_read(dev_priv, reg);
pipe_config->framestart_delay =
REG_FIELD_GET(HSW_FRAME_START_DELAY_MASK, tmp) + 1;
} else {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 13abe2b2170e..298004cae5a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -568,7 +568,10 @@ static void intel_mst_enable_dp(struct intel_atomic_state
*state,
drm_dp_add_payload_part2(_dp->mst_mgr, >base,
drm_atomic_get_mst_payload_state(mst_state,
connector->port));
- if (DISPLAY_VER(dev_priv) >= 12 && pipe_config->fec_enable)
+ if (DISPLAY_VER(dev_priv) >= 14 && pipe_config->fec_enable)
+ intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(trans), 0,
+FECSTALL_DIS_DPTSTREAM_DPTTG);
+ else if (DISPLAY_VER(dev_priv) >= 12 && pipe_config->fec_enable)
intel_de_rmw(dev_priv, CHICKEN_TRANS(trans), 0,
FECSTALL_DIS_DPTSTREAM_DPTTG);
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 079b7d3d0c53..da2d0661b630 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1139,7 +1139,8 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
if (intel_dp->psr.psr2_enabled) {
if (DISPLAY_VER(dev_priv) == 9)
- intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
+ intel_de_rmw(dev_priv,
+CHICKEN_TRANS(cpu_transcoder), 0,
PSR2_VSC_ENABLE_PROG_HEADER |
PSR2_ADD_VERTICAL_LINE_COUNT);
@@ -1149,7 +1150,8 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
* cause issues if non-supported panels are used.
*/
if (IS_ALDERLAKE_P(dev_priv))
- intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
+ intel_de_rmw(dev_priv,
+
