[PATCH v3 4/5] drm/msm/a6xx: Remove cx gdsc polling using 'reset'

2022-12-19 Thread Akhil P Oommen
Remove the unused 'reset' interface which was supposed to help to ensure
that cx gdsc has collapsed during gpu recovery. This is was not enabled
so far due to missing gpucc driver support. Similar functionality using
genpd framework will be implemented in the upcoming patch.

This effectively reverts commit 1f6cca404918
("drm/msm/a6xx: Ensure CX collapse during gpu recovery").

Signed-off-by: Akhil P Oommen 
---

Changes in v3:
- Updated commit msg (Philipp)

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 
 drivers/gpu/drm/msm/msm_gpu.c | 4 
 drivers/gpu/drm/msm/msm_gpu.h | 4 
 3 files changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 36c8fb699b56..4b16e75dfa50 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,7 +10,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #define GPU_PAS_ID 13
@@ -1298,9 +1297,6 @@ static void a6xx_recover(struct msm_gpu *gpu)
/* And the final one from recover worker */
pm_runtime_put_sync(>pdev->dev);
 
-   /* Call into gpucc driver to poll for cx gdsc collapse */
-   reset_control_reset(gpu->cx_collapse);
-
pm_runtime_use_autosuspend(>pdev->dev);
 
if (active_submits)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 30ed45af76ad..97e1319d4577 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /*
@@ -933,9 +932,6 @@ int msm_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
if (IS_ERR(gpu->gpu_cx))
gpu->gpu_cx = NULL;
 
-   gpu->cx_collapse = devm_reset_control_get_optional_exclusive(>dev,
-   "cx_collapse");
-
gpu->pdev = pdev;
platform_set_drvdata(pdev, >adreno_smmu);
 
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 651786bc55e5..fa9e34d02c91 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "msm_drv.h"
 #include "msm_fence.h"
@@ -282,9 +281,6 @@ struct msm_gpu {
bool hw_apriv;
 
struct thermal_cooling_device *cooling;
-
-   /* To poll for cx gdsc collapse during gpu recovery */
-   struct reset_control *cx_collapse;
 };
 
 static inline struct msm_gpu *dev_to_gpu(struct device *dev)
-- 
2.7.4



[PATCH v3 5/5] drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc collapse

2022-12-19 Thread Akhil P Oommen
As per the recommended recovery sequence of adreno gpu, cx gdsc should
collapse at hardware before it is turned back ON. This helps to clear
out the stale states in hardware before it is reinitialized. Use the
genpd notifier along with the newly introduced
dev_pm_genpd_synced_poweroff() api to ensure that cx gdsc has collapsed
before we turn it back ON.

Signed-off-by: Akhil P Oommen 
---

(no changes since v2)

Changes in v2:
- Select PM_GENERIC_DOMAINS from Kconfig

 drivers/gpu/drm/msm/Kconfig   |  1 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 15 +++
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h |  6 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 11 +++
 4 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 3c9dfdb0b328..74f5916f5ca5 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -28,6 +28,7 @@ config DRM_MSM
select SYNC_FILE
select PM_OPP
select NVMEM
+   select PM_GENERIC_DOMAINS
help
  DRM/KMS driver for MSM/snapdragon.
 
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 1580d0090f35..c03830957c26 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1507,6 +1507,17 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
gmu->initialized = false;
 }
 
+static int cxpd_notifier_cb(struct notifier_block *nb,
+   unsigned long action, void *data)
+{
+   struct a6xx_gmu *gmu = container_of(nb, struct a6xx_gmu, pd_nb);
+
+   if (action == GENPD_NOTIFY_OFF)
+   complete_all(>pd_gate);
+
+   return 0;
+}
+
 int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
 {
struct adreno_gpu *adreno_gpu = _gpu->base;
@@ -1640,6 +1651,10 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct 
device_node *node)
goto detach_cxpd;
}
 
+   init_completion(>pd_gate);
+   complete_all(>pd_gate);
+   gmu->pd_nb.notifier_call = cxpd_notifier_cb;
+
/*
 * Get a link to the GX power domain to reset the GPU in case of GMU
 * crash
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 5a42dd4dd31f..0bc3eb443fec 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -4,8 +4,10 @@
 #ifndef _A6XX_GMU_H_
 #define _A6XX_GMU_H_
 
+#include 
 #include 
 #include 
+#include 
 #include "msm_drv.h"
 #include "a6xx_hfi.h"
 
@@ -90,6 +92,10 @@ struct a6xx_gmu {
bool initialized;
bool hung;
bool legacy; /* a618 or a630 */
+
+   /* For power domain callback */
+   struct notifier_block pd_nb;
+   struct completion pd_gate;
 };
 
 static inline u32 gmu_read(struct a6xx_gmu *gmu, u32 offset)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 4b16e75dfa50..dd618b099110 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #define GPU_PAS_ID 13
@@ -1258,6 +1259,7 @@ static void a6xx_recover(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+   struct a6xx_gmu *gmu = _gpu->gmu;
int i, active_submits;
 
adreno_dump_info(gpu);
@@ -1290,6 +1292,10 @@ static void a6xx_recover(struct msm_gpu *gpu)
 */
gpu->active_submits = 0;
 
+   reinit_completion(>pd_gate);
+   dev_pm_genpd_add_notifier(gmu->cxpd, >pd_nb);
+   dev_pm_genpd_synced_poweroff(gmu->cxpd);
+
/* Drop the rpm refcount from active submits */
if (active_submits)
pm_runtime_put(>pdev->dev);
@@ -1297,6 +1303,11 @@ static void a6xx_recover(struct msm_gpu *gpu)
/* And the final one from recover worker */
pm_runtime_put_sync(>pdev->dev);
 
+   if (!wait_for_completion_timeout(>pd_gate, msecs_to_jiffies(1000)))
+   DRM_DEV_ERROR(>pdev->dev, "cx gdsc didn't collapse\n");
+
+   dev_pm_genpd_remove_notifier(gmu->cxpd);
+
pm_runtime_use_autosuspend(>pdev->dev);
 
if (active_submits)
-- 
2.7.4



[PATCH v3 2/5] clk: qcom: gdsc: Support 'synced_poweroff' genpd flag

2022-12-19 Thread Akhil P Oommen
Add support for the newly added 'synced_poweroff' genpd flag. This allows
some clients (like adreno gpu driver) to request gdsc driver to ensure
a votable gdsc (like gpucc cx gdsc) has collapsed at hardware.

Signed-off-by: Akhil P Oommen 
---

Changes in v3:
- Rename the var 'force_sync' to 'wait (Stephen)

 drivers/clk/qcom/gdsc.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index 9e4d6ce891aa..5358e28122ab 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -136,7 +136,8 @@ static int gdsc_update_collapse_bit(struct gdsc *sc, bool 
val)
return 0;
 }
 
-static int gdsc_toggle_logic(struct gdsc *sc, enum gdsc_status status)
+static int gdsc_toggle_logic(struct gdsc *sc, enum gdsc_status status,
+   bool wait)
 {
int ret;
 
@@ -149,7 +150,7 @@ static int gdsc_toggle_logic(struct gdsc *sc, enum 
gdsc_status status)
ret = gdsc_update_collapse_bit(sc, status == GDSC_OFF);
 
/* If disabling votable gdscs, don't poll on status */
-   if ((sc->flags & VOTABLE) && status == GDSC_OFF) {
+   if ((sc->flags & VOTABLE) && status == GDSC_OFF && !wait) {
/*
 * Add a short delay here to ensure that an enable
 * right after it was disabled does not put it in an
@@ -275,7 +276,7 @@ static int gdsc_enable(struct generic_pm_domain *domain)
gdsc_deassert_clamp_io(sc);
}
 
-   ret = gdsc_toggle_logic(sc, GDSC_ON);
+   ret = gdsc_toggle_logic(sc, GDSC_ON, false);
if (ret)
return ret;
 
@@ -352,7 +353,7 @@ static int gdsc_disable(struct generic_pm_domain *domain)
if (sc->pwrsts == PWRSTS_RET_ON)
return 0;
 
-   ret = gdsc_toggle_logic(sc, GDSC_OFF);
+   ret = gdsc_toggle_logic(sc, GDSC_OFF, domain->synced_poweroff);
if (ret)
return ret;
 
@@ -392,7 +393,7 @@ static int gdsc_init(struct gdsc *sc)
 
/* Force gdsc ON if only ON state is supported */
if (sc->pwrsts == PWRSTS_ON) {
-   ret = gdsc_toggle_logic(sc, GDSC_ON);
+   ret = gdsc_toggle_logic(sc, GDSC_ON, false);
if (ret)
return ret;
}
-- 
2.7.4



[PATCH v3 3/5] drm/msm/a6xx: Vote for cx gdsc from gpu driver

2022-12-19 Thread Akhil P Oommen
When a device has multiple power domains, dev->power_domain is left
empty during probe. That didn't cause any issue so far because we are
freeloading on smmu driver's vote on cx gdsc. Instead of that, create
a device_link between cx genpd device and gmu device to keep a vote from
gpu driver.

Before this patch:
localhost ~ # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
gx_gdsc on  0
/devices/genpd:1:3d6a000.gmuactive  0
cx_gdsc on  0
/devices/platform/soc@0/3da.iommu   active  0

After this patch:
localhost ~ # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
gx_gdsc on  0
/devices/genpd:1:3d6a000.gmuactive  0
cx_gdsc on  0
/devices/platform/soc@0/3da.iommu   active  0
/devices/genpd:0:3d6a000.gmuactive  0

Signed-off-by: Akhil P Oommen 
---

(no changes since v1)

 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 31 +++
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h |  1 +
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 6484b97c5344..1580d0090f35 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1479,6 +1479,12 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
 
pm_runtime_force_suspend(gmu->dev);
 
+   /*
+* Since cxpd is a virt device, the devlink with gmu-dev will be removed
+* automatically when we do detach
+*/
+   dev_pm_domain_detach(gmu->cxpd, false);
+
if (!IS_ERR_OR_NULL(gmu->gxpd)) {
pm_runtime_disable(gmu->gxpd);
dev_pm_domain_detach(gmu->gxpd, false);
@@ -1605,8 +1611,10 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct 
device_node *node)
 
if (adreno_is_a650_family(adreno_gpu)) {
gmu->rscc = a6xx_gmu_get_mmio(pdev, "rscc");
-   if (IS_ERR(gmu->rscc))
+   if (IS_ERR(gmu->rscc)) {
+   ret = -ENODEV;
goto err_mmio;
+   }
} else {
gmu->rscc = gmu->mmio + 0x23000;
}
@@ -1615,8 +1623,22 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct 
device_node *node)
gmu->hfi_irq = a6xx_gmu_get_irq(gmu, pdev, "hfi", a6xx_hfi_irq);
gmu->gmu_irq = a6xx_gmu_get_irq(gmu, pdev, "gmu", a6xx_gmu_irq);
 
-   if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0)
+   if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0) {
+   ret = -ENODEV;
+   goto err_mmio;
+   }
+
+   gmu->cxpd = dev_pm_domain_attach_by_name(gmu->dev, "cx");
+   if (IS_ERR(gmu->cxpd)) {
+   ret = PTR_ERR(gmu->cxpd);
goto err_mmio;
+   }
+
+   if (!device_link_add(gmu->dev, gmu->cxpd,
+   DL_FLAG_PM_RUNTIME)) {
+   ret = -ENODEV;
+   goto detach_cxpd;
+   }
 
/*
 * Get a link to the GX power domain to reset the GPU in case of GMU
@@ -1634,6 +1656,9 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct 
device_node *node)
 
return 0;
 
+detach_cxpd:
+   dev_pm_domain_detach(gmu->cxpd, false);
+
 err_mmio:
iounmap(gmu->mmio);
if (platform_get_resource_byname(pdev, IORESOURCE_MEM, "rscc"))
@@ -1641,8 +1666,6 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct 
device_node *node)
free_irq(gmu->gmu_irq, gmu);
free_irq(gmu->hfi_irq, gmu);
 
-   ret = -ENODEV;
-
 err_memory:
a6xx_gmu_memory_free(gmu);
 err_put_device:
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index e034935b3986..5a42dd4dd31f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -56,6 +56,7 @@ struct a6xx_gmu {
int gmu_irq;
 
struct device *gxpd;
+   struct device *cxpd;
 
int idle_level;
 
-- 
2.7.4



[PATCH v3 0/5] Improve GPU reset sequence for Adreno GPU

2022-12-19 Thread Akhil P Oommen


This is a rework of [1] using genpd instead of 'reset' framework.

As per the recommended reset sequence of Adreno gpu, we should ensure that
gpucc-cx-gdsc has collapsed at hardware to reset gpu's internal hardware states.
Because this gdsc is implemented as 'votable', gdsc driver doesn't poll and
wait until its hw status says OFF.

So use the newly introduced genpd api (dev_pm_genpd_synced_poweroff()) to
provide a hint to the gdsc driver to poll for the hw status and use genpd
notifier to wait from adreno gpu driver until gdsc is turned OFF.

This series is rebased on top of linux-next (20221215) since the changes span
multiple drivers.

[1] https://patchwork.freedesktop.org/series/107507/

Changes in v3:
- Rename the var 'force_sync' to 'wait (Stephen)

Changes in v2:
- Minor formatting fix
- Select PM_GENERIC_DOMAINS from Kconfig

Akhil P Oommen (4):
  clk: qcom: gdsc: Support 'synced_poweroff' genpd flag
  drm/msm/a6xx: Vote for cx gdsc from gpu driver
  drm/msm/a6xx: Remove cx gdsc polling using 'reset'
  drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc collapse

Ulf Hansson (1):
  PM: domains: Allow a genpd consumer to require a synced power off

 drivers/base/power/domain.c   | 23 ++
 drivers/clk/qcom/gdsc.c   | 11 +
 drivers/gpu/drm/msm/Kconfig   |  1 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 46 ---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h |  7 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 13 +++---
 drivers/gpu/drm/msm/msm_gpu.c |  4 ---
 drivers/gpu/drm/msm/msm_gpu.h |  4 ---
 include/linux/pm_domain.h |  5 
 9 files changed, 94 insertions(+), 20 deletions(-)

-- 
2.7.4



[PATCH v3 1/5] PM: domains: Allow a genpd consumer to require a synced power off

2022-12-19 Thread Akhil P Oommen
From: Ulf Hansson 

Some genpd providers doesn't ensure that it has turned off at hardware.
This is fine until the consumer really requires during some special
scenarios that the power domain collapse at hardware before it is
turned ON again.

An example is the reset sequence of Adreno GPU which requires that the
'gpucc cx gdsc' power domain should move to OFF state in hardware at
least once before turning in ON again to clear the internal state.

Signed-off-by: Ulf Hansson 
Signed-off-by: Akhil P Oommen 
---

(no changes since v2)

Changes in v2:
- Minor formatting fix

 drivers/base/power/domain.c | 23 +++
 include/linux/pm_domain.h   |  5 +
 2 files changed, 28 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 967bcf9d415e..53524a102321 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -519,6 +519,28 @@ ktime_t dev_pm_genpd_get_next_hrtimer(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(dev_pm_genpd_get_next_hrtimer);
 
+/*
+ * dev_pm_genpd_synced_poweroff - Next power off should be synchronous
+ *
+ * @dev: A device that is attached to the genpd.
+ *
+ * Allows a consumer of the genpd to notify the provider that the next power 
off
+ * should be synchronous.
+ */
+void dev_pm_genpd_synced_poweroff(struct device *dev)
+{
+   struct generic_pm_domain *genpd;
+
+   genpd = dev_to_genpd_safe(dev);
+   if (!genpd)
+   return;
+
+   genpd_lock(genpd);
+   genpd->synced_poweroff = true;
+   genpd_unlock(genpd);
+}
+EXPORT_SYMBOL_GPL(dev_pm_genpd_synced_poweroff);
+
 static int _genpd_power_on(struct generic_pm_domain *genpd, bool timed)
 {
unsigned int state_idx = genpd->state_idx;
@@ -562,6 +584,7 @@ static int _genpd_power_on(struct generic_pm_domain *genpd, 
bool timed)
 
 out:
raw_notifier_call_chain(>power_notifiers, GENPD_NOTIFY_ON, NULL);
+   genpd->synced_poweroff = false;
return 0;
 err:
raw_notifier_call_chain(>power_notifiers, GENPD_NOTIFY_OFF,
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 1cd41bdf73cf..f776fb93eaa0 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -136,6 +136,7 @@ struct generic_pm_domain {
unsigned int prepared_count;/* Suspend counter of prepared devices 
*/
unsigned int performance_state; /* Aggregated max performance state */
cpumask_var_t cpus; /* A cpumask of the attached CPUs */
+   bool synced_poweroff;   /* A consumer needs a synced poweroff */
int (*power_off)(struct generic_pm_domain *domain);
int (*power_on)(struct generic_pm_domain *domain);
struct raw_notifier_head power_notifiers; /* Power on/off notifiers */
@@ -235,6 +236,7 @@ int dev_pm_genpd_add_notifier(struct device *dev, struct 
notifier_block *nb);
 int dev_pm_genpd_remove_notifier(struct device *dev);
 void dev_pm_genpd_set_next_wakeup(struct device *dev, ktime_t next);
 ktime_t dev_pm_genpd_get_next_hrtimer(struct device *dev);
+void dev_pm_genpd_synced_poweroff(struct device *dev);
 
 extern struct dev_power_governor simple_qos_governor;
 extern struct dev_power_governor pm_domain_always_on_gov;
@@ -300,6 +302,9 @@ static inline ktime_t dev_pm_genpd_get_next_hrtimer(struct 
device *dev)
 {
return KTIME_MAX;
 }
+static inline void dev_pm_genpd_synced_poweroff(struct device *dev)
+{ }
+
 #define simple_qos_governor(*(struct dev_power_governor *)(NULL))
 #define pm_domain_always_on_gov(*(struct dev_power_governor 
*)(NULL))
 #endif
-- 
2.7.4



Re: [PATCH] drm/fsl-dcu: Remove redundant error logging

2022-12-19 Thread Stefan Agner
On 2022-12-11 11:27, Deepak R Varma wrote:
> A call to platform_get_irq() already prints an error on failure within
> its own implementation. So printing another error based on its return
> value in the caller is redundant and should be removed. The clean up
> also makes if condition block braces unnecessary. Remove that as well.
> 
> Issue identified using platform_get_irq.cocci coccicheck script.
> 
> Signed-off-by: Deepak R Varma 

Reviewed-by: Stefan Agner 

--
Stefan

> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> index 8579c7629f5e..1ba7d95e1956 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -272,10 +272,8 @@ static int fsl_dcu_drm_probe(struct platform_device 
> *pdev)
>   }
> 
>   fsl_dev->irq = platform_get_irq(pdev, 0);
> - if (fsl_dev->irq < 0) {
> - dev_err(dev, "failed to get irq\n");
> + if (fsl_dev->irq < 0)
>   return fsl_dev->irq;
> - }
> 
>   fsl_dev->regmap = devm_regmap_init_mmio(dev, base,
>   _dcu_regmap_config);
> --
> 2.34.1


Re: [PATCH] drm/drv: Make use of local variable driver in drm_dev_register()

2022-12-19 Thread Thomas Zimmermann

Hi

Am 19.12.22 um 19:31 schrieb Uwe Kleine-König:

There is a local variable that contains dev->driver. Make use of it
instead of "open coding" it.

Signed-off-by: Uwe Kleine-König 


Added to drm-misc-next. Thanks a lot.

Best regards
Thomas


---
  drivers/gpu/drm/drm_drv.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 203bf8d6c34c..3cc8e8111d16 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -889,8 +889,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
  
  	dev->registered = true;
  
-	if (dev->driver->load) {

-   ret = dev->driver->load(dev, flags);
+   if (driver->load) {
+   ret = driver->load(dev, flags);
if (ret)
goto err_minors;
}

base-commit: 678e5b2258e871b22fe8c26edac2723feb852a47


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature


[Bug 216625] [regression] GPU lockup on Radeon R7 Kaveri

2022-12-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=216625

--- Comment #7 from Pierre Ossman (pierre-bugzi...@ossman.eu) ---
Sorry, I haven't had time to look at downgrading Mesa yet. But FYI, it does
still happen with mesa 22.1.7 and kernel 6.0.10.

I am now almost 100% certain that it is videos that are triggering this. And
possibly not all videos. So I'm thinking, perhaps the video acceleration?

Is that also handled by mesa, or some other component?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] [next] i915/gvt: Replace one-element array with flexible-array member

2022-12-19 Thread Paulo Miguel Almeida
One-element arrays are deprecated, and we are replacing them with
flexible array members instead. So, replace one-element array with
flexible-array member in struct gvt_firmware_header and refactor the
rest of the code accordingly.

Additionally, previous implementation was allocating 8 bytes more than
required to represent firmware_header + cfg_space data + mmio data.

This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].

Link: https://github.com/KSPP/linux/issues/79
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1]
Signed-off-by: Paulo Miguel Almeida 
---
To make reviewing this patch easier, I'm pasting before/after struct
sizes.

pahole -C gvt_firmware_header before/drivers/gpu/drm/i915/gvt/firmware.o 
struct gvt_firmware_header {
u64magic;/* 0 8 */
u32crc32;/* 8 4 */
u32version;  /*12 4 */
u64cfg_space_size;   /*16 8 */
u64cfg_space_offset; /*24 8 */
u64mmio_size;/*32 8 */
u64mmio_offset;  /*40 8 */
unsigned char  data[1];  /*48 1 */

/* size: 56, cachelines: 1, members: 8 */
/* padding: 7 */
/* last cacheline: 56 bytes */
};

pahole -C gvt_firmware_header after/drivers/gpu/drm/i915/gvt/firmware.o 
struct gvt_firmware_header {
u64magic;/* 0 8 */
u32crc32;/* 8 4 */
u32version;  /*12 4 */
u64cfg_space_size;   /*16 8 */
u64cfg_space_offset; /*24 8 */
u64mmio_size;/*32 8 */
u64mmio_offset;  /*40 8 */
unsigned char  data[];   /*48 0 */

/* size: 48, cachelines: 1, members: 8 */
/* last cacheline: 48 bytes */
};

As you can see the additional byte of the fake-flexible array (data[1])
forced the compiler to pad the struct but those bytes aren't actually used
as first & last bytes (of both cfg_space and mmio) are controlled by the
<>_size and <>_offset members present in the gvt_firmware_header struct.
---
 drivers/gpu/drm/i915/gvt/firmware.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index a683c22d5b64..dce93738e98a 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -45,7 +45,7 @@ struct gvt_firmware_header {
u64 cfg_space_offset;   /* offset in the file */
u64 mmio_size;
u64 mmio_offset;/* offset in the file */
-   unsigned char data[1];
+   unsigned char data[];
 };
 
 #define dev_to_drm_minor(d) dev_get_drvdata((d))
@@ -77,7 +77,7 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
unsigned long size, crc32_start;
int ret;
 
-   size = sizeof(*h) + info->mmio_size + info->cfg_space_size;
+   size = offsetof(struct gvt_firmware_header, data) + info->mmio_size + 
info->cfg_space_size;
firmware = vzalloc(size);
if (!firmware)
return -ENOMEM;
-- 
2.38.1



[PATCH 2/3] drm/i915/guc: Fix a static analysis warning

2022-12-19 Thread John . C . Harrison
From: John Harrison 

A static analyser was complaining about not checking for null
pointers. However, the location of the complaint can only be reached
in the first place if said pointer is non-null. Basically, if we are
using a v69 GuC then the descriptor pool is guaranteed to be alocated
at start of day or submission will be disabled with an ENOMEM error.
And if we are using a later GuC that does not use a descriptor pool
then the v69 submission function would not be called. So, not a
possible null at that point in the code.

Hence adding a GEM_BUG_ON(!ptr) to keep the tool happy.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 4682ec1dbd9c0..c93d0594bfd5e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2538,6 +2538,7 @@ static void prepare_context_registration_info_v69(struct 
intel_context *ce)
   i915_gem_object_is_lmem(ce->ring->vma->obj));
 
desc = __get_lrc_desc_v69(guc, ctx_id);
+   GEM_BUG_ON(!desc);
desc->engine_class = engine_class_to_guc_class(engine->class);
desc->engine_submit_mask = engine->logical_mask;
desc->hw_context_desc = ce->lrc.lrca;
-- 
2.39.0



[PATCH 1/3] drm/i915/guc: Fix missing return code checks in submission init

2022-12-19 Thread John . C . Harrison
From: John Harrison 

The CI results for the 'fast request' patch set (enables error return
codes for fire-and-forget H2G messages) hit an issue with the KMD
sending context submission requests on an invalid context. That was
caused by a fault injection probe failing the context creation of a
kernel context. However, there was no return code checking on any of
the kernel context registration paths. So the driver kept going and
tried to use the kernel context for the record defaults process.

Fix that by checking for errors and aborting as appropriate when
creating kernel contexts. While at it, clean up some other submission
init related failure cleanup paths. Also, rename guc_init_lrc_mapping
to guc_init_submission as the former name hasn't been valid in a long
time.

Signed-off-by: John Harrison 
---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 74 ++-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.h |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  7 +-
 3 files changed, 62 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 53f7f599cde3a..4682ec1dbd9c0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1431,21 +1431,25 @@ static int guc_action_enable_usage_stats(struct 
intel_guc *guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
 }
 
-static void guc_init_engine_stats(struct intel_guc *guc)
+static int guc_init_engine_stats(struct intel_guc *guc)
 {
struct intel_gt *gt = guc_to_gt(guc);
intel_wakeref_t wakeref;
+   int ret;
 
mod_delayed_work(system_highpri_wq, >timestamp.work,
 guc->timestamp.ping_delay);
 
with_intel_runtime_pm(>i915->runtime_pm, wakeref) {
-   int ret = guc_action_enable_usage_stats(guc);
+   ret = guc_action_enable_usage_stats(guc);
 
-   if (ret)
-   drm_err(>i915->drm,
-   "Failed to enable usage stats: %d!\n", ret);
+   if (ret) {
+   cancel_delayed_work_sync(>timestamp.work);
+   drm_err(>i915->drm, "Failed to enable usage stats: 
%d!\n", ret);
+   }
}
+
+   return ret;
 }
 
 void intel_guc_busyness_park(struct intel_gt *gt)
@@ -4101,9 +4105,11 @@ static void guc_set_default_submission(struct 
intel_engine_cs *engine)
engine->submit_request = guc_submit_request;
 }
 
-static inline void guc_kernel_context_pin(struct intel_guc *guc,
- struct intel_context *ce)
+static inline int guc_kernel_context_pin(struct intel_guc *guc,
+struct intel_context *ce)
 {
+   int ret;
+
/*
 * Note: we purposefully do not check the returns below because
 * the registration can only fail if a reset is just starting.
@@ -4111,16 +4117,24 @@ static inline void guc_kernel_context_pin(struct 
intel_guc *guc,
 * isn't happening and even it did this code would be run again.
 */
 
-   if (context_guc_id_invalid(ce))
-   pin_guc_id(guc, ce);
+   if (context_guc_id_invalid(ce)) {
+   int ret = pin_guc_id(guc, ce);
+
+   if (ret < 0)
+   return ret;
+   }
 
if (!test_bit(CONTEXT_GUC_INIT, >flags))
guc_context_init(ce);
 
-   try_context_registration(ce, true);
+   ret = try_context_registration(ce, true);
+   if (ret)
+   unpin_guc_id(guc, ce);
+
+   return ret;
 }
 
-static inline void guc_init_lrc_mapping(struct intel_guc *guc)
+static inline int guc_init_submission(struct intel_guc *guc)
 {
struct intel_gt *gt = guc_to_gt(guc);
struct intel_engine_cs *engine;
@@ -4147,9 +4161,17 @@ static inline void guc_init_lrc_mapping(struct intel_guc 
*guc)
struct intel_context *ce;
 
list_for_each_entry(ce, >pinned_contexts_list,
-   pinned_contexts_link)
-   guc_kernel_context_pin(guc, ce);
+   pinned_contexts_link) {
+   int ret = guc_kernel_context_pin(guc, ce);
+
+   if (ret) {
+   /* No point in trying to clean up as i915 will 
wedge on failure */
+   return ret;
+   }
+   }
}
+
+   return 0;
 }
 
 static void guc_release(struct intel_engine_cs *engine)
@@ -4391,9 +4413,10 @@ static int guc_init_global_schedule_policy(struct 
intel_guc *guc)
return ret;
 }
 
-void intel_guc_submission_enable(struct intel_guc *guc)
+int intel_guc_submission_enable(struct intel_guc *guc)
 {
struct intel_gt *gt = guc_to_gt(guc);
+   int ret;
 
/* Enable and 

[PATCH 3/3] drm/i915/uc: Fix two issues with over-size firmware files

2022-12-19 Thread John . C . Harrison
From: John Harrison 

In the case where a firmware file is too large (e.g. someone
downloaded a web page ASCII dump from github...), the firmware object
is released but the pointer is not zerod. If no other firmware file
was found then release would be called again leading to a double kfree.

Also, the size check was only being applied to the initial firmware
load not any of the subsequent attempts. So move the check into a
wrapper that is used for all loads.

Fixes: 016241168dc5 ("drm/i915/uc: use different ggtt pin offsets for uc loads")
Signed-off-by: John Harrison 
Cc: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: Rodrigo Vivi 
Cc: Matt Roper 
Cc: Jani Nikula 
Cc: Matthew Auld 
Cc: "Thomas Hellström" 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 42 
 1 file changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index d6ff6c584c1e1..06b5f92ba3a55 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -675,6 +675,32 @@ static int check_fw_header(struct intel_gt *gt,
return 0;
 }
 
+int try_firmware_load(struct intel_uc_fw *uc_fw, const struct firmware **fw)
+{
+   struct intel_gt *gt = __uc_fw_to_gt(uc_fw);
+   struct device *dev = gt->i915->drm.dev;
+   int err;
+
+   err = firmware_request_nowarn(fw, uc_fw->file_selected.path, dev);
+
+   if (err)
+   return err;
+
+   if ((*fw)->size > INTEL_UC_RSVD_GGTT_PER_FW) {
+   drm_err(>i915->drm,
+   "%s firmware %s: size (%zuKB) exceeds max supported 
size (%uKB)\n",
+   intel_uc_fw_type_repr(uc_fw->type), 
uc_fw->file_selected.path,
+   (*fw)->size / SZ_1K, INTEL_UC_RSVD_GGTT_PER_FW / SZ_1K);
+
+   /* try to find another blob to load */
+   release_firmware(*fw);
+   *fw = NULL;
+   return -ENOENT;
+   }
+
+   return 0;
+}
+
 /**
  * intel_uc_fw_fetch - fetch uC firmware
  * @uc_fw: uC firmware
@@ -688,7 +714,6 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
struct intel_gt *gt = __uc_fw_to_gt(uc_fw);
struct drm_i915_private *i915 = gt->i915;
struct intel_uc_fw_file file_ideal;
-   struct device *dev = i915->drm.dev;
struct drm_i915_gem_object *obj;
const struct firmware *fw = NULL;
bool old_ver = false;
@@ -704,20 +729,9 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
__force_fw_fetch_failures(uc_fw, -EINVAL);
__force_fw_fetch_failures(uc_fw, -ESTALE);
 
-   err = firmware_request_nowarn(, uc_fw->file_selected.path, dev);
+   err = try_firmware_load(uc_fw, );
memcpy(_ideal, _fw->file_wanted, sizeof(file_ideal));
 
-   if (!err && fw->size > INTEL_UC_RSVD_GGTT_PER_FW) {
-   drm_err(>drm,
-   "%s firmware %s: size (%zuKB) exceeds max supported 
size (%uKB)\n",
-   intel_uc_fw_type_repr(uc_fw->type), 
uc_fw->file_selected.path,
-   fw->size / SZ_1K, INTEL_UC_RSVD_GGTT_PER_FW / SZ_1K);
-
-   /* try to find another blob to load */
-   release_firmware(fw);
-   err = -ENOENT;
-   }
-
/* Any error is terminal if overriding. Don't bother searching for 
older versions */
if (err && intel_uc_fw_is_overridden(uc_fw))
goto fail;
@@ -738,7 +752,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
break;
}
 
-   err = firmware_request_nowarn(, uc_fw->file_selected.path, 
dev);
+   err = try_firmware_load(uc_fw, );
}
 
if (err)
-- 
2.39.0



[PATCH 0/3] Fixes for various UC related issues

2022-12-19 Thread John . C . Harrison
From: John Harrison 

Fix a bunch of assorted issues with firmware loading and GuC
intialisation.

Signed-off-by: John Harrison 


John Harrison (3):
  drm/i915/guc: Fix missing return code checks in submission init
  drm/i915/guc: Fix a static analysis warning
  drm/i915/uc: Fix two issues with over-size firmware files

 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 75 ++-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.h |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  7 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 42 +++
 4 files changed, 91 insertions(+), 35 deletions(-)

-- 
2.39.0



[PATCH AUTOSEL 4.9 1/3] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function 
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, 
struct drm_display_mode *)' with an expression of type 'int (struct 
drm_connector *, struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
  1 error generated.

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index e1dd75b18118..5993d6ac85e6 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -90,8 +90,9 @@ static int fsl_dcu_drm_connector_get_modes(struct 
drm_connector *connector)
return num_modes;
 }
 
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
if (mode->hdisplay & 0xf)
return MODE_ERROR;
-- 
2.35.1



[PATCH AUTOSEL 5.4 2/5] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function 
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, 
struct drm_display_mode *)' with an expression of type 'int (struct 
drm_connector *, struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
  1 error generated.

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index a92fd6c70b09..8de9bc8343a2 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -70,8 +70,9 @@ static int fsl_dcu_drm_connector_get_modes(struct 
drm_connector *connector)
return drm_panel_get_modes(fsl_connector->panel);
 }
 
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
if (mode->hdisplay & 0xf)
return MODE_ERROR;
-- 
2.35.1



[PATCH AUTOSEL 4.9 2/3] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hda_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_dvo_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hdmi_connector_mode_valid,
^

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_dvo.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hda.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index e8c1ed08a9f7..c67a543d3574 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -354,8 +354,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 08808e3701de..bfdc5197bc7f 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -606,8 +606,9 @@ static int sti_hda_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index a5412a6fbeca..d62616f62b53 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -906,8 +906,9 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
-- 
2.35.1



[PATCH AUTOSEL 4.19 1/3] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function 
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, 
struct drm_display_mode *)' with an expression of type 'int (struct 
drm_connector *, struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
  1 error generated.

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 2298ed2a9e1c..3c8c4a820e95 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -83,8 +83,9 @@ static int fsl_dcu_drm_connector_get_modes(struct 
drm_connector *connector)
return num_modes;
 }
 
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
if (mode->hdisplay & 0xf)
return MODE_ERROR;
-- 
2.35.1



[PATCH AUTOSEL 4.19 2/3] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hda_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_dvo_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hdmi_connector_mode_valid,
^

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_dvo.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hda.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index b08376b7611b..08d096822f24 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -346,8 +346,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 19b9b5ed1297..9974c19c04c4 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -596,8 +596,9 @@ static int sti_hda_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index ccf718404a1c..b5199dd4b817 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -989,8 +989,9 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
-- 
2.35.1



[PATCH AUTOSEL 5.4 3/5] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hda_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_dvo_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hdmi_connector_mode_valid,
^

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_dvo.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hda.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index e55870190bf5..71c0b9875cb8 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -345,8 +345,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 94e404f13234..7a975d7eeec0 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -600,8 +600,9 @@ static int sti_hda_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 9862c322f0c4..b0a5f75b1b16 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -996,8 +996,9 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
-- 
2.35.1



[PATCH AUTOSEL 4.14 2/3] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hda_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_dvo_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hdmi_connector_mode_valid,
^

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_dvo.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hda.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 852bf2293b05..755319c86187 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -346,8 +346,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 0399bb18d387..39de2e14fdbb 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -596,8 +596,9 @@ static int sti_hda_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index bbb195a92e93..1b95c82b2dcf 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -988,8 +988,9 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
-- 
2.35.1



[PATCH AUTOSEL 4.14 1/3] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function 
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, 
struct drm_display_mode *)' with an expression of type 'int (struct 
drm_connector *, struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
  1 error generated.

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index c54806d08dd7..aec9fe01dfe9 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -83,8 +83,9 @@ static int fsl_dcu_drm_connector_get_modes(struct 
drm_connector *connector)
return num_modes;
 }
 
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
if (mode->hdisplay & 0xf)
return MODE_ERROR;
-- 
2.35.1



[PATCH AUTOSEL 5.15 6/9] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function 
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, 
struct drm_display_mode *)' with an expression of type 'int (struct 
drm_connector *, struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
  1 error generated.

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 4d4a715b429d..2c2b92324a2e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -60,8 +60,9 @@ static int fsl_dcu_drm_connector_get_modes(struct 
drm_connector *connector)
return drm_panel_get_modes(fsl_connector->panel, connector);
 }
 
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
if (mode->hdisplay & 0xf)
return MODE_ERROR;
-- 
2.35.1



[PATCH AUTOSEL 5.10 3/5] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hda_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_dvo_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hdmi_connector_mode_valid,
^

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_dvo.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hda.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index ddb4184f0726..58b092eb8907 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -346,8 +346,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 5c2b650b561d..bc04b8f50b09 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -600,8 +600,9 @@ static int sti_hda_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 38a558768e53..b0890234ffbe 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -997,8 +997,9 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
-- 
2.35.1



[PATCH AUTOSEL 6.0 10/16] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function 
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, 
struct drm_display_mode *)' with an expression of type 'int (struct 
drm_connector *, struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
  1 error generated.

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 4d4a715b429d..2c2b92324a2e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -60,8 +60,9 @@ static int fsl_dcu_drm_connector_get_modes(struct 
drm_connector *connector)
return drm_panel_get_modes(fsl_connector->panel, connector);
 }
 
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
if (mode->hdisplay & 0xf)
return MODE_ERROR;
-- 
2.35.1



[PATCH AUTOSEL 5.10 2/5] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function 
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, 
struct drm_display_mode *)' with an expression of type 'int (struct 
drm_connector *, struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
  1 error generated.

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 4d4a715b429d..2c2b92324a2e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -60,8 +60,9 @@ static int fsl_dcu_drm_connector_get_modes(struct 
drm_connector *connector)
return drm_panel_get_modes(fsl_connector->panel, connector);
 }
 
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
if (mode->hdisplay & 0xf)
return MODE_ERROR;
-- 
2.35.1



[PATCH AUTOSEL 6.0 11/16] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hda_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_dvo_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hdmi_connector_mode_valid,
^

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_dvo.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hda.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index b6ee8a82e656..076d5f30a09c 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -346,8 +346,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 03cc401ed593..a53b5a15c2a9 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -601,8 +601,9 @@ static int sti_hda_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index cb82622877d2..09e0cadb6368 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1004,8 +1004,9 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
-- 
2.35.1



[PATCH AUTOSEL 5.15 7/9] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hda_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_dvo_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hdmi_connector_mode_valid,
^

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_dvo.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hda.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index b6ee8a82e656..076d5f30a09c 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -346,8 +346,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 03f3377f918c..1959387cda98 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -600,8 +600,9 @@ static int sti_hda_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index f3ace11209dd..dd256c7b9060 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1003,8 +1003,9 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
-- 
2.35.1



[PATCH AUTOSEL 6.1 11/16] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hda_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_dvo_connector_mode_valid,
^~~~
  drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer 
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct 
drm_display_mode *)' with an expression of type 'int (struct drm_connector *, 
struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = sti_hdmi_connector_mode_valid,
^

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_dvo.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hda.c  | 5 +++--
 drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index b6ee8a82e656..076d5f30a09c 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -346,8 +346,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 03cc401ed593..a53b5a15c2a9 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -601,8 +601,9 @@ static int sti_hda_connector_get_modes(struct drm_connector 
*connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index cb82622877d2..09e0cadb6368 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1004,8 +1004,9 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
 
 #define CLK_TOLERANCE_HZ 50
 
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
 {
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
-- 
2.35.1



[PATCH AUTOSEL 6.1 10/16] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()

2022-12-19 Thread Sasha Levin
From: Nathan Chancellor 

[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function 
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, 
struct drm_display_mode *)' with an expression of type 'int (struct 
drm_connector *, struct drm_display_mode *)' 
[-Werror,-Wincompatible-function-pointer-types-strict]
  .mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
  1 error generated.

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 4d4a715b429d..2c2b92324a2e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -60,8 +60,9 @@ static int fsl_dcu_drm_connector_get_modes(struct 
drm_connector *connector)
return drm_panel_get_modes(fsl_connector->panel, connector);
 }
 
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
 {
if (mode->hdisplay & 0xf)
return MODE_ERROR;
-- 
2.35.1



Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

2022-12-19 Thread Laurent Pinchart
Hi Tomi,

(CC'ing Sakari and Hans)

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +--
>  2 files changed, 71 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 8c2719efda2a..8ccabf5a30c4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info 
> rcar_du_format_infos[] = {
>   .bpp = 32,
>   .planes = 1,
>   .hsub = 1,
> + }, {
> + .fourcc = DRM_FORMAT_RGBX1010102,

Ah, here the format makes sense.

> + .v4l2 = V4L2_PIX_FMT_XBGR2101010,

But this is horrible :-( Could we use the same names as DRM for new
formats, when there is no conflict with existing V4L2 formats ?

Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
the format definitions.

> + .bpp = 32,
> + .planes = 1,
> + .hsub = 1,
> + }, {
> + .fourcc = DRM_FORMAT_RGBA1010102,
> + .v4l2 = V4L2_PIX_FMT_ABGR2101010,
> + .bpp = 32,
> + .planes = 1,
> + .hsub = 1,
> + }, {
> + .fourcc = DRM_FORMAT_ARGB2101010,
> + .v4l2 = V4L2_PIX_FMT_BGRA1010102,
> + .bpp = 32,
> + .planes = 1,
> + .hsub = 1,
>   }, {
>   .fourcc = DRM_FORMAT_YVYU,
>   .v4l2 = V4L2_PIX_FMT_YVYU,
> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info 
> rcar_du_format_infos[] = {
>   .bpp = 24,
>   .planes = 3,
>   .hsub = 1,
> + }, {
> + .fourcc = DRM_FORMAT_Y210,
> + .v4l2 = V4L2_PIX_FMT_Y210,
> + .bpp = 32,
> + .planes = 1,
> + .hsub = 2,
>   },

Any reason why you'd not adding Y212 support already ?

>  };
>  
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index e465aef41585..6f3e109a4f80 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
>   DRM_FORMAT_YVU444,
>  };
>  
> +/*
> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
> + * formats and Y210 format.
> + */
> +static const u32 rcar_du_vsp_formats_gen4[] = {
> + 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_RGBX1010102,
> + DRM_FORMAT_RGBA1010102,
> + DRM_FORMAT_ARGB2101010,
> + 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,
> + DRM_FORMAT_Y210,
> +};
> +
>  static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
>  {
>   struct rcar_du_vsp_plane_state *state =
> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>? DRM_PLANE_TYPE_PRIMARY
>: DRM_PLANE_TYPE_OVERLAY;
>   struct rcar_du_vsp_plane *plane = >planes[i];
> + unsigned int num_formats;
> + const u32 *formats;
> +
> + if (rcdu->info->gen < 4) {
> + num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
> + formats = rcar_du_vsp_formats;
> + } else {
> + num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
> + formats = rcar_du_vsp_formats_gen4;
> + }
>  
>   plane->vsp = vsp;
>   plane->index = i;
>  
>   ret = drm_universal_plane_init(>ddev, >plane,
>  crtcs, _du_vsp_plane_funcs,
> -rcar_du_vsp_formats,
> -ARRAY_SIZE(rcar_du_vsp_formats),
> +formats, num_formats,
>  NULL, type, NULL);
>   if (ret < 0)
>   return ret;

-- 
Regards,

Laurent Pinchart


Re: [PATCH v2 6/7] drm: rcar-du: Bump V3U to gen 4

2022-12-19 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:38PM +0200, Tomi Valkeinen wrote:
> V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the
> rcar_du_r8a779a0_info.

With the typo reporting by Kieran fixed,

Conditionally-Reviewed-by: Laurent Pinchart 


> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 46c60a2d710d..c7c5217cfc1a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -504,7 +504,7 @@ static const struct rcar_du_device_info 
> rcar_du_r8a7799x_info = {
>  };
>  
>  static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
> - .gen = 3,
> + .gen = 4,
>   .features = RCAR_DU_FEATURE_CRTC_IRQ
> | RCAR_DU_FEATURE_VSP1_SOURCE
> | RCAR_DU_FEATURE_NO_BLENDING,

-- 
Regards,

Laurent Pinchart


Re: [PATCH v2 5/7] media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210)

2022-12-19 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:37PM +0200, Tomi Valkeinen wrote:
> Add new pixel formats: XBGR2101010, ABGR2101010, BGRA1010102 and Y210.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  .../media/platform/renesas/vsp1/vsp1_pipe.c   | 15 ++
>  .../media/platform/renesas/vsp1/vsp1_regs.h   | 22 +
>  .../media/platform/renesas/vsp1/vsp1_rpf.c| 49 +++
>  3 files changed, 86 insertions(+)
> 
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c 
> b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> index f72ac01c21ea..2867b3de06fa 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> @@ -146,6 +146,18 @@ static const struct vsp1_format_info 
> vsp1_video_formats[] = {
> VI6_FMT_ARGB_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> 1, { 32, 0, 0 }, false, false, 1, 1, false },
> + { V4L2_PIX_FMT_XBGR2101010, MEDIA_BUS_FMT_ARGB_1X32,
> +   VI6_FMT_RGB10_RGB10A2_A2RGB10,
> +   VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +   1, { 32, 0, 0 }, false, false, 1, 1, false },
> + { V4L2_PIX_FMT_ABGR2101010, MEDIA_BUS_FMT_ARGB_1X32,
> +   VI6_FMT_RGB10_RGB10A2_A2RGB10,
> +   VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +   1, { 32, 0, 0 }, false, false, 1, 1, false },
> + { V4L2_PIX_FMT_BGRA1010102, MEDIA_BUS_FMT_ARGB_1X32,
> +   VI6_FMT_RGB10_RGB10A2_A2RGB10,
> +   VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +   1, { 32, 0, 0 }, false, false, 1, 1, false },
>   { V4L2_PIX_FMT_UYVY, MEDIA_BUS_FMT_AYUV8_1X32,
> VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> @@ -202,6 +214,9 @@ static const struct vsp1_format_info vsp1_video_formats[] 
> = {
> VI6_FMT_Y_U_V_444, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> 3, { 8, 8, 8 }, false, true, 1, 1, false },
> + { V4L2_PIX_FMT_Y210, MEDIA_BUS_FMT_AYUV8_1X32,
> +   VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> +   1, { 32, 0, 0 }, false, false, 2, 1, false },
>  };
>  
>  /**
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h 
> b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index c61e8dafeecf..8947ea05f95e 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -228,6 +228,27 @@
>  #define VI6_RPF_MULT_ALPHA_RATIO_MASK(0xff << 0)
>  #define VI6_RPF_MULT_ALPHA_RATIO_SHIFT   0
>  
> +#define VI6_RPF_EXT_INFMT0   0x0370
> +#define VI6_RPF_EXT_INFMT0_F2B_LSB   (0 << 12)
> +#define VI6_RPF_EXT_INFMT0_F2B_MSB   (1 << 12)

We don't normally define two macros for each bit. You can drop the
F2B_LSB macro, rename F2B_MSB to F2B, and use BIT(12).

> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_8  (0 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_10 (1 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_12 (2 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_8  (0 << 4)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_10 (1 << 4)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_12 (2 << 4)
> +#define VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10 (3 << 0)
> +#define VI6_RPF_EXT_INFMT0_BYPP_M1_N_RGB10   (0 << 0)

I would drop the last one as you don't use it.

> +
> +#define VI6_RPF_EXT_INFMT1   0x0374
> +#define VI6_RPF_EXT_INFMT2   0x0378
> +
> +#define VI6_RPF_BRDITH_CTRL  0x03e0
> +#define VI6_RPF_BRDITH_CTRL_ODE_EN   (1 << 8)
> +#define VI6_RPF_BRDITH_CTRL_ODE_DIS  (0 << 8)
> +#define VI6_RPF_BRDITH_CTRL_CBRM_RO  (1 << 0)
> +#define VI6_RPF_BRDITH_CTRL_CBRM_TR  (0 << 0)

Same here, one macro per bit.

The BRDITH_CTRL registers doesn't seem to be used. I don't mind adding
it though.

> +
>  /* 
> -
>   * WPF Control Registers
>   */
> @@ -846,6 +867,7 @@
>  #define VI6_FMT_XBXGXR_2626260x21
>  #define VI6_FMT_ABGR_0x22
>  #define VI6_FMT_XXRGB_88565  0x23
> +#define VI6_FMT_RGB10_RGB10A2_A2RGB100x30
>  
>  #define VI6_FMT_Y_UV_444 0x40
>  #define VI6_FMT_Y_UV_422 0x41
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c 
> b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> index 045aa54f7998..60ba3c62e86c 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> @@ -55,6 +55,11 @@ static const struct v4l2_subdev_ops rpf_ops = {
>   * VSP1 Entity Operations
>   */
>  
> +#define PACK_CPOS(a, b, c, d) \
> + (((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
> +#define PACK_CLEN(a, b, c, d) \
> + (((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
> +

Please move this to vsp1_regs.h, just 

Re: [PATCH v2 4/7] media: renesas: vsp1: Add V4H SoC version

2022-12-19 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:36PM +0200, Tomi Valkeinen wrote:
> Add VI6_IP_VERSION_SOC_V4H so that we can identify V4H SoC.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/renesas/vsp1/vsp1_regs.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h 
> b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index 8c9333f76858..c61e8dafeecf 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -782,6 +782,7 @@
>  #define VI6_IP_VERSION_SOC_M3N   (0x04 << 0)
>  #define VI6_IP_VERSION_SOC_E3(0x04 << 0)
>  #define VI6_IP_VERSION_SOC_V3U   (0x05 << 0)
> +#define VI6_IP_VERSION_SOC_V4H   (0x06 << 0)
>  /* RZ/G2L SoCs have no version register, So use 0x80 for SoC Identification 
> */
>  #define VI6_IP_VERSION_SOC_RZG2L (0x80 << 0)
>  

-- 
Regards,

Laurent Pinchart


Re: [PATCH v2 3/7] media: renesas: vsp1: Change V3U to be gen4

2022-12-19 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:35PM +0200, Tomi Valkeinen wrote:
> V3U is actually gen4, not gen3. The same IP is also used in the
> (not-yet-supported) V4H.
> 
> Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
> to represent the model correctly. V3U and V4H can still be
> differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
> 
> Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
> and update the code to correcly match for gen 4.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/media/platform/renesas/vsp1/vsp1_drv.c   |  4 ++--
>  drivers/media/platform/renesas/vsp1/vsp1_hgo.c   |  4 ++--
>  drivers/media/platform/renesas/vsp1/vsp1_lif.c   |  1 +
>  drivers/media/platform/renesas/vsp1/vsp1_regs.h  |  2 +-
>  drivers/media/platform/renesas/vsp1/vsp1_rpf.c   | 12 ++--
>  drivers/media/platform/renesas/vsp1/vsp1_video.c |  4 ++--
>  drivers/media/platform/renesas/vsp1/vsp1_wpf.c   |  4 ++--
>  7 files changed, 16 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c 
> b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> index c260d318d298..5710152d6511 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> @@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] 
> = {
>   .wpf_count = 2,
>   .num_bru_inputs = 5,
>   }, {
> - .version = VI6_IP_VERSION_MODEL_VSPD_V3U,
> + .version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
>   .model = "VSP2-D",
> - .gen = 3,
> + .gen = 4,
>   .features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
>   .lif_count = 1,
>   .rpf_count = 5,
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c 
> b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> index bf3f981f93a1..e6492deb0a64 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> @@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device 
> *vsp1)
>  
>   /* Initialize the control handler. */
>   v4l2_ctrl_handler_init(>ctrls.handler,
> -vsp1->info->gen == 3 ? 2 : 1);
> +vsp1->info->gen >= 3 ? 2 : 1);
>   hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(>ctrls.handler,
> _max_rgb_control, NULL);
> - if (vsp1->info->gen == 3)
> + if (vsp1->info->gen >= 3)
>   hgo->ctrls.num_bins =
>   v4l2_ctrl_new_custom(>ctrls.handler,
>_num_bins_control, NULL);
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c 
> b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> index 186a5730e1e3..0ab2e0c70474 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> @@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity 
> *entity,
>   break;
>  
>   case VI6_IP_VERSION_MODEL_VSPD_GEN3:
> + case VI6_IP_VERSION_MODEL_VSPD_GEN4:

While this doesn't cause any functional change, it doesn't fall into the
renaming explained in the commit message. I'd make a mention of it
there.

Conditional-Reviewed-by: Laurent Pinchart 


>   default:
>   hbth = 0;
>   obth = 3000;
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h 
> b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index 8928f4c6bb55..8c9333f76858 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -766,7 +766,7 @@
>  #define VI6_IP_VERSION_MODEL_VSPD_V3 (0x18 << 8)
>  #define VI6_IP_VERSION_MODEL_VSPDL_GEN3  (0x19 << 8)
>  #define VI6_IP_VERSION_MODEL_VSPBS_GEN3  (0x1a << 8)
> -#define VI6_IP_VERSION_MODEL_VSPD_V3U(0x1c << 8)
> +#define VI6_IP_VERSION_MODEL_VSPD_GEN4   (0x1c << 8)
>  /* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
>  #define VI6_IP_VERSION_MODEL_VSPD_RZG2L  (0x80 << 8)
>  
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c 
> b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> index 75083cb234fe..045aa54f7998 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> @@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity 
> *entity,
>* a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
>* otherwise.
>*
> -  * The Gen3 RPF has extended alpha capability and can both multiply the
> +  * The Gen3+ RPF has extended alpha capability and can both multiply the
>* alpha channel by a fixed global alpha value, and multiply the pixel
>* components to convert the input to 

Re: [PATCH] drm/tegra: sor: Remove redundant error logging

2022-12-19 Thread Deepak R Varma
On Mon, Dec 12, 2022 at 10:44:55AM +0530, Deepak R Varma wrote:

Hello,
May I please request a review and feedback on this patch proposal?

Also, I was able to build the changes for ARM arch verified using modinfo
tegr-drm.ko command.


Thank you,
./drv


> A call to platform_get_irq() already prints an error on failure within
> its own implementation. So printing another error based on its return
> value in the caller is redundant and should be removed. The clean up
> also makes if condition block braces unnecessary. Remove that as well.
>
> Issue identified using platform_get_irq.cocci coccicheck script.
>
> Signed-off-by: Deepak R Varma 
> ---
> Please note: I was not able to build this driver since I did not find the
> DRM_TEGRA option in menu config. All dependencies listed in the KConfig are
> enabled, however, I was still not able to find the DRM_TEGRA module in the
> Graphics-Drivers list. Since the proposed change is known, minor and obvious, 
> I
> am sending in this patch without build testing.
>
> Any advise on how to enable the DRM_TEGRA module in menuconfig selection list
> will be helpful. Thank you.
>
>
>  drivers/gpu/drm/tegra/sor.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index 8af632740673..ceaebd33408d 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -3799,10 +3799,8 @@ static int tegra_sor_probe(struct platform_device 
> *pdev)
>   }
>
>   err = platform_get_irq(pdev, 0);
> - if (err < 0) {
> - dev_err(>dev, "failed to get IRQ: %d\n", err);
> + if (err < 0)
>   goto remove;
> - }
>
>   sor->irq = err;
>
> --
> 2.34.1
>




Re: [PATCH] drm/sprd: remove redundant error logging

2022-12-19 Thread Deepak R Varma
On Sun, Dec 11, 2022 at 07:25:08PM +0530, Deepak R Varma wrote:

Hello,
May I please request a review and feedback on this patch proposal?

Thank you,
./drv

> A call to platform_get_irq() already prints an error on failure within
> its own implementation. So printing another error based on its return
> value in the caller is redundant and should be removed. The clean up
> also makes if condition block braces unnecessary. Remove that as well.
>
> Issue identified using platform_get_irq.cocci coccicheck script.
>
> Signed-off-by: Deepak R Varma 
> ---
>  drivers/gpu/drm/sprd/sprd_dpu.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c b/drivers/gpu/drm/sprd/sprd_dpu.c
> index 88f4259680f1..db0bcea1d9f4 100644
> --- a/drivers/gpu/drm/sprd/sprd_dpu.c
> +++ b/drivers/gpu/drm/sprd/sprd_dpu.c
> @@ -803,10 +803,8 @@ static int sprd_dpu_context_init(struct sprd_dpu *dpu,
>   }
>
>   ctx->irq = platform_get_irq(pdev, 0);
> - if (ctx->irq < 0) {
> - dev_err(dev, "failed to get dpu irq\n");
> + if (ctx->irq < 0)
>   return ctx->irq;
> - }
>
>   /* disable and clear interrupts before register dpu IRQ. */
>   writel(0x00, ctx->base + REG_DPU_INT_EN);
> --
> 2.34.1
>




Re: [PATCH] drm/fsl-dcu: Remove redundant error logging

2022-12-19 Thread Deepak R Varma
On Sun, Dec 11, 2022 at 03:57:47PM +0530, Deepak R Varma wrote:

Hello,
May I please request a review and feedback on this patch proposal?

Thank you,
./drv

> A call to platform_get_irq() already prints an error on failure within
> its own implementation. So printing another error based on its return
> value in the caller is redundant and should be removed. The clean up
> also makes if condition block braces unnecessary. Remove that as well.
>
> Issue identified using platform_get_irq.cocci coccicheck script.
>
> Signed-off-by: Deepak R Varma 
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> index 8579c7629f5e..1ba7d95e1956 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -272,10 +272,8 @@ static int fsl_dcu_drm_probe(struct platform_device 
> *pdev)
>   }
>
>   fsl_dev->irq = platform_get_irq(pdev, 0);
> - if (fsl_dev->irq < 0) {
> - dev_err(dev, "failed to get irq\n");
> + if (fsl_dev->irq < 0)
>   return fsl_dev->irq;
> - }
>
>   fsl_dev->regmap = devm_regmap_init_mmio(dev, base,
>   _dcu_regmap_config);
> --
> 2.34.1
>




Re: [PATCH v2 2/7] media: Add Y210, Y212 and Y216 formats

2022-12-19 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:34PM +0200, Tomi Valkeinen wrote:
> Add Y210, Y212 and Y216 formats.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  .../media/v4l/pixfmt-packed-yuv.rst   | 44 +++
>  drivers/media/v4l2-core/v4l2-ioctl.c  |  3 ++
>  include/uapi/linux/videodev2.h|  8 
>  3 files changed, 55 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst 
> b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> index bf283a1b5581..3f193e5fd5cb 100644
> --- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> +++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> @@ -337,6 +337,50 @@ components horizontally by 2, storing 2 pixels in 4 
> bytes.

I would patch the above sentence to mention that it applies to 8 bit
formats.

>- Y'\ :sub:`3`
>- Cb\ :sub:`2`
>  
> +The packed YUYV formats with more than 8 bits per component are stored as 
> four
> +16-bit little-endian words. Each word's most significat bits contain one

s/significat/significant/

> +component, and the least significant bits are zero padding.
> +
> +.. tabularcolumns:: 
> |p{3.4cm}|p{1.2cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
> +
> +.. flat-table:: Packed YUV 4:2:2 Formats in 64-bit container
> +:header-rows: 1
> +:stub-columns: 0
> +
> +* - Identifier
> +  - Code
> +  - Word 0
> +  - Word 1
> +  - Word 2
> +  - Word 3
> +* .. _V4L2-PIX-FMT-Y210:
> +
> +  - ``V4L2_PIX_FMT_Y210``
> +  - 'Y210'
> +
> +  - Y'\ :sub:`0` (bits 15-6)
> +  - Cb\ :sub:`0` (bits 15-6)
> +  - Y'\ :sub:`1` (bits 15-6)
> +  - Cr\ :sub:`0` (bits 15-6)
> +* .. _V4L2-PIX-FMT-Y212:
> +
> +  - ``V4L2_PIX_FMT_Y212``
> +  - 'Y212'
> +
> +  - Y'\ :sub:`0` (bits 15-4)
> +  - Cb\ :sub:`0` (bits 15-4)
> +  - Y'\ :sub:`1` (bits 15-4)
> +  - Cr\ :sub:`0` (bits 15-4)
> +* .. _V4L2-PIX-FMT-Y216:
> +
> +  - ``V4L2_PIX_FMT_Y216``
> +  - 'Y216'
> +
> +  - Y'\ :sub:`0` (bits 15-0)
> +  - Cb\ :sub:`0` (bits 15-0)
> +  - Y'\ :sub:`1` (bits 15-0)
> +  - Cr\ :sub:`0` (bits 15-0)
> +
>  .. raw:: latex
>  
>  \normalsize
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 964300deaf62..ba95389a59b5 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1449,6 +1449,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>   case V4L2_META_FMT_RK_ISP1_STAT_3A: descr = "Rockchip ISP1 3A 
> Statistics"; break;
>   case V4L2_PIX_FMT_NV12M_8L128:  descr = "NV12M (8x128 Linear)"; break;
>   case V4L2_PIX_FMT_NV12M_10BE_8L128: descr = "10-bit NV12M (8x128 
> Linear, BE)"; break;
> + case V4L2_PIX_FMT_Y210: descr = "10-bit YUYV Packed"; break;
> + case V4L2_PIX_FMT_Y212: descr = "12-bit YUYV Packed"; break;
> + case V4L2_PIX_FMT_Y216: descr = "16-bit YUYV Packed"; break;

While the names will not play nicely with future formats that would swap
the order of the Y, U and V components, they match the formats defined
by DRM, which I think is more important.

With the above small issues fixed,

Conditionally-Reviewed-by: Laurent Pinchart 


>  
>   default:
>   /* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 877fd61693b8..15b640d2da8a 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -621,6 +621,14 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_YUVX32  v4l2_fourcc('Y', 'U', 'V', 'X') /* 32  
> YUVX-8-8-8-8  */
>  #define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 
> 4:2:0 2 lines y, 1 line uv interleaved */
>  
> +/*
> + * YCbCr packed format. For each Y2xx format, xx bits of valid data occupy 
> the MSBs
> + * of the 16 bit components, and 16-xx bits of zero padding occupy the LSBs.
> + */
> +#define V4L2_PIX_FMT_Y210v4l2_fourcc('Y', '2', '1', '0') /* 32  YUYV 
> 4:2:2 */
> +#define V4L2_PIX_FMT_Y212v4l2_fourcc('Y', '2', '1', '2') /* 32  YUYV 
> 4:2:2 */
> +#define V4L2_PIX_FMT_Y216v4l2_fourcc('Y', '2', '1', '6') /* 32  YUYV 
> 4:2:2 */
> +
>  /* two planes -- one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 
> 4:2:0  */
>  #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1') /* 12  Y/CrCb 
> 4:2:0  */

-- 
Regards,

Laurent Pinchart


[PATCH v3 1/2] drm/panel: add the orisetech ota5601a

2022-12-19 Thread Christophe Branchereau
Add the orisetech ota5601a ic driver

For now it only supports the focaltech gpt3 3" 640x480 ips panel
found in the ylm rg300x handheld.

Signed-off-by: Christophe Branchereau 
---
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-orisetech-ota5601a.c  | 364 ++
 3 files changed, 374 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-orisetech-ota5601a.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 737edcdf9eef..114758f64d26 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -400,6 +400,15 @@ config DRM_PANEL_OLIMEX_LCD_OLINUXINO
  Say Y here if you want to enable support for Olimex Ltd.
  LCD-OLinuXino panel.
 
+config DRM_PANEL_ORISETECH_OTA5601A
+tristate "Orise Technology ota5601a RGB/SPI panel"
+depends on SPI
+depends on BACKLIGHT_CLASS_DEVICE
+select REGMAP_SPI
+help
+  Say Y here if you want to enable support for the panels built
+  around the Orise Technology OTA9601A display controller.
+
 config DRM_PANEL_ORISETECH_OTM8009A
tristate "Orise Technology otm8009a 480x800 dsi 2dl panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f8f9d9f6a307..ddcf8df889c8 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += 
panel-novatek-nt36672a.o
 obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
 obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
 obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
+obj-$(CONFIG_DRM_PANEL_ORISETECH_OTA5601A) += panel-orisetech-ota5601a.o
 obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
 obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c 
b/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
new file mode 100644
index ..b40a641f1d67
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
@@ -0,0 +1,364 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Orisetech OTA5601A TFT LCD panel driver
+ *
+ * Copyright (C) 2021, Christophe Branchereau 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define OTA5601A_CTL 0x01
+#define OTA5601A_CTL_OFF 0x00
+#define OTA5601A_CTL_ON BIT(0)
+
+struct ota5601a_panel_info {
+   const struct drm_display_mode *display_modes;
+   unsigned int num_modes;
+   u16 width_mm, height_mm;
+   u32 bus_format, bus_flags;
+};
+
+struct ota5601a {
+   struct drm_panel drm_panel;
+   struct regmap *map;
+   struct regulator *supply;
+   const struct ota5601a_panel_info *panel_info;
+
+   struct gpio_desc *reset_gpio;
+};
+
+static inline struct ota5601a *to_ota5601a(struct drm_panel *panel)
+{
+   return container_of(panel, struct ota5601a, drm_panel);
+}
+
+static const struct reg_sequence ota5601a_panel_regs[] = {
+   { 0xfd, 0x00 }, /* Page Shift */
+   { 0x02, 0x00 }, /* Reset */
+
+   { 0x18, 0x00 }, /* Interface Sel: RGB 24 Bits */
+   { 0x34, 0x20 }, /* Undocumented */
+
+   { 0x0c, 0x01 }, /* Contrast set by CMD1 == within page 0x00 */
+   { 0x0d, 0x48 }, /* R Brightness */
+   { 0x0e, 0x48 }, /* G Brightness */
+   { 0x0f, 0x48 }, /* B Brightness */
+   { 0x07, 0x40 }, /* R Contrast */
+   { 0x08, 0x33 }, /* G Contrast */
+   { 0x09, 0x3a }, /* B Contrast */
+
+   { 0x16, 0x01 }, /* NTSC Sel */
+   { 0x19, 0x8d }, /* VBLK */
+   { 0x1a, 0x28 }, /* HBLK */
+   { 0x1c, 0x00 }, /* Scan Shift Dir. */
+
+   { 0xfd, 0xc5 }, /* Page Shift */
+   { 0x82, 0x0c }, /* PWR_CTRL Pump */
+   { 0xa2, 0xb4 }, /* PWR_CTRL VGH/VGL */
+
+   { 0xfd, 0xc4 }, /* Page Shift - What follows is listed as "RGB 24bit 
Timing Set" */
+   { 0x82, 0x45 },
+
+   { 0xfd, 0xc1 },
+   { 0x91, 0x02 },
+
+   { 0xfd, 0xc0 },
+   { 0xa1, 0x01 },
+   { 0xa2, 0x1f },
+   { 0xa3, 0x0b },
+   { 0xa4, 0x38 },
+   { 0xa5, 0x00 },
+   { 0xa6, 0x0a },
+   { 0xa7, 0x38 },
+   { 0xa8, 0x00 },
+   { 0xa9, 0x0a },
+   { 0xaa, 0x37 },
+
+   { 0xfd, 0xce },
+   { 0x81, 0x18 },
+   { 0x82, 0x43 },
+   { 0x83, 0x43 },
+   { 0x91, 0x06 },
+   { 0x93, 0x38 },
+   { 0x94, 0x02 },
+   { 0x95, 0x06 },
+   { 0x97, 0x38 },
+   { 0x98, 0x02 },
+   { 0x99, 0x06 },
+   { 0x9b, 0x38 },
+   { 0x9c, 0x02 },
+
+   { 0xfd, 0x00 }, /* Page Shift */
+};
+
+static const struct regmap_config ota5601a_regmap_config = {

[PATCH v3 2/2] dt-bindings: display/panel: Add the Focaltech gpt3

2022-12-19 Thread Christophe Branchereau
Add bindings for the Forcaltech gpt3, which is a 640x480 3.0" 4:3
IPS LCD Panel found in the YLM/Anbernic RG300X handheld.

Signed-off-by: Christophe Branchereau 
Reviewed-by: Krzysztof Kozlowski 
---
 .../display/panel/focaltech,gpt3.yaml | 56 +++
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml 
b/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
new file mode 100644
index ..d54e96b2a9e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/focaltech,gpt3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Focaltech GPT3 3.0" (640x480 pixels) IPS LCD panel
+
+maintainers:
+  - Christophe Branchereau 
+
+allOf:
+  - $ref: panel-common.yaml#
+  - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+  compatible:
+const: focaltech,gpt3
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - power-supply
+  - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "focaltech,gpt3";
+reg = <0>;
+
+spi-max-frequency = <3125000>;
+
+reset-gpios = < 2 GPIO_ACTIVE_LOW>;
+
+backlight = <>;
+power-supply = <>;
+
+port {
+panel_input: endpoint {
+remote-endpoint = <_output>;
+};
+};
+};
+};
-- 
2.35.1



[PATCH v3 0/2] Add support for the orisetech ota5601

2022-12-19 Thread Christophe Branchereau
Changes since v2:
 - Documented the registers to the best of my knowledge
 - Used macros for on/off panel registers
 - Added SPI id_table (non-requested change, fixes a warning in dmesg)

---
Changes since v1:
 - fixed the dt-bindings maintainer email adress
 - dropped backlight, port, power-supply and reset-gpios as they're
   provided by panel-common.yaml as pointed by Krzysztof Kozlowski
 - changed reg: true to reg : maxItems: 1

Christophe Branchereau (2):
  drm/panel: add the orisetech ota5601a
  dt-bindings: display/panel: Add the Focaltech gpt3

 .../display/panel/focaltech,gpt3.yaml |  56 +++
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-orisetech-ota5601a.c  | 364 ++
 4 files changed, 430 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
 create mode 100644 drivers/gpu/drm/panel/panel-orisetech-ota5601a.c

-- 
2.35.1



Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats

2022-12-19 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  .../userspace-api/media/v4l/pixfmt-rgb.rst| 194 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c  |   3 +
>  include/uapi/linux/videodev2.h|   3 +
>  3 files changed, 200 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst 
> b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> index 30f51cd33f99..de78cd2dcd73 100644
> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components 
> as seen in a 24- or
>  \normalsize
>  
>  
> +10 Bits Per Component
> +=
> +
> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
> +bytes. They are named based on the order of the RGB components as seen in a
> +32-bit word, which is then stored in memory in little endian byte order
> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on 
> the
> +number of bits for each component.
> +
> +.. raw:: latex
> +
> +\begingroup
> +\tiny
> +\setlength{\tabcolsep}{2pt}
> +
> +.. tabularcolumns:: 
> |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
> +
> +
> +.. flat-table:: RGB Formats 10 Bits Per Color Component
> +:header-rows:  2
> +:stub-columns: 0
> +
> +* - Identifier
> +  - Code
> +  - :cspan:`7` Byte 0 in memory
> +  - :cspan:`7` Byte 1
> +  - :cspan:`7` Byte 2
> +  - :cspan:`7` Byte 3
> +* -
> +  -
> +  - 7
> +  - 6
> +  - 5
> +  - 4
> +  - 3
> +  - 2
> +  - 1
> +  - 0
> +
> +  - 7
> +  - 6
> +  - 5
> +  - 4
> +  - 3
> +  - 2
> +  - 1
> +  - 0
> +
> +  - 7
> +  - 6
> +  - 5
> +  - 4
> +  - 3
> +  - 2
> +  - 1
> +  - 0
> +
> +  - 7
> +  - 6
> +  - 5
> +  - 4
> +  - 3
> +  - 2
> +  - 1
> +  - 0
> +* .. _V4L2-PIX-FMT-XBGR2101010:
> +
> +  - ``V4L2_PIX_FMT_XBGR2101010``
> +  - 'RX30'
> +
> +  - b\ :sub:`5`
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - x
> +  - x
> +
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - b\ :sub:`9`
> +  - b\ :sub:`8`
> +  - b\ :sub:`7`
> +  - b\ :sub:`6`
> +
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - g\ :sub:`9`
> +  - g\ :sub:`8`
> +  - g\ :sub:`7`
> +  - g\ :sub:`6`
> +  - g\ :sub:`5`
> +  - g\ :sub:`4`
> +
> +  - r\ :sub:`9`
> +  - r\ :sub:`8`
> +  - r\ :sub:`7`
> +  - r\ :sub:`6`
> +  - r\ :sub:`5`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  -

This doesn't match the text above. This would be RGBX2101010. I'm not
sure which format you want, so I don't know if it's the documentation or
the format name that is incorrect. The next two formats also seem
incorrect to me.

> +* .. _V4L2-PIX-FMT-ABGR2101010:
> +
> +  - ``V4L2_PIX_FMT_ABGR2101010``
> +  - 'RA30'
> +
> +  - b\ :sub:`5`
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - a\ :sub:`1`
> +  - a\ :sub:`0`
> +
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - b\ :sub:`9`
> +  - b\ :sub:`8`
> +  - b\ :sub:`7`
> +  - b\ :sub:`6`
> +
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - g\ :sub:`9`
> +  - g\ :sub:`8`
> +  - g\ :sub:`7`
> +  - g\ :sub:`6`
> +  - g\ :sub:`5`
> +  - g\ :sub:`4`
> +
> +  - r\ :sub:`9`
> +  - r\ :sub:`8`
> +  - r\ :sub:`7`
> +  - r\ :sub:`6`
> +  - r\ :sub:`5`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  -
> +* .. _V4L2-PIX-FMT-BGRA1010102:
> +
> +  - ``V4L2_PIX_FMT_BGRA1010102``
> +  - 'AR30'
> +
> +  - b\ :sub:`7`
> +  - b\ :sub:`6`
> +  - b\ :sub:`5`
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +
> +  - g\ :sub:`5`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - b\ :sub:`9`
> +  - b\ :sub:`8`
> +
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - g\ :sub:`9`
> +  - 

[PATCH] drm/drv: Make use of local variable driver in drm_dev_register()

2022-12-19 Thread Uwe Kleine-König
There is a local variable that contains dev->driver. Make use of it
instead of "open coding" it.

Signed-off-by: Uwe Kleine-König 
---
 drivers/gpu/drm/drm_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 203bf8d6c34c..3cc8e8111d16 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -889,8 +889,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
 
dev->registered = true;
 
-   if (dev->driver->load) {
-   ret = dev->driver->load(dev, flags);
+   if (driver->load) {
+   ret = driver->load(dev, flags);
if (ret)
goto err_minors;
}

base-commit: 678e5b2258e871b22fe8c26edac2723feb852a47
-- 
2.38.1



Re: [PATCH] drm/panfrost: Fix GEM handle creation ref-counting

2022-12-19 Thread Rob Clark
On Mon, Dec 19, 2022 at 6:02 AM Steven Price  wrote:
>
> panfrost_gem_create_with_handle() previously returned a BO but with the
> only reference being from the handle, which user space could in theory
> guess and release, causing a use-after-free. Additionally if the call to
> panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then
> a(nother) reference on the BO was dropped.
>
> The _create_with_handle() is a problematic pattern, so ditch it and
> instead create the handle in panfrost_ioctl_create_bo(). If the call to
> panfrost_gem_mapping_get() fails then this means that user space has
> indeed gone behind our back and freed the handle. In which case just
> return an error code.
>
> Reported-by: Rob Clark 

Yeah, I like getting rid of the _create_with_handle() pattern, the
only place where that pattern works is if you immediately return the
handle to userspace (and don't otherwise touch the obj)

Reviewed-by: Rob Clark 

> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Signed-off-by: Steven Price 
> ---
>  drivers/gpu/drm/panfrost/panfrost_drv.c | 27 -
>  drivers/gpu/drm/panfrost/panfrost_gem.c | 16 +--
>  drivers/gpu/drm/panfrost/panfrost_gem.h |  5 +
>  3 files changed, 20 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index fa619fe72086..abb0dadd8f63 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -82,6 +82,7 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev, 
> void *data,
> struct panfrost_gem_object *bo;
> struct drm_panfrost_create_bo *args = data;
> struct panfrost_gem_mapping *mapping;
> +   int ret;
>
> if (!args->size || args->pad ||
> (args->flags & ~(PANFROST_BO_NOEXEC | PANFROST_BO_HEAP)))
> @@ -92,21 +93,29 @@ static int panfrost_ioctl_create_bo(struct drm_device 
> *dev, void *data,
> !(args->flags & PANFROST_BO_NOEXEC))
> return -EINVAL;
>
> -   bo = panfrost_gem_create_with_handle(file, dev, args->size, 
> args->flags,
> ->handle);
> +   bo = panfrost_gem_create(dev, args->size, args->flags);
> if (IS_ERR(bo))
> return PTR_ERR(bo);
>
> +   ret = drm_gem_handle_create(file, >base.base, >handle);
> +   if (ret)
> +   goto out;
> +
> mapping = panfrost_gem_mapping_get(bo, priv);
> -   if (!mapping) {
> -   drm_gem_object_put(>base.base);
> -   return -EINVAL;
> +   if (mapping) {
> +   args->offset = mapping->mmnode.start << PAGE_SHIFT;
> +   panfrost_gem_mapping_put(mapping);
> +   } else {
> +   /* This can only happen if the handle from
> +* drm_gem_handle_create() has already been guessed and freed
> +* by user space
> +*/
> +   ret = -EINVAL;
> }
>
> -   args->offset = mapping->mmnode.start << PAGE_SHIFT;
> -   panfrost_gem_mapping_put(mapping);
> -
> -   return 0;
> +out:
> +   drm_gem_object_put(>base.base);
> +   return ret;
>  }
>
>  /**
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c 
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 293e799e2fe8..3c812fbd126f 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -235,12 +235,8 @@ struct drm_gem_object *panfrost_gem_create_object(struct 
> drm_device *dev, size_t
>  }
>
>  struct panfrost_gem_object *
> -panfrost_gem_create_with_handle(struct drm_file *file_priv,
> -   struct drm_device *dev, size_t size,
> -   u32 flags,
> -   uint32_t *handle)
> +panfrost_gem_create(struct drm_device *dev, size_t size, u32 flags)
>  {
> -   int ret;
> struct drm_gem_shmem_object *shmem;
> struct panfrost_gem_object *bo;
>
> @@ -256,16 +252,6 @@ panfrost_gem_create_with_handle(struct drm_file 
> *file_priv,
> bo->noexec = !!(flags & PANFROST_BO_NOEXEC);
> bo->is_heap = !!(flags & PANFROST_BO_HEAP);
>
> -   /*
> -* Allocate an id of idr table where the obj is registered
> -* and handle has the id what user can see.
> -*/
> -   ret = drm_gem_handle_create(file_priv, >base, handle);
> -   /* drop reference from allocate - handle holds it now. */
> -   drm_gem_object_put(>base);
> -   if (ret)
> -   return ERR_PTR(ret);
> -
> return bo;
>  }
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h 
> b/drivers/gpu/drm/panfrost/panfrost_gem.h
> index 8088d5fd8480..ad2877eeeccd 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
> @@ -69,10 +69,7 @@ panfrost_gem_prime_import_sg_table(struct 

[PATCH v4 5/5] arm64: dts: rockchip: px30: add lvds_out node

2022-12-19 Thread Johan Jonker
With the conversion of rockchip,lvds.yaml a port@1 node
is required, so add a node with label lvds_out.

Signed-off-by: Johan Jonker 
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi 
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index bfa358042..eb414d0f8 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -468,6 +468,10 @@
remote-endpoint = 
<_out_lvds>;
};
};
+
+   lvds_out: port@1 {
+   reg = <1>;
+   };
};
};
};
--
2.20.1



[PATCH v4 4/5] ARM: dts: rockchip: rk3288: add lvds_out node

2022-12-19 Thread Johan Jonker
With the conversion of rockchip,lvds.yaml a port@1 node
is required, so add a node with label lvds_out.

Signed-off-by: Johan Jonker 
---
 arch/arm/boot/dts/rk3288.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 487b0e03d..60207136f 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1170,6 +1170,10 @@
remote-endpoint = <_out_lvds>;
};
};
+
+   lvds_out: port@1 {
+   reg = <1>;
+   };
};
};

--
2.20.1



[PATCH v4 3/5] dt-bindings: phy: add port node to phy-rockchip-inno-usb2.yaml

2022-12-19 Thread Johan Jonker
On Rockchip rk3399 a port node with one endpoint can be connected
to a USB Type-C connector node.
Add a port node to the phy-rockchip-inno-usb2.yaml file.

Signed-off-by: Johan Jonker 
---
 .../devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml  | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml 
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml
index f71920082..ffc7e7560 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml
@@ -115,6 +115,11 @@ properties:
 required:
   - "#phy-cells"

+  port:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Port node with one endpoint connected to a USB Type-C connector node.
+
 required:
   - compatible
   - reg
--
2.20.1



[PATCH v4 2/5] dt-bindings: soc: rockchip: grf: add rockchip,lvds.yaml

2022-12-19 Thread Johan Jonker
Add new converted rockchip,lvds.yaml to grf.yaml file.
Prepare for more SoCs with lvds output.

Signed-off-by: Johan Jonker 
---
 .../devicetree/bindings/soc/rockchip/grf.yaml  | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml 
b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index 2ed8cca79..d74295e98 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -75,13 +75,17 @@ allOf:
   properties:
 compatible:
   contains:
-const: rockchip,px30-grf
+enum:
+  - rockchip,px30-grf

 then:
   properties:
 lvds:
-  description:
-
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
+  type: object
+
+  $ref: "/schemas/display/rockchip/rockchip,lvds.yaml#"
+
+  unevaluatedProperties: false

   - if:
   properties:
--
2.20.1



[PATCH v4 1/5] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML

2022-12-19 Thread Johan Jonker
Convert rockchip-lvds.txt to YAML.

Changed:
  Add power-domains property.
  Requirements between PX30 and RK3288

Signed-off-by: Johan Jonker 
---

Changed V3:
  Filename matching compatible style
  Drop "Regulator phandle for "
  Specify properties and requirements per SoC
  Sort order and restyle

Changed V2:
  Fix title
---
 .../display/rockchip/rockchip,lvds.yaml   | 170 ++
 .../display/rockchip/rockchip-lvds.txt|  92 --
 2 files changed, 170 insertions(+), 92 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
 delete mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
new file mode 100644
index 0..03b002a05
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip low-voltage differential signal (LVDS) transmitter
+
+maintainers:
+  - Sandy Huang 
+  - Heiko Stuebner 
+
+properties:
+  compatible:
+enum:
+  - rockchip,px30-lvds
+  - rockchip,rk3288-lvds
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: pclk_lvds
+
+  avdd1v0-supply:
+description: 1.0V analog power.
+
+  avdd1v8-supply:
+description: 1.8V analog power.
+
+  avdd3v3-supply:
+description: 3.3V analog power.
+
+  rockchip,grf:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: Phandle to the general register files syscon.
+
+  rockchip,output:
+$ref: /schemas/types.yaml#/definitions/string
+enum: [rgb, lvds, duallvds]
+description: This describes the output interface.
+
+  phys:
+maxItems: 1
+
+  phy-names:
+const: dphy
+
+  pinctrl-names:
+const: lcdc
+
+  pinctrl-0: true
+
+  power-domains:
+maxItems: 1
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Video port 0 for the VOP input.
+  The remote endpoint maybe vopb or vopl.
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Video port 1 for either a panel or subsequent encoder.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - rockchip,grf
+  - rockchip,output
+  - ports
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: rockchip,px30-lvds
+
+then:
+  properties:
+reg: false
+clocks: false
+clock-names: false
+avdd1v0-supply: false
+avdd1v8-supply: false
+avdd3v3-supply: false
+
+  required:
+- phys
+- phy-names
+
+  - if:
+  properties:
+compatible:
+  contains:
+const: rockchip,rk3288-lvds
+
+then:
+  properties:
+phys: false
+phy-names: false
+
+  required:
+- reg
+- clocks
+- clock-names
+- avdd1v0-supply
+- avdd1v8-supply
+- avdd3v3-supply
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+lvds: lvds@ff96c000 {
+  compatible = "rockchip,rk3288-lvds";
+  reg = <0xff96c000 0x4000>;
+  clocks = < PCLK_LVDS_PHY>;
+  clock-names = "pclk_lvds";
+  avdd1v0-supply = <_lcd>;
+  avdd1v8-supply = <_lcd>;
+  avdd3v3-supply = <_33>;
+  pinctrl-names = "lcdc";
+  pinctrl-0 = <_ctl>;
+  rockchip,grf = <>;
+  rockchip,output = "rgb";
+
+  ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lvds_in: port@0 {
+  reg = <0>;
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  lvds_in_vopb: endpoint@0 {
+reg = <0>;
+remote-endpoint = <_out_lvds>;
+  };
+  lvds_in_vopl: endpoint@1 {
+reg = <1>;
+remote-endpoint = <_out_lvds>;
+  };
+};
+
+lvds_out: port@1 {
+  reg = <1>;
+
+  lvds_out_panel: endpoint {
+remote-endpoint = <_in_lvds>;
+  };
+};
+  };
+};
diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
deleted file mode 100644
index aaf8c44cf..0
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-Rockchip RK3288 LVDS interface
-
-
-Required properties:
-- compatible: matching the soc type, one of
-   - "rockchip,rk3288-lvds";
-   - "rockchip,px30-lvds";
-

Re: [PATCH v3 05/11] drm/msm: Add support for SM8350

2022-12-19 Thread Robert Foss
On Thu, 8 Dec 2022 at 00:50, Dmitry Baryshkov
 wrote:
>
> On 05/12/2022 18:37, Robert Foss wrote:
> > Add compatibles string, "qcom,sm8350-mdss", for the multimedia display
> > subsystem unit used on Qualcomm SM8350 platform.
> >
> > Signed-off-by: Robert Foss 
> > ---
> >   drivers/gpu/drm/msm/msm_mdss.c | 4 
> >   1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> > index a2264fb517a1..39746b972cdd 100644
> > --- a/drivers/gpu/drm/msm/msm_mdss.c
> > +++ b/drivers/gpu/drm/msm/msm_mdss.c
> > @@ -293,6 +293,9 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
> >   /* UBWC_2_0 */
> >   msm_mdss_setup_ubwc_dec_20(msm_mdss, 0x1e);
> >   break;
> > + case DPU_HW_VER_700:
> > + msm_mdss_setup_ubwc_dec_40(msm_mdss, UBWC_4_0, 6, 1, 1, 1);
> > + break;
>
> Judging from the vendor kernel, the highest_rank_bit is 3, with usual
> todo for 2 for LP_DDR4.

Thanks! Will fix.

>
> >   case DPU_HW_VER_720:
> >   msm_mdss_setup_ubwc_dec_40(msm_mdss, UBWC_3_0, 6, 1, 1, 1);
> >   break;
> > @@ -530,6 +533,7 @@ static const struct of_device_id mdss_dt_match[] = {
> >   { .compatible = "qcom,sc8180x-mdss" },
> >   { .compatible = "qcom,sm8150-mdss" },
> >   { .compatible = "qcom,sm8250-mdss" },
> > + { .compatible = "qcom,sm8350-mdss" },
> >   { .compatible = "qcom,sm8450-mdss" },
> >   {}
> >   };
>
> --
> With best wishes
> Dmitry
>


Re: [PATCH v3 08/11] arm64: dts: qcom: sm8350: Use 2 interconnect cells

2022-12-19 Thread Robert Foss
On Mon, 5 Dec 2022 at 20:19, Georgi Djakov  wrote:
>
> Hi Robert,
>
> On 5.12.22 18:37, Robert Foss wrote:
> > Use two interconnect cells in order to optionally
> > support a path tag.
> >
> > Signed-off-by: Robert Foss 
> > Reviewed-by: Konrad Dybcio 
> > ---
> >   arch/arm64/boot/dts/qcom/sm8350.dtsi | 28 ++--
> >   1 file changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi 
> > b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> > index 805d53d91952..434f8e8b12c1 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> > @@ -1543,56 +1543,56 @@ apps_smmu: iommu@1500 {
> >   config_noc: interconnect@150 {
> >   compatible = "qcom,sm8350-config-noc";
> >   reg = <0 0x0150 0 0xa580>;
> > - #interconnect-cells = <1>;
> > + #interconnect-cells = <2>;
> >   qcom,bcm-voters = <_bcm_voter>;
> >   };
> >
> >   mc_virt: interconnect@158 {
> >   compatible = "qcom,sm8350-mc-virt";
> >   reg = <0 0x0158 0 0x1000>;
> > - #interconnect-cells = <1>;
> > + #interconnect-cells = <2>;
> >   qcom,bcm-voters = <_bcm_voter>;
> >   };
> [..]
> > @@ -1620,8 +1620,8 @@ ipa: ipa@1e4 {
> >   clocks = < RPMH_IPA_CLK>;
> >   clock-names = "core";
> >
> > - interconnects = <_noc MASTER_IPA _virt 
> > SLAVE_EBI1>,
> > - <_noc MASTER_APPSS_PROC 
> > _noc SLAVE_IPA_CFG>;
> > + interconnects = <_noc MASTER_IPA 0 _virt 
> > SLAVE_EBI1 0>,
> > + <_noc MASTER_APPSS_PROC 0 
> > _noc SLAVE_IPA_CFG 0>;
> >   interconnect-names = "memory",
> >"config";
> >
> > @@ -1661,7 +1661,7 @@ mpss: remoteproc@408 {
> >   < SM8350_MSS>;
> >   power-domain-names = "cx", "mss";
> >
> > - interconnects = <_virt MASTER_LLCC _virt 
> > SLAVE_EBI1>;
> > + interconnects = <_virt MASTER_LLCC _virt 
> > SLAVE_EBI1 0>;
>
> The second cell for the first endpoint is missing, so this should be:
> interconnects = <_virt MASTER_LLCC 0 _virt SLAVE_EBI1 0>;

Nice catch, thanks!

>
> Thanks,
> Georgi
>
> >
> >   memory-region = <_modem_mem>;
> >
> > @@ -2239,7 +2239,7 @@ cdsp: remoteproc@9890 {
> >   < SM8350_MXC>;
> >   power-domain-names = "cx", "mxc";
> >
> > - interconnects = <_noc MASTER_CDSP_PROC 
> > _virt SLAVE_EBI1>;
> > + interconnects = <_noc MASTER_CDSP_PROC 0 
> > _virt SLAVE_EBI1 0>;
> >
> >   memory-region = <_cdsp_mem>;
> >
> > @@ -2421,14 +2421,14 @@ usb_2_ssphy: phy@88ebe00 {
> >   dc_noc: interconnect@90c {
> >   compatible = "qcom,sm8350-dc-noc";
> >   reg = <0 0x090c 0 0x4200>;
> > - #interconnect-cells = <1>;
> > + #interconnect-cells = <2>;
> >   qcom,bcm-voters = <_bcm_voter>;
> >   };
> >
> >   gem_noc: interconnect@910 {
> >   compatible = "qcom,sm8350-gem-noc";
> >   reg = <0 0x0910 0 0xb4000>;
> > - #interconnect-cells = <1>;
> > + #interconnect-cells = <2>;
> >   qcom,bcm-voters = <_bcm_voter>;
> >   };
> >
>


Re: [PATCH] drm: Replace DRM_INFO() with pr_info()

2022-12-19 Thread Thomas Zimmermann

Hi

Am 19.12.22 um 16:34 schrieb Siddh Raman Pant:

On Mon, 19 Dec 2022 20:27:45 +0530, Thomas Zimmermann wrote:

Hi

Am 19.12.22 um 15:23 schrieb Siddh Raman Pant:

Line 536 of drm_print.h says DRM_INFO() is deprecated
in favor of pr_info().


That's a misleading comment. DRM_INFO() is deprecated for drm_info().
pr_info() et al is only to be used of you don't have a dev pointer.

Best regards
Thomas


Maybe you are confusing it with DRM_DEV_INFO? It takes the dev pointer,
and is indeed told to be deprecated in favour of drm_info() in the
comments (see line 394).

DRM_INFO is a separate macro for printing stuff, and does not take the
dev pointer. They seem to be early wrappers for printk, I guess when
pr_info did not exist. And all they do different from pr_info is to add
DRM_NAME (which seems to be just "drm") in front of the string.


The DRM_ print macros in capital letters are deprecated AFAIK. In cases 
where a dev pointer is available, using drm_info() et al. is preferred 
over pr_info().


In the context of your patch, you should use drm_info() in 
drm_client_target_cloned(), as is gets a dev pointer as its first 
argument. In most the other cases from your patch, you can get the dev 
pointer from connector->dev.


The final case, drm_legacy_pci_exit(), there's no dev pointer, so you 
can use pr_info() there. I'd remove '[drm]' from the string. We don't 
use this much elsewhere.


Best regards
Thomas



Thanks,
Siddh


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH v3 10/11] arm64: dts: qcom: sm8350-hdk: Enable display & dsi nodes

2022-12-19 Thread Robert Foss
On Mon, 5 Dec 2022 at 17:44, Dmitry Baryshkov
 wrote:
>
> On 05/12/2022 18:37, Robert Foss wrote:
> > Enable the display subsystem and the dsi0 output for
> > the sm8350-hdk board.
> >
> > Signed-off-by: Robert Foss 
> > ---
> >   arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 22 ++
> >   1 file changed, 22 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts 
> > b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> > index e6deb08c6da0..39462c659c58 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> > +++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> > @@ -213,10 +213,32 @@  {
> >   firmware-name = "qcom/sm8350/cdsp.mbn";
> >   };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
>
> Bjorn suggested using mdss_dsi0 / mdss_dsi0_phy labels for DSI host and
> PHY, as it allows us to group them nicely. WDYT?

Sounds quite reasonable, fixing it in dts/dtsi/binding.

>
> > + vdda-supply = <_l6b_1p2>;
> > + status = "okay";
> > +};
> > +
> > +_phy  {
> > + vdds-supply = <_l5b_0p88>;
> > + status = "okay";
> > +};
> > +
> >   _dma1 {
> >   status = "okay";
> >   };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > +_mdp {
> > + status = "okay";
> > +};
> > +
> >{
> >   status = "okay";
> >   firmware-name = "qcom/sm8350/modem.mbn";
>
> --
> With best wishes
> Dmitry
>


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate TLB invalidation flow

2022-12-19 Thread Andrzej Hajda

On 19.12.2022 11:13, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

As the logic for selecting the register and corresponsing values grew, the


corresponding


code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during each and every TLB
invalidation.

v2:
  * Fail engine probe if TLB invlidations registers are unknown.

Signed-off-by: Tvrtko Ursulin 
Cc: Andrzej Hajda 
Cc: Matt Roper 
Reviewed-by: Andrzej Hajda  # v1
---
  drivers/gpu/drm/i915/gt/intel_engine_cs.c|  93 +
  drivers/gpu/drm/i915/gt/intel_engine_types.h |  15 +++
  drivers/gpu/drm/i915/gt/intel_gt.c   | 135 +++
  3 files changed, 128 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 99c4b866addd..d47dadfc25c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1143,12 +1143,105 @@ static int init_status_page(struct intel_engine_cs 
*engine)
return ret;
  }
  
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs *engine)

+{
+   static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+   [RENDER_CLASS].reg  = GEN8_RTCR,
+   [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , GEN8_M2TCR */
+   [VIDEO_ENHANCEMENT_CLASS].reg   = GEN8_VTCR,
+   [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
+   };
+   static const union intel_engine_tlb_inv_reg gen12_regs[] = {
+   [RENDER_CLASS].reg  = GEN12_GFX_TLB_INV_CR,
+   [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
+   [VIDEO_ENHANCEMENT_CLASS].reg   = GEN12_VE_TLB_INV_CR,
+   [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
+   [COMPUTE_CLASS].reg = GEN12_COMPCTX_TLB_INV_CR,
+   };
+   static const union intel_engine_tlb_inv_reg xehp_regs[] = {
+   [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
+   [VIDEO_DECODE_CLASS].mcr_reg  = XEHP_VD_TLB_INV_CR,
+   [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
+   [COPY_ENGINE_CLASS].mcr_reg   = XEHP_BLT_TLB_INV_CR,
+   [COMPUTE_CLASS].mcr_reg   = XEHP_COMPCTX_TLB_INV_CR,
+   };
+   struct drm_i915_private *i915 = engine->i915;
+   const union intel_engine_tlb_inv_reg *regs;
+   union intel_engine_tlb_inv_reg reg;
+   unsigned int class = engine->class;
+   unsigned int num = 0;
+   u32 val;
+
+   /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+   if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
+   regs = xehp_regs;
+   num = ARRAY_SIZE(xehp_regs);
+   } else if (GRAPHICS_VER(i915) == 12) {
+   regs = gen12_regs;
+   num = ARRAY_SIZE(gen12_regs);
+   } else if (GRAPHICS_VER(i915) >= 8 && GRAPHICS_VER(i915) <= 11) {
+   regs = gen8_regs;
+   num = ARRAY_SIZE(gen8_regs);
+   } else if (GRAPHICS_VER(i915) < 8) {
+   return 0;
+   } > +
+   if (drm_WARN_ONCE(>drm, !num,
+ "Platform does not implement TLB invalidation!"))
+   return -ENODEV;
+
+   if (drm_WARN_ON_ONCE(>drm,
+class >= num ||
+(!regs[class].reg.reg &&
+ !regs[class].mcr_reg.reg)))
+   return -ERANGE;


I hope the propagation of -ERANGE to device probe is OK.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej


+
+   reg = regs[class];
+
+   if (GRAPHICS_VER(i915) == 8 && class == VIDEO_DECODE_CLASS) {
+   reg.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
+   val = 0;
+   } else {
+   val = engine->instance;
+   }
+
+   val = BIT(val);
+
+   engine->tlb_inv.mcr = regs == xehp_regs;
+   engine->tlb_inv.reg = reg;
+   engine->tlb_inv.done = val;
+
+   if (GRAPHICS_VER(i915) >= 12 &&
+   (engine->class == VIDEO_DECODE_CLASS ||
+engine->class == VIDEO_ENHANCEMENT_CLASS ||
+engine->class == COMPUTE_CLASS))
+   engine->tlb_inv.request = _MASKED_BIT_ENABLE(val);
+   else
+   engine->tlb_inv.request = val;
+
+   

[PATCH 13/18] fbdev/offb: Do not use struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Acquire ownership of the firmware scanout buffer by calling Linux'
aperture helpers. Remove the use of struct fb_info.apertures and do
not set FBINFO_MISC_FIRMWARE; both of which previously configured
buffer ownership.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/offb.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index a298adcee2d9..f7ad6bc9d02d 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -12,6 +12,7 @@
  *  more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -54,6 +55,8 @@ struct offb_par {
int cmap_type;
int blanked;
u32 pseudo_palette[16];
+   resource_size_t base;
+   resource_size_t size;
 };
 
 #ifdef CONFIG_PPC32
@@ -279,9 +282,11 @@ static int offb_set_par(struct fb_info *info)
 
 static void offb_destroy(struct fb_info *info)
 {
+   struct offb_par *par = info->par;
+
if (info->screen_base)
iounmap(info->screen_base);
-   release_mem_region(info->apertures->ranges[0].base, 
info->apertures->ranges[0].size);
+   release_mem_region(par->base, par->size);
fb_dealloc_cmap(>cmap);
framebuffer_release(info);
 }
@@ -503,20 +508,18 @@ static void offb_init_fb(struct platform_device *parent, 
const char *name,
var->sync = 0;
var->vmode = FB_VMODE_NONINTERLACED;
 
-   /* set offb aperture size for generic probing */
-   info->apertures = alloc_apertures(1);
-   if (!info->apertures)
-   goto out_aper;
-   info->apertures->ranges[0].base = address;
-   info->apertures->ranges[0].size = fix->smem_len;
+   par->base = address;
+   par->size = fix->smem_len;
 
info->fbops = _ops;
info->screen_base = ioremap(address, fix->smem_len);
info->pseudo_palette = par->pseudo_palette;
-   info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE | foreign_endian;
+   info->flags = FBINFO_DEFAULT | foreign_endian;
 
fb_alloc_cmap(>cmap, 256, 0);
 
+   if (devm_aperture_acquire_for_platform_device(parent, par->base, 
par->size) < 0)
+   goto out_err;
if (register_framebuffer(info) < 0)
goto out_err;
 
@@ -526,7 +529,6 @@ static void offb_init_fb(struct platform_device *parent, 
const char *name,
 out_err:
fb_dealloc_cmap(>cmap);
iounmap(info->screen_base);
-out_aper:
iounmap(par->cmap_adr);
par->cmap_adr = NULL;
framebuffer_release(info);
-- 
2.39.0



[PATCH 10/18] fbdev/efifb: Add struct efifb_par for driver data

2022-12-19 Thread Thomas Zimmermann
The efifb_par structure holds the palette for efifb. It will also
be useful for storing the device's aperture range.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/efifb.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 16c1aaae9afa..694013f62781 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -49,6 +49,10 @@ static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
 
 static struct pci_dev *efifb_pci_dev;  /* dev with BAR covering the efifb */
 
+struct efifb_par {
+   u32 pseudo_palette[16];
+};
+
 static struct fb_var_screeninfo efifb_defined = {
.activate   = FB_ACTIVATE_NOW,
.height = -1,
@@ -351,6 +355,7 @@ static u64 bar_offset;
 static int efifb_probe(struct platform_device *dev)
 {
struct fb_info *info;
+   struct efifb_par *par;
int err, orientation;
unsigned int size_vmode;
unsigned int size_remap;
@@ -447,14 +452,14 @@ static int efifb_probe(struct platform_device *dev)
efifb_fix.smem_start);
}
 
-   info = framebuffer_alloc(sizeof(u32) * 16, >dev);
+   info = framebuffer_alloc(sizeof(*par), >dev);
if (!info) {
err = -ENOMEM;
goto err_release_mem;
}
platform_set_drvdata(dev, info);
-   info->pseudo_palette = info->par;
-   info->par = NULL;
+   par = info->par;
+   info->pseudo_palette = par->pseudo_palette;
 
info->apertures = alloc_apertures(1);
if (!info->apertures) {
-- 
2.39.0



[PATCH 12/18] fbdev/offb: Allocate struct offb_par with framebuffer_alloc()

2022-12-19 Thread Thomas Zimmermann
Move the palette array into struct offb_par and allocate both via
framebuffer_alloc(), as intended by fbdev. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/offb.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index 91001990e351..a298adcee2d9 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -53,10 +53,9 @@ struct offb_par {
volatile void __iomem *cmap_data;
int cmap_type;
int blanked;
+   u32 pseudo_palette[16];
 };
 
-struct offb_par default_par;
-
 #ifdef CONFIG_PPC32
 extern boot_infos_t *boot_infos;
 #endif
@@ -393,11 +392,11 @@ static void offb_init_fb(struct platform_device *parent, 
const char *name,
 int foreign_endian, struct device_node *dp)
 {
unsigned long res_size = pitch * height;
-   struct offb_par *par = _par;
unsigned long res_start = address;
struct fb_fix_screeninfo *fix;
struct fb_var_screeninfo *var;
struct fb_info *info;
+   struct offb_par *par;
 
if (!request_mem_region(res_start, res_size, "offb"))
return;
@@ -411,17 +410,15 @@ static void offb_init_fb(struct platform_device *parent, 
const char *name,
return;
}
 
-   info = framebuffer_alloc(sizeof(u32) * 16, >dev);
-
+   info = framebuffer_alloc(sizeof(*par), >dev);
if (!info) {
release_mem_region(res_start, res_size);
return;
}
platform_set_drvdata(parent, info);
-
+   par = info->par;
fix = >fix;
var = >var;
-   info->par = par;
 
if (name) {
strcpy(fix->id, "OFfb ");
@@ -515,7 +512,7 @@ static void offb_init_fb(struct platform_device *parent, 
const char *name,
 
info->fbops = _ops;
info->screen_base = ioremap(address, fix->smem_len);
-   info->pseudo_palette = (void *) (info + 1);
+   info->pseudo_palette = par->pseudo_palette;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE | foreign_endian;
 
fb_alloc_cmap(>cmap, 256, 0);
-- 
2.39.0



[PATCH 17/18] fbdev/vga16fb: Do not use struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Acquire ownership of the firmware scanout buffer by calling Linux'
aperture helpers. Remove the use of struct fb_info.apertures and do
not set FBINFO_MISC_FIRMWARE; both of which previously configured
buffer ownership.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/vga16fb.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
index af47f8217095..1a8ffdb2be26 100644
--- a/drivers/video/fbdev/vga16fb.c
+++ b/drivers/video/fbdev/vga16fb.c
@@ -10,6 +10,7 @@
  * archive for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1324,11 +1325,6 @@ static int vga16fb_probe(struct platform_device *dev)
ret = -ENOMEM;
goto err_fb_alloc;
}
-   info->apertures = alloc_apertures(1);
-   if (!info->apertures) {
-   ret = -ENOMEM;
-   goto err_ioremap;
-   }
 
/* XXX share VGA_FB_PHYS_BASE and I/O region with vgacon and others */
info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS_BASE, 0);
@@ -1363,8 +1359,7 @@ static int vga16fb_probe(struct platform_device *dev)
info->fix = vga16fb_fix;
/* supports rectangles with widths of multiples of 8 */
info->pixmap.blit_x = 1 << 7 | 1 << 15 | 1 << 23 | 1 << 31;
-   info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
-   FBINFO_HWACCEL_YPAN;
+   info->flags = FBINFO_FLAG_DEFAULT | FBINFO_HWACCEL_YPAN;
 
i = (info->var.bits_per_pixel == 8) ? 256 : 16;
ret = fb_alloc_cmap(>cmap, i, 0);
@@ -1382,9 +1377,9 @@ static int vga16fb_probe(struct platform_device *dev)
 
vga16fb_update_fix(info);
 
-   info->apertures->ranges[0].base = VGA_FB_PHYS_BASE;
-   info->apertures->ranges[0].size = VGA_FB_PHYS_SIZE;
-
+   ret = devm_aperture_acquire_for_platform_device(dev, VGA_FB_PHYS_BASE, 
VGA_FB_PHYS_SIZE);
+   if (ret)
+   goto err_check_var;
if (register_framebuffer(info) < 0) {
printk(KERN_ERR "vga16fb: unable to register framebuffer\n");
ret = -EINVAL;
-- 
2.39.0



[PATCH 09/18] vfio-mdev/mdpy-fb: Do not set struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in mdpy-fb.

Signed-off-by: Thomas Zimmermann 
---
 samples/vfio-mdev/mdpy-fb.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/samples/vfio-mdev/mdpy-fb.c b/samples/vfio-mdev/mdpy-fb.c
index 9ec93d90e8a5..1de5801cd2e8 100644
--- a/samples/vfio-mdev/mdpy-fb.c
+++ b/samples/vfio-mdev/mdpy-fb.c
@@ -161,14 +161,6 @@ static int mdpy_fb_probe(struct pci_dev *pdev,
goto err_release_fb;
}
 
-   info->apertures = alloc_apertures(1);
-   if (!info->apertures) {
-   ret = -ENOMEM;
-   goto err_unmap;
-   }
-   info->apertures->ranges[0].base = info->fix.smem_start;
-   info->apertures->ranges[0].size = info->fix.smem_len;
-
info->fbops = _fb_ops;
info->flags = FBINFO_DEFAULT;
info->pseudo_palette = par->palette;
-- 
2.39.0



[PATCH 06/18] drm/fb-helper: Do not allocate unused apertures structure

2022-12-19 Thread Thomas Zimmermann
The apertures field in struct fb_info is not used by DRM drivers. Do
not allocate it.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_fb_helper.c | 20 ++--
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3a731b9170a..e8a7e8be91d9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -473,8 +473,8 @@ EXPORT_SYMBOL(drm_fb_helper_init);
  * drm_fb_helper_alloc_info - allocate fb_info and some of its members
  * @fb_helper: driver-allocated fbdev helper
  *
- * A helper to alloc fb_info and the members cmap and apertures. Called
- * by the driver within the fb_probe fb_helper callback function. Drivers do 
not
+ * A helper to alloc fb_info and the member cmap. Called by the driver
+ * within the fb_probe fb_helper callback function. Drivers do not
  * need to release the allocated fb_info structure themselves, this is
  * automatically done when calling drm_fb_helper_fini().
  *
@@ -496,27 +496,11 @@ struct fb_info *drm_fb_helper_alloc_info(struct 
drm_fb_helper *fb_helper)
if (ret)
goto err_release;
 
-   /*
-* TODO: We really should be smarter here and alloc an aperture
-* for each IORESOURCE_MEM resource helper->dev->dev has and also
-* init the ranges of the appertures based on the resources.
-* Note some drivers currently count on there being only 1 empty
-* aperture and fill this themselves, these will need to be dealt
-* with somehow when fixing this.
-*/
-   info->apertures = alloc_apertures(1);
-   if (!info->apertures) {
-   ret = -ENOMEM;
-   goto err_free_cmap;
-   }
-
fb_helper->info = info;
info->skip_vt_switch = true;
 
return info;
 
-err_free_cmap:
-   fb_dealloc_cmap(>cmap);
 err_release:
framebuffer_release(info);
return ERR_PTR(ret);
-- 
2.39.0



[PATCH 07/18] fbdev/clps711x-fb: Do not set struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in clps711x-fb.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/clps711x-fb.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/clps711x-fb.c 
b/drivers/video/fbdev/clps711x-fb.c
index a1061c2f1640..45c75ff01eca 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -251,16 +251,8 @@ static int clps711x_fb_probe(struct platform_device *pdev)
goto out_fb_release;
}
 
-   info->apertures = alloc_apertures(1);
-   if (!info->apertures) {
-   ret = -ENOMEM;
-   goto out_fb_release;
-   }
-
cfb->buffsize = resource_size(res);
info->fix.smem_start = res->start;
-   info->apertures->ranges[0].base = info->fix.smem_start;
-   info->apertures->ranges[0].size = cfb->buffsize;
 
cfb->clk = devm_clk_get(dev, NULL);
if (IS_ERR(cfb->clk)) {
@@ -345,7 +337,7 @@ static int clps711x_fb_probe(struct platform_device *pdev)
   _lcd_ops);
if (!IS_ERR(lcd))
return 0;
-   
+
ret = PTR_ERR(lcd);
unregister_framebuffer(info);
 
-- 
2.39.0



[PATCH 16/18] fbdev/vesafb: Do not use struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Acquire ownership of the firmware scanout buffer by calling Linux'
aperture helpers. Remove the use of struct fb_info.apertures and do
not set FBINFO_MISC_FIRMWARE; both of which previously configured
buffer ownership.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/vesafb.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index 47ce244e4bb8..3f8bdfcf51f0 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -9,6 +9,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,8 @@
 
 struct vesafb_par {
u32 pseudo_palette[256];
+   resource_size_t base;
+   resource_size_t size;
int wc_cookie;
struct resource *region;
 };
@@ -191,7 +194,7 @@ static void vesafb_destroy(struct fb_info *info)
arch_phys_wc_del(par->wc_cookie);
if (info->screen_base)
iounmap(info->screen_base);
-   release_mem_region(info->apertures->ranges[0].base, 
info->apertures->ranges[0].size);
+   release_mem_region(par->base, par->size);
 
framebuffer_release(info);
 }
@@ -316,14 +319,8 @@ static int vesafb_probe(struct platform_device *dev)
par = info->par;
info->pseudo_palette = par->pseudo_palette;
 
-   /* set vesafb aperture size for generic probing */
-   info->apertures = alloc_apertures(1);
-   if (!info->apertures) {
-   err = -ENOMEM;
-   goto err;
-   }
-   info->apertures->ranges[0].base = screen_info.lfb_base;
-   info->apertures->ranges[0].size = size_total;
+   par->base = screen_info.lfb_base;
+   par->size = size_total;
 
printk(KERN_INFO "vesafb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
   vesafb_defined.xres, vesafb_defined.yres, 
vesafb_defined.bits_per_pixel, vesafb_fix.line_length, screen_info.pages);
@@ -460,27 +457,29 @@ static int vesafb_probe(struct platform_device *dev)
info->fbops = _ops;
info->var = vesafb_defined;
info->fix = vesafb_fix;
-   info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
-   (ypan ? FBINFO_HWACCEL_YPAN : 0);
+   info->flags = FBINFO_FLAG_DEFAULT | (ypan ? FBINFO_HWACCEL_YPAN : 0);
 
if (fb_alloc_cmap(>cmap, 256, 0) < 0) {
err = -ENOMEM;
goto err_release_region;
}
+   err = devm_aperture_acquire_for_platform_device(dev, par->base, 
par->size);
+   if (err)
+   goto err_fb_dealloc_cmap;
if (register_framebuffer(info)<0) {
err = -EINVAL;
-   fb_dealloc_cmap(>cmap);
-   goto err_release_region;
+   goto err_fb_dealloc_cmap;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
return 0;
+err_fb_dealloc_cmap:
+   fb_dealloc_cmap(>cmap);
 err_release_region:
arch_phys_wc_del(par->wc_cookie);
if (info->screen_base)
iounmap(info->screen_base);
if (par->region)
release_region(0x3c0, 32);
-err:
framebuffer_release(info);
release_mem_region(vesafb_fix.smem_start, size_total);
return err;
-- 
2.39.0



[PATCH 01/18] fbcon: Remove trailing whitespaces

2022-12-19 Thread Thomas Zimmermann
Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/core/fbcon.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c0143d38df83..500b26d652f6 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -26,7 +26,7 @@
  *
  *  Hardware cursor support added by Emmanuel Marty (c...@ggi-project.org)
  *  Smart redraw scrolling, arbitrary font width support, 512char font support
- *  and software scrollback added by 
+ *  and software scrollback added by
  * Jakub Jelinek (j...@ultra.linux.cz)
  *
  *  Random hacking by Martin Mares 
@@ -127,7 +127,7 @@ static int logo_shown = FBCON_LOGO_CANSHOW;
 /* console mappings */
 static unsigned int first_fb_vc;
 static unsigned int last_fb_vc = MAX_NR_CONSOLES - 1;
-static int fbcon_is_default = 1; 
+static int fbcon_is_default = 1;
 static int primary_device = -1;
 static int fbcon_has_console_bind;
 
@@ -415,12 +415,12 @@ static int __init fb_console_setup(char *this_opt)
strscpy(fontname, options + 5, sizeof(fontname));
continue;
}
-   
+
if (!strncmp(options, "scrollback:", 11)) {
pr_warn("Ignoring scrollback size option\n");
continue;
}
-   
+
if (!strncmp(options, "map:", 4)) {
options += 4;
if (*options) {
@@ -446,7 +446,7 @@ static int __init fb_console_setup(char *this_opt)
last_fb_vc = simple_strtoul(options, , 
10) - 1;
if (last_fb_vc < first_fb_vc || last_fb_vc >= 
MAX_NR_CONSOLES)
last_fb_vc = MAX_NR_CONSOLES - 1;
-   fbcon_is_default = 0; 
+   fbcon_is_default = 0;
continue;
}
 
@@ -940,7 +940,7 @@ static const char *fbcon_startup(void)
info = fbcon_registered_fb[info_idx];
if (!info)
return NULL;
-   
+
if (fbcon_open(info))
return NULL;
 
@@ -1999,7 +1999,7 @@ static void updatescrollmode(struct fbcon_display *p,
 #define PITCH(w) (((w) + 7) >> 3)
 #define CALC_FONTSZ(h, p, c) ((h) * (p) * (c)) /* size = height * pitch * 
charcount */
 
-static int fbcon_resize(struct vc_data *vc, unsigned int width, 
+static int fbcon_resize(struct vc_data *vc, unsigned int width,
unsigned int height, unsigned int user)
 {
struct fb_info *info = fbcon_info_from_console(vc->vc_num);
@@ -2174,7 +2174,7 @@ static int fbcon_switch(struct vc_data *vc)
ops->update_start(info);
}
 
-   fbcon_set_palette(vc, color_table); 
+   fbcon_set_palette(vc, color_table);
fbcon_clear_margins(vc, 0);
 
if (logo_shown == FBCON_LOGO_DRAW) {
@@ -2343,7 +2343,7 @@ static void set_vc_hi_font(struct vc_data *vc, bool set)
vc->vc_complement_mask >>= 1;
vc->vc_s_complement_mask >>= 1;
}
-   
+
/* ++Edmund: reorder the attribute bits */
if (vc->vc_can_do_color) {
unsigned short *cp =
@@ -2366,7 +2366,7 @@ static void set_vc_hi_font(struct vc_data *vc, bool set)
vc->vc_complement_mask <<= 1;
vc->vc_s_complement_mask <<= 1;
}
-   
+
/* ++Edmund: reorder the attribute bits */
{
unsigned short *cp =
@@ -2527,7 +2527,7 @@ static int fbcon_set_font(struct vc_data *vc, struct 
console_font *font,
/* Check if the same font is on some other console already */
for (i = first_fb_vc; i <= last_fb_vc; i++) {
struct vc_data *tmp = vc_cons[i].d;
-   
+
if (fb_display[i].userfont &&
fb_display[i].fontdata &&
FNTSUM(fb_display[i].fontdata) == csum &&
@@ -3435,5 +3435,5 @@ void __exit fb_console_exit(void)
 
do_unregister_con_driver(_con);
console_unlock();
-}  
+}
 #endif
-- 
2.39.0



[PATCH 03/18] drm/gma500: Do not set struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in gma500.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/gma500/framebuffer.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 8d5a37b8f110..9e892a82e109 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -297,11 +297,6 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
info->screen_base = dev_priv->vram_addr + backing->offset;
info->screen_size = size;
 
-   if (dev_priv->gtt.stolen_size) {
-   info->apertures->ranges[0].base = dev_priv->fb_base;
-   info->apertures->ranges[0].size = dev_priv->gtt.stolen_size;
-   }
-
drm_fb_helper_fill_info(info, fb_helper, sizes);
 
info->fix.mmio_start = pci_resource_start(pdev, 0);
-- 
2.39.0



[PATCH 15/18] fbdev/vesafb: Remove trailing whitespaces

2022-12-19 Thread Thomas Zimmermann
Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/vesafb.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index 929d4775cb4b..47ce244e4bb8 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -140,7 +140,7 @@ static int vesafb_setcolreg(unsigned regno, unsigned red, 
unsigned green,
 *  (according to the entries in the `var' structure). Return
 *  != 0 for invalid regno.
 */
-   
+
if (regno >= info->cmap.len)
return 1;
 
@@ -209,13 +209,13 @@ static struct fb_ops vesafb_ops = {
 static int vesafb_setup(char *options)
 {
char *this_opt;
-   
+
if (!options || !*options)
return 0;
-   
+
while ((this_opt = strsep(, ",")) != NULL) {
if (!*this_opt) continue;
-   
+
if (! strcmp(this_opt, "inverse"))
inverse=1;
else if (! strcmp(this_opt, "redraw"))
@@ -381,7 +381,7 @@ static int vesafb_probe(struct platform_device *dev)
vesafb_defined.pixclock = 1000 / vesafb_defined.xres * 1000 / 
vesafb_defined.yres;
vesafb_defined.left_margin  = (vesafb_defined.xres / 8) & 0xf8;
vesafb_defined.hsync_len= (vesafb_defined.xres / 8) & 0xf8;
-   
+
vesafb_defined.red.offset= screen_info.red_pos;
vesafb_defined.red.length= screen_info.red_size;
vesafb_defined.green.offset  = screen_info.green_pos;
-- 
2.39.0



[PATCH 14/18] fbdev/simplefb: Do not use struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Acquire ownership of the firmware scanout buffer by calling Linux'
aperture helpers. Remove the use of struct fb_info.apertures and do
not set FBINFO_MISC_FIRMWARE; both of which previously configured
buffer ownership.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/simplefb.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index e770b4a356b5..10d71879d340 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -12,6 +12,7 @@
  * Copyright (C) 1996 Paul Mackerras
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -68,6 +69,8 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int 
green, u_int blue,
 
 struct simplefb_par {
u32 palette[PSEUDO_PALETTE_SIZE];
+   resource_size_t base;
+   resource_size_t size;
struct resource *mem;
 #if defined CONFIG_OF && defined CONFIG_COMMON_CLK
bool clks_enabled;
@@ -472,16 +475,11 @@ static int simplefb_probe(struct platform_device *pdev)
info->var.blue = params.format->blue;
info->var.transp = params.format->transp;
 
-   info->apertures = alloc_apertures(1);
-   if (!info->apertures) {
-   ret = -ENOMEM;
-   goto error_fb_release;
-   }
-   info->apertures->ranges[0].base = info->fix.smem_start;
-   info->apertures->ranges[0].size = info->fix.smem_len;
+   par->base = info->fix.smem_start;
+   par->size = info->fix.smem_len;
 
info->fbops = _ops;
-   info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
+   info->flags = FBINFO_DEFAULT;
info->screen_base = ioremap_wc(info->fix.smem_start,
   info->fix.smem_len);
if (!info->screen_base) {
@@ -511,6 +509,11 @@ static int simplefb_probe(struct platform_device *pdev)
if (mem != res)
par->mem = mem; /* release in clean-up handler */
 
+   ret = devm_aperture_acquire_for_platform_device(pdev, par->base, 
par->size);
+   if (ret) {
+   dev_err(>dev, "Unable to acquire aperture: %d\n", ret);
+   goto error_regulators;
+   }
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(>dev, "Unable to register simplefb: %d\n", ret);
-- 
2.39.0



[PATCH 00/18] drm, fbdev: Remove apertures structure and FBINFO_MISC_FIRMWARE

2022-12-19 Thread Thomas Zimmermann
Remove struct fb_info.apertures and FBINFO_MISC_FIRMWARE from fbdev
and handle the aperture ownership without involving the fbdev core.

The apertures field in struct fb_info is a remnant from earlier
ownership management for framebuffer apertures. When fbdev core code
still handled ownership of the framebuffer among fbdev device drivers,
generic drivers set the aperture ranges to claim the firmware scanout
buffer for themselves.

Now that we have a module with helpers that manage aperture and
framebuffer ownership among drivers, the aperture field is not needed
any longer. In fact, several drivers set this field, even though they
are not generic fbdev drivers. Only drivers that set FBINFO_MISC_FIRMWARE
can use apertures in a meaningful way.

To remove FBINFO_MISC_FIRMWARE, patches 1 and 2 remove it from fbcon. It
was used to work around issues with font loading. That is now all handled
in userspace.

Patches 3 to 9 remove aperture setup from all non-generic drivers. These
drivers are not for firmware graphics and do not have to set the values.
For DRM, we do not need to allocate the apertures field any longer.

Patches 10 to 17 update all generic fbdev drivers to manage aperture
ownership by themselves by called Linux aperture helpers. The setup of
the apertures field and setting FBINFO_MISC_FIRMWARE is being removed as
a result of that.

With all of its users gone, patch 18 removes FBINFO_MISC_FIRMWARE, struct
fb_info.apertures and the fbdev core's aperture code.

Tested with handover combinations of efifb, simpledrm and radeon.

Thomas Zimmermann (18):
  fbcon: Remove trailing whitespaces
  Revert "fbcon: don't lose the console font across generic->chip driver
switch"
  drm/gma500: Do not set struct fb_info.apertures
  drm/i915: Do not set struct fb_info.apertures
  drm/radeon: Do not set struct fb_info.apertures
  drm/fb-helper: Do not allocate unused apertures structure
  fbdev/clps711x-fb: Do not set struct fb_info.apertures
  fbdev/hyperv-fb: Do not set struct fb_info.apertures
  vfio-mdev/mdpy-fb: Do not set struct fb_info.apertures
  fbdev/efifb: Add struct efifb_par for driver data
  fbdev/efifb: Do not use struct fb_info.apertures
  fbdev/offb: Allocate struct offb_par with framebuffer_alloc()
  fbdev/offb: Do not use struct fb_info.apertures
  fbdev/simplefb: Do not use struct fb_info.apertures
  fbdev/vesafb: Remove trailing whitespaces
  fbdev/vesafb: Do not use struct fb_info.apertures
  fbdev/vga16fb: Do not use struct fb_info.apertures
  drm/fbdev: Remove aperture handling and FBINFO_MISC_FIRMWARE

 drivers/gpu/drm/drm_fb_helper.c| 20 ++-
 drivers/gpu/drm/gma500/framebuffer.c   |  5 ---
 drivers/gpu/drm/i915/display/intel_fbdev.c |  7 
 drivers/gpu/drm/radeon/radeon_fb.c |  4 ---
 drivers/video/fbdev/clps711x-fb.c  | 10 +-
 drivers/video/fbdev/core/fbcon.c   | 41 ++
 drivers/video/fbdev/core/fbmem.c   | 33 -
 drivers/video/fbdev/core/fbsysfs.c |  1 -
 drivers/video/fbdev/efifb.c| 35 +++---
 drivers/video/fbdev/hyperv_fb.c| 17 -
 drivers/video/fbdev/offb.c | 33 +
 drivers/video/fbdev/simplefb.c | 19 +-
 drivers/video/fbdev/vesafb.c   | 37 ++-
 drivers/video/fbdev/vga16fb.c  | 15 +++-
 include/linux/fb.h | 22 
 samples/vfio-mdev/mdpy-fb.c|  8 -
 16 files changed, 99 insertions(+), 208 deletions(-)


base-commit: d322881f7e33af24901ee8ccaec3beef82f21203
prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
prerequisite-patch-id: 3f204510fcbf9530d6540bd8e6128cce598988b6
-- 
2.39.0



[PATCH 18/18] drm/fbdev: Remove aperture handling and FBINFO_MISC_FIRMWARE

2022-12-19 Thread Thomas Zimmermann
There are no users left of struct fb_info.apertures and the flag
FBINFO_MISC_FIRMWARE. Remove both and the aperture-ownership code
in the fbdev core. All code for aperture ownership is now located
in the fbdev drivers.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/core/fbmem.c   | 33 --
 drivers/video/fbdev/core/fbsysfs.c |  1 -
 include/linux/fb.h | 22 
 3 files changed, 56 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 3a6c8458eb8d..02217c33d152 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -13,7 +13,6 @@
 
 #include 
 
-#include 
 #include 
 #include 
 #include 
@@ -1653,32 +1652,6 @@ static void do_unregister_framebuffer(struct fb_info 
*fb_info)
put_fb_info(fb_info);
 }
 
-static int fb_aperture_acquire_for_platform_device(struct fb_info *fb_info)
-{
-   struct apertures_struct *ap = fb_info->apertures;
-   struct device *dev = fb_info->device;
-   struct platform_device *pdev;
-   unsigned int i;
-   int ret;
-
-   if (!ap)
-   return 0;
-
-   if (!dev_is_platform(dev))
-   return 0;
-
-   pdev = to_platform_device(dev);
-
-   for (ret = 0, i = 0; i < ap->count; ++i) {
-   ret = devm_aperture_acquire_for_platform_device(pdev, 
ap->ranges[i].base,
-   
ap->ranges[i].size);
-   if (ret)
-   break;
-   }
-
-   return ret;
-}
-
 /**
  * register_framebuffer - registers a frame buffer device
  * @fb_info: frame buffer info structure
@@ -1693,12 +1666,6 @@ register_framebuffer(struct fb_info *fb_info)
 {
int ret;
 
-   if (fb_info->flags & FBINFO_MISC_FIRMWARE) {
-   ret = fb_aperture_acquire_for_platform_device(fb_info);
-   if (ret)
-   return ret;
-   }
-
mutex_lock(_lock);
ret = do_register_framebuffer(fb_info);
mutex_unlock(_lock);
diff --git a/drivers/video/fbdev/core/fbsysfs.c 
b/drivers/video/fbdev/core/fbsysfs.c
index 4d7f63892dcc..0c33c4adcd79 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -88,7 +88,6 @@ void framebuffer_release(struct fb_info *info)
mutex_destroy(>bl_curve_mutex);
 #endif
 
-   kfree(info->apertures);
kfree(info);
 }
 EXPORT_SYMBOL(framebuffer_release);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 96b96323e9cb..30183fd259ae 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -423,8 +423,6 @@ struct fb_tile_ops {
  */
 #define FBINFO_MISC_ALWAYS_SETPAR   0x4
 
-/* where the fb is a firmware driver, and can be replaced with a proper one */
-#define FBINFO_MISC_FIRMWARE0x8
 /*
  * Host and GPU endianness differ.
  */
@@ -499,30 +497,10 @@ struct fb_info {
void *fbcon_par;/* fbcon use-only private area */
/* From here on everything is device dependent */
void *par;
-   /* we need the PCI or similar aperture base/size not
-  smem_start/size as smem_start may just be an object
-  allocated inside the aperture so may not actually overlap */
-   struct apertures_struct {
-   unsigned int count;
-   struct aperture {
-   resource_size_t base;
-   resource_size_t size;
-   } ranges[0];
-   } *apertures;
 
bool skip_vt_switch; /* no VT switch on suspend/resume required */
 };
 
-static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
-   struct apertures_struct *a;
-
-   a = kzalloc(struct_size(a, ranges, max_num), GFP_KERNEL);
-   if (!a)
-   return NULL;
-   a->count = max_num;
-   return a;
-}
-
 #define FBINFO_FLAG_DEFAULTFBINFO_DEFAULT
 
 /* This will go away
-- 
2.39.0



[PATCH 11/18] fbdev/efifb: Do not use struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Acquire ownership of the firmware scanout buffer by calling Linux'
aperture helpers. Remove the use of struct fb_info.apertures and do
not set FBINFO_MISC_FIRMWARE; both of which previously configured
buffer ownership.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/efifb.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 694013f62781..a5779fb453a2 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -7,6 +7,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +52,8 @@ static struct pci_dev *efifb_pci_dev; /* dev with BAR 
covering the efifb */
 
 struct efifb_par {
u32 pseudo_palette[16];
+   resource_size_t base;
+   resource_size_t size;
 };
 
 static struct fb_var_screeninfo efifb_defined = {
@@ -253,6 +256,8 @@ static inline void efifb_show_boot_graphics(struct fb_info 
*info) {}
  */
 static void efifb_destroy(struct fb_info *info)
 {
+   struct efifb_par *par = info->par;
+
if (efifb_pci_dev)
pm_runtime_put(_pci_dev->dev);
 
@@ -264,8 +269,7 @@ static void efifb_destroy(struct fb_info *info)
}
 
if (request_mem_succeeded)
-   release_mem_region(info->apertures->ranges[0].base,
-  info->apertures->ranges[0].size);
+   release_mem_region(par->base, par->size);
fb_dealloc_cmap(>cmap);
 
framebuffer_release(info);
@@ -461,13 +465,8 @@ static int efifb_probe(struct platform_device *dev)
par = info->par;
info->pseudo_palette = par->pseudo_palette;
 
-   info->apertures = alloc_apertures(1);
-   if (!info->apertures) {
-   err = -ENOMEM;
-   goto err_release_fb;
-   }
-   info->apertures->ranges[0].base = efifb_fix.smem_start;
-   info->apertures->ranges[0].size = size_remap;
+   par->base = efifb_fix.smem_start;
+   par->size = size_remap;
 
if (efi_enabled(EFI_MEMMAP) &&
!efi_mem_desc_lookup(efifb_fix.smem_start, )) {
@@ -556,7 +555,7 @@ static int efifb_probe(struct platform_device *dev)
info->fbops = _ops;
info->var = efifb_defined;
info->fix = efifb_fix;
-   info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
+   info->flags = FBINFO_FLAG_DEFAULT;
 
orientation = drm_get_panel_orientation_quirk(efifb_defined.xres,
  efifb_defined.yres);
@@ -589,6 +588,11 @@ static int efifb_probe(struct platform_device *dev)
if (efifb_pci_dev)
WARN_ON(pm_runtime_get_sync(_pci_dev->dev) < 0);
 
+   err = devm_aperture_acquire_for_platform_device(dev, par->base, 
par->size);
+   if (err) {
+   pr_err("efifb: cannot acquire aperture\n");
+   goto err_put_rpm_ref;
+   }
err = register_framebuffer(info);
if (err < 0) {
pr_err("efifb: cannot register framebuffer\n");
-- 
2.39.0



[PATCH 05/18] drm/radeon: Do not set struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in radeon.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/radeon/radeon_fb.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index c1710ed1cab8..fe4087bfdb3c 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -277,10 +277,6 @@ static int radeonfb_create(struct drm_fb_helper *helper,
 
drm_fb_helper_fill_info(info, >helper, sizes);
 
-   /* setup aperture base/size for vesafb takeover */
-   info->apertures->ranges[0].base = rdev->mc.aper_base;
-   info->apertures->ranges[0].size = rdev->mc.aper_size;
-
/* Use default scratch pixmap (info->pixmap.flags = FB_PIXMAP_SYSTEM) */
 
if (info->screen_base == NULL) {
-- 
2.39.0



[PATCH 08/18] fbdev/hyperv-fb: Do not set struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in hyperv-fb.

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/hyperv_fb.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index d8edb5635f77..1c7d6ff5a6c0 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -988,13 +988,10 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
fb_info *info)
struct pci_dev *pdev  = NULL;
void __iomem *fb_virt;
int gen2vm = efi_enabled(EFI_BOOT);
+   resource_size_t base, size;
phys_addr_t paddr;
int ret;
 
-   info->apertures = alloc_apertures(1);
-   if (!info->apertures)
-   return -ENOMEM;
-
if (!gen2vm) {
pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
@@ -1003,8 +1000,8 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
fb_info *info)
return -ENODEV;
}
 
-   info->apertures->ranges[0].base = pci_resource_start(pdev, 0);
-   info->apertures->ranges[0].size = pci_resource_len(pdev, 0);
+   base = pci_resource_start(pdev, 0);
+   size = pci_resource_len(pdev, 0);
 
/*
 * For Gen 1 VM, we can directly use the contiguous memory
@@ -1027,8 +1024,8 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
fb_info *info)
}
pr_info("Unable to allocate enough contiguous physical memory 
on Gen 1 VM. Using MMIO instead.\n");
} else {
-   info->apertures->ranges[0].base = screen_info.lfb_base;
-   info->apertures->ranges[0].size = screen_info.lfb_size;
+   base = screen_info.lfb_base;
+   size = screen_info.lfb_size;
}
 
/*
@@ -1070,9 +1067,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
fb_info *info)
info->screen_size = dio_fb_size;
 
 getmem_done:
-   aperture_remove_conflicting_devices(info->apertures->ranges[0].base,
-   info->apertures->ranges[0].size,
-   false, KBUILD_MODNAME);
+   aperture_remove_conflicting_devices(base, size, false, KBUILD_MODNAME);
 
if (gen2vm) {
/* framebuffer is reallocated, clear screen_info to avoid 
misuse from kexec */
-- 
2.39.0



[PATCH 04/18] drm/i915: Do not set struct fb_info.apertures

2022-12-19 Thread Thomas Zimmermann
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in i915.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 03ed4607a46d..bbdb98d7c96e 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -267,23 +267,16 @@ static int intelfb_create(struct drm_fb_helper *helper,
 
info->fbops = _ops;
 
-   /* setup aperture base/size for vesafb takeover */
obj = intel_fb_obj(_fb->base);
if (i915_gem_object_is_lmem(obj)) {
struct intel_memory_region *mem = obj->mm.region;
 
-   info->apertures->ranges[0].base = mem->io_start;
-   info->apertures->ranges[0].size = mem->io_size;
-
/* Use fbdev's framebuffer from lmem for discrete */
info->fix.smem_start =
(unsigned long)(mem->io_start +
i915_gem_object_get_dma_address(obj, 
0));
info->fix.smem_len = obj->base.size;
} else {
-   info->apertures->ranges[0].base = ggtt->gmadr.start;
-   info->apertures->ranges[0].size = ggtt->mappable_end;
-
/* Our framebuffer is the entirety of fbdev's system memory */
info->fix.smem_start =
(unsigned long)(ggtt->gmadr.start + 
i915_ggtt_offset(vma));
-- 
2.39.0



[PATCH 02/18] Revert "fbcon: don't lose the console font across generic->chip driver switch"

2022-12-19 Thread Thomas Zimmermann
This reverts commit ae1287865f5361fa138d4d3b1b6277908b54eac9.

Always free the console font when deinitializing the framebuffer
console. Subsequent framebuffer consoles will then use the default
font. Rely on userspace to load any user-configured font for these
consoles.

Commit ae1287865f53 ("fbcon: don't lose the console font across
generic->chip driver switch") was introduced to work around losing
the font during graphics-device handover. [1][2] It kept a dangling
pointer with the font data between loading the two consoles, which is
fairly adventurous hack. It also never covered cases when the other
consoles, such as VGA text mode, where involved.

The problem has meanwhile been solved in userspace. Systemd comes
with a udev rule that re-installs the configured font when a console
comes up. [3] So the kernel workaround can be removed.

This also removes one of the two special cases triggered by setting
FBINFO_MISC_FIRMWARE in an fbdev driver.

Tested during device handover from efifb and simpledrm to radeon. Udev
reloads the configured console font for the new driver's terminal.

Signed-off-by: Thomas Zimmermann 
Link: https://bugzilla.redhat.com/show_bug.cgi?id=892340 # 1
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1074624 # 2
Link: 
https://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/90-vconsole.rules.in?h=v222
 # 3
---
 drivers/video/fbdev/core/fbcon.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 500b26d652f6..90b36b3adfd0 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -958,7 +958,7 @@ static const char *fbcon_startup(void)
set_blitting_type(vc, info);
 
/* Setup default font */
-   if (!p->fontdata && !vc->vc_font.data) {
+   if (!p->fontdata) {
if (!fontname[0] || !(font = find_font(fontname)))
font = get_default_font(info->var.xres,
info->var.yres,
@@ -968,8 +968,6 @@ static const char *fbcon_startup(void)
vc->vc_font.height = font->height;
vc->vc_font.data = (void *)(p->fontdata = font->data);
vc->vc_font.charcount = font->charcount;
-   } else {
-   p->fontdata = vc->vc_font.data;
}
 
cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres);
@@ -1135,9 +1133,9 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->p = _display[fg_console];
 }
 
-static void fbcon_free_font(struct fbcon_display *p, bool freefont)
+static void fbcon_free_font(struct fbcon_display *p)
 {
-   if (freefont && p->userfont && p->fontdata && (--REFCOUNT(p->fontdata) 
== 0))
+   if (p->userfont && p->fontdata && (--REFCOUNT(p->fontdata) == 0))
kfree(p->fontdata - FONT_EXTRA_WORDS * sizeof(int));
p->fontdata = NULL;
p->userfont = 0;
@@ -1172,8 +1170,8 @@ static void fbcon_deinit(struct vc_data *vc)
struct fb_info *info;
struct fbcon_ops *ops;
int idx;
-   bool free_font = true;
 
+   fbcon_free_font(p);
idx = con2fb_map[vc->vc_num];
 
if (idx == -1)
@@ -1184,8 +1182,6 @@ static void fbcon_deinit(struct vc_data *vc)
if (!info)
goto finished;
 
-   if (info->flags & FBINFO_MISC_FIRMWARE)
-   free_font = false;
ops = info->fbcon_par;
 
if (!ops)
@@ -1197,9 +1193,8 @@ static void fbcon_deinit(struct vc_data *vc)
ops->initialized = false;
 finished:
 
-   fbcon_free_font(p, free_font);
-   if (free_font)
-   vc->vc_font.data = NULL;
+   fbcon_free_font(p);
+   vc->vc_font.data = NULL;
 
if (vc->vc_hi_font_mask && vc->vc_screenbuf)
set_vc_hi_font(vc, false);
-- 
2.39.0



Re: [Intel-gfx] [PATCH 1/2] drm/i915: Do not cover all future platforms in TLB invalidation

2022-12-19 Thread Andrzej Hajda

On 19.12.2022 11:13, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Revert to the original explicit approach and document the reasoning
behind it.

Signed-off-by: Tvrtko Ursulin 
Cc: Matt Roper 
Cc: Balasubramani Vivekanandan 
Cc: Andrzej Hajda 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/gt/intel_gt.c | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 75a7cb33..854841a731cb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1070,7 +1070,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
unsigned int num = 0;
unsigned long flags;
  
-	if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {

+   /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+   if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
regs = NULL;
num = ARRAY_SIZE(xehp_regs);
} else if (GRAPHICS_VER(i915) == 12) {




Re: [PATCH v2 6/7] drm: rcar-du: Bump V3U to gen 4

2022-12-19 Thread Kieran Bingham
Quoting Tomi Valkeinen (2022-12-19 14:01:38)
> V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the

s/Bumb/bump/

Reviewed-by: Kieran Bingham 

> rcar_du_r8a779a0_info.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 46c60a2d710d..c7c5217cfc1a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -504,7 +504,7 @@ static const struct rcar_du_device_info 
> rcar_du_r8a7799x_info = {
>  };
>  
>  static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
> -   .gen = 3,
> +   .gen = 4,
> .features = RCAR_DU_FEATURE_CRTC_IRQ
>   | RCAR_DU_FEATURE_VSP1_SOURCE
>   | RCAR_DU_FEATURE_NO_BLENDING,
> -- 
> 2.34.1
>


Re: [PATCH] drm: Replace DRM_INFO() with pr_info()

2022-12-19 Thread Thomas Zimmermann

Hi

Am 19.12.22 um 15:23 schrieb Siddh Raman Pant:

Line 536 of drm_print.h says DRM_INFO() is deprecated
in favor of pr_info().


That's a misleading comment. DRM_INFO() is deprecated for drm_info(). 
pr_info() et al is only to be used of you don't have a dev pointer.


Best regards
Thomas



Signed-off-by: Siddh Raman Pant 
---
  drivers/gpu/drm/drm_client_modeset.c |  2 +-
  drivers/gpu/drm/drm_connector.c  |  8 
  drivers/gpu/drm/drm_drv.c| 10 +-
  drivers/gpu/drm/drm_edid_load.c  | 14 +++---
  drivers/gpu/drm/drm_pci.c|  2 +-
  5 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..2e2891614c58 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -335,7 +335,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
DRM_DEBUG_KMS("can clone using 1024x768\n");
return true;
}
-   DRM_INFO("kms: can't enable cloning when we probably wanted to.\n");
+   pr_info("[drm] kms: can't enable cloning when we probably wanted 
to.\n");
return false;
  }
  
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c

index 61c29ce74b03..26a03b70e2c6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -165,14 +165,14 @@ static void drm_connector_get_cmdline_mode(struct 
drm_connector *connector)
return;
  
  	if (mode->force) {

-   DRM_INFO("forcing %s connector %s\n", connector->name,
-drm_get_connector_force_name(mode->force));
+   pr_info("[drm] forcing %s connector %s\n", connector->name,
+   drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
  
  	if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {

-   DRM_INFO("cmdline forces connector %s panel_orientation to 
%d\n",
-connector->name, mode->panel_orientation);
+   pr_info("[drm] cmdline forces connector %s panel_orientation to 
%d\n",
+   connector->name, mode->panel_orientation);
drm_connector_set_panel_orientation(connector,
mode->panel_orientation);
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 203bf8d6c34c..1486df097908 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -898,11 +898,11 @@ int drm_dev_register(struct drm_device *dev, unsigned 
long flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
  
-	DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",

-driver->name, driver->major, driver->minor,
-driver->patchlevel, driver->date,
-dev->dev ? dev_name(dev->dev) : "virtual device",
-dev->primary->index);
+   pr_info("[drm] Initialized %s %d.%d.%d %s for %s on minor %d\n",
+   driver->name, driver->major, driver->minor,
+   driver->patchlevel, driver->date,
+   dev->dev ? dev_name(dev->dev) : "virtual device",
+   dev->primary->index);
  
  	goto out_unlock;
  
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c

index 37d8ba3ddb46..d3cb198380c5 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -242,9 +242,9 @@ static void *edid_load(struct drm_connector *connector, 
const char *name,
u8 *new_edid;
  
  		edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;

-   DRM_INFO("Found %d valid extensions instead of %d in EDID data "
-   "\"%s\" for connector \"%s\"\n", valid_extensions,
-   edid[0x7e], name, connector_name);
+   pr_info("[drm] Found %d valid extensions instead of %d in EDID data 
"
+   "\"%s\" for connector \"%s\"\n", valid_extensions,
+   edid[0x7e], name, connector_name);
edid[0x7e] = valid_extensions;
  
  		new_edid = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH,

@@ -253,10 +253,10 @@ static void *edid_load(struct drm_connector *connector, 
const char *name,
edid = new_edid;
}
  
-	DRM_INFO("Got %s EDID base block and %d extension%s from "

-   "\"%s\" for connector \"%s\"\n", (builtin >= 0) ? "built-in" :
-   "external", valid_extensions, valid_extensions == 1 ? "" : "s",
-   name, connector_name);
+   pr_info("[drm] Got %s EDID base block and %d extension%s from "
+   "\"%s\" for connector \"%s\"\n", (builtin >= 0) ? "built-in" :
+   "external", valid_extensions, valid_extensions == 1 ? "" : "s",
+   name, 

Re: [PATCH v3] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML

2022-12-19 Thread Johan Jonker



On 12/19/22 14:04, Krzysztof Kozlowski wrote:
> On 19/12/2022 13:32, Johan Jonker wrote:
>> Convert rockchip-lvds.txt to YAML.
>>
>> Changed:
>>   Add power-domains property.
>>   Requirements between PX30 and RK3288
>>
>> Signed-off-by: Johan Jonker 
>> ---
>>
>> Changed V3:
>>   Filename matching compatible style
>>   Drop "Regulator phandle for "
>>   Specify properties and requirements per SoC
>>   Sort order and restyle
>>
>> Changed V2:
>>   Fix title
>> ---
>>  .../display/rockchip/rockchip,lvds.yaml   | 170 ++
>>  .../display/rockchip/rockchip-lvds.txt|  92 --
>>  2 files changed, 170 insertions(+), 92 deletions(-)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
>>  delete mode 100644 
>> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml 
>> b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
>> new file mode 100644
>> index 0..03b002a05
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
>> @@ -0,0 +1,170 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Rockchip low-voltage differential signal (LVDS) transmitter
>> +
>> +maintainers:
>> +  - Sandy Huang 
>> +  - Heiko Stuebner 
>> +
>> +properties:
>> +  compatible:
>> +enum:
>> +  - rockchip,px30-lvds
>> +  - rockchip,rk3288-lvds
>> +
>> +  reg:
>> +maxItems: 1
>> +
>> +  clocks:
>> +maxItems: 1
>> +
>> +  clock-names:
>> +const: pclk_lvds
>> +
>> +  avdd1v0-supply:
>> +description: 1.0V analog power.
>> +
>> +  avdd1v8-supply:
>> +description: 1.8V analog power.
>> +
>> +  avdd3v3-supply:
>> +description: 3.3V analog power.
>> +
>> +  rockchip,grf:
>> +$ref: /schemas/types.yaml#/definitions/phandle
>> +description: Phandle to the general register files syscon.
>> +
>> +  rockchip,output:
>> +$ref: /schemas/types.yaml#/definitions/string
>> +enum: [rgb, lvds, duallvds]
>> +description: This describes the output interface.
>> +
>> +  phys:
>> +maxItems: 1
>> +
>> +  phy-names:
>> +const: dphy
>> +
>> +  pinctrl-names:
>> +const: lcdc
>> +
>> +  pinctrl-0: true
>> +
>> +  power-domains:
>> +maxItems: 1
>> +
>> +  ports:
>> +$ref: /schemas/graph.yaml#/properties/ports
>> +
>> +properties:
>> +  port@0:
>> +$ref: /schemas/graph.yaml#/properties/port
>> +description:
>> +  Video port 0 for the VOP input.
>> +  The remote endpoint maybe vopb or vopl.
>> +
>> +  port@1:
>> +$ref: /schemas/graph.yaml#/properties/port
>> +description:
>> +  Video port 1 for either a panel or subsequent encoder.
>> +
>> +required:
>> +  - port@0
>> +  - port@1
>> +
>> +required:
>> +  - compatible
>> +  - rockchip,grf
>> +  - rockchip,output
>> +  - ports
>> +
>> +allOf:
>> +  - if:
>> +  properties:
>> +compatible:
>> +  contains:
>> +const: rockchip,px30-lvds
>> +
>> +then:
>> +  properties:
>> +reg: false
>> +clocks: false
>> +clock-names: false
>> +avdd1v0-supply: false
>> +avdd1v8-supply: false
>> +avdd3v3-supply: false
>> +
> 

> I see one compatible expects regmap from parent (grf is the parent here)
> and other is directly on MMIO bus. Not the best combination... Maybe
> this  should be just split to two separate bindings? Looking at driver,
> their code is also very different between these two variants.

Looking at the manufacturer tree we can expect the rest with grf parent, but 
also in the same driver combined with different registers and common probe.
Due to common probe I prefer one common document.

Johan

===

https://github.com/rockchip-linux/kernel/blob/develop-5.10/drivers/gpu/drm/rockchip/rockchip_lvds.c#L671


rockchip,rk3126-lvds
https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm/boot/dts/rk312x.dtsi#L914

rockchip,rk3368-lvds
https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm64/boot/dts/rockchip/rk3368.dtsi#L1196

rockchip,rk3568-lvds
https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm64/boot/dts/rockchip/rk3568.dtsi#L734

> 
> Best regards,
> Krzysztof
> 


[PATCH] drm/amd/display: Remove the unused function dmub_outbox_irq_info_funcs

2022-12-19 Thread Jiapeng Chong
The function dmub_outbox_irq_info_funcs is defined in the
irq_service_dcn201.c file, but not called elsewhere, so remove this
unused function.

drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:139:43:
 warning: unused variable 'dmub_outbox_irq_info_funcs'.

Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3520
Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 .../gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c   | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c 
b/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
index 5f4f6dd79511..27dc8c9955f4 100644
--- a/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
+++ b/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
@@ -136,11 +136,6 @@ static const struct irq_source_info_funcs 
vupdate_no_lock_irq_info_funcs = {
.ack = NULL
 };
 
-static const struct irq_source_info_funcs dmub_outbox_irq_info_funcs = {
-   .set = NULL,
-   .ack = NULL
-};
-
 #undef BASE_INNER
 #define BASE_INNER(seg) DMU_BASE__INST0_SEG ## seg
 
-- 
2.20.1.7.g153144c



[PATCH] drm/panfrost: Fix GEM handle creation ref-counting

2022-12-19 Thread Steven Price
panfrost_gem_create_with_handle() previously returned a BO but with the
only reference being from the handle, which user space could in theory
guess and release, causing a use-after-free. Additionally if the call to
panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then
a(nother) reference on the BO was dropped.

The _create_with_handle() is a problematic pattern, so ditch it and
instead create the handle in panfrost_ioctl_create_bo(). If the call to
panfrost_gem_mapping_get() fails then this means that user space has
indeed gone behind our back and freed the handle. In which case just
return an error code.

Reported-by: Rob Clark 
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Signed-off-by: Steven Price 
---
 drivers/gpu/drm/panfrost/panfrost_drv.c | 27 -
 drivers/gpu/drm/panfrost/panfrost_gem.c | 16 +--
 drivers/gpu/drm/panfrost/panfrost_gem.h |  5 +
 3 files changed, 20 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index fa619fe72086..abb0dadd8f63 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -82,6 +82,7 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev, 
void *data,
struct panfrost_gem_object *bo;
struct drm_panfrost_create_bo *args = data;
struct panfrost_gem_mapping *mapping;
+   int ret;
 
if (!args->size || args->pad ||
(args->flags & ~(PANFROST_BO_NOEXEC | PANFROST_BO_HEAP)))
@@ -92,21 +93,29 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev, 
void *data,
!(args->flags & PANFROST_BO_NOEXEC))
return -EINVAL;
 
-   bo = panfrost_gem_create_with_handle(file, dev, args->size, args->flags,
->handle);
+   bo = panfrost_gem_create(dev, args->size, args->flags);
if (IS_ERR(bo))
return PTR_ERR(bo);
 
+   ret = drm_gem_handle_create(file, >base.base, >handle);
+   if (ret)
+   goto out;
+
mapping = panfrost_gem_mapping_get(bo, priv);
-   if (!mapping) {
-   drm_gem_object_put(>base.base);
-   return -EINVAL;
+   if (mapping) {
+   args->offset = mapping->mmnode.start << PAGE_SHIFT;
+   panfrost_gem_mapping_put(mapping);
+   } else {
+   /* This can only happen if the handle from
+* drm_gem_handle_create() has already been guessed and freed
+* by user space
+*/
+   ret = -EINVAL;
}
 
-   args->offset = mapping->mmnode.start << PAGE_SHIFT;
-   panfrost_gem_mapping_put(mapping);
-
-   return 0;
+out:
+   drm_gem_object_put(>base.base);
+   return ret;
 }
 
 /**
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c 
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 293e799e2fe8..3c812fbd126f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -235,12 +235,8 @@ struct drm_gem_object *panfrost_gem_create_object(struct 
drm_device *dev, size_t
 }
 
 struct panfrost_gem_object *
-panfrost_gem_create_with_handle(struct drm_file *file_priv,
-   struct drm_device *dev, size_t size,
-   u32 flags,
-   uint32_t *handle)
+panfrost_gem_create(struct drm_device *dev, size_t size, u32 flags)
 {
-   int ret;
struct drm_gem_shmem_object *shmem;
struct panfrost_gem_object *bo;
 
@@ -256,16 +252,6 @@ panfrost_gem_create_with_handle(struct drm_file *file_priv,
bo->noexec = !!(flags & PANFROST_BO_NOEXEC);
bo->is_heap = !!(flags & PANFROST_BO_HEAP);
 
-   /*
-* Allocate an id of idr table where the obj is registered
-* and handle has the id what user can see.
-*/
-   ret = drm_gem_handle_create(file_priv, >base, handle);
-   /* drop reference from allocate - handle holds it now. */
-   drm_gem_object_put(>base);
-   if (ret)
-   return ERR_PTR(ret);
-
return bo;
 }
 
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h 
b/drivers/gpu/drm/panfrost/panfrost_gem.h
index 8088d5fd8480..ad2877eeeccd 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.h
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
@@ -69,10 +69,7 @@ panfrost_gem_prime_import_sg_table(struct drm_device *dev,
   struct sg_table *sgt);
 
 struct panfrost_gem_object *
-panfrost_gem_create_with_handle(struct drm_file *file_priv,
-   struct drm_device *dev, size_t size,
-   u32 flags,
-   uint32_t *handle);
+panfrost_gem_create(struct drm_device *dev, size_t size, u32 flags);
 
 int panfrost_gem_open(struct drm_gem_object *obj, struct drm_file *file_priv);
 void 

Re: [PATCH] drm/panfrost: Fix GEM handle creation UAF

2022-12-19 Thread Steven Price
On 16/12/2022 23:33, Rob Clark wrote:
> From: Rob Clark 
> 
> Relying on an unreturned handle to hold a reference to an object we
> dereference is not safe.  Userspace can guess the handle and race us
> by closing the handle from another thread.  The _create_with_handle()
> that returns an object ptr is pretty much a pattern to avoid.  And
> ideally creating the handle would be done after any needed dererencing.
> But in this case creation of the mapping is tied to the handle creation.
> Fortunately the mapping is refcnt'd and holds a reference to the object,
> so we can drop the handle's reference once we hold a mapping reference.

Thanks for spotting this, it's a small window but definitely a bug.

> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/panfrost/panfrost_drv.c |  7 +++
>  drivers/gpu/drm/panfrost/panfrost_gem.c | 10 +++---
>  2 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 2fa5afe21288..aa5848de647c 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -98,6 +98,13 @@ static int panfrost_ioctl_create_bo(struct drm_device 
> *dev, void *data,
>   return PTR_ERR(bo);
>  
>   mapping = panfrost_gem_mapping_get(bo, priv);
> +
> + /*
> +  * Now that the mapping holds a reference to the bo until we no longer
> +  * need it, we can safely drop the handle's reference.
> +  */
> + drm_gem_object_put(>base.base);
> +
>   if (!mapping) {
>   drm_gem_object_put(>base.base);

This !mapping call to drm_gem_object_put() is suspicious. It doesn't
make any sense and if it can be reached is going to drive the reference
count negative. So I don't think the bug is completely gone.

If user space does the trick of freeing the handle between the call to
panfrost_gem_create_with_handle() and panfrost_gem_mapping_get() then
even with the extra reference we now have the call to
panfrost_gem_mapping_get() will fail and two references are dropped.

I think the whole _create_with_handle() approach was a bad idea and it's
best to simply drop the _with_handle part. I'll post a patch tidying
this up along with removing the drm_gem_object_put() in the !mapping case.

Thanks,

Steve

>   return -EINVAL;
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c 
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 293e799e2fe8..e3e21c500d24 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -234,6 +234,10 @@ struct drm_gem_object *panfrost_gem_create_object(struct 
> drm_device *dev, size_t
>   return >base.base;
>  }
>  
> +/*
> + * NOTE: if this succeeds, both the handle and the returned object have
> + * an outstanding reference.
> + */
>  struct panfrost_gem_object *
>  panfrost_gem_create_with_handle(struct drm_file *file_priv,
>   struct drm_device *dev, size_t size,
> @@ -261,10 +265,10 @@ panfrost_gem_create_with_handle(struct drm_file 
> *file_priv,
>* and handle has the id what user can see.
>*/
>   ret = drm_gem_handle_create(file_priv, >base, handle);
> - /* drop reference from allocate - handle holds it now. */
> - drm_gem_object_put(>base);
> - if (ret)
> + if (ret) {
> + drm_gem_object_put(>base);
>   return ERR_PTR(ret);
> + }
>  
>   return bo;
>  }



Re: [PATCH v4 0/2] Make ILI9486 driver working with 16-bits SPI controllers

2022-12-19 Thread Neil Armstrong

Hi Kamlesh,

On 19/12/2022 10:02, Carlo Caione wrote:

This patchset is trying to fix problems seen on S905X boards when interfacing
with an ILI9486 equipped SPI panel.


I fully reviewed both patches, but I'd like a review from the maintainer,
can you have a look ?

Thanks,
Neil



To: Kamlesh Gurudasani 
To: David Airlie 
To: Daniel Vetter 
To: Mark Brown 
To: Neil Armstrong 
To: Kevin Hilman 
To: Jerome Brunet 
To: Martin Blumenstingl 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Signed-off-by: Carlo Caione 

---
Changes in v4:
- Removed NAK-ed patch from patchset
- Link to v3: 
https://lore.kernel.org/r/20221116-s905x_spi_ili9486-v3-0-59c6b58cb...@baylibre.com

Changes in v3:
- Added trailers
- Added new patch to use drm_aperture_remove_framebuffers()
- Link to v2: 
https://lore.kernel.org/r/20221116-s905x_spi_ili9486-v2-0-084c6e3cd...@baylibre.com

Changes in v2:
- Removed SPICC patch
- Reworked commit message
- Link to v1: 
https://lore.kernel.org/r/20221116-s905x_spi_ili9486-v1-0-630401cb6...@baylibre.com

---
Carlo Caione (2):
   drm/tiny: ili9486: Enable driver module autoloading
   drm/tiny: ili9486: Do not assume 8-bit only SPI controllers

  drivers/gpu/drm/tiny/ili9486.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)
---
base-commit: 84e57d292203a45c96dbcb2e6be9dd80961d981a
change-id: 20221116-s905x_spi_ili9486-aed54ff3cb21

Best regards,




Re: [PATCH] drm/meson: Reduce the FIFO lines held when AFBC is not used

2022-12-19 Thread Neil Armstrong

On 19/12/2022 12:00, Martin Blumenstingl wrote:

Hi Carlo,

On Mon, Dec 19, 2022 at 9:43 AM Carlo Caione  wrote:


Having a bigger number of FIFO lines held after vsync is only useful to
SoCs using AFBC to give time to the AFBC decoder to be reset, configured
and enabled again.

For SoCs not using AFBC this, on the contrary, is causing on some
displays issues and a few pixels vertical offset in the displayed image.

On the 32-bit SoCs (for which VPU support is not upstream yet) it has
caused screen tearing instead of shifting the image.


Conditionally increase the number of lines held after vsync only for
SoCs using AFBC, leaving the default value for all the others.

That was also my approach (for a not-yet-upstream patch).
Since it's affecting already supported SoCs I suggest adding
"Fixed-by: 24e0d4058eff ..." (maybe Neil can do so when he agrees and
is applying the patch).

Acked-by: Martin Blumenstingl 



Yep I'll add the Fixes tag when applying

Thank Carlo !

Acked-by: Neil Armstrong 



Re: [PATCH v2] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML

2022-12-19 Thread Rob Herring


On Sat, 17 Dec 2022 16:23:53 +0100, Johan Jonker wrote:
> Convert rockchip-lvds.txt to YAML.
> 
> Changed:
>   Add power-domains property.
>   Requirements between PX30 and RK3288
> 
> Signed-off-by: Johan Jonker 
> ---
> 
> Changed V2:
>   Fix title
> ---
>  .../display/rockchip/rockchip-lvds.txt|  92 --
>  .../display/rockchip/rockchip-lvds.yaml   | 157 ++
>  2 files changed, 157 insertions(+), 92 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:


doc reference errors (make refcheckdocs):
Documentation/devicetree/bindings/soc/rockchip/grf.yaml: 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt

See 
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/dea33013-ae1b-a8b2-5287-68a52f5ce...@gmail.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



Re: [PATCH v4 2/7] accel/ivpu: Add Intel VPU MMU support

2022-12-19 Thread Jacek Lawrynowicz
Hi,

On 18.12.2022 10:13, Oded Gabbay wrote:
> On Thu, Dec 8, 2022 at 1:08 PM Jacek Lawrynowicz
>  wrote:
>>
>> VPU Memory Management Unit is based on ARM MMU-600.
>> It allows the creation of multiple virtual address spaces for
>> the device and map noncontinuous host memory (there is no dedicated
>> memory on the VPU).
>>
>> Address space is implemented as a struct ivpu_mmu_context, it has an ID,
>> drm_mm allocator for VPU addresses and struct ivpu_mmu_pgtable that
>> holds actual 3-level, 4KB page table.
>> Context with ID 0 (global context) is created upon driver initialization
>> and it's mainly used for mapping memory required to execute
>> the firmware.
>> Contexts with non-zero IDs are user contexts allocated each time
>> the devices is open()-ed and they map command buffers and other
>> workload-related memory.
>> Workloads executing in a given contexts have access only
>> to the memory mapped in this context.
>>
>> This patch is has to main files:
> This patch has two main files:

OK

>>   - ivpu_mmu_context.c handles MMU page tables and memory mapping
>>   - ivpu_mmu.c implements a driver that programs the MMU device
>>
>> Co-developed-by: Karol Wachowski 
>> Signed-off-by: Karol Wachowski 
>> Co-developed-by: Krystian Pradzynski 
>> Signed-off-by: Krystian Pradzynski 
>> Signed-off-by: Jacek Lawrynowicz 
>> ---
>>  drivers/accel/ivpu/Makefile   |   4 +-
>>  drivers/accel/ivpu/ivpu_drv.c |  83 ++-
>>  drivers/accel/ivpu/ivpu_drv.h |   6 +
>>  drivers/accel/ivpu/ivpu_hw_mtl.c  |  10 +
>>  drivers/accel/ivpu/ivpu_mmu.c | 875 ++
>>  drivers/accel/ivpu/ivpu_mmu.h |  50 ++
>>  drivers/accel/ivpu/ivpu_mmu_context.c | 385 
>>  drivers/accel/ivpu/ivpu_mmu_context.h |  49 ++
>>  include/uapi/drm/ivpu_drm.h   |   4 +
>>  9 files changed, 1463 insertions(+), 3 deletions(-)
>>  create mode 100644 drivers/accel/ivpu/ivpu_mmu.c
>>  create mode 100644 drivers/accel/ivpu/ivpu_mmu.h
>>  create mode 100644 drivers/accel/ivpu/ivpu_mmu_context.c
>>  create mode 100644 drivers/accel/ivpu/ivpu_mmu_context.h
>>
>> diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
>> index 28330c04e52f..37b8bf1d3247 100644
>> --- a/drivers/accel/ivpu/Makefile
>> +++ b/drivers/accel/ivpu/Makefile
>> @@ -3,6 +3,8 @@
>>
>>  intel_vpu-y := \
>> ivpu_drv.o \
>> -   ivpu_hw_mtl.o
>> +   ivpu_hw_mtl.o \
>> +   ivpu_mmu.o \
>> +   ivpu_mmu_context.o
>>
>>  obj-$(CONFIG_DRM_ACCEL_IVPU) += intel_vpu.o
>> \ No newline at end of file
>> diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
>> index 8fbccb8d888b..a22d41ca5a4b 100644
>> --- a/drivers/accel/ivpu/ivpu_drv.c
>> +++ b/drivers/accel/ivpu/ivpu_drv.c
>> @@ -15,6 +15,8 @@
>>
>>  #include "ivpu_drv.h"
>>  #include "ivpu_hw.h"
>> +#include "ivpu_mmu.h"
>> +#include "ivpu_mmu_context.h"
>>
>>  #ifndef DRIVER_VERSION_STR
>>  #define DRIVER_VERSION_STR __stringify(DRM_IVPU_DRIVER_MAJOR) "." \
>> @@ -37,23 +39,38 @@ MODULE_PARM_DESC(pll_max_ratio, "Maximum PLL ratio used 
>> to set VPU frequency");
>>
>>  struct ivpu_file_priv *ivpu_file_priv_get(struct ivpu_file_priv *file_priv)
>>  {
>> +   struct ivpu_device *vdev = file_priv->vdev;
>> +
>> kref_get(_priv->ref);
>> +
>> +   ivpu_dbg(vdev, KREF, "file_priv get: ctx %u refcount %u\n",
>> +file_priv->ctx.id, kref_read(_priv->ref));
>> +
>> return file_priv;
>>  }
>>
>>  static void file_priv_release(struct kref *ref)
>>  {
>> struct ivpu_file_priv *file_priv = container_of(ref, struct 
>> ivpu_file_priv, ref);
>> +   struct ivpu_device *vdev = file_priv->vdev;
>>
>> +   ivpu_dbg(vdev, FILE, "file_priv release: ctx %u\n", 
>> file_priv->ctx.id);
>> +
>> +   ivpu_mmu_user_context_fini(vdev, _priv->ctx);
>> +   WARN_ON(xa_erase_irq(>context_xa, file_priv->ctx.id) != 
>> file_priv);
>> kfree(file_priv);
>>  }
>>
>>  void ivpu_file_priv_put(struct ivpu_file_priv **link)
>>  {
>> struct ivpu_file_priv *file_priv = *link;
>> +   struct ivpu_device *vdev = file_priv->vdev;
>>
>> WARN_ON(!file_priv);
>>
>> +   ivpu_dbg(vdev, KREF, "file_priv put: ctx %u refcount %u\n",
>> +file_priv->ctx.id, kref_read(_priv->ref));
>> +
>> *link = NULL;
>> kref_put(_priv->ref, file_priv_release);
>>  }
>> @@ -88,6 +105,9 @@ static int ivpu_get_param_ioctl(struct drm_device *dev, 
>> void *data, struct drm_f
>> case DRM_IVPU_PARAM_CONTEXT_PRIORITY:
>> args->value = file_priv->priority;
>> break;
>> +   case DRM_IVPU_PARAM_CONTEXT_ID:
>> +   args->value = file_priv->ctx.id;
> Why is this needed ? Why does the user need to know its context ID ?

This is not really needed by the user space, we only use this as a debug 
feature.

>> +   break;
>> default:
>> ret = -EINVAL;
>> break;
>> @@ 

Re: [PATCH v3] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML

2022-12-19 Thread Krzysztof Kozlowski
On 19/12/2022 13:32, Johan Jonker wrote:
> Convert rockchip-lvds.txt to YAML.
> 
> Changed:
>   Add power-domains property.
>   Requirements between PX30 and RK3288
> 
> Signed-off-by: Johan Jonker 
> ---
> 
> Changed V3:
>   Filename matching compatible style
>   Drop "Regulator phandle for "
>   Specify properties and requirements per SoC
>   Sort order and restyle
> 
> Changed V2:
>   Fix title
> ---
>  .../display/rockchip/rockchip,lvds.yaml   | 170 ++
>  .../display/rockchip/rockchip-lvds.txt|  92 --
>  2 files changed, 170 insertions(+), 92 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml 
> b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
> new file mode 100644
> index 0..03b002a05
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
> @@ -0,0 +1,170 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip low-voltage differential signal (LVDS) transmitter
> +
> +maintainers:
> +  - Sandy Huang 
> +  - Heiko Stuebner 
> +
> +properties:
> +  compatible:
> +enum:
> +  - rockchip,px30-lvds
> +  - rockchip,rk3288-lvds
> +
> +  reg:
> +maxItems: 1
> +
> +  clocks:
> +maxItems: 1
> +
> +  clock-names:
> +const: pclk_lvds
> +
> +  avdd1v0-supply:
> +description: 1.0V analog power.
> +
> +  avdd1v8-supply:
> +description: 1.8V analog power.
> +
> +  avdd3v3-supply:
> +description: 3.3V analog power.
> +
> +  rockchip,grf:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: Phandle to the general register files syscon.
> +
> +  rockchip,output:
> +$ref: /schemas/types.yaml#/definitions/string
> +enum: [rgb, lvds, duallvds]
> +description: This describes the output interface.
> +
> +  phys:
> +maxItems: 1
> +
> +  phy-names:
> +const: dphy
> +
> +  pinctrl-names:
> +const: lcdc
> +
> +  pinctrl-0: true
> +
> +  power-domains:
> +maxItems: 1
> +
> +  ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> +  port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Video port 0 for the VOP input.
> +  The remote endpoint maybe vopb or vopl.
> +
> +  port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Video port 1 for either a panel or subsequent encoder.
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - rockchip,grf
> +  - rockchip,output
> +  - ports
> +
> +allOf:
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: rockchip,px30-lvds
> +
> +then:
> +  properties:
> +reg: false
> +clocks: false
> +clock-names: false
> +avdd1v0-supply: false
> +avdd1v8-supply: false
> +avdd3v3-supply: false
> +

I see one compatible expects regmap from parent (grf is the parent here)
and other is directly on MMIO bus. Not the best combination... Maybe
this  should be just split to two separate bindings? Looking at driver,
their code is also very different between these two variants.

Best regards,
Krzysztof



[RESEND PATCH v4] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

2022-12-19 Thread Zheng Wang
If intel_gvt_dma_map_guest_page failed, it will call
 ppgtt_invalidate_spt, which will finally free the spt. But the caller does
 not notice that, it will free spt again in error path.

Fix this by undoing the mapping of DMA address and freeing sub_spt.

Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Signed-off-by: Zheng Wang 
---
v4:
- fix by undo the mapping of DMA address and free sub_spt suggested by Zhi

v3:
- correct spelling mistake and remove unused variable suggested by Greg

v2: https://lore.kernel.org/all/20221006165845.1735393-1-zyytlz...@163.com/

v1: https://lore.kernel.org/all/20220928033340.1063949-1-zyytlz...@163.com/
---
 drivers/gpu/drm/i915/gvt/gtt.c | 53 +-
 1 file changed, 46 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 51e5e8fb505b..b472e021e5a4 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1192,11 +1192,11 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
 {
const struct intel_gvt_gtt_pte_ops *ops = vgpu->gvt->gtt.pte_ops;
struct intel_vgpu_ppgtt_spt *sub_spt;
-   struct intel_gvt_gtt_entry sub_se;
+   struct intel_gvt_gtt_entry sub_se, e;
unsigned long start_gfn;
dma_addr_t dma_addr;
-   unsigned long sub_index;
-   int ret;
+   unsigned long sub_index, parent_index;
+   int ret, ret1;
 
gvt_dbg_mm("Split 2M gtt entry, index %lu\n", index);
 
@@ -1209,10 +1209,8 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
for_each_shadow_entry(sub_spt, _se, sub_index) {
ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn + sub_index,
   PAGE_SIZE, _addr);
-   if (ret) {
-   ppgtt_invalidate_spt(spt);
-   return ret;
-   }
+   if (ret)
+   goto err;
sub_se.val64 = se->val64;
 
/* Copy the PAT field from PDE. */
@@ -1231,6 +1229,47 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
ops->set_pfn(se, sub_spt->shadow_page.mfn);
ppgtt_set_shadow_entry(spt, se, index);
return 0;
+err:
+   /* Undone the existing mappings of DMA addr. */
+   for_each_present_shadow_entry(spt, , parent_index) {
+   switch (e.type) {
+   case GTT_TYPE_PPGTT_PTE_4K_ENTRY:
+   gvt_vdbg_mm("invalidate 4K entry\n");
+   ppgtt_invalidate_pte(spt, );
+   break;
+   case GTT_TYPE_PPGTT_PTE_64K_ENTRY:
+   /* We don't setup 64K shadow entry so far. */
+   WARN(1, "suspicious 64K gtt entry\n");
+   continue;
+   case GTT_TYPE_PPGTT_PTE_2M_ENTRY:
+   gvt_vdbg_mm("invalidate 2M entry\n");
+   continue;
+   case GTT_TYPE_PPGTT_PTE_1G_ENTRY:
+   WARN(1, "GVT doesn't support 1GB page\n");
+   continue;
+   case GTT_TYPE_PPGTT_PML4_ENTRY:
+   case GTT_TYPE_PPGTT_PDP_ENTRY:
+   case GTT_TYPE_PPGTT_PDE_ENTRY:
+   gvt_vdbg_mm("invalidate PMUL4/PDP/PDE entry\n");
+   ret1 = ppgtt_invalidate_spt_by_shadow_entry(
+   spt->vgpu, );
+   if (ret1) {
+   gvt_vgpu_err("fail: shadow page %p shadow entry 
0x%llx type %d\n",
+   spt, e.val64, e.type);
+   goto free_spt;
+   }
+   break;
+   default:
+   GEM_BUG_ON(1);
+   }
+   }
+   /* Release the new alloced apt. */
+free_spt:
+   trace_spt_change(sub_spt->vgpu->id, "release", sub_spt,
+   sub_spt->guest_page.gfn, sub_spt->shadow_page.type);
+   ppgtt_free_spt(sub_spt);
+   sub_spt = NULL;
+   return ret;
 }
 
 static int split_64KB_gtt_entry(struct intel_vgpu *vgpu,
-- 
2.25.1



Re: [PATCH v4 0/7] Introduce debugfs device-centered functions

2022-12-19 Thread Melissa Wen
On 12/19, Maíra Canal wrote:
> This series introduces the initial structure to make DRM debugfs more
> device-centered and it is the first step to drop the
> drm_driver->debugfs_init hooks in the future [1].
> 
> Currently, DRM debugfs files are created using drm_debugfs_create_files()
> on request. The first patch of this series makes it possible for DRM devices
> for creating debugfs files during drm_dev_register(). For it, it introduces
> two new functions that can be used by the drivers: drm_debugfs_add_files()
> and drm_debugfs_add_file(). The requests are added to a list and are created
> all at once during drm_dev_register(). Moreover, the first patch was based on
> this RFC series [2].
> 
> The main difference between the RFC series and the current series is the
> creation of a new fops structure to accommodate the new structs and, also,
> the creation of a new drm_debugfs_open. Moreover, the new series uses
> device-managed allocation, returns memory allocation errors, and converts
> more drivers to the new structure.
> 
> Moreover, since v3, the ability to create debugfs files at late_register 
> hooks was
> added. In previous versions, modeset components weren't able to create debugfs
> files at late_register hooks as the registration of drm_minor happens before 
> the
> registration of the modeset abstractions. So, the third patch fixes this 
> problem
> by adding a drm_debugfs_late_register() function. Thanks to Melissa Wen for
> catching this problem!
> 
> Apart from the third patch, the series looks similiar from its last version.
> 
> [1] https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/todo.rst#n506
> [2] 
> https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karu...@gmail.com/
> 
> Best Regards,
> - Maíra Canal
> 
> ---
> 
> v1 -> v2: 
> https://lore.kernel.org/dri-devel/20221122190314.185015-1-mca...@igalia.com/T/#t
> 
> - Fix compilation errors in the second patch (kernel test robot).
> - Drop debugfs_init hook from vkms (Maíra Canal).
> - Remove return values and error handling to debugfs related
> functions (Jani Nikula).
> - Remove entry from list after the file is created, so that drm_debugfs_init
> can be called more than once (Maíra Canal).
> 
> v2 -> v3: 
> https://lore.kernel.org/dri-devel/20221123220725.1272155-1-mca...@igalia.com/
> 
> - Rebase on top of drm-misc-next
> 
> v3 -> v4: 
> https://lore.kernel.org/dri-devel/20221207132325.140393-1-mca...@igalia.com/
> 
> - Add Maxime's Reviewed-by tags
> - Add the ability to create debugfs files at late_register hooks (Melissa 
> Wen).

Hi Maíra,

Thanks for addressing all comments.

Maybe Danvet has some inputs for the late_register approach.

Anyway, LGTM and the entire series is:

Reviewed-by: Melissa Wen 

> 
> ---
> 
> Maíra Canal (7):
>   drm/debugfs: create device-centered debugfs functions
>   drm: use new debugfs device-centered functions on DRM core files
>   drm/debugfs: create debugfs late register functions
>   drm/vc4: use new debugfs device-centered functions
>   drm/v3d: use new debugfs device-centered functions
>   drm/vkms: use new debugfs device-centered functions
>   drm/todo: update the debugfs clean up task
> 
>  Documentation/gpu/todo.rst|   9 +--
>  drivers/gpu/drm/drm_atomic.c  |  11 ++-
>  drivers/gpu/drm/drm_client.c  |  11 ++-
>  drivers/gpu/drm/drm_debugfs.c | 102 +++---
>  drivers/gpu/drm/drm_drv.c |   3 +
>  drivers/gpu/drm/drm_framebuffer.c |  11 ++-
>  drivers/gpu/drm/drm_gem_vram_helper.c |  11 ++-
>  drivers/gpu/drm/drm_internal.h|   5 ++
>  drivers/gpu/drm/drm_mode_config.c |   2 +
>  drivers/gpu/drm/v3d/v3d_debugfs.c |  22 +++---
>  drivers/gpu/drm/vc4/vc4_bo.c  |  10 +--
>  drivers/gpu/drm/vc4/vc4_crtc.c|   7 +-
>  drivers/gpu/drm/vc4/vc4_debugfs.c |  36 ++---
>  drivers/gpu/drm/vc4/vc4_dpi.c |   5 +-
>  drivers/gpu/drm/vc4/vc4_drv.c |   1 -
>  drivers/gpu/drm/vc4/vc4_drv.h |  32 ++--
>  drivers/gpu/drm/vc4/vc4_dsi.c |   6 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.c|  12 +--
>  drivers/gpu/drm/vc4/vc4_hvs.c |  24 ++
>  drivers/gpu/drm/vc4/vc4_v3d.c |  14 +---
>  drivers/gpu/drm/vc4/vc4_vec.c |   6 +-
>  drivers/gpu/drm/vkms/vkms_drv.c   |  17 ++---
>  include/drm/drm_debugfs.h |  41 +++
>  include/drm/drm_device.h  |  15 
>  24 files changed, 233 insertions(+), 180 deletions(-)
> 
> -- 
> 2.38.1
> 


signature.asc
Description: PGP signature


[PATCH v4] [PATCH v4] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

2022-12-19 Thread Zheng Wang
If intel_gvt_dma_map_guest_page failed, it will call
 ppgtt_invalidate_spt, which will finally free the spt. But the caller does
 not notice that, it will free spt again in error path.

Fix this by undoing the mapping of DMA address and freeing sub_spt.

Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Signed-off-by: Zheng Wang 
---
v4:
- fix by undo the mapping of DMA address and free sub_spt suggested by Zhi

v3:
- correct spelling mistake and remove unused variable suggested by Greg

v2: https://lore.kernel.org/all/20221006165845.1735393-1-zyytlz...@163.com/

v1: https://lore.kernel.org/all/20220928033340.1063949-1-zyytlz...@163.com/
---
 drivers/gpu/drm/i915/gvt/gtt.c | 58 +-
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 45271acc5038..b472e021e5a4 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1209,7 +1209,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
for_each_shadow_entry(sub_spt, _se, sub_index) {
ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn + sub_index,
   PAGE_SIZE, _addr);
-   if (ret) 
+   if (ret)
goto err;
sub_se.val64 = se->val64;
 
@@ -1233,34 +1233,34 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
/* Undone the existing mappings of DMA addr. */
for_each_present_shadow_entry(spt, , parent_index) {
switch (e.type) {
-   case GTT_TYPE_PPGTT_PTE_4K_ENTRY:
-   gvt_vdbg_mm("invalidate 4K entry\n");
-   ppgtt_invalidate_pte(spt, );
-   break;
-   case GTT_TYPE_PPGTT_PTE_64K_ENTRY:
-   /* We don't setup 64K shadow entry so far. */
-   WARN(1, "suspicious 64K gtt entry\n");
-   continue;
-   case GTT_TYPE_PPGTT_PTE_2M_ENTRY:
-   gvt_vdbg_mm("invalidate 2M entry\n");
-   continue;
-   case GTT_TYPE_PPGTT_PTE_1G_ENTRY:
-   WARN(1, "GVT doesn't support 1GB page\n");
-   continue;
-   case GTT_TYPE_PPGTT_PML4_ENTRY:
-   case GTT_TYPE_PPGTT_PDP_ENTRY:
-   case GTT_TYPE_PPGTT_PDE_ENTRY:
-   gvt_vdbg_mm("invalidate PMUL4/PDP/PDE entry\n");
-   ret1 = ppgtt_invalidate_spt_by_shadow_entry(
-   spt->vgpu, );
-   if (ret1) {
-   gvt_vgpu_err("fail: shadow page %p 
shadow entry 0x%llx type %d\n",
-   spt, e.val64, e.type);
-   goto free_spt;
-   }
-   break;
-   default:
-   GEM_BUG_ON(1);
+   case GTT_TYPE_PPGTT_PTE_4K_ENTRY:
+   gvt_vdbg_mm("invalidate 4K entry\n");
+   ppgtt_invalidate_pte(spt, );
+   break;
+   case GTT_TYPE_PPGTT_PTE_64K_ENTRY:
+   /* We don't setup 64K shadow entry so far. */
+   WARN(1, "suspicious 64K gtt entry\n");
+   continue;
+   case GTT_TYPE_PPGTT_PTE_2M_ENTRY:
+   gvt_vdbg_mm("invalidate 2M entry\n");
+   continue;
+   case GTT_TYPE_PPGTT_PTE_1G_ENTRY:
+   WARN(1, "GVT doesn't support 1GB page\n");
+   continue;
+   case GTT_TYPE_PPGTT_PML4_ENTRY:
+   case GTT_TYPE_PPGTT_PDP_ENTRY:
+   case GTT_TYPE_PPGTT_PDE_ENTRY:
+   gvt_vdbg_mm("invalidate PMUL4/PDP/PDE entry\n");
+   ret1 = ppgtt_invalidate_spt_by_shadow_entry(
+   spt->vgpu, );
+   if (ret1) {
+   gvt_vgpu_err("fail: shadow page %p shadow entry 
0x%llx type %d\n",
+   spt, e.val64, e.type);
+   goto free_spt;
+   }
+   break;
+   default:
+   GEM_BUG_ON(1);
}
}
/* Release the new alloced apt. */
-- 
2.25.1



Re: [RFC PATCH 0/4] Add RGB ttl connection on rockchip phy

2022-12-19 Thread Michael Nazzareno Trimarchi
Hi all

On Sun, Oct 2, 2022 at 8:45 AM Michael Trimarchi
 wrote:
>
> The rockchip phy can be convigured in ttl mode. The phy is shared
> between lvds, dsi, ttl. The configuration that now I'm able to support
> has the display output on some set of pins on standard vop output
> and a set of pins using the ttl phy. The solution is not clean as I
> would like to have because some register that are used to enable
> the TTL, are in the same register area of the dsi controller.
> In order to test I must add the following
>
> dsi_dphy: phy@ff2e {
>
> reg = <0x0 0xff2e 0x0 0x1>,
> <0x0 0xff45 0x0 0x1>;
> ...
> }
>
> The problem here is the second region I have added is the same of
> dsi logic. Only one register is needed by the the phy driver
>

Is there anyone who has time to review it?

Michael

> Michael Trimarchi (4):
>   phy: add PHY_MODE_TTL
>   phy: rockchip: Add inno_is_valid_phy_mode
>   phy: rockchip: Implement TTY phy mode
>   drm/rockchip: rgb: Add dphy connection to rgb output
>
>  drivers/gpu/drm/rockchip/rockchip_rgb.c   | 18 +
>  .../phy/rockchip/phy-rockchip-inno-dsidphy.c  | 72 +++
>  include/linux/phy/phy.h   |  3 +-
>  3 files changed, 92 insertions(+), 1 deletion(-)
>
> --
> 2.34.1
>


-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com


[PATCH v3] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML

2022-12-19 Thread Johan Jonker
Convert rockchip-lvds.txt to YAML.

Changed:
  Add power-domains property.
  Requirements between PX30 and RK3288

Signed-off-by: Johan Jonker 
---

Changed V3:
  Filename matching compatible style
  Drop "Regulator phandle for "
  Specify properties and requirements per SoC
  Sort order and restyle

Changed V2:
  Fix title
---
 .../display/rockchip/rockchip,lvds.yaml   | 170 ++
 .../display/rockchip/rockchip-lvds.txt|  92 --
 2 files changed, 170 insertions(+), 92 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
 delete mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
new file mode 100644
index 0..03b002a05
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip low-voltage differential signal (LVDS) transmitter
+
+maintainers:
+  - Sandy Huang 
+  - Heiko Stuebner 
+
+properties:
+  compatible:
+enum:
+  - rockchip,px30-lvds
+  - rockchip,rk3288-lvds
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: pclk_lvds
+
+  avdd1v0-supply:
+description: 1.0V analog power.
+
+  avdd1v8-supply:
+description: 1.8V analog power.
+
+  avdd3v3-supply:
+description: 3.3V analog power.
+
+  rockchip,grf:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: Phandle to the general register files syscon.
+
+  rockchip,output:
+$ref: /schemas/types.yaml#/definitions/string
+enum: [rgb, lvds, duallvds]
+description: This describes the output interface.
+
+  phys:
+maxItems: 1
+
+  phy-names:
+const: dphy
+
+  pinctrl-names:
+const: lcdc
+
+  pinctrl-0: true
+
+  power-domains:
+maxItems: 1
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Video port 0 for the VOP input.
+  The remote endpoint maybe vopb or vopl.
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Video port 1 for either a panel or subsequent encoder.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - rockchip,grf
+  - rockchip,output
+  - ports
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: rockchip,px30-lvds
+
+then:
+  properties:
+reg: false
+clocks: false
+clock-names: false
+avdd1v0-supply: false
+avdd1v8-supply: false
+avdd3v3-supply: false
+
+  required:
+- phys
+- phy-names
+
+  - if:
+  properties:
+compatible:
+  contains:
+const: rockchip,rk3288-lvds
+
+then:
+  properties:
+phys: false
+phy-names: false
+
+  required:
+- reg
+- clocks
+- clock-names
+- avdd1v0-supply
+- avdd1v8-supply
+- avdd3v3-supply
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+lvds: lvds@ff96c000 {
+  compatible = "rockchip,rk3288-lvds";
+  reg = <0xff96c000 0x4000>;
+  clocks = < PCLK_LVDS_PHY>;
+  clock-names = "pclk_lvds";
+  avdd1v0-supply = <_lcd>;
+  avdd1v8-supply = <_lcd>;
+  avdd3v3-supply = <_33>;
+  pinctrl-names = "lcdc";
+  pinctrl-0 = <_ctl>;
+  rockchip,grf = <>;
+  rockchip,output = "rgb";
+
+  ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lvds_in: port@0 {
+  reg = <0>;
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  lvds_in_vopb: endpoint@0 {
+reg = <0>;
+remote-endpoint = <_out_lvds>;
+  };
+  lvds_in_vopl: endpoint@1 {
+reg = <1>;
+remote-endpoint = <_out_lvds>;
+  };
+};
+
+lvds_out: port@1 {
+  reg = <1>;
+
+  lvds_out_panel: endpoint {
+remote-endpoint = <_in_lvds>;
+  };
+};
+  };
+};
diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
deleted file mode 100644
index aaf8c44cf..0
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-Rockchip RK3288 LVDS interface
-
-
-Required properties:
-- compatible: matching the soc type, one of
-   - "rockchip,rk3288-lvds";
-   - "rockchip,px30-lvds";
-

[PATCH v4 7/7] drm/todo: update the debugfs clean up task

2022-12-19 Thread Maíra Canal
The structs drm_debugfs_info and drm_debugfs_entry introduced a new
debugfs structure to DRM, centered on drm_device instead of drm_minor.
Therefore, remove the tasks related to create a new device-centered
debugfs structure and add a new task to replace the use of
drm_debugfs_create_files() for the use of drm_debugfs_add_file() and
drm_debugfs_add_files().

Signed-off-by: Maíra Canal 
---
 Documentation/gpu/todo.rst | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index b2c6aaf1edf2..f64abf69f341 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -508,17 +508,14 @@ Clean up the debugfs support
 
 There's a bunch of issues with it:
 
-- The drm_info_list ->show() function doesn't even bother to cast to the drm
-  structure for you. This is lazy.
+- Convert drivers to support the drm_debugfs_add_files() function instead of
+  the drm_debugfs_create_files() function.
 
 - We probably want to have some support for debugfs files on crtc/connectors 
and
   maybe other kms objects directly in core. There's even drm_print support in
   the funcs for these objects to dump kms state, so it's all there. And then 
the
   ->show() functions should obviously give you a pointer to the right object.
 
-- The drm_info_list stuff is centered on drm_minor instead of drm_device. For
-  anything we want to print drm_device (or maybe drm_file) is the right thing.
-
 - The drm_driver->debugfs_init hooks we have is just an artifact of the old
   midlayered load sequence. DRM debugfs should work more like sysfs, where you
   can create properties/files for an object anytime you want, and the core
@@ -527,8 +524,6 @@ There's a bunch of issues with it:
   this (together with the drm_minor->drm_device move) would allow us to remove
   debugfs_init.
 
-Previous RFC that hasn't landed yet: 
https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karu...@gmail.com/
-
 Contact: Daniel Vetter
 
 Level: Intermediate
-- 
2.38.1



[PATCH v4 5/7] drm/v3d: use new debugfs device-centered functions

2022-12-19 Thread Maíra Canal
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which centers the debugfs files
management on the drm_device instead of drm_minor.

Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/v3d/v3d_debugfs.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c 
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index efbde124c296..330669f51fa7 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -79,8 +79,8 @@ static const struct v3d_reg_def v3d_csd_reg_defs[] = {
 
 static int v3d_v3d_debugfs_regs(struct seq_file *m, void *unused)
 {
-   struct drm_info_node *node = (struct drm_info_node *)m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
struct v3d_dev *v3d = to_v3d_dev(dev);
int i, core;
 
@@ -126,8 +126,8 @@ static int v3d_v3d_debugfs_regs(struct seq_file *m, void 
*unused)
 
 static int v3d_v3d_debugfs_ident(struct seq_file *m, void *unused)
 {
-   struct drm_info_node *node = (struct drm_info_node *)m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
struct v3d_dev *v3d = to_v3d_dev(dev);
u32 ident0, ident1, ident2, ident3, cores;
int core;
@@ -188,8 +188,8 @@ static int v3d_v3d_debugfs_ident(struct seq_file *m, void 
*unused)
 
 static int v3d_debugfs_bo_stats(struct seq_file *m, void *unused)
 {
-   struct drm_info_node *node = (struct drm_info_node *)m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
struct v3d_dev *v3d = to_v3d_dev(dev);
 
mutex_lock(>bo_lock);
@@ -204,8 +204,8 @@ static int v3d_debugfs_bo_stats(struct seq_file *m, void 
*unused)
 
 static int v3d_measure_clock(struct seq_file *m, void *unused)
 {
-   struct drm_info_node *node = (struct drm_info_node *)m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
struct v3d_dev *v3d = to_v3d_dev(dev);
uint32_t cycles;
int core = 0;
@@ -236,7 +236,7 @@ static int v3d_measure_clock(struct seq_file *m, void 
*unused)
return 0;
 }
 
-static const struct drm_info_list v3d_debugfs_list[] = {
+static const struct drm_debugfs_info v3d_debugfs_list[] = {
{"v3d_ident", v3d_v3d_debugfs_ident, 0},
{"v3d_regs", v3d_v3d_debugfs_regs, 0},
{"measure_clock", v3d_measure_clock, 0},
@@ -246,7 +246,5 @@ static const struct drm_info_list v3d_debugfs_list[] = {
 void
 v3d_debugfs_init(struct drm_minor *minor)
 {
-   drm_debugfs_create_files(v3d_debugfs_list,
-ARRAY_SIZE(v3d_debugfs_list),
-minor->debugfs_root, minor);
+   drm_debugfs_add_files(minor->dev, v3d_debugfs_list, 
ARRAY_SIZE(v3d_debugfs_list));
 }
-- 
2.38.1



[PATCH v4 4/7] drm/vc4: use new debugfs device-centered functions

2022-12-19 Thread Maíra Canal
Currently, vc4 has its own debugfs infrastructure that adds the debugfs
files on drm_dev_register(). With the introduction of the new debugfs,
functions, replace the vc4 debugfs structure with the DRM debugfs
device-centered function, drm_debugfs_add_file().

Moreover, remove the explicit error handling of debugfs related functions,
considering that the only failure mode is -ENOMEM and also that error
handling is not recommended for debugfs functions, as pointed out in [1].

[1] https://lore.kernel.org/all/ywamzdrwnat6w...@kroah.com/

Reviewed-by: Maxime Ripard 
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/vc4/vc4_bo.c  | 10 +++--
 drivers/gpu/drm/vc4/vc4_crtc.c|  7 ++
 drivers/gpu/drm/vc4/vc4_debugfs.c | 36 ++-
 drivers/gpu/drm/vc4/vc4_dpi.c |  5 +
 drivers/gpu/drm/vc4/vc4_drv.c |  1 -
 drivers/gpu/drm/vc4/vc4_drv.h | 32 ++-
 drivers/gpu/drm/vc4/vc4_dsi.c |  6 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c| 12 ---
 drivers/gpu/drm/vc4/vc4_hvs.c | 24 ++---
 drivers/gpu/drm/vc4/vc4_v3d.c | 14 
 drivers/gpu/drm/vc4/vc4_vec.c |  6 +-
 11 files changed, 37 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 43d9b3a6a352..c2b7573bd92b 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -69,8 +69,8 @@ static void vc4_bo_stats_print(struct drm_printer *p, struct 
vc4_dev *vc4)
 
 static int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
 {
-   struct drm_info_node *node = (struct drm_info_node *)m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_printer p = drm_seq_file_printer(m);
 
@@ -993,15 +993,11 @@ int vc4_bo_debugfs_init(struct drm_minor *minor)
 {
struct drm_device *drm = minor->dev;
struct vc4_dev *vc4 = to_vc4_dev(drm);
-   int ret;
 
if (!vc4->v3d)
return -ENODEV;
 
-   ret = vc4_debugfs_add_file(minor, "bo_stats",
-  vc4_bo_stats_debugfs, NULL);
-   if (ret)
-   return ret;
+   drm_debugfs_add_file(drm, "bo_stats", vc4_bo_stats_debugfs, NULL);
 
return 0;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index a1a3465948c4..35a6b5907278 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -1090,12 +1090,9 @@ int vc4_crtc_late_register(struct drm_crtc *crtc)
struct drm_device *drm = crtc->dev;
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
const struct vc4_crtc_data *crtc_data = 
vc4_crtc_to_vc4_crtc_data(vc4_crtc);
-   int ret;
 
-   ret = vc4_debugfs_add_regset32(drm->primary, crtc_data->debugfs_name,
-  _crtc->regset);
-   if (ret)
-   return ret;
+   vc4_debugfs_add_regset32(drm, crtc_data->debugfs_name,
+_crtc->regset);
 
return 0;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_debugfs.c 
b/drivers/gpu/drm/vc4/vc4_debugfs.c
index 19cda4f91a82..fac624a663ea 100644
--- a/drivers/gpu/drm/vc4/vc4_debugfs.c
+++ b/drivers/gpu/drm/vc4/vc4_debugfs.c
@@ -34,9 +34,9 @@ vc4_debugfs_init(struct drm_minor *minor)
 
 static int vc4_debugfs_regset32(struct seq_file *m, void *unused)
 {
-   struct drm_info_node *node = (struct drm_info_node *)m->private;
-   struct drm_device *drm = node->minor->dev;
-   struct debugfs_regset32 *regset = node->info_ent->data;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *drm = entry->dev;
+   struct debugfs_regset32 *regset = entry->file.data;
struct drm_printer p = drm_seq_file_printer(m);
int idx;
 
@@ -50,31 +50,9 @@ static int vc4_debugfs_regset32(struct seq_file *m, void 
*unused)
return 0;
 }
 
-int vc4_debugfs_add_file(struct drm_minor *minor,
-const char *name,
-int (*show)(struct seq_file*, void*),
-void *data)
+void vc4_debugfs_add_regset32(struct drm_device *drm,
+ const char *name,
+ struct debugfs_regset32 *regset)
 {
-   struct drm_device *dev = minor->dev;
-   struct dentry *root = minor->debugfs_root;
-   struct drm_info_list *file;
-
-   file = drmm_kzalloc(dev, sizeof(*file), GFP_KERNEL);
-   if (!file)
-   return -ENOMEM;
-
-   file->name = name;
-   file->show = show;
-   file->data = data;
-
-   drm_debugfs_create_files(file, 1, root, minor);
-
-   return 0;
-}
-
-int vc4_debugfs_add_regset32(struct drm_minor *minor,
-const char *name,
-struct 

[PATCH v4 6/7] drm/vkms: use new debugfs device-centered functions

2022-12-19 Thread Maíra Canal
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which centers the debugfs files
management on the drm_device instead of drm_minor. Moreover, remove the
debugfs_init hook and add the debugfs files directly on vkms_create(),
before drm_dev_register().

Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/vkms/vkms_drv.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 69346906ec81..6d3a2d57d992 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -92,8 +92,8 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state 
*old_state)
 
 static int vkms_config_show(struct seq_file *m, void *data)
 {
-   struct drm_info_node *node = (struct drm_info_node *)m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
 
seq_printf(m, "writeback=%d\n", vkmsdev->config->writeback);
@@ -103,24 +103,16 @@ static int vkms_config_show(struct seq_file *m, void 
*data)
return 0;
 }
 
-static const struct drm_info_list vkms_config_debugfs_list[] = {
+static const struct drm_debugfs_info vkms_config_debugfs_list[] = {
{ "vkms_config", vkms_config_show, 0 },
 };
 
-static void vkms_config_debugfs_init(struct drm_minor *minor)
-{
-   drm_debugfs_create_files(vkms_config_debugfs_list, 
ARRAY_SIZE(vkms_config_debugfs_list),
-minor->debugfs_root, minor);
-}
-
 static const struct drm_driver vkms_driver = {
.driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
.release= vkms_release,
.fops   = _driver_fops,
DRM_GEM_SHMEM_DRIVER_OPS,
 
-   .debugfs_init   = vkms_config_debugfs_init,
-
.name   = DRIVER_NAME,
.desc   = DRIVER_DESC,
.date   = DRIVER_DATE,
@@ -202,6 +194,9 @@ static int vkms_create(struct vkms_config *config)
if (ret)
goto out_devres;
 
+   drm_debugfs_add_files(_device->drm, vkms_config_debugfs_list,
+ ARRAY_SIZE(vkms_config_debugfs_list));
+
ret = drm_dev_register(_device->drm, 0);
if (ret)
goto out_devres;
-- 
2.38.1



[PATCH v4 2/7] drm: use new debugfs device-centered functions on DRM core files

2022-12-19 Thread Maíra Canal
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function in all DRM core files, centering the
debugfs files management on the drm_device instead of drm_minor.

Reviewed-by: Maxime Ripard 
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/drm_atomic.c  | 11 +--
 drivers/gpu/drm/drm_client.c  | 11 +--
 drivers/gpu/drm/drm_debugfs.c | 18 --
 drivers/gpu/drm/drm_framebuffer.c | 11 +--
 drivers/gpu/drm/drm_gem_vram_helper.c | 11 +--
 5 files changed, 28 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e666799a46d5..5457c02ca1ab 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1756,8 +1756,8 @@ EXPORT_SYMBOL(drm_state_dump);
 #ifdef CONFIG_DEBUG_FS
 static int drm_state_info(struct seq_file *m, void *data)
 {
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
struct drm_printer p = drm_seq_file_printer(m);
 
__drm_state_dump(dev, , true);
@@ -1766,14 +1766,13 @@ static int drm_state_info(struct seq_file *m, void 
*data)
 }
 
 /* any use in debugfs files to dump individual planes/crtc/etc? */
-static const struct drm_info_list drm_atomic_debugfs_list[] = {
+static const struct drm_debugfs_info drm_atomic_debugfs_list[] = {
{"state", drm_state_info, 0},
 };
 
 void drm_atomic_debugfs_init(struct drm_minor *minor)
 {
-   drm_debugfs_create_files(drm_atomic_debugfs_list,
-ARRAY_SIZE(drm_atomic_debugfs_list),
-minor->debugfs_root, minor);
+   drm_debugfs_add_files(minor->dev, drm_atomic_debugfs_list,
+ ARRAY_SIZE(drm_atomic_debugfs_list));
 }
 #endif
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index fd67efe37c63..262ec64d4397 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -480,8 +480,8 @@ EXPORT_SYMBOL(drm_client_framebuffer_flush);
 #ifdef CONFIG_DEBUG_FS
 static int drm_client_debugfs_internal_clients(struct seq_file *m, void *data)
 {
-   struct drm_info_node *node = m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
struct drm_printer p = drm_seq_file_printer(m);
struct drm_client_dev *client;
 
@@ -493,14 +493,13 @@ static int drm_client_debugfs_internal_clients(struct 
seq_file *m, void *data)
return 0;
 }
 
-static const struct drm_info_list drm_client_debugfs_list[] = {
+static const struct drm_debugfs_info drm_client_debugfs_list[] = {
{ "internal_clients", drm_client_debugfs_internal_clients, 0 },
 };
 
 void drm_client_debugfs_init(struct drm_minor *minor)
 {
-   drm_debugfs_create_files(drm_client_debugfs_list,
-ARRAY_SIZE(drm_client_debugfs_list),
-minor->debugfs_root, minor);
+   drm_debugfs_add_files(minor->dev, drm_client_debugfs_list,
+ ARRAY_SIZE(drm_client_debugfs_list));
 }
 #endif
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 988fc07b94b4..d9d3ed7acc80 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -51,9 +51,8 @@
 
 static int drm_name_info(struct seq_file *m, void *data)
 {
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_minor *minor = node->minor;
-   struct drm_device *dev = minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
struct drm_master *master;
 
mutex_lock(>master_mutex);
@@ -73,8 +72,8 @@ static int drm_name_info(struct seq_file *m, void *data)
 
 static int drm_clients_info(struct seq_file *m, void *data)
 {
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
struct drm_file *priv;
kuid_t uid;
 
@@ -125,8 +124,8 @@ static int drm_gem_one_name_info(int id, void *ptr, void 
*data)
 
 static int drm_gem_name_info(struct seq_file *m, void *data)
 {
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
 
seq_printf(m, "  name size handles refcount\n");
 
@@ -137,7 +136,7 @@ static int drm_gem_name_info(struct seq_file *m, void *data)
return 0;
 }
 
-static const struct drm_info_list drm_debugfs_list[] = {
+static const struct 

[PATCH v4 3/7] drm/debugfs: create debugfs late register functions

2022-12-19 Thread Maíra Canal
Although the device-centered debugfs functions can track requests for
the addition of DRM debugfs files at any time and have them added all
at once during drm_dev_register(), they are not able to create debugfs
files for modeset components, as they are registered after the primary
and the render drm_minor are registered.

So, create a drm_debugfs_late_register() function, which is responsible
for dealing with the creation of all the debugfs files for modeset
components at once. Therefore, the functions drm_debugfs_add_file()
and drm_debugfs_add_files() can be used in late_register hooks.

Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/drm_debugfs.c | 14 ++
 drivers/gpu/drm/drm_internal.h|  5 +
 drivers/gpu/drm/drm_mode_config.c |  2 ++
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index d9d3ed7acc80..51e3772e2e2b 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -254,6 +254,20 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
return 0;
 }
 
+void drm_debugfs_late_register(struct drm_device *dev)
+{
+   struct drm_minor *minor = dev->primary;
+   struct drm_debugfs_entry *entry, *tmp;
+
+   if (minor == NULL)
+   return;
+
+   list_for_each_entry_safe(entry, tmp, >debugfs_list, list) {
+   debugfs_create_file(entry->file.name, S_IFREG | S_IRUGO,
+   minor->debugfs_root, entry, 
_debugfs_entry_fops);
+   list_del(>list);
+   }
+}
 
 int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
 struct drm_minor *minor)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 5ea5e260118c..ed2103ee272c 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -186,6 +186,7 @@ int drm_gem_dumb_destroy(struct drm_file *file, struct 
drm_device *dev,
 int drm_debugfs_init(struct drm_minor *minor, int minor_id,
 struct dentry *root);
 void drm_debugfs_cleanup(struct drm_minor *minor);
+void drm_debugfs_late_register(struct drm_device *dev);
 void drm_debugfs_connector_add(struct drm_connector *connector);
 void drm_debugfs_connector_remove(struct drm_connector *connector);
 void drm_debugfs_crtc_add(struct drm_crtc *crtc);
@@ -202,6 +203,10 @@ static inline void drm_debugfs_cleanup(struct drm_minor 
*minor)
 {
 }
 
+static inline void drm_debugfs_late_register(struct drm_device *dev)
+{
+}
+
 static inline void drm_debugfs_connector_add(struct drm_connector *connector)
 {
 }
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index 8525ef851540..87eb591fe9b5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -54,6 +54,8 @@ int drm_modeset_register_all(struct drm_device *dev)
if (ret)
goto err_connector;
 
+   drm_debugfs_late_register(dev);
+
return 0;
 
 err_connector:
-- 
2.38.1



[PATCH v4 0/7] Introduce debugfs device-centered functions

2022-12-19 Thread Maíra Canal
This series introduces the initial structure to make DRM debugfs more
device-centered and it is the first step to drop the
drm_driver->debugfs_init hooks in the future [1].

Currently, DRM debugfs files are created using drm_debugfs_create_files()
on request. The first patch of this series makes it possible for DRM devices
for creating debugfs files during drm_dev_register(). For it, it introduces
two new functions that can be used by the drivers: drm_debugfs_add_files()
and drm_debugfs_add_file(). The requests are added to a list and are created
all at once during drm_dev_register(). Moreover, the first patch was based on
this RFC series [2].

The main difference between the RFC series and the current series is the
creation of a new fops structure to accommodate the new structs and, also,
the creation of a new drm_debugfs_open. Moreover, the new series uses
device-managed allocation, returns memory allocation errors, and converts
more drivers to the new structure.

Moreover, since v3, the ability to create debugfs files at late_register hooks 
was
added. In previous versions, modeset components weren't able to create debugfs
files at late_register hooks as the registration of drm_minor happens before the
registration of the modeset abstractions. So, the third patch fixes this problem
by adding a drm_debugfs_late_register() function. Thanks to Melissa Wen for
catching this problem!

Apart from the third patch, the series looks similiar from its last version.

[1] https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/todo.rst#n506
[2] 
https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karu...@gmail.com/

Best Regards,
- Maíra Canal

---

v1 -> v2: 
https://lore.kernel.org/dri-devel/20221122190314.185015-1-mca...@igalia.com/T/#t

- Fix compilation errors in the second patch (kernel test robot).
- Drop debugfs_init hook from vkms (Maíra Canal).
- Remove return values and error handling to debugfs related
functions (Jani Nikula).
- Remove entry from list after the file is created, so that drm_debugfs_init
can be called more than once (Maíra Canal).

v2 -> v3: 
https://lore.kernel.org/dri-devel/20221123220725.1272155-1-mca...@igalia.com/

- Rebase on top of drm-misc-next

v3 -> v4: 
https://lore.kernel.org/dri-devel/20221207132325.140393-1-mca...@igalia.com/

- Add Maxime's Reviewed-by tags
- Add the ability to create debugfs files at late_register hooks (Melissa Wen).

---

Maíra Canal (7):
  drm/debugfs: create device-centered debugfs functions
  drm: use new debugfs device-centered functions on DRM core files
  drm/debugfs: create debugfs late register functions
  drm/vc4: use new debugfs device-centered functions
  drm/v3d: use new debugfs device-centered functions
  drm/vkms: use new debugfs device-centered functions
  drm/todo: update the debugfs clean up task

 Documentation/gpu/todo.rst|   9 +--
 drivers/gpu/drm/drm_atomic.c  |  11 ++-
 drivers/gpu/drm/drm_client.c  |  11 ++-
 drivers/gpu/drm/drm_debugfs.c | 102 +++---
 drivers/gpu/drm/drm_drv.c |   3 +
 drivers/gpu/drm/drm_framebuffer.c |  11 ++-
 drivers/gpu/drm/drm_gem_vram_helper.c |  11 ++-
 drivers/gpu/drm/drm_internal.h|   5 ++
 drivers/gpu/drm/drm_mode_config.c |   2 +
 drivers/gpu/drm/v3d/v3d_debugfs.c |  22 +++---
 drivers/gpu/drm/vc4/vc4_bo.c  |  10 +--
 drivers/gpu/drm/vc4/vc4_crtc.c|   7 +-
 drivers/gpu/drm/vc4/vc4_debugfs.c |  36 ++---
 drivers/gpu/drm/vc4/vc4_dpi.c |   5 +-
 drivers/gpu/drm/vc4/vc4_drv.c |   1 -
 drivers/gpu/drm/vc4/vc4_drv.h |  32 ++--
 drivers/gpu/drm/vc4/vc4_dsi.c |   6 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|  12 +--
 drivers/gpu/drm/vc4/vc4_hvs.c |  24 ++
 drivers/gpu/drm/vc4/vc4_v3d.c |  14 +---
 drivers/gpu/drm/vc4/vc4_vec.c |   6 +-
 drivers/gpu/drm/vkms/vkms_drv.c   |  17 ++---
 include/drm/drm_debugfs.h |  41 +++
 include/drm/drm_device.h  |  15 
 24 files changed, 233 insertions(+), 180 deletions(-)

-- 
2.38.1



[PATCH v4 1/7] drm/debugfs: create device-centered debugfs functions

2022-12-19 Thread Maíra Canal
Introduce the ability to track requests for the addition of DRM debugfs
files at any time and have them added all at once during
drm_dev_register().

Drivers can add DRM debugfs files to a device-managed list and, during
drm_dev_register(), all added files will be created at once.

Now, the drivers can use the functions drm_debugfs_add_file() and
drm_debugfs_add_files() to create DRM debugfs files instead of using the
drm_debugfs_create_files() function.

Co-developed-by: Wambui Karuga 
Signed-off-by: Wambui Karuga 
Reviewed-by: Maxime Ripard 
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/drm_debugfs.c | 70 +++
 drivers/gpu/drm/drm_drv.c |  3 ++
 include/drm/drm_debugfs.h | 41 
 include/drm/drm_device.h  | 15 
 4 files changed, 129 insertions(+)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index ee445f4605ba..988fc07b94b4 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -151,6 +152,21 @@ static int drm_debugfs_open(struct inode *inode, struct 
file *file)
return single_open(file, node->info_ent->show, node);
 }
 
+static int drm_debugfs_entry_open(struct inode *inode, struct file *file)
+{
+   struct drm_debugfs_entry *entry = inode->i_private;
+   struct drm_debugfs_info *node = >file;
+
+   return single_open(file, node->show, entry);
+}
+
+static const struct file_operations drm_debugfs_entry_fops = {
+   .owner = THIS_MODULE,
+   .open = drm_debugfs_entry_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+};
 
 static const struct file_operations drm_debugfs_fops = {
.owner = THIS_MODULE,
@@ -207,6 +223,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
 struct dentry *root)
 {
struct drm_device *dev = minor->dev;
+   struct drm_debugfs_entry *entry, *tmp;
char name[64];
 
INIT_LIST_HEAD(>debugfs_list);
@@ -230,6 +247,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
if (dev->driver->debugfs_init)
dev->driver->debugfs_init(minor);
 
+   list_for_each_entry_safe(entry, tmp, >debugfs_list, list) {
+   debugfs_create_file(entry->file.name, S_IFREG | S_IRUGO,
+   minor->debugfs_root, entry, 
_debugfs_entry_fops);
+   list_del(>list);
+   }
+
return 0;
 }
 
@@ -281,6 +304,53 @@ void drm_debugfs_cleanup(struct drm_minor *minor)
minor->debugfs_root = NULL;
 }
 
+/**
+ * drm_debugfs_add_file - Add a given file to the DRM device debugfs file list
+ * @dev: drm device for the ioctl
+ * @name: debugfs file name
+ * @show: show callback
+ * @data: driver-private data, should not be device-specific
+ *
+ * Add a given file entry to the DRM device debugfs file list to be created on
+ * drm_debugfs_init.
+ */
+void drm_debugfs_add_file(struct drm_device *dev, const char *name,
+ int (*show)(struct seq_file*, void*), void *data)
+{
+   struct drm_debugfs_entry *entry = drmm_kzalloc(dev, sizeof(*entry), 
GFP_KERNEL);
+
+   if (!entry)
+   return;
+
+   entry->file.name = name;
+   entry->file.show = show;
+   entry->file.data = data;
+   entry->dev = dev;
+
+   mutex_lock(>debugfs_mutex);
+   list_add(>list, >debugfs_list);
+   mutex_unlock(>debugfs_mutex);
+}
+EXPORT_SYMBOL(drm_debugfs_add_file);
+
+/**
+ * drm_debugfs_add_files - Add an array of files to the DRM device debugfs 
file list
+ * @dev: drm device for the ioctl
+ * @files: The array of files to create
+ * @count: The number of files given
+ *
+ * Add a given set of debugfs files represented by an array of
+ *  drm_debugfs_info in the DRM device debugfs file list.
+ */
+void drm_debugfs_add_files(struct drm_device *dev, const struct 
drm_debugfs_info *files, int count)
+{
+   int i;
+
+   for (i = 0; i < count; i++)
+   drm_debugfs_add_file(dev, files[i].name, files[i].show, 
files[i].data);
+}
+EXPORT_SYMBOL(drm_debugfs_add_files);
+
 static int connector_show(struct seq_file *m, void *data)
 {
struct drm_connector *connector = m->private;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 203bf8d6c34c..c287488c776f 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -575,6 +575,7 @@ static void drm_dev_init_release(struct drm_device *dev, 
void *res)
mutex_destroy(>clientlist_mutex);
mutex_destroy(>filelist_mutex);
mutex_destroy(>struct_mutex);
+   mutex_destroy(>debugfs_mutex);
drm_legacy_destroy_members(dev);
 }
 
@@ -608,12 +609,14 @@ static int drm_dev_init(struct drm_device *dev,
INIT_LIST_HEAD(>filelist_internal);

Re: [PATCH v2] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML

2022-12-19 Thread Krzysztof Kozlowski
On 17/12/2022 16:23, Johan Jonker wrote:
> Convert rockchip-lvds.txt to YAML.
> 
> Changed:
>   Add power-domains property.
>   Requirements between PX30 and RK3288
> 
> Signed-off-by: Johan Jonker 
> ---
> 
> Changed V2:
>   Fix title
> ---
>  .../display/rockchip/rockchip-lvds.txt|  92 --
>  .../display/rockchip/rockchip-lvds.yaml   | 157 ++
>  2 files changed, 157 insertions(+), 92 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt 
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> deleted file mode 100644
> index aaf8c44cf..0
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> +++ /dev/null
> @@ -1,92 +0,0 @@
> -Rockchip RK3288 LVDS interface
> -
> -
> -Required properties:
> -- compatible: matching the soc type, one of
> - - "rockchip,rk3288-lvds";
> - - "rockchip,px30-lvds";
> -
> -- reg: physical base address of the controller and length
> - of memory mapped region.
> -- clocks: must include clock specifiers corresponding to entries in the
> - clock-names property.
> -- clock-names: must contain "pclk_lvds"
> -
> -- avdd1v0-supply: regulator phandle for 1.0V analog power
> -- avdd1v8-supply: regulator phandle for 1.8V analog power
> -- avdd3v3-supply: regulator phandle for 3.3V analog power
> -
> -- rockchip,grf: phandle to the general register files syscon
> -- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output 
> interface
> -
> -- phys: LVDS/DSI DPHY (px30 only)
> -- phy-names: name of the PHY, must be "dphy" (px30 only)
> -
> -Optional properties:
> -- pinctrl-names: must contain a "lcdc" entry.
> -- pinctrl-0: pin control group to be used for this controller.
> -
> -Required nodes:
> -
> -The lvds has two video ports as described by
> - Documentation/devicetree/bindings/media/video-interfaces.txt
> -Their connections are modeled using the OF graph bindings specified in
> - Documentation/devicetree/bindings/graph.txt.
> -
> -- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
> -- video port 1 for either a panel or subsequent encoder
> -
> -Example:
> -
> -lvds_panel: lvds-panel {
> - compatible = "auo,b101ean01";
> - enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
> - data-mapping = "jeida-24";
> -
> - ports {
> - panel_in_lvds: endpoint {
> - remote-endpoint = <_out_panel>;
> - };
> - };
> -};
> -
> -For Rockchip RK3288:
> -
> - lvds: lvds@ff96c000 {
> - compatible = "rockchip,rk3288-lvds";
> - rockchip,grf = <>;
> - reg = <0xff96c000 0x4000>;
> - clocks = < PCLK_LVDS_PHY>;
> - clock-names = "pclk_lvds";
> - pinctrl-names = "lcdc";
> - pinctrl-0 = <_ctl>;
> - avdd1v0-supply = <_lcd>;
> - avdd1v8-supply = <_lcd>;
> - avdd3v3-supply = <_33>;
> - rockchip,output = "rgb";
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - lvds_in: port@0 {
> - reg = <0>;
> -
> - lvds_in_vopb: endpoint@0 {
> - reg = <0>;
> - remote-endpoint = <_out_lvds>;
> - };
> - lvds_in_vopl: endpoint@1 {
> - reg = <1>;
> - remote-endpoint = <_out_lvds>;
> - };
> - };
> -
> - lvds_out: port@1 {
> - reg = <1>;
> -
> - lvds_out_panel: endpoint {
> - remote-endpoint = <_in_lvds>;
> - };
> - };
> - };
> - };
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.yaml 
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.yaml
> new file mode 100644
> index 0..f05901633
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.yaml

Filename matching compatible style, so: "rockchip,lvds.yaml"

> @@ -0,0 +1,157 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/rockchip/rockchip-lvds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip low-voltage differential signal (LVDS) transmitter
> +
> +maintainers:
> +  - Sandy Huang 
> +  - Heiko Stuebner 
> +
> +properties:
> +  compatible:
> +

  1   2   >