[PATCH v3 1/4] irq: export kstat_irqs

[Jerry Snitselaar]

To try and detect potential interrupt storms that
have been occurring with tpm_tis devices it was suggested
to use kstat_irqs() to get the number of interrupts.
Since tpm_tis can be built as a module it needs kstat_irqs
exported.

Reported-by: kernel test robot 
Cc: Thomas Gleixner 
Cc: Jarkko Sakkinen 
Cc: Jason Gunthorpe 
Cc: Peter Huewe 
Cc: James Bottomley 
Cc: Matthew Garrett 
Cc: Hans de Goede 
Signed-off-by: Jerry Snitselaar 
---
 include/linux/irqdesc.h | 1 +
 kernel/irq/irqdesc.c| 1 +
 2 files changed, 2 insertions(+)

diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index 5745491303e0..fff88c1f1ac6 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -153,6 +153,7 @@ static inline void generic_handle_irq_desc(struct irq_desc 
*desc)
 }
 
 int generic_handle_irq(unsigned int irq);
+unsigned int kstat_irqs(unsigned int irq);
 
 #ifdef CONFIG_HANDLE_DOMAIN_IRQ
 /*
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 1a7723604399..12398ef1796b 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -1000,6 +1000,7 @@ unsigned int kstat_irqs(unsigned int irq)
sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
return sum;
 }
+EXPORT_SYMBOL_GPL(kstat_irqs);
 
 /**
  * kstat_irqs_usr - Get the statistics for an interrupt
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 4/4] tpm_tis: Disable Interrupts on the ThinkPad L490

[Jerry Snitselaar]

The interrupt storm detection code detects the issue on the ThinkPad
T490s, but the L490 still hangs at initialization. So swap out the
T490s for the L490 in the dmi check.

Cc: Jarkko Sakkinen 
Cc: Jason Gunthorpe 
Cc: Peter Huewe 
Cc: James Bottomley 
Cc: Matthew Garrett 
Cc: Hans de Goede 
Signed-off-by: Jerry Snitselaar 
---
 drivers/char/tpm/tpm_tis.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 4ed6e660273a..7322e0986a83 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -77,10 +77,10 @@ static int tpm_tis_disable_irq(const struct dmi_system_id 
*d)
 static const struct dmi_system_id tpm_tis_dmi_table[] = {
{
.callback = tpm_tis_disable_irq,
-   .ident = "ThinkPad T490s",
+   .ident = "ThinkPad L490",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-   DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T490s"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L490"),
},
},
{}
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count

[Jerry Snitselaar]

Now that kstat_irqs is exported, get rid of count_interrupts in
i915_pmu.c

Cc: Thomas Gleixner 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: intel-...@lists.freedesktop.org 
Cc: dri-devel@lists.freedesktop.org
Cc: Jarkko Sakkinen 
Cc: Jason Gunthorpe 
Cc: Peter Huewe 
Cc: James Bottomley 
Cc: Matthew Garrett 
Cc: Hans de Goede 
Signed-off-by: Jerry Snitselaar 
---
 drivers/gpu/drm/i915/i915_pmu.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 69c0fa20eba1..a3e63f03da8c 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample(struct hrtimer 
*hrtimer)
return HRTIMER_RESTART;
 }
 
-static u64 count_interrupts(struct drm_i915_private *i915)
-{
-   /* open-coded kstat_irqs() */
-   struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq);
-   u64 sum = 0;
-   int cpu;
-
-   if (!desc || !desc->kstat_irqs)
-   return 0;
-
-   for_each_possible_cpu(cpu)
-   sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
-
-   return sum;
-}
-
 static void i915_pmu_event_destroy(struct perf_event *event)
 {
struct drm_i915_private *i915 =
@@ -581,7 +565,7 @@ static u64 __i915_pmu_event_read(struct perf_event *event)
   USEC_PER_SEC /* to MHz */);
break;
case I915_PMU_INTERRUPTS:
-   val = count_interrupts(i915);
+   val = kstat_irqs(i915->drm.pdev->irq);
break;
case I915_PMU_RC6_RESIDENCY:
val = get_rc6(>gt);
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected

[Jerry Snitselaar]

When enabling the interrupt code for the tpm_tis driver we have
noticed some systems have a bios issue causing an interrupt storm to
occur. The issue isn't limited to a single tpm or system manufacturer
so keeping a denylist of systems with the issue isn't optimal. Instead
try to detect the problem occurring, disable interrupts, and revert to
polling when it happens.

Cc: Jarkko Sakkinen 
Cc: Jason Gunthorpe 
Cc: Peter Huewe 
Cc: James Bottomley 
Cc: Matthew Garrett 
Cc: Hans de Goede 
Signed-off-by: Jerry Snitselaar 
---
v3: - Change include from linux/kernel_stat.h to linux/irq.h
v2: - drop tpm_tis specific workqueue and use just system_w

drivers/char/tpm/tpm_tis_core.c | 27 +++
 drivers/char/tpm/tpm_tis_core.h |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index 92c51c6cfd1b..d817ff5664d1 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "tpm.h"
 #include "tpm_tis_core.h"
 
@@ -715,9 +717,23 @@ static irqreturn_t tis_int_handler(int dummy, void *dev_id)
 {
struct tpm_chip *chip = dev_id;
struct tpm_tis_data *priv = dev_get_drvdata(>dev);
+   static bool check_storm = true;
+   static unsigned int check_start;
u32 interrupt;
int i, rc;
 
+   if (unlikely(check_storm)) {
+   if (!check_start) {
+   check_start = jiffies_to_msecs(jiffies);
+   } else if ((kstat_irqs(priv->irq) > 1000) &&
+  (jiffies_to_msecs(jiffies) - check_start < 500)) {
+   check_storm = false;
+   schedule_work(>storm_work);
+   } else if (jiffies_to_msecs(jiffies) - check_start >= 500) {
+   check_storm = false;
+   }
+   }
+
rc = tpm_tis_read32(priv, TPM_INT_STATUS(priv->locality), );
if (rc < 0)
return IRQ_NONE;
@@ -943,6 +959,14 @@ static const struct tpm_class_ops tpm_tis = {
.clk_enable = tpm_tis_clkrun_enable,
 };
 
+static void tpm_tis_storm_work(struct work_struct *work)
+{
+   struct tpm_tis_data *priv = container_of(work, struct tpm_tis_data, 
storm_work);
+
+   disable_interrupts(priv->chip);
+   dev_warn(>chip->dev, "Interrupt storm detected, using 
polling.\n");
+}
+
 int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq,
  const struct tpm_tis_phy_ops *phy_ops,
  acpi_handle acpi_dev_handle)
@@ -959,6 +983,9 @@ int tpm_tis_core_init(struct device *dev, struct 
tpm_tis_data *priv, int irq,
if (IS_ERR(chip))
return PTR_ERR(chip);
 
+   priv->chip = chip;
+   INIT_WORK(>storm_work, tpm_tis_storm_work);
+
 #ifdef CONFIG_ACPI
chip->acpi_dev_handle = acpi_dev_handle;
 #endif
diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
index 9b2d32a59f67..973297ee2e16 100644
--- a/drivers/char/tpm/tpm_tis_core.h
+++ b/drivers/char/tpm/tpm_tis_core.h
@@ -95,6 +95,8 @@ struct tpm_tis_data {
u16 clkrun_enabled;
wait_queue_head_t int_queue;
wait_queue_head_t read_queue;
+   struct work_struct storm_work;
+   struct tpm_chip *chip;
const struct tpm_tis_phy_ops *phy_ops;
unsigned short rng_quality;
 };
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/4] tpm_tis: Detect interrupt storms

[Jerry Snitselaar]

This patchset is an attempt to try and catch tpm_tis devices that have
interrupt storm issues, disable the interrupt, and use polling. In
2016 the tpm_tis interrupt code was accidently disabled, and polling
was just being used. When we initially tried to enable interrupts
again there were some reports of systems being hit with interrupt
storms. It turned out that the ThinkPad T490s had misconfigured a gpio
pin being used for the interrupt.  The problem is more widespread
though, with interrupt storms also being seen on other platforms and
different TPM vendors. With the L490 the system hangs at tpm_tis
initialization even with the detection code, so change the earlier
detection code that used dmi to look for the T490s to instead look for
the L490 and disable interrupts.

Since kstat_irqs needs to be exported to allow building of tpm_tis
as a module, I've included a patch to change the i915_pmu code to
use kstat_irqs where before it was using its own version. If this
isn't desired it can be dropped.

I've been testing this on top of James' proposed patchset which
re-enables interrupts for tpm_tis. With the patchsets applied
it detects the problem on the T490s and on the Ice Lake development
system where I found the issue. I have Lenovo verifying that the
dmi detection code will now detect the L490 and avoid the hang
it experiences. I'm also working on getting access to an L490
to see if I can figure out what the underlying issue is.



Changes from v2:
- Export kstat_irqs to allow building tpm_tis as a module.
- Change i915_pmu.c to use kstat_irqs instead of it's own
  version count_interrupts.
- Change include from linux/kernel_stat.h to linux/irq.h.
- Change dmi checking code to now look for L490 instead of
  T490s.

Changes from v1:
- drop tpm_tis specific workqueue and use just system_w.

Jerry Snitselaar (4):
  irq: export kstat_irqs
  drm/i915/pmu: Use kstat_irqs to get interrupt count
  tpm_tis: Disable interrupts if interrupt storm detected
  tpm_tis: Disable Interrupts on the ThinkPad L490


Cc: Thomas Gleixner 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: intel-...@lists.freedesktop.org 
Cc: dri-devel@lists.freedesktop.org
Cc: Jarkko Sakkinen 
Cc: Jason Gunthorpe 
Cc: Peter Huewe 
Cc: James Bottomley 
Cc: Matthew Garrett 
Cc: Hans de Goede 
Cc: linux-integr...@vger.kernel.org

 drivers/char/tpm/tpm_tis.c  |  4 ++--
 drivers/char/tpm/tpm_tis_core.c | 27 +++
 drivers/char/tpm/tpm_tis_core.h |  2 ++
 drivers/gpu/drm/i915/i915_pmu.c | 18 +-
 include/linux/irqdesc.h |  1 +
 kernel/irq/irqdesc.c|  1 +
 6 files changed, 34 insertions(+), 19 deletions(-)

-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: automatic legacy gamma support

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thu, Dec 03, 2020 at 01:48:45PM +0200, Tomi Valkeinen wrote:
> To support legacy gamma ioctls the drivers need to set
> drm_crtc_funcs.gamma_set either to a custom implementation or to
> drm_atomic_helper_legacy_gamma_set. Most of the atomic drivers do the
> latter.
> 
> We can simplify this by making the core handle it automatically.
> 
> Add two functions: drm_crtc_supports_legacy_gamma() which tells if the
> legacy gamma table can be set, and drm_crtc_legacy_gamma_set() which
> does the work by either calling the drm_crtc_funcs.gamma_set or using
> GAMMA_LUT or DEGAMMA_LUT.
> 
> We can then drop drm_atomic_helper_legacy_gamma_set() and remove all its
> uses.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   1 -
>  .../gpu/drm/arm/display/komeda/komeda_crtc.c  |   1 -
>  drivers/gpu/drm/arm/malidp_crtc.c |   1 -
>  drivers/gpu/drm/armada/armada_crtc.c  |   1 -
>  drivers/gpu/drm/ast/ast_mode.c|   1 -
>  .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c|   1 -
>  drivers/gpu/drm/drm_atomic_helper.c   |  82 -
>  drivers/gpu/drm/drm_color_mgmt.c  | 113 +-
>  drivers/gpu/drm/drm_fb_helper.c   |  12 +-
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c |   2 -
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c   |   1 -
>  drivers/gpu/drm/nouveau/dispnv50/head.c   |   2 -
>  drivers/gpu/drm/omapdrm/omap_crtc.c   |   1 -
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   1 -
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |   1 -
>  drivers/gpu/drm/stm/ltdc.c|   1 -
>  drivers/gpu/drm/vc4/vc4_crtc.c|   1 -
>  drivers/gpu/drm/vc4/vc4_txp.c |   1 -
>  include/drm/drm_atomic_helper.h   |   4 -
>  include/drm/drm_color_mgmt.h  |   7 ++
>  20 files changed, 123 insertions(+), 112 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 2855bb918535..848b06c51b0e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5396,7 +5396,6 @@ static void dm_disable_vblank(struct drm_crtc *crtc)
>  static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs = {
>   .reset = dm_crtc_reset_state,
>   .destroy = amdgpu_dm_crtc_destroy,
> - .gamma_set = drm_atomic_helper_legacy_gamma_set,
>   .set_config = drm_atomic_helper_set_config,
>   .page_flip = drm_atomic_helper_page_flip,
>   .atomic_duplicate_state = dm_crtc_duplicate_state,
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 4b485eb512e2..59172acb9738 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -550,7 +550,6 @@ static void komeda_crtc_vblank_disable(struct drm_crtc 
> *crtc)
>  }
>  
>  static const struct drm_crtc_funcs komeda_crtc_funcs = {
> - .gamma_set  = drm_atomic_helper_legacy_gamma_set,
>   .destroy= drm_crtc_cleanup,
>   .set_config = drm_atomic_helper_set_config,
>   .page_flip  = drm_atomic_helper_page_flip,
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index 108e7a31bd26..494075ddbef6 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -510,7 +510,6 @@ static void malidp_crtc_disable_vblank(struct drm_crtc 
> *crtc)
>  }
>  
>  static const struct drm_crtc_funcs malidp_crtc_funcs = {
> - .gamma_set = drm_atomic_helper_legacy_gamma_set,
>   .destroy = drm_crtc_cleanup,
>   .set_config = drm_atomic_helper_set_config,
>   .page_flip = drm_atomic_helper_page_flip,
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 3ebcf5a52c8b..b7bb90ae787f 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -820,7 +820,6 @@ static const struct drm_crtc_funcs armada_crtc_funcs = {
>   .cursor_set = armada_drm_crtc_cursor_set,
>   .cursor_move= armada_drm_crtc_cursor_move,
>   .destroy= armada_drm_crtc_destroy,
> - .gamma_set  = drm_atomic_helper_legacy_gamma_set,
>   .set_config = drm_atomic_helper_set_config,
>   .page_flip  = drm_atomic_helper_page_flip,
>   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 9db371f4054f..5b0ec785c516 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -903,7 +903,6 @@ static void ast_crtc_atomic_destroy_state(struct drm_crtc 
> *crtc,
>  
>  static const struct drm_crtc_funcs 

[PATCH v3 8/9] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight

[Lyude Paul]

Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.

So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).

v3:
* Rebase

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
 drivers/gpu/drm/i915/i915_params.c|  2 +-
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 9a3ff3ffc158..eef14ab6bddc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -609,15 +609,54 @@ static const struct intel_panel_bl_funcs 
intel_dp_vesa_bl_funcs = {
.get = intel_dp_aux_vesa_get_backlight,
 };
 
+enum intel_dp_aux_backlight_modparam {
+   INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+   INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+   INTEL_DP_AUX_BACKLIGHT_ON = 1,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   bool try_intel_interface = false, try_vesa_interface = false;
 
-   if (i915->params.enable_dpcd_backlight == 0)
+   /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+   switch (i915->params.enable_dpcd_backlight) {
+   case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+   case INTEL_DP_AUX_BACKLIGHT_AUTO:
+   switch (i915->vbt.backlight.type) {
+   case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+   try_vesa_interface = true;
+   break;
+   case INTEL_BACKLIGHT_DISPLAY_DDI:
+   try_intel_interface = true;
+   try_vesa_interface = true;
+   break;
+   default:
+   return -ENODEV;
+   }
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_ON:
+   if (i915->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+   try_intel_interface = true;
+
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+   try_intel_interface = true;
+   break;
+   }
 
/*
 * A lot of eDP panels in the wild will report supporting both the
@@ -626,13 +665,13 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
 * and will only work with the Intel interface. So, always probe for
 * that first.
 */
-   if (intel_dp_aux_supports_hdr_backlight(connector)) {
+   if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg(dev, "Using Intel proprietary eDP backlight 
controls\n");
panel->backlight.funcs = _dp_hdr_bl_funcs;
return 0;
}
 
-   if (intel_dp_aux_supports_vesa_backlight(connector)) {
+   if (try_vesa_interface && 
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg(dev, "Using VESA eDP backlight controls\n");
panel->backlight.funcs = _dp_vesa_bl_funcs;
return 0;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b..6939634e56ed 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
 
 i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
-   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enabled)");
+   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enable, 2=force VESA interface, 3=force Intel interface)");
 
 #if IS_ENABLED(CONFIG_DRM_I915_GVT)
 i915_param_named(enable_gvt, bool, 0400,
-- 

[PATCH v3 7/9] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)

[Lyude Paul]

So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 244 --
 drivers/gpu/drm/i915/display/intel_panel.c|  34 ++-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 4 files changed, 263 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 47ee565c49a2..889b6f9c1aa9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -261,7 +261,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct backlight_device *device;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 9775f33d1aac..9a3ff3ffc158 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
 
 /*
  * DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,175 @@
 
 #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
 
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
+{
+   struct drm_device *dev = connector->base.dev;
+   struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
+   struct drm_dp_aux *aux = _dp->aux;
+   struct intel_panel *panel = >panel;
+   int ret;
+   u8 tcon_cap[4];
+
+   ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap, 
sizeof(tcon_cap));
+   if (ret < 0)
+   return 

[PATCH v3 9/9] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

[Lyude Paul]

This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
  intel_edp_init_connector()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 83 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 9 insertions(+), 113 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..62f696fe511e 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1204,7 +1204,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1925,87 +1925,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * Some devices have unreliable OUIDs where they don't set the device ID
- * correctly, and as a result we need to use the EDID for finding additional
- * DP quirks in such cases.
- */
-static const struct edid_quirk edid_quirk_list[] = {
-   /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
-* only supports DPCD backlight controls
-*/
-   { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   /*
-* Some Dell CML 2020 systems have panels support both AUX and PWM
-* backlight control, and some only support AUX backlight control. All
-* said panels start up in AUX mode by default, and we don't have any
-* support for disabling HDR mode on these panels which would be
-* required to switch to PWM backlight control mode (plus, I'm not
-* even sure we want PWM backlight controls over DPCD backlight
-* controls anyway...). Until we have a better way of detecting these,
-* force DPCD backlight mode on all of them.
-*/
-   { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x09, 0xe5), PROD_ID(0xde, 0x08), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirks in some cases. This function can 

[PATCH v3 6/9] drm/i915/dp: Add register definitions for Intel HDR backlight interface

[Lyude Paul]

No functional changes yet, this just adds definitions for all of the
known DPCD registers used by Intel's HDR backlight interface. Since
we'll only ever use this in i915, we just define them in
intel_dp_aux_backlight.c

Reviewed-by: Rodrigo Vivi 
Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 53 +++
 1 file changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index b102692a659d..9775f33d1aac 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -25,6 +25,59 @@
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
 
+/*
+ * DP AUX registers for Intel's proprietary HDR backlight interface. We define
+ * them here since we'll likely be the only driver to ever use these.
+ */
+#define INTEL_EDP_HDR_TCON_CAP00x340
+
+#define INTEL_EDP_HDR_TCON_CAP10x341
+# define INTEL_EDP_HDR_TCON_2084_DECODE_CAP   BIT(0)
+# define INTEL_EDP_HDR_TCON_2020_GAMUT_CAPBIT(1)
+# define INTEL_EDP_HDR_TCON_TONE_MAPPING_CAP  BIT(2)
+# define INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_CAP   BIT(3)
+# define INTEL_EDP_HDR_TCON_BRIGHTNESS_NITS_CAP   BIT(4)
+# define INTEL_EDP_HDR_TCON_OPTIMIZATION_CAP  BIT(5)
+# define INTEL_EDP_HDR_TCON_SDP_COLORIMETRY_CAP   BIT(6)
+# define INTEL_EDP_HDR_TCON_SRGB_TO_PANEL_GAMUT_CONVERSION_CAPBIT(7)
+
+#define INTEL_EDP_HDR_TCON_CAP20x342
+# define INTEL_EDP_SDR_TCON_BRIGHTNESS_AUX_CAPBIT(0)
+
+#define INTEL_EDP_HDR_TCON_CAP30x343
+
+#define INTEL_EDP_HDR_GETSET_CTRL_PARAMS   0x344
+# define INTEL_EDP_HDR_TCON_2084_DECODE_ENABLEBIT(0)
+# define INTEL_EDP_HDR_TCON_2020_GAMUT_ENABLE BIT(1)
+# define INTEL_EDP_HDR_TCON_TONE_MAPPING_ENABLE   BIT(2) 
/* Pre-TGL+ */
+# define INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_ENABLEBIT(3)
+# define INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE BIT(4)
+# define INTEL_EDP_HDR_TCON_SRGB_TO_PANEL_GAMUT_ENABLEBIT(5)
+/* Bit 6 is reserved */
+# define INTEL_EDP_HDR_TCON_SDP_COLORIMETRY_ENABLEBIT(7)
+
+#define INTEL_EDP_HDR_CONTENT_LUMINANCE0x346 
/* Pre-TGL+ */
+#define INTEL_EDP_HDR_PANEL_LUMINANCE_OVERRIDE 0x34A
+#define INTEL_EDP_SDR_LUMINANCE_LEVEL  0x352
+#define INTEL_EDP_BRIGHTNESS_NITS_LSB  0x354
+#define INTEL_EDP_BRIGHTNESS_NITS_MSB  0x355
+#define INTEL_EDP_BRIGHTNESS_DELAY_FRAMES  0x356
+#define INTEL_EDP_BRIGHTNESS_PER_FRAME_STEPS   0x357
+
+#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_00x358
+# define INTEL_EDP_TCON_USAGE_MASK GENMASK(0, 3)
+# define INTEL_EDP_TCON_USAGE_UNKNOWN0x0
+# define INTEL_EDP_TCON_USAGE_DESKTOP0x1
+# define INTEL_EDP_TCON_USAGE_FULL_SCREEN_MEDIA  0x2
+# define INTEL_EDP_TCON_USAGE_FULL_SCREEN_GAMING 0x3
+# define INTEL_EDP_TCON_POWER_MASKBIT(4)
+# define INTEL_EDP_TCON_POWER_DC(0 << 4)
+# define INTEL_EDP_TCON_POWER_AC(1 << 4)
+# define INTEL_EDP_TCON_OPTIMIZATION_STRENGTH_MASK GENMASK(5, 7)
+
+#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
+
+/* VESA backlight callbacks */
 static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 5/9] drm/i915/dp: Rename eDP VESA backlight interface functions

[Lyude Paul]

Since we're about to add support for a second type of backlight control
interface over DP AUX (specifically, Intel's proprietary HDR backlight
controls) let's rename all of the current backlight hooks we have for
vesa to make it clear that they're specific to the VESA interface and
not Intel's.

v3:
* Rebase

Signed-off-by: Lyude Paul 
Reviewed-by: Rodrigo Vivi 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 62 ++-
 1 file changed, 32 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index c76287e9e91e..b102692a659d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -25,7 +25,7 @@
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
 
-static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
+static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 reg_val = 0;
@@ -52,7 +52,7 @@ static void set_aux_backlight_enable(struct intel_dp 
*intel_dp, bool enable)
}
 }
 
-static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector *connector)
+static bool intel_dp_aux_vesa_backlight_dpcd_mode(struct intel_connector 
*connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
@@ -75,7 +75,7 @@ static bool intel_dp_aux_backlight_dpcd_mode(struct 
intel_connector *connector)
  * Read the current backlight value from DPCD register(s) based
  * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
  */
-static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
+static u32 intel_dp_aux_vesa_get_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
@@ -86,7 +86,7 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector 
*connector)
 * If we're not in DPCD control mode yet, the programmed brightness
 * value is meaningless and we should assume max brightness
 */
-   if (!intel_dp_aux_backlight_dpcd_mode(connector))
+   if (!intel_dp_aux_vesa_backlight_dpcd_mode(connector))
return connector->panel.backlight.max;
 
if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
@@ -107,7 +107,8 @@ static u32 intel_dp_aux_get_backlight(struct 
intel_connector *connector)
  * 8-bit or 16 bit value (MSB and LSB)
  */
 static void
-intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 
level)
+intel_dp_aux_vesa_set_backlight(const struct drm_connector_state *conn_state,
+   u32 level)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -137,7 +138,7 @@ intel_dp_aux_set_backlight(const struct drm_connector_state 
*conn_state, u32 lev
  * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
  * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
  */
-static bool intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
+static bool intel_dp_aux_vesa_set_pwm_freq(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -173,8 +174,9 @@ static bool intel_dp_aux_set_pwm_freq(struct 
intel_connector *connector)
return true;
 }
 
-static void intel_dp_aux_enable_backlight(const struct intel_crtc_state 
*crtc_state,
- const struct drm_connector_state 
*conn_state, u32 level)
+static void
+intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -214,7 +216,7 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
}
 
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
-   if (intel_dp_aux_set_pwm_freq(connector))
+   if (intel_dp_aux_vesa_set_pwm_freq(connector))
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
 
if (new_dpcd_buf != dpcd_buf) {
@@ -225,18 +227,18 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
}
}
 
-   intel_dp_aux_set_backlight(conn_state, level);
-   set_aux_backlight_enable(intel_dp, true);
+   

[PATCH v3 4/9] drm/i915: Keep track of pwm-related backlight hooks separately

[Lyude Paul]

Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs->setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.

Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in PCH mode. The reason for
this is because in the original codepath for this, it was expected that the
intel_panel_bl_funcs->setup() hook would be responsible for fetching the
initial backlight level. On lpt systems, the only time we could ever be in
PCH backlight mode is during the initial driver load - meaning that outside
of the setup() hook, lpt_get_backlight() will always be the callback used
for retrieving the current backlight level. After this patch we still need
to fetch and write-back the PCH backlight value if we're in PCH mode, but
because intel_pwm_setup_backlight() will retrieve the backlight level after
setup() using the get() hook, which always ends up being
lpt_get_backlight(). Thus - an additional call to lpt_get_backlight() in
lpt_setup_backlight() is made redundant.

v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   4 +
 drivers/gpu/drm/i915/display/intel_panel.c| 344 ++
 2 files changed, 194 insertions(+), 154 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index a70d1bf29aa5..47ee565c49a2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -252,6 +252,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_min;
+   u32 pwm_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -263,6 +266,7 @@ struct intel_panel {
struct backlight_device *device;
 
const struct intel_panel_bl_funcs *funcs;
+   const struct intel_panel_bl_funcs *pwm_funcs;
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 67f81ae995c4..41f0d2b2c627 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector 
*connector,
 0, user_max);
 }
 
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector, 
u32 val)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
 
-   drm_WARN_ON(_priv->drm, panel->backlight.max == 0);
+   drm_WARN_ON(_priv->drm, panel->backlight.pwm_max == 0);
 
if (dev_priv->params.invert_brightness < 0)
return val;
 
if (dev_priv->params.invert_brightness > 0 ||

[PATCH v3 3/9] drm/i915: Pass down brightness values to enable/disable backlight callbacks

[Lyude Paul]

Instead of using intel_panel->backlight.level, have the caller provide us
with the current panel backlight value. We'll need this for when we
separate PWM-related backlight callbacks from other means of backlight
control (like DPCD backlight controls), as the caller of each PWM callback
will be responsible for converting the current brightness value to it's
respective PWM level.

Signed-off-by: Lyude Paul 
---
 .../drm/i915/display/intel_display_types.h|  4 +-
 .../drm/i915/display/intel_dp_aux_backlight.c |  8 +--
 .../i915/display/intel_dsi_dcs_backlight.c|  7 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 67 +--
 4 files changed, 42 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1fa0246b3a82..a70d1bf29aa5 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -230,9 +230,9 @@ struct intel_panel_bl_funcs {
int (*setup)(struct intel_connector *connector, enum pipe pipe);
u32 (*get)(struct intel_connector *connector);
void (*set)(const struct drm_connector_state *conn_state, u32 level);
-   void (*disable)(const struct drm_connector_state *conn_state);
+   void (*disable)(const struct drm_connector_state *conn_state, u32 
level);
void (*enable)(const struct intel_crtc_state *crtc_state,
-  const struct drm_connector_state *conn_state);
+  const struct drm_connector_state *conn_state, u32 level);
u32 (*hz_to_pwm)(struct intel_connector *connector, u32 hz);
 };
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 4fd536801b14..c76287e9e91e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -174,7 +174,7 @@ static bool intel_dp_aux_set_pwm_freq(struct 
intel_connector *connector)
 }
 
 static void intel_dp_aux_enable_backlight(const struct intel_crtc_state 
*crtc_state,
- const struct drm_connector_state 
*conn_state)
+ const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -225,12 +225,12 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
}
}
 
-   intel_dp_aux_set_backlight(conn_state,
-  connector->panel.backlight.level);
+   intel_dp_aux_set_backlight(conn_state, level);
set_aux_backlight_enable(intel_dp, true);
 }
 
-static void intel_dp_aux_disable_backlight(const struct drm_connector_state 
*old_conn_state)
+static void intel_dp_aux_disable_backlight(const struct drm_connector_state 
*old_conn_state,
+  u32 level)
 {

set_aux_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
 false);
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
index 5c508d51f526..88628764956d 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
@@ -77,7 +77,7 @@ static void dcs_set_backlight(const struct 
drm_connector_state *conn_state, u32
}
 }
 
-static void dcs_disable_backlight(const struct drm_connector_state *conn_state)
+static void dcs_disable_backlight(const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_dsi *intel_dsi = 
enc_to_intel_dsi(to_intel_encoder(conn_state->best_encoder));
struct mipi_dsi_device *dsi_device;
@@ -111,10 +111,9 @@ static void dcs_disable_backlight(const struct 
drm_connector_state *conn_state)
 }
 
 static void dcs_enable_backlight(const struct intel_crtc_state *crtc_state,
-const struct drm_connector_state *conn_state)
+const struct drm_connector_state *conn_state, 
u32 level)
 {
struct intel_dsi *intel_dsi = 
enc_to_intel_dsi(to_intel_encoder(conn_state->best_encoder));
-   struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
struct mipi_dsi_device *dsi_device;
enum port port;
 
@@ -142,7 +141,7 @@ static void dcs_enable_backlight(const struct 
intel_crtc_state *crtc_state,
   , sizeof(cabc));
}
 
-   dcs_set_backlight(conn_state, panel->backlight.level);
+   dcs_set_backlight(conn_state, level);
 }
 
 static int dcs_setup_backlight(struct intel_connector *connector,
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 

[PATCH v3 2/9] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*

[Lyude Paul]

Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight functions is a bit more obvious.

This introduces no functional changes.

Signed-off-by: Lyude Paul 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 28 +++---
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 36b7693453ae..da8f7c12ae22 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
 BXT_BLC_PWM_DUTY(panel->backlight.controller));
 }
 
-static u32 pwm_get_backlight(struct intel_connector *connector)
+static u32 ext_pwm_get_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
struct pwm_state state;
@@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
   BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
 }
 
-static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
+static void ext_pwm_set_backlight(const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
 
@@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct 
drm_connector_state *old_conn_sta
   tmp & ~BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
+static void ext_pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct 
intel_crtc_state *crtc_state,
   pwm_ctl | BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
-const struct drm_connector_state *conn_state)
+static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
+const struct drm_connector_state 
*conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector, 
enum pipe unused)
return 0;
 }
 
-static int pwm_setup_backlight(struct intel_connector *connector,
-  enum pipe pipe)
+static int ext_pwm_setup_backlight(struct intel_connector *connector,
+  enum pipe pipe)
 {
struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2061,12 +2061,12 @@ static const struct intel_panel_bl_funcs pch_funcs = {
.hz_to_pwm = pch_hz_to_pwm,
 };
 
-static const struct intel_panel_bl_funcs pwm_funcs = {
-   .setup = pwm_setup_backlight,
-   .enable = pwm_enable_backlight,
-   .disable = pwm_disable_backlight,
-   .set = pwm_set_backlight,
-   .get = pwm_get_backlight,
+static const struct intel_panel_bl_funcs ext_pwm_funcs = {
+   .setup = ext_pwm_setup_backlight,
+   .enable = ext_pwm_enable_backlight,
+   .disable = ext_pwm_disable_backlight,
+   .set = ext_pwm_set_backlight,
+   .get = ext_pwm_get_backlight,
 };
 
 static const struct intel_panel_bl_funcs vlv_funcs = {
@@ -2125,7 +2125,7 @@ intel_panel_init_backlight_funcs(struct intel_panel 
*panel)
panel->backlight.funcs = _funcs;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
-   panel->backlight.funcs = _funcs;
+   panel->backlight.funcs = _pwm_funcs;
} else {
panel->backlight.funcs = _funcs;
}
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/9] drm/i915/dp: Program source OUI on eDP panels

[Lyude Paul]

Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.

We also take care not to reprogram the source OUI if it already matches
what we expect. This is just to be careful so that we don't accidentally
take the panel out of any backlight control modes we found it in.

v2:
* Add careful parameter to intel_edp_init_source_oui() to avoid
  re-writing the source OUI if it's already been set during driver
  initialization

Signed-off-by: Lyude Paul 
Reviewed-by: Rodrigo Vivi 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2d4d5e95af84..4cb2bfee9c40 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3583,6 +3583,29 @@ void intel_dp_sink_set_decompression_state(struct 
intel_dp *intel_dp,
enable ? "enable" : "disable");
 }
 
+static void
+intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 oui[] = { 0x00, 0xaa, 0x01 };
+   u8 buf[3] = { 0 };
+
+   /*
+* During driver init, we want to be careful and avoid changing the 
source OUI if it's
+* already set to what we want, so as to avoid clearing any state by 
accident
+*/
+   if (careful) {
+   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, 
sizeof(buf)) < 0)
+   drm_err(>drm, "Failed to read source OUI\n");
+
+   if (memcmp(oui, buf, sizeof(oui)) == 0)
+   return;
+   }
+
+   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
< 0)
+   drm_err(>drm, "Failed to write source OUI\n");
+}
+
 /* If the device supports it, try to set the power state appropriately */
 void intel_dp_set_power(struct intel_dp *intel_dp, u8 mode)
 {
@@ -3604,6 +3627,10 @@ void intel_dp_set_power(struct intel_dp *intel_dp, u8 
mode)
 
lspcon_resume(dp_to_dig_port(intel_dp));
 
+   /* Write the source OUI as early as possible */
+   if (intel_dp_is_edp(intel_dp))
+   intel_edp_init_source_oui(intel_dp, false);
+
/*
 * When turning on, we need to retry for 1ms to give the sink
 * time to wake up.
@@ -4869,6 +4896,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
intel_dp_get_dsc_sink_cap(intel_dp);
 
+   /*
+* If needed, program our source OUI so we can make various 
Intel-specific AUX services
+* available (such as HDR backlight controls)
+*/
+   intel_edp_init_source_oui(intel_dp, true);
+
return true;
 }
 
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/9] drm/i915: Add support for Intel's eDP backlight controls

[Lyude Paul]

A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Series-wide changes in v3:
* Pass down brightness values to enable/disable backlight callbacks in a
  separate patch
* Rebase

Lyude Paul (9):
  drm/i915/dp: Program source OUI on eDP panels
  drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*
  drm/i915: Pass down brightness values to enable/disable backlight
callbacks
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915/dp: Rename eDP VESA backlight interface functions
  drm/i915/dp: Add register definitions for Intel HDR backlight
interface
  drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
  drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  83 +---
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  18 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  42 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 394 +---
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 .../i915/display/intel_dsi_dcs_backlight.c|   7 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 435 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 12 files changed, 655 insertions(+), 359 deletions(-)

-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: add legacy support for using degamma for gamma

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thu, Dec 03, 2020 at 01:48:44PM +0200, Tomi Valkeinen wrote:
> We currently have drm_atomic_helper_legacy_gamma_set() helper which can
> be used to handle legacy gamma-set ioctl.
> drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
> CTM and DEGAMMA_LUT. This works fine on HW where we have either:
> 
> degamma -> ctm -> gamma -> out
> 
> or
> 
> ctm -> gamma -> out
> 
> However, if the HW has gamma table before ctm, the atomic property
> should be DEGAMMA_LUT, and thus we have:
> 
> degamma -> ctm -> out
> 
> This is fine for userspace which sets gamma table using the properties,
> as the userspace can check for the existence of gamma & degamma, but the
> legacy gamma-set ioctl does not work.
> 
> This patch fixes the issue by changing
> drm_atomic_helper_legacy_gamma_set() so that GAMMA_LUT will be used if
> it exists, and DEGAMMA_LUT will be used as a fallback.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 18 +++---
>  drivers/gpu/drm/drm_color_mgmt.c|  4 
>  include/drm/drm_crtc.h  |  3 +++
>  3 files changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ba1507036f26..fe59c8ea42a9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3512,6 +3512,10 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
>   * that support color management through the DEGAMMA_LUT/GAMMA_LUT
>   * properties. See drm_crtc_enable_color_mgmt() and the containing chapter 
> for
>   * how the atomic color management and gamma tables work.
> + *
> + * This function uses the GAMMA_LUT or DEGAMMA_LUT property for the gamma 
> table.
> + * GAMMA_LUT property is used if it exists, and DEGAMMA_LUT property is used 
> as
> + * a fallback.
>   */
>  int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
>  u16 *red, u16 *green, u16 *blue,
> @@ -3525,6 +3529,12 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
> *crtc,
>   struct drm_color_lut *blob_data;
>   int i, ret = 0;
>   bool replaced;
> + bool use_degamma;
> +
> + if (!crtc->has_gamma_prop && !crtc->has_degamma_prop)
> + return -ENODEV;
> +
> + use_degamma = !crtc->has_gamma_prop;
>  
>   state = drm_atomic_state_alloc(crtc->dev);
>   if (!state)
> @@ -3554,10 +3564,12 @@ int drm_atomic_helper_legacy_gamma_set(struct 
> drm_crtc *crtc,
>   goto fail;
>   }
>  
> - /* Reset DEGAMMA_LUT and CTM properties. */
> - replaced  = drm_property_replace_blob(_state->degamma_lut, NULL);
> + /* Set GAMMA/DEGAMMA_LUT and reset DEGAMMA/GAMMA_LUT and CTM */
> + replaced  = drm_property_replace_blob(_state->degamma_lut,
> +   use_degamma ? blob : NULL);
>   replaced |= drm_property_replace_blob(_state->ctm, NULL);
> - replaced |= drm_property_replace_blob(_state->gamma_lut, blob);
> + replaced |= drm_property_replace_blob(_state->gamma_lut,
> +   use_degamma ? NULL : blob);
>   crtc_state->color_mgmt_changed |= replaced;
>  
>   ret = drm_atomic_commit(state);
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 3bcabc2f6e0e..956e59d5f6a7 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -176,6 +176,8 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>  degamma_lut_size);
>   }
>  
> + crtc->has_degamma_prop = !!degamma_lut_size;
> +
>   if (has_ctm)
>   drm_object_attach_property(>base,
>  config->ctm_property, 0);
> @@ -187,6 +189,8 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>  config->gamma_lut_size_property,
>  gamma_lut_size);
>   }
> +
> + crtc->has_gamma_prop = !!gamma_lut_size;
>  }
>  EXPORT_SYMBOL(drm_crtc_enable_color_mgmt);
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index ba839e5e357d..9e1f06047e3d 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1084,6 +1084,9 @@ struct drm_crtc {
>*/
>   uint16_t *gamma_store;
>  
> + bool has_gamma_prop;
> + bool has_degamma_prop;

We could use a bitfield to save a bit of memory. Apart from that, the
patch looks good to me.

Reviewed-by: Laurent Pinchart 

> +
>   /** @helper_private: mid-layer private data */
>   const struct drm_crtc_helper_funcs *helper_private;
>  

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Allow drm_fourcc.h without including drm.h

[kernel test robot]

Hi James,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next 
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc6 
next-20201204]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/James-Park/drm-Allow-drm_fourcc-h-without-including-drm-h/20201204-163753
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-a014-20201204 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
32c501dd88b62787d3a5ffda7aabcf4650dbe3cd)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/444ac999e27a36307f741eb0ef60d630b0b8946a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
James-Park/drm-Allow-drm_fourcc-h-without-including-drm-h/20201204-163753
git checkout 444ac999e27a36307f741eb0ef60d630b0b8946a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> usr/include/drm/drm_fourcc.h:29: found __[us]{8,16,32,64} type without 
>> #include 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 8/9] drm: rcar-du: Skip encoder allocation for LVDS1 in dual-link mode

[Laurent Pinchart]

The rcar-du driver skips registration of the encoder for the LVDS1
output when LVDS is used in dual-link mode, as the LVDS0 and LVDS1 links
are bundled and handled through the LVDS0 output. It however still
allocates the encoder and immediately destroys it, which is pointless.
Skip allocation of the encoder altogether in that case.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 51 ++-
 1 file changed, 22 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index e4f35a88d00f..49c0b27e2f5a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -65,17 +65,6 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
struct drm_bridge *bridge;
int ret;
 
-   renc = kzalloc(sizeof(*renc), GFP_KERNEL);
-   if (renc == NULL)
-   return -ENOMEM;
-
-   rcdu->encoders[output] = renc;
-   renc->output = output;
-   encoder = rcar_encoder_to_drm_encoder(renc);
-
-   dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
-   enc_node, output);
-
/*
 * Locate the DRM bridge from the DT node. For the DPAD outputs, if the
 * DT node has a single port, assume that it describes a panel and
@@ -86,23 +75,17 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
rcar_du_encoder_count_ports(enc_node) == 1) {
struct drm_panel *panel = of_drm_find_panel(enc_node);
 
-   if (IS_ERR(panel)) {
-   ret = PTR_ERR(panel);
-   goto error;
-   }
+   if (IS_ERR(panel))
+   return PTR_ERR(panel);
 
bridge = devm_drm_panel_bridge_add_typed(rcdu->dev, panel,
 
DRM_MODE_CONNECTOR_DPI);
-   if (IS_ERR(bridge)) {
-   ret = PTR_ERR(bridge);
-   goto error;
-   }
+   if (IS_ERR(bridge))
+   return PTR_ERR(bridge);
} else {
bridge = of_drm_find_bridge(enc_node);
-   if (!bridge) {
-   ret = -EPROBE_DEFER;
-   goto error;
-   }
+   if (!bridge)
+   return -EPROBE_DEFER;
 
if (output == RCAR_DU_OUTPUT_LVDS0 ||
output == RCAR_DU_OUTPUT_LVDS1)
@@ -110,16 +93,26 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
}
 
/*
-* On Gen3 skip the LVDS1 output if the LVDS1 encoder is used as a
-* companion for LVDS0 in dual-link mode.
+* Create and initialize the encoder. On Gen3 skip the LVDS1 output if
+* the LVDS1 encoder is used as a companion for LVDS0 in dual-link
+* mode.
 */
if (rcdu->info->gen >= 3 && output == RCAR_DU_OUTPUT_LVDS1) {
-   if (rcar_lvds_dual_link(bridge)) {
-   ret = -ENOLINK;
-   goto error;
-   }
+   if (rcar_lvds_dual_link(bridge))
+   return -ENOLINK;
}
 
+   renc = kzalloc(sizeof(*renc), GFP_KERNEL);
+   if (renc == NULL)
+   return -ENOMEM;
+
+   rcdu->encoders[output] = renc;
+   renc->output = output;
+   encoder = rcar_encoder_to_drm_encoder(renc);
+
+   dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
+   enc_node, output);
+
ret = drm_encoder_init(>ddev, encoder, _du_encoder_funcs,
   DRM_MODE_ENCODER_NONE, NULL);
if (ret < 0)
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 9/9] drm: rcar-du: Drop local encoder variable

[Laurent Pinchart]

The local encoder variable is an alias for >base, and is only use
twice. It doesn't help much, drop it, along with the
rcar_encoder_to_drm_encoder() macro that is then unused.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 6 ++
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 2 --
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 49c0b27e2f5a..9a565bd3380d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -61,7 +61,6 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 struct device_node *enc_node)
 {
struct rcar_du_encoder *renc;
-   struct drm_encoder *encoder;
struct drm_bridge *bridge;
int ret;
 
@@ -108,12 +107,11 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 
rcdu->encoders[output] = renc;
renc->output = output;
-   encoder = rcar_encoder_to_drm_encoder(renc);
 
dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
enc_node, output);
 
-   ret = drm_encoder_init(>ddev, encoder, _du_encoder_funcs,
+   ret = drm_encoder_init(>ddev, >base, _du_encoder_funcs,
   DRM_MODE_ENCODER_NONE, NULL);
if (ret < 0)
goto error;
@@ -127,7 +125,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 * Attach the bridge to the encoder. The bridge will create the
 * connector.
 */
-   return drm_bridge_attach(encoder, bridge, NULL, 0);
+   return drm_bridge_attach(>base, bridge, NULL, 0);
 
 error:
kfree(renc);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index df9be4524301..73560563fb31 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -22,8 +22,6 @@ struct rcar_du_encoder {
 #define to_rcar_encoder(e) \
container_of(e, struct rcar_du_encoder, base)
 
-#define rcar_encoder_to_drm_encoder(e) (&(e)->base)
-
 int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 enum rcar_du_output output,
 struct device_node *enc_node);
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/9] drm: rcar-du: Embed drm_device in rcar_du_device

[Laurent Pinchart]

Embedding drm_device in rcar_du_device allows usage of the DRM managed
API to allocate both structures in one go, simplifying error handling.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 33 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  5 ++--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c   |  4 +--
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  4 +--
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  6 ++--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  6 ++--
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c |  2 +-
 8 files changed, 29 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index e23b9c7b4afe..9a099c0fe1d4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -1251,7 +1251,7 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int swindex,
else
primary = >planes[swindex % 2].plane;
 
-   ret = drm_crtc_init_with_planes(rcdu->ddev, crtc, primary, NULL,
+   ret = drm_crtc_init_with_planes(>ddev, crtc, primary, NULL,
rcdu->info->gen <= 2 ?
_funcs_gen2 : _funcs_gen3,
NULL);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 1490ec182646..4ab99ac49891 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -18,10 +18,11 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
+#include 
 #include 
 
 #include "rcar_du_drv.h"
@@ -529,14 +530,14 @@ static int rcar_du_pm_suspend(struct device *dev)
 {
struct rcar_du_device *rcdu = dev_get_drvdata(dev);
 
-   return drm_mode_config_helper_suspend(rcdu->ddev);
+   return drm_mode_config_helper_suspend(>ddev);
 }
 
 static int rcar_du_pm_resume(struct device *dev)
 {
struct rcar_du_device *rcdu = dev_get_drvdata(dev);
 
-   return drm_mode_config_helper_resume(rcdu->ddev);
+   return drm_mode_config_helper_resume(>ddev);
 }
 #endif
 
@@ -551,7 +552,7 @@ static const struct dev_pm_ops rcar_du_pm_ops = {
 static int rcar_du_remove(struct platform_device *pdev)
 {
struct rcar_du_device *rcdu = platform_get_drvdata(pdev);
-   struct drm_device *ddev = rcdu->ddev;
+   struct drm_device *ddev = >ddev;
 
drm_dev_unregister(ddev);
 
@@ -565,14 +566,14 @@ static int rcar_du_remove(struct platform_device *pdev)
 static int rcar_du_probe(struct platform_device *pdev)
 {
struct rcar_du_device *rcdu;
-   struct drm_device *ddev;
struct resource *mem;
int ret;
 
/* Allocate and initialize the R-Car device structure. */
-   rcdu = devm_kzalloc(>dev, sizeof(*rcdu), GFP_KERNEL);
-   if (rcdu == NULL)
-   return -ENOMEM;
+   rcdu = devm_drm_dev_alloc(>dev, _du_driver,
+ struct rcar_du_device, ddev);
+   if (IS_ERR(rcdu))
+   return PTR_ERR(rcdu);
 
rcdu->dev = >dev;
rcdu->info = of_device_get_match_data(rcdu->dev);
@@ -586,12 +587,7 @@ static int rcar_du_probe(struct platform_device *pdev)
return PTR_ERR(rcdu->mmio);
 
/* DRM/KMS objects */
-   ddev = drm_dev_alloc(_du_driver, >dev);
-   if (IS_ERR(ddev))
-   return PTR_ERR(ddev);
-
-   rcdu->ddev = ddev;
-   ddev->dev_private = rcdu;
+   rcdu->ddev.dev_private = rcdu;
 
ret = rcar_du_modeset_init(rcdu);
if (ret < 0) {
@@ -601,25 +597,24 @@ static int rcar_du_probe(struct platform_device *pdev)
goto error;
}
 
-   ddev->irq_enabled = 1;
+   rcdu->ddev.irq_enabled = 1;
 
/*
 * Register the DRM device with the core and the connectors with
 * sysfs.
 */
-   ret = drm_dev_register(ddev, 0);
+   ret = drm_dev_register(>ddev, 0);
if (ret)
goto error;
 
DRM_INFO("Device %s probed\n", dev_name(>dev));
 
-   drm_fbdev_generic_setup(ddev, 32);
+   drm_fbdev_generic_setup(>ddev, 32);
 
return 0;
 
 error:
-   rcar_du_remove(pdev);
-
+   drm_kms_helper_poll_fini(>ddev);
return ret;
 }
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 71732fc5df8f..e5b6f456357e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include 
+
 #include "rcar_cmm.h"
 #include "rcar_du_crtc.h"
 #include "rcar_du_group.h"
@@ -21,7 +23,6 @@
 struct clk;
 struct device;
 struct drm_bridge;
-struct drm_device;
 struct drm_property;
 struct rcar_du_device;
 struct rcar_du_encoder;
@@ -80,7 +81,7 @@ struct rcar_du_device {
 
void __iomem 

[PATCH 7/9] drm: rcar-du: Replace dev_private with container_of

[Laurent Pinchart]

Now that drm_device is embedded in rcar_du_device, we can use
container_of to get the rcar_du_device pointer from the drm_device,
instead of using the drm_device.dev_private field.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 2 --
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   | 5 +
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 8 
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +-
 4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 4ab99ac49891..d6a8b7899952 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -587,8 +587,6 @@ static int rcar_du_probe(struct platform_device *pdev)
return PTR_ERR(rcdu->mmio);
 
/* DRM/KMS objects */
-   rcdu->ddev.dev_private = rcdu;
-
ret = rcar_du_modeset_init(rcdu);
if (ret < 0) {
if (ret != -EPROBE_DEFER)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index e5b6f456357e..98d6bac3f2fa 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -102,6 +102,11 @@ struct rcar_du_device {
unsigned int vspd1_sink;
 };
 
+static inline struct rcar_du_device *to_rcar_du_device(struct drm_device *dev)
+{
+   return container_of(dev, struct rcar_du_device, ddev);
+}
+
 static inline bool rcar_du_has(struct rcar_du_device *rcdu,
   unsigned int feature)
 {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 57bb0dc22807..d6b71a9361ca 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -327,7 +327,7 @@ const struct rcar_du_format_info *rcar_du_format_info(u32 
fourcc)
 int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
 {
-   struct rcar_du_device *rcdu = dev->dev_private;
+   struct rcar_du_device *rcdu = to_rcar_du_device(dev);
unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
unsigned int align;
 
@@ -349,7 +349,7 @@ static struct drm_framebuffer *
 rcar_du_fb_create(struct drm_device *dev, struct drm_file *file_priv,
  const struct drm_mode_fb_cmd2 *mode_cmd)
 {
-   struct rcar_du_device *rcdu = dev->dev_private;
+   struct rcar_du_device *rcdu = to_rcar_du_device(dev);
const struct rcar_du_format_info *format;
unsigned int chroma_pitch;
unsigned int max_pitch;
@@ -421,7 +421,7 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file 
*file_priv,
 static int rcar_du_atomic_check(struct drm_device *dev,
struct drm_atomic_state *state)
 {
-   struct rcar_du_device *rcdu = dev->dev_private;
+   struct rcar_du_device *rcdu = to_rcar_du_device(dev);
int ret;
 
ret = drm_atomic_helper_check(dev, state);
@@ -437,7 +437,7 @@ static int rcar_du_atomic_check(struct drm_device *dev,
 static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state)
 {
struct drm_device *dev = old_state->dev;
-   struct rcar_du_device *rcdu = dev->dev_private;
+   struct rcar_du_device *rcdu = to_rcar_du_device(dev);
struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
unsigned int i;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 5f69ff4502c1..02e5f11f38eb 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -128,7 +128,7 @@ static int rcar_du_plane_hwalloc(struct rcar_du_plane 
*plane,
 int rcar_du_atomic_check_planes(struct drm_device *dev,
struct drm_atomic_state *state)
 {
-   struct rcar_du_device *rcdu = dev->dev_private;
+   struct rcar_du_device *rcdu = to_rcar_du_device(dev);
unsigned int group_freed_planes[RCAR_DU_MAX_GROUPS] = { 0, };
unsigned int group_free_planes[RCAR_DU_MAX_GROUPS] = { 0, };
bool needs_realloc = false;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/9] drm: rcar-du: Use DRM-managed allocation for encoders

[Laurent Pinchart]

devm_kzalloc() is the wrong API to allocate encoders, as the lifetime of
the encoders is tied to the DRM device, not the device to driver
binding. drmm_kzalloc() isn't a good option either, as it would result
in the encoder being freed before being unregistered during the managed
cleanup of the DRM objects. Use a plain kzalloc(), and register a drmm
action to cleanup the encoder.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 47 ++-
 1 file changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 0edce24f2053..7c491ff72cd2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -8,12 +8,13 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 
 #include "rcar_du_drv.h"
 #include "rcar_du_encoder.h"
@@ -44,6 +45,17 @@ static unsigned int rcar_du_encoder_count_ports(struct 
device_node *node)
return num_ports;
 }
 
+static const struct drm_encoder_funcs rcar_du_encoder_funcs = {
+};
+
+static void rcar_du_encoder_release(struct drm_device *dev, void *res)
+{
+   struct rcar_du_encoder *renc = res;
+
+   drm_encoder_cleanup(>base);
+   kfree(renc);
+}
+
 int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 enum rcar_du_output output,
 struct device_node *enc_node)
@@ -53,7 +65,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
struct drm_bridge *bridge;
int ret;
 
-   renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
+   renc = kzalloc(sizeof(*renc), GFP_KERNEL);
if (renc == NULL)
return -ENOMEM;
 
@@ -76,20 +88,20 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 
if (IS_ERR(panel)) {
ret = PTR_ERR(panel);
-   goto done;
+   goto error;
}
 
bridge = devm_drm_panel_bridge_add_typed(rcdu->dev, panel,
 
DRM_MODE_CONNECTOR_DPI);
if (IS_ERR(bridge)) {
ret = PTR_ERR(bridge);
-   goto done;
+   goto error;
}
} else {
bridge = of_drm_find_bridge(enc_node);
if (!bridge) {
ret = -EPROBE_DEFER;
-   goto done;
+   goto error;
}
 
if (output == RCAR_DU_OUTPUT_LVDS0 ||
@@ -104,28 +116,27 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
if (rcdu->info->gen >= 3 && output == RCAR_DU_OUTPUT_LVDS1) {
if (rcar_lvds_dual_link(bridge)) {
ret = -ENOLINK;
-   goto done;
+   goto error;
}
}
 
-   ret = drm_simple_encoder_init(rcdu->ddev, encoder,
- DRM_MODE_ENCODER_NONE);
+   ret = drm_encoder_init(rcdu->ddev, encoder, _du_encoder_funcs,
+  DRM_MODE_ENCODER_NONE, NULL);
if (ret < 0)
-   goto done;
+   goto error;
+
+   ret = drmm_add_action_or_reset(rcdu->ddev, rcar_du_encoder_release,
+  renc);
+   if (ret)
+   return ret;
 
/*
 * Attach the bridge to the encoder. The bridge will create the
 * connector.
 */
-   ret = drm_bridge_attach(encoder, bridge, NULL, 0);
-   if (ret) {
-   drm_encoder_cleanup(encoder);
-   return ret;
-   }
-
-done:
-   if (ret < 0)
-   devm_kfree(rcdu->dev, renc);
+   return drm_bridge_attach(encoder, bridge, NULL, 0);
 
+error:
+   kfree(renc);
return ret;
 }
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/9] drm: rcar-du: Use DRM-managed allocation for VSP planes

[Laurent Pinchart]

devm_kcalloc() is the wrong API to allocate planes, as the lifetime of
the planes is tied to the DRM device, not the device to driver
binding. drmm_kcalloc() isn't a good option either, as it would result
in the planes being freed before being unregistered during the managed
cleanup of the DRM objects. Use a plain kcalloc(), and cleanup the
planes and free the memory in the existing rcar_du_vsp_cleanup()
handler.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 4dcb1bfbe201..78a886651d9f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -344,6 +345,15 @@ static const struct drm_plane_funcs 
rcar_du_vsp_plane_funcs = {
 static void rcar_du_vsp_cleanup(struct drm_device *dev, void *res)
 {
struct rcar_du_vsp *vsp = res;
+   unsigned int i;
+
+   for (i = 0; i < vsp->num_planes; ++i) {
+   struct rcar_du_vsp_plane *plane = >planes[i];
+
+   drm_plane_cleanup(>plane);
+   }
+
+   kfree(vsp->planes);
 
put_device(vsp->vsp);
 }
@@ -354,6 +364,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
device_node *np,
struct rcar_du_device *rcdu = vsp->dev;
struct platform_device *pdev;
unsigned int num_crtcs = hweight32(crtcs);
+   unsigned int num_planes;
unsigned int i;
int ret;
 
@@ -376,14 +387,13 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
device_node *np,
  * The VSP2D (Gen3) has 5 RPFs, but the VSP1D (Gen2) is limited to
  * 4 RPFs.
  */
-   vsp->num_planes = rcdu->info->gen >= 3 ? 5 : 4;
+   num_planes = rcdu->info->gen >= 3 ? 5 : 4;
 
-   vsp->planes = devm_kcalloc(rcdu->dev, vsp->num_planes,
-  sizeof(*vsp->planes), GFP_KERNEL);
+   vsp->planes = kcalloc(num_planes, sizeof(*vsp->planes), GFP_KERNEL);
if (!vsp->planes)
return -ENOMEM;
 
-   for (i = 0; i < vsp->num_planes; ++i) {
+   for (i = 0; i < num_planes; ++i) {
enum drm_plane_type type = i < num_crtcs
 ? DRM_PLANE_TYPE_PRIMARY
 : DRM_PLANE_TYPE_OVERLAY;
@@ -409,8 +419,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
device_node *np,
} else {
drm_plane_create_alpha_property(>plane);
drm_plane_create_zpos_property(>plane, 1, 1,
-  vsp->num_planes - 1);
+  num_planes - 1);
}
+
+   vsp->num_planes++;
}
 
return 0;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/9] drm: rcar-du: Release vsp device reference in all error paths

[Laurent Pinchart]

Use drmm_add_action_or_reset() instead of drmm_add_action() to ensure
the vsp device reference is released in case the function call fails.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index f6a69aa116e6..4dcb1bfbe201 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -364,7 +364,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
device_node *np,
 
vsp->vsp = >dev;
 
-   ret = drmm_add_action(rcdu->ddev, rcar_du_vsp_cleanup, vsp);
+   ret = drmm_add_action_or_reset(rcdu->ddev, rcar_du_vsp_cleanup, vsp);
if (ret < 0)
return ret;
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/9] drm: rcar-du: Drop unneeded encoder cleanup in error path

[Laurent Pinchart]

The encoder->name field can never be non-null in the error path, as that
can only be possible after a successful call to
drm_simple_encoder_init(). Drop the cleanup.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 2d40da98144b..0edce24f2053 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -124,11 +124,8 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
}
 
 done:
-   if (ret < 0) {
-   if (encoder->name)
-   encoder->funcs->destroy(encoder);
+   if (ret < 0)
devm_kfree(rcdu->dev, renc);
-   }
 
return ret;
 }
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/9] drm: rcar-du: Fix LVDS-related crash

[Laurent Pinchart]

Hello,

This patch series fixes a crash in the LVDS encoder on D3 and E3 SoCs.
See patch 1/9 for details. The next patches are additional cleanups.

Patches 4/9 to 6/9 fix incorrect usage of the devm_* API. They could be
made simpler by using the proposed drmm_* allocators for encoders and
planes ([1]), but those haven't landed yet. Not depending on them also
helps backporting those fixes to stable kernels. I will switch to the
new helpers when they will be available.

[1] 
https://lore.kernel.org/dri-devel/20200911135724.25833-1-p.za...@pengutronix.de/

Laurent Pinchart (9):
  drm: rcar-du: Fix crash when using LVDS1 clock for CRTC
  drm: rcar-du: Release vsp device reference in all error paths
  drm: rcar-du: Drop unneeded encoder cleanup in error path
  drm: rcar-du: Use DRM-managed allocation for VSP planes
  drm: rcar-du: Use DRM-managed allocation for encoders
  drm: rcar-du: Embed drm_device in rcar_du_device
  drm: rcar-du: Replace dev_private with container_of
  drm: rcar-du: Skip encoder allocation for LVDS1 in dual-link mode
  drm: rcar-du: Drop local encoder variable

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 12 +--
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 33 +++
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   | 13 ++-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c   | 95 +++--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h   |  2 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 12 +--
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  8 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 28 --
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c |  2 +-
 9 files changed, 107 insertions(+), 98 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/9] drm: rcar-du: Fix crash when using LVDS1 clock for CRTC

[Laurent Pinchart]

On D3 and E3 platforms, the LVDS encoder includes a PLL that can
generate a clock for the corresponding CRTC, used even when the CRTC
output to a non-LVDS port. This mechanism is supported by the driver,
but the implementation is broken in dual-link LVDS mode. In that case,
the LVDS1 drm_encoder is skipped, which causes a crash when trying to
access its bridge later on.

Fix this by storing bridge pointers internally instead of retrieving
them from the encoder.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 10 ++
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |  3 +++
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  4 
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index b5fb941e0f53..e23b9c7b4afe 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -730,13 +730,10 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc 
*crtc,
 */
if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index) &&
rstate->outputs == BIT(RCAR_DU_OUTPUT_DPAD0)) {
-   struct rcar_du_encoder *encoder =
-   rcdu->encoders[RCAR_DU_OUTPUT_LVDS0 + rcrtc->index];
+   struct drm_bridge *bridge = rcdu->lvds[rcrtc->index];
const struct drm_display_mode *mode =
>state->adjusted_mode;
-   struct drm_bridge *bridge;
 
-   bridge = drm_bridge_chain_get_first_bridge(>base);
rcar_lvds_clk_enable(bridge, mode->clock * 1000);
}
 
@@ -764,15 +761,12 @@ static void rcar_du_crtc_atomic_disable(struct drm_crtc 
*crtc,
 
if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index) &&
rstate->outputs == BIT(RCAR_DU_OUTPUT_DPAD0)) {
-   struct rcar_du_encoder *encoder =
-   rcdu->encoders[RCAR_DU_OUTPUT_LVDS0 + rcrtc->index];
-   struct drm_bridge *bridge;
+   struct drm_bridge *bridge = rcdu->lvds[rcrtc->index];
 
/*
 * Disable the LVDS clock output, see
 * rcar_du_crtc_atomic_enable().
 */
-   bridge = drm_bridge_chain_get_first_bridge(>base);
rcar_lvds_clk_disable(bridge);
}
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 61504c54e2ec..71732fc5df8f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -20,6 +20,7 @@
 
 struct clk;
 struct device;
+struct drm_bridge;
 struct drm_device;
 struct drm_property;
 struct rcar_du_device;
@@ -71,6 +72,7 @@ struct rcar_du_device_info {
 #define RCAR_DU_MAX_CRTCS  4
 #define RCAR_DU_MAX_GROUPS DIV_ROUND_UP(RCAR_DU_MAX_CRTCS, 2)
 #define RCAR_DU_MAX_VSPS   4
+#define RCAR_DU_MAX_LVDS   2
 
 struct rcar_du_device {
struct device *dev;
@@ -88,6 +90,7 @@ struct rcar_du_device {
struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
struct platform_device *cmms[RCAR_DU_MAX_CRTCS];
struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
+   struct drm_bridge *lvds[RCAR_DU_MAX_LVDS];
 
struct {
struct drm_property *colorkey;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index b0335da0c161..2d40da98144b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -91,6 +91,10 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
ret = -EPROBE_DEFER;
goto done;
}
+
+   if (output == RCAR_DU_OUTPUT_LVDS0 ||
+   output == RCAR_DU_OUTPUT_LVDS1)
+   rcdu->lvds[output - RCAR_DU_OUTPUT_LVDS0] = bridge;
}
 
/*
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: fw_attestation: fix unused function warning

[Alex Deucher]

On Fri, Dec 4, 2020 at 11:51 AM Arnd Bergmann  wrote:
>
> From: Arnd Bergmann 
>
> Without debugfs, the compiler notices one function that is not used at
> all:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c:123:12: error: unused 
> function 'amdgpu_is_fw_attestation_supported' [-Werror,-Wunused-function]
>
> In fact the static const amdgpu_fw_attestation_debugfs_ops structure is
> also unused here, but that warning is currently disabled.
>
> Removing the #ifdef check does the right thing and leads to all of this
> code to be dropped without warning.
>
> Fixes: 19ae333001b3 ("drm/amdgpu: added support for psp fw attestation")
> Signed-off-by: Arnd Bergmann 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
> index e47bca1c7635..7c6e02e35573 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
> @@ -130,7 +130,6 @@ static int amdgpu_is_fw_attestation_supported(struct 
> amdgpu_device *adev)
>
>  void amdgpu_fw_attestation_debugfs_init(struct amdgpu_device *adev)
>  {
> -#if defined(CONFIG_DEBUG_FS)
> if (!amdgpu_is_fw_attestation_supported(adev))
> return;
>
> @@ -139,5 +138,4 @@ void amdgpu_fw_attestation_debugfs_init(struct 
> amdgpu_device *adev)
> adev_to_drm(adev)->primary->debugfs_root,
> adev,
> _fw_attestation_debugfs_ops);
> -#endif
>  }
> --
> 2.27.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: fix debugfs creation/removal, again

[Alex Deucher]

On Fri, Dec 4, 2020 at 1:17 AM Zhou1, Tao  wrote:
>
> [AMD Public Use]
>
> Reviewed-by: Tao Zhou 

Applied.  Thanks!

Alex

>
> > -Original Message-
> > From: Arnd Bergmann 
> > Sent: Friday, December 4, 2020 7:07 AM
> > To: Deucher, Alexander ; Koenig, Christian
> > ; David Airlie ; Daniel Vetter
> > ; Li, Dennis ; Zhou1, Tao
> > ; Chen, Guchun 
> > Cc: Arnd Bergmann ; Zhang, Hawking
> > ; Clements, John ;
> > Yang, Stanley ; Ma, Le ; amd-
> > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> > ker...@vger.kernel.org
> > Subject: [PATCH] drm/amdgpu: fix debugfs creation/removal, again
> >
> > From: Arnd Bergmann 
> >
> > There is still a warning when CONFIG_DEBUG_FS is disabled:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1145:13: error:
> > 'amdgpu_ras_debugfs_create_ctrl_node' defined but not used [-
> > Werror=unused-function]
> >  1145 | static void amdgpu_ras_debugfs_create_ctrl_node(struct
> > amdgpu_device *adev)
> >
> > Change the code again to make the compiler actually drop this code but not
> > warn about it.
> >
> > Fixes: ae2bf61ff39e ("drm/amdgpu: guard ras debugfs creation/removal based
> > on CONFIG_DEBUG_FS")
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 13 +
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h |  6 --
> >  2 files changed, 5 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> > index 9d11b847e6ef..c136bd449744 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> > @@ -1167,7 +1167,7 @@ static void
> > amdgpu_ras_debugfs_create_ctrl_node(struct amdgpu_device *adev)
> >   con->dir, >disable_ras_err_cnt_harvest);
> >  }
> >
> > -void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
> > +static void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
> >   struct ras_fs_if *head)
> >  {
> >   struct amdgpu_ras *con = amdgpu_ras_get_context(adev); @@ -1189,7
> > +1189,6 @@ void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
> >
> >  void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev)  { -#if
> > defined(CONFIG_DEBUG_FS)
> >   struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
> >   struct ras_manager *obj;
> >   struct ras_fs_if fs_info;
> > @@ -1198,7 +1197,7 @@ void amdgpu_ras_debugfs_create_all(struct
> > amdgpu_device *adev)
> >* it won't be called in resume path, no need to check
> >* suspend and gpu reset status
> >*/
> > - if (!con)
> > + if (!IS_ENABLED(CONFIG_DEBUG_FS) || !con)
> >   return;
> >
> >   amdgpu_ras_debugfs_create_ctrl_node(adev);
> > @@ -1212,10 +1211,9 @@ void amdgpu_ras_debugfs_create_all(struct
> > amdgpu_device *adev)
> >   amdgpu_ras_debugfs_create(adev, _info);
> >   }
> >   }
> > -#endif
> >  }
> >
> > -void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
> > +static void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
> >   struct ras_common_if *head)
> >  {
> >   struct ras_manager *obj = amdgpu_ras_find_obj(adev, head); @@ -
> > 1229,7 +1227,6 @@ void amdgpu_ras_debugfs_remove(struct amdgpu_device
> > *adev,
> >
> >  static void amdgpu_ras_debugfs_remove_all(struct amdgpu_device *adev)  { -
> > #if defined(CONFIG_DEBUG_FS)
> >   struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
> >   struct ras_manager *obj, *tmp;
> >
> > @@ -1238,7 +1235,6 @@ static void amdgpu_ras_debugfs_remove_all(struct
> > amdgpu_device *adev)
> >   }
> >
> >   con->dir = NULL;
> > -#endif
> >  }
> >  /* debugfs end */
> >
> > @@ -1286,7 +1282,8 @@ static int amdgpu_ras_fs_init(struct amdgpu_device
> > *adev)
> >
> >  static int amdgpu_ras_fs_fini(struct amdgpu_device *adev)  {
> > - amdgpu_ras_debugfs_remove_all(adev);
> > + if (IS_ENABLED(CONFIG_DEBUG_FS))
> > + amdgpu_ras_debugfs_remove_all(adev);
> >   amdgpu_ras_sysfs_remove_all(adev);
> >   return 0;
> >  }
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> > index 4667cce38582..762f5e46c007 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> > @@ -592,14 +592,8 @@ int amdgpu_ras_sysfs_create(struct amdgpu_device
> > *adev,  int amdgpu_ras_sysfs_remove(struct amdgpu_device *adev,
> >   struct ras_common_if *head);
> >
> > -void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
> > - struct ras_fs_if *head);
> > -
> >  void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev);
> >
> > -void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
> > - struct ras_common_if *head);
> > -
> >  int amdgpu_ras_error_query(struct amdgpu_device *adev,
> >   struct ras_query_if *info);
> >
> > --
> > 

Re: [PATCH] dma-buf: Fix kerneldoc formatting

[Simon Ser]

On Friday, December 4th, 2020 at 9:02 PM, Daniel Vetter 
 wrote:

> I wanted to look up something and noticed the hyperlink doesn't work.
> While fixing that also noticed a trivial kerneldoc comment typo in the
> same section, fix that too.

Reviewed-by: Simon Ser 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf: Fix kerneldoc formatting

[Daniel Vetter]

I wanted to look up something and noticed the hyperlink doesn't work.
While fixing that also noticed a trivial kerneldoc comment typo in the
same section, fix that too.

Signed-off-by: Daniel Vetter 
---
 Documentation/driver-api/dma-buf.rst | 2 +-
 include/linux/dma-buf-map.h  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index d6b2a195dbed..a2133d69872c 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -190,7 +190,7 @@ DMA Fence uABI/Sync File
 Indefinite DMA Fences
 ~
 
-At various times _fence with an indefinite time until dma_fence_wait()
+At various times struct dma_fence with an indefinite time until 
dma_fence_wait()
 finishes have been proposed. Examples include:
 
 * Future fences, used in HWC1 to signal when a buffer isn't used by the display
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index 583a3a1f9447..278d489e4bdd 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -122,7 +122,7 @@ struct dma_buf_map {
 
 /**
  * DMA_BUF_MAP_INIT_VADDR - Initializes struct dma_buf_map to an address in 
system memory
- * @vaddr: A system-memory address
+ * @vaddr_:A system-memory address
  */
 #define DMA_BUF_MAP_INIT_VADDR(vaddr_) \
{ \
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 5/7] drm/tidss: Set bus_format correctly from bridge/connector

[Tomi Valkeinen]

On 04/12/2020 15:54, Boris Brezillon wrote:
> On Fri, 4 Dec 2020 13:47:05 +0200
> Tomi Valkeinen  wrote:
> 
>> On 04/12/2020 13:12, Boris Brezillon wrote:
>>
> That'd be even better if you implement the bridge interface instead of
> the encoder one so we can get rid of the encoder_{helper}_funcs and use
> drm_simple_encoder_init().

 I'm a bit confused here. What should be the design here...

 These formats need to be handled by the crtc (well, the display 
 controller, which is modeled as the
 crtc). Should we have a tidss_crtc.c file, which implements a crtc, a 
 simple encoder and a bridge?
 And just consider those three DRM components as different API parts of the 
 display controller?  
>>>
>>> The idea is to hide the encoder abstraction from drivers as much as we
>>> can. We have to keep the encoder concept because that's what we expose
>>> to userspace, but drivers shouldn't have to worry about the distinction
>>> between the first bridge in the chain (what we currently call encoders)
>>> and other bridges. The bridge interface provides pretty much the same
>>> functionality, so all you need to do is turn your encoder driver into a
>>> bridge driver (see what we did for
>>> drivers/gpu/drm/imx/parallel-display.c), the only particularity here is
>>> that the bridge knows it's the first in the chain, and has access to
>>> the CRTC it's directly connected to.  
>>
>> With a quick look, the imx parallel-display.c seems to be really part of the 
>> crtc. Shouldn't we then
>> take one more step forward, and just combine the crtc, encoder and bridge 
>> (somehow)? That's kind of
>> what parallel-display.c is doing, isn't it? It's directly poking the crtc 
>> state, but the code just
>> happens to be in a separate file from the crtc.
> 
> Right. If we want to keep the code split, the logic should probably be
> reversed, with the CRTC driver checking the first bridge state to setup
> its internal state. Those DPI encoders are always a bit special, since
> they tend to be directly embedded in the block responsible for timing
> control (what we call CRTCs), so you're right, maybe we should model
> that as a CRTC+bridge pair.
> 
>>
>> Thinking about the TI HW, we have a bunch of internal IPs which are clearly 
>> bridges: HDMI, DSI,
>> which get the pixel data from the display controller, and they have their 
>> own registers, so clearly
>> independent bridges.
>>
>> Then we have MIPI DPI, which doesn't really have its own registers, as it's 
>> just plain parallel RGB,
>> the same as what is sent to e.g. HDMI and DSI bridges.
> 
> I still consider that one a bridge, even if the translation is almost
> transparent from a HW PoV.
> 
>> However, there might be some muxes or
>> regulators to set up to get the external signals working. So a bridge would 
>> be ok here too to handle
>> that external side.
> 
> Exactly.
> 
>>
>> But in all the above cases, we have the display controller (crtc), which in 
>> all the cases needs to
>> do e.g. pixel/bus format configuration. So why add direct crtc poking into 
>> the first bridges (HDMI,
>> DSI, DPI), when we could just model the crtc as a bridge, and thus the first 
>> bridges wouldn't need
>> to touch the crtc.
> 
> Yes, that's an option. I mean, you can already modify your CRTC
> logic to implement the bridge and CRTC interface and have your
> driver-specific CRTC object embed both a drm_crtc and a drm_bridge.

Alright, thanks for the clarifications!

I think the best first step here is what you proposed, use the bridge interface 
and
drm_simple_encoder_init(), as that should solve the issue at hand quite neatly.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v1 00/12] Replace strstarts() by str_has_prefix()

[James Bottomley]

On Fri, 2020-12-04 at 18:03 +0100, laniel_fran...@privacyrequired.com
wrote:
> In this patch set, I replaced all calls to strstarts() by calls to
> str_has_prefix(). Indeed, the kernel has two functions to test if a
> string begins with an other:
> 1. strstarts() which returns a bool, so 1 if the string begins with
> the prefix,0 otherwise.
> 2. str_has_prefix() which returns the length of the prefix or 0.
> 
> str_has_prefix() was introduced later than strstarts(), in commit
> 495d714ad140 which also stated that str_has_prefix() should replace
> strstarts(). This is what this patch set does.

What's the reason why?  If you look at the use cases for the
replacement of strstart()  they're all cases where we need to know the
length we're skipping and this is hard coded, leading to potential
errors later.  This is a classic example:  3d739c1f6156 ("tracing: Use
the return of str_has_prefix() to remove open coded numbers").  However
you're not doing this transformation in the conversion, so the
conversion is pretty useless.  I also see no case for replacing
strstart() where we're using it simply as a boolean without needing to
know the length of the prefix.

James


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] dt-bindings: eliminate yamllint warnings

[Mark Brown]

On Fri, Dec 04, 2020 at 10:42:26AM +0800, Zhen Lei wrote:
> All warnings are related only to "wrong indentation", except one:
> Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:4:1: \
> [error] missing document start "---" (document-start)

It would make life easier (and be more normal practice) to split this up
by driver/subsystem and send a bunch of separate patches to the relevant
maintainers, this makes it much easier to review and handle things.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes for 5.10-rc7

[pr-tracker-bot]

The pull request you sent on Fri, 4 Dec 2020 12:25:35 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-12-04

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e87297fa080a7ed6b431873c771b3801cab573f5

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ttm: fix unused function warning

[Arnd Bergmann]

From: Arnd Bergmann 

ttm_pool_type_count() is not used when debugfs is disabled:

drivers/gpu/drm/ttm/ttm_pool.c:243:21: error: unused function 
'ttm_pool_type_count' [-Werror,-Wunused-function]
static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)

Move the definition into the #ifdef block.

Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/ttm/ttm_pool.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 5455b2044759..7b2f60616750 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -239,21 +239,6 @@ static struct page *ttm_pool_type_take(struct 
ttm_pool_type *pt)
return p;
 }
 
-/* Count the number of pages available in a pool_type */
-static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
-{
-   unsigned int count = 0;
-   struct page *p;
-
-   spin_lock(>lock);
-   /* Only used for debugfs, the overhead doesn't matter */
-   list_for_each_entry(p, >pages, lru)
-   ++count;
-   spin_unlock(>lock);
-
-   return count;
-}
-
 /* Initialize and add a pool type to the global shrinker list */
 static void ttm_pool_type_init(struct ttm_pool_type *pt, struct ttm_pool *pool,
   enum ttm_caching caching, unsigned int order)
@@ -543,6 +528,20 @@ void ttm_pool_fini(struct ttm_pool *pool)
 EXPORT_SYMBOL(ttm_pool_fini);
 
 #ifdef CONFIG_DEBUG_FS
+/* Count the number of pages available in a pool_type */
+static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
+{
+   unsigned int count = 0;
+   struct page *p;
+
+   spin_lock(>lock);
+   /* Only used for debugfs, the overhead doesn't matter */
+   list_for_each_entry(p, >pages, lru)
+   ++count;
+   spin_unlock(>lock);
+
+   return count;
+}
 
 /* Dump information about the different pool types */
 static void ttm_pool_debugfs_orders(struct ttm_pool_type *pt,
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: fw_attestation: fix unused function warning

[Arnd Bergmann]

From: Arnd Bergmann 

Without debugfs, the compiler notices one function that is not used at
all:

drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c:123:12: error: unused 
function 'amdgpu_is_fw_attestation_supported' [-Werror,-Wunused-function]

In fact the static const amdgpu_fw_attestation_debugfs_ops structure is
also unused here, but that warning is currently disabled.

Removing the #ifdef check does the right thing and leads to all of this
code to be dropped without warning.

Fixes: 19ae333001b3 ("drm/amdgpu: added support for psp fw attestation")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
index e47bca1c7635..7c6e02e35573 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
@@ -130,7 +130,6 @@ static int amdgpu_is_fw_attestation_supported(struct 
amdgpu_device *adev)
 
 void amdgpu_fw_attestation_debugfs_init(struct amdgpu_device *adev)
 {
-#if defined(CONFIG_DEBUG_FS)
if (!amdgpu_is_fw_attestation_supported(adev))
return;
 
@@ -139,5 +138,4 @@ void amdgpu_fw_attestation_debugfs_init(struct 
amdgpu_device *adev)
adev_to_drm(adev)->primary->debugfs_root,
adev,
_fw_attestation_debugfs_ops);
-#endif
 }
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v11 04/10] memory: tegra124-emc: Make driver modular

[Thierry Reding]

On Thu, Dec 03, 2020 at 10:24:33PM +0300, Dmitry Osipenko wrote:
> Add modularization support to the Tegra124 EMC driver, which now can be
> compiled as a loadable kernel module.
> 
> Note that EMC clock must be registered at clk-init time, otherwise PLLM
> will be disabled as unused clock at boot time if EMC driver is compiled
> as a module. Hence add a prepare/complete callbacks. similarly to what is
> done for the Tegra20/30 EMC drivers.
> 
> Tested-by: Nicolas Chauvet 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/clk/tegra/Kconfig|  3 ++
>  drivers/clk/tegra/Makefile   |  2 +-
>  drivers/clk/tegra/clk-tegra124-emc.c | 41 
>  drivers/clk/tegra/clk-tegra124.c | 26 --
>  drivers/clk/tegra/clk.h  | 18 
>  drivers/memory/tegra/Kconfig |  3 +-
>  drivers/memory/tegra/tegra124-emc.c  | 31 ++---
>  include/linux/clk/tegra.h|  8 ++
>  include/soc/tegra/emc.h  | 16 ---
>  9 files changed, 106 insertions(+), 42 deletions(-)
>  delete mode 100644 include/soc/tegra/emc.h
> 
> diff --git a/drivers/clk/tegra/Kconfig b/drivers/clk/tegra/Kconfig
> index deaa4605824c..90df619dc087 100644
> --- a/drivers/clk/tegra/Kconfig
> +++ b/drivers/clk/tegra/Kconfig
> @@ -7,3 +7,6 @@ config TEGRA_CLK_DFLL
>   depends on ARCH_TEGRA_124_SOC || ARCH_TEGRA_210_SOC
>   select PM_OPP
>   def_bool y
> +
> +config TEGRA124_CLK_EMC
> + bool
> diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
> index eec2313fd37e..7b1816856eb5 100644
> --- a/drivers/clk/tegra/Makefile
> +++ b/drivers/clk/tegra/Makefile
> @@ -22,7 +22,7 @@ obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += 
> clk-tegra20-emc.o
>  obj-$(CONFIG_ARCH_TEGRA_114_SOC) += clk-tegra114.o
>  obj-$(CONFIG_ARCH_TEGRA_124_SOC) += clk-tegra124.o
>  obj-$(CONFIG_TEGRA_CLK_DFLL) += clk-tegra124-dfll-fcpu.o
> -obj-$(CONFIG_TEGRA124_EMC)   += clk-tegra124-emc.o
> +obj-$(CONFIG_TEGRA124_CLK_EMC)   += clk-tegra124-emc.o
>  obj-$(CONFIG_ARCH_TEGRA_132_SOC) += clk-tegra124.o
>  obj-y+= cvb.o
>  obj-$(CONFIG_ARCH_TEGRA_210_SOC) += clk-tegra210.o
> diff --git a/drivers/clk/tegra/clk-tegra124-emc.c 
> b/drivers/clk/tegra/clk-tegra124-emc.c
> index 745f9faa98d8..bdf6f4a51617 100644
> --- a/drivers/clk/tegra/clk-tegra124-emc.c
> +++ b/drivers/clk/tegra/clk-tegra124-emc.c
> @@ -11,7 +11,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -21,7 +23,6 @@
>  #include 
>  
>  #include 
> -#include 
>  
>  #include "clk.h"
>  
> @@ -80,6 +81,9 @@ struct tegra_clk_emc {
>   int num_timings;
>   struct emc_timing *timings;
>   spinlock_t *lock;
> +
> + tegra124_emc_prepare_timing_change_cb *prepare_timing_change;
> + tegra124_emc_complete_timing_change_cb *complete_timing_change;
>  };
>  
>  /* Common clock framework callback implementations */
> @@ -176,6 +180,9 @@ static struct tegra_emc *emc_ensure_emc_driver(struct 
> tegra_clk_emc *tegra)
>   if (tegra->emc)
>   return tegra->emc;
>  
> + if (!tegra->prepare_timing_change || !tegra->complete_timing_change)
> + return NULL;
> +
>   if (!tegra->emc_node)
>   return NULL;
>  
> @@ -241,7 +248,7 @@ static int emc_set_timing(struct tegra_clk_emc *tegra,
>  
>   div = timing->parent_rate / (timing->rate / 2) - 2;
>  
> - err = tegra_emc_prepare_timing_change(emc, timing->rate);
> + err = tegra->prepare_timing_change(emc, timing->rate);
>   if (err)
>   return err;
>  
> @@ -259,7 +266,7 @@ static int emc_set_timing(struct tegra_clk_emc *tegra,
>  
>   spin_unlock_irqrestore(tegra->lock, flags);
>  
> - tegra_emc_complete_timing_change(emc, timing->rate);
> + tegra->complete_timing_change(emc, timing->rate);
>  
>   clk_hw_reparent(>hw, __clk_get_hw(timing->parent));
>   clk_disable_unprepare(tegra->prev_parent);
> @@ -473,8 +480,8 @@ static const struct clk_ops tegra_clk_emc_ops = {
>   .get_parent = emc_get_parent,
>  };
>  
> -struct clk *tegra_clk_register_emc(void __iomem *base, struct device_node 
> *np,
> -spinlock_t *lock)
> +struct clk *tegra124_clk_register_emc(void __iomem *base, struct device_node 
> *np,
> +   spinlock_t *lock)
>  {
>   struct tegra_clk_emc *tegra;
>   struct clk_init_data init;
> @@ -538,3 +545,27 @@ struct clk *tegra_clk_register_emc(void __iomem *base, 
> struct device_node *np,
>  
>   return clk;
>  };
> +
> +void tegra124_clk_set_emc_callbacks(tegra124_emc_prepare_timing_change_cb 
> *prep_cb,
> + tegra124_emc_complete_timing_change_cb 
> *complete_cb)
> +{
> + struct clk *clk = __clk_lookup("emc");
> + struct tegra_clk_emc *tegra;
> + struct 

Re: [PATCH v11 03/10] memory: tegra30: Support interconnect framework

[Thierry Reding]

On Thu, Dec 03, 2020 at 10:24:32PM +0300, Dmitry Osipenko wrote:
> Now Internal and External memory controllers are memory interconnection
> providers. This allows us to use interconnect API for tuning of memory
> configuration. EMC driver now supports OPPs and DVFS. MC driver now
> supports tuning of memory arbitration latency, which needs to be done
> for ISO memory clients, like a Display client for example.
> 
> Tested-by: Peter Geis 
> Acked-by: Georgi Djakov 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/memory/tegra/Kconfig   |   1 +
>  drivers/memory/tegra/tegra30-emc.c | 344 +++--
>  drivers/memory/tegra/tegra30.c | 173 ++-
>  3 files changed, 496 insertions(+), 22 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v11 02/10] memory: tegra20: Support hardware versioning and clean up OPP table initialization

[Thierry Reding]

On Thu, Dec 03, 2020 at 10:24:31PM +0300, Dmitry Osipenko wrote:
> Support hardware versioning, which is now required for Tegra20 EMC OPP.
> Clean up OPP table initialization by using a error code returned by OPP
> API for judging about the OPP table presence in a device-tree and remove
> OPP regulator initialization because we're now going to use power domain
> instead of a raw regulator. This puts Tegra20 EMC OPP preparation on par
> with the Tegra30/124 EMC drivers.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/memory/tegra/tegra20-emc.c | 48 +-
>  1 file changed, 20 insertions(+), 28 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/7] drm: Introduce an atomic_commit_setup function

[Daniel Vetter]

On Fri, Dec 4, 2020 at 4:11 PM Maxime Ripard  wrote:
>
> Private objects storing a state shared across all CRTCs need to be
> carefully handled to avoid a use-after-free issue.
>
> The proper way to do this to track all the commits using that shared
> state and wait for the previous commits to be done before going on with
> the current one to avoid the reordering of commits that could occur.
>
> However, this commit setup needs to be done after
> drm_atomic_helper_setup_commit(), because before the CRTC commit
> structure hasn't been allocated before, and before the workqueue is
> scheduled, because we would be potentially reordered already otherwise.
>
> That means that drivers currently have to roll their own
> drm_atomic_helper_commit() function, even though it would be identical
> if not for the commit setup.
>
> Let's introduce a hook to do so that would be called as part of
> drm_atomic_helper_commit, allowing us to reuse the atomic helpers.
>
> Suggested-by: Daniel Vetter 
> Signed-off-by: Maxime Ripard 

r-b: me too

Cheers, Daniel

> ---
>  drivers/gpu/drm/drm_atomic_helper.c  |  9 +
>  include/drm/drm_modeset_helper_vtables.h | 21 +
>  2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index f9170b4b22e7..f754e21b96eb 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2034,6 +2034,9 @@ crtc_or_fake_commit(struct drm_atomic_state *state, 
> struct drm_crtc *crtc)
>   * should always call this function from their
>   * _mode_config_funcs.atomic_commit hook.
>   *
> + * Drivers that need to extend the commit setup to private objects can use 
> the
> + * _mode_config_helper_funcs.atomic_commit_setup hook.
> + *
>   * To be able to use this support drivers need to use a few more helper
>   * functions. drm_atomic_helper_wait_for_dependencies() must be called before
>   * actually committing the hardware state, and for nonblocking commits this 
> call
> @@ -2077,8 +2080,11 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
> struct drm_plane *plane;
> struct drm_plane_state *old_plane_state, *new_plane_state;
> struct drm_crtc_commit *commit;
> +   const struct drm_mode_config_helper_funcs *funcs;
> int i, ret;
>
> +   funcs = state->dev->mode_config.helper_private;
> +
> for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> commit = kzalloc(sizeof(*commit), GFP_KERNEL);
> if (!commit)
> @@ -2155,6 +2161,9 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
> new_plane_state->commit = drm_crtc_commit_get(commit);
> }
>
> +   if (funcs && funcs->atomic_commit_setup)
> +   return funcs->atomic_commit_setup(state);
> +
> return 0;
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_setup_commit);
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index 4efec30f8bad..0ebb3f191bbc 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1406,6 +1406,27 @@ struct drm_mode_config_helper_funcs {
>  * drm_atomic_helper_commit_tail().
>  */
> void (*atomic_commit_tail)(struct drm_atomic_state *state);
> +
> +   /**
> +* @atomic_commit_setup:
> +*
> +* This hook is used by the default atomic_commit() hook implemented 
> in
> +* drm_atomic_helper_commit() together with the nonblocking helpers 
> (see
> +* drm_atomic_helper_setup_commit()) to extend the DRM commit setup. 
> It
> +* is not used by the atomic helpers.
> +*
> +* This function is called at the end of
> +* drm_atomic_helper_setup_commit(), so once the commit has been
> +* properly setup across the generic DRM object states. It allows
> +* drivers to do some additional commit tracking that isn't related 
> to a
> +* CRTC, plane or connector, tracked in a _private_obj structure.
> +*
> +* Note that the documentation of _private_obj has more details on
> +* how one should implement this.
> +*
> +* This hook is optional.
> +*/
> +   int (*atomic_commit_setup)(struct drm_atomic_state *state);
>  };
>
>  #endif
> --
> 2.28.0
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Fix drm.h uapi header for Windows

[Daniel Vetter]

On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen  wrote:
>
> On Thu, 3 Dec 2020 21:45:14 +0100
> Daniel Vetter  wrote:
>
> > On Thu, Dec 3, 2020 at 7:55 PM James Park  
> > wrote:
> > >
> > > The trailing underscore for  DRM_FOURCC_STANDALONE_ isn't
> > > intentional, right? Should I put all the integer types, or just the
> > > ones that are used in that file?
> >
> > Yeah that trailing _ just slipped in. And I'd just do the types
> > already used. I don't think anything else than __u32 (for drm fourcc)
> > and __u64 (for drm modifier) is needed.
>
> Hi,
>
> can that create conflicts if userspace first includes drm_fourcc.h and
> then drm.h?
>
> I would find it natural to userspace have generic headers including
> drm_fourcc.h and then DRM-specific C-files including drm.h as well
> (through libdrm headers). I think Weston might already do this.
>
> The generic userspace (weston) header would obviously #define
> DRM_FOURCC_STANDALONE, because it is used by non-DRM C-files as well.

Hm yes that would break. I guess we could just include the linux types
header for this. And I guess on windows you'd need to have that from
somewhere. Or we just require that users of the standalone header pull
the right header or defines in first?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v10 17/19] ARM: tegra: Add EMC OPP properties to Tegra20 device-trees

[Thierry Reding]

On Tue, Dec 01, 2020 at 01:57:44AM +0300, Dmitry Osipenko wrote:
> 01.12.2020 00:17, Jon Hunter пишет:
> > Hi Dmitry,
> > 
> > On 23/11/2020 00:27, Dmitry Osipenko wrote:
> >> Add EMC OPP DVFS tables and update board device-trees by removing
> >> unsupported OPPs.
> >>
> >> Signed-off-by: Dmitry Osipenko 
> > This change is generating the following warning on Tegra20 Ventana
> > and prevents the EMC from probing ...
> > 
> > [2.485711] tegra20-emc 7000f400.memory-controller: device-tree doesn't 
> > have memory timings
> > [2.499386] tegra20-emc 7000f400.memory-controller: 32bit DRAM bus
> > [2.505810] [ cut here ]
> > [2.510511] WARNING: CPU: 0 PID: 1 at 
> > /local/workdir/tegra/mlt-linux_next/kernel/drivers/opp/of.c:875 
> > _of_add_opp_table_v2+0x598/0x61c
> > [2.529746] Modules linked in:
> > [2.540140] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> > 5.10.0-rc5-next-20201130 #1
> > [2.554606] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
> > [2.560892] [] (unwind_backtrace) from [] 
> > (show_stack+0x10/0x14)
> > [2.568640] [] (show_stack) from [] 
> > (dump_stack+0xc8/0xdc)
> > [2.575866] [] (dump_stack) from [] 
> > (__warn+0x104/0x108)
> > [2.582912] [] (__warn) from [] 
> > (warn_slowpath_fmt+0xb0/0xb8)
> > [2.590397] [] (warn_slowpath_fmt) from [] 
> > (_of_add_opp_table_v2+0x598/0x61c)
> > [2.599269] [] (_of_add_opp_table_v2) from [] 
> > (dev_pm_opp_of_add_table+0x3c/0x1a0)
> > [2.608582] [] (dev_pm_opp_of_add_table) from [] 
> > (tegra_emc_probe+0x478/0x940)
> > [2.617548] [] (tegra_emc_probe) from [] 
> > (platform_drv_probe+0x48/0x98)
> > [2.625899] [] (platform_drv_probe) from [] 
> > (really_probe+0x218/0x3b8)
> > [2.634162] [] (really_probe) from [] 
> > (driver_probe_device+0x5c/0xb4)
> > [2.642338] [] (driver_probe_device) from [] 
> > (device_driver_attach+0x58/0x60)
> > [2.651208] [] (device_driver_attach) from [] 
> > (__driver_attach+0x80/0xbc)
> > [2.659730] [] (__driver_attach) from [] 
> > (bus_for_each_dev+0x74/0xb4)
> > [2.667905] [] (bus_for_each_dev) from [] 
> > (bus_add_driver+0x164/0x1e8)
> > [2.676168] [] (bus_add_driver) from [] 
> > (driver_register+0x7c/0x114)
> > [2.684259] [] (driver_register) from [] 
> > (do_one_initcall+0x54/0x2b0)
> > [2.692441] [] (do_one_initcall) from [] 
> > (kernel_init_freeable+0x1a4/0x1f4)
> > [2.701145] [] (kernel_init_freeable) from [] 
> > (kernel_init+0x8/0x118)
> > [2.709321] [] (kernel_init) from [] 
> > (ret_from_fork+0x14/0x24)
> > [2.716885] Exception stack(0xc1501fb0 to 0xc1501ff8)
> > [2.721933] 1fa0:   
> >  
> > [2.730106] 1fc0:       
> >  
> > [2.738278] 1fe0:     0013 
> > [2.751940] ---[ end trace 61e3b76deca27ef3 ]---
> > 
> > 
> > Cheers
> > Jon
> > 
> 
> Hello Jon,
> 
> That is harmless and expected to happen because the patch "memory:
> tegra20: Support hardware versioning and clean up OPP table
> initialization" isn't applied yet, while Thierry already applied the DT
> patches from this v10.

Hmm... that's new. Since when are device tree additions expected to
cause these kinds of splats?

Anyway, I did apply these because I had seen at least some of the memory
controller driver patches appear in linux-next and hence had assumed
that the whole series had gone in, not realizing there was anything left
to do.

Krzysztof, what's your schedule for the memory controller tree? My
recollection is that this will feed into ARM SoC, so if the -rc6 dead-
line applies like it does for platforms, then I may need to revert the
DT patch that causes this so that we don't have to drag this along
through all of the release cycle. If there's still time for you to send
that PR, perhaps we can get the remainder of the Tegra interconnect
series merged for v5.11 as well?

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 5/7] drm/tidss: Set bus_format correctly from bridge/connector

[Tomi Valkeinen]

On 04/12/2020 13:12, Boris Brezillon wrote:

>>> That'd be even better if you implement the bridge interface instead of
>>> the encoder one so we can get rid of the encoder_{helper}_funcs and use
>>> drm_simple_encoder_init().  
>>
>> I'm a bit confused here. What should be the design here...
>>
>> These formats need to be handled by the crtc (well, the display controller, 
>> which is modeled as the
>> crtc). Should we have a tidss_crtc.c file, which implements a crtc, a simple 
>> encoder and a bridge?
>> And just consider those three DRM components as different API parts of the 
>> display controller?
> 
> The idea is to hide the encoder abstraction from drivers as much as we
> can. We have to keep the encoder concept because that's what we expose
> to userspace, but drivers shouldn't have to worry about the distinction
> between the first bridge in the chain (what we currently call encoders)
> and other bridges. The bridge interface provides pretty much the same
> functionality, so all you need to do is turn your encoder driver into a
> bridge driver (see what we did for
> drivers/gpu/drm/imx/parallel-display.c), the only particularity here is
> that the bridge knows it's the first in the chain, and has access to
> the CRTC it's directly connected to.

With a quick look, the imx parallel-display.c seems to be really part of the 
crtc. Shouldn't we then
take one more step forward, and just combine the crtc, encoder and bridge 
(somehow)? That's kind of
what parallel-display.c is doing, isn't it? It's directly poking the crtc 
state, but the code just
happens to be in a separate file from the crtc.

Thinking about the TI HW, we have a bunch of internal IPs which are clearly 
bridges: HDMI, DSI,
which get the pixel data from the display controller, and they have their own 
registers, so clearly
independent bridges.

Then we have MIPI DPI, which doesn't really have its own registers, as it's 
just plain parallel RGB,
the same as what is sent to e.g. HDMI and DSI bridges. However, there might be 
some muxes or
regulators to set up to get the external signals working. So a bridge would be 
ok here too to handle
that external side.

But in all the above cases, we have the display controller (crtc), which in all 
the cases needs to
do e.g. pixel/bus format configuration. So why add direct crtc poking into the 
first bridges (HDMI,
DSI, DPI), when we could just model the crtc as a bridge, and thus the first 
bridges wouldn't need
to touch the crtc.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v11 01/10] dt-bindings: memory: tegra20: emc: Document opp-supported-hw property

[Thierry Reding]

On Thu, Dec 03, 2020 at 10:24:30PM +0300, Dmitry Osipenko wrote:
> Document opp-supported-hw property, which is not strictly necessary to
> have on Tegra20, but it's very convenient to have because all other SoC
> core devices will use hardware versioning, and thus, it's good to maintain
> the consistency.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  .../bindings/memory-controllers/nvidia,tegra20-emc.txt  | 6 ++
>  1 file changed, 6 insertions(+)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 1/2] drm: RFC add choice to use dynamic debug in drm-debug

[Ville Syrjälä]

On Thu, Dec 03, 2020 at 08:53:17PM -0700, Jim Cromie wrote:
> drm's debug system uses distinct categories of debug messages, mapped
> to bits in drm.debug.  Currently, code does a lot of unlikely bit-mask
> checks on drm.debug (in drm_debug_enabled), we can use dynamic debug
> instead, and get all that jump_label goodness.

whatis jump_label?

One thing that bugs me about the current drm_dbg() stuff is that
it's a function, and thus we pay the cost of setting up the
arguments even when debugs are not enabled. I played around a bit
with making it a macro again with the unlikely bit check moved
into the macro. That did seem to make some of the asm a bit nicer
where the debug stuff got shoved out the main codepath, but
it did result in a slight net increase in code size. What I didn't
have time to do is check if this has any measurable speed effect
on eg. TEST_ONLY commits.

And while doing that I started to ponder if we could use something
like the alternate() instruction stuff to patch the code at runtime
in order to turn all those debug checks into nops when debugging
is not enabled. But I couldn't immediately find any generic
infrastructure for it. So now I wonder if this jump_label is something
like that?

> 
> RFC: dynamic debug has no concept of category, but we can do without
> one if we can prepend a class-prefix to each printk format.  Then we
> can use "format ^prefix" to select the whole category with one query.
> This is a log-facing and user visible change, but it seems unlikely to
> cause trouble for log watchers; they're not relying on the absence of
> class prefix strings.
> 
> This conversion yields ~2100 new callsites on my i7 laptop:
> 
>   dyndbg: 195 debug prints in module drm_kms_helper
>   dyndbg: 298 debug prints in module drm
>   dyndbg: 1630 debug prints in module i915
> 
> Since this change has wide-ranging effects (many drm drivers, with
> many callsites, and kernel image growth), and most vendors don't
> enable DYNAMIC_DEBUG, we supplement the existing mechanism, adding
> CONFIG_DRM_USE_DYNAMIC_DEBUG to enable the new one.
> 
> The indirection/switchover has a few parts:
> 
> 1 a new callback on drm.debug which calls dynamic_debug_exec_queries
>   to map those bits to specific query/commands
>   dynamic_debug_exec_queries("format ^drm:kms: +p", "drm*");
> 
> 2 a "converted" or "classy" DRM_UT_* map
>   similar to DRM_UT_* ( symbol => bit-mask )
>   named it  cDRM_UT_* ( symbol => format-class-prefix-string )
> 
>   cDRM_UT_* is either ( CONFIG_DRM_USE_DYNAMIC_DEBUG )
>   legacy: cDRM_UT_* <-- DRM_UT_*
>   enabled:
>   +#define cDRM_UT_KMS"drm:kms: "
>   +#define cDRM_UT_PRIME  "drm:prime: "
>   +#define cDRM_UT_ATOMIC "drm:atomic: "
> 
>   these are similar to "gvt: cmd:" in i915/gvt
>   and effectively a replacement for DRM_NAME
>   please bikeshed on keys, values. latter are log-facing.
> 
> 3 drm_dev_dbg & drm_debug are renamed (prefixed with '_')
>   old names are now macros, which are ifdefd
>   legacy:  -> to renamed fn
>   enabled: -> dev_dbg & pr_debug, after prepending prefix to format.
> 
> 4 names in (2) are called from DRM_DEBUG_ and drm_dbg_.
>   all these get "converted" to use cDRM_UT_*, to get right token type.
> 
> RFC: for dynamic debug, category is a source-facing addition;
> something like pr_debug_cat(cat, ...) would do it, iff cat is a
> compile-time const.  Note that cat isn't needed in the printing, it
> would be saved into a new field in struct _ddebug, and used only for
> callsite selection, activation and control.
> 
> Signed-off-by: Jim Cromie 
> ---
>  drivers/gpu/drm/Kconfig | 13 ++
>  drivers/gpu/drm/drm_print.c | 75 --
>  include/drm/drm_print.h | 92 +++--
>  3 files changed, 153 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 147d61b9674e..854bc1ad21fb 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -54,6 +54,19 @@ config DRM_DEBUG_MM
>  
> If in doubt, say "N".
>  
> +config DRM_USE_DYNAMIC_DEBUG
> + bool "use dynamic debug to implement drm.debug"
> + default n
> + depends on DRM
> + depends on DYNAMIC_DEBUG
> + depends on JUMP_LABEL
> + help
> +   The drm debug category facility does a lot of unlikely bit-field
> +   tests at runtime; while cheap individually, the cost accumulates.
> +   This option uses dynamic debug facility (if configured and
> +   using jump_label) to avoid those runtime checks, patching
> +   the kernel when those debugs are desired.
> +
>  config DRM_DEBUG_SELFTEST
>   tristate "kselftests for DRM"
>   depends on DRM
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 111b932cf2a9..e2acdfc7088b 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -52,8 +52,75 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each 
> bit enables a debug cat

Re: [PATCH v2] drm/vc4: hdmi: Don't poll for the infoframes status on setup

[Dave Stevenson]

Hi Maxime

On Thu, 3 Dec 2020 at 07:46, Maxime Ripard  wrote:
>
> The infoframes are sent at a regular interval as a data island packet,
> so we don't need to wait for them to be sent when we're setting them up.
>
> However, we do need to poll when we're enabling since the we can't
> update the packet RAM until it has been sent.
>
> Let's add a boolean flag to tell whether we want to poll or not to
> support both cases.
>
> Suggested-by: Dave Stevenson 
> Signed-off-by: Maxime Ripard 

That looks like it should do what was intended - thanks.

Reviewed-by: Dave Stevenson 

> ---
>
> Changes from v1:
>   - Inverted when to poll
> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index a2c5b5e9786a..d3c4a9b5bb6d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -265,7 +265,8 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
>  }
>
>  static int vc4_hdmi_stop_packet(struct drm_encoder *encoder,
> -   enum hdmi_infoframe_type type)
> +   enum hdmi_infoframe_type type,
> +   bool poll)
>  {
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> u32 packet_id = type - 0x80;
> @@ -273,6 +274,9 @@ static int vc4_hdmi_stop_packet(struct drm_encoder 
> *encoder,
> HDMI_WRITE(HDMI_RAM_PACKET_CONFIG,
>HDMI_READ(HDMI_RAM_PACKET_CONFIG) & ~BIT(packet_id));
>
> +   if (!poll)
> +   return 0;
> +
> return wait_for(!(HDMI_READ(HDMI_RAM_PACKET_STATUS) &
>   BIT(packet_id)), 100);
>  }
> @@ -299,7 +303,7 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder 
> *encoder,
> if (len < 0)
> return;
>
> -   ret = vc4_hdmi_stop_packet(encoder, frame->any.type);
> +   ret = vc4_hdmi_stop_packet(encoder, frame->any.type, true);
> if (ret) {
> DRM_ERROR("Failed to wait for infoframe to go idle: %d\n", 
> ret);
> return;
> @@ -1056,7 +1060,7 @@ static void vc4_hdmi_audio_reset(struct vc4_hdmi 
> *vc4_hdmi)
> int ret;
>
> vc4_hdmi->audio.streaming = false;
> -   ret = vc4_hdmi_stop_packet(encoder, HDMI_INFOFRAME_TYPE_AUDIO);
> +   ret = vc4_hdmi_stop_packet(encoder, HDMI_INFOFRAME_TYPE_AUDIO, false);
> if (ret)
> dev_err(dev, "Failed to stop audio infoframe: %d\n", ret);
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/scheduler: Job timeout handler returns status (v2)

[Andrey Grodzovsky]

On 12/4/20 3:13 AM, Christian König wrote:
Thinking more about that I came to the conclusion that the whole approach here 
isn't correct.


See even when the job has been completed or canceled we still want to restart 
the timer.


The reason for this is that the timer is then not restarted for the current 
job, but for the next job in the queue.


The only valid reason to not restart the timer is that the whole device was 
hot plugged and we return -ENODEV here. E.g. what Andrey has been working on.



We discussed this with Luben off line a few days ago but came to a conclusion 
that for the next job the timer restart in drm_sched_job_begin should do the 
work, no ?


Andrey




Regards,
Christian.

Am 04.12.20 um 04:17 schrieb Luben Tuikov:

The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.

Default behaviour as of this patch, is preserved,
except in obvious-by-comment case in the Panfrost
driver, as documented below.

All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_TASK_STATUS_ALIVE to restart the task's
timeout timer--this is the old behaviour, and
is preserved by this patch.

In the case of the Panfrost driver, its timedout
callback correctly first checks if the job had
completed in due time and if so, it now returns
DRM_TASK_STATUS_COMPLETE to notify the DRM layer
that the task can be moved to the done list, to be
freed later. In the other two subsequent checks,
the value of DRM_TASK_STATUS_ALIVE is returned, as
per the default behaviour.

A more involved driver's solutions can be had
in subequent patches.

Signed-off-by: Luben Tuikov 
Reported-by: kernel test robot 

Cc: Alexander Deucher 
Cc: Andrey Grodzovsky 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Cc: Qiang Yu 
Cc: Rob Herring 
Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: Eric Anholt 

v2: Use enum as the status of a driver's job
 timeout callback method.
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  6 +++--
  drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
  drivers/gpu/drm/lima/lima_sched.c   |  4 +++-
  drivers/gpu/drm/panfrost/panfrost_job.c |  9 ---
  drivers/gpu/drm/scheduler/sched_main.c  |  4 +---
  drivers/gpu/drm/v3d/v3d_sched.c | 32 +
  include/drm/gpu_scheduler.h | 20 +---
  7 files changed, 57 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c

index ff48101bab55..a111326cbdde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
  #include "amdgpu.h"
  #include "amdgpu_trace.h"
  -static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_task_status amdgpu_job_timedout(struct drm_sched_job *s_job)
  {
  struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
  struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
  amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent)) {
  DRM_ERROR("ring %s timeout, but soft recovered\n",
    s_job->sched->name);
-    return;
+    return DRM_TASK_STATUS_ALIVE;
  }
    amdgpu_vm_get_task_info(ring->adev, job->pasid, );
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
    if (amdgpu_device_should_recover_gpu(ring->adev)) {
  amdgpu_device_gpu_recover(ring->adev, job);
+    return DRM_TASK_STATUS_ALIVE;
  } else {
  drm_sched_suspend_timeout(>sched);
  if (amdgpu_sriov_vf(adev))
  adev->virt.tdr_debug = true;
+    return DRM_TASK_STATUS_ALIVE;
  }
  }
  diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c 
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c

index cd46c882269c..c49516942328 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence *etnaviv_sched_run_job(struct 
drm_sched_job *sched_job)

  return fence;
  }
  -static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
+static enum drm_task_status etnaviv_sched_timedout_job(struct drm_sched_job
+   *sched_job)
  {
  struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
  struct etnaviv_gpu *gpu = submit->gpu;
@@ -120,9 +121,16 @@ static void etnaviv_sched_timedout_job(struct 
drm_sched_job *sched_job)

    drm_sched_resubmit_jobs(>sched);
  +    /* Tell the DRM scheduler that this task needs
+ * more time.
+ */
+    drm_sched_start(>sched, true);
+    return DRM_TASK_STATUS_ALIVE;
+
  out_no_timeout:
 

Re: [PATCH v4 5/7] drm/tidss: Set bus_format correctly from bridge/connector

[Tomi Valkeinen]

Hi Boris,

On 04/12/2020 12:50, Boris Brezillon wrote:
> On Tue, 1 Dec 2020 17:48:28 +0530
> Nikhil Devshatwar  wrote:
> 
>> Remove the old code to iterate over the bridge chain, as this is
>> already done by the framework.
>> The bridge state should have the negotiated bus format and flags.
>> Use these from the bridge's state.
>> If the bridge does not support format negotiation, error out
>> and fail.
> 
> That'd be even better if you implement the bridge interface instead of
> the encoder one so we can get rid of the encoder_{helper}_funcs and use
> drm_simple_encoder_init().

I'm a bit confused here. What should be the design here...

These formats need to be handled by the crtc (well, the display controller, 
which is modeled as the
crtc). Should we have a tidss_crtc.c file, which implements a crtc, a simple 
encoder and a bridge?
And just consider those three DRM components as different API parts of the 
display controller?

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Allow drm_fourcc.h without including drm.h

[kernel test robot]

Hi James,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next 
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master drm/drm-next 
v5.10-rc6 next-20201204]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/James-Park/drm-Allow-drm_fourcc-h-without-including-drm-h/20201204-163753
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-c002-20201204 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/444ac999e27a36307f741eb0ef60d630b0b8946a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
James-Park/drm-Allow-drm_fourcc-h-without-including-drm-h/20201204-163753
git checkout 444ac999e27a36307f741eb0ef60d630b0b8946a
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> usr/include/drm/drm_fourcc.h:29: found __[us]{8,16,32,64} type without 
>> #include 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 5/7] drm/tidss: Set bus_format correctly from bridge/connector

[Boris Brezillon]

On Fri, 4 Dec 2020 13:47:05 +0200
Tomi Valkeinen  wrote:

> On 04/12/2020 13:12, Boris Brezillon wrote:
> 
> >>> That'd be even better if you implement the bridge interface instead of
> >>> the encoder one so we can get rid of the encoder_{helper}_funcs and use
> >>> drm_simple_encoder_init().
> >>
> >> I'm a bit confused here. What should be the design here...
> >>
> >> These formats need to be handled by the crtc (well, the display 
> >> controller, which is modeled as the
> >> crtc). Should we have a tidss_crtc.c file, which implements a crtc, a 
> >> simple encoder and a bridge?
> >> And just consider those three DRM components as different API parts of the 
> >> display controller?  
> > 
> > The idea is to hide the encoder abstraction from drivers as much as we
> > can. We have to keep the encoder concept because that's what we expose
> > to userspace, but drivers shouldn't have to worry about the distinction
> > between the first bridge in the chain (what we currently call encoders)
> > and other bridges. The bridge interface provides pretty much the same
> > functionality, so all you need to do is turn your encoder driver into a
> > bridge driver (see what we did for
> > drivers/gpu/drm/imx/parallel-display.c), the only particularity here is
> > that the bridge knows it's the first in the chain, and has access to
> > the CRTC it's directly connected to.  
> 
> With a quick look, the imx parallel-display.c seems to be really part of the 
> crtc. Shouldn't we then
> take one more step forward, and just combine the crtc, encoder and bridge 
> (somehow)? That's kind of
> what parallel-display.c is doing, isn't it? It's directly poking the crtc 
> state, but the code just
> happens to be in a separate file from the crtc.

Right. If we want to keep the code split, the logic should probably be
reversed, with the CRTC driver checking the first bridge state to setup
its internal state. Those DPI encoders are always a bit special, since
they tend to be directly embedded in the block responsible for timing
control (what we call CRTCs), so you're right, maybe we should model
that as a CRTC+bridge pair.

> 
> Thinking about the TI HW, we have a bunch of internal IPs which are clearly 
> bridges: HDMI, DSI,
> which get the pixel data from the display controller, and they have their own 
> registers, so clearly
> independent bridges.
> 
> Then we have MIPI DPI, which doesn't really have its own registers, as it's 
> just plain parallel RGB,
> the same as what is sent to e.g. HDMI and DSI bridges.

I still consider that one a bridge, even if the translation is almost
transparent from a HW PoV.

> However, there might be some muxes or
> regulators to set up to get the external signals working. So a bridge would 
> be ok here too to handle
> that external side.

Exactly.

> 
> But in all the above cases, we have the display controller (crtc), which in 
> all the cases needs to
> do e.g. pixel/bus format configuration. So why add direct crtc poking into 
> the first bridges (HDMI,
> DSI, DPI), when we could just model the crtc as a bridge, and thus the first 
> bridges wouldn't need
> to touch the crtc.

Yes, that's an option. I mean, you can already modify your CRTC
logic to implement the bridge and CRTC interface and have your
driver-specific CRTC object embed both a drm_crtc and a drm_bridge.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 209123] Bogus possible_crtcs: [ENCODER:58:TMDS-58] possible_crtcs=0xf (full crtc mask=0x7)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209123

Stuart Foster (smf-li...@virginmedia.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #2 from Stuart Foster (smf-li...@virginmedia.com) ---
That seems to fix the problem, tested it on kernels 5.8.7 and 5.9.10.

thank you Alex.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: Add setup and testing information

[Melissa Wen]

Hi Sumera,

Thanks for the doc improvements.
Please see some complimentary comments below.

On 12/03, Daniel Vetter wrote:
> On Thu, Dec 3, 2020 at 8:13 PM Sumera Priyadarsini
>  wrote:
> >
> > Update the vkms documentation to contain steps to:
> >
> >  - setup the vkms driver
> >  - run tests using igt
> >
> > Signed-off-by: Sumera Priyadarsini 
> > ---
> >  Documentation/gpu/vkms.rst | 47 ++
> >  1 file changed, 47 insertions(+)
> >
> > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> > index 13bab1d93bb3..d6782174d23f 100644
> > --- a/Documentation/gpu/vkms.rst
> > +++ b/Documentation/gpu/vkms.rst
> > @@ -7,6 +7,53 @@
> >  .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c
> > :doc: vkms (Virtual Kernel Modesetting)
> >
> > +SETUP
> 
> Absolute bikeshed, but we generally stick to titlecase for titles, so
> just "Setup" and "Testing with IGT".
> > +=
> > +
> > +The VKMS driver can be setup with the following steps:
> > +
> > +To check if VKMS is loaded, run::
> > +
> > +  lsmod | grep vkms
> > +
> > +This should list the VKMS driver. If no output is obtained, then
> > +you need to enable and/or load the VKMS driver.
> > +Ensure that the VKMS driver has been set as a loadable module in your
> > +kernel config file. The following line should be present in the .config
> > +file in your kernel root::
> > +
> > +  CONFIG_DRM_VKMS=m
> > +

Considering the target audience, I would make it clearer to explore the
configuration options using "make *config". As in
https://kernelnewbies.org/FirstKernelPatch#Recompiling_the_driver

> > +Compile and build the kernel for the changes to get reflected.
> > +If your existing config already has VKMS available as a loadable module,
> > +then there is no need to build the kernel again.
> > +Now, to load the driver, use::
> > +
> > +  sudo modprobe vkms
> > +
> > +On running the lsmod command now, the VKMS driver will appear listed.
> > +You can also observe the driver being loaded in the dmesg logs.
> > +
> > +To disable the driver, use ::
s/disable/unload/
> > +
> > +  sudo modprobe -r vkms
> > +
> > +TESTING WITH IGT
> > +
> > +
> > +The IGT GPU Tools is a test suite used specifically for debugging and
> > +development of the DRM drivers.
> > +The IGT Tools can be installed from
> > +`here `_ .
> > +Once you have installed IGT, you can run tests using::
> > +
> > +  ./scripts/run-tests.sh -t 
> > +
> > +For example, to test the functionality of the igt_draw library,
> > +we can run the kms_draw_crc test::
> > +
> > +  ./scripts/run-tests.sh -t kms_draw_crc
> 
> If we run igt tests directly, there's an option to select the right
> device. This is important if you have more than one gpu driver
> (usually the case if you run this directly, but even on virtual
> machines there should usually be a drm driver around).  E.g. when I
> run a test directly:
> 
> # tests/kms_flip --device drm:/dev/dri/card0
> 
> I'm not sure whether there's an option that's always going to select
> the vkms device. I'm also not sure you can pass these options to
> run-tests.sh, I kinda don't use that one myself ...

I also run a test directly. Some cases have many subtests, therefore I
can pass --run-subtest to specify one.

And, to select vkms, I use IGT_FORCE_DRIVER. For example:

# IGT_FORCE_DRIVER=vkms tests/kms_flip --run-subtest basic-plain-flip

> 
> Aside from that looks all good to me.
+1

Melissa
> -Daniel
> 
> > +
> >  TODO
> >  
> >
> > --
> > 2.25.1
> >
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 5/7] drm/tidss: Set bus_format correctly from bridge/connector

[Boris Brezillon]

On Fri, 4 Dec 2020 12:56:27 +0200
Tomi Valkeinen  wrote:

> Hi Boris,
> 
> On 04/12/2020 12:50, Boris Brezillon wrote:
> > On Tue, 1 Dec 2020 17:48:28 +0530
> > Nikhil Devshatwar  wrote:
> >   
> >> Remove the old code to iterate over the bridge chain, as this is
> >> already done by the framework.
> >> The bridge state should have the negotiated bus format and flags.
> >> Use these from the bridge's state.
> >> If the bridge does not support format negotiation, error out
> >> and fail.  
> > 
> > That'd be even better if you implement the bridge interface instead of
> > the encoder one so we can get rid of the encoder_{helper}_funcs and use
> > drm_simple_encoder_init().  
> 
> I'm a bit confused here. What should be the design here...
> 
> These formats need to be handled by the crtc (well, the display controller, 
> which is modeled as the
> crtc). Should we have a tidss_crtc.c file, which implements a crtc, a simple 
> encoder and a bridge?
> And just consider those three DRM components as different API parts of the 
> display controller?

The idea is to hide the encoder abstraction from drivers as much as we
can. We have to keep the encoder concept because that's what we expose
to userspace, but drivers shouldn't have to worry about the distinction
between the first bridge in the chain (what we currently call encoders)
and other bridges. The bridge interface provides pretty much the same
functionality, so all you need to do is turn your encoder driver into a
bridge driver (see what we did for
drivers/gpu/drm/imx/parallel-display.c), the only particularity here is
that the bridge knows it's the first in the chain, and has access to
the CRTC it's directly connected to.

IMHO, the less interfaces we keep the clearer it gets for our users.
Getting rid of the encoder_{helper_}funcs in favor or bridge_ops would
clarify the fact that any kind of encoder, no matter if it's the first
in the chain or not, should be represented as a bridge object.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 5/7] drm/tidss: Set bus_format correctly from bridge/connector

[Boris Brezillon]

On Tue, 1 Dec 2020 17:48:28 +0530
Nikhil Devshatwar  wrote:

> Remove the old code to iterate over the bridge chain, as this is
> already done by the framework.
> The bridge state should have the negotiated bus format and flags.
> Use these from the bridge's state.
> If the bridge does not support format negotiation, error out
> and fail.

That'd be even better if you implement the bridge interface instead of
the encoder one so we can get rid of the encoder_{helper}_funcs and use
drm_simple_encoder_init().

> 
> Signed-off-by: Nikhil Devshatwar 
> Reviewed-by: Tomi Valkeinen 
> ---
> 
> Notes:
> changes from v3:
> * cosmetic updates
> changes from v2:
> * Remove the old code and use the flags from the bridge state
> 
>  drivers/gpu/drm/tidss/tidss_encoder.c | 36 +++
>  1 file changed, 14 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c 
> b/drivers/gpu/drm/tidss/tidss_encoder.c
> index e278a9c89476..5deb8102e4d3 100644
> --- a/drivers/gpu/drm/tidss/tidss_encoder.c
> +++ b/drivers/gpu/drm/tidss/tidss_encoder.c
> @@ -21,37 +21,29 @@ static int tidss_encoder_atomic_check(struct drm_encoder 
> *encoder,
>  {
>   struct drm_device *ddev = encoder->dev;
>   struct tidss_crtc_state *tcrtc_state = to_tidss_crtc_state(crtc_state);
> - struct drm_display_info *di = _state->connector->display_info;
> + struct drm_bridge_state *bstate;
>   struct drm_bridge *bridge;
> - bool bus_flags_set = false;
>  
>   dev_dbg(ddev->dev, "%s\n", __func__);
>  
> - /*
> -  * Take the bus_flags from the first bridge that defines
> -  * bridge timings, or from the connector's display_info if no
> -  * bridge defines the timings.
> -  */
> - drm_for_each_bridge_in_chain(encoder, bridge) {
> - if (!bridge->timings)
> - continue;
> -
> - tcrtc_state->bus_flags = bridge->timings->input_bus_flags;
> - bus_flags_set = true;
> - break;
> + /* Copy the bus_format and flags from the first bridge's state */
> + bridge = drm_bridge_chain_get_first_bridge(encoder);
> + bstate = drm_atomic_get_new_bridge_state(crtc_state->state, bridge);
> + if (!bstate) {
> + dev_err(ddev->dev, "Could not get the bridge state\n");
> + return -EINVAL;
>   }
>  
> - if (!di->bus_formats || di->num_bus_formats == 0)  {
> - dev_err(ddev->dev, "%s: No bus_formats in connected display\n",
> - __func__);
> + tcrtc_state->bus_format = bstate->input_bus_cfg.format;
> + tcrtc_state->bus_flags = bstate->input_bus_cfg.flags;
> +
> + if (tcrtc_state->bus_format == 0 ||
> + tcrtc_state->bus_format == MEDIA_BUS_FMT_FIXED) {
> +
> + dev_err(ddev->dev, "Bridge connected to the encoder did not 
> specify media bus format\n");
>   return -EINVAL;
>   }
>  
> - // XXX any cleaner way to set bus format and flags?
> - tcrtc_state->bus_format = di->bus_formats[0];
> - if (!bus_flags_set)
> - tcrtc_state->bus_flags = di->bus_flags;
> -
>   return 0;
>  }
>  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 4/7] drm/bridge: mhdp8546: Set input_bus_flags from atomic_check

[Boris Brezillon]

On Tue, 1 Dec 2020 17:48:27 +0530
Nikhil Devshatwar  wrote:

> input_bus_flags are specified in drm_bridge_timings (legacy) as well
> as drm_bridge_state->input_bus_cfg.flags
> 
> The flags from the timings will be deprecated. Bridges are supposed
> to validate and set the bridge state flags from atomic_check.
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 ++
>  drivers/gpu/drm/bridge/ti-tfp410.c  | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index 2cd809eed827..9c17e4bb517e 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -2121,6 +2121,12 @@ static int cdns_mhdp_atomic_check(struct drm_bridge 
> *bridge,
>   return -EINVAL;
>   }
>  
> + /*
> +  * There might be flags negotiation supported in future
> +  * Set the bus flags in atomic_check statically for now
> +  */
> + bridge_state->input_bus_cfg.flags = bridge->timings->input_bus_flags;

I'd go even further and replace the timings field in
cdns_mhdp_platform_info by an input_bus_flags field, you'll then
have the following assignment here.

if (mhdp->info)
bridge_state->input_bus_cfg.flags = mhdp->info->input_bus_flags;

This way you no rely on the bridge->timings presence and can
get rid of the mhdp->bridge.timings assignment in the probe path.


> +
>   mutex_unlock(>link_mutex);
>   return 0;
>  }

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 3/7] drm/bridge: mhdp8546: Add minimal format negotiation

[Boris Brezillon]

On Tue, 1 Dec 2020 17:48:26 +0530
Nikhil Devshatwar  wrote:

> With new connector model, mhdp bridge will not create the connector and
> SoC driver will rely on format negotiation to setup the encoder format.
> 
> Support minimal format negotiations hooks in the drm_bridge_funcs.
> Complete format negotiation can be added based on EDID data.
> This patch adds the minimal required support to avoid failure
> after moving to new connector model.
> 
> Signed-off-by: Nikhil Devshatwar 
> Reviewed-by: Tomi Valkeinen 
> ---
> 
> Notes:
> changes from v1:
> * cosmetic fixes, commit message update
> 
>  .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 25 +++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index d0c65610ebb5..2cd809eed827 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -2078,6 +2078,30 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge 
> *bridge)
>   return _mhdp_state->base;
>  }
>  
> +static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
> +   struct drm_bridge_state *bridge_state,
> +   struct drm_crtc_state *crtc_state,
> +   struct drm_connector_state *conn_state,
> +   u32 output_fmt,
> +   unsigned int *num_input_fmts)
> +{
> + u32 *input_fmts;
> + u32 default_bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
> +
> + *num_input_fmts = 0;
> +
> + if (output_fmt != MEDIA_BUS_FMT_FIXED)
> + return NULL;
> +
> + input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
> + if (!input_fmts)
> + return NULL;
> +
> + *num_input_fmts = 1;
> + input_fmts[0] = default_bus_format;

Why not 

input_fmts[0] = MEDIA_BUS_FMT_RGB121212_1X36;

?

This way you could get rid of the default_bus_format variable.

> + return input_fmts;
> +}
> +
>  static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
> struct drm_bridge_state *bridge_state,
> struct drm_crtc_state *crtc_state,
> @@ -2142,6 +2166,7 @@ static const struct drm_bridge_funcs 
> cdns_mhdp_bridge_funcs = {
>   .atomic_duplicate_state = cdns_mhdp_bridge_atomic_duplicate_state,
>   .atomic_destroy_state = cdns_mhdp_bridge_atomic_destroy_state,
>   .atomic_reset = cdns_mhdp_bridge_atomic_reset,
> + .atomic_get_input_bus_fmts = cdns_mhdp_get_input_bus_fmts,
>   .detect = cdns_mhdp_bridge_detect,
>   .get_edid = cdns_mhdp_bridge_get_edid,
>   .hpd_enable = cdns_mhdp_bridge_hpd_enable,

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 4/7] drm/bridge: mhdp8546: Set input_bus_flags from atomic_check

[Boris Brezillon]

On Tue, 1 Dec 2020 17:48:27 +0530
Nikhil Devshatwar  wrote:

> input_bus_flags are specified in drm_bridge_timings (legacy) as well
> as drm_bridge_state->input_bus_cfg.flags
> 
> The flags from the timings will be deprecated. Bridges are supposed
> to validate and set the bridge state flags from atomic_check.
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 ++
>  drivers/gpu/drm/bridge/ti-tfp410.c  | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index 2cd809eed827..9c17e4bb517e 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -2121,6 +2121,12 @@ static int cdns_mhdp_atomic_check(struct drm_bridge 
> *bridge,
>   return -EINVAL;
>   }
>  
> + /*
> +  * There might be flags negotiation supported in future
> +  * Set the bus flags in atomic_check statically for now
> +  */
> + bridge_state->input_bus_cfg.flags = bridge->timings->input_bus_flags;
> +
>   mutex_unlock(>link_mutex);
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 4c536df003c8..9035d2145a28 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -245,6 +245,7 @@ int tfp410_atomic_check(struct drm_bridge *bridge,
>* Set the bus flags in atomic_check statically for now
>*/
>   bridge_state->input_bus_cfg.flags = dvi->timings.input_bus_flags;
> + return 0;

And here is the return statement that was missing in patch 2 :-).

>  }
>  
>  static const struct drm_bridge_funcs tfp410_bridge_funcs = {

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/bridge: tfp410: Set input_bus_flags in atomic_check

[Boris Brezillon]

On Thu, 3 Dec 2020 18:20:48 +0530
Nikhil Devshatwar  wrote:

> input_bus_flags are specified in drm_bridge_timings (legacy) as well
> as drm_bridge_state->input_bus_cfg.flags
> 
> The flags from the timings will be deprecated. Bridges are supposed
> to validate and set the bridge state flags from atomic_check.
> 
> Implement atomic_check hook for the same.
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
> 
> Notes:
> changes from v4:
> * fix a warning Reported-by: kernel test robot 
> 
>  drivers/gpu/drm/bridge/ti-tfp410.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 3def9acba86b..92963d12106b 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -233,6 +233,20 @@ static u32 *tfp410_get_input_bus_fmts(struct drm_bridge 
> *bridge,
>   return input_fmts;
>  }
>  
> +static int tfp410_atomic_check(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state)
> +{
> + struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
> +
> + /*
> +  * There might be flags negotiation supported in future
> +  * Set the bus flags in atomic_check statically for now
> +  */
> + bridge_state->input_bus_cfg.flags = dvi->timings.input_bus_flags;

The return statement is still missing :-).

> +}
> +
>  static const struct drm_bridge_funcs tfp410_bridge_funcs = {
>   .attach = tfp410_attach,
>   .detach = tfp410_detach,
> @@ -243,6 +257,7 @@ static const struct drm_bridge_funcs tfp410_bridge_funcs 
> = {
>   .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
>   .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
>   .atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts,
> + .atomic_check = tfp410_atomic_check,
>  };
>  
>  static const struct drm_bridge_timings tfp410_default_timings = {

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/7] drm/simple_kms_helper: add drmm_simple_encoder_alloc()

[Philipp Zabel]

Hi Laurent,

On Fri, 2020-12-04 at 11:19 +0200, Laurent Pinchart wrote:
> Hi Philipp,
> 
> Thank you for the patch.
> 
> On Fri, Sep 11, 2020 at 03:57:19PM +0200, Philipp Zabel wrote:
> > Add an alternative to drm_simple_encoder_init() that allocates and
> > initializes a simple encoder and registers drm_encoder_cleanup() with
> > drmm_add_action_or_reset().
> > 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  drivers/gpu/drm/drm_simple_kms_helper.c | 12 
> >  include/drm/drm_simple_kms_helper.h | 24 
> >  2 files changed, 36 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 74946690aba4..3cbbfb0f9b51 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -9,6 +9,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -71,6 +72,17 @@ int drm_simple_encoder_init(struct drm_device *dev,
> >  }
> >  EXPORT_SYMBOL(drm_simple_encoder_init);
> >  
> > +static const struct drm_encoder_funcs drmm_simple_encoder_funcs_empty = { 
> > };
> > +
> > +void *__drmm_simple_encoder_alloc(struct drm_device *dev, size_t size,
> > + size_t offset, int encoder_type)
> > +{
> > +   return __drmm_encoder_alloc(dev, size, offset,
> > +   _simple_encoder_funcs_empty,
> > +   encoder_type, NULL);
> > +}
> > +EXPORT_SYMBOL(__drmm_simple_encoder_alloc);
> 
> Do we need this ? Wouldn't it be better support a NULL drm_encoder_funcs
> in the core (if we don't already) and use drmm_encoder_alloc() directly
> in drivers ?

I could change it to remove the empty drm_encoder_funcs, and prepend
something like this:

--8<--
>From 12147d90a8ae48dabc16ca8750fa0f629cc46570 Mon Sep 17 00:00:00 2001
From: Philipp Zabel 
Date: Fri, 4 Dec 2020 10:49:41 +0100
Subject: [PATCH] drm/encoder: make encoder control functions optional

Simple managed encoders do not require the .destroy callback,
make the whole funcs structure optional.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/drm_encoder.c | 4 ++--
 drivers/gpu/drm/drm_mode_config.c | 5 +++--
 include/drm/drm_encoder.h | 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index e555281f43d4..b0b86a3c08f5 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -72,7 +72,7 @@ int drm_encoder_register_all(struct drm_device *dev)
int ret = 0;
 
drm_for_each_encoder(encoder, dev) {
-   if (encoder->funcs->late_register)
+   if (encoder->funcs && encoder->funcs->late_register)
ret = encoder->funcs->late_register(encoder);
if (ret)
return ret;
@@ -86,7 +86,7 @@ void drm_encoder_unregister_all(struct drm_device *dev)
struct drm_encoder *encoder;
 
drm_for_each_encoder(encoder, dev) {
-   if (encoder->funcs->early_unregister)
+   if (encoder->funcs && encoder->funcs->early_unregister)
encoder->funcs->early_unregister(encoder);
}
 }
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index f1affc1bb679..87e144155456 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -195,7 +195,7 @@ void drm_mode_config_reset(struct drm_device *dev)
crtc->funcs->reset(crtc);
 
drm_for_each_encoder(encoder, dev)
-   if (encoder->funcs->reset)
+   if (encoder->funcs && encoder->funcs->reset)
encoder->funcs->reset(encoder);
 
drm_connector_list_iter_begin(dev, _iter);
@@ -487,7 +487,8 @@ void drm_mode_config_cleanup(struct drm_device *dev)
 
list_for_each_entry_safe(encoder, enct, >mode_config.encoder_list,
 head) {
-   encoder->funcs->destroy(encoder);
+   if (encoder->funcs)
+   encoder->funcs->destroy(encoder);
}
 
drm_connector_list_iter_begin(dev, _iter);
diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index 5dfa5f7a80a7..833123637fbf 100644
--- a/include/drm/drm_encoder.h
+++ b/include/drm/drm_encoder.h
@@ -89,7 +89,7 @@ struct drm_encoder_funcs {
  * @head: list management
  * @base: base KMS object
  * @name: human readable name, can be overwritten by the driver
- * @funcs: control functions
+ * @funcs: control functions, can be NULL for simple managed encoders
  * @helper_private: mid-layer private data
  *
  * CRTCs drive pixels to encoders, which convert them into signals
-- 
2.20.1
-->8--

regards
Philipp
___
dri-devel mailing list

Re: [PATCH v3 1/7] drm: add drmm_encoder_alloc()

[Philipp Zabel]

Hi Laurent,

On Fri, 2020-12-04 at 11:17 +0200, Laurent Pinchart wrote:
> Hi Philipp,
> 
> Thank you for the patch.

Thank you for the review.

> On Fri, Sep 11, 2020 at 03:57:18PM +0200, Philipp Zabel wrote:
> > Add an alternative to drm_encoder_init() that allocates and initializes
> > an encoder and registers drm_encoder_cleanup() with
> > drmm_add_action_or_reset().
> > 
> > Signed-off-by: Philipp Zabel 
> > ---
> > Changes since v2:
> >  - call va_start() / va_end() unconditionally
> > ---
> >  drivers/gpu/drm/drm_encoder.c | 101 ++
> >  include/drm/drm_encoder.h |  30 ++
> >  2 files changed, 108 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > index e555281f43d4..f5414705f9ad 100644
> > --- a/drivers/gpu/drm/drm_encoder.c
> > +++ b/drivers/gpu/drm/drm_encoder.c
> > @@ -26,6 +26,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "drm_crtc_internal.h"
> >  
> > @@ -91,25 +92,11 @@ void drm_encoder_unregister_all(struct drm_device *dev)
> > }
> >  }
> >  
> > -/**
> > - * drm_encoder_init - Init a preallocated encoder
> > - * @dev: drm device
> > - * @encoder: the encoder to init
> > - * @funcs: callbacks for this encoder
> > - * @encoder_type: user visible type of the encoder
> > - * @name: printf style format string for the encoder name, or NULL for 
> > default name
> > - *
> > - * Initialises a preallocated encoder. Encoder should be subclassed as 
> > part of
> > - * driver encoder objects. At driver unload time drm_encoder_cleanup() 
> > should be
> > - * called from the driver's _encoder_funcs.destroy hook.
> > - *
> > - * Returns:
> > - * Zero on success, error code on failure.
> > - */
> > -int drm_encoder_init(struct drm_device *dev,
> > -struct drm_encoder *encoder,
> > -const struct drm_encoder_funcs *funcs,
> > -int encoder_type, const char *name, ...)
> > +__printf(5, 0)
> > +static int __drm_encoder_init(struct drm_device *dev,
> > + struct drm_encoder *encoder,
> > + const struct drm_encoder_funcs *funcs,
> > + int encoder_type, const char *name, va_list ap)
> >  {
> > int ret;
> >  
> > @@ -125,11 +112,7 @@ int drm_encoder_init(struct drm_device *dev,
> > encoder->encoder_type = encoder_type;
> > encoder->funcs = funcs;
> > if (name) {
> > -   va_list ap;
> > -
> > -   va_start(ap, name);
> > encoder->name = kvasprintf(GFP_KERNEL, name, ap);
> > -   va_end(ap);
> > } else {
> > encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
> >   
> > drm_encoder_enum_list[encoder_type].name,
> > @@ -150,6 +133,36 @@ int drm_encoder_init(struct drm_device *dev,
> >  
> > return ret;
> >  }
> > +
> > +/**
> > + * drm_encoder_init - Init a preallocated encoder
> > + * @dev: drm device
> > + * @encoder: the encoder to init
> > + * @funcs: callbacks for this encoder
> > + * @encoder_type: user visible type of the encoder
> > + * @name: printf style format string for the encoder name, or NULL for 
> > default name
> > + *
> > + * Initializes a preallocated encoder. Encoder should be subclassed as 
> > part of
> > + * driver encoder objects. At driver unload time drm_encoder_cleanup() 
> > should be
> > + * called from the driver's _encoder_funcs.destroy hook.
> > + *
> > + * Returns:
> > + * Zero on success, error code on failure.
> > + */
> > +int drm_encoder_init(struct drm_device *dev,
> > +struct drm_encoder *encoder,
> > +const struct drm_encoder_funcs *funcs,
> > +int encoder_type, const char *name, ...)
> > +{
> > +   va_list ap;
> > +   int ret;
> > +
> > +   va_start(ap, name);
> > +   ret = __drm_encoder_init(dev, encoder, funcs, encoder_type, name, ap);
> > +   va_end(ap);
> > +
> > +   return ret;
> > +}
> >  EXPORT_SYMBOL(drm_encoder_init);
> >  
> >  /**
> > @@ -181,6 +194,48 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> >  }
> >  EXPORT_SYMBOL(drm_encoder_cleanup);
> >  
> > +static void drmm_encoder_alloc_release(struct drm_device *dev, void *ptr)
> > +{
> > +   struct drm_encoder *encoder = ptr;
> > +
> > +   if (WARN_ON(!encoder->dev))
> > +   return;
> > +
> > +   drm_encoder_cleanup(encoder);
> > +}
> > +
> > +void *__drmm_encoder_alloc(struct drm_device *dev, size_t size, size_t 
> > offset,
> > +  const struct drm_encoder_funcs *funcs,
> > +  int encoder_type, const char *name, ...)
> > +{
> > +   void *container;
> > +   struct drm_encoder *encoder;
> > +   va_list ap;
> > +   int ret;
> > +
> > +   if (WARN_ON(!funcs || funcs->destroy))
> > +   return ERR_PTR(-EINVAL);
> > +
> > +   container = drmm_kzalloc(dev, size, GFP_KERNEL);
> > +   if (!container)
> > +   return ERR_PTR(-EINVAL);

Re: [PATCH] drm: Remove drmm_add_final_kfree() declaration from public headers

[Thomas Zimmermann]

Am 04.12.20 um 10:29 schrieb Laurent Pinchart:

The drmm_add_final_kfree() function is declared in the
include/drm/drm_managed.h public header, but has become an internal API
not exposed to drivers. Drop it from drm_managed.h as it's already
declared in drm_internal.h.

Signed-off-by: Laurent Pinchart 


Acked-by: Thomas Zimmermann 


---
  include/drm/drm_managed.h | 2 --
  1 file changed, 2 deletions(-)

diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
index ca4114633bf9..b45c6fbf53ac 100644
--- a/include/drm/drm_managed.h
+++ b/include/drm/drm_managed.h
@@ -44,8 +44,6 @@ int __must_check __drmm_add_action_or_reset(struct drm_device 
*dev,
drmres_release_t action,
void *data, const char *name);
  
-void drmm_add_final_kfree(struct drm_device *dev, void *container);

-
  void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp) __malloc;
  
  /**




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



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Remove drmm_add_final_kfree() declaration from public headers

[Laurent Pinchart]

The drmm_add_final_kfree() function is declared in the
include/drm/drm_managed.h public header, but has become an internal API
not exposed to drivers. Drop it from drm_managed.h as it's already
declared in drm_internal.h.

Signed-off-by: Laurent Pinchart 
---
 include/drm/drm_managed.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
index ca4114633bf9..b45c6fbf53ac 100644
--- a/include/drm/drm_managed.h
+++ b/include/drm/drm_managed.h
@@ -44,8 +44,6 @@ int __must_check __drmm_add_action_or_reset(struct drm_device 
*dev,
drmres_release_t action,
void *data, const char *name);
 
-void drmm_add_final_kfree(struct drm_device *dev, void *container);
-
 void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp) __malloc;
 
 /**
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/7] drm/crtc: add drmm_crtc_alloc_with_planes()

[Laurent Pinchart]

Hi Philipp,

Thank you for the patch.

On Fri, Sep 11, 2020 at 03:57:21PM +0200, Philipp Zabel wrote:
> Add an alternative to drm_crtc_init_with_planes() that allocates
> and initializes a crtc and registers drm_crtc_cleanup() with
> drmm_add_action_or_reset().
> 
> Signed-off-by: Philipp Zabel 
> ---
> Changes since v2:
>  - call va_start() / va_end() unconditionally
> ---
>  drivers/gpu/drm/drm_crtc.c | 116 -
>  include/drm/drm_crtc.h |  33 +++
>  2 files changed, 121 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index aecdd7ea26dc..b9e7c11a76b7 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -231,30 +232,12 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc 
> *crtc)
>   *   Setting MODE_ID to 0 will release reserved resources for the CRTC.
>   */
>  
> -/**
> - * drm_crtc_init_with_planes - Initialise a new CRTC object with
> - *specified primary and cursor planes.
> - * @dev: DRM device
> - * @crtc: CRTC object to init
> - * @primary: Primary plane for CRTC
> - * @cursor: Cursor plane for CRTC
> - * @funcs: callbacks for the new CRTC
> - * @name: printf style format string for the CRTC name, or NULL for default 
> name
> - *
> - * Inits a new object created as base part of a driver crtc object. Drivers
> - * should use this function instead of drm_crtc_init(), which is only 
> provided
> - * for backwards compatibility with drivers which do not yet support 
> universal
> - * planes). For really simple hardware which has only 1 plane look at
> - * drm_simple_display_pipe_init() instead.
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
> -   struct drm_plane *primary,
> -   struct drm_plane *cursor,
> -   const struct drm_crtc_funcs *funcs,
> -   const char *name, ...)
> +__printf(6, 0)
> +static int __drm_crtc_init_with_planes(struct drm_device *dev, struct 
> drm_crtc *crtc,
> +struct drm_plane *primary,
> +struct drm_plane *cursor,
> +const struct drm_crtc_funcs *funcs,
> +const char *name, va_list ap)
>  {
>   struct drm_mode_config *config = >mode_config;
>   int ret;
> @@ -282,11 +265,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   return ret;
>  
>   if (name) {
> - va_list ap;
> -
> - va_start(ap, name);
>   crtc->name = kvasprintf(GFP_KERNEL, name, ap);
> - va_end(ap);
>   } else {
>   crtc->name = kasprintf(GFP_KERNEL, "crtc-%d",
>  drm_num_crtcs(dev));
> @@ -330,8 +309,89 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>  
>   return 0;
>  }
> +
> +/**
> + * drm_crtc_init_with_planes - Initialise a new CRTC object with
> + *specified primary and cursor planes.
> + * @dev: DRM device
> + * @crtc: CRTC object to init
> + * @primary: Primary plane for CRTC
> + * @cursor: Cursor plane for CRTC
> + * @funcs: callbacks for the new CRTC
> + * @name: printf style format string for the CRTC name, or NULL for default 
> name
> + *
> + * Inits a new object created as base part of a driver crtc object. Drivers
> + * should use this function instead of drm_crtc_init(), which is only 
> provided
> + * for backwards compatibility with drivers which do not yet support 
> universal
> + * planes). For really simple hardware which has only 1 plane look at
> + * drm_simple_display_pipe_init() instead.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
> +   struct drm_plane *primary,
> +   struct drm_plane *cursor,
> +   const struct drm_crtc_funcs *funcs,
> +   const char *name, ...)
> +{
> + va_list ap;
> + int ret;
> +
> + va_start(ap, name);
> + ret = __drm_crtc_init_with_planes(dev, crtc, primary, cursor, funcs,
> +   name, ap);
> + va_end(ap);
> +
> + return ret;
> +}
>  EXPORT_SYMBOL(drm_crtc_init_with_planes);
>  
> +static void drmm_crtc_alloc_with_planes_cleanup(struct drm_device *dev,
> + void *ptr)
> +{
> + struct drm_crtc *crtc = ptr;
> +
> + drm_crtc_cleanup(crtc);
> +}
> +
> +void *__drmm_crtc_alloc_with_planes(struct drm_device *dev,
> + size_t size, 

Re: [PATCH v3 3/7] drm/plane: add drmm_universal_plane_alloc()

[Laurent Pinchart]

Hi Philipp,

Thank you for the patch.

On Fri, Sep 11, 2020 at 03:57:20PM +0200, Philipp Zabel wrote:
> Add an alternative to drm_universal_plane_init() that allocates
> and initializes a plane and registers drm_plane_cleanup() with
> drmm_add_action_or_reset().
> 
> Signed-off-by: Philipp Zabel 
> ---
> Changes since v2:
>  - call va_start() / va_end() unconditionally
> ---
>  drivers/gpu/drm/drm_plane.c | 126 +++-
>  include/drm/drm_plane.h |  42 
>  2 files changed, 139 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index affe1cfed009..0081f6bb76b2 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "drm_crtc_internal.h"
> @@ -152,31 +153,16 @@ static int create_in_format_blob(struct drm_device 
> *dev, struct drm_plane *plane
>   return 0;
>  }
>  
> -/**
> - * drm_universal_plane_init - Initialize a new universal plane object
> - * @dev: DRM device
> - * @plane: plane object to init
> - * @possible_crtcs: bitmask of possible CRTCs
> - * @funcs: callbacks for the new plane
> - * @formats: array of supported formats (DRM_FORMAT\_\*)
> - * @format_count: number of elements in @formats
> - * @format_modifiers: array of struct drm_format modifiers terminated by
> - *DRM_FORMAT_MOD_INVALID
> - * @type: type of plane (overlay, primary, cursor)
> - * @name: printf style format string for the plane name, or NULL for default 
> name
> - *
> - * Initializes a plane object of type @type.
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
> -  uint32_t possible_crtcs,
> -  const struct drm_plane_funcs *funcs,
> -  const uint32_t *formats, unsigned int format_count,
> -  const uint64_t *format_modifiers,
> -  enum drm_plane_type type,
> -  const char *name, ...)
> +__printf(9, 0)
> +static int __drm_universal_plane_init(struct drm_device *dev,
> +   struct drm_plane *plane,
> +   uint32_t possible_crtcs,
> +   const struct drm_plane_funcs *funcs,
> +   const uint32_t *formats,
> +   unsigned int format_count,
> +   const uint64_t *format_modifiers,
> +   enum drm_plane_type type,
> +   const char *name, va_list ap)
>  {
>   struct drm_mode_config *config = >mode_config;
>   unsigned int format_modifier_count = 0;
> @@ -237,11 +223,7 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>   }
>  
>   if (name) {
> - va_list ap;
> -
> - va_start(ap, name);
>   plane->name = kvasprintf(GFP_KERNEL, name, ap);
> - va_end(ap);
>   } else {
>   plane->name = kasprintf(GFP_KERNEL, "plane-%d",
>   drm_num_planes(dev));
> @@ -286,8 +268,94 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>  
>   return 0;
>  }
> +
> +/**
> + * drm_universal_plane_init - Initialize a new universal plane object
> + * @dev: DRM device
> + * @plane: plane object to init
> + * @possible_crtcs: bitmask of possible CRTCs
> + * @funcs: callbacks for the new plane
> + * @formats: array of supported formats (DRM_FORMAT\_\*)
> + * @format_count: number of elements in @formats
> + * @format_modifiers: array of struct drm_format modifiers terminated by
> + *DRM_FORMAT_MOD_INVALID
> + * @type: type of plane (overlay, primary, cursor)
> + * @name: printf style format string for the plane name, or NULL for default 
> name
> + *
> + * Initializes a plane object of type @type.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
> +  uint32_t possible_crtcs,
> +  const struct drm_plane_funcs *funcs,
> +  const uint32_t *formats, unsigned int format_count,
> +  const uint64_t *format_modifiers,
> +  enum drm_plane_type type,
> +  const char *name, ...)
> +{
> + va_list ap;
> + int ret;
> +
> + va_start(ap, name);
> + ret = __drm_universal_plane_init(dev, plane, possible_crtcs, funcs,
> +  formats, format_count, 
> format_modifiers,
> +  type, name, ap);
> + va_end(ap);
> +

Re: [PATCH v3 2/7] drm/simple_kms_helper: add drmm_simple_encoder_alloc()

[Laurent Pinchart]

Hi Philipp,

Thank you for the patch.

On Fri, Sep 11, 2020 at 03:57:19PM +0200, Philipp Zabel wrote:
> Add an alternative to drm_simple_encoder_init() that allocates and
> initializes a simple encoder and registers drm_encoder_cleanup() with
> drmm_add_action_or_reset().
> 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/drm_simple_kms_helper.c | 12 
>  include/drm/drm_simple_kms_helper.h | 24 
>  2 files changed, 36 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 74946690aba4..3cbbfb0f9b51 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -71,6 +72,17 @@ int drm_simple_encoder_init(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drm_simple_encoder_init);
>  
> +static const struct drm_encoder_funcs drmm_simple_encoder_funcs_empty = { };
> +
> +void *__drmm_simple_encoder_alloc(struct drm_device *dev, size_t size,
> +   size_t offset, int encoder_type)
> +{
> + return __drmm_encoder_alloc(dev, size, offset,
> + _simple_encoder_funcs_empty,
> + encoder_type, NULL);
> +}
> +EXPORT_SYMBOL(__drmm_simple_encoder_alloc);

Do we need this ? Wouldn't it be better support a NULL drm_encoder_funcs
in the core (if we don't already) and use drmm_encoder_alloc() directly
in drivers ?

> +
>  static enum drm_mode_status
>  drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
>  const struct drm_display_mode *mode)
> diff --git a/include/drm/drm_simple_kms_helper.h 
> b/include/drm/drm_simple_kms_helper.h
> index a026375464ff..e6dbf3161c2f 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -185,4 +185,28 @@ int drm_simple_encoder_init(struct drm_device *dev,
>   struct drm_encoder *encoder,
>   int encoder_type);
>  
> +void *__drmm_simple_encoder_alloc(struct drm_device *dev, size_t size,
> +   size_t offset, int encoder_type);
> +
> +/**
> + * drmm_simple_encoder_alloc - Allocate and initialize an encoder with basic
> + * functionality.
> + * @dev: drm device
> + * @type: the type of the struct which contains struct _encoder
> + * @member: the name of the _encoder within @type.
> + * @encoder_type: user visible type of the encoder
> + *
> + * Allocates and initializes an encoder that has no further functionality.
> + * Settings for possible CRTC and clones are left to their initial values.
> + * Cleanup is automatically handled through registering drm_encoder_cleanup()
> + * with drmm_add_action().
> + *
> + * Returns:
> + * Pointer to new encoder, or ERR_PTR on failure.
> + */
> +#define drmm_simple_encoder_alloc(dev, type, member, encoder_type) \
> + ((type *)__drmm_simple_encoder_alloc(dev, sizeof(type), \
> +  offsetof(type, member), \
> +  encoder_type))
> +
>  #endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/6] drm/panel: mantix and st7703 fixes and additions

[Guido Günther]

Hi Linus,
On Thu, Nov 19, 2020 at 09:35:17AM +0100, Linus Walleij wrote:
> On Wed, Nov 18, 2020 at 9:29 AM Guido Günther  wrote:
> 
> > This adds new panel type to the mantix driver as found on the Librem 5 and
> > fixes a glitch in the init sequence (affecting both panels). The fix is at 
> > the
> > start of the series to make backporting simpler.
> > It also adds a patch to make st7703 use dev_err_probe().
> >
> > changes from v1
> > - as per review comments by Linus Walleij
> >   - fix alphabetical ordering in 
> > Documentation/devicetree/bindings/vendor-prefixes.yaml
> > 
> > https://lore.kernel.org/dri-devel/CACRpkdao_TMcpRsdK=7k5fnkjse0bqwk58iwu0xsxddndcf...@mail.gmail.com/
> >   - add reviewed by to all except 5/6, thanks
> 
> The whole v2 looks fine to me, I'd give the devicetree
> maintainers some slack to review the DT patches then I can
> apply the whole series unless you have commit access yourself,
> just tell me.

Thanks. Is 2 weeks enough slack? Checking what's the rule of thumb here.
Cheers,
 -- Guido

> 
> For all v2 patches:
> Reviewed-by: Linus Walleij 
> 
> If you have time, please review my s6e63m0 series.
> https://lore.kernel.org/dri-devel/20201117175621.870085-1-linus.wall...@linaro.org/
> https://lore.kernel.org/dri-devel/20201117175621.870085-2-linus.wall...@linaro.org/
> https://lore.kernel.org/dri-devel/20201117175621.870085-3-linus.wall...@linaro.org/
> 
> Yours,
> Linus Walleij
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/7] drm: add drmm_encoder_alloc()

[Laurent Pinchart]

Hi Philipp,

Thank you for the patch.

On Fri, Sep 11, 2020 at 03:57:18PM +0200, Philipp Zabel wrote:
> Add an alternative to drm_encoder_init() that allocates and initializes
> an encoder and registers drm_encoder_cleanup() with
> drmm_add_action_or_reset().
> 
> Signed-off-by: Philipp Zabel 
> ---
> Changes since v2:
>  - call va_start() / va_end() unconditionally
> ---
>  drivers/gpu/drm/drm_encoder.c | 101 ++
>  include/drm/drm_encoder.h |  30 ++
>  2 files changed, 108 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index e555281f43d4..f5414705f9ad 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  
> @@ -91,25 +92,11 @@ void drm_encoder_unregister_all(struct drm_device *dev)
>   }
>  }
>  
> -/**
> - * drm_encoder_init - Init a preallocated encoder
> - * @dev: drm device
> - * @encoder: the encoder to init
> - * @funcs: callbacks for this encoder
> - * @encoder_type: user visible type of the encoder
> - * @name: printf style format string for the encoder name, or NULL for 
> default name
> - *
> - * Initialises a preallocated encoder. Encoder should be subclassed as part 
> of
> - * driver encoder objects. At driver unload time drm_encoder_cleanup() 
> should be
> - * called from the driver's _encoder_funcs.destroy hook.
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_encoder_init(struct drm_device *dev,
> -  struct drm_encoder *encoder,
> -  const struct drm_encoder_funcs *funcs,
> -  int encoder_type, const char *name, ...)
> +__printf(5, 0)
> +static int __drm_encoder_init(struct drm_device *dev,
> +   struct drm_encoder *encoder,
> +   const struct drm_encoder_funcs *funcs,
> +   int encoder_type, const char *name, va_list ap)
>  {
>   int ret;
>  
> @@ -125,11 +112,7 @@ int drm_encoder_init(struct drm_device *dev,
>   encoder->encoder_type = encoder_type;
>   encoder->funcs = funcs;
>   if (name) {
> - va_list ap;
> -
> - va_start(ap, name);
>   encoder->name = kvasprintf(GFP_KERNEL, name, ap);
> - va_end(ap);
>   } else {
>   encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
> 
> drm_encoder_enum_list[encoder_type].name,
> @@ -150,6 +133,36 @@ int drm_encoder_init(struct drm_device *dev,
>  
>   return ret;
>  }
> +
> +/**
> + * drm_encoder_init - Init a preallocated encoder
> + * @dev: drm device
> + * @encoder: the encoder to init
> + * @funcs: callbacks for this encoder
> + * @encoder_type: user visible type of the encoder
> + * @name: printf style format string for the encoder name, or NULL for 
> default name
> + *
> + * Initializes a preallocated encoder. Encoder should be subclassed as part 
> of
> + * driver encoder objects. At driver unload time drm_encoder_cleanup() 
> should be
> + * called from the driver's _encoder_funcs.destroy hook.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_encoder_init(struct drm_device *dev,
> +  struct drm_encoder *encoder,
> +  const struct drm_encoder_funcs *funcs,
> +  int encoder_type, const char *name, ...)
> +{
> + va_list ap;
> + int ret;
> +
> + va_start(ap, name);
> + ret = __drm_encoder_init(dev, encoder, funcs, encoder_type, name, ap);
> + va_end(ap);
> +
> + return ret;
> +}
>  EXPORT_SYMBOL(drm_encoder_init);
>  
>  /**
> @@ -181,6 +194,48 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
>  }
>  EXPORT_SYMBOL(drm_encoder_cleanup);
>  
> +static void drmm_encoder_alloc_release(struct drm_device *dev, void *ptr)
> +{
> + struct drm_encoder *encoder = ptr;
> +
> + if (WARN_ON(!encoder->dev))
> + return;
> +
> + drm_encoder_cleanup(encoder);
> +}
> +
> +void *__drmm_encoder_alloc(struct drm_device *dev, size_t size, size_t 
> offset,
> +const struct drm_encoder_funcs *funcs,
> +int encoder_type, const char *name, ...)
> +{
> + void *container;
> + struct drm_encoder *encoder;
> + va_list ap;
> + int ret;
> +
> + if (WARN_ON(!funcs || funcs->destroy))
> + return ERR_PTR(-EINVAL);
> +
> + container = drmm_kzalloc(dev, size, GFP_KERNEL);
> + if (!container)
> + return ERR_PTR(-EINVAL);
> +
> + encoder = container + offset;
> +
> + va_start(ap, name);
> + ret = __drm_encoder_init(dev, encoder, funcs, encoder_type, name, ap);
> + va_end(ap);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + ret = drmm_add_action_or_reset(dev, drmm_encoder_alloc_release, 
> 

Re: [PATCH v6 04/18] drm/i915/hdcp: No HDCP when encoder is't initialized

[Anshuman Gupta]

On 2020-12-04 at 14:32:16 +0530, Ramalingam C wrote:
> On 2020-11-26 at 13:07:08 +0530, Anshuman Gupta wrote:
> > There can be situation when DP MST connector is created without
> > mst modeset being done, in those cases connector->encoder will be
> > NULL. MST connector->encoder initializes after modeset.
> 
> This patch is to reject the HDCP request on MST connector without
> encoder initialized(modeset). But userspace are not supposed to request hdcp 
> at such
> scenario right?.
AFAIU user space doesn't know about DP MST topology until unless it parse
PATH property. This crash oberved on chrome OS with DP MST dock.
>From driver POV it should avoid kernel crash in such cases.

Thanks,
Anshuman Gupta. 
> 
> Ram
> 
> > Don't enable HDCP in such cases to prevent any crash.
> > 
> > Cc: Ramalingam C 
> > Cc: Juston Li 
> > Signed-off-by: Anshuman Gupta 
> > ---
> >  drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index b9d8825e2bb1..7d63e9495956 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -2106,6 +2106,12 @@ int intel_hdcp_enable(struct intel_connector 
> > *connector,
> > if (!hdcp->shim)
> > return -ENOENT;
> >  
> > +   if (!connector->encoder) {
> > +   drm_err(_priv->drm, "[%s:%d] encoder is not initialized\n",
> > +   connector->base.name, connector->base.base.id);
> > +   return -ENODEV;
> > +   }
> > +
> > mutex_lock(>mutex);
> > mutex_lock(_port->hdcp_mutex);
> > drm_WARN_ON(_priv->drm,
> > -- 
> > 2.26.2
> > 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 04/18] drm/i915/hdcp: No HDCP when encoder is't initialized

[Ramalingam C]

On 2020-11-26 at 13:07:08 +0530, Anshuman Gupta wrote:
> There can be situation when DP MST connector is created without
> mst modeset being done, in those cases connector->encoder will be
> NULL. MST connector->encoder initializes after modeset.

This patch is to reject the HDCP request on MST connector without
encoder initialized(modeset). But userspace are not supposed to request hdcp at 
such
scenario right?.

Ram

> Don't enable HDCP in such cases to prevent any crash.
> 
> Cc: Ramalingam C 
> Cc: Juston Li 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index b9d8825e2bb1..7d63e9495956 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -2106,6 +2106,12 @@ int intel_hdcp_enable(struct intel_connector 
> *connector,
>   if (!hdcp->shim)
>   return -ENOENT;
>  
> + if (!connector->encoder) {
> + drm_err(_priv->drm, "[%s:%d] encoder is not initialized\n",
> + connector->base.name, connector->base.base.id);
> + return -ENODEV;
> + }
> +
>   mutex_lock(>mutex);
>   mutex_lock(_port->hdcp_mutex);
>   drm_WARN_ON(_priv->drm,
> -- 
> 2.26.2
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Allow drm_fourcc.h without including drm.h

[Simon Ser]

On Friday, December 4, 2020 5:53 AM, James Park  
wrote:

> +#ifdef DRM_FOURCC_STANDALONE
> +#include 
>
> +typedef uint32_t __u32;
> +typedef uint64_t __u64;
> +#else
> #include "drm.h"
> +#endif

C11 allows duplicate typedefs, but older versions of the standard
don't AFAIK. If this is a concern, a solution would be to guard the
typedefs.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 7/7] dma-buf: Write down some rules for vmap usage

[Christian König]

Am 04.12.20 um 09:32 schrieb Thomas Zimmermann:

Hi

Am 03.12.20 um 21:41 schrieb Daniel Vetter:

On Thu, Dec 03, 2020 at 07:59:04PM +0100, Thomas Zimmermann wrote:

Hi

Am 03.12.20 um 16:26 schrieb Daniel Vetter:

On Thu, Dec 03, 2020 at 03:02:59PM +0100, Thomas Zimmermann wrote:

Dma-buf's vmap and vunmap callbacks are undocumented and various
exporters currently have slightly different semantics for them. Add
documentation on how to implement and use these interfaces correctly.

v2:
* document vmap semantics in struct dma_buf_ops
* add TODO item for reviewing and maybe fixing dma-buf exporters

Signed-off-by: Thomas Zimmermann 


I still don't think this works, we're breaking dma_buf_vmap for 
everyone

else here.


I removed the text on the importer. These notes for callers in the 
docs are

more or less a consequence of the exporter semantics.


Callers are importers, so I'm not seeing how that fixes anything.

I thought we at least agreed on the exporter semantics in the other 
thread,

didn't we?

What I'm trying to do is to write dome some rules for exporters, 
even if not

all exporters follow them.


This is a standard interface, everyone needs to follow the same 
rules. And
if they change, we need to make sure nothing breaks and we're not 
creating

issues.

In the past the rule was the dma_buf_vmap was allowed to take the
dma_resv_lock, and that the buffer should be pinned. Now some ttm 
drivers
didn't ever bother with the pinning, and mostly got away with that 
because
drm_prime helpers do the pinning by default at attach time, and most 
users

do call dma_buf_attach.

But if you look through dma-buf docs nothing ever said you have to do a
dummy attachment before you call dma_buf_vmap, that's just slightly 
crappy

implementations that didn't blow up yet.


I had a patch for adding pin to radeon's implementation of vmap. [1] 
Christian told me to not do this; instead just get the lock in the 
fbdev code. His advise almost seems the opposite of what you're 
telling me here.


I think what Daniel suggests here is that we need to smoothly transition 
the code from making assumptions to having a straight interface where 
importers explicitly say when stuff is locked and when stuff is pinned.


I've started this with the attach interface by adding a new dynamic 
approach to that, but you probably need to carry on here with that for 
vmap as well.


When that is done we can migrate every exporter over to the new dynamic 
approach.




For the GEM VRAM helpers, that implicit pin in vmap gave me headaches. 
Because scanouts can only be done from VRAM, which is badly suited for 
exporting. So I ended up with an implicit pin that pins the buffer to 
whatever domain it currently is. I got away with it because GEM VRAM 
BOs are not sharable among devices; fbdev is the only user of that 
functionality and only pins for short periods of time.


I suspect that fixing TTM-based drivers by adding an implicit pin 
would result in a similar situation. Whatever domain it ends up 
pinning, some functionality might not be compatible with that.


Correct, exactly that's the problem.





Given the circumstances, we should leave out this patch from the 
patchset.


So the defacto rules are already a big mess, but that's not a good 
excuse

to make it worse.

What I had in mind is that we split dma_buf_vmap up into two variants:

- The current one, which should guarantee that the buffer is pinned.
   Because that's what all current callers wanted, before the fbdev code
   started allowing non-pinned buffers.


Can we add an explicit pin operation to dma_buf_vmap() to enforce the 
semantics?


At least I would be fine with that. For now amdgpu is the only exporter 
who implements the explicit pin/unpin semantics anyway.


Regards,
Christian.



Best regards
Thomas

[1] https://patchwork.freedesktop.org/patch/400054/?series=83765=1



- The new one, which allows vmapping with just dma_resv locked, and 
should

   have some caching in exporters.

Breaking code and then adding todos about that is kinda not so cool
approach here imo.

Also I guess ttm_bo_vmap should have a check that either the buffer is
pinned, or dma_resv_lock is held.

Cheers, Daniel





Best regards
Thomas




---
   Documentation/gpu/todo.rst | 15 +
   include/drm/drm_gem.h  |  4 
   include/linux/dma-buf.h    | 45 
++

   3 files changed, 64 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 009d8e6c7e3c..32bb797a84fc 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -505,6 +505,21 @@ Contact: Thomas Zimmermann 
, Christian König, Daniel Vette

   Level: Intermediate
+Enforce rules for dma-buf vmap and pin ops
+--
+
+Exporter implementations of vmap and pin in struct dma_buf_ops 
(and consequently
+struct drm_gem_object_funcs) use a variety of locking semantics. 
Some rely on
+the 

Re: [PATCH V3 1/2] dt-bindings: Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge

[Marek Vasut]

On 12/3/20 7:01 PM, Dave Stevenson wrote:

Hi Marek


Hi,

[...]


+additionalProperties: false
+
+examples:
+  - |
+i2c1 {


Minor point.
I've just come to use this and noticed that this example puts the
device under i2c1. Seeing as it's a DSI driver with no I2C
interaction, shouldn't it be under a dsi node?


Good catch, it should, please send a patch to correct this error, thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support

[Liu Ying]

Hi,

This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the
Freescale i.MX8qxp SoC.

The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either
MIPI DPHY mode or LVDS PHY mode.  The PHY mode is controlled by i.MX8qxp
SCU firmware.  The PHY driver would call a SCU function to configure the
mode.

The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC,
where it appears to be a single MIPI DPHY.


Patch 1/4 sets PHY mode in the Northwest Logic MIPI DSI host controller
bridge driver, since i.MX8qxp SoC embeds this controller IP to support
MIPI DSI displays together with the Mixel PHY.

Patch 2/4 allows LVDS PHYs to be configured through the generic PHY functions
and through a custom structure added to the generic PHY configuration union.

Patch 3/4 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC.

Patch 4/4 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver.


Welcome comments, thanks.


Liu Ying (4):
  drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable()
  phy: Add LVDS configuration options
  dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for
i.MX8qxp
  phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode
support

 .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt |   8 +-
 drivers/gpu/drm/bridge/nwl-dsi.c   |   6 +
 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266 -
 include/linux/phy/phy-lvds.h   |  48 
 include/linux/phy/phy.h|   4 +
 5 files changed, 320 insertions(+), 12 deletions(-)
 create mode 100644 include/linux/phy/phy-lvds.h

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/dp: remove duplicate include statement

[Tian Tao]

linux/rational.h is included more than once, Remove the one that isn't
necessary.

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/msm/dp/dp_catalog.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c 
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index b15b4ce..105fa65 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -5,7 +5,6 @@
 
 #define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
 
-#include 
 #include 
 #include 
 #include 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] phy: Add LVDS configuration options

[Liu Ying]

This patch allows LVDS PHYs to be configured through
the generic functions and through a custom structure
added to the generic union.

The parameters added here are based on common LVDS PHY
implementation practices.  The set of parameters
should cover all potential users.

Cc: Kishon Vijay Abraham I 
Cc: Vinod Koul 
Cc: NXP Linux Team 
Signed-off-by: Liu Ying 
---
 include/linux/phy/phy-lvds.h | 48 
 include/linux/phy/phy.h  |  4 
 2 files changed, 52 insertions(+)
 create mode 100644 include/linux/phy/phy-lvds.h

diff --git a/include/linux/phy/phy-lvds.h b/include/linux/phy/phy-lvds.h
new file mode 100644
index ..1b5b9d6
--- /dev/null
+++ b/include/linux/phy/phy-lvds.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2020 NXP
+ */
+
+#ifndef __PHY_LVDS_H_
+#define __PHY_LVDS_H_
+
+/**
+ * struct phy_configure_opts_lvds - LVDS configuration set
+ *
+ * This structure is used to represent the configuration state of a
+ * LVDS phy.
+ */
+struct phy_configure_opts_lvds {
+   /**
+* @bits_per_lane_and_dclk_cycle:
+*
+* Number of bits per data lane and differential clock cycle.
+*/
+   unsigned int bits_per_lane_and_dclk_cycle;
+
+   /**
+* @differential_clk_rate:
+*
+* Clock rate, in Hertz, of the LVDS differential clock.
+*/
+   unsigned long differential_clk_rate;
+
+   /**
+* @lanes:
+*
+* Number of active, consecutive, data lanes, starting from
+* lane 0, used for the transmissions.
+*/
+   unsigned int lanes;
+
+   /**
+* @is_slave:
+*
+* Boolean, true if the phy is a slave which works together
+* with a master phy to support dual link transmission,
+* otherwise a regular phy or a master phy.
+*/
+   bool is_slave;
+};
+
+#endif /* __PHY_LVDS_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e435bdb..d450b44 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 struct phy;
@@ -51,10 +52,13 @@ enum phy_mode {
  * the MIPI_DPHY phy mode.
  * @dp:Configuration set applicable for phys supporting
  * the DisplayPort protocol.
+ * @lvds:  Configuration set applicable for phys supporting
+ * the LVDS phy mode.
  */
 union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
struct phy_configure_opts_dpdp;
+   struct phy_configure_opts_lvds  lvds;
 };
 
 /**
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: ipu-v3: replace spin_lock_irqsave by spin_lock in hard IRQ

[Tian Tao]

The code has been in a irq-disabled context since it is hard IRQ. There
is no necessity to do it again.

Signed-off-by: Tian Tao 
---
 drivers/gpu/ipu-v3/ipu-image-convert.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c 
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index aa1d4b6..c28764c 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -1737,9 +1737,8 @@ static irqreturn_t eof_irq(int irq, void *data)
struct ipu_image_convert_run *run;
irqreturn_t ret = IRQ_HANDLED;
bool tile_complete = false;
-   unsigned long flags;
 
-   spin_lock_irqsave(>irqlock, flags);
+   spin_lock(>irqlock);
 
/* get current run and its context */
run = chan->current_run;
@@ -1778,7 +1777,7 @@ static irqreturn_t eof_irq(int irq, void *data)
if (tile_complete)
ret = do_tile_complete(run);
 out:
-   spin_unlock_irqrestore(>irqlock, flags);
+   spin_unlock(>irqlock);
return ret;
 }
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/3] drm/tiny: Add driver for ili9341 with parallel bus

[mdurnev]

From: Mikhail Durnev 

MRB2801 display module [1] is an example of ILI9341 display that connects to
Intel 8080 parallel bus. Its connector is compatible with the ALIENTEK STM32
development board.

It can be used with the drm/mipi-dbi bus driver if the bus is emulated with
GPIO.

[1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801

Signed-off-by: Mikhail Durnev 
---
 drivers/gpu/drm/tiny/Kconfig|  13 ++
 drivers/gpu/drm/tiny/Makefile   |   1 +
 drivers/gpu/drm/tiny/ili9341_gpio.c | 284 
 3 files changed, 298 insertions(+)
 create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c

diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f..e48e268 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -66,6 +66,19 @@ config TINYDRM_ILI9341
 
  If M is selected the module will be called ili9341.
 
+config TINYDRM_ILI9341_GPIO
+   tristate "DRM support for ILI9341 display panels with parallel bus 
interface over GPIO"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_MIPI_DBI
+   select BACKLIGHT_CLASS_DEVICE
+   help
+ DRM driver for the following Ilitek ILI9341 panels:
+ * MRB2801 2.8" 240x320 TFT
+
+ If M is selected the module will be called ili9341_gpio.
+
 config TINYDRM_ILI9486
tristate "DRM support for ILI9486 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5..1ad2c0d 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_GM12U320)  += gm12u320.o
 obj-$(CONFIG_TINYDRM_HX8357D)  += hx8357d.o
 obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
 obj-$(CONFIG_TINYDRM_ILI9341)  += ili9341.o
+obj-$(CONFIG_TINYDRM_ILI9341_GPIO) += ili9341_gpio.o
 obj-$(CONFIG_TINYDRM_ILI9486)  += ili9486.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
diff --git a/drivers/gpu/drm/tiny/ili9341_gpio.c 
b/drivers/gpu/drm/tiny/ili9341_gpio.c
new file mode 100644
index 000..841f01c
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9341_gpio.c
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9341 panels with parallel bus interface
+ *
+ * Copyright 2020 Mikhail Durnev 
+ *
+ * Based on ili9341.c:
+ * Copyright 2018 David Lechner 
+ *
+ * Based on mi0283qt.c:
+ * Copyright 2016 Noralf Trønnes
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ILI9341_FRMCTR10xb1
+#define ILI9341_DISCTRL0xb6
+#define ILI9341_ETMOD  0xb7
+
+#define ILI9341_PWCTRL10xc0
+#define ILI9341_PWCTRL20xc1
+#define ILI9341_VMCTRL10xc5
+#define ILI9341_VMCTRL20xc7
+#define ILI9341_PWCTRLA0xcb
+#define ILI9341_PWCTRLB0xcf
+
+#define ILI9341_PGAMCTRL   0xe0
+#define ILI9341_NGAMCTRL   0xe1
+#define ILI9341_DTCTRLA0xe8
+#define ILI9341_DTCTRLB0xea
+#define ILI9341_PWRSEQ 0xed
+
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL   0xf7
+
+#define ILI9341_MADCTL_BGR BIT(3)
+#define ILI9341_MADCTL_MV  BIT(5)
+#define ILI9341_MADCTL_MX  BIT(6)
+#define ILI9341_MADCTL_MY  BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+   struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+   struct mipi_dbi *dbi = >dbi;
+   u8 addr_mode;
+   int ret, idx;
+
+   if (!drm_dev_enter(pipe->crtc.dev, ))
+   return;
+
+   DRM_DEBUG_KMS("\n");
+
+   ret = mipi_dbi_poweron_conditional_reset(dbidev);
+   if (ret < 0)
+   goto out_exit;
+   if (ret == 1)
+   goto out_enable;
+
+   mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_OFF);
+
+   mipi_dbi_command(dbi, ILI9341_PWCTRLB, 0x00, 0xc1, 0x30);
+   mipi_dbi_command(dbi, ILI9341_PWRSEQ, 0x64, 0x03, 0x12, 0x81);
+   mipi_dbi_command(dbi, ILI9341_DTCTRLA, 0x85, 0x00, 0x78);
+   mipi_dbi_command(dbi, ILI9341_PWCTRLA, 0x39, 0x2c, 0x00, 0x34, 0x02);
+   mipi_dbi_command(dbi, ILI9341_PUMPCTRL, 0x20);
+   mipi_dbi_command(dbi, ILI9341_DTCTRLB, 0x00, 0x00);
+
+   /* Power Control */
+   mipi_dbi_command(dbi, ILI9341_PWCTRL1, 0x23);
+   mipi_dbi_command(dbi, ILI9341_PWCTRL2, 0x10);
+   /* VCOM */
+   mipi_dbi_command(dbi, ILI9341_VMCTRL1, 0x3e, 0x28);
+   mipi_dbi_command(dbi, ILI9341_VMCTRL2, 0x86);
+
+   /* Memory 

[PATCH] drm/ttm: remove unused varibles

[Tian Tao]

fixed the following warnings
drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7aa4286..9465f56 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1228,7 +1228,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
 {
struct ttm_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
-   struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
 
if (ttm_tt_is_populated(ttm))
@@ -1242,7 +1241,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
}
 
drm = nouveau_bdev(bdev);
-   dev = drm->dev->dev;
 
return ttm_pool_alloc(>ttm.bdev.pool, ttm, ctx);
 }
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v11 00/10] Introduce memory interconnect for NVIDIA Tegra SoCs

[Dmitry Osipenko]

This series brings initial support for memory interconnect to Tegra20,
Tegra30 and Tegra124 SoCs.

For the starter only display controllers and devfreq devices are getting
interconnect API support, others could be supported later on. The display
controllers have the biggest demand for interconnect API right now because
dynamic memory frequency scaling can't be done safely without taking into
account bandwidth requirement from the displays. In particular this series
fixes distorted display output on T30 Ouya and T124 TK1 devices.

Changelog:

v11: - Added acks from Georgi Djakov.

 - CC'ed devicet...@vger.kernel.org in order to make the dt-bindings
   patch ("Document opp-supported-hw property") visible to the DT
   maintainers.

 - Rebased on a recent linux-next, note that some of v10 DT patches
   were already applied by Thierry into tegra tree, as well as one
   devfreq patch which removed the older tegra20-devfreq driver was
   applied by Chanwoo Choi to the devfreq tree.

 - Note that patch "memory: tegra20: Support hardware versioning and
   clean up OPP table initialization" fixes the noisy (but harmless)
   warning which happens because DT patches were applied before the
   code changes. This problem was spotted in current linux-next by
   Jonathan Hunter, hence could be worthwhile to pick up this patch
   for the v5.11.

v10 - In a longer run it will be much nicer if we could support EMC
  hardware versioning on Tegra20 and it's not late to support it now.
  Hence I added these new patches:

dt-bindings: memory: tegra20: emc: Document opp-supported-hw property
memory: tegra20: Support hardware versioning and clean up OPP table 
initialization

- Removed error message from tegra30-devfreq driver about missing OPP
  properties in a device-tree because EMC driver already prints that
  message and it uses OPP API error code instead of checking DT directly,
  which is a more correct way of doing that.

v9: - Squashed "memory: tegra30-emc: Factor out clk initialization" into
  patch "tegra30: Support interconnect framework".
  Suggested by Krzysztof Kozlowski.

- Improved Kconfig in the patch "memory: tegra124-emc: Make driver modular"
  by adding CONFIG_TEGRA124_CLK_EMC entry, which makes clk-driver changes
  to look a bit more cleaner. Suggested by Krzysztof Kozlowski.

- Dropped voltage regulator support from ICC and DT patches for now
  because there is a new discussion about using a power domain abstraction
  for controlling the regulator, which is likely to happen.

- Replaced direct "operating-points-v2" property checking in EMC drivers
  with checking of a returned error code from dev_pm_opp_of_add_table().
  Note that I haven't touched T20 EMC driver because it's very likely
  that we'll replace that code with a common helper soon anyways.
  Suggested by Viresh Kumar.

- The T30 DT patches now include EMC OPP changes for Ouya board, which
  is available now in linux-next.

Dmitry Osipenko (10):
  dt-bindings: memory: tegra20: emc: Document opp-supported-hw property
  memory: tegra20: Support hardware versioning and clean up OPP table
initialization
  memory: tegra30: Support interconnect framework
  memory: tegra124-emc: Make driver modular
  memory: tegra124-emc: Continue probing if timings are missing in
device-tree
  memory: tegra124: Support interconnect framework
  drm/tegra: dc: Support memory bandwidth management
  drm/tegra: dc: Extend debug stats with total number of events
  PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
  PM / devfreq: tegra30: Separate configurations per-SoC generation

 .../memory-controllers/nvidia,tegra20-emc.txt |   6 +
 drivers/clk/tegra/Kconfig |   3 +
 drivers/clk/tegra/Makefile|   2 +-
 drivers/clk/tegra/clk-tegra124-emc.c  |  41 +-
 drivers/clk/tegra/clk-tegra124.c  |  26 +-
 drivers/clk/tegra/clk.h   |  18 +-
 drivers/devfreq/tegra30-devfreq.c | 147 ---
 drivers/gpu/drm/tegra/Kconfig |   1 +
 drivers/gpu/drm/tegra/dc.c| 359 +
 drivers/gpu/drm/tegra/dc.h|  19 +
 drivers/gpu/drm/tegra/drm.c   |  14 +
 drivers/gpu/drm/tegra/hub.c   |   3 +
 drivers/gpu/drm/tegra/plane.c | 121 ++
 drivers/gpu/drm/tegra/plane.h |  15 +
 drivers/memory/tegra/Kconfig  |   5 +-
 drivers/memory/tegra/tegra124-emc.c   | 377 --
 drivers/memory/tegra/tegra124.c   |  82 +++-
 drivers/memory/tegra/tegra20-emc.c|  48 +--
 drivers/memory/tegra/tegra30-emc.c| 344 +++-
 drivers/memory/tegra/tegra30.c| 173 +++-
 include/linux/clk/tegra.h |   8 +
 

[PATCH] drm: Allow drm_fourcc.h without including drm.h

[James Park]

Add DRM_FOURCC_STANDALONE guard to skip drm.h dependency.

This will allow Mesa to port code to Windows more easily.

Signed-off-by: James Park 
---
 include/uapi/drm/drm_fourcc.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 82f3278..159a9d0 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -24,7 +24,13 @@
 #ifndef DRM_FOURCC_H
 #define DRM_FOURCC_H
 
+#ifdef DRM_FOURCC_STANDALONE
+#include 
+typedef uint32_t __u32;
+typedef uint64_t __u64;
+#else
 #include "drm.h"
+#endif
 
 #if defined(__cplusplus)
 extern "C" {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/8] drm/vc4: drv: Remove the DSI pointer in vc4_drv

[Maxime Ripard]

That pointer isn't used anywhere, so there's no point in keeping it.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_drv.h | 1 -
 drivers/gpu/drm/vc4/vc4_dsi.c | 9 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c5f2944d5bc6..ee95b4327796 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -77,7 +77,6 @@ struct vc4_dev {
struct vc4_hvs *hvs;
struct vc4_v3d *v3d;
struct vc4_dpi *dpi;
-   struct vc4_dsi *dsi1;
struct vc4_vec *vec;
struct vc4_txp *txp;
 
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 19aab4e7e209..b1d8765795f1 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1459,7 +1459,6 @@ static int vc4_dsi_bind(struct device *dev, struct device 
*master, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = dev_get_drvdata(master);
-   struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_dsi *dsi = dev_get_drvdata(dev);
struct vc4_dsi_encoder *vc4_dsi_encoder;
struct drm_panel *panel;
@@ -1612,9 +1611,6 @@ static int vc4_dsi_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;
 
-   if (dsi->port == 1)
-   vc4->dsi1 = dsi;
-
drm_simple_encoder_init(drm, dsi->encoder, DRM_MODE_ENCODER_DSI);
drm_encoder_helper_add(dsi->encoder, _dsi_encoder_helper_funcs);
 
@@ -1643,8 +1639,6 @@ static int vc4_dsi_bind(struct device *dev, struct device 
*master, void *data)
 static void vc4_dsi_unbind(struct device *dev, struct device *master,
   void *data)
 {
-   struct drm_device *drm = dev_get_drvdata(master);
-   struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_dsi *dsi = dev_get_drvdata(dev);
 
if (dsi->bridge)
@@ -1656,9 +1650,6 @@ static void vc4_dsi_unbind(struct device *dev, struct 
device *master,
 */
list_splice_init(>bridge_chain, >encoder->bridge_chain);
drm_encoder_cleanup(dsi->encoder);
-
-   if (dsi->port == 1)
-   vc4->dsi1 = NULL;
 }
 
 static const struct component_ops vc4_dsi_ops = {
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v11 05/10] memory: tegra124-emc: Continue probing if timings are missing in device-tree

[Dmitry Osipenko]

EMC driver will become mandatory after turning it into interconnect
provider because interconnect users, like display controller driver, will
fail to probe using newer device-trees that have interconnect properties.
Thus make EMC driver to probe even if timings are missing in device-tree.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra124-emc.c | 26 +-
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/memory/tegra/tegra124-emc.c 
b/drivers/memory/tegra/tegra124-emc.c
index edfbf6d6d357..8fb8c1af25c9 100644
--- a/drivers/memory/tegra/tegra124-emc.c
+++ b/drivers/memory/tegra/tegra124-emc.c
@@ -1201,23 +1201,15 @@ static int tegra_emc_probe(struct platform_device *pdev)
ram_code = tegra_read_ram_code();
 
np = tegra_emc_find_node_by_ram_code(pdev->dev.of_node, ram_code);
-   if (!np) {
-   dev_err(>dev,
-   "no memory timings for RAM code %u found in DT\n",
-   ram_code);
-   return -ENOENT;
-   }
-
-   err = tegra_emc_load_timings_from_dt(emc, np);
-   of_node_put(np);
-   if (err)
-   return err;
-
-   if (emc->num_timings == 0) {
-   dev_err(>dev,
-   "no memory timings for RAM code %u registered\n",
-   ram_code);
-   return -ENOENT;
+   if (np) {
+   err = tegra_emc_load_timings_from_dt(emc, np);
+   of_node_put(np);
+   if (err)
+   return err;
+   } else {
+   dev_info(>dev,
+"no memory timings for RAM code %u found in DT\n",
+ram_code);
}
 
err = emc_init(emc);
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/fb-helper: Add missed unlocks in setcmap_legacy()

[Chuhong Yuan]

setcmap_legacy() does not call drm_modeset_unlock_all() in some exits,
add the missed unlocks with goto to fix it.

Fixes: 964c60063bff ("drm/fb-helper: separate the fb_setcmap helper into atomic 
and legacy paths")
Signed-off-by: Chuhong Yuan 
---
 drivers/gpu/drm/drm_fb_helper.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1543d9d10970..8033467db4be 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -923,11 +923,15 @@ static int setcmap_legacy(struct fb_cmap *cmap, struct 
fb_info *info)
drm_modeset_lock_all(fb_helper->dev);
drm_client_for_each_modeset(modeset, _helper->client) {
crtc = modeset->crtc;
-   if (!crtc->funcs->gamma_set || !crtc->gamma_size)
-   return -EINVAL;
+   if (!crtc->funcs->gamma_set || !crtc->gamma_size) {
+   ret = -EINVAL;
+   goto out;
+   }
 
-   if (cmap->start + cmap->len > crtc->gamma_size)
-   return -EINVAL;
+   if (cmap->start + cmap->len > crtc->gamma_size) {
+   ret = -EINVAL;
+   goto out;
+   }
 
r = crtc->gamma_store;
g = r + crtc->gamma_size;
@@ -940,8 +944,9 @@ static int setcmap_legacy(struct fb_cmap *cmap, struct 
fb_info *info)
ret = crtc->funcs->gamma_set(crtc, r, g, b,
 crtc->gamma_size, NULL);
if (ret)
-   return ret;
+   goto out;
}
+out:
drm_modeset_unlock_all(fb_helper->dev);
 
return ret;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/8] drm/vc4: dsi: Use snprintf for the PHY clocks instead of an array

[Maxime Ripard]

The DSI clocks setup function has been using an array to store the clock
name of either the DSI0 or DSI1 blocks, using the port ID to choose the
proper one.

Let's switch to an snprintf call to do the same thing and simplify the
array a bit.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index bb316e6cc12b..f704d959e65b 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1398,12 +1398,12 @@ vc4_dsi_init_phy_clocks(struct vc4_dsi *dsi)
struct device *dev = >pdev->dev;
const char *parent_name = __clk_get_name(dsi->pll_phy_clock);
static const struct {
-   const char *dsi0_name, *dsi1_name;
+   const char *name;
int div;
} phy_clocks[] = {
-   { "dsi0_byte", "dsi1_byte", 8 },
-   { "dsi0_ddr2", "dsi1_ddr2", 4 },
-   { "dsi0_ddr", "dsi1_ddr", 2 },
+   { "byte", 8 },
+   { "ddr2", 4 },
+   { "ddr", 2 },
};
int i;
 
@@ -1419,8 +1419,12 @@ vc4_dsi_init_phy_clocks(struct vc4_dsi *dsi)
for (i = 0; i < ARRAY_SIZE(phy_clocks); i++) {
struct clk_fixed_factor *fix = >phy_clocks[i];
struct clk_init_data init;
+   char clk_name[16];
int ret;
 
+   snprintf(clk_name, sizeof(clk_name),
+"dsi%u_%s", dsi->port, phy_clocks[i].name);
+
/* We just use core fixed factor clock ops for the PHY
 * clocks.  The clocks are actually gated by the
 * PHY_AFEC0_DDRCLK_EN bits, which we should be
@@ -1437,10 +1441,7 @@ vc4_dsi_init_phy_clocks(struct vc4_dsi *dsi)
memset(, 0, sizeof(init));
init.parent_names = _name;
init.num_parents = 1;
-   if (dsi->port == 1)
-   init.name = phy_clocks[i].dsi1_name;
-   else
-   init.name = phy_clocks[i].dsi0_name;
+   init.name = clk_name;
init.ops = _fixed_factor_ops;
 
ret = devm_clk_hw_register(dev, >hw);
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v11 06/10] memory: tegra124: Support interconnect framework

[Dmitry Osipenko]

Now Internal and External memory controllers are memory interconnection
providers. This allows us to use interconnect API for tuning of memory
configuration. EMC driver now supports OPPs and DVFS.

Tested-by: Nicolas Chauvet 
Acked-by: Georgi Djakov 
Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/Kconfig|   1 +
 drivers/memory/tegra/tegra124-emc.c | 320 +++-
 drivers/memory/tegra/tegra124.c |  82 ++-
 3 files changed, 391 insertions(+), 12 deletions(-)

diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index f5b451403c58..a70967a56e52 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -36,6 +36,7 @@ config TEGRA124_EMC
default y
depends on TEGRA_MC && ARCH_TEGRA_124_SOC
select TEGRA124_CLK_EMC
+   select PM_OPP
help
  This driver is for the External Memory Controller (EMC) found on
  Tegra124 chips. The EMC controls the external DRAM on the board.
diff --git a/drivers/memory/tegra/tegra124-emc.c 
b/drivers/memory/tegra/tegra124-emc.c
index 8fb8c1af25c9..9706550bdd5d 100644
--- a/drivers/memory/tegra/tegra124-emc.c
+++ b/drivers/memory/tegra/tegra124-emc.c
@@ -12,20 +12,26 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include 
 #include 
 
+#include "mc.h"
+
 #define EMC_FBIO_CFG5  0x104
 #defineEMC_FBIO_CFG5_DRAM_TYPE_MASK0x3
 #defineEMC_FBIO_CFG5_DRAM_TYPE_SHIFT   0
+#define EMC_FBIO_CFG5_DRAM_WIDTH_X64   BIT(4)
 
 #define EMC_INTSTATUS  0x0
 #define EMC_INTSTATUS_CLKCHANGE_COMPLETE   BIT(4)
@@ -461,6 +467,17 @@ struct emc_timing {
u32 emc_zcal_interval;
 };
 
+enum emc_rate_request_type {
+   EMC_RATE_DEBUG,
+   EMC_RATE_ICC,
+   EMC_RATE_TYPE_MAX,
+};
+
+struct emc_rate_request {
+   unsigned long min_rate;
+   unsigned long max_rate;
+};
+
 struct tegra_emc {
struct device *dev;
 
@@ -471,6 +488,7 @@ struct tegra_emc {
struct clk *clk;
 
enum emc_dram_type dram_type;
+   unsigned int dram_bus_width;
unsigned int dram_num;
 
struct emc_timing last_timing;
@@ -482,6 +500,17 @@ struct tegra_emc {
unsigned long min_rate;
unsigned long max_rate;
} debugfs;
+
+   struct icc_provider provider;
+
+   /*
+* There are multiple sources in the EMC driver which could request
+* a min/max clock rate, these rates are contained in this array.
+*/
+   struct emc_rate_request requested_rate[EMC_RATE_TYPE_MAX];
+
+   /* protect shared rate-change code path */
+   struct mutex rate_lock;
 };
 
 /* Timing change sequence functions */
@@ -870,6 +899,14 @@ static void emc_read_current_timing(struct tegra_emc *emc,
 static int emc_init(struct tegra_emc *emc)
 {
emc->dram_type = readl(emc->regs + EMC_FBIO_CFG5);
+
+   if (emc->dram_type & EMC_FBIO_CFG5_DRAM_WIDTH_X64)
+   emc->dram_bus_width = 64;
+   else
+   emc->dram_bus_width = 32;
+
+   dev_info(emc->dev, "%ubit DRAM bus\n", emc->dram_bus_width);
+
emc->dram_type &= EMC_FBIO_CFG5_DRAM_TYPE_MASK;
emc->dram_type >>= EMC_FBIO_CFG5_DRAM_TYPE_SHIFT;
 
@@ -1009,6 +1046,83 @@ tegra_emc_find_node_by_ram_code(struct device_node 
*node, u32 ram_code)
return NULL;
 }
 
+static void tegra_emc_rate_requests_init(struct tegra_emc *emc)
+{
+   unsigned int i;
+
+   for (i = 0; i < EMC_RATE_TYPE_MAX; i++) {
+   emc->requested_rate[i].min_rate = 0;
+   emc->requested_rate[i].max_rate = ULONG_MAX;
+   }
+}
+
+static int emc_request_rate(struct tegra_emc *emc,
+   unsigned long new_min_rate,
+   unsigned long new_max_rate,
+   enum emc_rate_request_type type)
+{
+   struct emc_rate_request *req = emc->requested_rate;
+   unsigned long min_rate = 0, max_rate = ULONG_MAX;
+   unsigned int i;
+   int err;
+
+   /* select minimum and maximum rates among the requested rates */
+   for (i = 0; i < EMC_RATE_TYPE_MAX; i++, req++) {
+   if (i == type) {
+   min_rate = max(new_min_rate, min_rate);
+   max_rate = min(new_max_rate, max_rate);
+   } else {
+   min_rate = max(req->min_rate, min_rate);
+   max_rate = min(req->max_rate, max_rate);
+   }
+   }
+
+   if (min_rate > max_rate) {
+   dev_err_ratelimited(emc->dev, "%s: type %u: out of range: %lu 
%lu\n",
+   __func__, type, min_rate, max_rate);
+   return -ERANGE;
+   }
+
+   /*
+* EMC rate-changes should go via OPP API because it manages voltage
+

[PATCH v11 10/10] PM / devfreq: tegra30: Separate configurations per-SoC generation

[Dmitry Osipenko]

Previously we were using count-weight of the T124 for T30 in order to
get EMC clock rate that was reasonable for T30. In fact the count-weight
should be x2 times smaller on T30, but then devfreq was producing a bit
too low EMC clock rate for ISO memory clients, like display controller
for example.

Now both Tegra ACTMON and Tegra DRM display drivers support interconnect
framework and display driver tells to ICC what a minimum memory bandwidth
is needed, preventing FIFO underflows. Thus, now we can use a proper
count-weight value for Tegra30 and MC_ALL device config needs a bit more
aggressive boosting.

Add a separate ACTMON driver configuration that is specific to Tegra30.

Tested-by: Peter Geis 
Tested-by: Nicolas Chauvet 
Acked-by: Chanwoo Choi 
Signed-off-by: Dmitry Osipenko 
---
 drivers/devfreq/tegra30-devfreq.c | 68 ---
 1 file changed, 54 insertions(+), 14 deletions(-)

diff --git a/drivers/devfreq/tegra30-devfreq.c 
b/drivers/devfreq/tegra30-devfreq.c
index 145ef91ae092..117cad7968ab 100644
--- a/drivers/devfreq/tegra30-devfreq.c
+++ b/drivers/devfreq/tegra30-devfreq.c
@@ -57,13 +57,6 @@
 #define ACTMON_BELOW_WMARK_WINDOW  3
 #define ACTMON_BOOST_FREQ_STEP 16000
 
-/*
- * Activity counter is incremented every 256 memory transactions, and each
- * transaction takes 4 EMC clocks for Tegra124; So the COUNT_WEIGHT is
- * 4 * 256 = 1024.
- */
-#define ACTMON_COUNT_WEIGHT0x400
-
 /*
  * ACTMON_AVERAGE_WINDOW_LOG2: default value for @DEV_CTRL_K_VAL, which
  * translates to 2 ^ (K_VAL + 1). ex: 2 ^ (6 + 1) = 128
@@ -111,7 +104,7 @@ enum tegra_actmon_device {
MCCPU,
 };
 
-static const struct tegra_devfreq_device_config actmon_device_configs[] = {
+static const struct tegra_devfreq_device_config tegra124_device_configs[] = {
{
/* MCALL: All memory accesses (including from the CPUs) */
.offset = 0x1c0,
@@ -133,6 +126,28 @@ static const struct tegra_devfreq_device_config 
actmon_device_configs[] = {
},
 };
 
+static const struct tegra_devfreq_device_config tegra30_device_configs[] = {
+   {
+   /* MCALL: All memory accesses (including from the CPUs) */
+   .offset = 0x1c0,
+   .irq_mask = 1 << 26,
+   .boost_up_coeff = 200,
+   .boost_down_coeff = 50,
+   .boost_up_threshold = 20,
+   .boost_down_threshold = 10,
+   },
+   {
+   /* MCCPU: memory accesses from the CPUs */
+   .offset = 0x200,
+   .irq_mask = 1 << 25,
+   .boost_up_coeff = 800,
+   .boost_down_coeff = 40,
+   .boost_up_threshold = 27,
+   .boost_down_threshold = 10,
+   .avg_dependency_threshold = 16000, /* 16MHz in kHz units */
+   },
+};
+
 /**
  * struct tegra_devfreq_device - state specific to an ACTMON device
  *
@@ -155,6 +170,12 @@ struct tegra_devfreq_device {
unsigned long target_freq;
 };
 
+struct tegra_devfreq_soc_data {
+   const struct tegra_devfreq_device_config *configs;
+   /* Weight value for count measurements */
+   unsigned int count_weight;
+};
+
 struct tegra_devfreq {
struct devfreq  *devfreq;
struct opp_table*opp_table;
@@ -171,11 +192,13 @@ struct tegra_devfreq {
struct delayed_work cpufreq_update_work;
struct notifier_block   cpu_rate_change_nb;
 
-   struct tegra_devfreq_device devices[ARRAY_SIZE(actmon_device_configs)];
+   struct tegra_devfreq_device devices[2];
 
unsigned intirq;
 
boolstarted;
+
+   const struct tegra_devfreq_soc_data *soc;
 };
 
 struct tegra_actmon_emc_ratio {
@@ -488,7 +511,7 @@ static void tegra_actmon_configure_device(struct 
tegra_devfreq *tegra,
tegra_devfreq_update_avg_wmark(tegra, dev);
tegra_devfreq_update_wmark(tegra, dev);
 
-   device_writel(dev, ACTMON_COUNT_WEIGHT, ACTMON_DEV_COUNT_WEIGHT);
+   device_writel(dev, tegra->soc->count_weight, ACTMON_DEV_COUNT_WEIGHT);
device_writel(dev, ACTMON_INTR_STATUS_CLEAR, ACTMON_DEV_INTR_STATUS);
 
val |= ACTMON_DEV_CTRL_ENB_PERIODIC;
@@ -779,6 +802,8 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
if (!tegra)
return -ENOMEM;
 
+   tegra->soc = of_device_get_match_data(>dev);
+
tegra->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(tegra->regs))
return PTR_ERR(tegra->regs);
@@ -852,9 +877,9 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
 
tegra->max_freq = rate / KHZ;
 
-   for (i = 0; i < ARRAY_SIZE(actmon_device_configs); i++) {
+   for (i = 0; i < ARRAY_SIZE(tegra->devices); i++) {
dev = tegra->devices + i;
-   dev->config = actmon_device_configs + i;
+  

[PATCH 5/8] drm/vc4: dsi: Add support for DSI0

[Maxime Ripard]

From: Dave Stevenson 

DSI0 was partially supported, but didn't register with the main
driver, and the code was inconsistent as to whether it checked
port == 0 or port == 1.

Add compatible string and other support to make it consistent.

Signed-off-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 601020c10053..82162900e351 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1324,6 +1324,13 @@ static const struct drm_encoder_helper_funcs 
vc4_dsi_encoder_helper_funcs = {
.mode_fixup = vc4_dsi_encoder_mode_fixup,
 };
 
+static const struct vc4_dsi_variant bcm2835_dsi0_variant = {
+   .port   = 0,
+   .debugfs_name   = "dsi0_regs",
+   .regs   = dsi0_regs,
+   .nregs  = ARRAY_SIZE(dsi0_regs),
+};
+
 static const struct vc4_dsi_variant bcm2835_dsi1_variant = {
.port   = 1,
.broken_axi_workaround  = true,
@@ -1333,6 +1340,7 @@ static const struct vc4_dsi_variant bcm2835_dsi1_variant 
= {
 };
 
 static const struct of_device_id vc4_dsi_dt_match[] = {
+   { .compatible = "brcm,bcm2835-dsi0", _dsi0_variant },
{ .compatible = "brcm,bcm2835-dsi1", _dsi1_variant },
{}
 };
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 1/2] drm: RFC add choice to use dynamic debug in drm-debug

[Jim Cromie]

drm's debug system uses distinct categories of debug messages, mapped
to bits in drm.debug.  Currently, code does a lot of unlikely bit-mask
checks on drm.debug (in drm_debug_enabled), we can use dynamic debug
instead, and get all that jump_label goodness.

RFC: dynamic debug has no concept of category, but we can do without
one if we can prepend a class-prefix to each printk format.  Then we
can use "format ^prefix" to select the whole category with one query.
This is a log-facing and user visible change, but it seems unlikely to
cause trouble for log watchers; they're not relying on the absence of
class prefix strings.

This conversion yields ~2100 new callsites on my i7 laptop:

  dyndbg: 195 debug prints in module drm_kms_helper
  dyndbg: 298 debug prints in module drm
  dyndbg: 1630 debug prints in module i915

Since this change has wide-ranging effects (many drm drivers, with
many callsites, and kernel image growth), and most vendors don't
enable DYNAMIC_DEBUG, we supplement the existing mechanism, adding
CONFIG_DRM_USE_DYNAMIC_DEBUG to enable the new one.

The indirection/switchover has a few parts:

1 a new callback on drm.debug which calls dynamic_debug_exec_queries
  to map those bits to specific query/commands
  dynamic_debug_exec_queries("format ^drm:kms: +p", "drm*");

2 a "converted" or "classy" DRM_UT_* map
  similar to DRM_UT_* ( symbol => bit-mask )
  named it  cDRM_UT_* ( symbol => format-class-prefix-string )

  cDRM_UT_* is either ( CONFIG_DRM_USE_DYNAMIC_DEBUG )
  legacy: cDRM_UT_* <-- DRM_UT_*
  enabled:
  +#define cDRM_UT_KMS"drm:kms: "
  +#define cDRM_UT_PRIME  "drm:prime: "
  +#define cDRM_UT_ATOMIC "drm:atomic: "

  these are similar to "gvt: cmd:" in i915/gvt
  and effectively a replacement for DRM_NAME
  please bikeshed on keys, values. latter are log-facing.

3 drm_dev_dbg & drm_debug are renamed (prefixed with '_')
  old names are now macros, which are ifdefd
  legacy:  -> to renamed fn
  enabled: -> dev_dbg & pr_debug, after prepending prefix to format.

4 names in (2) are called from DRM_DEBUG_ and drm_dbg_.
  all these get "converted" to use cDRM_UT_*, to get right token type.

RFC: for dynamic debug, category is a source-facing addition;
something like pr_debug_cat(cat, ...) would do it, iff cat is a
compile-time const.  Note that cat isn't needed in the printing, it
would be saved into a new field in struct _ddebug, and used only for
callsite selection, activation and control.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/Kconfig | 13 ++
 drivers/gpu/drm/drm_print.c | 75 --
 include/drm/drm_print.h | 92 +++--
 3 files changed, 153 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 147d61b9674e..854bc1ad21fb 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -54,6 +54,19 @@ config DRM_DEBUG_MM
 
  If in doubt, say "N".
 
+config DRM_USE_DYNAMIC_DEBUG
+   bool "use dynamic debug to implement drm.debug"
+   default n
+   depends on DRM
+   depends on DYNAMIC_DEBUG
+   depends on JUMP_LABEL
+   help
+ The drm debug category facility does a lot of unlikely bit-field
+ tests at runtime; while cheap individually, the cost accumulates.
+ This option uses dynamic debug facility (if configured and
+ using jump_label) to avoid those runtime checks, patching
+ the kernel when those debugs are desired.
+
 config DRM_DEBUG_SELFTEST
tristate "kselftests for DRM"
depends on DRM
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 111b932cf2a9..e2acdfc7088b 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -52,8 +52,75 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit 
enables a debug cat
 "\t\tBit 5 (0x20)  will enable VBL messages (vblank code)\n"
 "\t\tBit 7 (0x80)  will enable LEASE messages (leasing code)\n"
 "\t\tBit 8 (0x100) will enable DP messages (displayport code)");
+
+#ifndef CONFIG_DRM_USE_DYNAMIC_DEBUG
 module_param_named(debug, __drm_debug, int, 0600);
 
+#else
+static char *format_class_prefixes[] = {
+   cDRM_UT_CORE,
+   cDRM_UT_DRIVER,
+   cDRM_UT_KMS,
+   cDRM_UT_PRIME,
+   cDRM_UT_ATOMIC,
+   cDRM_UT_VBL,
+   cDRM_UT_STATE,
+   cDRM_UT_LEASE,
+   cDRM_UT_DP,
+   cDRM_UT_DRMRES
+};
+
+#define OUR_QUERY_SIZE 64 /* > strlen "format '^%s' %cp" + longest prefix */
+
+static int param_set_dyndbg(const char *instr, const struct kernel_param *kp)
+{
+   unsigned int val;
+   unsigned long changes, result;
+   int rc, chgct = 0, totct = 0, bitpos;
+   char query[OUR_QUERY_SIZE];
+
+   rc = kstrtouint(instr, 0, );
+   if (rc) {
+   pr_err("%s: failed\n", __func__);
+   return -EINVAL;
+   }
+   result = val;
+   changes = result ^ __drm_debug;
+
+   pr_debug("changes:0x%lx from 

[PATCH v3 0/3] Add bus format negotiation support for Cadence MHDP8546 driver

[Yuti Amonkar]

This patch series add bus format negotiation support for Cadence MHDP8546 
bridge driver.

The patch series has four patches in the below sequence:
1. drm: bridge: cdns-mhdp8546: Modify atomic_get_input_bus_format bridge 
function.
   Return all the input formats supported.
2. drm: bridge: cdns-mhdp8546: Remove setting of bus format using connector 
info 
   Remove the bus format configuration using connector info structure.
3. drm: bridge: cdns-mhdp8546: Retrieve the pixel format and bpc based on bus 
format 
   Get the pixel format and bpc based on negotiated output bus format.

This patch series is dependent on tidss series [1] for the new connector model 
support.

[1]
https://patchwork.kernel.org/project/dri-devel/cover/20201201121830.29704-1-nikhil...@ti.com/

Version History:

v3:
 - Modify the atomic_get_input_bus_fmts to return the 
MEDIA_BUS_FMT_RGB121212_1X36
   as default format.along as tidss currently supports only this format.

v2:
 - Remove the Add output bus format negotiation patch from the series, 
   as we use ouput format as MEDIA_BUS_FMT_FIXED and that is  the 
   default value if atomic_get_output_bus_fmts function is not implemented.
 - Return NULL if output format is not MEDIA_BUS_FMT_FIXED.
 - Return the supported color formats based on the display info structure.


Yuti Amonkar (3):
  drm: bridge: cdns-mhdp8546: Modify atomic_get_input_bus_format bridge
function
  drm: bridge: cdns-mhdp8546: Remove setting of bus format using
connector info
  drm: bridge: cdns-mhdp8546: Retrieve the pixel format and bpc based on
bus format

 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 171 ++
 1 file changed, 138 insertions(+), 33 deletions(-)

-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/3] drm: bridge: cdns-mhdp8546: Retrieve the pixel format and bpc based on bus format

[Yuti Amonkar]

Get the pixel format and bpc based on the output bus format
negotiated instead of hardcoding the values.

Signed-off-by: Yuti Amonkar 
---
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 82 +++
 1 file changed, 64 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index d9f7eb8249e8..2ad5cad46599 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -1530,24 +1530,8 @@ static int cdns_mhdp_get_modes(struct drm_connector 
*connector)
 
drm_connector_update_edid_property(connector, edid);
num_modes = drm_add_edid_modes(connector, edid);
-   kfree(edid);
 
-   /*
-* HACK: Warn about unsupported display formats until we deal
-*   with them correctly.
-*/
-   if (connector->display_info.color_formats &&
-   !(connector->display_info.color_formats &
- mhdp->display_fmt.color_format))
-   dev_warn(mhdp->dev,
-"%s: No supported color_format found (0x%08x)\n",
-   __func__, connector->display_info.color_formats);
-
-   if (connector->display_info.bpc &&
-   connector->display_info.bpc < mhdp->display_fmt.bpc)
-   dev_warn(mhdp->dev, "%s: Display bpc only %d < %d\n",
-__func__, connector->display_info.bpc,
-mhdp->display_fmt.bpc);
+   kfree(edid);
 
return num_modes;
 }
@@ -1706,6 +1690,66 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
return 0;
 }
 
+static void cdns_mhdp_get_display_fmt(struct cdns_mhdp_device *mhdp,
+ struct drm_bridge_state *state)
+{
+   u32 bus_fmt, bpc, pxlfmt;
+
+   bus_fmt = state->output_bus_cfg.format;
+   switch (bus_fmt) {
+   case MEDIA_BUS_FMT_RGB161616_1X48:
+   pxlfmt = DRM_COLOR_FORMAT_RGB444;
+   bpc = 16;
+   break;
+   case MEDIA_BUS_FMT_YUV16_1X48:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+   bpc = 16;
+   break;
+   case MEDIA_BUS_FMT_RGB121212_1X36:
+   pxlfmt = DRM_COLOR_FORMAT_RGB444;
+   bpc = 12;
+   break;
+   case MEDIA_BUS_FMT_UYVY12_1X24:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB422;
+   bpc = 12;
+   break;
+   case MEDIA_BUS_FMT_YUV12_1X36:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+   bpc = 12;
+   break;
+   case MEDIA_BUS_FMT_RGB101010_1X30:
+   pxlfmt = DRM_COLOR_FORMAT_RGB444;
+   bpc = 10;
+   break;
+   case MEDIA_BUS_FMT_UYVY10_1X20:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB422;
+   bpc = 10;
+   break;
+   case MEDIA_BUS_FMT_YUV10_1X30:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+   bpc = 10;
+   break;
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   pxlfmt = DRM_COLOR_FORMAT_RGB444;
+   bpc = 8;
+   break;
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB422;
+   bpc = 8;
+   break;
+   case MEDIA_BUS_FMT_YUV8_1X24:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+   bpc = 8;
+   break;
+   default:
+   pxlfmt = DRM_COLOR_FORMAT_RGB444;
+   bpc = 8;
+   }
+
+   mhdp->display_fmt.color_format = pxlfmt;
+   mhdp->display_fmt.bpc = bpc;
+}
+
 static void cdns_mhdp_configure_video(struct cdns_mhdp_device *mhdp,
  const struct drm_display_mode *mode)
 {
@@ -2186,6 +2230,8 @@ static int cdns_mhdp_atomic_check(struct drm_bridge 
*bridge,
struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
const struct drm_display_mode *mode = _state->adjusted_mode;
 
+   cdns_mhdp_get_display_fmt(mhdp, bridge_state);
+
mutex_lock(>link_mutex);
 
if (!cdns_mhdp_bandwidth_ok(mhdp, mode, mhdp->link.num_lanes,
@@ -2499,7 +2545,7 @@ static int cdns_mhdp_probe(struct platform_device *pdev)
mhdp->link.rate = mhdp->host.link_rate;
mhdp->link.num_lanes = mhdp->host.lanes_cnt;
 
-   /* The only currently supported format */
+   /* Initialize color format bpc and y_only to default values*/
mhdp->display_fmt.y_only = false;
mhdp->display_fmt.color_format = DRM_COLOR_FORMAT_RGB444;
mhdp->display_fmt.bpc = 8;
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/8] drm/vc4: dsi: Introduce a variant structure

[Maxime Ripard]

Most of the differences between DSI0 and DSI1 are handled through the
ID. However, the BCM2711 DSI is going to introduce one more variable to
the mix and will break some expectations of the earlier, simpler, test.

Let's add a variant structure that will address most of the differences
between those three controllers.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 63 ---
 1 file changed, 37 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index f704d959e65b..601020c10053 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -493,6 +493,18 @@
  */
 #define DSI1_ID0x8c
 
+struct vc4_dsi_variant {
+   /* Whether we're on bcm2835's DSI0 or DSI1. */
+   unsigned int port;
+
+   bool broken_axi_workaround;
+
+   const char *debugfs_name;
+   const struct debugfs_reg32 *regs;
+   size_t nregs;
+
+};
+
 /* General DSI hardware state. */
 struct vc4_dsi {
struct platform_device *pdev;
@@ -509,8 +521,7 @@ struct vc4_dsi {
u32 *reg_dma_mem;
dma_addr_t reg_paddr;
 
-   /* Whether we're on bcm2835's DSI0 or DSI1. */
-   int port;
+   const struct vc4_dsi_variant *variant;
 
/* DSI channel for the panel we're connected to. */
u32 channel;
@@ -586,10 +597,10 @@ dsi_dma_workaround_write(struct vc4_dsi *dsi, u32 offset, 
u32 val)
 #define DSI_READ(offset) readl(dsi->regs + (offset))
 #define DSI_WRITE(offset, val) dsi_dma_workaround_write(dsi, offset, val)
 #define DSI_PORT_READ(offset) \
-   DSI_READ(dsi->port ? DSI1_##offset : DSI0_##offset)
+   DSI_READ(dsi->variant->port ? DSI1_##offset : DSI0_##offset)
 #define DSI_PORT_WRITE(offset, val) \
-   DSI_WRITE(dsi->port ? DSI1_##offset : DSI0_##offset, val)
-#define DSI_PORT_BIT(bit) (dsi->port ? DSI1_##bit : DSI0_##bit)
+   DSI_WRITE(dsi->variant->port ? DSI1_##offset : DSI0_##offset, val)
+#define DSI_PORT_BIT(bit) (dsi->variant->port ? DSI1_##bit : DSI0_##bit)
 
 /* VC4 DSI encoder KMS struct */
 struct vc4_dsi_encoder {
@@ -837,7 +848,7 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
*encoder)
 
ret = pm_runtime_get_sync(dev);
if (ret) {
-   DRM_ERROR("Failed to runtime PM enable on DSI%d\n", dsi->port);
+   DRM_ERROR("Failed to runtime PM enable on DSI%d\n", 
dsi->variant->port);
return;
}
 
@@ -871,7 +882,7 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
*encoder)
DSI_PORT_WRITE(STAT, DSI_PORT_READ(STAT));
 
/* Set AFE CTR00/CTR1 to release powerdown of analog. */
-   if (dsi->port == 0) {
+   if (dsi->variant->port == 0) {
u32 afec0 = (VC4_SET_FIELD(7, DSI_PHY_AFEC0_PTATADJ) |
 VC4_SET_FIELD(7, DSI_PHY_AFEC0_CTATADJ));
 
@@ -1017,7 +1028,7 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
*encoder)
   DSI_PORT_BIT(PHYC_CLANE_ENABLE) |
   ((dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) ?
0 : DSI_PORT_BIT(PHYC_HS_CLK_CONTINUOUS)) |
-  (dsi->port == 0 ?
+  (dsi->variant->port == 0 ?
VC4_SET_FIELD(lpx - 1, DSI0_PHYC_ESC_CLK_LPDT) :
VC4_SET_FIELD(lpx - 1, DSI1_PHYC_ESC_CLK_LPDT)));
 
@@ -1043,13 +1054,13 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
*encoder)
   DSI_DISP1_ENABLE);
 
/* Ungate the block. */
-   if (dsi->port == 0)
+   if (dsi->variant->port == 0)
DSI_PORT_WRITE(CTRL, DSI_PORT_READ(CTRL) | DSI0_CTRL_CTRL0);
else
DSI_PORT_WRITE(CTRL, DSI_PORT_READ(CTRL) | DSI1_CTRL_EN);
 
/* Bring AFE out of reset. */
-   if (dsi->port == 0) {
+   if (dsi->variant->port == 0) {
} else {
DSI_PORT_WRITE(PHY_AFEC0,
   DSI_PORT_READ(PHY_AFEC0) &
@@ -1313,8 +1324,16 @@ static const struct drm_encoder_helper_funcs 
vc4_dsi_encoder_helper_funcs = {
.mode_fixup = vc4_dsi_encoder_mode_fixup,
 };
 
+static const struct vc4_dsi_variant bcm2835_dsi1_variant = {
+   .port   = 1,
+   .broken_axi_workaround  = true,
+   .debugfs_name   = "dsi1_regs",
+   .regs   = dsi1_regs,
+   .nregs  = ARRAY_SIZE(dsi1_regs),
+};
+
 static const struct of_device_id vc4_dsi_dt_match[] = {
-   { .compatible = "brcm,bcm2835-dsi1", (void *)(uintptr_t)1 },
+   { .compatible = "brcm,bcm2835-dsi1", _dsi1_variant },
{}
 };
 
@@ -1325,7 +1344,7 @@ static void dsi_handle_error(struct vc4_dsi *dsi,
if (!(stat & bit))
return;
 
-   DRM_ERROR("DSI%d: %s error\n", dsi->port, type);
+   DRM_ERROR("DSI%d: %s error\n", dsi->variant->port, type);
*ret = IRQ_HANDLED;
 }
 

[PATCH v3 1/3] drm: bridge: cdns-mhdp8546: Modify atomic_get_input_bus_format bridge function

[Yuti Amonkar]

Modify atomic_get_input_bus_format function to return input formats
supported instead of using hardcoded value.

Signed-off-by: Yuti Amonkar 
---
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 83 +--
 1 file changed, 74 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index d0ed950f4f87..5ef6adb8bc82 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2095,27 +2095,92 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge *bridge)
return _mhdp_state->base;
 }
 
+#define MAX_INPUT_FORMAT 11
+
 static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
- struct drm_bridge_state *bridge_state,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state *conn_state,
- u32 output_fmt,
- unsigned int *num_input_fmts)
-{
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+   struct drm_connector *conn = conn_state->connector;
+   struct drm_display_info *info = >display_info;
u32 *input_fmts;
u32 default_bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
+   unsigned int i = 0;
 
*num_input_fmts = 0;
 
if (output_fmt != MEDIA_BUS_FMT_FIXED)
return NULL;
 
-   input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
+   input_fmts = kcalloc(MAX_INPUT_FORMAT,
+sizeof(*input_fmts), GFP_KERNEL);
if (!input_fmts)
return NULL;
 
-   *num_input_fmts = 1;
-   input_fmts[0] = default_bus_format;
+   input_fmts[i++] = default_bus_format;
+
+   if (info->color_formats & DRM_COLOR_FORMAT_RGB444) {
+   if (info->bpc == 16) {
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB161616_1X48;
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+   }
+
+   if (info->bpc == 12) {
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+   }
+
+   if (info->bpc == 10) {
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+   }
+
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+   }
+
+   if (info->color_formats & DRM_COLOR_FORMAT_YCRCB444) {
+   if (info->bpc == 16) {
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV16_1X48;
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36;
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+   }
+
+   if (info->bpc == 12) {
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36;
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+   }
+
+   if (info->bpc == 10) {
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+   }
+
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+   }
+
+   if (info->color_formats & DRM_COLOR_FORMAT_YCRCB422) {
+   if (info->bpc == 12) {
+   input_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24;
+   input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
+   input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
+   }
+
+   if (info->bpc == 10) {
+   input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
+   input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
+   }
+
+   input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
+   }
+
+   *num_input_fmts = i;
+
return input_fmts;
 }
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/5] thermal: devfreq_cooling: add new registration functions with Energy Model

[Daniel Lezcano]

On 18/11/2020 13:03, Lukasz Luba wrote:
> The Energy Model (EM) framework supports devices such as Devfreq. Create
> new registration functions which automatically register EM for the thermal
> devfreq_cooling devices. This patch prepares the code for coming changes
> which are going to replace old power model with the new EM.
> 
> Signed-off-by: Lukasz Luba 
> ---
>  drivers/thermal/devfreq_cooling.c | 99 ++-
>  include/linux/devfreq_cooling.h   | 22 +++
>  2 files changed, 120 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/devfreq_cooling.c 
> b/drivers/thermal/devfreq_cooling.c
> index 925523694462..b354271742c5 100644
> --- a/drivers/thermal/devfreq_cooling.c
> +++ b/drivers/thermal/devfreq_cooling.c
> @@ -50,6 +50,8 @@ static DEFINE_IDA(devfreq_ida);
>   * @capped_state:index to cooling state with in dynamic power budget
>   * @req_max_freq:PM QoS request for limiting the maximum frequency
>   *   of the devfreq device.
> + * @em:  Energy Model for the associated Devfreq device
> + * @em_registered:   Devfreq cooling registered the EM and should free it.
>   */
>  struct devfreq_cooling_device {
>   int id;
> @@ -63,6 +65,8 @@ struct devfreq_cooling_device {
>   u32 res_util;
>   int capped_state;
>   struct dev_pm_qos_request req_max_freq;
> + struct em_perf_domain *em;

This pointer is not needed, it is in the struct device.

> + bool em_registered;

The boolean em_registered is not needed because of the test in the
function em_dev_unregister_perf_domain():

if (IS_ERR_OR_NULL(dev) || !dev->em_pd)
return;

Logically if the 'em' was not initialized, it must be NULL, the
corresponding struct device was zero-allocated.


>  };
>  
>  static int devfreq_cooling_get_max_state(struct thermal_cooling_device *cdev,
> @@ -583,22 +587,115 @@ struct thermal_cooling_device 
> *devfreq_cooling_register(struct devfreq *df)
>  }
>  EXPORT_SYMBOL_GPL(devfreq_cooling_register);
>  
> +/**
> + * devfreq_cooling_em_register_power() - Register devfreq cooling device with
> + *   power information and attempt to register Energy Model (EM)
> + * @df:  Pointer to devfreq device.
> + * @dfc_power:   Pointer to devfreq_cooling_power.
> + * @em_cb:   Callback functions providing the data of the EM
> + *
> + * Register a devfreq cooling device and attempt to register Energy Model. 
> The
> + * available OPPs must be registered for the device.
> + *
> + * If @dfc_power is provided, the cooling device is registered with the
> + * power extensions. If @em_cb is provided it will be called for each OPP to
> + * calculate power value and cost. If @em_cb is not provided then simple 
> Energy
> + * Model is going to be used, which requires "dynamic-power-coefficient" a
> + * devicetree property.
> + */
> +struct thermal_cooling_device *
> +devfreq_cooling_em_register_power(struct devfreq *df,
> +   struct devfreq_cooling_power *dfc_power,
> +   struct em_data_callback *em_cb)
> +{
> + struct thermal_cooling_device *cdev;
> + struct devfreq_cooling_device *dfc;
> + struct device_node *np = NULL;
> + struct device *dev;
> + int nr_opp, ret;
> +
> + if (IS_ERR_OR_NULL(df))
> + return ERR_PTR(-EINVAL);
> +
> + dev = df->dev.parent;

Why the parent ?

> +
> + if (em_cb) {
> + nr_opp = dev_pm_opp_get_opp_count(dev);
> + if (nr_opp <= 0) {
> + dev_err(dev, "No valid OPPs found\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + ret = em_dev_register_perf_domain(dev, nr_opp, em_cb, NULL, 
> false);
> + } else {
> + ret = dev_pm_opp_of_register_em(dev, NULL);
> + }
> +
> + if (ret)
> + dev_warn(dev, "Unable to register EM for devfreq cooling device 
> (%d)\n",
> +  ret);
> +
> + if (dev->of_node)
> + np = of_node_get(dev->of_node);
> +
> + cdev = of_devfreq_cooling_register_power(np, df, dfc_power);
> +
> + if (np)
> + of_node_put(np);> +
> + if (IS_ERR_OR_NULL(cdev)) {
> + if (!ret)
> + em_dev_unregister_perf_domain(dev);
> + } else {
> + dfc = cdev->devdata;
> + dfc->em_registered = !ret;
> + }
> +
> + return cdev;
> +}
> +EXPORT_SYMBOL_GPL(devfreq_cooling_em_register_power);
> +
> +/**
> + * devfreq_cooling_em_register() - Register devfreq cooling device together
> + *   with Energy Model.
> + * @df:  Pointer to devfreq device.
> + * @em_cb:   Callback functions providing the data of the Energy Model
> + *
> + * This function attempts to register Energy Model for devfreq device and 
> then
> + * register the devfreq cooling device.
> + */
> +struct thermal_cooling_device *
> +devfreq_cooling_em_register(struct 

Re: [PATCH v2 2/5] thermal: devfreq_cooling: get a copy of device status

[Lukasz Luba]

On 12/3/20 1:09 PM, Daniel Lezcano wrote:

On 18/11/2020 13:03, Lukasz Luba wrote:

Devfreq cooling needs to now the correct status of the device in order
to operate. Do not rely on Devfreq last_status which might be a stale data
and get more up-to-date values of the load.

Devfreq framework can change the device status in the background. To
mitigate this situation make a copy of the status structure and use it
for internal calculations.

In addition this patch adds normalization function, which also makes sure
that whatever data comes from the device, it is in a sane range.

Signed-off-by: Lukasz Luba 
---
  drivers/thermal/devfreq_cooling.c | 52 +--
  1 file changed, 43 insertions(+), 9 deletions(-)

diff --git a/drivers/thermal/devfreq_cooling.c 
b/drivers/thermal/devfreq_cooling.c
index 659c0143c9f0..925523694462 100644
--- a/drivers/thermal/devfreq_cooling.c
+++ b/drivers/thermal/devfreq_cooling.c
@@ -227,20 +227,46 @@ static inline unsigned long get_total_power(struct 
devfreq_cooling_device *dfc,
   voltage);
  }
  
+static void _normalize_load(struct devfreq_dev_status *status)

+{
+   /* Make some space if needed */
+   if (status->busy_time > 0x) {
+   status->busy_time >>= 10;
+   status->total_time >>= 10;
+   }
+
+   if (status->busy_time > status->total_time)
+   status->busy_time = status->total_time;


How the condition above is possible?


They should, be checked by the driver, but I cannot trust
and have to check for all corner cases: (div by 0, overflow
one of them, etc). The busy_time and total_time are unsigned long,
which means 4B on 32bit machines.
If these values are coming from device counters, which count every
busy cycle and total cycles of a clock of a device running at e.g.
1GHz they would overflow every ~4s.

Normally IPA polling are 1s and 100ms, it's platform specific. But there
are also 'empty' periods when IPA sees temperature very low and does not
even call the .get_requested_power() callbacks for the cooling devices,
just grants max freq to all. This is problematic. I am investigating it
and will propose a solution for IPA soon.

I would avoid all of this if devfreq core would have default for all
devices a reliable polling timer... Let me check some possibilities also
for this case.




+   status->busy_time *= 100;
+   status->busy_time /= status->total_time ? : 1;
+
+   /* Avoid division by 0 */
+   status->busy_time = status->busy_time ? : 1;
+   status->total_time = 100;


Why not base the normalization on 1024? and use an intermediate u64.


You are the 2nd reviewer who is asking this. I tried to keep 'load' as
in range [0, 100] since we also have 'load' in cpufreq cooling in this
range. Maybe I should switch to 1024 (Ionela was also asking for this).



For example:

static u32 _normalize_load(struct devfreq_dev_status *status)
{
u64 load = 0;

/* Prevent divison by zero */
if (!status->busy_time)
return 0;

/*
 * Assuming status->total_time is always greater or equal
 * to status->busy_time, it can not be equal to zero because
 * of the test above
 */
load = status->busy_time * 1024;
load /= status->total_time;


I wanted to avoid any divisions which involve 64bit var on 32bit
machine.



/*
 * load is always [1..1024[, so it can not be truncated by a
 * u64 -> u32 coercive cast
 */
return (u32)load;
}



+}
  
  static int devfreq_cooling_get_requested_power(struct thermal_cooling_device *cdev,

   u32 *power)
  {
struct devfreq_cooling_device *dfc = cdev->devdata;
struct devfreq *df = dfc->devfreq;
-   struct devfreq_dev_status *status = >last_status;
+   struct devfreq_dev_status status;
unsigned long state;
-   unsigned long freq = status->current_frequency;
+   unsigned long freq;
unsigned long voltage;
u32 dyn_power = 0;
u32 static_power = 0;
int res;
  
+	mutex_lock(>lock);

+   res = df->profile->get_dev_status(df->dev.parent, );
+   mutex_unlock(>lock);
+   if (res)
+   return res;
+
+   freq = status.current_frequency;
+
state = freq_get_state(dfc, freq);
if (state == THERMAL_CSTATE_INVALID) {
res = -EAGAIN;
@@ -268,16 +294,18 @@ static int devfreq_cooling_get_requested_power(struct 
thermal_cooling_device *cd
} else {
dyn_power = dfc->power_table[state];
  
+		_normalize_load();


load = _normalize_load();


+
/* Scale dynamic power for utilization */
-   dyn_power *= status->busy_time;
-   dyn_power /= status->total_time;
+   dyn_power *= status.busy_time;
+   dyn_power /= 

[PATCH 2/2] drm/hisilicon: Deletted unused local parameters

[Tian Tao]

deletted unused variable ‘priv’.

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 04fee18..8a04014 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -237,12 +237,9 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
 
 static int hibmc_unload(struct drm_device *dev)
 {
-   struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
-
drm_atomic_helper_shutdown(dev);
-
pci_disable_msi(dev->pdev);
-   dev->dev_private = NULL;
+
return 0;
 }
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/hisilicon: Delete the entire file hibmc_ttm.c

[Tian Tao]

Delete the entire file hibmc_ttm.c. drmm_vram_helper_init() can be
called directly from hibmc_load(). hibmc_dumb_create() and
hibmc_mode_funcs can go to hibmc_drm_drv.c

v2:
change Deletted to Delete

Signed-off-by: Tian Tao 
Reviewed-by: Thomas Zimmermann 
---
 drivers/gpu/drm/hisilicon/hibmc/Makefile|  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 21 ++-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h |  4 --
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 50 -
 4 files changed, 20 insertions(+), 57 deletions(-)
 delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile 
b/drivers/gpu/drm/hisilicon/hibmc/Makefile
index 684ef79..d25c75e 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
+++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
-hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_ttm.o 
hibmc_drm_i2c.o
+hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_drm_i2c.o
 
 obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc-drm.o
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 5aea2e9..3687753 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -43,6 +44,12 @@ static irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+static int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
+struct drm_mode_create_dumb *args)
+{
+   return drm_gem_vram_fill_create_dumb(file, dev, 0, 128, args);
+}
+
 static const struct drm_driver hibmc_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops   = _fops,
@@ -77,6 +84,13 @@ static const struct dev_pm_ops hibmc_pm_ops = {
hibmc_pm_resume)
 };
 
+static const struct drm_mode_config_funcs hibmc_mode_funcs = {
+   .mode_valid = drm_vram_helper_mode_valid,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+   .fb_create = drm_gem_fb_create,
+};
+
 static int hibmc_kms_init(struct hibmc_drm_private *priv)
 {
struct drm_device *dev = >dev;
@@ -262,9 +276,12 @@ static int hibmc_load(struct drm_device *dev)
if (ret)
goto err;
 
-   ret = hibmc_mm_init(priv);
-   if (ret)
+   ret = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
+   priv->fb_size);
+   if (ret) {
+   drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
goto err;
+   }
 
ret = hibmc_kms_init(priv);
if (ret)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 2786de5..a49c10e 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -64,10 +64,6 @@ int hibmc_de_init(struct hibmc_drm_private *priv);
 int hibmc_vdac_init(struct hibmc_drm_private *priv);
 
 int hibmc_mm_init(struct hibmc_drm_private *hibmc);
-int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
- struct drm_mode_create_dumb *args);
 int hibmc_ddc_create(struct drm_device *drm_dev, struct hibmc_connector 
*connector);
 
-extern const struct drm_mode_config_funcs hibmc_mode_funcs;
-
 #endif
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
deleted file mode 100644
index 892d566..000
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ /dev/null
@@ -1,50 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/* Hisilicon Hibmc SoC drm driver
- *
- * Based on the bochs drm driver.
- *
- * Copyright (c) 2016 Huawei Limited.
- *
- * Author:
- * Rongrong Zou 
- * Rongrong Zou 
- * Jianhua Li 
- */
-
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "hibmc_drm_drv.h"
-
-int hibmc_mm_init(struct hibmc_drm_private *hibmc)
-{
-   int ret;
-   struct drm_device *dev = >dev;
-
-   ret = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
-   hibmc->fb_size);
-   if (ret) {
-   drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
-   return ret;
-   }
-
-   return 0;
-}
-
-int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
- struct drm_mode_create_dumb *args)
-{
-   return drm_gem_vram_fill_create_dumb(file, dev, 0, 128, args);
-}
-
-const struct drm_mode_config_funcs hibmc_mode_funcs = {
-   .mode_valid = drm_vram_helper_mode_valid,
-   .atomic_check = drm_atomic_helper_check,
-   

[PATCH 4/4] phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support

[Liu Ying]

i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
either a MIPI DSI display or a LVDS display.  The PHY mode is controlled
by SCU firmware and the driver would call a SCU firmware function to
configure the PHY mode.  The single LVDS PHY has 4 data lanes to support
a LVDS display.  Also, with a master LVDS PHY and a slave LVDS PHY, they
may work together to support a LVDS display with 8 data lanes(usually, dual
LVDS link display).  Note that this patch supports the LVDS PHY mode only
for the i.MX8qxp Mixel combo PHY, i.e., the MIPI DPHY mode is yet to be
supported, so for now error would be returned from ->set_mode() if MIPI
DPHY mode is passed over to it for the combo PHY.

Cc: Guido Günther 
Cc: Robert Chiras 
Cc: Kishon Vijay Abraham I 
Cc: Vinod Koul 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Signed-off-by: Liu Ying 
---
 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266 -
 1 file changed, 255 insertions(+), 11 deletions(-)

diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c 
b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
index a95572b..37084a9 100644
--- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
+++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
@@ -4,17 +4,31 @@
  * Copyright 2019 Purism SPC
  */
 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+
+/* Control and Status Registers(CSR) */
+#define PHY_CTRL   0x00
+#define  CCM_MASK  GENMASK(7, 5)
+#define  CCM(n)FIELD_PREP(CCM_MASK, (n))
+#define  CA_MASK   GENMASK(4, 2)
+#define  CA(n) FIELD_PREP(CA_MASK, (n))
+#define  RFB   BIT(1)
+#define  LVDS_EN   BIT(0)
 
 /* DPHY registers */
 #define DPHY_PD_DPHY   0x00
@@ -55,8 +69,15 @@
 #define PWR_ON 0
 #define PWR_OFF1
 
+#define MIN_VCO_FREQ 64000
+#define MAX_VCO_FREQ 15
+
+#define MIN_LVDS_REFCLK_FREQ 2400
+#define MAX_LVDS_REFCLK_FREQ 15000
+
 enum mixel_dphy_devtype {
MIXEL_IMX8MQ,
+   MIXEL_IMX8QXP,
 };
 
 struct mixel_dphy_devdata {
@@ -65,6 +86,7 @@ struct mixel_dphy_devdata {
u8 reg_rxlprp;
u8 reg_rxcdrp;
u8 reg_rxhs_settle;
+   bool is_combo;  /* MIPI DPHY and LVDS PHY combo */
 };
 
 static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
@@ -74,6 +96,10 @@ static const struct mixel_dphy_devdata mixel_dphy_devdata[] 
= {
.reg_rxlprp = 0x40,
.reg_rxcdrp = 0x44,
.reg_rxhs_settle = 0x48,
+   .is_combo = false,
+   },
+   [MIXEL_IMX8QXP] = {
+   .is_combo = true,
},
 };
 
@@ -95,8 +121,12 @@ struct mixel_dphy_cfg {
 struct mixel_dphy_priv {
struct mixel_dphy_cfg cfg;
struct regmap *regmap;
+   struct regmap *lvds_regmap;
struct clk *phy_ref_clk;
const struct mixel_dphy_devdata *devdata;
+   struct imx_sc_ipc *ipc_handle;
+   bool is_slave;
+   int id;
 };
 
 static const struct regmap_config mixel_dphy_regmap_config = {
@@ -317,7 +347,8 @@ static int mixel_dphy_set_pll_params(struct phy *phy)
return 0;
 }
 
-static int mixel_dphy_configure(struct phy *phy, union phy_configure_opts 
*opts)
+static int
+mixel_dphy_configure_mipi_dphy(struct phy *phy, union phy_configure_opts *opts)
 {
struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
struct mixel_dphy_cfg cfg = { 0 };
@@ -345,15 +376,118 @@ static int mixel_dphy_configure(struct phy *phy, union 
phy_configure_opts *opts)
return 0;
 }
 
+static int
+mixel_dphy_configure_lvds_phy(struct phy *phy, union phy_configure_opts *opts)
+{
+   struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
+   struct phy_configure_opts_lvds *lvds_opts = >lvds;
+   unsigned long data_rate;
+   unsigned long fvco;
+   u32 rsc;
+   u32 co;
+   int ret;
+
+   priv->is_slave = lvds_opts->is_slave;
+
+   /* LVDS interface pins */
+   regmap_write(priv->lvds_regmap, PHY_CTRL, CCM(0x5) | CA(0x4) | RFB);
+
+   /* enable MODE8 only for slave LVDS PHY */
+   rsc = priv->id ? IMX_SC_R_MIPI_1 : IMX_SC_R_MIPI_0;
+   ret = imx_sc_misc_set_control(priv->ipc_handle, rsc, IMX_SC_C_DUAL_MODE,
+ lvds_opts->is_slave);
+   if (ret) {
+   dev_err(>dev, "Failed to configure MODE8: %d\n", ret);
+   return ret;
+   }
+
+   /*
+* Choose an appropriate divider ratio to meet the requirement of
+* PLL VCO frequency range.
+*
+*  -  640MHz ~ 1500MHz     ---
+* | VCO | > | CO divider | -> | LVDS data rate|
+*  -   

[PATCH] drm: Allow drm_fourcc.h without including drm.h

[James Park]

Add DRM_FOURCC_STANDALONE guard to skip drm.h dependency.

This will allow Mesa to port code to Windows more easily.

Signed-off-by: James Park 

James Park (1):
  drm: Allow drm_fourcc.h without including drm.h

 include/uapi/drm/drm_fourcc.h | 6 ++
 1 file changed, 6 insertions(+)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel