Re: [PATCH] drm/docs: Fix usage stats typos

2023-04-17 Thread Rodrigo Vivi
On Mon, Apr 17, 2023 at 01:06:56PM -0700, Rob Clark wrote:
> From: Rob Clark 
> 
> Fix a couple missing ':'s.
> 
> Signed-off-by: Rob Clark 

Reviewed-by: Rodrigo Vivi 

> ---
>  Documentation/gpu/drm-usage-stats.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-usage-stats.rst 
> b/Documentation/gpu/drm-usage-stats.rst
> index b46327356e80..72d069e5dacb 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -105,7 +105,7 @@ object belong to this client, in the respective memory 
> region.
>  Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
>  indicating kibi- or mebi-bytes.
>  
> -- drm-cycles- 
> +- drm-cycles-: 
>  
>  Engine identifier string must be the same as the one specified in the
>  drm-engine- tag and shall contain the number of busy cycles for the 
> given
> @@ -117,7 +117,7 @@ larger value within a reasonable period. Upon observing a 
> value lower than what
>  was previously read, userspace is expected to stay with that larger previous
>  value until a monotonic update is seen.
>  
> -- drm-maxfreq-  [Hz|MHz|KHz]
> +- drm-maxfreq-:  [Hz|MHz|KHz]
>  
>  Engine identifier string must be the same as the one specified in the
>  drm-engine- tag and shall contain the maximum frequency for the given
> -- 
> 2.39.2
> 


RE: [PATCH v9 02/10] drm/hdcp: Avoid changing crtc state in hdcp atomic check

2023-04-17 Thread Kandpal, Suraj
> 
> From: Sean Paul 
> 
> Instead of forcing a modeset in the hdcp atomic check, rename to
> drm_hdcp_has_changed and return true if the content protection value is
> changing and let the driver decide whether a modeset is required or not.
> 
> Acked-by: Jani Nikula 
> Reviewed-by: Rodrigo Vivi 
> Signed-off-by: Sean Paul 
> Signed-off-by: Mark Yacoub 
> 
> ---
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -Rebase: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
> Changes in v7:
> -Renamed the function from drm_hdcp_atomic_check to
> drm_hdcp_has_changed (Dmitry Baryshkov)
> 
>  drivers/gpu/drm/display/drm_hdcp_helper.c   | 39 ++---
>  drivers/gpu/drm/i915/display/intel_atomic.c |  6 ++--
>  include/drm/display/drm_hdcp_helper.h   |  2 +-
>  3 files changed, 30 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
> b/drivers/gpu/drm/display/drm_hdcp_helper.c
> index 7ca390b3ea106..34baf2b97cd87 100644
> --- a/drivers/gpu/drm/display/drm_hdcp_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
> @@ -422,18 +422,21 @@ void drm_hdcp_update_content_protection(struct
> drm_connector *connector,
> EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> 
>  /**
> - * drm_hdcp_atomic_check - Helper for drivers to call during connector-
> >atomic_check
> + * drm_hdcp_has_changed - Helper for drivers to call during
> + connector->atomic_check
>   *
>   * @state: pointer to the atomic state being checked
>   * @connector: drm_connector on which content protection state needs an
> update
>   *
>   * This function can be used by display drivers to perform an atomic check
> on the
> - * hdcp state elements. If hdcp state has changed, this function will set
> - * mode_changed on the crtc driving the connector so it can update its
> hardware
> - * to match the hdcp state.
> + * hdcp state elements. If hdcp state has changed in a manner which
> + requires the
> + * driver to enable or disable content protection, this function will
> + return
> + * true.
> + *
> + * Returns:
> + * true if the driver must enable/disable hdcp, false otherwise
>   */
> -void drm_hdcp_atomic_check(struct drm_connector *connector,
> -struct drm_atomic_state *state)
> +bool drm_hdcp_has_changed(struct drm_connector *connector,
> +   struct drm_atomic_state *state)
>  {
>   struct drm_connector_state *new_conn_state, *old_conn_state;
>   struct drm_crtc_state *new_crtc_state; @@ -450,19 +453,31 @@
> void drm_hdcp_atomic_check(struct drm_connector *connector,
>* If the connector is being disabled with CP enabled, mark it
>* desired so it's re-enabled when the connector is brought
> back
>*/
> - if (old_hdcp ==
> DRM_MODE_CONTENT_PROTECTION_ENABLED)
> + if (old_hdcp ==
> DRM_MODE_CONTENT_PROTECTION_ENABLED) {
>   new_conn_state->content_protection =
> 
>   DRM_MODE_CONTENT_PROTECTION_DESIRED;
> - return;
> + return true;
> + }
> + return false;
>   }
> 
>   new_crtc_state =
>   drm_atomic_get_new_crtc_state(state, new_conn_state-
> >crtc);
>   if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
>   (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> -  new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
> +  new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
> {
>   new_conn_state->content_protection =
>   DRM_MODE_CONTENT_PROTECTION_DESIRED;
> + return true;
> + }
> +
> + /*
> +  * Coming back from UNDESIRED state, CRTC change or re-
> enablement requires
> +  * the driver to try CP enable.
> +  */
> + if (new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> + new_conn_state->crtc != old_conn_state->crtc)
> + return true;
> 
>   /*
>* Nothing to do if content type is unchanged and one of:
> @@ -477,9 +492,9 @@ void drm_hdcp_atomic_check(struct drm_connector
> *connector,
>new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
>   if (old_conn_state->hdcp_content_type ==
>   new_conn_state->hdcp_content_type)
> - return;
> + return false;
>   }
> 
> - new_crtc_state->mode_changed = true;
> + return true;
>  }

So previously in hdcp_atomic_check we decided if a mode change was required 
only after going through two different checks
if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
 (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
 new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))

and 

if (old_hdcp == new_hdcp ||
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
 new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||

Re: [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete

2023-04-17 Thread Rodrigo Vivi
On Mon, Apr 10, 2023 at 03:35:09PM -0700, Ashutosh Dixit wrote:
> Instead of erroring out when GuC reset is in progress, block waiting for
> GuC reset to complete which is a more reasonable uapi behavior.
> 
> v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo)
> 
> Signed-off-by: Ashutosh Dixit 
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c | 38 +++
>  1 file changed, 33 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9ab8971679fe3..8471a667dfc71 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -51,6 +51,7 @@ struct hwm_drvdata {
>   char name[12];
>   int gt_n;
>   bool reset_in_progress;
> + wait_queue_head_t waitq;
>  };
>  
>  struct i915_hwmon {
> @@ -395,16 +396,41 @@ hwm_power_max_read(struct hwm_drvdata *ddat, long *val)
>  static int
>  hwm_power_max_write(struct hwm_drvdata *ddat, long val)
>  {
> +#define GUC_RESET_TIMEOUT msecs_to_jiffies(2000)
> +
> + int ret = 0, timeout = GUC_RESET_TIMEOUT;
>   struct i915_hwmon *hwmon = ddat->hwmon;
>   intel_wakeref_t wakeref;
> - int ret = 0;
> + DEFINE_WAIT(wait);
>   u32 nval;
>  
> - mutex_lock(>hwmon_lock);
> - if (hwmon->ddat.reset_in_progress) {
> - ret = -EAGAIN;
> - goto unlock;
> + /* Block waiting for GuC reset to complete when needed */
> + for (;;) {
> + mutex_lock(>hwmon_lock);

I'm really afraid of how this mutex is handled with the wait queue.
some initial thought it looks like it is trying to reimplement ww_mutex?

all other examples of the wait_queue usages like this or didn't use
locks or had it in a total different flow that I could not correlate.

> +
> + prepare_to_wait(>waitq, , TASK_INTERRUPTIBLE);
> +
> + if (!hwmon->ddat.reset_in_progress)
> + break;

If this breaks we never unlock it?

> +
> + if (signal_pending(current)) {
> + ret = -EINTR;
> + break;
> + }
> +
> + if (!timeout) {
> + ret = -ETIME;
> + break;
> + }
> +
> + mutex_unlock(>hwmon_lock);

do we need to lock the signal pending and timeout as well?
or only wrapping it around the hwmon->ddat access would be
enough?

> +
> + timeout = schedule_timeout(timeout);
>   }
> + finish_wait(>waitq, );
> + if (ret)
> + goto unlock;
> +
>   wakeref = intel_runtime_pm_get(ddat->uncore->rpm);
>  
>   /* Disable PL1 limit and verify, because the limit cannot be disabled 
> on all platforms */
> @@ -508,6 +534,7 @@ void i915_hwmon_power_max_restore(struct drm_i915_private 
> *i915, bool old)
>   intel_uncore_rmw(hwmon->ddat.uncore, hwmon->rg.pkg_rapl_limit,
>PKG_PWR_LIM_1_EN, old ? PKG_PWR_LIM_1_EN : 0);
>   hwmon->ddat.reset_in_progress = false;
> + wake_up_all(>ddat.waitq);
>  
>   mutex_unlock(>hwmon_lock);
>  }
> @@ -784,6 +811,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
>   ddat->uncore = >uncore;
>   snprintf(ddat->name, sizeof(ddat->name), "i915");
>   ddat->gt_n = -1;
> + init_waitqueue_head(>waitq);
>  
>   for_each_gt(gt, i915, i) {
>   ddat_gt = hwmon->ddat_gt + i;
> -- 
> 2.38.0
> 


RE: [PATCH v9 01/10] drm/hdcp: Add drm_hdcp_atomic_check()

2023-04-17 Thread Kandpal, Suraj
Yacoub
> ; linux-ker...@vger.kernel.org
> Subject: [PATCH v9 01/10] drm/hdcp: Add drm_hdcp_atomic_check()
> 
> From: Sean Paul 
> 
> Move the hdcp atomic check from i915 to drm_hdcp so other drivers can use
> it. No functional changes, just cleaned up some of the code when moving it
> over.
> 
> Acked-by: Jani Nikula 
> Reviewed-by: Rodrigo Vivi 
> Reviewed-by: Dmitry Baryshkov 
> Signed-off-by: Sean Paul 
> Signed-off-by: Mark Yacoub 
> 
> ---
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -Rebase: move helper from drm_hdcp.c to drm_hdcp_helper.c Changes in
> v7:
> -Removed links to patch from commit msg (Dmitry Baryshkov)
> 
>  drivers/gpu/drm/display/drm_hdcp_helper.c   | 64
> +
>  drivers/gpu/drm/i915/display/intel_atomic.c |  4 +-
>  drivers/gpu/drm/i915/display/intel_hdcp.c   | 47 ---
>  drivers/gpu/drm/i915/display/intel_hdcp.h   |  3 -
>  include/drm/display/drm_hdcp_helper.h   |  3 +
>  5 files changed, 69 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
> b/drivers/gpu/drm/display/drm_hdcp_helper.c
> index e78999c72bd77..7ca390b3ea106 100644
> --- a/drivers/gpu/drm/display/drm_hdcp_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  static inline void drm_hdcp_print_ksv(const u8 *ksv)  { @@ -419,3 +420,66
> @@ void drm_hdcp_update_content_protection(struct drm_connector
> *connector,
>dev-
> >mode_config.content_protection_property);
>  }
>  EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> +
> +/**
> + * drm_hdcp_atomic_check - Helper for drivers to call during
> +connector->atomic_check
> + *
> + * @state: pointer to the atomic state being checked
> + * @connector: drm_connector on which content protection state needs an
> +update
> + *
> + * This function can be used by display drivers to perform an atomic
> +check on the
> + * hdcp state elements. If hdcp state has changed, this function will
> +set
> + * mode_changed on the crtc driving the connector so it can update its
> +hardware
> + * to match the hdcp state.
> + */
> +void drm_hdcp_atomic_check(struct drm_connector *connector,
> +struct drm_atomic_state *state)
> +{
> + struct drm_connector_state *new_conn_state, *old_conn_state;
> + struct drm_crtc_state *new_crtc_state;
> + u64 old_hdcp, new_hdcp;
> +
> + old_conn_state = drm_atomic_get_old_connector_state(state,
> connector);
> + old_hdcp = old_conn_state->content_protection;
> +
> + new_conn_state = drm_atomic_get_new_connector_state(state,
> connector);
> + new_hdcp = new_conn_state->content_protection;
> +

Nit: Why not assign these as right when they are declared we would end up using 
less lines

> + if (!new_conn_state->crtc) {
> + /*
> +  * If the connector is being disabled with CP enabled, mark it
> +  * desired so it's re-enabled when the connector is brought
> back
> +  */
> + if (old_hdcp ==
> DRM_MODE_CONTENT_PROTECTION_ENABLED)
> + new_conn_state->content_protection =
> +
>   DRM_MODE_CONTENT_PROTECTION_DESIRED;
> + return;
> + }
> +
> + new_crtc_state =
> + drm_atomic_get_new_crtc_state(state, new_conn_state-
> >crtc);
> + if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
> + (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> +  new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
> + new_conn_state->content_protection =
> + DRM_MODE_CONTENT_PROTECTION_DESIRED;
> +
> + /*
> +  * Nothing to do if content type is unchanged and one of:
> +  *  - state didn't change
> +  *  - HDCP was activated since the last commit
> +  *  - attempting to set to desired while already enabled
> +  */
> + if (old_hdcp == new_hdcp ||
> + (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> +  new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
> + (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> +  new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
> + if (old_conn_state->hdcp_content_type ==
> + new_conn_state->hdcp_content_type)
> + return;
> + }
> +
> + new_crtc_state->mode_changed = true;
> +}
> +EXPORT_SYMBOL(drm_hdcp_atomic_check);
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index a9a3f3715279d..e9d00b6a63d39 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "i915_drv.h"
>  #include "i915_reg.h"
> @@ -39,7 +40,6 @@
>  #include "intel_cdclk.h"
>  #include 

Re: [PATCH 4/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing

2023-04-17 Thread Adam Ford
On Mon, Apr 17, 2023 at 6:53 AM Adam Ford  wrote:
>
> On Mon, Apr 17, 2023 at 3:38 AM Lucas Stach  wrote:
> >
> > Hi Adam,
> >
> > Am Samstag, dem 15.04.2023 um 05:41 -0500 schrieb Adam Ford:
> > > NXP uses a lookup table to determine the various values for
> > > the PHY Timing based on the clock rate in their downstream
> > > kernel.  Since the input clock can be variable, the phy
> > > settings need to be variable too.  Add an additional variable
> > > to the driver data to enable this feature to prevent breaking
> > > boards that don't support it.
> > >
> >
> > I haven't checked if this generates values close to the ones in this
> > table, but I guess it should be worth a try to use
> > phy_mipi_dphy_get_default_config() instead.
>
> I didn't know that was a thing.  I like that idea much better than the
> table.  I just pulled what NXP had and tweaked it to fit the mainline.
> I'll give it a try in the next few days, when I have some more time.

I tried phy_mipi_dphy_get_default_config() and the function return
different values than what NXP's table returns, and the screen doesn't
sync properly.  I will try to figure out the mathematical calculation
to generate the values for this DSIM instead of using a lookup table.

adam
>
> adam
> >
> > Regards,
> > Lucas
> >
> > > Signed-off-by: Adam Ford 
> > > ---
> > >  drivers/gpu/drm/bridge/samsung-dsim.c |  85 +++--
> > >  drivers/gpu/drm/bridge/samsung-dsim.h | 254 ++
> > >  include/drm/bridge/samsung-dsim.h |   1 +
> > >  3 files changed, 326 insertions(+), 14 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.h
> > >
> 
> >


Re: [PATCH 3/6] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically

2023-04-17 Thread Adam Ford
On Sun, Apr 16, 2023 at 5:08 PM Marek Vasut  wrote:
>
> On 4/15/23 12:41, Adam Ford wrote:
> > Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
> > having an entry in the device tree for samsung,pll-clock-frequency.
> >
> > Signed-off-by: Adam Ford 
> > ---
> >   drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++--
> >   1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> > b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index 9fec32b44e05..73f0c3fbbdf5 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -1744,11 +1744,6 @@ static int samsung_dsim_parse_dt(struct samsung_dsim 
> > *dsi)
> >   struct device_node *node = dev->of_node;
> >   int ret;
> >
> > - ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
> > ->pll_clk_rate);
> > - if (ret < 0)
> > - return ret;
> > -
> >   ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
> >  >burst_clk_rate);
> >   if (ret < 0)
>
> Does this break compatibility with old samsung DTs ?

My goal here was to declutter the device tree stuff and fetch data
automatically if possible. What if I changed this to make them
optional?  If they exist, we can use them, if they don't exist, we
could read the clock rate.  Would that be acceptable?

adam


Re: [PATCH 1/3] drm/msm/dpu: Drop unused members from HW structs

2023-04-17 Thread Abhinav Kumar




On 4/17/2023 4:14 PM, Marijn Suijten wrote:

Some of these members were initialized while never read, while others
were not even assigned any value at all.  Drop them to save some space,
and above all confusion when looking at these members.

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Fixes: 84a33d0fd921 ("drm/msm/dpu: add dpu_hw_wb abstraction for writeback 
blocks")
Signed-off-by: Marijn Suijten 
---


It seems like WB UBWC formats are not supported today. Because otherwise 
ctx->mdp would be used for writeback. I guess we can add a ubwc member 
similar to hw_sspp, when we do add the support for this. Hence this is,



Reviewed-by: Abhinav Kumar 




Re: [PATCH v4 3/5] drm/tests: Add test cases for drm_rect_calc_vscale()

2023-04-17 Thread Arthur Grillo Queiroz Cabral



On 17/04/23 13:19, Maíra Canal wrote:
> On 4/6/23 08:53, Arthur Grillo wrote:
>> Insert parameterized test for the drm_rect_calc_vscale() to ensure
>> correctness and prevent future regressions. Besides the test for the
>> usual case, tests the exceptions.
>>
>> It uses the same struct from drm_rect_calc_hscale().
>>
>> Signed-off-by: Arthur Grillo 
>> ---
>>   drivers/gpu/drm/tests/drm_rect_test.c | 59 +++
>>   1 file changed, 59 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/tests/drm_rect_test.c 
>> b/drivers/gpu/drm/tests/drm_rect_test.c
>> index 44150545c1bc..a1fd9b2c5128 100644
>> --- a/drivers/gpu/drm/tests/drm_rect_test.c
>> +++ b/drivers/gpu/drm/tests/drm_rect_test.c
>> @@ -414,6 +414,64 @@ static void drm_test_rect_calc_hscale(struct kunit 
>> *test)
>>   KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
>>   }
>>   +static const struct drm_rect_scale_case drm_rect_vscale_cases[] = {
>> +{
>> +.name = "normal use",
>> +.src = DRM_RECT_INIT(0, 0, 0, 2 << 16),
>> +.dst = DRM_RECT_INIT(0, 0, 0, 1 << 16),
>> +.min_range = 0, .max_range = INT_MAX,
>> +.expected_scaling_factor = 2,
>> +},
>> +{
>> +.name = "out of max range",
>> +.src = DRM_RECT_INIT(0, 0, 0, 10 << 16),
>> +.dst = DRM_RECT_INIT(0, 0, 0, 1 << 16),
>> +.min_range = 3, .max_range = 5,
>> +.expected_scaling_factor = -ERANGE,
>> +},
>> +{
>> +.name = "out of min range",
>> +.src = DRM_RECT_INIT(0, 0, 0, 2 << 16),
>> +.dst = DRM_RECT_INIT(0, 0, 0, 1 << 16),
>> +.min_range = 3, .max_range = 5,
>> +.expected_scaling_factor = -ERANGE,
>> +},
>> +{
>> +.name = "zero dst height",
>> +.src = DRM_RECT_INIT(0, 0, 0, 2 << 16),
>> +.dst = DRM_RECT_INIT(0, 0, 0, 0 << 16),
>> +.min_range = 0, .max_range = INT_MAX,
>> +.expected_scaling_factor = 0,
>> +},
>> +{
>> +.name = "negative src height",
>> +.src = DRM_RECT_INIT(0, 0, 0, -(1 << 16)),
>> +.dst = DRM_RECT_INIT(0, 0, 0, 1 << 16),
>> +.min_range = 0, .max_range = INT_MAX,
>> +.expected_scaling_factor = -EINVAL,
>> +},
>> +{
>> +.name = "negative dst height",
>> +.src = DRM_RECT_INIT(0, 0, 0, 1 << 16),
>> +.dst = DRM_RECT_INIT(0, 0, 0, -(1 << 16)),
>> +.min_range = 0, .max_range = INT_MAX,
>> +.expected_scaling_factor = -EINVAL,
>> +},
>> +};
>> +
> 
> Would it possible to use the same parameter array for vscale and hscale?
> 
> Best Regards,
> - Maíra Canal
> 

Instead of having drm_rect directly, I could create an src and dst
length. Or maybe have drm_rects that increase on both sizes.

Regards,
~Arthur Grillo

>> +KUNIT_ARRAY_PARAM(drm_rect_vscale, drm_rect_vscale_cases, 
>> drm_rect_scale_case_desc);
>> +
>> +static void drm_test_rect_calc_vscale(struct kunit *test)
>> +{
>> +const struct drm_rect_scale_case *params = test->param_value;
>> +int scaling_factor;
>> +
>> +scaling_factor = drm_rect_calc_vscale(>src, >dst,
>> +  params->min_range, params->max_range);
>> +
>> +KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
>> +}
>> +
>>   static struct kunit_case drm_rect_tests[] = {
>>   KUNIT_CASE(drm_test_rect_clip_scaled_div_by_zero),
>>   KUNIT_CASE(drm_test_rect_clip_scaled_not_clipped),
>> @@ -421,6 +479,7 @@ static struct kunit_case drm_rect_tests[] = {
>>   KUNIT_CASE(drm_test_rect_clip_scaled_signed_vs_unsigned),
>>   KUNIT_CASE_PARAM(drm_test_rect_intersect, 
>> drm_rect_intersect_gen_params),
>>   KUNIT_CASE_PARAM(drm_test_rect_calc_hscale, 
>> drm_rect_hscale_gen_params),
>> +KUNIT_CASE_PARAM(drm_test_rect_calc_vscale, drm_rect_vscale_gen_params),
>>   { }
>>   };
>>   


Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Provide sysfs for efficient freq

2023-04-17 Thread Andi Shyti
Hi Vinay,

Looks good, just few minor comments below,

[...]

> @@ -267,13 +267,11 @@ static int run_test(struct intel_gt *gt, int test_type)
>   }
>  
>   /*
> -  * Set min frequency to RPn so that we can test the whole
> -  * range of RPn-RP0. This also turns off efficient freq
> -  * usage and makes results more predictable.
> +  * Turn off efficient freq so RPn/RP0 ranges are obeyed
>*/
> - err = slpc_set_min_freq(slpc, slpc->min_freq);
> + err = intel_guc_slpc_set_ignore_eff_freq(slpc, true);
>   if (err) {
> - pr_err("Unable to update min freq!");
> + pr_err("Unable to turn off efficient freq!");

drm_err()? or gt_err()? As we are here we can use a proper
printing.

How is this change related to the scope of this patch?

>   return err;
>   }
>  
> @@ -358,9 +356,10 @@ static int run_test(struct intel_gt *gt, int test_type)
>   break;
>   }
>  
> - /* Restore min/max frequencies */
> - slpc_set_max_freq(slpc, slpc_max_freq);
> + /* Restore min/max frequencies and efficient flag */
>   slpc_set_min_freq(slpc, slpc_min_freq);
> + slpc_set_max_freq(slpc, slpc_max_freq);
> + intel_guc_slpc_set_ignore_eff_freq(slpc, false);

mmhhh... do we care here about the return value?

>  
>   if (igt_flush_test(gt->i915))
>   err = -EIO;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> index 026d73855f36..b1b70ee3001b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> @@ -277,6 +277,7 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
>  
>   slpc->max_freq_softlimit = 0;
>   slpc->min_freq_softlimit = 0;
> + slpc->ignore_eff_freq = false;
>   slpc->min_is_rpmax = false;
>  
>   slpc->boost_freq = 0;
> @@ -457,6 +458,31 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc 
> *slpc, u32 *val)
>   return ret;
>  }
>  
> +int intel_guc_slpc_set_ignore_eff_freq(struct intel_guc_slpc *slpc, bool val)
> +{
> + struct drm_i915_private *i915 = slpc_to_i915(slpc);
> + intel_wakeref_t wakeref;
> + int ret = 0;

no need to initialize ret here.

> +
> + mutex_lock(>lock);
> + wakeref = intel_runtime_pm_get(>runtime_pm);
> +
> + ret = slpc_set_param(slpc,
> +  SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
> +  val);
> + if (ret) {
> + guc_probe_error(slpc_to_guc(slpc), "Failed to set efficient 
> freq(%d): %pe\n",
> + val, ERR_PTR(ret));
> + goto out;
> + }
> +
> + slpc->ignore_eff_freq = val;

nit that you can ignore: if you put this under else and save
brackets and a goto.

Andi


Re: [PATCH v3 1/6] drm/vkms: isolate pixel conversion functionality

2023-04-17 Thread Arthur Grillo Queiroz Cabral



On 17/04/23 09:10, Maíra Canal wrote:
> Currently, the pixel conversion functions repeat the same loop to
> iterate the rows. Instead of repeating the same code for each pixel
> format, create a function to wrap the loop and isolate the pixel
> conversion functionality.
> 
> Suggested-by: Arthur Grillo 
> Signed-off-by: Maíra Canal 

I really liked how simple the conversion function turned out :-).

Reviewed-by: Arthur Grillo 

Regards,
~Arthur Grillo

> ---
>  drivers/gpu/drm/vkms/vkms_composer.c |   4 +-
>  drivers/gpu/drm/vkms/vkms_drv.h  |   4 +-
>  drivers/gpu/drm/vkms/vkms_formats.c  | 125 +++
>  drivers/gpu/drm/vkms/vkms_formats.h  |   2 +-
>  drivers/gpu/drm/vkms/vkms_plane.c|   2 +-
>  5 files changed, 56 insertions(+), 81 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 8e53fa80742b..80164e79af00 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -99,7 +99,7 @@ static void blend(struct vkms_writeback_job *wb,
>   if (!check_y_limit(plane[i]->frame_info, y))
>   continue;
>  
> - plane[i]->plane_read(stage_buffer, 
> plane[i]->frame_info, y);
> + vkms_compose_row(stage_buffer, plane[i], y);
>   pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer,
>   output_buffer);
>   }
> @@ -118,7 +118,7 @@ static int check_format_funcs(struct vkms_crtc_state 
> *crtc_state,
>   u32 n_active_planes = crtc_state->num_active_planes;
>  
>   for (size_t i = 0; i < n_active_planes; i++)
> - if (!planes[i]->plane_read)
> + if (!planes[i]->pixel_read)
>   return -1;
>  
>   if (active_wb && !active_wb->wb_write)
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 4a248567efb2..f152d54baf76 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -56,8 +56,7 @@ struct vkms_writeback_job {
>  struct vkms_plane_state {
>   struct drm_shadow_plane_state base;
>   struct vkms_frame_info *frame_info;
> - void (*plane_read)(struct line_buffer *buffer,
> -const struct vkms_frame_info *frame_info, int y);
> + void (*pixel_read)(u8 *src_buffer, struct pixel_argb_u16 *out_pixel);
>  };
>  
>  struct vkms_plane {
> @@ -155,6 +154,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const 
> char *source_name,
>  /* Composer Support */
>  void vkms_composer_worker(struct work_struct *work);
>  void vkms_set_composer(struct vkms_output *out, bool enabled);
> +void vkms_compose_row(struct line_buffer *stage_buffer, struct 
> vkms_plane_state *plane, int y);
>  
>  /* Writeback */
>  int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c 
> b/drivers/gpu/drm/vkms/vkms_formats.c
> index d4950688b3f1..bd542fd00698 100644
> --- a/drivers/gpu/drm/vkms/vkms_formats.c
> +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> @@ -42,100 +42,75 @@ static void *get_packed_src_addr(const struct 
> vkms_frame_info *frame_info, int y
>   return packed_pixels_addr(frame_info, x_src, y_src);
>  }
>  
> -static void ARGB_to_argb_u16(struct line_buffer *stage_buffer,
> -  const struct vkms_frame_info *frame_info, int 
> y)
> +static void ARGB_to_argb_u16(u8 *src_pixels, struct pixel_argb_u16 
> *out_pixel)
>  {
> - struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
> - u8 *src_pixels = get_packed_src_addr(frame_info, y);
> - int x_limit = min_t(size_t, drm_rect_width(_info->dst),
> - stage_buffer->n_pixels);
> -
> - for (size_t x = 0; x < x_limit; x++, src_pixels += 4) {
> - /*
> -  * The 257 is the "conversion ratio". This number is obtained 
> by the
> -  * (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries 
> to get
> -  * the best color value in a pixel format with more 
> possibilities.
> -  * A similar idea applies to others RGB color conversions.
> -  */
> - out_pixels[x].a = (u16)src_pixels[3] * 257;
> - out_pixels[x].r = (u16)src_pixels[2] * 257;
> - out_pixels[x].g = (u16)src_pixels[1] * 257;
> - out_pixels[x].b = (u16)src_pixels[0] * 257;
> - }
> + /*
> +  * The 257 is the "conversion ratio". This number is obtained by the
> +  * (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries to get
> +  * the best color value in a pixel format with more possibilities.
> +  * A similar idea applies to others RGB color conversions.
> +  */
> + out_pixel->a = (u16)src_pixels[3] * 257;
> + out_pixel->r = (u16)src_pixels[2] * 257;
> + out_pixel->g = 

Re: [PATCH] drm/ast: Fix ARM compatibility

2023-04-17 Thread Jammy Huang

Hi Thomas,

The Intel(x86) CPUs have a separate address space for "IO", but the ARM 
architecture only has "memory", so all IO devices are accessed as if 
they were memory. Which means ARM does not support isolated IO. Here is 
a related discussion on ARM's forum.


https://community.arm.com/support-forums/f/architectures-and-processors-forum/52046/how-to-read-write-an-i-o-port-in-aarch64

Thus, we want to adapt MMIO only after this patch.

On 2023/4/17 下午 07:51, Thomas Zimmermann wrote:

Hi

Am 07.04.23 um 04:09 schrieb Jammy Huang:

Hi Thomas,

Could you help review this patch??

We met some problem on nvidia's ARM platfrom and need this patch to 
fix it.


On 2023/3/2 上午 10:19, Jammy Huang wrote:
ARM architecture only has 'memory', so all devices are accessed by 
MMIO.


Signed-off-by: Jammy Huang 
---
  drivers/gpu/drm/ast/ast_main.c | 17 +
  1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_main.c 
b/drivers/gpu/drm/ast/ast_main.c

index 794ffd4a29c5..f86d01e9f024 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -424,22 +424,7 @@ struct ast_device *ast_device_create(const 
struct drm_driver *drv,

  if (!ast->regs)
  return ERR_PTR(-EIO);
-    /*
- * If we don't have IO space at all, use MMIO now and
- * assume the chip has MMIO enabled by default (rev 0x20
- * and higher).
- */
-    if (!(pci_resource_flags(pdev, 2) & IORESOURCE_IO)) {
-    drm_info(dev, "platform has no IO space, trying MMIO\n");
-    ast->ioregs = ast->regs + AST_IO_MM_OFFSET;
-    }
-
-    /* "map" IO regs if the above hasn't done so already */
-    if (!ast->ioregs) {
-    ast->ioregs = pcim_iomap(pdev, 2, 0);


What happens on systems that use this branch?

Best regards
Thomas


-    if (!ast->ioregs)
-    return ERR_PTR(-EIO);
-    }
+    ast->ioregs = ast->regs + AST_IO_MM_OFFSET;
  ast_detect_chip(dev, _post);

base-commit: 254986e324add8a30d0019c6da59f81adc8b565f





--
Best Regards
Jammy


Re: [PATCH 01/27] dt-bindings: pwm: Add compatible for MediaTek MT6795

2023-04-17 Thread Rob Herring
On Thu, Apr 13, 2023 at 10:52:28AM +0200, Matthias Brugger wrote:
> 
> 
> On 12/04/2023 23:03, Rob Herring wrote:
> > 
> > On Wed, 12 Apr 2023 13:27:13 +0200, AngeloGioacchino Del Regno wrote:
> > > Add a compatible string for MediaTek Helio X10 MT6795's display PWM
> > > block: this is the same as MT8173.
> > > 
> > > Signed-off-by: AngeloGioacchino Del Regno 
> > > 
> > > ---
> > >   Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 4 +++-
> > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > 
> > Running 'make dtbs_check' with the schema in this patch gives the
> > following warnings. Consider if they are expected or the schema is
> > incorrect. These may not be new warnings.
> > 
> 
> These are not new warnings. I think we should address them in a different
> patch. In my opinion it shouldn't block this patch. In the end it only add
> as compatible here.

I disagree if it's the schema that needs fixing. From the looks of 
it, I'd say it's probably at least some schema fixes needed.

> 
> Regards,
> Matthias
> 
> > Note that it is not yet a requirement to have 0 warnings for dtbs_check.
> > This will change in the future.
> > 
> > Full log is available here: 
> > https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230412112739.160376-2-angelogioacchino.delre...@collabora.com
> > 
> > 
> > pwm@1100e000: 'power-domains' does not match any of the regexes: 
> > 'pinctrl-[0-9]+'

Are you saying the MT6795 has no power-domains?

> > arch/arm64/boot/dts/mediatek/mt8183-evb.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-cozmo.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel14.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel14-sku2.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku1.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku6.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku7.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper-sku16.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu-sku22.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dtb
> > arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dtb
> > 
> > pwm@1400a000: compatible: 'oneOf' conditional failed, one must be fixed:
> > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dtb
> > arch/arm/boot/dts/mt7623n-rfb-emmc.dtb
> > 
> > pwm@1401e000: compatible: 'oneOf' conditional failed, one must be fixed:
> > arch/arm64/boot/dts/mediatek/mt8173-elm.dtb
> > arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtb
> > arch/arm64/boot/dts/mediatek/mt8173-elm-hana-rev7.dtb
> > arch/arm64/boot/dts/mediatek/mt8173-evb.dtb
> > 
> > pwm@1401f000: compatible: 'oneOf' conditional failed, one must be fixed:
> > arch/arm64/boot/dts/mediatek/mt8173-elm.dtb
> > arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtb
> > arch/arm64/boot/dts/mediatek/mt8173-elm-hana-rev7.dtb
> > arch/arm64/boot/dts/mediatek/mt8173-evb.dtb

The commit message says the MT6795 is the same as the MT8173. Which is 
wrong here, the dtb or the schema? 

Rob


Re: [PATCH 01/11] drm/ast: Use drm_aperture_remove_conflicting_pci_framebuffers

2023-04-17 Thread Jammy Huang

Hi Thomas,

The Intel(x86) CPUs have a separate address space for "IO", but the ARM 
architecture only has "memory", so all IO devices are accessed as if 
they were memory. Which means ARM does not support isolated IO. Here is 
a related discussion on ARM's forum.


https://community.arm.com/support-forums/f/architectures-and-processors-forum/52046/how-to-read-write-an-i-o-port-in-aarch64

Thus, we adapt MMIO only after this patch.


On 2023/4/4 下午 10:45, Thomas Zimmermann wrote:

Hi,

FYI I have merged patches 1, 6 and 7 of this patchset. They look fine 
and are worthwhile fixes on their own.


Best regards
Thomas

Am 11.01.23 um 16:41 schrieb Daniel Vetter:

It's just open coded and matches.

Note that Thomas said that his version apparently failed for some
reason, but hey maybe we should try again.

Signed-off-by: Daniel Vetter 
Cc: Dave Airlie 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
---
  drivers/gpu/drm/ast/ast_drv.c | 16 +---
  1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.c 
b/drivers/gpu/drm/ast/ast_drv.c

index 420fc75c240e..3ac24a780f50 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -90,27 +90,13 @@ static const struct pci_device_id ast_pciidlist[] 
= {

    MODULE_DEVICE_TABLE(pci, ast_pciidlist);
  -static int ast_remove_conflicting_framebuffers(struct pci_dev *pdev)
-{
-    bool primary = false;
-    resource_size_t base, size;
-
-    base = pci_resource_start(pdev, 0);
-    size = pci_resource_len(pdev, 0);
-#ifdef CONFIG_X86
-    primary = pdev->resource[PCI_ROM_RESOURCE].flags & 
IORESOURCE_ROM_SHADOW;

-#endif
-
-    return drm_aperture_remove_conflicting_framebuffers(base, size, 
primary, _driver);

-}
-
  static int ast_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)

  {
  struct ast_private *ast;
  struct drm_device *dev;
  int ret;
  -    ret = ast_remove_conflicting_framebuffers(pdev);
+    ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
_driver);

  if (ret)
  return ret;



--
Best Regards
Jammy



[PATCH] drm/i915/guc/slpc: Provide sysfs for efficient freq

2023-04-17 Thread Vinay Belgaumkar
SLPC enables use of efficient freq at init by default. It is
possible for GuC to request frequencies that are higher than
the 'software' max if user has set it lower than the efficient
level.

Scenarios/tests that require strict fixing of freq below the efficient
level will need to disable it through this interface.

v2: Keep just one interface to toggle sysfs. With this, user will
be completely responsible for toggling efficient frequency if need
be. There will be no implicit disabling when user sets min < RP1 (Ashutosh)

v3: Remove unused label, review comments (Ashutosh)

v4: Toggle efficient freq usage in SLPC selftest and checkpatch fixes

Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency")
Signed-off-by: Vinay Belgaumkar 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 35 
 drivers/gpu/drm/i915/gt/selftest_slpc.c   | 13 +++---
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   | 40 ++-
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h   |  1 +
 .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h |  1 +
 5 files changed, 72 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 28f27091cd3b..ee2b44f896a2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -451,6 +451,33 @@ static ssize_t punit_req_freq_mhz_show(struct kobject 
*kobj,
return sysfs_emit(buff, "%u\n", preq);
 }
 
+static ssize_t slpc_ignore_eff_freq_show(struct kobject *kobj,
+struct kobj_attribute *attr,
+char *buff)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+   struct intel_guc_slpc *slpc = >uc.guc.slpc;
+
+   return sysfs_emit(buff, "%u\n", slpc->ignore_eff_freq);
+}
+
+static ssize_t slpc_ignore_eff_freq_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buff, size_t count)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+   struct intel_guc_slpc *slpc = >uc.guc.slpc;
+   int err;
+   u32 val;
+
+   err = kstrtou32(buff, 0, );
+   if (err)
+   return err;
+
+   err = intel_guc_slpc_set_ignore_eff_freq(slpc, val);
+   return err ?: count;
+}
+
 struct intel_gt_bool_throttle_attr {
struct attribute attr;
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
@@ -663,6 +690,8 @@ static struct kobj_attribute attr_media_freq_factor_scale =
 INTEL_GT_ATTR_RO(media_RP0_freq_mhz);
 INTEL_GT_ATTR_RO(media_RPn_freq_mhz);
 
+INTEL_GT_ATTR_RW(slpc_ignore_eff_freq);
+
 static const struct attribute *media_perf_power_attrs[] = {
_media_freq_factor.attr,
_media_freq_factor_scale.attr,
@@ -744,6 +773,12 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct 
kobject *kobj)
if (ret)
gt_warn(gt, "failed to create punit_req_freq_mhz sysfs (%pe)", 
ERR_PTR(ret));
 
+   if (intel_uc_uses_guc_slpc(>uc)) {
+   ret = sysfs_create_file(kobj, _slpc_ignore_eff_freq.attr);
+   if (ret)
+   gt_warn(gt, "failed to create ignore_eff_freq sysfs 
(%pe)", ERR_PTR(ret));
+   }
+
if (i915_mmio_reg_valid(intel_gt_perf_limit_reasons_reg(gt))) {
ret = sysfs_create_files(kobj, throttle_reason_attrs);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c 
b/drivers/gpu/drm/i915/gt/selftest_slpc.c
index bd44ce73a504..0de44db34d27 100644
--- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
@@ -267,13 +267,11 @@ static int run_test(struct intel_gt *gt, int test_type)
}
 
/*
-* Set min frequency to RPn so that we can test the whole
-* range of RPn-RP0. This also turns off efficient freq
-* usage and makes results more predictable.
+* Turn off efficient freq so RPn/RP0 ranges are obeyed
 */
-   err = slpc_set_min_freq(slpc, slpc->min_freq);
+   err = intel_guc_slpc_set_ignore_eff_freq(slpc, true);
if (err) {
-   pr_err("Unable to update min freq!");
+   pr_err("Unable to turn off efficient freq!");
return err;
}
 
@@ -358,9 +356,10 @@ static int run_test(struct intel_gt *gt, int test_type)
break;
}
 
-   /* Restore min/max frequencies */
-   slpc_set_max_freq(slpc, slpc_max_freq);
+   /* Restore min/max frequencies and efficient flag */
slpc_set_min_freq(slpc, slpc_min_freq);
+   slpc_set_max_freq(slpc, slpc_max_freq);
+   intel_guc_slpc_set_ignore_eff_freq(slpc, false);
 
if (igt_flush_test(gt->i915))
err = 

[PATCH v5] drm/i915: Make IRQ reset and postinstall multi-gt aware

2023-04-17 Thread Andi Shyti
In multi-gt systems IRQs need to be reset and enabled per GT.

This might add some redundancy when handling interrupts for
engines that might not exist in every tile, but helps to keep the
code cleaner and more understandable.

Signed-off-by: Andi Shyti 
Cc: Tvrtko Ursulin 
Reviewed-by: Matt Roper 
---
Hi,

thanks Matt for the review.

Andi

Changelog
=
v4 -> v5
 - Another little cosmetic on the variable declaration. Go back
   to v3 but using "_priv->uncore" instead of
   "to_gt(dev_priv)->uncore", which is much cleaner.
 - Add Matt's r-b.
v3 -> v4
 - do not change the initial gt and uncore initialization in
   order to gain a better understanding at a glance of the
   purpose of all the local variables.
v2 -> v3
 - keep GUnit irq initialization out of the for_each_gt() loop as
   the media GT doesn't have a GUnit.
v1 -> v2
 - improve description in the commit log.

 drivers/gpu/drm/i915/i915_irq.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

 drivers/gpu/drm/i915/i915_irq.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dea1a117f3fa1..eead067f18c7a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2856,12 +2856,15 @@ static void gen11_irq_reset(struct drm_i915_private 
*dev_priv)
 
 static void dg1_irq_reset(struct drm_i915_private *dev_priv)
 {
-   struct intel_gt *gt = to_gt(dev_priv);
-   struct intel_uncore *uncore = gt->uncore;
+   struct intel_uncore *uncore = _priv->uncore;
+   struct intel_gt *gt;
+   unsigned int i;
 
dg1_master_intr_disable(dev_priv->uncore.regs);
 
-   gen11_gt_irq_reset(gt);
+   for_each_gt(gt, dev_priv, i)
+   gen11_gt_irq_reset(gt);
+
gen11_display_irq_reset(dev_priv);
 
GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
@@ -3643,11 +3646,13 @@ static void gen11_irq_postinstall(struct 
drm_i915_private *dev_priv)
 
 static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
 {
-   struct intel_gt *gt = to_gt(dev_priv);
-   struct intel_uncore *uncore = gt->uncore;
+   struct intel_uncore *uncore = _priv->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+   struct intel_gt *gt;
+   unsigned int i;
 
-   gen11_gt_irq_postinstall(gt);
+   for_each_gt(gt, dev_priv, i)
+   gen11_gt_irq_postinstall(gt);
 
GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
 
-- 
2.39.2



Re: [Intel-gfx] [PATCH v3] drm/i915/guc/slpc: Provide sysfs for efficient freq

2023-04-17 Thread Belgaumkar, Vinay



On 4/14/2023 4:49 PM, Dixit, Ashutosh wrote:

On Fri, 14 Apr 2023 15:34:15 -0700, Vinay Belgaumkar wrote:

@@ -457,6 +458,34 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc 
*slpc, u32 *val)
return ret;
  }

+int intel_guc_slpc_set_ignore_eff_freq(struct intel_guc_slpc *slpc, bool val)
+{
+   struct drm_i915_private *i915 = slpc_to_i915(slpc);
+   intel_wakeref_t wakeref;
+   int ret = 0;
+
+   /* Need a lock now since waitboost can be modifying min as well */

Delete comment.

ok.

+   mutex_lock(>lock);

Actually, don't need the lock itself now so delete the lock.

Or, maybe the lock prevents the race if userspace writes to the sysfs when
GuC reset is going on so let's retain the lock. But the comment is wrong.

yup, ok.



+   wakeref = intel_runtime_pm_get(>runtime_pm);
+
+   /* Ignore efficient freq if lower min freq is requested */

Delete comment, it's wrong.

ok.



+   ret = slpc_set_param(slpc,
+SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
+val);
+   if (ret) {
+   guc_probe_error(slpc_to_guc(slpc), "Failed to set efficient 
freq(%d): %pe\n",
+   val, ERR_PTR(ret));
+   goto out;
+   }
+
+   slpc->ignore_eff_freq = val;
+

This extra line can also be deleted.

ok.



+out:
+   intel_runtime_pm_put(>runtime_pm, wakeref);
+   mutex_unlock(>lock);
+   return ret;
+}
+
  /**
   * intel_guc_slpc_set_min_freq() - Set min frequency limit for SLPC.
   * @slpc: pointer to intel_guc_slpc.
@@ -482,16 +511,6 @@ int intel_guc_slpc_set_min_freq(struct intel_guc_slpc 
*slpc, u32 val)
mutex_lock(>lock);
wakeref = intel_runtime_pm_get(>runtime_pm);

-   /* Ignore efficient freq if lower min freq is requested */
-   ret = slpc_set_param(slpc,
-SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
-val < slpc->rp1_freq);
-   if (ret) {
-   guc_probe_error(slpc_to_guc(slpc), "Failed to toggle efficient freq: 
%pe\n",
-   ERR_PTR(ret));
-   goto out;
-   }
-

Great, thanks!

After taking care of the above, and seems there are also a couple of
checkpatch errors, this is:

Reviewed-by: Ashutosh Dixit 


Thanks,

Vinay.



Re: [PATCH v4] drm/i915: Make IRQ reset and postinstall multi-gt aware

2023-04-17 Thread Matt Roper
On Tue, Apr 18, 2023 at 12:34:43AM +0200, Andi Shyti wrote:
> In multi-gt systems IRQs need to be reset and enabled per GT.
> 
> This might add some redundancy when handling interrupts for
> engines that might not exist in every tile, but helps to keep the
> code cleaner and more understandable.
> 
> Signed-off-by: Andi Shyti 
> Cc: Tvrtko Ursulin 
> ---
> Hi,
> 
> The rsults of this patch are more than promising as we are able
> to have MTL booting and executing basic tests.(*)
> 
> Thank you Daniele and Matt for the valuable exchange of opinions.
> 
> Amdo
> 
> (*) https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/index.html?
> 
> Changelog
> =
> v3 -> v4
>  - do not change the initial gt and uncore initialization in
>order to gain a better understanding at a glance of the
>purpose of all the local variables.

I think I may not have explained myself well on the previous feedback
here.  What I meant was that rather than doing

struct intel_uncore *uncore = to_gt(dev_priv)->uncore;

as you were in the previous rev, you can simply do

struct intel_uncore *uncore = dev_priv->uncore;

because gt0's uncore pointer is always the same as dev_priv's.  Since
we're using the uncore variable to access display-specific gunit stuff I
figured that was slightly more clear to the reader to take the
device-level pointer rather than grabbing it from any of the GTs. 

That said, using "uncore = gt->uncore" as you have in this version
doesn't cause any real problems since the actual registers being
accessed are sgunit registers and thus don't get translated by GSI
offset.  You still wind up at the same sgunit register offsets on MTL no
matter which GT you grab an uncore from, and display/gunit isn't
something that PVC even needs to worry about.  So

Reviewed-by: Matt Roper 


> v2 -> v3
>  - keep GUnit irq initialization out of the for_each_gt() loop as
>the media GT doesn't have a GUnit.
> v1 -> v2
>  - improve description in the commit log.
> 
>  drivers/gpu/drm/i915/i915_irq.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index dea1a117f3fa1..c027fd5189b85 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2858,10 +2858,13 @@ static void dg1_irq_reset(struct drm_i915_private 
> *dev_priv)
>  {
>   struct intel_gt *gt = to_gt(dev_priv);
>   struct intel_uncore *uncore = gt->uncore;
> + unsigned int i;
>  
>   dg1_master_intr_disable(dev_priv->uncore.regs);
>  
> - gen11_gt_irq_reset(gt);
> + for_each_gt(gt, dev_priv, i)
> + gen11_gt_irq_reset(gt);
> +
>   gen11_display_irq_reset(dev_priv);
>  
>   GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
> @@ -3646,8 +3649,10 @@ static void dg1_irq_postinstall(struct 
> drm_i915_private *dev_priv)
>   struct intel_gt *gt = to_gt(dev_priv);
>   struct intel_uncore *uncore = gt->uncore;
>   u32 gu_misc_masked = GEN11_GU_MISC_GSE;
> + unsigned int i;
>  
> - gen11_gt_irq_postinstall(gt);
> + for_each_gt(gt, dev_priv, i)
> + gen11_gt_irq_postinstall(gt);
>  
>   GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
>  
> -- 
> 2.39.2
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation


Re: [PATCH 5/6] drm: bridge: samsung-dsim: Support non-burst mode

2023-04-17 Thread Marek Vasut

On 4/18/23 00:24, Adam Ford wrote:

On Mon, Apr 17, 2023 at 3:08 PM Marek Vasut  wrote:


On 4/17/23 13:57, Adam Ford wrote:

On Sun, Apr 16, 2023 at 5:13 PM Marek Vasut  wrote:


On 4/15/23 12:41, Adam Ford wrote:

The high-speed clock is hard-coded to the burst-clock
frequency specified in the device tree.  However, when
using devices like certain bridge chips without burst mode
and varying resolutions and refresh rates, it may be
necessary to set the high-speed clock dynamically based
on the desired pixel clock for the connected device.


The link rate negotiation should happen internally between the nearest
bridge and DSIM, so please add that to DRM core instead of hacking
around it by tweaking the HS clock again.


I thought you tried to add something like this before and had some resistance.


Yes, all my attempts were rejected by a single reviewer. I suspended my
efforts in that area for now.


The Pixel clock is set by the bridge already without any new code
added to the DRM core..  I am just reading that value that's there,
and setting the clock accordingly.  I don't see how this is a hack.


Assume you have a DSI-to-HDMI bridge attached to your DSIM bridge, it
operates in non-burst mode, like ADV7533 . How would you configure the


I have an ADV7535


HS clock rate for such a bridge in DT ? (hint: you cannot, because the
required clock comes from the EDID, which may not be available just yet)


The whole idea is that you wouldn't want to or need to configure the
clock speed in the device tree because it comes from the
EDID->bridge->DSI.

I've tested this configuration on imx8mm, imx8mn, and imx8mp and I can
change the resolution and refresh rate on the fly and the DSI will
automatically readjust accordingly.   If you fixed the clock in the
device tree, you wouldn't be able to do that, and that was the point
of this patch.


Uh, I retract my comment, I was clearly confused here and we're talking 
about the same thing.


Re: [PATCH v6 0/3] Add sync object UAPI support to VirtIO-GPU driver

2023-04-17 Thread Gurchetan Singh
On Sun, Apr 16, 2023 at 4:53 AM Dmitry Osipenko <
dmitry.osipe...@collabora.com> wrote:

> We have multiple Vulkan context types that are awaiting for the addition
> of the sync object DRM UAPI support to the VirtIO-GPU kernel driver:
>
>  1. Venus context
>  2. Native contexts (virtio-freedreno, virtio-intel, virtio-amdgpu)
>
> Mesa core supports DRM sync object UAPI, providing Vulkan drivers with a
> generic fencing implementation that we want to utilize.
>
> This patch adds initial sync objects support. It creates fundament for a
> further fencing improvements. Later on we will want to extend the
> VirtIO-GPU
> fencing API with passing fence IDs to host for waiting, it will be a new
> additional VirtIO-GPU IOCTL and more. Today we have several VirtIO-GPU
> context
> drivers in works that require VirtIO-GPU to support sync objects UAPI.
>
> The patch is heavily inspired by the sync object UAPI implementation of the
> MSM driver.
>

The changes seem good, but I would recommend getting a full end-to-end
solution (i.e, you've proxied the host fence with these changes and shared
with the host compositor) working first.  You'll never know what you'll
find after completing this exercise.  Or is that the plan already?

Typically, you want to land the uAPI and virtio spec changes last.
Mesa/gfxstream/virglrenderer/crosvm all have the ability to test out
unstable uAPIs ...


>
> Changelog:
>
> v6: - Added zeroing out of syncobj_desc, as was suggested by Emil Velikov.
>
> - Fixed memleak in error code path which was spotted by Emil Velikov.
>
> - Switched to u32/u64 instead of uint_t. Previously was keeping
>   uint_t style of the virtgpu_ioctl.c, in the end decided to change
>   it because it's not a proper kernel coding style after all.
>
> - Kept single drm_virtgpu_execbuffer_syncobj struct for both in/out
>   sync objects. There was a little concern about whether it would be
>   worthwhile to have separate in/out descriptors, in practice it's
>   unlikely that we will extend the descs in a foreseeable future.
>   There is no overhead in using same struct since we want to pad it
>   to 64b anyways and it shouldn't be a problem to separate the descs
>   later on if we will want to do that.
>
> - Added r-b from Emil Velikov.
>
> v5: - Factored out dma-fence unwrap API usage into separate patch as was
>   suggested by Emil Velikov.
>
> - Improved and documented the job submission reorderings as was
>   requested by Emil Velikov. Sync file FD is now installed after
>   job is submitted to virtio to further optimize reorderings.
>
> - Added comment for the kvalloc, as was requested by Emil Velikov.
>
> - The num_in/out_syncobjs now is set only after completed parsing
>   of pre/post deps, as was requested by Emil Velikov.
>
> v4: - Added r-b from Rob Clark to the "refactoring" patch.
>
> - Replaced for/while(ptr && itr) with if (ptr), like was suggested by
>   Rob Clark.
>
> - Dropped NOWARN and NORETRY GFP flags and switched syncobj patch
>   to use kvmalloc.
>
> - Removed unused variables from syncobj patch that were borrowed by
>   accident from another (upcoming) patch after one of git rebases.
>
> v3: - Switched to use dma_fence_unwrap_for_each(), like was suggested by
>   Rob Clark.
>
> - Fixed missing dma_fence_put() in error code path that was spotted by
>   Rob Clark.
>
> - Removed obsoleted comment to virtio_gpu_execbuffer_ioctl(), like was
>   suggested by Rob Clark.
>
> v2: - Fixed chain-fence context matching by making use of
>   dma_fence_chain_contained().
>
> - Fixed potential uninitialized var usage in error code patch of
>   parse_post_deps(). MSM driver had a similar issue that is fixed
>   already in upstream.
>
> - Added new patch that refactors job submission code path. I found
>   that it was very difficult to add a new/upcoming host-waits feature
>   because of how variables are passed around the code, the
> virtgpu_ioctl.c
>   also was growing to unmanageable size.
>
> Dmitry Osipenko (3):
>   drm/virtio: Refactor and optimize job submission code path
>   drm/virtio: Wait for each dma-fence of in-fence array individually
>   drm/virtio: Support sync objects
>
>  drivers/gpu/drm/virtio/Makefile |   2 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.c|   3 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.h|   4 +
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c  | 182 
>  drivers/gpu/drm/virtio/virtgpu_submit.c | 530 
>  include/uapi/drm/virtgpu_drm.h  |  16 +-
>  6 files changed, 552 insertions(+), 185 deletions(-)
>  create mode 100644 drivers/gpu/drm/virtio/virtgpu_submit.c
>
> --
> 2.39.2
>
>


[PATCH 3/3] drm/msm/dpu: Pass catalog pointers directly from RM instead of IDs

2023-04-17 Thread Marijn Suijten
The Resource Manager already iterates over all available blocks from the
catalog, only to pass their ID to a dpu_hw_xxx_init() function which
uses an _xxx_offset() helper to search for and find the exact same
catalog pointer again to initialize the block with, fallible error
handling and all.

Instead, pass const pointers to the catalog entries directly to these
_init functions and drop the for loops entirely, saving on both
readability complexity and unnecessary cycles at boot.

Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 30 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h| 10 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 32 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h| 11 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c   | 38 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h   | 12 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c   | 40 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h   | 12 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 38 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 10 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 33 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h| 14 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   | 33 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h   | 14 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c   | 33 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h   |  8 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c   | 33 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h   | 11 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 33 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 11 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 17 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 18 +-
 23 files changed, 127 insertions(+), 366 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95ce374a..dec0111bf65e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -53,23 +53,6 @@ static const u32 fetch_tbl[SSPP_MAX] = {CTL_INVALID_BIT, 16, 
17, 18, 19,
CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, 0,
1, 2, 3, CTL_INVALID_BIT, CTL_INVALID_BIT};
 
-static const struct dpu_ctl_cfg *_ctl_offset(enum dpu_ctl ctl,
-   const struct dpu_mdss_cfg *m,
-   void __iomem *addr,
-   struct dpu_hw_blk_reg_map *b)
-{
-   int i;
-
-   for (i = 0; i < m->ctl_count; i++) {
-   if (ctl == m->ctl[i].id) {
-   b->blk_addr = addr + m->ctl[i].base;
-   b->log_mask = DPU_DBG_MASK_CTL;
-   return >ctl[i];
-   }
-   }
-   return ERR_PTR(-ENOMEM);
-}
-
 static int _mixer_stages(const struct dpu_lm_cfg *mixer, int count,
enum dpu_lm lm)
 {
@@ -676,27 +659,22 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->set_active_pipes = dpu_hw_ctl_set_fetch_pipe_active;
 };
 
-struct dpu_hw_ctl *dpu_hw_ctl_init(enum dpu_ctl idx,
+struct dpu_hw_ctl *dpu_hw_ctl_init(const struct dpu_ctl_cfg *cfg,
void __iomem *addr,
const struct dpu_mdss_cfg *m)
 {
struct dpu_hw_ctl *c;
-   const struct dpu_ctl_cfg *cfg;
 
c = kzalloc(sizeof(*c), GFP_KERNEL);
if (!c)
return ERR_PTR(-ENOMEM);
 
-   cfg = _ctl_offset(idx, m, addr, >hw);
-   if (IS_ERR_OR_NULL(cfg)) {
-   kfree(c);
-   pr_err("failed to create dpu_hw_ctl %d\n", idx);
-   return ERR_PTR(-EINVAL);
-   }
+   c->hw.blk_addr = addr + cfg->base;
+   c->hw.log_mask = DPU_DBG_MASK_CTL;
 
c->caps = cfg;
_setup_ctl_ops(>ops, c->caps->features);
-   c->idx = idx;
+   c->idx = cfg->id;
c->mixer_count = m->mixer_count;
c->mixer_hw_caps = m->mixer;
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index 78611a831697..88f4f3eb98ea 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -261,13 +261,13 @@ static inline struct dpu_hw_ctl *to_dpu_hw_ctl(struct 
dpu_hw_blk *hw)
 }
 
 /**
- * dpu_hw_ctl_init(): Initializes the ctl_path hw driver object.
- * should be called before accessing every ctl path registers.
- * @idx:  ctl_path index for which driver object is required
+ * dpu_hw_ctl_init() - Initializes the ctl_path hw driver object.
+ * Should be called before accessing any ctl_path register.
+ * @cfg:  ctl_path 

[PATCH 2/3] drm/msm/dpu: Assign missing writeback log_mask

2023-04-17 Thread Marijn Suijten
The WB debug log mask ended up never being assigned, leading to writes
to this block to never be logged even if the mask is enabled in
dpu_hw_util_log_mask via sysfs.

Fixes: 84a33d0fd921 ("drm/msm/dpu: add dpu_hw_wb abstraction for writeback 
blocks")
Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
index db5e6040017f..f33b48045b5c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
@@ -61,6 +61,7 @@ static const struct dpu_wb_cfg *_wb_offset(enum dpu_wb wb,
for (i = 0; i < m->wb_count; i++) {
if (wb == m->wb[i].id) {
b->blk_addr = addr + m->wb[i].base;
+   b->log_mask = DPU_DBG_MASK_WB;
return >wb[i];
}
}

-- 
2.40.0



[PATCH 1/3] drm/msm/dpu: Drop unused members from HW structs

2023-04-17 Thread Marijn Suijten
Some of these members were initialized while never read, while others
were not even assigned any value at all.  Drop them to save some space,
and above all confusion when looking at these members.

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Fixes: 84a33d0fd921 ("drm/msm/dpu: add dpu_hw_wb abstraction for writeback 
blocks")
Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 2 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c   | 1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h   | 5 -
 6 files changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 84ee2efa9c66..a9c90249a6ac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -374,7 +374,6 @@ struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf idx,
 */
c->idx = idx;
c->cap = cfg;
-   c->mdss = m;
_setup_intf_ops(>ops, c->cap->features);
 
return c;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 643dd10bc030..e07b2e33af3e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -90,7 +90,6 @@ struct dpu_hw_intf {
/* intf */
enum dpu_intf idx;
const struct dpu_intf_cfg *cap;
-   const struct dpu_mdss_cfg *mdss;
 
/* ops */
struct dpu_hw_intf_ops ops;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index cf70a9bd1034..bb3ddec5c7d7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -812,7 +812,6 @@ struct dpu_hw_sspp *dpu_hw_sspp_init(enum dpu_sspp idx,
}
 
/* Assign ops */
-   hw_pipe->catalog = catalog;
hw_pipe->ubwc = catalog->ubwc;
hw_pipe->idx = idx;
hw_pipe->cap = cfg;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index 74b98b6b3bc3..5004a02fd61e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -341,7 +341,6 @@ struct dpu_hw_sspp_ops {
  * struct dpu_hw_sspp - pipe description
  * @base: hardware block base structure
  * @hw: block hardware details
- * @catalog: back pointer to catalog
  * @ubwc: ubwc configuration data
  * @idx: pipe index
  * @cap: pointer to layer_cfg
@@ -350,7 +349,6 @@ struct dpu_hw_sspp_ops {
 struct dpu_hw_sspp {
struct dpu_hw_blk base;
struct dpu_hw_blk_reg_map hw;
-   const struct dpu_mdss_cfg *catalog;
const struct dpu_ubwc_cfg *ubwc;
 
/* Pipe */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
index 2d28afdf860e..db5e6040017f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
@@ -262,7 +262,6 @@ struct dpu_hw_wb *dpu_hw_wb_init(enum dpu_wb idx,
}
 
/* Assign ops */
-   c->mdp = >mdp[0];
c->idx = idx;
c->caps = cfg;
_setup_wb_ops(>ops, c->caps->features);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h
index 3ff5a48541e2..b91923f879f1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h
@@ -76,15 +76,12 @@ struct dpu_hw_wb_ops {
 /**
  * struct dpu_hw_wb : WB driver object
  * @hw: block hardware details
- * @mdp: pointer to associated mdp portion of the catalog
  * @idx: hardware index number within type
  * @wb_hw_caps: hardware capabilities
  * @ops: function pointers
- * @hw_mdp: MDP top level hardware block
  */
 struct dpu_hw_wb {
struct dpu_hw_blk_reg_map hw;
-   const struct dpu_mdp_cfg *mdp;
 
/* wb path */
int idx;
@@ -92,8 +89,6 @@ struct dpu_hw_wb {
 
/* ops */
struct dpu_hw_wb_ops ops;
-
-   struct dpu_hw_mdp *hw_mdp;
 };
 
 /**

-- 
2.40.0



[PATCH 0/3] drm/msm/dpu: Drop useless for-loop HW block lookup

2023-04-17 Thread Marijn Suijten
Doing a for loop in every DPU HW block driver init to find a catalog
entry matching the given ID is rather useless if the init function
called by RM already has that catalog entry pointer, and uses exactly
its ID to drive this init and for loop.  Remove all that machinery to
drop quite some lines of unnecessarily-complicated code, and the
fallibility that comes with it, by simply giving _init() the catalog
entry pointers straight away.

Also clean up some unused struct members, and assign a log_mask for WB.

---
Marijn Suijten (3):
  drm/msm/dpu: Drop unused members from HW structs
  drm/msm/dpu: Assign missing writeback log_mask
  drm/msm/dpu: Pass catalog pointers directly from RM instead of IDs

 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 30 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h| 10 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 32 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h| 11 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c   | 38 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h   | 12 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c   | 41 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h   | 13 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 38 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 10 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 33 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h| 14 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   | 33 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h   | 14 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c   | 34 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h   | 10 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c   | 33 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h   | 11 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 33 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 16 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 17 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 18 +-
 23 files changed, 127 insertions(+), 376 deletions(-)
---
base-commit: 4aa1da8d99724f6c0b762b58a71cee7c5e2e109b
change-id: 20230418-dpu-drop-useless-for-lookup-488700c7a469

Best regards,
-- 
Marijn Suijten 



[PATCH] drm/msm: Move cmdstream dumping out of sched kthread

2023-04-17 Thread Rob Clark
From: Rob Clark 

This is something that can block for arbitrary amounts of time as
userspace consumes from the FIFO.  So we don't really want this to
be in the fence signaling path.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_gem_submit.c |  2 ++
 drivers/gpu/drm/msm/msm_gpu.c|  4 
 drivers/gpu/drm/msm/msm_rd.c | 24 
 3 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 89375c2e422b..6c6aefaa72be 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -952,6 +952,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
/* The scheduler owns a ref now: */
msm_gem_submit_get(submit);
 
+   msm_rd_dump_submit(priv->rd, submit, NULL);
+
drm_sched_entity_push_job(>base);
 
args->fence = submit->fence_id;
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 1150dcbf28aa..513e2fccfefc 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -759,8 +759,6 @@ void msm_gpu_retire(struct msm_gpu *gpu)
 /* add bo's to gpu's ring, and kick gpu: */
 void msm_gpu_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
 {
-   struct drm_device *dev = gpu->dev;
-   struct msm_drm_private *priv = dev->dev_private;
struct msm_ringbuffer *ring = submit->ring;
unsigned long flags;
 
@@ -772,8 +770,6 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit)
 
submit->seqno = submit->hw_fence->seqno;
 
-   msm_rd_dump_submit(priv->rd, submit, NULL);
-
update_sw_cntrs(gpu);
 
/*
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index db2f847c8535..8d5687d5ed78 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -83,15 +83,10 @@ struct msm_rd_state {
 
bool open;
 
-   /* current submit to read out: */
-   struct msm_gem_submit *submit;
-
/* fifo access is synchronized on the producer side by
-* gpu->lock held by submit code (otherwise we could
-* end up w/ cmds logged in different order than they
-* were executed).  And read_lock synchronizes the reads
+* write_lock.  And read_lock synchronizes the reads
 */
-   struct mutex read_lock;
+   struct mutex read_lock, write_lock;
 
wait_queue_head_t fifo_event;
struct circ_buf fifo;
@@ -243,6 +238,7 @@ static void rd_cleanup(struct msm_rd_state *rd)
return;
 
mutex_destroy(>read_lock);
+   mutex_destroy(>write_lock);
kfree(rd);
 }
 
@@ -258,6 +254,7 @@ static struct msm_rd_state *rd_init(struct drm_minor 
*minor, const char *name)
rd->fifo.buf = rd->buf;
 
mutex_init(>read_lock);
+   mutex_init(>write_lock);
 
init_waitqueue_head(>fifo_event);
 
@@ -338,19 +335,15 @@ static void snapshot_buf(struct msm_rd_state *rd,
if (!(submit->bos[idx].flags & MSM_SUBMIT_BO_READ))
return;
 
-   msm_gem_lock(>base);
buf = msm_gem_get_vaddr_active(>base);
if (IS_ERR(buf))
-   goto out_unlock;
+   return;
 
buf += offset;
 
rd_write_section(rd, RD_BUFFER_CONTENTS, buf, size);
 
msm_gem_put_vaddr_locked(>base);
-
-out_unlock:
-   msm_gem_unlock(>base);
 }
 
 /* called under gpu->lock */
@@ -364,10 +357,7 @@ void msm_rd_dump_submit(struct msm_rd_state *rd, struct 
msm_gem_submit *submit,
if (!rd->open)
return;
 
-   /* writing into fifo is serialized by caller, and
-* rd->read_lock is used to serialize the reads
-*/
-   WARN_ON(!mutex_is_locked(>gpu->lock));
+   mutex_lock(>write_lock);
 
if (fmt) {
va_list args;
@@ -424,5 +414,7 @@ void msm_rd_dump_submit(struct msm_rd_state *rd, struct 
msm_gem_submit *submit,
break;
}
}
+
+   mutex_unlock(>write_lock);
 }
 #endif
-- 
2.39.2



[PATCH] drm/msm: Fix vmap madv warning

2023-04-17 Thread Rob Clark
From: Rob Clark 

Commit d6ae7d1cd58e ("drm/msm/gem: Simplify vmap vs LRU tracking")
introduced a splat in the pin_pages_locked() path for buffers that
had been MADV_DONTNEED.

   [ cut here ]
   msm_obj->madv != 0
   WARNING: CPU: 1 PID: 144 at drivers/gpu/drm/msm/msm_gem.c:230 
msm_gem_pin_pages_locked+0x9c/0xd4
   Modules linked in: lzo_rle cros_ec_lid_angle cros_ec_sensors 
cros_ec_sensors_core venus_dec venus_enc videobuf2_dma_contig cdc_ether usbnet 
mii uvcvideo videobuf2_vmalloc hci_uart btqca qcom_spmi_adc5 uvc 
qcom_spmi_temp_alarm qcom_vadc_common cros_ec_sensorhub videobuf2_memops 
cros_ec_typec sx9324 sx_common typec joydev bluetooth 
industrialio_triggered_buffer ecdh_generic kfifo_buf ecc venus_core qcom_stats 
v4l2_mem2mem videobuf2_v4l2 videobuf2_common ath11k_ahb ath11k mac80211 
cfg80211 fuse zram zsmalloc
   CPU: 1 PID: 144 Comm: ring0 Tainted: GW  6.3.0-rc2-debug+ 
#622
   Hardware name: Google Villager (rev1+) with LTE (DT)
   pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
   pc : msm_gem_pin_pages_locked+0x9c/0xd4
   lr : msm_gem_pin_pages_locked+0x9c/0xd4
   sp : ffc009ffbab0
   x29: ffc009ffbab0 x28: ffee8da75008 x27: ff80a10274d0
   x26: ff8087fe3bf8 x25: ff8087fe3c08 x24: 0001
   x23: ff80891d5800 x22: ff809d0de480 x21: ff8081e5a080
   x20: 0002 x19: ff80a3564c00 x18: 
   x17:  x16:  x15: 000a9620
   x14:  x13: 2d2d2d2d2d2d2d2d x12: 2d2d2d2d5d206572
   x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : ffee8c705dfc
   x8 : ffee8da75000 x7 : ffee8d34e6d0 x6 : 
   x5 : 000affa8 x4 : 000d x3 : ffee8da75008
   x2 :  x1 :  x0 : ff8088048040
   Call trace:
msm_gem_pin_pages_locked+0x9c/0xd4
get_vaddr+0xb0/0x150
msm_gem_get_vaddr_active+0x1c/0x28
snapshot_buf+0x90/0x10c
msm_rd_dump_submit+0x30c/0x380
msm_gpu_submit+0x88/0x174
msm_job_run+0x68/0x118
drm_sched_main+0x2b8/0x3a0
kthread+0xf0/0x100
ret_from_fork+0x10/0x20
   irq event stamp: 3358
   hardirqs last  enabled at (3357): [] 
__up_console_sem+0x7c/0x80
   hardirqs last disabled at (3358): [] el1_dbg+0x24/0x80
   softirqs last  enabled at (3330): [] 
__do_softirq+0x21c/0x4bc
   softirqs last disabled at (3325): [] 
do_softirq+0x18/0x24
   ---[ end trace  ]---

But, as with msm_gem_get_vaddr_active(), this is a special case
because we know that the buffer won't be purged evicted until it's
fence is signaled.  We just forgot to propagate the logic get_vaddr()
to pin_pages_locked().

Fixes: d6ae7d1cd58e ("drm/msm/gem: Simplify vmap vs LRU tracking")
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_gem.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index c32264234ea1..20cfd86d2b32 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -219,7 +219,8 @@ static void put_pages(struct drm_gem_object *obj)
}
 }
 
-static struct page **msm_gem_pin_pages_locked(struct drm_gem_object *obj)
+static struct page **msm_gem_pin_pages_locked(struct drm_gem_object *obj,
+ unsigned madv)
 {
struct msm_drm_private *priv = obj->dev->dev_private;
struct msm_gem_object *msm_obj = to_msm_bo(obj);
@@ -227,7 +228,9 @@ static struct page **msm_gem_pin_pages_locked(struct 
drm_gem_object *obj)
 
msm_gem_assert_locked(obj);
 
-   if (GEM_WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
+   if (GEM_WARN_ON(msm_obj->madv > madv)) {
+   DRM_DEV_ERROR(obj->dev->dev, "Invalid madv state: %u vs %u\n",
+   msm_obj->madv, madv);
return ERR_PTR(-EBUSY);
}
 
@@ -248,7 +251,7 @@ struct page **msm_gem_pin_pages(struct drm_gem_object *obj)
struct page **p;
 
msm_gem_lock(obj);
-   p = msm_gem_pin_pages_locked(obj);
+   p = msm_gem_pin_pages_locked(obj, MSM_MADV_WILLNEED);
msm_gem_unlock(obj);
 
return p;
@@ -473,10 +476,7 @@ int msm_gem_pin_vma_locked(struct drm_gem_object *obj, 
struct msm_gem_vma *vma)
 
msm_gem_assert_locked(obj);
 
-   if (GEM_WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED))
-   return -EBUSY;
-
-   pages = msm_gem_pin_pages_locked(obj);
+   pages = msm_gem_pin_pages_locked(obj, MSM_MADV_WILLNEED);
if (IS_ERR(pages))
return PTR_ERR(pages);
 
@@ -699,13 +699,7 @@ static void *get_vaddr(struct drm_gem_object *obj, 
unsigned madv)
if (obj->import_attach)
return ERR_PTR(-ENODEV);
 
-   if (GEM_WARN_ON(msm_obj->madv > madv)) {
-   DRM_DEV_ERROR(obj->dev->dev, "Invalid madv state: %u vs %u\n",
-   

Re: [PATCH] drm/sysfs: Expose DRM connector id in each connector sysfs

2023-04-17 Thread Manasi Navare
On Tue, Mar 28, 2023 at 6:45 PM Won Chung  wrote:
>
> Expose DRM connector id in device sysfs so that we can map the connector
> id to the connector syspath. Currently, even if we can derive the
> connector id from modeset, we do not have a way to find the
> corresponding connector's syspath.
>
> This is helpful when determining the root connector of MST tree. When a
> tree of multiple MST hub is connected to the system, modeset describes
> the tree in the PATH blob. For example, consider the following scenario.
>
> +-+
> | Source  |+-+
> | (Device)|| BranchX |
> | || (MST)   |
> |   [conn6]--->|   [port1]--->DisplayA
> +-+| |
>| |+-+
>| || BranchY |
>| || (MST)   |
>|   [port2]--->|   [port1]->DisplayB
>+-+| |
>   |   [port2]->DisplayC
>   +-+
>
> DPMST connector of DisplayA would have "mst:6-1" PATH.
> DPMST connector of DisplayB would have "mst:6-2-1" PATH.
> DPMST connector of DisplayC would have "mst:6-2-2" PATH.
>
> Given that connector id of 6 is the root of the MST connector tree, we
> can utilize this patch to parse through DRM connectors sysfs and find
> which connector syspath corresponds to the root connector (id == 6).
>
> ChromeOS intend to use this information for metrics collection. For
> example, we want to tell which port is deriving which displays even with
> a MST hub. Chromium patch for parsing DRM connector id from the kernel
> is at http://crrev.com/c/4317207.
>
> Signed-off-by: Won Chung 

Exposing connector id in device sysfs looks good to me.

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/drm_sysfs.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 183130355997..11f98c5d6103 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -282,16 +282,27 @@ static ssize_t modes_show(struct device *device,
> return written;
>  }
>
> +static ssize_t connector_id_show(struct device *device,
> +struct device_attribute *attr,
> +char *buf)
> +{
> +   struct drm_connector *connector = to_drm_connector(device);
> +
> +   return sysfs_emit(buf, "%d\n", connector->base.id);
> +}
> +
>  static DEVICE_ATTR_RW(status);
>  static DEVICE_ATTR_RO(enabled);
>  static DEVICE_ATTR_RO(dpms);
>  static DEVICE_ATTR_RO(modes);
> +static DEVICE_ATTR_RO(connector_id);
>
>  static struct attribute *connector_dev_attrs[] = {
> _attr_status.attr,
> _attr_enabled.attr,
> _attr_dpms.attr,
> _attr_modes.attr,
> +   _attr_connector_id.attr,
> NULL
>  };
>
> --
> 2.40.0.348.gf938b09366-goog
>


[PATCH v4] drm/i915: Make IRQ reset and postinstall multi-gt aware

2023-04-17 Thread Andi Shyti
In multi-gt systems IRQs need to be reset and enabled per GT.

This might add some redundancy when handling interrupts for
engines that might not exist in every tile, but helps to keep the
code cleaner and more understandable.

Signed-off-by: Andi Shyti 
Cc: Tvrtko Ursulin 
---
Hi,

The rsults of this patch are more than promising as we are able
to have MTL booting and executing basic tests.(*)

Thank you Daniele and Matt for the valuable exchange of opinions.

Amdo

(*) https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/index.html?

Changelog
=
v3 -> v4
 - do not change the initial gt and uncore initialization in
   order to gain a better understanding at a glance of the
   purpose of all the local variables.
v2 -> v3
 - keep GUnit irq initialization out of the for_each_gt() loop as
   the media GT doesn't have a GUnit.
v1 -> v2
 - improve description in the commit log.

 drivers/gpu/drm/i915/i915_irq.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dea1a117f3fa1..c027fd5189b85 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2858,10 +2858,13 @@ static void dg1_irq_reset(struct drm_i915_private 
*dev_priv)
 {
struct intel_gt *gt = to_gt(dev_priv);
struct intel_uncore *uncore = gt->uncore;
+   unsigned int i;
 
dg1_master_intr_disable(dev_priv->uncore.regs);
 
-   gen11_gt_irq_reset(gt);
+   for_each_gt(gt, dev_priv, i)
+   gen11_gt_irq_reset(gt);
+
gen11_display_irq_reset(dev_priv);
 
GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
@@ -3646,8 +3649,10 @@ static void dg1_irq_postinstall(struct drm_i915_private 
*dev_priv)
struct intel_gt *gt = to_gt(dev_priv);
struct intel_uncore *uncore = gt->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+   unsigned int i;
 
-   gen11_gt_irq_postinstall(gt);
+   for_each_gt(gt, dev_priv, i)
+   gen11_gt_irq_postinstall(gt);
 
GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
 
-- 
2.39.2



Re: [PATCH 5/6] drm: bridge: samsung-dsim: Support non-burst mode

2023-04-17 Thread Adam Ford
On Mon, Apr 17, 2023 at 3:08 PM Marek Vasut  wrote:
>
> On 4/17/23 13:57, Adam Ford wrote:
> > On Sun, Apr 16, 2023 at 5:13 PM Marek Vasut  wrote:
> >>
> >> On 4/15/23 12:41, Adam Ford wrote:
> >>> The high-speed clock is hard-coded to the burst-clock
> >>> frequency specified in the device tree.  However, when
> >>> using devices like certain bridge chips without burst mode
> >>> and varying resolutions and refresh rates, it may be
> >>> necessary to set the high-speed clock dynamically based
> >>> on the desired pixel clock for the connected device.
> >>
> >> The link rate negotiation should happen internally between the nearest
> >> bridge and DSIM, so please add that to DRM core instead of hacking
> >> around it by tweaking the HS clock again.
> >
> > I thought you tried to add something like this before and had some 
> > resistance.
>
> Yes, all my attempts were rejected by a single reviewer. I suspended my
> efforts in that area for now.
>
> > The Pixel clock is set by the bridge already without any new code
> > added to the DRM core..  I am just reading that value that's there,
> > and setting the clock accordingly.  I don't see how this is a hack.
>
> Assume you have a DSI-to-HDMI bridge attached to your DSIM bridge, it
> operates in non-burst mode, like ADV7533 . How would you configure the

I have an ADV7535

> HS clock rate for such a bridge in DT ? (hint: you cannot, because the
> required clock comes from the EDID, which may not be available just yet)

The whole idea is that you wouldn't want to or need to configure the
clock speed in the device tree because it comes from the
EDID->bridge->DSI.

I've tested this configuration on imx8mm, imx8mn, and imx8mp and I can
change the resolution and refresh rate on the fly and the DSI will
automatically readjust accordingly.   If you fixed the clock in the
device tree, you wouldn't be able to do that, and that was the point
of this patch.


adam


Re: [PATCH 2/2] drm/amd/display: fix missing=prototypes warnings

2023-04-17 Thread Arnd Bergmann
On Mon, Apr 17, 2023, at 23:17, Hamza Mahfooz wrote:
> On 4/17/23 17:05, Arnd Bergmann wrote:
>> From: Arnd Bergmann 
>> 
>> Three functions in the amdgpu display driver cause -Wmissing-prototype
>> warnings:
>> 
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: 
>> no previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:210:6: 
>> error: no previous prototype for 'is_synaptics_cascaded_panamera' 
>> [-Werror=missing-prototypes]
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: error: no 
>> previous prototype for 'optc3_wait_drr_doublebuffer_pending_clear' 
>> [-Werror=missing-prototypes]
>> 
>> is_timing_changed() is actually meant to be a global symbol, but needs
>> a proper name and prototype, while the other two can just be made static.
>> 
>> Fixes: 54c7b715b5ef ("drm/amd/display: Add DSC Support for Synaptics 
>> Cascaded MST Hub")
>> Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic 
>> check")
>> Fixes: 8f0d304d21b3 ("drm/amd/display: Do not commit pipe when updating DRR")
>> Signed-off-by: Arnd Bergmann 
>
> It seems like, only the changes for is_timing_changed() are in this patch.

Indeed. I made this patch a few weeks ago, and it looks like the other
two were fixed in the same way that I had in the meantime, so the other
changes got silently dropped during a rebase. I've updated the changelog
text and sent a v2 now.

  Arnd


[PATCH] [v2] drm/amd/display: fix is_timing_changed() prototype

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no 
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]

is_timing_changed() is actually meant to be a global symbol, but needs
a proper name and prototype.

Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 ++---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c   | 6 +++---
 drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 994ba426ca66..442511061178 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -45,8 +45,7 @@
 #endif
 
 #include "dc/dcn20/dcn20_resource.h"
-bool is_timing_changed(struct dc_stream_state *cur_stream,
-  struct dc_stream_state *new_stream);
+
 #define PEAK_FACTOR_X1000 1006
 
 static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
@@ -1417,7 +1416,7 @@ int pre_validate_dsc(struct drm_atomic_state *state,
struct dc_stream_state *stream = dm_state->context->streams[i];
 
if (local_dc_state->streams[i] &&
-   is_timing_changed(stream, local_dc_state->streams[i])) {
+   dc_is_timing_changed(stream, local_dc_state->streams[i])) {
DRM_INFO_ONCE("crtc[%d] needs mode_changed\n", i);
} else {
int ind = find_crtc_index_in_state_by_stream(state, 
stream);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 85d54bfb595c..344533623cb9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1855,7 +1855,7 @@ bool dc_add_all_planes_for_stream(
return add_all_planes_for_stream(dc, stream, , 1, context);
 }
 
-bool is_timing_changed(struct dc_stream_state *cur_stream,
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
   struct dc_stream_state *new_stream)
 {
if (cur_stream == NULL)
@@ -1880,7 +1880,7 @@ static bool are_stream_backends_same(
if (stream_a == NULL || stream_b == NULL)
return false;
 
-   if (is_timing_changed(stream_a, stream_b))
+   if (dc_is_timing_changed(stream_a, stream_b))
return false;
 
if (stream_a->signal != stream_b->signal)
@@ -3505,7 +3505,7 @@ bool pipe_need_reprogram(
if (pipe_ctx_old->stream_res.stream_enc != 
pipe_ctx->stream_res.stream_enc)
return true;
 
-   if (is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
+   if (dc_is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
return true;
 
if (pipe_ctx_old->stream->dpms_off != pipe_ctx->stream->dpms_off)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 23ee63b98dcd..e7ab6cb3769b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -2225,4 +2225,7 @@ void dc_process_dmub_dpia_hpd_int_enable(const struct dc 
*dc,
 /* Disable acc mode Interfaces */
 void dc_disable_accelerated_mode(struct dc *dc);
 
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
+  struct dc_stream_state *new_stream);
+
 #endif /* DC_INTERFACE_H_ */
-- 
2.39.2



Re: [PATCH] drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume

2023-04-17 Thread Heiko Stuebner
On Mon, 17 Apr 2023 14:37:47 +0200, Sascha Hauer wrote:
> afa965a45e01 ("drm/rockchip: vop2: fix suspend/resume") uses
> regmap_reinit_cache() to fix the suspend/resume issue with the VOP2
> driver. During discussion it came up that we should rather use
> regcache_sync() instead. As the original patch is already applied
> fix this up in this follow-up patch.
> 
> 
> [...]

Applied, thanks!

[1/1] drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume
  commit: b63a553e8f5aa6574eeb535a551817a93c426d8c

Best regards,
-- 
Heiko Stuebner 


[PATCH] drm/amd/display: Fix a test dml32_rq_dlg_get_rq_reg()

2023-04-17 Thread Christophe JAILLET
It is likely p1_min_meta_chunk_bytes was expected here, instead of
min_meta_chunk_bytes.

Test the correct variable.

Fixes: dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321")
Signed-off-by: Christophe JAILLET 
---
 .../gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c
index 395ae8761980..9ba6cb67655f 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c
@@ -116,7 +116,7 @@ void dml32_rq_dlg_get_rq_reg(display_rq_regs_st *rq_regs,
else
rq_regs->rq_regs_l.min_meta_chunk_size = 
dml_log2(min_meta_chunk_bytes) - 6 + 1;
 
-   if (min_meta_chunk_bytes == 0)
+   if (p1_min_meta_chunk_bytes == 0)
rq_regs->rq_regs_c.min_meta_chunk_size = 0;
else
rq_regs->rq_regs_c.min_meta_chunk_size = 
dml_log2(p1_min_meta_chunk_bytes) - 6 + 1;
-- 
2.34.1



Re: [PATCH 2/2] drm/msm/dpu: add HDMI output support

2023-04-17 Thread Abhinav Kumar




On 4/15/2023 10:19 AM, Dmitry Baryshkov wrote:

MSM8998 and the older Qualcomm platforms support HDMI outputs. Now as
DPU encoder is ready, add support for using INTF_HDMI.



From what I see, encoder was always ready but just HDMI case was not 
handled? Or are you saying this because of the prev patch which sorts 
out encoder_type and intf_type



Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 45 +
  1 file changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e85e3721d2c7..65cce59163a4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -617,6 +617,45 @@ static int _dpu_kms_initialize_displayport(struct 
drm_device *dev,
return 0;
  }
  
+static int _dpu_kms_initialize_hdmi(struct drm_device *dev,

+   struct msm_drm_private *priv,
+   struct dpu_kms *dpu_kms)
+{
+   struct drm_encoder *encoder = NULL;
+   struct msm_display_info info;
+   int rc;
+   int i;
+
+   if (!priv->hdmi)
+   return 0;
+
+   encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
+   if (IS_ERR(encoder)) {
+   DPU_ERROR("encoder init failed for HDMI display\n");
+   return PTR_ERR(encoder);
+   }
+
+   memset(, 0, sizeof(info));
+   rc = msm_hdmi_modeset_init(priv->hdmi, dev, encoder);
+   if (rc) {
+   DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
+   drm_encoder_cleanup(encoder);
+   return rc;
+   }
+
+   info.num_of_h_tiles = 1;
+   info.h_tile_instance[0] = i;


As Arnaud noted, i is uninitialized here.


+   info.intf_type = INTF_HDMI;
+   rc = dpu_encoder_setup(dev, encoder, );
+   if (rc) {
+   DPU_ERROR("failed to setup DPU encoder %d: rc:%d\n",
+ encoder->base.id, rc);
+   return rc;
+   }
+
+   return 0;
+}
+
  static int _dpu_kms_initialize_writeback(struct drm_device *dev,
struct msm_drm_private *priv, struct dpu_kms *dpu_kms,
const u32 *wb_formats, int n_formats)
@@ -683,6 +722,12 @@ static int _dpu_kms_setup_displays(struct drm_device *dev,
return rc;
}
  
+	rc = _dpu_kms_initialize_hdmi(dev, priv, dpu_kms);

+   if (rc) {
+   DPU_ERROR("initialize HDMI failed, rc = %d\n", rc);
+   return rc;
+   }
+
/* Since WB isn't a driver check the catalog before initializing */
if (dpu_kms->catalog->wb_count) {
for (i = 0; i < dpu_kms->catalog->wb_count; i++) {


[PATCH] drm/amd/display: Fix a test CalculatePrefetchSchedule()

2023-04-17 Thread Christophe JAILLET
It is likely Height was expected here, instead of Width.

Test the correct variable.

Fixes: 17529ea2acfa ("drm/amd/display: Optimizations for DML math")
Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
index b7c2844d0cbe..f294f2f8c75b 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
@@ -810,7 +810,7 @@ static bool CalculatePrefetchSchedule(
*swath_width_chroma_ub = dml_ceil(SwathWidthY / 2 - 1, 
myPipe->BlockWidth256BytesC) + myPipe->BlockWidth256BytesC;
} else {
*swath_width_luma_ub = dml_ceil(SwathWidthY - 1, 
myPipe->BlockHeight256BytesY) + myPipe->BlockHeight256BytesY;
-   if (myPipe->BlockWidth256BytesC > 0)
+   if (myPipe->BlockHeight256BytesC > 0)
*swath_width_chroma_ub = dml_ceil(SwathWidthY / 2 - 1, 
myPipe->BlockHeight256BytesC) + myPipe->BlockHeight256BytesC;
}
 
-- 
2.34.1



Re: [PATCH 2/2] drm/amd/display: fix missing=prototypes warnings

2023-04-17 Thread Hamza Mahfooz

On 4/17/23 17:05, Arnd Bergmann wrote:

From: Arnd Bergmann 

Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no 
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:210:6: 
error: no previous prototype for 'is_synaptics_cascaded_panamera' 
[-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: error: no 
previous prototype for 'optc3_wait_drr_doublebuffer_pending_clear' 
[-Werror=missing-prototypes]

is_timing_changed() is actually meant to be a global symbol, but needs
a proper name and prototype, while the other two can just be made static.

Fixes: 54c7b715b5ef ("drm/amd/display: Add DSC Support for Synaptics Cascaded MST 
Hub")
Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check")
Fixes: 8f0d304d21b3 ("drm/amd/display: Do not commit pipe when updating DRR")
Signed-off-by: Arnd Bergmann 


It seems like, only the changes for is_timing_changed() are in this patch.


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 ++---
  drivers/gpu/drm/amd/display/dc/core/dc_resource.c   | 6 +++---
  drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
  3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 994ba426ca66..442511061178 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -45,8 +45,7 @@
  #endif
  
  #include "dc/dcn20/dcn20_resource.h"

-bool is_timing_changed(struct dc_stream_state *cur_stream,
-  struct dc_stream_state *new_stream);
+
  #define PEAK_FACTOR_X1000 1006
  
  static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,

@@ -1417,7 +1416,7 @@ int pre_validate_dsc(struct drm_atomic_state *state,
struct dc_stream_state *stream = dm_state->context->streams[i];
  
  		if (local_dc_state->streams[i] &&

-   is_timing_changed(stream, local_dc_state->streams[i])) {
+   dc_is_timing_changed(stream, local_dc_state->streams[i])) {
DRM_INFO_ONCE("crtc[%d] needs mode_changed\n", i);
} else {
int ind = find_crtc_index_in_state_by_stream(state, 
stream);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 85d54bfb595c..344533623cb9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1855,7 +1855,7 @@ bool dc_add_all_planes_for_stream(
return add_all_planes_for_stream(dc, stream, , 1, context);
  }
  
-bool is_timing_changed(struct dc_stream_state *cur_stream,

+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
   struct dc_stream_state *new_stream)
  {
if (cur_stream == NULL)
@@ -1880,7 +1880,7 @@ static bool are_stream_backends_same(
if (stream_a == NULL || stream_b == NULL)
return false;
  
-	if (is_timing_changed(stream_a, stream_b))

+   if (dc_is_timing_changed(stream_a, stream_b))
return false;
  
  	if (stream_a->signal != stream_b->signal)

@@ -3505,7 +3505,7 @@ bool pipe_need_reprogram(
if (pipe_ctx_old->stream_res.stream_enc != 
pipe_ctx->stream_res.stream_enc)
return true;
  
-	if (is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))

+   if (dc_is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
return true;
  
  	if (pipe_ctx_old->stream->dpms_off != pipe_ctx->stream->dpms_off)

diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 23ee63b98dcd..e7ab6cb3769b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -2225,4 +2225,7 @@ void dc_process_dmub_dpia_hpd_int_enable(const struct dc 
*dc,
  /* Disable acc mode Interfaces */
  void dc_disable_accelerated_mode(struct dc *dc);
  
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,

+  struct dc_stream_state *new_stream);
+
  #endif /* DC_INTERFACE_H_ */

--
Hamza



Re: [PATCH 1/2] drm/amd/display: mark dccg314_init() static

2023-04-17 Thread Arnd Bergmann
On Mon, Apr 17, 2023, at 23:12, Hamza Mahfooz wrote:
> On 4/17/23 17:05, Arnd Bergmann wrote:
>> From: Arnd Bergmann 
>> 
>> The newly introduced global function is not declared in a header or
>> called from another file, causing a harmless warning with sparse
>> or W=1 builds:
>> 
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error: 
>> no previous prototype for 'dccg314_init' [-Werror=missing-prototypes]
>> 
>> Mark it static instead.
>> 
>> Fixes: 6f6869dcf415 ("drm/amd/display: prep work for root clock optimization 
>> enablement for DCN314")
>> Signed-off-by: Arnd Bergmann 
>
> This has already been fixed as of commit 669f4ac40947 ("drm/amd/display:
> set variable dccg314_init storage-class-specifier to static") in
> amd-staging-drm-next.

Ok, thanks. I waited for a rebase on today's linux-next before posting
mine to make sure it's not already fixed, it must have just missed the
cut-off.

  Arnd


Re: [PATCH 1/2] drm/amd/display: mark dccg314_init() static

2023-04-17 Thread Hamza Mahfooz



On 4/17/23 17:05, Arnd Bergmann wrote:

From: Arnd Bergmann 

The newly introduced global function is not declared in a header or
called from another file, causing a harmless warning with sparse
or W=1 builds:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error: no 
previous prototype for 'dccg314_init' [-Werror=missing-prototypes]

Mark it static instead.

Fixes: 6f6869dcf415 ("drm/amd/display: prep work for root clock optimization 
enablement for DCN314")
Signed-off-by: Arnd Bergmann 


This has already been fixed as of commit 669f4ac40947 ("drm/amd/display:
set variable dccg314_init storage-class-specifier to static") in
amd-staging-drm-next.


---
  drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c 
b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
index 6f879265ad9c..de7bfba2c179 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
@@ -274,7 +274,7 @@ static void dccg314_set_dpstreamclk(
}
  }
  
-void dccg314_init(struct dccg *dccg)

+static void dccg314_init(struct dccg *dccg)
  {
int otg_inst;
  

--
Hamza



[PATCH 2/2] drm/amd/display: fix missing=prototypes warnings

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no 
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:210:6: 
error: no previous prototype for 'is_synaptics_cascaded_panamera' 
[-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: error: no 
previous prototype for 'optc3_wait_drr_doublebuffer_pending_clear' 
[-Werror=missing-prototypes]

is_timing_changed() is actually meant to be a global symbol, but needs
a proper name and prototype, while the other two can just be made static.

Fixes: 54c7b715b5ef ("drm/amd/display: Add DSC Support for Synaptics Cascaded 
MST Hub")
Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check")
Fixes: 8f0d304d21b3 ("drm/amd/display: Do not commit pipe when updating DRR")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 ++---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c   | 6 +++---
 drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 994ba426ca66..442511061178 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -45,8 +45,7 @@
 #endif
 
 #include "dc/dcn20/dcn20_resource.h"
-bool is_timing_changed(struct dc_stream_state *cur_stream,
-  struct dc_stream_state *new_stream);
+
 #define PEAK_FACTOR_X1000 1006
 
 static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
@@ -1417,7 +1416,7 @@ int pre_validate_dsc(struct drm_atomic_state *state,
struct dc_stream_state *stream = dm_state->context->streams[i];
 
if (local_dc_state->streams[i] &&
-   is_timing_changed(stream, local_dc_state->streams[i])) {
+   dc_is_timing_changed(stream, local_dc_state->streams[i])) {
DRM_INFO_ONCE("crtc[%d] needs mode_changed\n", i);
} else {
int ind = find_crtc_index_in_state_by_stream(state, 
stream);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 85d54bfb595c..344533623cb9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1855,7 +1855,7 @@ bool dc_add_all_planes_for_stream(
return add_all_planes_for_stream(dc, stream, , 1, context);
 }
 
-bool is_timing_changed(struct dc_stream_state *cur_stream,
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
   struct dc_stream_state *new_stream)
 {
if (cur_stream == NULL)
@@ -1880,7 +1880,7 @@ static bool are_stream_backends_same(
if (stream_a == NULL || stream_b == NULL)
return false;
 
-   if (is_timing_changed(stream_a, stream_b))
+   if (dc_is_timing_changed(stream_a, stream_b))
return false;
 
if (stream_a->signal != stream_b->signal)
@@ -3505,7 +3505,7 @@ bool pipe_need_reprogram(
if (pipe_ctx_old->stream_res.stream_enc != 
pipe_ctx->stream_res.stream_enc)
return true;
 
-   if (is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
+   if (dc_is_timing_changed(pipe_ctx_old->stream, pipe_ctx->stream))
return true;
 
if (pipe_ctx_old->stream->dpms_off != pipe_ctx->stream->dpms_off)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 23ee63b98dcd..e7ab6cb3769b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -2225,4 +2225,7 @@ void dc_process_dmub_dpia_hpd_int_enable(const struct dc 
*dc,
 /* Disable acc mode Interfaces */
 void dc_disable_accelerated_mode(struct dc *dc);
 
+bool dc_is_timing_changed(struct dc_stream_state *cur_stream,
+  struct dc_stream_state *new_stream);
+
 #endif /* DC_INTERFACE_H_ */
-- 
2.39.2



[PATCH 1/2] drm/amd/display: mark dccg314_init() static

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

The newly introduced global function is not declared in a header or
called from another file, causing a harmless warning with sparse
or W=1 builds:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error: no 
previous prototype for 'dccg314_init' [-Werror=missing-prototypes]

Mark it static instead.

Fixes: 6f6869dcf415 ("drm/amd/display: prep work for root clock optimization 
enablement for DCN314")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c 
b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
index 6f879265ad9c..de7bfba2c179 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
@@ -274,7 +274,7 @@ static void dccg314_set_dpstreamclk(
}
 }
 
-void dccg314_init(struct dccg *dccg)
+static void dccg314_init(struct dccg *dccg)
 {
int otg_inst;
 
-- 
2.39.2



[PATCH] drm/radeon: move prototypes to header

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

Global functions in radeon_atpx_handler.c are not declared in a header
but instead in each file using them. This risks the types getting out
of sync and causes warnings:

drivers/gpu/drm/radeon/radeon_atpx_handler.c:64:6: error: no previous prototype 
for 'radeon_has_atpx' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:68:6: error: no previous prototype 
for 'radeon_has_atpx_dgpu_power_cntl' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:72:6: error: no previous prototype 
for 'radeon_is_atpx_hybrid' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:76:6: error: no previous prototype 
for 'radeon_atpx_dgpu_req_power_for_displays' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:594:6: error: no previous 
prototype for 'radeon_register_atpx_handler' [-Werror=missing-prototypes]
drivers/gpu/drm/radeon/radeon_atpx_handler.c:612:6: error: no previous 
prototype for 'radeon_unregister_atpx_handler' [-Werror=missing-prototypes]

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/radeon/radeon.h  | 18 ++
 drivers/gpu/drm/radeon/radeon_acpi.c |  6 --
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |  1 +
 drivers/gpu/drm/radeon/radeon_device.c   |  8 
 drivers/gpu/drm/radeon/radeon_drv.c  | 13 -
 drivers/gpu/drm/radeon/radeon_kms.c  |  6 --
 6 files changed, 19 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8afb03bbce29..74fb4dfc3e5e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2964,6 +2964,24 @@ void radeon_irq_kms_set_irq_n_enabled(struct 
radeon_device *rdev,
 void radeon_audio_component_init(struct radeon_device *rdev);
 void radeon_audio_component_fini(struct radeon_device *rdev);
 
+/* atpx handler */
+#if defined(CONFIG_VGA_SWITCHEROO)
+bool radeon_has_atpx(void);
+void radeon_register_atpx_handler(void);
+void radeon_unregister_atpx_handler(void);
+bool radeon_has_atpx_dgpu_power_cntl(void);
+bool radeon_is_atpx_hybrid(void);
+bool radeon_atpx_dgpu_req_power_for_displays(void);
+#else
+static inline bool radeon_has_atpx(void) { return false; }
+static inline void radeon_register_atpx_handler(void) {}
+static inline void radeon_unregister_atpx_handler(void) {}
+static inline bool radeon_has_atpx_dgpu_power_cntl(void) { return false; }
+static inline bool radeon_is_atpx_hybrid(void) { return false; }
+static inline bool radeon_atpx_dgpu_req_power_for_displays(void) { return 
false; }
+#endif
+
+
 #include "radeon_object.h"
 
 #endif
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c 
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 5771d1fcb073..695c673eb9f6 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -38,12 +38,6 @@
 #include "radeon_acpi.h"
 #include "radeon_pm.h"
 
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_atpx_dgpu_req_power_for_displays(void);
-#else
-static inline bool radeon_atpx_dgpu_req_power_for_displays(void) { return 
false; }
-#endif
-
 #define ACPI_AC_CLASS   "ac_adapter"
 
 struct atif_verify_interface {
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 6f93f54bf651..dfd30558f8e8 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -12,6 +12,7 @@
 #include 
 
 #include "radeon_acpi.h"
+#include "radeon.h"
 
 struct radeon_atpx_functions {
bool px_params;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index afbb3a80c0c6..180f8aa971b4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -113,14 +113,6 @@ static const char radeon_family_name[][16] = {
"LAST",
 };
 
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_has_atpx_dgpu_power_cntl(void);
-bool radeon_is_atpx_hybrid(void);
-#else
-static inline bool radeon_has_atpx_dgpu_power_cntl(void) { return false; }
-static inline bool radeon_is_atpx_hybrid(void) { return false; }
-#endif
-
 #define RADEON_PX_QUIRK_DISABLE_PX  (1 << 0)
 
 struct radeon_px_quirk {
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index e4374814f0ef..d8d75b347678 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -128,19 +128,6 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
 
-/* atpx handler */
-#if defined(CONFIG_VGA_SWITCHEROO)
-void radeon_register_atpx_handler(void);
-void radeon_unregister_atpx_handler(void);
-bool radeon_has_atpx_dgpu_power_cntl(void);
-bool radeon_is_atpx_hybrid(void);
-#else
-static inline void radeon_register_atpx_handler(void) {}
-static 

[PATCH] drm/exynos: fix g2d_open/close helper function definitions

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

The empty stub functions are defined as global functions, which
causes a warning because of missing prototypes:

drivers/gpu/drm/exynos/exynos_drm_g2d.h:37:5: error: no previous prototype for 
'g2d_open'
drivers/gpu/drm/exynos/exynos_drm_g2d.h:42:5: error: no previous prototype for 
'g2d_close'

Mark them as 'static inline' to avoid the warning and to make
them behave as intended.

Fixes: eb4d9796fa34 ("drm/exynos: g2d: Convert to driver component API")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.h 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.h
index 74ea3c26dead..1a5ae781b56c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.h
@@ -34,11 +34,11 @@ static inline int exynos_g2d_exec_ioctl(struct drm_device 
*dev, void *data,
return -ENODEV;
 }
 
-int g2d_open(struct drm_device *drm_dev, struct drm_file *file)
+static inline int g2d_open(struct drm_device *drm_dev, struct drm_file *file)
 {
return 0;
 }
 
-void g2d_close(struct drm_device *drm_dev, struct drm_file *file)
+static inline void g2d_close(struct drm_device *drm_dev, struct drm_file *file)
 { }
 #endif
-- 
2.39.2



[PATCH] drm/nouveau: dispnv50: fix missing-prototypes warning

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

nv50_display_create() is declared in another header, along with
a couple of declarations that are now outdated:

drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype 
for 'nv50_display_create'

Fixes: ba801ef068c1 ("drm/nouveau/kms: display destroy/init/fini hooks can be 
static")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 +
 drivers/gpu/drm/nouveau/nv50_display.h  | 4 +---
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 5bb777ff1313..9b6824f6b9e4 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -64,6 +64,7 @@
 #include "nouveau_connector.h"
 #include "nouveau_encoder.h"
 #include "nouveau_fence.h"
+#include "nv50_display.h"
 
 #include 
 
diff --git a/drivers/gpu/drm/nouveau/nv50_display.h 
b/drivers/gpu/drm/nouveau/nv50_display.h
index fbd3b15583bc..60f77766766e 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.h
+++ b/drivers/gpu/drm/nouveau/nv50_display.h
@@ -31,7 +31,5 @@
 #include "nouveau_reg.h"
 
 int  nv50_display_create(struct drm_device *);
-void nv50_display_destroy(struct drm_device *);
-int  nv50_display_init(struct drm_device *);
-void nv50_display_fini(struct drm_device *);
+
 #endif /* __NV50_DISPLAY_H__ */
-- 
2.39.2



[PATCH] drm/nouveau: remove unused tu102_gr_load() function

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

tu102_gr_load() is completely unused and can be removed to address
this warning:

drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype 
for 'nv50_display_create'

Fixes: 1cd97b5490c8 ("drm/nouveau/gr/tu102-: use sw_veid_bundle_init from 
firmware")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
index 3b6c8100a242..a7775aa18541 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
@@ -206,19 +206,6 @@ tu102_gr_av_to_init_veid(struct nvkm_blob *blob, struct 
gf100_gr_pack **ppack)
return gk20a_gr_av_to_init_(blob, 64, 0x0010, ppack);
 }
 
-int
-tu102_gr_load(struct gf100_gr *gr, int ver, const struct gf100_gr_fwif *fwif)
-{
-   int ret;
-
-   ret = gm200_gr_load(gr, ver, fwif);
-   if (ret)
-   return ret;
-
-   return gk20a_gr_load_net(gr, "gr/", "sw_veid_bundle_init", ver, 
tu102_gr_av_to_init_veid,
->bundle_veid);
-}
-
 static const struct gf100_gr_fwif
 tu102_gr_fwif[] = {
{  0, gm200_gr_load, _gr, _gr_fecs_acr, _gr_gpccs_acr 
},
-- 
2.39.2



[PATCH] backlight: corgi_lcd: fix missing prototype

2023-04-17 Thread Arnd Bergmann
From: Arnd Bergmann 

The corgi_lcd_limit_intensity() function is called from platform
and defined in a driver, but the driver does not see the declaration:

drivers/video/backlight/corgi_lcd.c:434:6: error: no previous prototype for 
'corgi_lcd_limit_intensity' [-Werror=missing-prototypes]
  434 | void corgi_lcd_limit_intensity(int limit)

Move the prototype into a header that can be included from both
sides to shut up the warning.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-pxa/sharpsl_pm.h | 1 -
 arch/arm/mach-pxa/spitz_pm.c   | 1 +
 include/linux/spi/corgi_lcd.h  | 2 ++
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-pxa/sharpsl_pm.h b/arch/arm/mach-pxa/sharpsl_pm.h
index 9429900db0bb..eff9a74e787f 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.h
+++ b/arch/arm/mach-pxa/sharpsl_pm.h
@@ -105,5 +105,4 @@ void sharpsl_pm_led(int val);
 #define MAX_ACIN_VOLT   6u
 int sharpsl_pm_pxa_read_max(int channel);
 
-void corgi_lcd_limit_intensity(int limit);
 #endif
diff --git a/arch/arm/mach-pxa/spitz_pm.c b/arch/arm/mach-pxa/spitz_pm.c
index c783696e13b9..9571f2b5b118 100644
--- a/arch/arm/mach-pxa/spitz_pm.c
+++ b/arch/arm/mach-pxa/spitz_pm.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/include/linux/spi/corgi_lcd.h b/include/linux/spi/corgi_lcd.h
index 0b857616919c..fc6c1515dc54 100644
--- a/include/linux/spi/corgi_lcd.h
+++ b/include/linux/spi/corgi_lcd.h
@@ -15,4 +15,6 @@ struct corgi_lcd_platform_data {
void (*kick_battery)(void);
 };
 
+void corgi_lcd_limit_intensity(int limit);
+
 #endif /* __LINUX_SPI_CORGI_LCD_H */
-- 
2.39.2



[PATCH v2] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Hamza Mahfooz
Currently, on a handful of ASICs. We allow the framebuffer for a given
plane to exist in either VRAM or GTT. However, if the plane's new
framebuffer is in a different memory domain than it's previous
framebuffer, flipping between them can cause the screen to flicker. So,
to fix this, don't perform an immediate flip in the aforementioned case.

Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2354
Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)")
Signed-off-by: Hamza Mahfooz 
---
v2: make a number of clarifications to the commit message and drop
locking.
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 16 ++--
 1 file changed, 14 insertions(+), 2 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 da3045fdcb6d..fd1b323f0e85 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7897,6 +7897,13 @@ static void amdgpu_dm_commit_cursors(struct 
drm_atomic_state *state)
amdgpu_dm_plane_handle_cursor_update(plane, 
old_plane_state);
 }
 
+static inline uint32_t get_mem_type(struct drm_framebuffer *fb)
+{
+   struct amdgpu_bo *abo = gem_to_amdgpu_bo(fb->obj[0]);
+
+   return abo->tbo.resource ? abo->tbo.resource->mem_type : 0;
+}
+
 static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
struct dc_state *dc_state,
struct drm_device *dev,
@@ -7916,6 +7923,7 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, 
pcrtc));
int planes_count = 0, vpos, hpos;
unsigned long flags;
+   uint32_t mem_type;
u32 target_vblank, last_flip_vblank;
bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
bool cursor_update = false;
@@ -8035,13 +8043,17 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
}
}
 
+   mem_type = get_mem_type(old_plane_state->fb);
+
/*
 * Only allow immediate flips for fast updates that don't
-* change FB pitch, DCC state, rotation or mirroing.
+* change memory domain, FB pitch, DCC state, rotation or
+* mirroring.
 */
bundle->flip_addrs[planes_count].flip_immediate =
crtc->state->async_flip &&
-   acrtc_state->update_type == UPDATE_TYPE_FAST;
+   acrtc_state->update_type == UPDATE_TYPE_FAST &&
+   (!mem_type || get_mem_type(fb) == mem_type);
 
timestamp_ns = ktime_get_ns();
bundle->flip_addrs[planes_count].flip_timestamp_in_us = 
div_u64(timestamp_ns, 1000);
-- 
2.40.0



Re: [RFC 0/3] drm: Add comm/cmdline fdinfo fields

2023-04-17 Thread Rob Clark
On Mon, Apr 17, 2023 at 1:12 PM Rob Clark  wrote:
>
> From: Rob Clark 
>
> When many of the things using the GPU are processes in a VM guest, the
> actual client process is just a proxy.  The msm driver has a way to let
> the proxy tell the kernel the actual VM client process's executable name
> and command-line, which has until now been used simply for GPU crash
> devcore dumps.  Lets also expose this via fdinfo so that tools can
> expose who the actual user of the GPU is.

I should have also mentioned, in the VM/proxy scenario we have a
single process with separate drm_file's for each guest VM process.  So
it isn't an option to just change the proxy process's name to match
the client.

> Rob Clark (3):
>   drm/doc: Relax fdinfo string constraints
>   drm/msm: Rework get_comm_cmdline() helper
>   drm/msm: Add comm/cmdline fields
>
>  Documentation/gpu/drm-usage-stats.rst   | 37 +++--
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c |  4 +--
>  drivers/gpu/drm/msm/msm_drv.c   |  2 ++
>  drivers/gpu/drm/msm/msm_gpu.c   | 27 +-
>  drivers/gpu/drm/msm/msm_gpu.h   | 12 ++--
>  drivers/gpu/drm/msm/msm_submitqueue.c   |  1 +
>  6 files changed, 58 insertions(+), 25 deletions(-)
>
> --
> 2.39.2
>


[PATCH v2 10/17] drm/msm/dpu: Disable pingpong TE on DPU 5.0.0 and above

2023-04-17 Thread Marijn Suijten
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block.  Writing these registers has no
effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
flag.  This flag is only added to PINGPONG blocks used by hardware prior
to 5.0.0.

The existing PP_BLK_TE macro has been removed in favour of directly
passing this feature flag, which has thus far been the only difference
with PP_BLK.  PP_BLK_DITHER has been left in place as its embedded
feature flag already excludes this DPU_PINGPONG_TE bit and differs by
setting the block length to zero, as it only contains a DITHER subblock.

The code that writes to these registers in the INTF block will follow in
subsequent patches.

Signed-off-by: Marijn Suijten 
---
 .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h|  8 +++
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h |  8 +++
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 12 +--
 .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 12 +--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 12 +--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h |  4 ++--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h |  2 +-
 .../drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h|  2 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 12 +--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h |  8 +++
 .../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h   | 24 ++---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 16 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 25 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c| 12 ++-
 14 files changed, 78 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 2b3ae84057df..b7845591c384 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -112,16 +112,16 @@ static const struct dpu_lm_cfg msm8998_lm[] = {
 };
 
 static const struct dpu_pingpong_cfg msm8998_pp[] = {
-   PP_BLK_TE("pingpong_0", PINGPONG_0, 0x7, 0, sdm845_pp_sblk_te,
+   PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SDM845_TE2_MASK, 0, 
sdm845_pp_sblk_te,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
-   PP_BLK_TE("pingpong_1", PINGPONG_1, 0x70800, 0, sdm845_pp_sblk_te,
+   PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SDM845_TE2_MASK, 0, 
sdm845_pp_sblk_te,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
-   PP_BLK("pingpong_2", PINGPONG_2, 0x71000, 0, sdm845_pp_sblk,
+   PP_BLK("pingpong_2", PINGPONG_2, 0x71000, PINGPONG_SDM845_MASK, 0, 
sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 14)),
-   PP_BLK("pingpong_3", PINGPONG_3, 0x71800, 0, sdm845_pp_sblk,
+   PP_BLK("pingpong_3", PINGPONG_3, 0x71800, PINGPONG_SDM845_MASK, 0, 
sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
 };
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index ceca741e93c9..5b9b3b99f1b5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -110,16 +110,16 @@ static const struct dpu_lm_cfg sdm845_lm[] = {
 };
 
 static const struct dpu_pingpong_cfg sdm845_pp[] = {
-   PP_BLK_TE("pingpong_0", PINGPONG_0, 0x7, 0, sdm845_pp_sblk_te,
+   PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SDM845_TE2_MASK, 0, 
sdm845_pp_sblk_te,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
-   PP_BLK_TE("pingpong_1", PINGPONG_1, 0x70800, 0, sdm845_pp_sblk_te,
+   PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SDM845_TE2_MASK, 0, 
sdm845_pp_sblk_te,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
-   PP_BLK("pingpong_2", PINGPONG_2, 0x71000, 0, sdm845_pp_sblk,
+   PP_BLK("pingpong_2", PINGPONG_2, 0x71000, PINGPONG_SDM845_MASK, 0, 
sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 14)),
-   PP_BLK("pingpong_3", PINGPONG_3, 0x71800, 0, sdm845_pp_sblk,
+   PP_BLK("pingpong_3", PINGPONG_3, 0x71800, PINGPONG_SDM845_MASK, 0, 
sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
 };
diff --git 

[PATCH v2 09/17] drm/msm/dpu: Move autorefresh disable from CMD encoder to pingpong

2023-04-17 Thread Marijn Suijten
This autorefresh disable logic in the physical command-mode encoder
consumes three callbacks to the pingpong block, and will explode in
unnecessary complexity when the same callbacks need to be called on the
interface block instead to accommodate INTF TE support.  To clean this
up, move the logic into the pingpong block under a disable_autorefresh
callback, replacing the aforementioned three get_autorefresh,
setup_autorefresh and get_vsync_info callbacks.

The same logic will have to be replicated to the interface block when it
receives INTF TE support, but it is less complex than constantly
switching on a "has_intf_te" boolean to choose a callback.

Suggested-by: Dmitry Baryshkov 
Signed-off-by: Marijn Suijten 
---
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   | 60 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c| 47 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h| 25 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|  4 ++
 4 files changed, 57 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 74470d068622..a60fb8d3736b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -36,10 +36,6 @@
 #define DEFAULT_TEARCHECK_SYNC_THRESH_START4
 #define DEFAULT_TEARCHECK_SYNC_THRESH_CONTINUE 4
 
-#define DPU_ENC_WR_PTR_START_TIMEOUT_US 2
-
-#define DPU_ENC_MAX_POLL_TIMEOUT_US2000
-
 static void dpu_encoder_phys_cmd_enable_te(struct dpu_encoder_phys *phys_enc);
 
 static bool dpu_encoder_phys_cmd_is_master(struct dpu_encoder_phys *phys_enc)
@@ -574,28 +570,8 @@ static void dpu_encoder_phys_cmd_prepare_for_kickoff(
atomic_read(_enc->pending_kickoff_cnt));
 }
 
-static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
-   struct dpu_encoder_phys *phys_enc)
-{
-   struct dpu_hw_pp_vsync_info info;
-
-   if (!phys_enc)
-   return false;
-
-   phys_enc->hw_pp->ops.get_vsync_info(phys_enc->hw_pp, );
-   if (info.wr_ptr_line_count > 0 &&
-   info.wr_ptr_line_count < phys_enc->cached_mode.vdisplay)
-   return true;
-
-   return false;
-}
-
 static void dpu_encoder_phys_cmd_enable_te(struct dpu_encoder_phys *phys_enc)
 {
-   struct dpu_encoder_phys_cmd *cmd_enc =
-   to_dpu_encoder_phys_cmd(phys_enc);
-   int trial = 0;
-
if (!phys_enc)
return;
if (!phys_enc->hw_pp)
@@ -603,37 +579,11 @@ static void dpu_encoder_phys_cmd_enable_te(struct 
dpu_encoder_phys *phys_enc)
if (!dpu_encoder_phys_cmd_is_master(phys_enc))
return;
 
-   /* If autorefresh is already disabled, we have nothing to do */
-   if (!phys_enc->hw_pp->ops.get_autorefresh(phys_enc->hw_pp, NULL))
-   return;
-
-   /*
-* If autorefresh is enabled, disable it and make sure it is safe to
-* proceed with current frame commit/push. Sequence fallowed is,
-* 1. Disable TE
-* 2. Disable autorefresh config
-* 4. Poll for frame transfer ongoing to be false
-* 5. Enable TE back
-*/
-   _dpu_encoder_phys_cmd_connect_te(phys_enc, false);
-   phys_enc->hw_pp->ops.setup_autorefresh(phys_enc->hw_pp, 0, false);
-
-   do {
-   udelay(DPU_ENC_MAX_POLL_TIMEOUT_US);
-   if ((trial * DPU_ENC_MAX_POLL_TIMEOUT_US)
-   > (KICKOFF_TIMEOUT_MS * USEC_PER_MSEC)) {
-   DPU_ERROR_CMDENC(cmd_enc,
-   "disable autorefresh failed\n");
-   break;
-   }
-
-   trial++;
-   } while (dpu_encoder_phys_cmd_is_ongoing_pptx(phys_enc));
-
-   _dpu_encoder_phys_cmd_connect_te(phys_enc, true);
-
-   DPU_DEBUG_CMDENC(to_dpu_encoder_phys_cmd(phys_enc),
-"disabled autorefresh\n");
+   if (phys_enc->hw_pp->ops.disable_autorefresh) {
+   phys_enc->hw_pp->ops.disable_autorefresh(phys_enc->hw_pp,
+
DRMID(phys_enc->parent),
+
phys_enc->cached_mode.vdisplay);
+   }
 }
 
 static int _dpu_encoder_phys_cmd_wait_for_ctl_start(
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index b18efd640abd..dea270c0936f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -228,6 +228,49 @@ static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong 
*pp)
return line;
 }
 
+static void dpu_hw_pp_disable_autorefresh(struct dpu_hw_pingpong *pp,
+ uint32_t encoder_id, u16 vdisplay)
+{
+   struct dpu_hw_pp_vsync_info info;
+   int trial = 0;
+

[PATCH v2 11/17] drm/msm/dpu: Disable MDP vsync source selection on DPU 5.0.0 and above

2023-04-17 Thread Marijn Suijten
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block, including vsync source selection
that was previously part of MDP top.  Writing to the MDP_VSYNC_SEL
register has no effect anymore and is omitted downstream via the
DPU/SDE_MDP_VSYNC_SEL feature flag.  This flag is only added to INTF
blocks used by hardware prior to 5.0.0.

The code that writes to these registers in the INTF block will follow in
subsequent patches.

Signed-off-by: Marijn Suijten 
Reviewed-by: Dmitry Baryshkov 
---
 .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h|  2 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  3 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 52 +++---
 4 files changed, 41 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index b7845591c384..6906f8046b9e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -30,7 +30,7 @@ static const struct dpu_mdp_cfg msm8998_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
.base = 0x0, .len = 0x458,
-   .features = 0,
+   .features = BIT(DPU_MDP_VSYNC_SEL),
.clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
.clk_ctrls[DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0 },
.clk_ctrls[DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0 },
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index 5b9b3b99f1b5..14ce397800d5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -30,7 +30,7 @@ static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
.base = 0x0, .len = 0x45c,
-   .features = BIT(DPU_MDP_AUDIO_SELECT),
+   .features = BIT(DPU_MDP_AUDIO_SELECT) | BIT(DPU_MDP_VSYNC_SEL),
.clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0 },
.clk_ctrls[DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0 },
.clk_ctrls[DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0 },
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 71584cd56fd7..599e177b89dd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -48,6 +48,8 @@ enum {
  * @DPU_MDP_UBWC_1_5,  Universal Bandwidth compression version 1.5
  * @DPU_MDP_PERIPH_0_REMOVED Indicates that access to periph top0 block results
  *in a failure
+ * @DPU_MDP_VSYNC_SEL  Enables vsync source selection via MDP_VSYNC_SEL 
register
+ * (moved into INTF block since DPU 5.0.0)
  * @DPU_MDP_MAXMaximum value
 
  */
@@ -59,6 +61,7 @@ enum {
DPU_MDP_UBWC_1_5,
DPU_MDP_AUDIO_SELECT,
DPU_MDP_PERIPH_0_REMOVED,
+   DPU_MDP_VSYNC_SEL,
DPU_MDP_MAX
 };
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
index 2bb02e17ee52..9ea15a647a66 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
@@ -126,28 +126,16 @@ static void dpu_hw_get_danger_status(struct dpu_hw_mdp 
*mdp,
status->sspp[SSPP_CURSOR1] = (value >> 26) & 0x3;
 }
 
-static void dpu_hw_setup_vsync_source(struct dpu_hw_mdp *mdp,
+static void dpu_hw_setup_vsync_source_v1(struct dpu_hw_mdp *mdp,
struct dpu_vsync_source_cfg *cfg)
 {
struct dpu_hw_blk_reg_map *c;
-   u32 reg, wd_load_value, wd_ctl, wd_ctl2, i;
-   static const u32 pp_offset[PINGPONG_MAX] = {0xC, 0x8, 0x4, 0x13, 0x18};
+   u32 reg, wd_load_value, wd_ctl, wd_ctl2;
 
-   if (!mdp || !cfg || (cfg->pp_count > ARRAY_SIZE(cfg->ppnumber)))
+   if (!mdp || !cfg)
return;
 
c = >hw;
-   reg = DPU_REG_READ(c, MDP_VSYNC_SEL);
-   for (i = 0; i < cfg->pp_count; i++) {
-   int pp_idx = cfg->ppnumber[i] - PINGPONG_0;
-
-   if (pp_idx >= ARRAY_SIZE(pp_offset))
-   continue;
-
-   reg &= ~(0xf << pp_offset[pp_idx]);
-   reg |= (cfg->vsync_source & 0xf) << pp_offset[pp_idx];
-   }
-   DPU_REG_WRITE(c, MDP_VSYNC_SEL, reg);
 
if (cfg->vsync_source >= DPU_VSYNC_SOURCE_WD_TIMER_4 &&
cfg->vsync_source <= DPU_VSYNC_SOURCE_WD_TIMER_0) {
@@ -194,6 +182,33 @@ static void dpu_hw_setup_vsync_source(struct dpu_hw_mdp 
*mdp,
}
 }
 
+static void dpu_hw_setup_vsync_source(struct dpu_hw_mdp *mdp,
+   struct dpu_vsync_source_cfg *cfg)
+{
+   struct dpu_hw_blk_reg_map *c;
+   u32 reg, i;
+

[PATCH v2 14/17] drm/msm/dpu: Document and enable TEAR interrupts on DSI interfaces

2023-04-17 Thread Marijn Suijten
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block.  Wire up these interrupts
and IRQ masks on all supported hardware.

Signed-off-by: Marijn Suijten 
---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 12 ++
 .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 12 ++
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 12 ++
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h |  8 ---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h |  8 ---
 .../drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h|  8 ---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 12 ++
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h |  6 +++--
 .../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h   | 12 ++
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 12 ++
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 12 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 15 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  6 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c  | 27 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h  |  4 
 15 files changed, 125 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index e0f62f84b3cf..e8d25a45d6b3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -165,12 +165,14 @@ static const struct dpu_intf_cfg sm8150_intf[] = {
INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP, 0, 24, 
INTF_SC7180_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25)),
-   INTF_BLK("intf_1", INTF_1, 0x6a800, 0x2bc, INTF_DSI, 0, 24, 
INTF_SC7180_MASK,
+   INTF_BLK_DSI_TE("intf_1", INTF_1, 0x6a800, 0x2bc, INTF_DSI, 0, 24, 
INTF_SC7180_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27)),
-   INTF_BLK("intf_2", INTF_2, 0x6b000, 0x2bc, INTF_DSI, 1, 24, 
INTF_SC7180_MASK,
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
+   DPU_IRQ_IDX(MDP_INTF1_TEAR_INTR, 2)),
+   INTF_BLK_DSI_TE("intf_2", INTF_2, 0x6b000, 0x2bc, INTF_DSI, 1, 24, 
INTF_SC7180_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29)),
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29),
+   DPU_IRQ_IDX(MDP_INTF2_TEAR_INTR, 2)),
INTF_BLK("intf_3", INTF_3, 0x6b800, 0x280, INTF_DP, 1, 24, 
INTF_SC7180_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 31)),
@@ -236,7 +238,9 @@ const struct dpu_mdss_cfg dpu_sm8150_cfg = {
 BIT(MDP_SSPP_TOP0_HIST_INTR) | \
 BIT(MDP_INTF0_INTR) | \
 BIT(MDP_INTF1_INTR) | \
+BIT(MDP_INTF1_TEAR_INTR) | \
 BIT(MDP_INTF2_INTR) | \
+BIT(MDP_INTF2_TEAR_INTR) | \
 BIT(MDP_INTF3_INTR) | \
 BIT(MDP_AD4_0_INTR) | \
 BIT(MDP_AD4_1_INTR),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index fbcfbbd74875..62857288ad91 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -146,12 +146,14 @@ static const struct dpu_intf_cfg sc8180x_intf[] = {
INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP, 
MSM_DP_CONTROLLER_0, 24, INTF_SC7180_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25)),
-   INTF_BLK("intf_1", INTF_1, 0x6a800, 0x2bc, INTF_DSI, 0, 24, 
INTF_SC7180_MASK,
+   INTF_BLK_DSI_TE("intf_1", INTF_1, 0x6a800, 0x2bc, INTF_DSI, 0, 24, 
INTF_SC7180_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27)),
-   INTF_BLK("intf_2", INTF_2, 0x6b000, 0x2bc, INTF_DSI, 1, 24, 
INTF_SC7180_MASK,
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27),
+   DPU_IRQ_IDX(MDP_INTF1_TEAR_INTR, 2)),
+   INTF_BLK_DSI_TE("intf_2", INTF_2, 0x6b000, 0x2bc, INTF_DSI, 1, 24, 
INTF_SC7180_MASK,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29)),
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29),
+   DPU_IRQ_IDX(MDP_INTF2_TEAR_INTR, 2)),
/* INTF_3 is for MST, wired to INTF_DP 0 and 1, use dummy index until 
this is supported */
INTF_BLK("intf_3", INTF_3, 0x6b800, 

[PATCH v2 08/17] drm/msm/dpu: Drop unused poll_timeout_wr_ptr PINGPONG callback

2023-04-17 Thread Marijn Suijten
This callback was migrated from downstream when DPU1 was first
introduced to mainline, but never used by any component.  Drop it to
save some lines and unnecessary confusion.

Suggested-by: Dmitry Baryshkov 
Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 18 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h |  6 --
 2 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 0fcad9760b6f..b18efd640abd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -144,23 +144,6 @@ static bool dpu_hw_pp_get_autorefresh_config(struct 
dpu_hw_pingpong *pp,
return !!((val & BIT(31)) >> 31);
 }
 
-static int dpu_hw_pp_poll_timeout_wr_ptr(struct dpu_hw_pingpong *pp,
-   u32 timeout_us)
-{
-   struct dpu_hw_blk_reg_map *c;
-   u32 val;
-   int rc;
-
-   if (!pp)
-   return -EINVAL;
-
-   c = >hw;
-   rc = readl_poll_timeout(c->blk_addr + PP_LINE_COUNT,
-   val, (val & 0x) >= 1, 10, timeout_us);
-
-   return rc;
-}
-
 static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, bool enable)
 {
struct dpu_hw_blk_reg_map *c;
@@ -280,7 +263,6 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
c->ops.get_vsync_info = dpu_hw_pp_get_vsync_info;
c->ops.setup_autorefresh = dpu_hw_pp_setup_autorefresh_config;
c->ops.get_autorefresh = dpu_hw_pp_get_autorefresh_config;
-   c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
c->ops.get_line_count = dpu_hw_pp_get_line_count;
c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
index c00223441d99..cf94b4ab603b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
@@ -107,12 +107,6 @@ struct dpu_hw_pingpong_ops {
bool (*get_autorefresh)(struct dpu_hw_pingpong *pp,
u32 *frame_count);
 
-   /**
-* poll until write pointer transmission starts
-* @Return: 0 on success, -ETIMEDOUT on timeout
-*/
-   int (*poll_timeout_wr_ptr)(struct dpu_hw_pingpong *pp, u32 timeout_us);
-
/**
 * Obtain current vertical line counter
 */

-- 
2.40.0



[PATCH v2 07/17] drm/msm/dpu: Sort INTF registers numerically

2023-04-17 Thread Marijn Suijten
A bunch of registers were appended at the end in e.g. 91143873a05d
("drm/msm/dpu: Add MISR register support for interface") rather than
being inserted in a place that maintains numerical sorting.  Restore
that.

Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 1d22d7dc99b8..1491568f86fc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -36,6 +36,10 @@
 #define INTF_CONFIG20x060
 #define INTF_DISPLAY_DATA_HCTL  0x064
 #define INTF_ACTIVE_DATA_HCTL   0x068
+
+#define INTF_DSI_CMD_MODE_TRIGGER_EN0x084
+#define INTF_PANEL_FORMAT   0x090
+
 #define INTF_FRAME_LINE_COUNT_EN0x0A8
 #define INTF_FRAME_COUNT0x0AC
 #define INTF_LINE_COUNT 0x0B0
@@ -44,8 +48,6 @@
 #define INTF_DEFLICKER_STRNG_COEFF  0x0F4
 #define INTF_DEFLICKER_WEAK_COEFF   0x0F8
 
-#define INTF_DSI_CMD_MODE_TRIGGER_EN0x084
-#define INTF_PANEL_FORMAT   0x090
 #define INTF_TPG_ENABLE 0x100
 #define INTF_TPG_MAIN_CONTROL   0x104
 #define INTF_TPG_VIDEO_CONFIG   0x108
@@ -57,6 +59,9 @@
 #define INTF_PROG_FETCH_START   0x170
 #define INTF_PROG_ROT_START 0x174
 
+#define INTF_MISR_CTRL  0x180
+#define INTF_MISR_SIGNATURE 0x184
+
 #define INTF_MUX0x25C
 #define INTF_STATUS 0x26C
 
@@ -66,9 +71,6 @@
 #define INTF_CFG2_DATABUS_WIDENBIT(0)
 #define INTF_CFG2_DATA_HCTL_EN BIT(4)
 
-#define INTF_MISR_CTRL 0x180
-#define INTF_MISR_SIGNATURE0x184
-
 static const struct dpu_intf_cfg *_intf_offset(enum dpu_intf intf,
const struct dpu_mdss_cfg *m,
void __iomem *addr,

-- 
2.40.0



[PATCH v2 15/17] drm/msm/dpu: Merge setup_- and enable_tearcheck pingpong callbacks

2023-04-17 Thread Marijn Suijten
These functions are always called consecutively and are best bundled
together for simplicity, especially when the same structure of callbacks
will be replicated later on the interface block for INTF TE support.
The enable_tearcheck(false) case is now replaced with a more obvious
disable_tearcheck(), encapsulating the original register write with 0.

Suggested-by: Dmitry Baryshkov 
Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 10 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c  | 10 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h  | 11 +--
 3 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index a60fb8d3736b..1df3745224f5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -327,8 +327,7 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
 
DPU_DEBUG_CMDENC(cmd_enc, "pp %d\n", phys_enc->hw_pp->idx - PINGPONG_0);
 
-   if (!phys_enc->hw_pp->ops.setup_tearcheck ||
-   !phys_enc->hw_pp->ops.enable_tearcheck) {
+   if (!phys_enc->hw_pp->ops.enable_tearcheck) {
DPU_DEBUG_CMDENC(cmd_enc, "tearcheck not supported\n");
return;
}
@@ -383,8 +382,7 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
phys_enc->hw_pp->idx - PINGPONG_0, tc_cfg.sync_cfg_height,
tc_cfg.sync_threshold_start, tc_cfg.sync_threshold_continue);
 
-   phys_enc->hw_pp->ops.setup_tearcheck(phys_enc->hw_pp, _cfg);
-   phys_enc->hw_pp->ops.enable_tearcheck(phys_enc->hw_pp, tc_enable);
+   phys_enc->hw_pp->ops.enable_tearcheck(phys_enc->hw_pp, _cfg);
 }
 
 static void _dpu_encoder_phys_cmd_pingpong_config(
@@ -511,8 +509,8 @@ static void dpu_encoder_phys_cmd_disable(struct 
dpu_encoder_phys *phys_enc)
return;
}
 
-   if (phys_enc->hw_pp->ops.enable_tearcheck)
-   phys_enc->hw_pp->ops.enable_tearcheck(phys_enc->hw_pp, false);
+   if (phys_enc->hw_pp->ops.disable_tearcheck)
+   phys_enc->hw_pp->ops.disable_tearcheck(phys_enc->hw_pp);
 
if (phys_enc->hw_intf->ops.bind_pingpong_blk) {
phys_enc->hw_intf->ops.bind_pingpong_blk(
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 4a20a5841f22..a5582425bfbb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -91,7 +91,7 @@ static void dpu_hw_pp_setup_dither(struct dpu_hw_pingpong *pp,
DPU_REG_WRITE(c, base + PP_DITHER_EN, 1);
 }
 
-static int dpu_hw_pp_setup_te_config(struct dpu_hw_pingpong *pp,
+static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp,
struct dpu_hw_tear_check *te)
 {
struct dpu_hw_blk_reg_map *c;
@@ -118,6 +118,8 @@ static int dpu_hw_pp_setup_te_config(struct dpu_hw_pingpong 
*pp,
DPU_REG_WRITE(c, PP_SYNC_WRCOUNT,
(te->start_pos + te->sync_threshold_start + 1));
 
+   DPU_REG_WRITE(c, PP_TEAR_CHECK_EN, 1);
+
return 0;
 }
 
@@ -144,7 +146,7 @@ static bool dpu_hw_pp_get_autorefresh_config(struct 
dpu_hw_pingpong *pp,
return !!((val & BIT(31)) >> 31);
 }
 
-static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, bool enable)
+static int dpu_hw_pp_disable_te(struct dpu_hw_pingpong *pp)
 {
struct dpu_hw_blk_reg_map *c;
 
@@ -152,7 +154,7 @@ static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, 
bool enable)
return -EINVAL;
c = >hw;
 
-   DPU_REG_WRITE(c, PP_TEAR_CHECK_EN, enable);
+   DPU_REG_WRITE(c, PP_TEAR_CHECK_EN, 0);
return 0;
 }
 
@@ -301,8 +303,8 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
unsigned long features)
 {
if (test_bit(DPU_PINGPONG_TE, )) {
-   c->ops.setup_tearcheck = dpu_hw_pp_setup_te_config;
c->ops.enable_tearcheck = dpu_hw_pp_enable_te;
+   c->ops.disable_tearcheck = dpu_hw_pp_disable_te;
c->ops.connect_external_te = dpu_hw_pp_connect_external_te;
c->ops.get_line_count = dpu_hw_pp_get_line_count;
c->ops.disable_autorefresh = dpu_hw_pp_disable_autorefresh;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
index 78db18dbda2b..eb426c840ce3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
@@ -37,8 +37,8 @@ struct dpu_hw_dither_cfg {
  *
  * struct dpu_hw_pingpong_ops : Interface to the pingpong Hw driver functions
  *  Assumption is these functions will be called after clocks are enabled
- *  @setup_tearcheck : program tear check values
- *  @enable_tearcheck : 

[PATCH v2 17/17] drm/msm/dpu: Remove intr_rdptr from DPU >= 5.0.0 pingpong config

2023-04-17 Thread Marijn Suijten
Now that newer DPU platforms use a readpointer-done interrupt on the
INTF block, stop providing the unused interrupt on the PINGPONG block.

Signed-off-by: Marijn Suijten 
Reviewed-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h  |  8 
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h |  8 
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h  |  8 
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h  |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h  |  8 
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h  | 10 +-
 7 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index e8d25a45d6b3..a6dbc4c8acb8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -130,16 +130,16 @@ static const struct dpu_dspp_cfg sm8150_dspp[] = {
 static const struct dpu_pingpong_cfg sm8150_pp[] = {
PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SM8150_TE2_MASK, 
MERGE_3D_0, sdm845_pp_sblk_te,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
+   -1),
PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SM8150_TE2_MASK, 
MERGE_3D_0, sdm845_pp_sblk_te,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
+   -1),
PP_BLK("pingpong_2", PINGPONG_2, 0x71000, PINGPONG_SM8150_MASK, 
MERGE_3D_1, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 14)),
+   -1),
PP_BLK("pingpong_3", PINGPONG_3, 0x71800, PINGPONG_SM8150_MASK, 
MERGE_3D_1, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
+   -1),
PP_BLK("pingpong_4", PINGPONG_4, 0x72000, PINGPONG_SM8150_MASK, 
MERGE_3D_2, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30),
-1),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index 62857288ad91..14d5ead8d40c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -118,16 +118,16 @@ static const struct dpu_lm_cfg sc8180x_lm[] = {
 static const struct dpu_pingpong_cfg sc8180x_pp[] = {
PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SM8150_TE2_MASK, 
MERGE_3D_0, sdm845_pp_sblk_te,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
+   -1),
PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SM8150_TE2_MASK, 
MERGE_3D_0, sdm845_pp_sblk_te,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
+   -1),
PP_BLK("pingpong_2", PINGPONG_2, 0x71000, PINGPONG_SM8150_MASK, 
MERGE_3D_1, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 14)),
+   -1),
PP_BLK("pingpong_3", PINGPONG_3, 0x71800, PINGPONG_SM8150_MASK, 
MERGE_3D_1, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
+   -1),
PP_BLK("pingpong_4", PINGPONG_4, 0x72000, PINGPONG_SM8150_MASK, 
MERGE_3D_2, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30),
-1),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
index f77329ab397d..f98ca0f1e4a9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
@@ -131,16 +131,16 @@ static const struct dpu_dspp_cfg sm8250_dspp[] = {
 static const struct dpu_pingpong_cfg sm8250_pp[] = {
PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SM8150_TE2_MASK, 
MERGE_3D_0, sdm845_pp_sblk_te,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
+   -1),
PP_BLK("pingpong_1", PINGPONG_1, 0x70800, PINGPONG_SM8150_TE2_MASK, 
MERGE_3D_0, sdm845_pp_sblk_te,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
-   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
+   -1),
PP_BLK("pingpong_2", PINGPONG_2, 0x71000, 

[PATCH v2 16/17] drm/msm/dpu: Implement tearcheck support on INTF block

2023-04-17 Thread Marijn Suijten
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF.  Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts.

Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  11 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |  10 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   | 160 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 214 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h|  25 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h  |  14 ++
 7 files changed, 378 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1dc5dbe58572..cf1de5d94ce6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -666,6 +666,7 @@ static void _dpu_encoder_update_vsync_source(struct 
dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms;
struct dpu_hw_mdp *hw_mdptop;
struct drm_encoder *drm_enc;
+   struct dpu_encoder_phys *phys_enc;
int i;
 
if (!dpu_enc || !disp_info) {
@@ -696,12 +697,22 @@ static void _dpu_encoder_update_vsync_source(struct 
dpu_encoder_virt *dpu_enc,
vsync_cfg.ppnumber[i] = dpu_enc->hw_pp[i]->idx;
 
vsync_cfg.pp_count = dpu_enc->num_phys_encs;
+   vsync_cfg.frame_rate = 
drm_mode_vrefresh(_enc->base.crtc->state->adjusted_mode);
+
if (disp_info->is_te_using_watchdog_timer)
vsync_cfg.vsync_source = DPU_VSYNC_SOURCE_WD_TIMER_0;
else
vsync_cfg.vsync_source = DPU_VSYNC0_SOURCE_GPIO;
 
hw_mdptop->ops.setup_vsync_source(hw_mdptop, _cfg);
+
+   for (i = 0; i < dpu_enc->num_phys_encs; i++) {
+   phys_enc = dpu_enc->phys_encs[i];
+
+   if (phys_enc->has_intf_te && 
phys_enc->hw_intf->ops.vsync_sel)
+   
phys_enc->hw_intf->ops.vsync_sel(phys_enc->hw_intf,
+   vsync_cfg.vsync_source);
+   }
}
 }
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 1d434b22180d..90f177e43262 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -129,10 +129,10 @@ struct dpu_encoder_phys_ops {
 /**
  * enum dpu_intr_idx - dpu encoder interrupt index
  * @INTR_IDX_VSYNC:Vsync interrupt for video mode panel
- * @INTR_IDX_PINGPONG: Pingpong done unterrupt for cmd mode panel
- * @INTR_IDX_UNDERRUN: Underrun unterrupt for video and cmd mode panel
- * @INTR_IDX_RDPTR:Readpointer done unterrupt for cmd mode panel
- * @INTR_IDX_WB_DONE:  Writeback fone interrupt for virtual connector
+ * @INTR_IDX_PINGPONG: Pingpong done interrupt for cmd mode panel
+ * @INTR_IDX_UNDERRUN: Underrun interrupt for video and cmd mode panel
+ * @INTR_IDX_RDPTR:Readpointer done interrupt for cmd mode panel
+ * @INTR_IDX_WB_DONE:  Writeback done interrupt for virtual connector
  */
 enum dpu_intr_idx {
INTR_IDX_VSYNC,
@@ -176,6 +176,7 @@ enum dpu_intr_idx {
  *  pending.
  * @pending_kickoff_wq:Wait queue for blocking until kickoff 
completes
  * @irq:   IRQ indices
+ * @has_intf_te:   Interface TE configuration support
  */
 struct dpu_encoder_phys {
struct drm_encoder *parent;
@@ -200,6 +201,7 @@ struct dpu_encoder_phys {
atomic_t pending_kickoff_cnt;
wait_queue_head_t pending_kickoff_wq;
int irq[INTR_IDX_MAX];
+   bool has_intf_te;
 };
 
 static inline int dpu_encoder_phys_inc_pending(struct dpu_encoder_phys *phys)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 1df3745224f5..d8ed85a238af 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -97,13 +97,18 @@ static void dpu_encoder_phys_cmd_pp_tx_done_irq(void *arg, 
int irq_idx)
DPU_ATRACE_END("pp_done_irq");
 }
 
-static void dpu_encoder_phys_cmd_pp_rd_ptr_irq(void *arg, int irq_idx)
+static void dpu_encoder_phys_cmd_te_rd_ptr_irq(void *arg, int irq_idx)
 {
struct dpu_encoder_phys *phys_enc = arg;
struct dpu_encoder_phys_cmd *cmd_enc;
 
-   if (!phys_enc->hw_pp)
-   return;
+   if (phys_enc->has_intf_te) {
+   if (!phys_enc->hw_intf)
+   return;
+   } else {
+   if (!phys_enc->hw_pp)
+   return;
+   }
 
DPU_ATRACE_BEGIN("rd_ptr_irq");
 

[PATCH v2 04/17] drm/msm/dpu: Fix PP_BLK_DIPHER -> DITHER typo

2023-04-17 Thread Marijn Suijten
SM8550 only comes with a DITHER subblock inside the PINGPONG block,
hence the name and a block length of zero.  However, the PP_BLK macro
name was typo'd to DIPHER rather than DITHER.

Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 16 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index 9e403034093f..d0ab351b6a8b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -132,28 +132,28 @@ static const struct dpu_dspp_cfg sm8550_dspp[] = {
 _dspp_sblk),
 };
 static const struct dpu_pingpong_cfg sm8550_pp[] = {
-   PP_BLK_DIPHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
-1),
-   PP_BLK_DIPHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
-1),
-   PP_BLK_DIPHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
-1),
-   PP_BLK_DIPHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
-1),
-   PP_BLK_DIPHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30),
-1),
-   PP_BLK_DIPHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, 
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
-1),
-   PP_BLK_DIPHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3, 
sc7280_pp_sblk,
-1,
-1),
-   PP_BLK_DIPHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3, 
sc7280_pp_sblk,
+   PP_BLK_DITHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3, 
sc7280_pp_sblk,
-1,
-1),
 };
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 03f162af1a50..ca8a02debda9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -491,7 +491,7 @@ static const struct dpu_pingpong_sub_blks sc7280_pp_sblk = {
.len = 0x20, .version = 0x2},
 };
 
-#define PP_BLK_DIPHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \
+#define PP_BLK_DITHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \
{\
.name = _name, .id = _id, \
.base = _base, .len = 0, \

-- 
2.40.0



[PATCH v2 12/17] drm/msm/dpu: Move dpu_hw_{tear_check,pp_vsync_info} to dpu_hw_mdss.h

2023-04-17 Thread Marijn Suijten
From: Konrad Dybcio 

Now that newer SoCs since DPU 5.0.0 manage tearcheck in the INTF instead
of PINGPONG block, move the struct definition to a common file. Also,
bring in documentation from msm-4.19 techpack while at it.

Signed-off-by: Konrad Dybcio 
[Marijn: Also move dpu_hw_pp_vsync_info]
Signed-off-by: Marijn Suijten 
Reviewed-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 46 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 22 
 2 files changed, 46 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index 2d9192a6ce00..6ed12fd0505b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -463,4 +463,50 @@ struct dpu_mdss_color {
 #define DPU_DBG_MASK_DSPP (1 << 10)
 #define DPU_DBG_MASK_DSC  (1 << 11)
 
+/**
+ * struct dpu_hw_tear_check - Struct contains parameters to configure
+ * tear-effect module. This structure is used to configure tear-check
+ * logic present either in ping-pong or in interface module.
+ * @vsync_count:Ratio of MDP VSYNC clk freq(Hz) to refresh rate divided
+ *  by no of lines
+ * @sync_cfg_height:Total vertical lines (display height - 1)
+ * @vsync_init_val: Init value to which the read pointer gets loaded at
+ *  vsync edge
+ * @sync_threshold_start:Read pointer threshold start ROI for write 
operation
+ * @sync_threshold_continue: The minimum number of lines the write pointer
+ *   needs to be above the read pointer
+ * @start_pos:  The position from which the start_threshold value is 
added
+ * @rd_ptr_irq: The read pointer line at which interrupt has to be 
generated
+ * @hw_vsync_mode:  Sync with external frame sync input
+ */
+struct dpu_hw_tear_check {
+   /*
+* This is ratio of MDP VSYNC clk freq(Hz) to
+* refresh rate divided by no of lines
+*/
+   u32 vsync_count;
+   u32 sync_cfg_height;
+   u32 vsync_init_val;
+   u32 sync_threshold_start;
+   u32 sync_threshold_continue;
+   u32 start_pos;
+   u32 rd_ptr_irq;
+   u8 hw_vsync_mode;
+};
+
+/**
+ * struct dpu_hw_pp_vsync_info - Struct contains parameters to configure
+ * read and write pointers for command mode panels
+ * @rd_ptr_init_val:Value of rd pointer at vsync edge
+ * @rd_ptr_frame_count: Num frames sent since enabling interface
+ * @rd_ptr_line_count:  Current line on panel (rd ptr)
+ * @wr_ptr_line_count:  Current line within pp fifo (wr ptr)
+ */
+struct dpu_hw_pp_vsync_info {
+   u32 rd_ptr_init_val;
+   u32 rd_ptr_frame_count;
+   u32 rd_ptr_line_count;
+   u32 wr_ptr_line_count;
+};
+
 #endif  /* _DPU_HW_MDSS_H */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
index 851b013c4c4b..78db18dbda2b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
@@ -13,28 +13,6 @@
 
 struct dpu_hw_pingpong;
 
-struct dpu_hw_tear_check {
-   /*
-* This is ratio of MDP VSYNC clk freq(Hz) to
-* refresh rate divided by no of lines
-*/
-   u32 vsync_count;
-   u32 sync_cfg_height;
-   u32 vsync_init_val;
-   u32 sync_threshold_start;
-   u32 sync_threshold_continue;
-   u32 start_pos;
-   u32 rd_ptr_irq;
-   u8 hw_vsync_mode;
-};
-
-struct dpu_hw_pp_vsync_info {
-   u32 rd_ptr_init_val;/* value of rd pointer at vsync edge */
-   u32 rd_ptr_frame_count; /* num frames sent since enabling interface */
-   u32 rd_ptr_line_count;  /* current line on panel (rd ptr) */
-   u32 wr_ptr_line_count;  /* current line within pp fifo (wr ptr) */
-};
-
 /**
  * struct dpu_hw_dither_cfg - dither feature structure
  * @flags: for customizing operations

-- 
2.40.0



[PATCH v2 13/17] drm/msm/dpu: Factor out shared interrupt register in INTF_BLK macro

2023-04-17 Thread Marijn Suijten
As the INTF block is going to attain more interrupts that don't share
the same MDP_SSPP_TOP0_INTR register, factor out the _reg argument for
the caller to construct the right interrupt index (register and bit
index) to not make the interrupt bit arguments depend on one of multiple
interrupt register indices.  This brings us more in line with how PP_BLK
specifies its interrupts and allows for better wrapping in the arrays.

Signed-off-by: Marijn Suijten 
---
 .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 16 +++---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 16 +++---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 16 +++---
 .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 24 +++
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 16 +++---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h |  8 +++--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h |  6 ++--
 .../drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h|  6 ++--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 16 +++---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 12 ++--
 .../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h   | 36 --
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 16 +++---
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 16 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  6 ++--
 14 files changed, 155 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 6906f8046b9e..c0dd4776f539 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -134,10 +134,18 @@ static const struct dpu_dspp_cfg msm8998_dspp[] = {
 };
 
 static const struct dpu_intf_cfg msm8998_intf[] = {
-   INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP, 0, 25, 
INTF_SDM845_MASK, MDP_SSPP_TOP0_INTR, 24, 25),
-   INTF_BLK("intf_1", INTF_1, 0x6a800, 0x280, INTF_DSI, 0, 25, 
INTF_SDM845_MASK, MDP_SSPP_TOP0_INTR, 26, 27),
-   INTF_BLK("intf_2", INTF_2, 0x6b000, 0x280, INTF_DSI, 1, 25, 
INTF_SDM845_MASK, MDP_SSPP_TOP0_INTR, 28, 29),
-   INTF_BLK("intf_3", INTF_3, 0x6b800, 0x280, INTF_HDMI, 0, 25, 
INTF_SDM845_MASK, MDP_SSPP_TOP0_INTR, 30, 31),
+   INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP, 0, 25, 
INTF_SDM845_MASK,
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25)),
+   INTF_BLK("intf_1", INTF_1, 0x6a800, 0x280, INTF_DSI, 0, 25, 
INTF_SDM845_MASK,
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27)),
+   INTF_BLK("intf_2", INTF_2, 0x6b000, 0x280, INTF_DSI, 1, 25, 
INTF_SDM845_MASK,
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29)),
+   INTF_BLK("intf_3", INTF_3, 0x6b800, 0x280, INTF_HDMI, 0, 25, 
INTF_SDM845_MASK,
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 31)),
 };
 
 static const struct dpu_perf_cfg msm8998_perf_data = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index 14ce397800d5..b109757b0672 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -132,10 +132,18 @@ static const struct dpu_dsc_cfg sdm845_dsc[] = {
 };
 
 static const struct dpu_intf_cfg sdm845_intf[] = {
-   INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP, 0, 24, 
INTF_SDM845_MASK, MDP_SSPP_TOP0_INTR, 24, 25),
-   INTF_BLK("intf_1", INTF_1, 0x6a800, 0x280, INTF_DSI, 0, 24, 
INTF_SDM845_MASK, MDP_SSPP_TOP0_INTR, 26, 27),
-   INTF_BLK("intf_2", INTF_2, 0x6b000, 0x280, INTF_DSI, 1, 24, 
INTF_SDM845_MASK, MDP_SSPP_TOP0_INTR, 28, 29),
-   INTF_BLK("intf_3", INTF_3, 0x6b800, 0x280, INTF_DP, 1, 24, 
INTF_SDM845_MASK, MDP_SSPP_TOP0_INTR, 30, 31),
+   INTF_BLK("intf_0", INTF_0, 0x6a000, 0x280, INTF_DP, 0, 24, 
INTF_SDM845_MASK,
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 24),
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 25)),
+   INTF_BLK("intf_1", INTF_1, 0x6a800, 0x280, INTF_DSI, 0, 24, 
INTF_SDM845_MASK,
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 26),
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 27)),
+   INTF_BLK("intf_2", INTF_2, 0x6b000, 0x280, INTF_DSI, 1, 24, 
INTF_SDM845_MASK,
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 28),
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 29)),
+   INTF_BLK("intf_3", INTF_3, 0x6b800, 0x280, INTF_DP, 1, 24, 
INTF_SDM845_MASK,
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 30),
+   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 31)),
 };
 
 static const struct 

[PATCH v2 05/17] drm/msm/dpu: Remove duplicate register defines from INTF

2023-04-17 Thread Marijn Suijten
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
registers are already defined higher up, in the right place when sorted
numerically.

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 84ee2efa9c66..b9dddf576c02 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -56,11 +56,6 @@
 #define   INTF_TPG_RGB_MAPPING  0x11C
 #define   INTF_PROG_FETCH_START 0x170
 #define   INTF_PROG_ROT_START   0x174
-
-#define   INTF_FRAME_LINE_COUNT_EN  0x0A8
-#define   INTF_FRAME_COUNT  0x0AC
-#define   INTF_LINE_COUNT   0x0B0
-
 #define   INTF_MUX  0x25C
 #define   INTF_STATUS   0x26C
 

-- 
2.40.0



[PATCH v2 06/17] drm/msm/dpu: Remove extraneous register define indentation

2023-04-17 Thread Marijn Suijten
A bunch of registers are indented with two extra spaces, looking as if
these are values corresponding to the previous register which is not the
case, rather these are simply also register offsets and should only have
a single space separating them and the #define keyword.

Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 41 +++--
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index b9dddf576c02..1d22d7dc99b8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -38,26 +38,27 @@
 #define INTF_ACTIVE_DATA_HCTL   0x068
 #define INTF_FRAME_LINE_COUNT_EN0x0A8
 #define INTF_FRAME_COUNT0x0AC
-#define   INTF_LINE_COUNT   0x0B0
-
-#define   INTF_DEFLICKER_CONFIG 0x0F0
-#define   INTF_DEFLICKER_STRNG_COEFF0x0F4
-#define   INTF_DEFLICKER_WEAK_COEFF 0x0F8
-
-#define   INTF_DSI_CMD_MODE_TRIGGER_EN  0x084
-#define   INTF_PANEL_FORMAT 0x090
-#define   INTF_TPG_ENABLE   0x100
-#define   INTF_TPG_MAIN_CONTROL 0x104
-#define   INTF_TPG_VIDEO_CONFIG 0x108
-#define   INTF_TPG_COMPONENT_LIMITS 0x10C
-#define   INTF_TPG_RECTANGLE0x110
-#define   INTF_TPG_INITIAL_VALUE0x114
-#define   INTF_TPG_BLK_WHITE_PATTERN_FRAMES   0x118
-#define   INTF_TPG_RGB_MAPPING  0x11C
-#define   INTF_PROG_FETCH_START 0x170
-#define   INTF_PROG_ROT_START   0x174
-#define   INTF_MUX  0x25C
-#define   INTF_STATUS   0x26C
+#define INTF_LINE_COUNT 0x0B0
+
+#define INTF_DEFLICKER_CONFIG   0x0F0
+#define INTF_DEFLICKER_STRNG_COEFF  0x0F4
+#define INTF_DEFLICKER_WEAK_COEFF   0x0F8
+
+#define INTF_DSI_CMD_MODE_TRIGGER_EN0x084
+#define INTF_PANEL_FORMAT   0x090
+#define INTF_TPG_ENABLE 0x100
+#define INTF_TPG_MAIN_CONTROL   0x104
+#define INTF_TPG_VIDEO_CONFIG   0x108
+#define INTF_TPG_COMPONENT_LIMITS   0x10C
+#define INTF_TPG_RECTANGLE  0x110
+#define INTF_TPG_INITIAL_VALUE  0x114
+#define INTF_TPG_BLK_WHITE_PATTERN_FRAMES 0x118
+#define INTF_TPG_RGB_MAPPING0x11C
+#define INTF_PROG_FETCH_START   0x170
+#define INTF_PROG_ROT_START 0x174
+
+#define INTF_MUX0x25C
+#define INTF_STATUS 0x26C
 
 #define INTF_CFG_ACTIVE_H_EN   BIT(29)
 #define INTF_CFG_ACTIVE_V_EN   BIT(30)

-- 
2.40.0



[PATCH v2 02/17] drm/msm/dpu: Remove TE2 block and feature from DPU >= 7.0.0 hardware

2023-04-17 Thread Marijn Suijten
No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
offset downstream.  Even though neither downstream nor upstream utilizes
these registers in any way, remove the erroneous specification for
SC8280XP, SM8350 and SM8450 to prevent confusion.

Note that downstream enables the PPSPLIT (split-FIFO) topology (single
LM for 2 PP and 2 INTF) based on the presence of a TE2 block.

Fixes: f0a1bdf64dd7 ("drm/msm/dpu: Introduce SC8280XP")
Fixes: 0a72f23f6ef8 ("drm/msm/dpu: Add SM8350 to hw catalog")
Fixes: 8cbbc3396065 ("drm/msm/dpu: add support for SM8450")
Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   |  4 ++--
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 12 ++--
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   |  4 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
index ca107ca8de46..41ef0c8fc993 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
@@ -127,10 +127,10 @@ static const struct dpu_dspp_cfg sm8350_dspp[] = {
 };
 
 static const struct dpu_pingpong_cfg sm8350_pp[] = {
-   PP_BLK_TE("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, 
sdm845_pp_sblk_te,
+   PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
-   PP_BLK_TE("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, 
sdm845_pp_sblk_te,
+   PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sdm845_pp_sblk,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
index 9aab110b8c44..12c14d15e386 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
@@ -121,17 +121,17 @@ static const struct dpu_dspp_cfg sc8280xp_dspp[] = {
 };
 
 static const struct dpu_pingpong_cfg sc8280xp_pp[] = {
-   PP_BLK_TE("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, 
sdm845_pp_sblk_te,
+   PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sdm845_pp_sblk,
  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8), -1),
-   PP_BLK_TE("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, 
sdm845_pp_sblk_te,
+   PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sdm845_pp_sblk,
  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9), -1),
-   PP_BLK_TE("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, 
sdm845_pp_sblk_te,
+   PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sdm845_pp_sblk,
  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10), -1),
-   PP_BLK_TE("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, 
sdm845_pp_sblk_te,
+   PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, sdm845_pp_sblk,
  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11), -1),
-   PP_BLK_TE("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, 
sdm845_pp_sblk_te,
+   PP_BLK("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, sdm845_pp_sblk,
  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30), -1),
-   PP_BLK_TE("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, 
sdm845_pp_sblk_te,
+   PP_BLK("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, sdm845_pp_sblk,
  DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31), -1),
 };
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
index 02a259b6b426..e409c119b0a2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
@@ -128,10 +128,10 @@ static const struct dpu_dspp_cfg sm8450_dspp[] = {
 };
 /* FIXME: interrupts */
 static const struct dpu_pingpong_cfg sm8450_pp[] = {
-   PP_BLK_TE("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, 
sdm845_pp_sblk_te,
+   PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
-   PP_BLK_TE("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, 
sdm845_pp_sblk_te,
+   PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sdm845_pp_sblk,

-- 
2.40.0



[PATCH v2 01/17] drm/msm/dpu: Remove unused INTF0 interrupt mask from SM6115/QCM2290

2023-04-17 Thread Marijn Suijten
Neither of these SoCs has INTF0, they only have a DSI interface on index
1.  Stop enabling an interrupt that can't fire.

Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
Fixes: 5334087ee743 ("drm/msm: add support for QCM2290 MDSS")
Signed-off-by: Marijn Suijten 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h  | 1 -
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h
index 6f04d8f85c92..988d820f7ef2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h
@@ -122,7 +122,6 @@ const struct dpu_mdss_cfg dpu_sm6115_cfg = {
.mdss_irqs = BIT(MDP_SSPP_TOP0_INTR) | \
 BIT(MDP_SSPP_TOP0_INTR2) | \
 BIT(MDP_SSPP_TOP0_HIST_INTR) | \
-BIT(MDP_INTF0_INTR) | \
 BIT(MDP_INTF1_INTR),
 };
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h
index 303492d62a5c..c9003dcc1a59 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h
@@ -112,7 +112,6 @@ const struct dpu_mdss_cfg dpu_qcm2290_cfg = {
.mdss_irqs = BIT(MDP_SSPP_TOP0_INTR) | \
 BIT(MDP_SSPP_TOP0_INTR2) | \
 BIT(MDP_SSPP_TOP0_HIST_INTR) | \
-BIT(MDP_INTF0_INTR) | \
 BIT(MDP_INTF1_INTR),
 };
 

-- 
2.40.0



[PATCH v2 03/17] drm/msm/dpu: Move non-MDP_TOP INTF_INTR offsets out of hwio header

2023-04-17 Thread Marijn Suijten
These offsets do not fall under the MDP TOP block and do not fit the
comment right above.  Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 5 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h  | 3 ---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 53326f25e40e..85c0bda3ff90 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -15,7 +15,7 @@
 
 /*
  * Register offsets in MDSS register file for the interrupt registers
- * w.r.t. to the MDP base
+ * w.r.t. the MDP base
  */
 #define MDP_SSPP_TOP0_OFF  0x0
 #define MDP_INTF_0_OFF 0x6A000
@@ -24,6 +24,9 @@
 #define MDP_INTF_3_OFF 0x6B800
 #define MDP_INTF_4_OFF 0x6C000
 #define MDP_INTF_5_OFF 0x6C800
+#define INTF_INTR_EN   0x1c0
+#define INTF_INTR_STATUS   0x1c4
+#define INTF_INTR_CLEAR0x1c8
 #define MDP_AD4_0_OFF  0x7C000
 #define MDP_AD4_1_OFF  0x7D000
 #define MDP_AD4_INTR_EN_OFF0x41c
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
index feb9a729844a..5acd5683d25a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
@@ -21,9 +21,6 @@
 #define HIST_INTR_EN0x01c
 #define HIST_INTR_STATUS0x020
 #define HIST_INTR_CLEAR 0x024
-#define INTF_INTR_EN0x1C0
-#define INTF_INTR_STATUS0x1C4
-#define INTF_INTR_CLEAR 0x1C8
 #define SPLIT_DISPLAY_EN0x2F4
 #define SPLIT_DISPLAY_UPPER_PIPE_CTRL   0x2F8
 #define DSPP_IGC_COLOR0_RAM_LUTN0x300

-- 
2.40.0



[PATCH v2 00/17] drm/msm/dpu: Implement tearcheck support on INTF block

2023-04-17 Thread Marijn Suijten
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF.  Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts.  Additionally, disable previous register writes and remove
unused interrupts in the PINGPONG and MDP_TOP blocks for these newer
platforms.

With these patches the devices on DPU >= 5.0.0 listed below now update
their panels at 60fps without tearing (nor sluggishness), and without
repeated timeouts in dmesg.

Tested on the following devices with command-mode panels and TE pins:

- Sony Xperia XZ3 (sdm845, DPU 4.0.0, cmdmode panel): no regressions on
  PINGPONG TE;
- Sony Xperia 5 (sm8150, DPU 5.0.0);
- Sony Xperia 10 II (sm6125, DPU 5.0.4).

---
Changes in v2:
- Rebase on -next with all the new SC8280XP and SM8[345]50 support;
  - Remove duplicate PP_BLK_TE macro now that .features is an argument;
  - Fix PP_BLK_DIPHER -> DITHER typo that was added recently;
  - Add INTF_TEAR interrupt blocks for DPU 7.0.0 (moved to different
register range);
  - Describe INTF_TEAR support for the newly added SM8350, SM8450,
SM8550 and SC8280XP SoCs;
  - Remove TE2 subblocks from 8[34]50 and sc8280xp (new patch);
- Rebase on -next with DPU catalog rework;
  - Remove dpu_hw_intf_v1_get_status which was inlined in the original
dpu_hw_intf_get_status function in e3969eadc8ee ("drm/msm/disp/dpu:
get timing engine status from intf status register");
  - Many changes to move all catalog edits to separate files;
- Add documentation for DPU_MDP_VSYNC_SEL;
- Fix sdm8150_mdp typo, should be sm8150_mdp;
- Move unrelated INTF_INTR offsets out of hwio header (new patch);
- Remove _reg argument from INTF_BLK, since we now have a third
  interrupt with a different base register.  To prevent confusion all
  three interrupts should provide the final value from DPU_IRQ_IDX
  directly.
- Only request the new tear_rd_ptr in a new INTF_BLK_DSI_TE macro;
- Drop stray INTF_MISR_SIGNATURE register definition;
- Clean up registers in dpu_hw_intf.c (many new patches);
- merged setup_tearcheck() and enable_tearcheck() callbacks;
- replaced enable_tearcheck(false) with new disable_tearcheck()
  callback;
- Moved dpu_encoder_phys_cmd_enable_te intestines (just autorefresh
  disablement) to INTF and PP block, replacing 3 callbacks in both
  blocks with just a single disable_autorefresh() callback.

v1: 
https://lore.kernel.org/r/20221231215006.211860-1-marijn.suij...@somainline.org

---
Konrad Dybcio (1):
  drm/msm/dpu: Move dpu_hw_{tear_check,pp_vsync_info} to dpu_hw_mdss.h

Marijn Suijten (16):
  drm/msm/dpu: Remove unused INTF0 interrupt mask from SM6115/QCM2290
  drm/msm/dpu: Remove TE2 block and feature from DPU >= 7.0.0 hardware
  drm/msm/dpu: Move non-MDP_TOP INTF_INTR offsets out of hwio header
  drm/msm/dpu: Fix PP_BLK_DIPHER -> DITHER typo
  drm/msm/dpu: Remove duplicate register defines from INTF
  drm/msm/dpu: Remove extraneous register define indentation
  drm/msm/dpu: Sort INTF registers numerically
  drm/msm/dpu: Drop unused poll_timeout_wr_ptr PINGPONG callback
  drm/msm/dpu: Move autorefresh disable from CMD encoder to pingpong
  drm/msm/dpu: Disable pingpong TE on DPU 5.0.0 and above
  drm/msm/dpu: Disable MDP vsync source selection on DPU 5.0.0 and above
  drm/msm/dpu: Factor out shared interrupt register in INTF_BLK macro
  drm/msm/dpu: Document and enable TEAR interrupts on DSI interfaces
  drm/msm/dpu: Merge setup_- and enable_tearcheck pingpong callbacks
  drm/msm/dpu: Implement tearcheck support on INTF block
  drm/msm/dpu: Remove intr_rdptr from DPU >= 5.0.0 pingpong config

 .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h|  26 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h |  26 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h |  40 +--
 .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h|  48 ++--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h |  40 +--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h |  16 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h |  15 +-
 .../drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h|  15 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h |  40 +--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h |  22 +-
 .../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h   |  64 +++--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h |  46 ++--
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h |  36 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  11 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |  10 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   | 210 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  48 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   9 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c  |  32 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h  |   4 +
 

[RFC 3/3] drm/msm: Add comm/cmdline fields

2023-04-17 Thread Rob Clark
From: Rob Clark 

Normally this would be the same information that can be obtained in
other ways.  But in some cases the process opening the drm fd is merely
a sort of proxy for the actual process using the GPU.  This is the case
for guest VM processes using the GPU via virglrenderer, in which case
the msm native-context renderer in virglrenderer overrides the comm/
cmdline to be the guest process's values.

Exposing this via fdinfo allows tools like gputop to show something more
meaningful than just a bunch of "pcivirtio-gpu" users.

Signed-off-by: Rob Clark 
---
 Documentation/gpu/drm-usage-stats.rst |  8 
 drivers/gpu/drm/msm/msm_gpu.c | 14 ++
 2 files changed, 22 insertions(+)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index 8e00d53231e0..bc90bed455e3 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -148,6 +148,14 @@ percentage utilization of the engine, whereas 
drm-engine- only reflects
 time active without considering what frequency the engine is operating as a
 percentage of it's maximum frequency.
 
+- drm-comm: 
+
+Returns the clients executable path.
+
+- drm-cmdline: 
+
+Returns the clients cmdline.
+
 Implementation Details
 ==
 
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index f0f4f845c32d..1150dcbf28aa 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -148,12 +148,26 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
return 0;
 }
 
+static void get_comm_cmdline(struct msm_file_private *ctx, char **comm, char 
**cmd);
+
 void msm_gpu_show_fdinfo(struct msm_gpu *gpu, struct msm_file_private *ctx,
 struct drm_printer *p)
 {
+   char *comm, *cmdline;
+
+   get_comm_cmdline(ctx, , );
+
drm_printf(p, "drm-engine-gpu:\t%llu ns\n", ctx->elapsed_ns);
drm_printf(p, "drm-cycles-gpu:\t%llu\n", ctx->cycles);
drm_printf(p, "drm-maxfreq-gpu:\t%u Hz\n", gpu->fast_rate);
+
+   if (comm)
+   drm_printf(p, "drm-comm:\t%s\n", comm);
+   if (cmdline)
+   drm_printf(p, "drm-cmdline:\t%s\n", cmdline);
+
+   kfree(comm);
+   kfree(cmdline);
 }
 
 int msm_gpu_hw_init(struct msm_gpu *gpu)
-- 
2.39.2



[RFC 2/3] drm/msm: Rework get_comm_cmdline() helper

2023-04-17 Thread Rob Clark
From: Rob Clark 

Make it work in terms of ctx so that it can be re-used for fdinfo.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  4 ++--
 drivers/gpu/drm/msm/msm_drv.c   |  2 ++
 drivers/gpu/drm/msm/msm_gpu.c   | 13 ++---
 drivers/gpu/drm/msm/msm_gpu.h   | 12 ++--
 drivers/gpu/drm/msm/msm_submitqueue.c   |  1 +
 5 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index bb38e728864d..43c4e1fea83f 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -412,7 +412,7 @@ int adreno_set_param(struct msm_gpu *gpu, struct 
msm_file_private *ctx,
/* Ensure string is null terminated: */
str[len] = '\0';
 
-   mutex_lock(>lock);
+   mutex_lock(>lock);
 
if (param == MSM_PARAM_COMM) {
paramp = >comm;
@@ -423,7 +423,7 @@ int adreno_set_param(struct msm_gpu *gpu, struct 
msm_file_private *ctx,
kfree(*paramp);
*paramp = str;
 
-   mutex_unlock(>lock);
+   mutex_unlock(>lock);
 
return 0;
}
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 3d73b98d6a9c..ca0e89e46e13 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -581,6 +581,8 @@ static int context_init(struct drm_device *dev, struct 
drm_file *file)
rwlock_init(>queuelock);
 
kref_init(>ref);
+   ctx->pid = get_pid(task_pid(current));
+   mutex_init(>lock);
msm_submitqueue_init(dev, ctx);
 
ctx->aspace = msm_gpu_create_private_address_space(priv->gpu, current);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index c403912d13ab..f0f4f845c32d 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -327,18 +327,17 @@ find_submit(struct msm_ringbuffer *ring, uint32_t fence)
 
 static void retire_submits(struct msm_gpu *gpu);
 
-static void get_comm_cmdline(struct msm_gem_submit *submit, char **comm, char 
**cmd)
+static void get_comm_cmdline(struct msm_file_private *ctx, char **comm, char 
**cmd)
 {
-   struct msm_file_private *ctx = submit->queue->ctx;
struct task_struct *task;
 
-   WARN_ON(!mutex_is_locked(>gpu->lock));
-
/* Note that kstrdup will return NULL if argument is NULL: */
+   mutex_lock(>lock);
*comm = kstrdup(ctx->comm, GFP_KERNEL);
*cmd  = kstrdup(ctx->cmdline, GFP_KERNEL);
+   mutex_unlock(>lock);
 
-   task = get_pid_task(submit->pid, PIDTYPE_PID);
+   task = get_pid_task(ctx->pid, PIDTYPE_PID);
if (!task)
return;
 
@@ -372,7 +371,7 @@ static void recover_worker(struct kthread_work *work)
if (submit->aspace)
submit->aspace->faults++;
 
-   get_comm_cmdline(submit, , );
+   get_comm_cmdline(submit->queue->ctx, , );
 
if (comm && cmd) {
DRM_DEV_ERROR(dev->dev, "%s: offending task: %s (%s)\n",
@@ -460,7 +459,7 @@ static void fault_worker(struct kthread_work *work)
goto resume_smmu;
 
if (submit) {
-   get_comm_cmdline(submit, , );
+   get_comm_cmdline(submit->queue->ctx, , );
 
/*
 * When we get GPU iova faults, we can get 1000s of them,
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 7a4fa1b8655b..b2023a42116b 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -377,17 +377,25 @@ struct msm_file_private {
 */
int sysprof;
 
+   /** @pid: Process that opened this file. */
+   struct pid *pid;
+
+   /**
+* lock: Protects comm and cmdline
+*/
+   struct mutex lock;
+
/**
 * comm: Overridden task comm, see MSM_PARAM_COMM
 *
-* Accessed under msm_gpu::lock
+* Accessed under msm_file_private::lock
 */
char *comm;
 
/**
 * cmdline: Overridden task cmdline, see MSM_PARAM_CMDLINE
 *
-* Accessed under msm_gpu::lock
+* Accessed under msm_file_private::lock
 */
char *cmdline;
 
diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c 
b/drivers/gpu/drm/msm/msm_submitqueue.c
index 0e803125a325..0444ba04fa06 100644
--- a/drivers/gpu/drm/msm/msm_submitqueue.c
+++ b/drivers/gpu/drm/msm/msm_submitqueue.c
@@ -61,6 +61,7 @@ void __msm_file_private_destroy(struct kref *kref)
}
 
msm_gem_address_space_put(ctx->aspace);
+   put_pid(ctx->pid);
kfree(ctx->comm);
kfree(ctx->cmdline);
kfree(ctx);
-- 
2.39.2



[RFC 1/3] drm/doc: Relax fdinfo string constraints

2023-04-17 Thread Rob Clark
From: Rob Clark 

The restriction about no whitespace, etc, really only applies to the
usage of strings in keys.  Values can contain anything (other than
newline).

Signed-off-by: Rob Clark 
---
 Documentation/gpu/drm-usage-stats.rst | 29 ++-
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index 258bdcc8fb86..8e00d53231e0 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -24,7 +24,7 @@ File format specification
 - All keys shall be prefixed with `drm-`.
 - Whitespace between the delimiter and first non-whitespace character shall be
   ignored when parsing.
-- Neither keys or values are allowed to contain whitespace characters.
+- Keys are not allowed to contain whitespace characters.
 - Numerical key value pairs can end with optional unit string.
 - Data type of the value is fixed as defined in the specification.
 
@@ -39,12 +39,13 @@ Data types
 --
 
 -  - Unsigned integer without defining the maximum value.
--  - String excluding any above defined reserved characters or whitespace.
+-  - String excluding any above defined reserved characters or 
whitespace.
+-  - String.
 
 Mandatory fully standardised keys
 -
 
-- drm-driver: 
+- drm-driver: 
 
 String shall contain the name this driver registered as via the respective
 `struct drm_driver` data structure.
@@ -69,10 +70,10 @@ scope of each device, in which case `drm-pdev` shall be 
present as well.
 Userspace should make sure to not double account any usage statistics by using
 the above described criteria in order to associate data to individual clients.
 
-- drm-engine-:  ns
+- drm-engine-:  ns
 
 GPUs usually contain multiple execution engines. Each shall be given a stable
-and unique name (str), with possible values documented in the driver specific
+and unique name (keystr), with possible values documented in the driver 
specific
 documentation.
 
 Value shall be in specified time units which the respective GPU engine spent
@@ -84,16 +85,16 @@ larger value within a reasonable period. Upon observing a 
value lower than what
 was previously read, userspace is expected to stay with that larger previous
 value until a monotonic update is seen.
 
-- drm-engine-capacity-: 
+- drm-engine-capacity-: 
 
 Engine identifier string must be the same as the one specified in the
-drm-engine- tag and shall contain a greater than zero number in case the
+drm-engine- tag and shall contain a greater than zero number in case 
the
 exported engine corresponds to a group of identical hardware engines.
 
 In the absence of this tag parser shall assume capacity of one. Zero capacity
 is not allowed.
 
-- drm-memory-:  [KiB|MiB]
+- drm-memory-:  [KiB|MiB]
 
 Each possible memory type which can be used to store buffer objects by the
 GPU in question shall be given a stable and unique name to be returned as the
@@ -126,10 +127,10 @@ The total size of buffers that are purgeable.
 
 The total size of buffers that are active on one or more rings.
 
-- drm-cycles-: 
+- drm-cycles-: 
 
 Engine identifier string must be the same as the one specified in the
-drm-engine- tag and shall contain the number of busy cycles for the given
+drm-engine- tag and shall contain the number of busy cycles for the 
given
 engine.
 
 Values are not required to be constantly monotonic if it makes the driver
@@ -138,12 +139,12 @@ larger value within a reasonable period. Upon observing a 
value lower than what
 was previously read, userspace is expected to stay with that larger previous
 value until a monotonic update is seen.
 
-- drm-maxfreq-:  [Hz|MHz|KHz]
+- drm-maxfreq-:  [Hz|MHz|KHz]
 
 Engine identifier string must be the same as the one specified in the
-drm-engine- tag and shall contain the maximum frequency for the given
-engine.  Taken together with drm-cycles-, this can be used to calculate
-percentage utilization of the engine, whereas drm-engine- only reflects
+drm-engine- tag and shall contain the maximum frequency for the given
+engine.  Taken together with drm-cycles-, this can be used to calculate
+percentage utilization of the engine, whereas drm-engine- only reflects
 time active without considering what frequency the engine is operating as a
 percentage of it's maximum frequency.
 
-- 
2.39.2



[RFC 0/3] drm: Add comm/cmdline fdinfo fields

2023-04-17 Thread Rob Clark
From: Rob Clark 

When many of the things using the GPU are processes in a VM guest, the
actual client process is just a proxy.  The msm driver has a way to let
the proxy tell the kernel the actual VM client process's executable name
and command-line, which has until now been used simply for GPU crash
devcore dumps.  Lets also expose this via fdinfo so that tools can
expose who the actual user of the GPU is.

Rob Clark (3):
  drm/doc: Relax fdinfo string constraints
  drm/msm: Rework get_comm_cmdline() helper
  drm/msm: Add comm/cmdline fields

 Documentation/gpu/drm-usage-stats.rst   | 37 +++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  4 +--
 drivers/gpu/drm/msm/msm_drv.c   |  2 ++
 drivers/gpu/drm/msm/msm_gpu.c   | 27 +-
 drivers/gpu/drm/msm/msm_gpu.h   | 12 ++--
 drivers/gpu/drm/msm/msm_submitqueue.c   |  1 +
 6 files changed, 58 insertions(+), 25 deletions(-)

-- 
2.39.2



Re: [PATCH 5/6] drm: bridge: samsung-dsim: Support non-burst mode

2023-04-17 Thread Marek Vasut

On 4/17/23 13:57, Adam Ford wrote:

On Sun, Apr 16, 2023 at 5:13 PM Marek Vasut  wrote:


On 4/15/23 12:41, Adam Ford wrote:

The high-speed clock is hard-coded to the burst-clock
frequency specified in the device tree.  However, when
using devices like certain bridge chips without burst mode
and varying resolutions and refresh rates, it may be
necessary to set the high-speed clock dynamically based
on the desired pixel clock for the connected device.


The link rate negotiation should happen internally between the nearest
bridge and DSIM, so please add that to DRM core instead of hacking
around it by tweaking the HS clock again.


I thought you tried to add something like this before and had some resistance.


Yes, all my attempts were rejected by a single reviewer. I suspended my 
efforts in that area for now.



The Pixel clock is set by the bridge already without any new code
added to the DRM core..  I am just reading that value that's there,
and setting the clock accordingly.  I don't see how this is a hack.


Assume you have a DSI-to-HDMI bridge attached to your DSIM bridge, it 
operates in non-burst mode, like ADV7533 . How would you configure the 
HS clock rate for such a bridge in DT ? (hint: you cannot, because the 
required clock comes from the EDID, which may not be available just yet)


[PATCH] drm/docs: Fix usage stats typos

2023-04-17 Thread Rob Clark
From: Rob Clark 

Fix a couple missing ':'s.

Signed-off-by: Rob Clark 
---
 Documentation/gpu/drm-usage-stats.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index b46327356e80..72d069e5dacb 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -105,7 +105,7 @@ object belong to this client, in the respective memory 
region.
 Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
 indicating kibi- or mebi-bytes.
 
-- drm-cycles- 
+- drm-cycles-: 
 
 Engine identifier string must be the same as the one specified in the
 drm-engine- tag and shall contain the number of busy cycles for the given
@@ -117,7 +117,7 @@ larger value within a reasonable period. Upon observing a 
value lower than what
 was previously read, userspace is expected to stay with that larger previous
 value until a monotonic update is seen.
 
-- drm-maxfreq-  [Hz|MHz|KHz]
+- drm-maxfreq-:  [Hz|MHz|KHz]
 
 Engine identifier string must be the same as the one specified in the
 drm-engine- tag and shall contain the maximum frequency for the given
-- 
2.39.2



Re: [LSF/MM/BPF proposal]: Physr discussion

2023-04-17 Thread Jason Gunthorpe
On Tue, Feb 28, 2023 at 12:59:41PM -0800, T.J. Mercier wrote:
> On Sat, Jan 21, 2023 at 7:03 AM Jason Gunthorpe  wrote:
> >
> > I would like to have a session at LSF to talk about Matthew's
> > physr discussion starter:
> >
> >  https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/
> >
> > I have become interested in this with some immediacy because of
> > IOMMUFD and this other discussion with Christoph:
> >
> >  
> > https://lore.kernel.org/kvm/4-v2-472615b3877e+28f7-vfio_dma_buf_...@nvidia.com/
> >
> > Which results in, more or less, we have no way to do P2P DMA
> > operations without struct page - and from the RDMA side solving this
> > well at the DMA API means advancing at least some part of the physr
> > idea.

[..]

I got fairly far along this and had to put it aside for some other
tasks, but here is what I came up with so far:

https://github.com/jgunthorpe/linux/commits/rlist

  PCI/P2PDMA: Do not store bus_off in the pci_p2pdma_map_state
  PCI/P2PDMA: Split out the information about the providing device from 
pgmap
  PCI/P2PDMA: Move the DMA API helpers to p2pdma_provider
  lib/rlist: Introduce range list
  lib/rlist: Introduce rlist cpu range iterator
  PCI/P2PDMA: Store the p2pdma_provider structs in an xarray
  lib/rlist: Introduce rlist_dma
  dma: Add DMA direct support for rlist mapping
  dma: Generic rlist dma_map_ops
  dma: Add DMA API support for mapping a rlist_cpu to a rlist_dma
  iommu/dma: Implement native rlist dma_map_ops
  dma: Use generic_dma.*_rlist in simple dma_map_ops implementations
  dma: Use generic_dma.*_rlist when map_sg just does map_page for n=1
  dma: Use generic_dma.*_rlist when iommu_area_alloc() is used
  dma/dummy: Add rlist
  s390/dma: Use generic_dma.*_rlist
  mm/gup: Create a wrapper for pin_user_pages to return a rlist
  dmabuf: WIP DMABUF exports the backing memory through rcpu
  RDMA/mlx5: Use rdma_umem_for_each_dma_block()
  RMDA/mlx: Use rdma_umem_for_each_dma_block() instead of sg_dma_address
  RDMA/mlx5: Use the length of the MR not the umem
  RDMA/umem: Add ib_umem_length() instead of open coding
  RDMA: Add IB DMA API wrappers for rlist
  RDMA: Switch ib_umem to rlist
  cover-letter: RFC Create an alternative to scatterlist in the DMA API

It is huge and scary. It is not quite nice enough to post but should
be an interesting starting point for LSF/MM. At least it broadly shows
all the touching required and why this is such a nasty problem.

The draft cover letter explaining what the series does:

cover-letter: RFC Create an alternative to scatterlist in the DMA API

This was kicked off by Matthew with his phyr idea from this thread:

https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/

Hwoevr, I have become interested in this with some immediacy because of
IOMMUFD and this other discussion with Christoph:


https://lore.kernel.org/kvm/4-v2-472615b3877e+28f7-vfio_dma_buf_...@nvidia.com/

Which results in, more or less, we have no way to do P2P DMA operations
without struct page. This becomes complicated when we touch RDMA which
highly relies on scatterlist for its internal implementations, so being
unable to use scatterlist to store only dma_addr_t's means RDMA needs a
complete scatterlist replacement that can.

So - my objective is to enable to DMA API to "DMA map" something that is
not a scatterlist, may or may not contain struct pages, but can still
contain P2P DMA physical addresses. With this tool, transform the RDMA
subystem to use the new DMA API and then go into DMABUF and stop creating
scatterlists without any CPU pages. From that point we could implement
DMABUF in VFIO (as above) and use the DMABUF to feed the MMIO pages into
IOMMUFD to restore the PCI P2P support in VMs withotu creating the
follow_pte security problem that VFIO has.

After going through the thread again, and making some sketches, I've come
up with this suggestion as a path forward, explored very roughly in this
RFC:

1) Create something I've called a 'range list CPU iterator'. This is an
   API that abstractly iterates over CPU physical memory ranges. It
   has useful helpers to iterate over things in 'struct page/folio *',
   physical ranges, copy to/from, and so on

   It has the necessary extra bits beyond the physr sketch to support P2P
   in the DMA API based on what was done for the pgmap based stuff. ie we
   need to know the provider of the non-struct page memory to get the
   struct device to compute the p2p distance and compute the pci_offset.

   The immediate idea is this is an iterator, not a data structure. So it
   can iterate over different kinds of storage. This frees us from having
   to immediatly consolidate all the different storage schemes in the
   

Re: [RFC PATCH 5/7] drm/msm/dpu: Document and enable TEAR interrupts on DSI interfaces

2023-04-17 Thread Abhinav Kumar




On 4/17/2023 12:41 PM, Marijn Suijten wrote:

On 2023-02-14 09:54:57, Abhinav Kumar wrote:
[..]

Just wondering, how were the lengths calculated for the INTF blocks?
The values in general seem a little off to me.


These (for MSM8998) have been taken from downstream specifically; my
series starts using INTF_STATUS at 0x26C which conveniently is the
register right after 0x268, matching the fact that INTF TE and these
registers weren't supported/available yet on MSM8998.


For example, I'm looking downstream and it seems to me that the length
for the INTF_0 on MSM8998 should be 0x280. Similarly for SC7280, I'm
seeing that length for INTF + tearcheck should be 0x2c4.


There are many different downstream sources and tags with seemingly
conflicting/confusing information.  For v2 [2] I've picked the highest
register used by the driver which is INTF_TEAR_AUTOREFRESH_CONFIG at
0x2B4 (but there might always be more registers that don't need to be
poked at by the driver, but contain magic debug information and the
like... those would be useful to capture in the dump going forward).

[2]: 
https://github.com/SoMainline/linux/commit/2bbc609dd28aa0bd0a2dede20163e521912d0072



Not entirely correct.TEAR_AUTOREFRESH_STATUS is at 0x2c0 for sm8350 and
sm8450 as well so 0x2b4 is a bit short. DPU code uses autorefresh status
today.Esp after your changes it will use the autorefresh status from
intf te which is at offset 0x2c0


Revisiting this, I don't see current DPU code nor downstream 5.4 / 5.10
SDE techpack on some of my checkouts use this register, only
INTF_TEAR_AUTOREFRESH_CONFIG at 0x2b4..0x2b7.  Am I missing something
critical here?



Wow, I lost context since its been months since your last response.

But, I refreshed some of it. You are right, we use the status bits 
present in the INTF_TEAR_AUTOREFRESH_CONFIG and INTF_TEAR_ 
AUTOREFRESH_STATUS is unused.


I got confused between the status bit present in the two registers as 
both relate to autorefresh.


But, the offset of of INTF_TEAR_ AUTOREFRESH_STATUS is still at 0x2c0 as 
i wrote before so 0x2c4 is the accurate length of this block.


And yes, all the blk lengths should be accurate now in the hw catalog 
after the rework and reviews of that rework.



We have discussed INTF lengths in [1]. The current understanding of the
block lengths can be found at [2]. Please comment there if any of the
fixed lengths sounds incorrect to you.

[1] https://patchwork.freedesktop.org/patch/522187/
[2] https://patchwork.freedesktop.org/patch/57/

[skipped the rest]



Please correct my understanding here, it was agreed to fix intf blocks
to 0x2c4 here https://patchwork.freedesktop.org/patch/57/ but I dont
see this was merged?

It was agreed to first land INTF_TE and then add the higher addresses


Seems like it, at least if I interpret [3] correctly.  My series adds a
new define that will hardcode _len to 0x2B8 for now, and Dmitry/Konrad
can later extend it to whatever is stated by the correct downstream
source.



Like mentioned above it should be 0x2c0 for intf block.

If you face any conflicting information in downstream code, you can
always check with me on IRC.


Ack, it looks like others landed these changes for me now via the
catalog rework, so I have just rebased and kept the lengths in.

- Marijn


Re: [RFC PATCH 5/7] drm/msm/dpu: Document and enable TEAR interrupts on DSI interfaces

2023-04-17 Thread Marijn Suijten
On 2023-02-14 09:54:57, Abhinav Kumar wrote:
[..]
>  Just wondering, how were the lengths calculated for the INTF blocks?
>  The values in general seem a little off to me.
> > 
> > These (for MSM8998) have been taken from downstream specifically; my
> > series starts using INTF_STATUS at 0x26C which conveniently is the
> > register right after 0x268, matching the fact that INTF TE and these
> > registers weren't supported/available yet on MSM8998.
> > 
>  For example, I'm looking downstream and it seems to me that the length
>  for the INTF_0 on MSM8998 should be 0x280. Similarly for SC7280, I'm
>  seeing that length for INTF + tearcheck should be 0x2c4.
> > 
> > There are many different downstream sources and tags with seemingly
> > conflicting/confusing information.  For v2 [2] I've picked the highest
> > register used by the driver which is INTF_TEAR_AUTOREFRESH_CONFIG at
> > 0x2B4 (but there might always be more registers that don't need to be
> > poked at by the driver, but contain magic debug information and the
> > like... those would be useful to capture in the dump going forward).
> > 
> > [2]: 
> > https://github.com/SoMainline/linux/commit/2bbc609dd28aa0bd0a2dede20163e521912d0072
> > 
> 
> Not entirely correct.TEAR_AUTOREFRESH_STATUS is at 0x2c0 for sm8350 and 
> sm8450 as well so 0x2b4 is a bit short. DPU code uses autorefresh status 
> today.Esp after your changes it will use the autorefresh status from 
> intf te which is at offset 0x2c0

Revisiting this, I don't see current DPU code nor downstream 5.4 / 5.10
SDE techpack on some of my checkouts use this register, only
INTF_TEAR_AUTOREFRESH_CONFIG at 0x2b4..0x2b7.  Am I missing something
critical here?

> >>> We have discussed INTF lengths in [1]. The current understanding of the
> >>> block lengths can be found at [2]. Please comment there if any of the
> >>> fixed lengths sounds incorrect to you.
> >>>
> >>> [1] https://patchwork.freedesktop.org/patch/522187/
> >>> [2] https://patchwork.freedesktop.org/patch/57/
> >>>
> >>> [skipped the rest]
> >>>
> >>
> >> Please correct my understanding here, it was agreed to fix intf blocks
> >> to 0x2c4 here https://patchwork.freedesktop.org/patch/57/ but I dont
> >> see this was merged?
> >>
> >> It was agreed to first land INTF_TE and then add the higher addresses
> > 
> > Seems like it, at least if I interpret [3] correctly.  My series adds a
> > new define that will hardcode _len to 0x2B8 for now, and Dmitry/Konrad
> > can later extend it to whatever is stated by the correct downstream
> > source.
> > 
> 
> Like mentioned above it should be 0x2c0 for intf block.
> 
> If you face any conflicting information in downstream code, you can 
> always check with me on IRC.

Ack, it looks like others landed these changes for me now via the
catalog rework, so I have just rebased and kept the lengths in.

- Marijn


Re: [RFC 3/6] drm: Add fdinfo memory stats

2023-04-17 Thread Rob Clark
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
 wrote:
>
> From: Tvrtko Ursulin 
>
> Add support to dump GEM stats to fdinfo.
>
> Signed-off-by: Tvrtko Ursulin 
> ---
>  Documentation/gpu/drm-usage-stats.rst | 12 +++
>  drivers/gpu/drm/drm_file.c| 52 +++
>  include/drm/drm_drv.h |  7 
>  include/drm/drm_file.h|  8 +
>  4 files changed, 79 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst 
> b/Documentation/gpu/drm-usage-stats.rst
> index 2ab32c40e93c..8273a41b2fb0 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -21,6 +21,7 @@ File format specification
>
>  - File shall contain one key value pair per one line of text.
>  - Colon character (`:`) must be used to delimit keys and values.
> +- Caret (`^`) is also a reserved character.

this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)

(also, it is IMHO rather ugly)

BR,
-R

>  - All keys shall be prefixed with `drm-`.
>  - Whitespace between the delimiter and first non-whitespace character shall 
> be
>ignored when parsing.
> @@ -105,6 +106,17 @@ object belong to this client, in the respective memory 
> region.
>  Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
>  indicating kibi- or mebi-bytes.
>
> +- drm-memory-^size:   [KiB|MiB]
> +- drm-memory-^shared: [KiB|MiB]
> +- drm-memory-^resident:   [KiB|MiB]
> +- drm-memory-^purgeable:  [KiB|MiB]
> +- drm-memory-^active: [KiB|MiB]
> +
> +Resident category is identical to the drm-memory- key and two should be
> +mutually exclusive.
> +
> +TODO more description text...
> +
>  - drm-cycles- 
>
>  Engine identifier string must be the same as the one specified in the
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 37b4f76a5191..e202f79e816d 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include "drm_crtc_internal.h"
> @@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct 
> drm_pending_event *e)
>  }
>  EXPORT_SYMBOL(drm_send_event);
>
> +static void
> +print_stat(struct drm_printer *p, const char *stat, const char *region, u64 
> sz)
> +{
> +   const char *units[] = {"", " KiB", " MiB"};
> +   unsigned int u;
> +
> +   if (sz == ~0ull) /* Not supported by the driver. */
> +   return;
> +
> +   for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> +   if (sz < SZ_1K)
> +   break;
> +   sz = div_u64(sz, SZ_1K);
> +   }
> +
> +   drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
> +  region, stat, sz, units[u]);
> +}
> +
> +static void print_memory_stats(struct drm_printer *p, struct drm_file *file)
> +{
> +   struct drm_device *dev = file->minor->dev;
> +   struct drm_fdinfo_memory_stat *stats;
> +   unsigned int num, i;
> +   char **regions;
> +
> +   regions = dev->driver->query_fdinfo_memory_regions(dev, );
> +
> +   stats = kcalloc(num, sizeof(*stats), GFP_KERNEL);
> +   if (!stats)
> +   return;
> +
> +   dev->driver->query_fdinfo_memory_stats(file, stats);
> +
> +   for (i = 0; i < num; i++) {
> +   if (!regions[i]) /* Allow sparse name arrays. */
> +   continue;
> +
> +   print_stat(p, "size", regions[i], stats[i].size);
> +   print_stat(p, "shared", regions[i], stats[i].shared);
> +   print_stat(p, "resident", regions[i], stats[i].resident);
> +   print_stat(p, "purgeable", regions[i], stats[i].purgeable);
> +   print_stat(p, "active", regions[i], stats[i].active);
> +   }
> +
> +   kfree(stats);
> +}
> +
>  /**
>   * drm_show_fdinfo - helper for drm file fops
>   * @seq_file: output stream
> @@ -900,6 +949,9 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
>
> if (dev->driver->show_fdinfo)
> dev->driver->show_fdinfo(, file);
> +
> +   if (dev->driver->query_fdinfo_memory_regions)
> +   print_memory_stats(, file);
>  }
>  EXPORT_SYMBOL(drm_show_fdinfo);
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 89e2706cac56..ccc1cd98d2aa 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -35,6 +35,7 @@
>  #include 
>
>  struct drm_file;
> +struct drm_fdinfo_memory_stat;
>  struct drm_gem_object;
>  struct drm_master;
>  struct drm_minor;
> @@ -408,6 +409,12 @@ struct drm_driver {
>  */
> void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
>
> +   char ** (*query_fdinfo_memory_regions)(struct drm_device *dev,
> +  unsigned int *num);
> +
> +   void (*query_fdinfo_memory_stats)(struct drm_file *f,
> +   

Re: [PATCH v2] radeon: avoid double free in ci_dpm_init()

2023-04-17 Thread Alex Deucher
Thanks.  Applied!

Alex

On Thu, Apr 13, 2023 at 11:12 AM Nikita Zhandarovich
 wrote:
>
> Several calls to ci_dpm_fini() will attempt to free resources that
> either have been freed before or haven't been allocated yet. This
> may lead to undefined or dangerous behaviour.
>
> For instance, if r600_parse_extended_power_table() fails, it might
> call r600_free_extended_power_table() as will ci_dpm_fini() later
> during error handling.
>
> Fix this by only freeing pointers to objects previously allocated.
>
> Found by Linux Verification Center (linuxtesting.org) with static
> analysis tool SVACE.
>
> Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
> Cc: sta...@vger.kernel.org
> Co-developed-by: Natalia Petrova 
> Signed-off-by: Nikita Zhandarovich 
> ---
> v2: free only resouces allocated prior, do not remove ci_dpm_fini()
> or other deallocating calls altogether; fix commit message.
> v1: 
> https://lore.kernel.org/all/20230403182808.8699-1-n.zhandarov...@fintech.ru/
>
>  drivers/gpu/drm/radeon/ci_dpm.c | 28 
>  1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
> index 8ef25ab305ae..b8f4dac68d85 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -5517,6 +5517,7 @@ static int ci_parse_power_table(struct radeon_device 
> *rdev)
> u8 frev, crev;
> u8 *power_state_offset;
> struct ci_ps *ps;
> +   int ret;
>
> if (!atom_parse_data_header(mode_info->atom_context, index, NULL,
>, , _offset))
> @@ -5546,11 +5547,15 @@ static int ci_parse_power_table(struct radeon_device 
> *rdev)
> non_clock_array_index = power_state->v2.nonClockInfoIndex;
> non_clock_info = (struct _ATOM_PPLIB_NONCLOCK_INFO *)
> 
> _clock_info_array->nonClockInfo[non_clock_array_index];
> -   if (!rdev->pm.power_state[i].clock_info)
> -   return -EINVAL;
> +   if (!rdev->pm.power_state[i].clock_info) {
> +   ret = -EINVAL;
> +   goto err_free_ps;
> +   }
> ps = kzalloc(sizeof(struct ci_ps), GFP_KERNEL);
> -   if (ps == NULL)
> -   return -ENOMEM;
> +   if (ps == NULL) {
> +   ret = -ENOMEM;
> +   goto err_free_ps;
> +   }
> rdev->pm.dpm.ps[i].ps_priv = ps;
> ci_parse_pplib_non_clock_info(rdev, >pm.dpm.ps[i],
>   non_clock_info,
> @@ -5590,6 +5595,12 @@ static int ci_parse_power_table(struct radeon_device 
> *rdev)
> }
>
> return 0;
> +
> +err_free_ps:
> +   for (i = 0; i < rdev->pm.dpm.num_ps; i++)
> +   kfree(rdev->pm.dpm.ps[i].ps_priv);
> +   kfree(rdev->pm.dpm.ps);
> +   return ret;
>  }
>
>  static int ci_get_vbios_boot_values(struct radeon_device *rdev,
> @@ -5678,25 +5689,26 @@ int ci_dpm_init(struct radeon_device *rdev)
>
> ret = ci_get_vbios_boot_values(rdev, >vbios_boot_state);
> if (ret) {
> -   ci_dpm_fini(rdev);
> +   kfree(rdev->pm.dpm.priv);
> return ret;
> }
>
> ret = r600_get_platform_caps(rdev);
> if (ret) {
> -   ci_dpm_fini(rdev);
> +   kfree(rdev->pm.dpm.priv);
> return ret;
> }
>
> ret = r600_parse_extended_power_table(rdev);
> if (ret) {
> -   ci_dpm_fini(rdev);
> +   kfree(rdev->pm.dpm.priv);
> return ret;
> }
>
> ret = ci_parse_power_table(rdev);
> if (ret) {
> -   ci_dpm_fini(rdev);
> +   kfree(rdev->pm.dpm.priv);
> +   r600_free_extended_power_table(rdev);
> return ret;
> }
>


Re: [PATCH] drm/amd/display: remove unused variable oldest_index

2023-04-17 Thread Alex Deucher
Applied.  Thanks!

On Fri, Apr 14, 2023 at 11:08 AM Tom Rix  wrote:
>
> cpp_check reports
> drivers/gpu/drm/amd/display/modules/freesync/freesync.c:1143:17: style: 
> Variable
>   'oldest_index' is assigned a value that is never used. [unreadVariable]
>oldest_index = 0;
> ^
>
> This variable is not used so remove.
>
> Signed-off-by: Tom Rix 
> ---
>  drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
> b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> index 5c41a4751db4..5798c0eafa1f 100644
> --- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> +++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> @@ -1137,10 +1137,6 @@ void mod_freesync_handle_preflip(struct mod_freesync 
> *mod_freesync,
>
> if (in_out_vrr->supported &&
> in_out_vrr->state == VRR_STATE_ACTIVE_VARIABLE) {
> -   unsigned int oldest_index = plane->time.index + 1;
> -
> -   if (oldest_index >= DC_PLANE_UPDATE_TIMES_MAX)
> -   oldest_index = 0;
>
> last_render_time_in_us = curr_time_stamp_in_us -
> plane->time.prev_update_time_in_us;
> --
> 2.27.0
>


Re: [PATCH v7 5/8] drm/i915/pxp: Add ARB session creation and cleanup

2023-04-17 Thread Teres Alexis, Alan Previn
On Mon, 2023-04-17 at 12:15 -0700, Ceraolo Spurio, Daniele wrote:
> On 4/17/2023 11:21 AM, Teres Alexis, Alan Previn wrote:
> > On Mon, 2023-04-10 at 10:14 -0700, Ceraolo Spurio, Daniele wrote:
> > > > @@ -354,8 +368,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
> > > > if (!intel_pxp_is_enabled(pxp))
> > > > return -ENODEV;
> > > >
> > > > -   if (wait_for(pxp_component_bound(pxp), 250))
> > > > -   return -ENXIO;
> > > > +   if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
> > > > +   /* Use a larger 1 second timeout considering all the 
> > > > dependencies. */
> > > > +   if 
> > > > (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 1000))
> > > > +   return -ENXIO;
> > > This needs a comment to explain that we expect userspace to retry later
> > > if we return -ENXIO and therefore the timeout is smaller that what would
> > > be required to guarantee that the init can complete. It also needs an
> > > ack from the userspace drivers for this behavior.
> > > 
> > alan: I agree with a requirement to comment this down. However, i believe 
> > its better
> > to put this int the UAPI header file comment-documentation since it applies 
> > to both
> > current MTL as well as previous ADL cases (this is not new behavior being 
> > introduced
> > in MTL but it is fixing of the spec of existing behavior).
> > That said, your feedback is already being addressed by patch #6 but i will 
> > ammend
> > patch #6 to add the detail you highlighted WRT ~"timeout is not larger than 
> > the completion-guarantee...".
> 
> Can you move that comment update for the context getparam from the next 
> patch to this one? that way it's all nicely self-contained in this patch.
alan: sounds good - will do
alan:snip

> > > > 
> > > > -#define GSC_REPLY_LATENCY_MS 200
> > > > +#define GSC_REPLY_LATENCY_MS 210
> > > why move from 200 to 210? not a problem, I just want to understand why
> > > this is required.
> > > 
> > > Daniele
> > alan: so 200 is based on the fw spec - and from real testing i observed the 
> > occasional highs touching ~185ms.
> > However, the spec gives this number as the expected max time the firmware 
> > is going to take to process the request
> > and post a reply. Therefore it doesn't include the additional overhead for 
> > the request creation, emision,
> > submission via guc and the completion pipeline completion indication. All 
> > of these contribute additional layers
> > of possible delay. Since arb-session creation and invalidation are not 
> > common events,
> > I believe a slightly wider overhead of 10 milisec will not hurt.
> 
> Agreed. Can you add a comment? something like "Max FW response time is 
> 200ms, to which we add 10ms to account for overhead".
alan: will do and thanks for the conditional rb. will fix these accordingly.

> With those 2 nits addressed:
> 
> Reviewed-by: Daniele Ceraolo Spurio 
> 
> Daniele



Re: [PATCH][next] drm/amd/pm: Fix spelling mistake "aquire" -> "acquire"

2023-04-17 Thread Alex Deucher
Applied.  Thanks!

Alex

On Mon, Apr 17, 2023 at 1:42 PM Colin Ian King  wrote:
>
> There is a spelling mistake in the smu_i2c_bus_access prototype. Fix it.
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h 
> b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
> index 5ce433e2c16a..f1580a26a850 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
> +++ b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
> @@ -359,7 +359,7 @@ struct pp_hwmgr_func {
> int (*set_ppfeature_status)(struct pp_hwmgr *hwmgr, uint64_t 
> ppfeature_masks);
> int (*set_mp1_state)(struct pp_hwmgr *hwmgr, enum pp_mp1_state 
> mp1_state);
> int (*asic_reset)(struct pp_hwmgr *hwmgr, enum SMU_ASIC_RESET_MODE 
> mode);
> -   int (*smu_i2c_bus_access)(struct pp_hwmgr *hwmgr, bool aquire);
> +   int (*smu_i2c_bus_access)(struct pp_hwmgr *hwmgr, bool acquire);
> int (*set_df_cstate)(struct pp_hwmgr *hwmgr, enum pp_df_cstate state);
> int (*set_xgmi_pstate)(struct pp_hwmgr *hwmgr, uint32_t pstate);
> int (*disable_power_features_for_compute_performance)(struct pp_hwmgr 
> *hwmgr,
> --
> 2.30.2
>


Re: [PATCH 1/2] drm/msm/dpu: simplify intf allocation code

2023-04-17 Thread Abhinav Kumar




On 4/15/2023 10:19 AM, Dmitry Baryshkov wrote:

Rather than passing DRM_MODE_ENCODER_* and letting dpu_encoder to guess,
which intf type we mean, pass INTF_DSI/INTF_DP directly. This is
required to support HDMI output in DPU, as both DP and HDMI encoders are
DRM_MODE_ENCODER_TMDS. Thus dpu_encoder code can not make a difference
between HDMI and DP outputs.

Reviewed-by: Bjorn Andersson 
Signed-off-by: Dmitry Baryshkov 
---


Since it was previously agreed that INTF_eDP will be dropped in favor of 
using just INTF_DP for both eDP and DP (the previous cause of debate), I 
am fine with this.


Hence,

Reviewed-by: Abhinav Kumar 


Re: [PATCH v7 5/8] drm/i915/pxp: Add ARB session creation and cleanup

2023-04-17 Thread Ceraolo Spurio, Daniele




On 4/17/2023 11:21 AM, Teres Alexis, Alan Previn wrote:

On Mon, 2023-04-10 at 10:14 -0700, Ceraolo Spurio, Daniele wrote:




alan:snip


@@ -354,8 +368,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
   
-	if (wait_for(pxp_component_bound(pxp), 250))

-   return -ENXIO;
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
+   /* Use a larger 1 second timeout considering all the 
dependencies. */
+   if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 1000))
+   return -ENXIO;

This needs a comment to explain that we expect userspace to retry later
if we return -ENXIO and therefore the timeout is smaller that what would
be required to guarantee that the init can complete. It also needs an
ack from the userspace drivers for this behavior.


alan: I agree with a requirement to comment this down. However, i believe its 
better
to put this int the UAPI header file comment-documentation since it applies to 
both
current MTL as well as previous ADL cases (this is not new behavior being 
introduced
in MTL but it is fixing of the spec of existing behavior).
That said, your feedback is already being addressed by patch #6 but i will 
ammend
patch #6 to add the detail you highlighted WRT ~"timeout is not larger than the 
completion-guarantee...".


Can you move that comment update for the context getparam from the next 
patch to this one? that way it's all nicely self-contained in this patch.



alan:snip

+fw_err_to_string(u32 type)
+{
+   switch (type) {
+   case PXP_STATUS_ERROR_API_VERSION:
+   return "ERR_API_VERSION";
+   case PXP_STATUS_NOT_READY:
+   return "ERR_NOT_READY";
+   case PXP_STATUS_PLATFCONFIG_KF1_NOVERIF:
+   case PXP_STATUS_PLATFCONFIG_KF1_BAD:
+   return "ERR_PLATFORM_CONFIG";
+   default:
+   break;
+   }
+   return NULL;
+}
+

There is a lot of replication for this error handling, I'm wondering if
it's worth adding a common function to handle this. Something like:

intel_pxp_header_error(u32 header, const char *op, u32 id)
{
if (is_fw_err_platform_config(header.status)) {
drm_info_once(>drm,
  "PXP %s-%d failed due to BIOS/SOC:0x%08x:%s\n",
  op, id, header.status,
  fw_err_to_string(header.status));
} else {
drm_dbg(>drm, "PXP %s-%d failed 0x%08x:%st:\n",
op, id, header.status,
fw_err_to_string(header.status));
drm_dbg(>drm, " cmd-detail: 
ID=[0x%08x],API-Ver-[0x%08x]\n",
header.command_id, header.api_version);
}
}


Not a blocker.

alan: Thanks - i will have to address as a stand alone patch since i have to
think about moving this to a comment helper layer (common to both ADL-mei-comp 
and MTL-gsccs)
while potentially have different set of error codes that can mean different 
reporting levels
(i.e. notice once coz its a platform limit vs always err out if its runtime 
related).
Once this series gets merged it will be easier to work on that patch (which 
would require both
backends to be present in the baseline).
alan:snip

+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
@@ -10,14 +10,18 @@
   
   struct intel_pxp;
   
-#define GSC_REPLY_LATENCY_MS 200

+#define GSC_REPLY_LATENCY_MS 210

why move from 200 to 210? not a problem, I just want to understand why
this is required.

Daniele

alan: so 200 is based on the fw spec - and from real testing i observed the 
occasional highs touching ~185ms.
However, the spec gives this number as the expected max time the firmware is 
going to take to process the request
and post a reply. Therefore it doesn't include the additional overhead for the 
request creation, emision,
submission via guc and the completion pipeline completion indication. All of 
these contribute additional layers
of possible delay. Since arb-session creation and invalidation are not common 
events,
I believe a slightly wider overhead of 10 milisec will not hurt.


Agreed. Can you add a comment? something like "Max FW response time is 
200ms, to which we add 10ms to account for overhead".

With those 2 nits addressed:

Reviewed-by: Daniele Ceraolo Spurio 

Daniele







Re: [PATCH v7 5/8] drm/i915/pxp: Add ARB session creation and cleanup

2023-04-17 Thread Teres Alexis, Alan Previn
On Mon, 2023-04-10 at 10:14 -0700, Ceraolo Spurio, Daniele wrote:
> 
> 
> 
alan:snip

> > @@ -354,8 +368,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
> > if (!intel_pxp_is_enabled(pxp))
> > return -ENODEV;
> >   
> > -   if (wait_for(pxp_component_bound(pxp), 250))
> > -   return -ENXIO;
> > +   if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
> > +   /* Use a larger 1 second timeout considering all the 
> > dependencies. */
> > +   if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 1000))
> > +   return -ENXIO;
> 
> This needs a comment to explain that we expect userspace to retry later 
> if we return -ENXIO and therefore the timeout is smaller that what would 
> be required to guarantee that the init can complete. It also needs an 
> ack from the userspace drivers for this behavior.
> 
alan: I agree with a requirement to comment this down. However, i believe its 
better
to put this int the UAPI header file comment-documentation since it applies to 
both
current MTL as well as previous ADL cases (this is not new behavior being 
introduced
in MTL but it is fixing of the spec of existing behavior).
That said, your feedback is already being addressed by patch #6 but i will 
ammend
patch #6 to add the detail you highlighted WRT ~"timeout is not larger than the 
completion-guarantee...".

> 
alan:snip
> > +fw_err_to_string(u32 type)
> > +{
> > +   switch (type) {
> > +   case PXP_STATUS_ERROR_API_VERSION:
> > +   return "ERR_API_VERSION";
> > +   case PXP_STATUS_NOT_READY:
> > +   return "ERR_NOT_READY";
> > +   case PXP_STATUS_PLATFCONFIG_KF1_NOVERIF:
> > +   case PXP_STATUS_PLATFCONFIG_KF1_BAD:
> > +   return "ERR_PLATFORM_CONFIG";
> > +   default:
> > +   break;
> > +   }
> > +   return NULL;
> > +}
> > +
> 
> There is a lot of replication for this error handling, I'm wondering if 
> it's worth adding a common function to handle this. Something like:
> 
> intel_pxp_header_error(u32 header, const char *op, u32 id)
> {
>   if (is_fw_err_platform_config(header.status)) {
>   drm_info_once(>drm,
> "PXP %s-%d failed due to BIOS/SOC:0x%08x:%s\n",
> op, id, header.status,
> fw_err_to_string(header.status));
>   } else {
>   drm_dbg(>drm, "PXP %s-%d failed 0x%08x:%st:\n",
>   op, id, header.status,
>   fw_err_to_string(header.status));
>   drm_dbg(>drm, " cmd-detail: 
> ID=[0x%08x],API-Ver-[0x%08x]\n",
>   header.command_id, header.api_version);
>   }
> }
> 
> 
> Not a blocker.
alan: Thanks - i will have to address as a stand alone patch since i have to
think about moving this to a comment helper layer (common to both ADL-mei-comp 
and MTL-gsccs)
while potentially have different set of error codes that can mean different 
reporting levels
(i.e. notice once coz its a platform limit vs always err out if its runtime 
related).
Once this series gets merged it will be easier to work on that patch (which 
would require both
backends to be present in the baseline).
> > 
alan:snip
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
> > @@ -10,14 +10,18 @@
> >   
> >   struct intel_pxp;
> >   
> > -#define GSC_REPLY_LATENCY_MS 200
> > +#define GSC_REPLY_LATENCY_MS 210
> 
> why move from 200 to 210? not a problem, I just want to understand why 
> this is required.
> 
> Daniele
alan: so 200 is based on the fw spec - and from real testing i observed the 
occasional highs touching ~185ms.
However, the spec gives this number as the expected max time the firmware is 
going to take to process the request
and post a reply. Therefore it doesn't include the additional overhead for the 
request creation, emision,
submission via guc and the completion pipeline completion indication. All of 
these contribute additional layers
of possible delay. Since arb-session creation and invalidation are not common 
events,
I believe a slightly wider overhead of 10 milisec will not hurt.



Re: [PATCH v7 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages

2023-04-17 Thread Teres Alexis, Alan Previn
On Mon, 2023-04-10 at 09:28 -0700, Ceraolo Spurio, Daniele wrote:
> 
alan:snip
> >   #define GSC_OUTFLAG_MSG_PENDING 1
> > +#define GSC_INFLAG_MSG_CLEANUP BIT(1)
> 
> For consistency those should all be BIT() defines
alan: will do.
> 
> With the define fixed:
> 
> Reviewed-by: Daniele Ceraolo Spurio 
> 
> Daniele
> 
alan: thanks Daniele.



Re: [PATCH v7 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

2023-04-17 Thread Teres Alexis, Alan Previn
On Mon, 2023-04-10 at 09:10 -0700, Ceraolo Spurio, Daniele wrote:
> 
alan:snip

> > +int
> > +intel_gsc_uc_heci_cmd_submit_nonpriv(struct intel_gsc_uc *gsc,
> > +struct intel_context *ce,
> > +struct intel_gsc_heci_non_priv_pkt *pkt,
> > +u32 *cmd, int timeout_ms)
> > +{
> > +   struct intel_engine_cs *eng;
> 
> We always use "engine" for engine_cs variables. IMO it's better to stick 
> to that here as well for consistency across the code.
alan: will do
> 
> > +   struct i915_gem_ww_ctx ww;
> > +   struct i915_request *rq;
> > +   int err, trials = 0;
> > +
> 
> Is the assumption that the caller is holding a wakeref already? 
> Otherwise we're going to need and engine_pm_get() here (assuming it 
> doesn't interfere with any locking, otherwise it has to be in the caller)
alan: right now the only places this can get called from is via 
intel_pxp_gsccs_create_session or
intel_pxp_gsccs_end_arb_fw_session. These functions are either being called by 
intel_pxp_start
or intel_pxp_end. intel_pxp_start calls intel_runtime_pm_get_if_in_use 
indirectly from the
session-worker and while intel_pxp_end takes an explicit intel_runtime_pm_get 
(since it is
for suspend/shutdown cleanup and doesn't use the worker). I'm assuming 
runtime_pm works right?
we have a similar logic across the paths from ADL version where we dont take 
explicit
engine_pm_get for the termination via VDBOX because its part of the same code 
paths.

alan:snip

> > +   err = i915_vma_move_to_active(pkt->bb_vma, rq, EXEC_OBJECT_WRITE);
> 
> nit: I don't think we need EXEC_OBJECT_WRITE for the bb as we're not 
> going to write it.
alan: yes - will remove. (had accidentally kept above flag from offline
debugging version of the code that had additional store dwords into bb).

> 
> > +   if (err)
> > +   goto out_rq;
> > +   err = i915_vma_move_to_active(pkt->heci_pkt_vma, rq, EXEC_OBJECT_WRITE);
> > +   if (err)
> > +   goto out_rq;
> > +
> > +   eng = rq->context->engine;
> > +   if (eng->emit_init_breadcrumb) {
> > +   err = eng->emit_init_breadcrumb(rq);
> > +   if (err)
> > +   goto out_rq;
> > +   }
> > +
> > +   err = eng->emit_bb_start(rq, i915_vma_offset(pkt->bb_vma), PAGE_SIZE, 
> > 0);
> > +   if (err)
> > +   goto out_rq;
> > +
> > +   err = ce->engine->emit_flush(rq, 0);
> > +   if (err)
> > +   drm_err(_uc_to_gt(gsc)->i915->drm,
> > +   "Failed emit-flush for gsc-heci-non-priv-pkterr=%d\n", 
> > err);
> > +
> > +out_rq:
> > +   i915_request_get(rq);
> > +
> > +   if (unlikely(err))
> > +   i915_request_set_error_once(rq, err);
> > +
> > +   i915_request_add(rq);
> > +
> > +   if (!err) {
> > +   if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
> > + msecs_to_jiffies(timeout_ms)) < 0)
> > +   err = -ETIME;
> > +   }
> > +
> > +   i915_request_put(rq);
> > +
> > +out_unpin_ce:
> > +   intel_context_unpin(ce);
> > +out_ww:
> > +   if (err == -EDEADLK) {
> > +   err = i915_gem_ww_ctx_backoff();
> > +   if (!err) {
> > +   if (++trials < 10)
> > +   goto retry;
> > +   else
> > +   err = EAGAIN;
> > +   }
> > +   }
> > +   i915_gem_ww_ctx_fini();
> > +
> > +   return err;
> > +}
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
> > b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
> > index 3d56ae501991..3addce861854 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
> > @@ -8,7 +8,10 @@
> >   
> >   #include 
> >   
> > +struct i915_vma;
> > +struct intel_context;
> >   struct intel_gsc_uc;
> > +
> >   struct intel_gsc_mtl_header {
> > u32 validity_marker;
> >   #define GSC_HECI_VALIDITY_MARKER 0xA578875A
> > @@ -47,7 +50,7 @@ struct intel_gsc_mtl_header {
> >  * we distinguish the flags using OUTFLAG or INFLAG
> >  */
> > u32 flags;
> > -#define GSC_OUTFLAG_MSG_PENDING1
> > +#define GSC_OUTFLAG_MSG_PENDING 1
> 
> Nit: this change on the define is not really needed
sure - will fix.
> 
> Daniele



[PATCH][next] drm/amd/pm: Fix spelling mistake "aquire" -> "acquire"

2023-04-17 Thread Colin Ian King
There is a spelling mistake in the smu_i2c_bus_access prototype. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h 
b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
index 5ce433e2c16a..f1580a26a850 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
@@ -359,7 +359,7 @@ struct pp_hwmgr_func {
int (*set_ppfeature_status)(struct pp_hwmgr *hwmgr, uint64_t 
ppfeature_masks);
int (*set_mp1_state)(struct pp_hwmgr *hwmgr, enum pp_mp1_state 
mp1_state);
int (*asic_reset)(struct pp_hwmgr *hwmgr, enum SMU_ASIC_RESET_MODE 
mode);
-   int (*smu_i2c_bus_access)(struct pp_hwmgr *hwmgr, bool aquire);
+   int (*smu_i2c_bus_access)(struct pp_hwmgr *hwmgr, bool acquire);
int (*set_df_cstate)(struct pp_hwmgr *hwmgr, enum pp_df_cstate state);
int (*set_xgmi_pstate)(struct pp_hwmgr *hwmgr, uint32_t pstate);
int (*disable_power_features_for_compute_performance)(struct pp_hwmgr 
*hwmgr,
-- 
2.30.2



Re: [PATCH] drm/etnaviv: fix dumping of active MMU context

2023-04-17 Thread Christian Gmeiner
Hi Lucas

>
> gpu->mmu_context is the MMU context of the last job in the HW queue, which
> isn't necessarily the same as the context from the bad job. Dump the MMU
> context from the scheduler determined bad submit to make it work as intended.
>

Good catch!

> Fixes: 17e4660ae3d7 ("drm/etnaviv: implement per-process address spaces on 
> MMUv2")
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_dump.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> index 44b5f3c35aab..898f84a0fc30 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> @@ -130,9 +130,9 @@ void etnaviv_core_dump(struct etnaviv_gem_submit *submit)
> return;
> etnaviv_dump_core = false;
>
> -   mutex_lock(>mmu_context->lock);
> +   mutex_lock(>mmu_context->lock);
>
> -   mmu_size = etnaviv_iommu_dump_size(gpu->mmu_context);
> +   mmu_size = etnaviv_iommu_dump_size(submit->mmu_context);
>
> /* We always dump registers, mmu, ring, hanging cmdbuf and end marker 
> */
> n_obj = 5;
> @@ -162,7 +162,7 @@ void etnaviv_core_dump(struct etnaviv_gem_submit *submit)
> iter.start = __vmalloc(file_size, GFP_KERNEL | __GFP_NOWARN |
> __GFP_NORETRY);
> if (!iter.start) {
> -   mutex_unlock(>mmu_context->lock);
> +   mutex_unlock(>mmu_context->lock);
> dev_warn(gpu->dev, "failed to allocate devcoredump file\n");
> return;
> }
> @@ -174,18 +174,18 @@ void etnaviv_core_dump(struct etnaviv_gem_submit 
> *submit)
> memset(iter.hdr, 0, iter.data - iter.start);
>
> etnaviv_core_dump_registers(, gpu);
> -   etnaviv_core_dump_mmu(, gpu->mmu_context, mmu_size);
> +   etnaviv_core_dump_mmu(, submit->mmu_context, mmu_size);
> etnaviv_core_dump_mem(, ETDUMP_BUF_RING, gpu->buffer.vaddr,
>   gpu->buffer.size,
>   etnaviv_cmdbuf_get_va(>buffer,
> -   >mmu_context->cmdbuf_mapping));
> +   
> >mmu_context->cmdbuf_mapping));
>
> etnaviv_core_dump_mem(, ETDUMP_BUF_CMD,
>   submit->cmdbuf.vaddr, submit->cmdbuf.size,
>   etnaviv_cmdbuf_get_va(>cmdbuf,
> -   >mmu_context->cmdbuf_mapping));
> +   
> >mmu_context->cmdbuf_mapping));
>
> -   mutex_unlock(>mmu_context->lock);
> +   mutex_unlock(>mmu_context->lock);
>
> /* Reserve space for the bomap */
> if (n_bomap_pages) {
> --
> 2.39.2
>


-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy


Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Alex Deucher
On Mon, Apr 17, 2023 at 1:59 AM Christian König
 wrote:
>
> Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:
> > Currently, we allow the framebuffer for a given plane to move between
> > memory domains, however when that happens it causes the screen to
> > flicker, it is even possible for the framebuffer to change memory
> > domains on every plane update (causing a continuous flicker effect). So,
> > to fix this, don't perform an immediate flip in the aforementioned case.
>
> That sounds strongly like you just forget to wait for the move to finish!

It doesn't exhibit when we allow only gtt or only vram, only when
switches between pools does it flicker.

Alex

>
> What is the order of things done here? E.g. who calls amdgpu_bo_pin()
> and who waits for fences for finish signaling? Is that maybe just in the
> wrong order?
>
> Regards,
> Christian.
>
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)")
> > Signed-off-by: Hamza Mahfooz 
> > ---
> >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 ++-
> >   1 file changed, 39 insertions(+), 2 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 da3045fdcb6d..9a4e7408384a 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct 
> > drm_atomic_state *state)
> >   amdgpu_dm_plane_handle_cursor_update(plane, 
> > old_plane_state);
> >   }
> >
> > +static inline uint32_t get_mem_type(struct amdgpu_device *adev,
> > + struct drm_gem_object *obj,
> > + bool check_domain)
> > +{
> > + struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
> > + uint32_t mem_type;
> > +
> > + if (unlikely(amdgpu_bo_reserve(abo, true)))
> > + return 0;
> > +
> > + if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
> > + goto err;
> > +
> > + if (check_domain &&
> > + amdgpu_display_supported_domains(adev, abo->flags) !=
> > + (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
> > + goto err;
> > +
> > + mem_type = abo->tbo.resource->mem_type;
> > + amdgpu_bo_unreserve(abo);
> > +
> > + return mem_type;
> > +
> > +err:
> > + amdgpu_bo_unreserve(abo);
> > + return 0;
> > +}
> > +
> >   static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
> >   struct dc_state *dc_state,
> >   struct drm_device *dev,
> > @@ -7916,6 +7944,7 @@ static void amdgpu_dm_commit_planes(struct 
> > drm_atomic_state *state,
> >   to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, 
> > pcrtc));
> >   int planes_count = 0, vpos, hpos;
> >   unsigned long flags;
> > + uint32_t mem_type;
> >   u32 target_vblank, last_flip_vblank;
> >   bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
> >   bool cursor_update = false;
> > @@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct 
> > drm_atomic_state *state,
> >   }
> >   }
> >
> > + mem_type = get_mem_type(dm->adev, old_plane_state->fb->obj[0],
> > + true);
> > +
> >   /*
> >* Only allow immediate flips for fast updates that don't
> > -  * change FB pitch, DCC state, rotation or mirroing.
> > +  * change memory domain, FB pitch, DCC state, rotation or
> > +  * mirroring.
> >*/
> >   bundle->flip_addrs[planes_count].flip_immediate =
> >   crtc->state->async_flip &&
> > - acrtc_state->update_type == UPDATE_TYPE_FAST;
> > + acrtc_state->update_type == UPDATE_TYPE_FAST &&
> > + (!mem_type || (mem_type && get_mem_type(dm->adev,
> > + fb->obj[0],
> > + false) ==
> > +mem_type));
> >
> >   timestamp_ns = ktime_get_ns();
> >   bundle->flip_addrs[planes_count].flip_timestamp_in_us = 
> > div_u64(timestamp_ns, 1000);
>


Canceled event: XDC 2023 A Corunha Spain @ Tue Oct 17 - Thu Oct 19, 2023 (dri-devel@lists.freedesktop.org)

2023-04-17 Thread mario . kleiner . de
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170848Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
UID:65qeuuc9e0gll25tq5r7e61...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=et
 na...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:etnaviv@lists.freedesktop
 .org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=xo
 rg-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:xorg-devel@lists.freed
 esktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=am
 d-gfx list;X-NUM-GUESTS=0:mailto:amd-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=in
 tel-gfx;X-NUM-GUESTS=0:mailto:intel-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=No
 uveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=mario.
 kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=bo
 a...@foundation.x.org;X-NUM-GUESTS=0:mailto:bo...@foundation.x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=li
 bre-soc-...@lists.libre-soc.org;X-NUM-GUESTS=0:mailto:libre-soc-dev@lists.l
 ibre-soc.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ML
  mesa-dev;X-NUM-GUESTS=0:mailto:mesa-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=me
 mb...@x.org;X-NUM-GUESTS=0:mailto:memb...@x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=fr
 eedr...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:freedreno@lists.freedes
 ktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=dr
 oidbit...@gmail.com;X-NUM-GUESTS=0:mailto:droidbit...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=wa
 yland-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:wayland-devel@lists
 .freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=dr
 i-devel;X-NUM-GUESTS=0:mailto:dri-devel@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=si
 gles...@igalia.com;X-NUM-GUESTS=0:mailto:sigles...@igalia.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ev
 e...@lists.x.org;X-NUM-GUESTS=0:mailto:eve...@lists.x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-NUM
 -GUESTS=0:mailto:bibby.hs...@mediatek.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN="G
 arg, Rohan";X-NUM-GUESTS=0:mailto:rohan.g...@intel.com
X-GOOGLE-CONFERENCE:https://meet.google.com/azn-uwfp-pgw
CREATED:20230417T170310Z
DESCRIPTION:Hello!\n \nRegistration & Call for Proposals are now open for X
 DC 2023\, which will\ntake place on October 17-19\, 2023.\n\nhttps://xdc202
 3.x.org\n \nAs usual\, the conference is free of charge and open to the gen
 eral\npublic. If you plan on attending\, please make sure to register as ea
 rly\nas possible!\n \nIn order to register as attendee\, you will therefore
  need to register\nvia the XDC website.\n \nhttps://indico.freedesktop.org/
 event/4/registrations/\n \nIn addition to registration\, the CfP is now ope
 n for talks\, workshops\nand demos at XDC 2023. While ...\n\n-::~:~::~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\n
 Join with Google Meet: https://meet.google.com/azn-uwfp-pgw\n\nLearn more a
 bout Meet at: https://support.google.com/a/users/answer/9282720\n\nPlease d
 o not edit this section.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20230417T170847Z
LOCATION:
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:XDC 2023 A Corunha Spain
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics


Invitation: XDC 2023 A Corunha Spain @ Tue Oct 17 - Thu Oct 19, 2023 (dri-devel@lists.freedesktop.org)

2023-04-17 Thread mario . kleiner . de
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170311Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
UID:65qeuuc9e0gll25tq5r7e61...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=etna...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:etnaviv@lists.f
 reedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=xorg-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:xorg-devel@l
 ists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=amd-gfx list;X-NUM-GUESTS=0:mailto:amd-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=intel-gfx;X-NUM-GUESTS=0:mailto:intel-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Nouveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=mario.kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner.de@gmail
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=bo...@foundation.x.org;X-NUM-GUESTS=0:mailto:bo...@foundation.x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=libre-soc-...@lists.libre-soc.org;X-NUM-GUESTS=0:mailto:libre-soc-d
 e...@lists.libre-soc.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=ML mesa-dev;X-NUM-GUESTS=0:mailto:mesa-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=memb...@x.org;X-NUM-GUESTS=0:mailto:memb...@x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=freedr...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:freedreno@lis
 ts.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=droidbit...@gmail.com;X-NUM-GUESTS=0:mailto:droidbit...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=wayland-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:wayland-d
 e...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=dri-devel;X-NUM-GUESTS=0:mailto:dri-devel@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=sigles...@igalia.com;X-NUM-GUESTS=0:mailto:sigles...@igalia.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=eve...@lists.x.org;X-NUM-GUESTS=0:mailto:eve...@lists.x.org
X-GOOGLE-CONFERENCE:https://meet.google.com/azn-uwfp-pgw
X-MICROSOFT-CDO-OWNERAPPTID:-1074514126
CREATED:20230417T170310Z
DESCRIPTION:Hello!\n \nRegistration & Call for Proposals are now open for X
 DC 2023\, which will\ntake place on October 17-19\, 2023.\n\nhttps://xdc202
 3.x.org\n \nAs usual\, the conference is free of charge and open to the gen
 eral\npublic. If you plan on attending\, please make sure to register as ea
 rly\nas possible!\n \nIn order to register as attendee\, you will therefore
  need to register\nvia the XDC website.\n \nhttps://indico.freedesktop.org/
 event/4/registrations/\n \nIn addition to registration\, the CfP is now ope
 n for talks\, workshops\nand demos at XDC 2023. While ...\n\n-::~:~::~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\n
 Join with Google Meet: https://meet.google.com/azn-uwfp-pgw\n\nLearn more a
 bout Meet at: https://support.google.com/a/users/answer/9282720\n\nPlease d
 o not edit this section.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20230417T170310Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:XDC 2023 A Corunha Spain
TRANSP:TRANSPARENT
BEGIN:VALARM
ACTION:EMAIL
DESCRIPTION:This is an event reminder
SUMMARY:Alarm notification
ATTENDEE:mailto:dri-devel@lists.freedesktop.org
TRIGGER:-P0DT0H30M0S
END:VALARM
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H30M0S
END:VALARM
BEGIN:VALARM
ACTION:EMAIL
DESCRIPTION:This is an event reminder
SUMMARY:Alarm notification
ATTENDEE:mailto:dri-devel@lists.freedesktop.org
TRIGGER:-P0DT7H30M0S
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics


Re: [Nouveau] XDC 2023: Registration & Call for Proposals now open!

2023-04-17 Thread Luna Jernberg
Signed up will only attend virtually Online however just fyi

On Mon, Apr 17, 2023 at 1:41 PM Samuel Iglesias Gonsálvez
 wrote:
>
> Hello!
>
> Registration & Call for Proposals are now open for XDC 2023, which will
> take place on October 17-19, 2023.
>
> https://xdc2023.x.org
>
> As usual, the conference is free of charge and open to the general
> public. If you plan on attending, please make sure to register as early
> as possible!
>
> In order to register as attendee, you will therefore need to register
> via the XDC website.
>
> https://indico.freedesktop.org/event/4/registrations/
>
> In addition to registration, the CfP is now open for talks, workshops
> and demos at XDC 2023. While any serious proposal will be gratefully
> considered, topics of interest to X.Org and freedesktop.org developers
> are encouraged. The program focus is on new development, ongoing
> challenges and anything else that will spark discussions among
> attendees in the hallway track.
>
> We are open to talks across all layers of the graphics stack, from the
> kernel to desktop environments / graphical applications and about how
> to make things better for the developers who build them. Head to the
> CfP page to learn more:
>
> https://indico.freedesktop.org/event/4/abstracts/
>
> The deadline for submissions is Monday, 17 July 2023 (23:59 CEST)
>
> Check out our Reimbursement Policy to accept speaker expenses:
>
> https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/
>
> If you have any questions, please send me an email to
> siglesias AT igalia.com, adding on Cc the X.org board (board
> at foundation.x.org).
>
> And please keep in mind, you can follow us on Twitter for all the latest
> updates and to stay connected:
>
> https://twitter.com/XOrgDevConf
>
> Best,
>
> Sam


Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode

2023-04-17 Thread Hamza Mahfooz

On 4/17/23 11:41, Wu, Hersen wrote:

[AMD Official Use Only - General]

Hi,

The change applies to all AMD GPU ASIC.
Please communicate with issue reporter to see if the issue could be reproduced 
older ASIC, like Mendocino, CZN.


From the community reports, it can be reproduced on as far back as the
Ryzen 4800H (which I guess is Renoir).



Thanks!
Hersen


-Original Message-
From: Mahfooz, Hamza 
Sent: Monday, April 17, 2023 11:26 AM
To: Koenig, Christian ; amd-...@lists.freedesktop.org
Cc: sta...@vger.kernel.org; Wentland, Harry ; Li, Sun peng (Leo) ; Siqueira, Rodrigo 
; Deucher, Alexander ; Pan, Xinhui ; David Airlie 
; Daniel Vetter ; Pillai, Aurabindo ; Zhuo, Qingqing (Lillian) 
; Hans de Goede ; Wu, Hersen ; Wang, Chao-kai (Stylon) 
; Tuikov, Luben ; dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amd/display: fix flickering caused by S/G mode


On 4/17/23 11:03, Christian König wrote:

Am 17.04.23 um 16:51 schrieb Hamza Mahfooz:


On 4/17/23 01:59, Christian König wrote:

Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:

Currently, we allow the framebuffer for a given plane to move
between memory domains, however when that happens it causes the
screen to flicker, it is even possible for the framebuffer to
change memory domains on every plane update (causing a continuous flicker 
effect).
So,
to fix this, don't perform an immediate flip in the aforementioned
case.


That sounds strongly like you just forget to wait for the move to
finish!

What is the order of things done here? E.g. who calls
amdgpu_bo_pin() and who waits for fences for finish signaling? Is
that maybe just in the wrong order?


The pinning logic is in dm_plane_helper_prepare_fb(). Also, it seems
like we wait for the fences in amdgpu_dm_atomic_commit_tail(), using
drm_atomic_helper_wait_for_fences(). The ordering should be fine as
well, since prepare_fb() is always called before atomic_commit_tail().


Ok, then why is there any flickering?

BTW reserving a fence slot is completely unnecessary. That looks like
you copy the code from somewhere else without checking what it
actually does.


It seemed like it was necessary to read `tbo.resource` since the documentation for 
`struct ttm_buffer_object` makes mention of a "bo::resv::reserved" lock.



Regards,
Christian.





Regards,
Christian.



Cc: sta...@vger.kernel.org
Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more
flexible
(v2)")
Signed-off-by: Hamza Mahfooz 
---
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41
++-
   1 file changed, 39 insertions(+), 2 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 da3045fdcb6d..9a4e7408384a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct
drm_atomic_state *state)
   amdgpu_dm_plane_handle_cursor_update(plane,
old_plane_state);
   }
+static inline uint32_t get_mem_type(struct amdgpu_device *adev,
+    struct drm_gem_object *obj,
+    bool check_domain) {
+    struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
+    uint32_t mem_type;
+
+    if (unlikely(amdgpu_bo_reserve(abo, true)))
+    return 0;
+
+    if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
+    goto err;
+
+    if (check_domain &&
+    amdgpu_display_supported_domains(adev, abo->flags) !=
+    (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
+    goto err;
+
+    mem_type = abo->tbo.resource->mem_type;
+    amdgpu_bo_unreserve(abo);
+
+    return mem_type;
+
+err:
+    amdgpu_bo_unreserve(abo);
+    return 0;
+}
+
   static void amdgpu_dm_commit_planes(struct drm_atomic_state
*state,
   struct dc_state *dc_state,
   struct drm_device *dev, @@ -7916,6 +7944,7 @@
static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, pcrtc));
   int planes_count = 0, vpos, hpos;
   unsigned long flags;
+    uint32_t mem_type;
   u32 target_vblank, last_flip_vblank;
   bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
   bool cursor_update = false;
@@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
   }
   }
+    mem_type = get_mem_type(dm->adev,
+old_plane_state->fb->obj[0],
+    true);
+
   /*
    * Only allow immediate flips for fast updates that don't
- * change FB pitch, DCC state, rotation or mirroing.
+ * change memory domain, FB pitch, DCC state, rotation or
+ * mirroring.
    */
   bundle->flip_addrs[planes_count].flip_immediate =
   crtc->state->async_flip &&
-    acrtc_state->update_type == UPDATE_TYPE_FAST;
+    

Re: [PATCH 0/9] GPU-DRM-nouveau: Adjustments for seven function implementations

2023-04-17 Thread Karol Herbst
On Sun, Apr 16, 2023 at 11:30 AM Markus Elfring  wrote:
>
> Date: Sun, 16 Apr 2023 11:22:23 +0200
>
> Several update suggestions were taken into account
> from static source code analysis.
>

Reviewed-by: Karol Herbst 

> Markus Elfring (9):
>   debugfs: Move an expression into a function call parameter
> in nouveau_debugfs_pstate_set()
>   debugfs: Move a variable assignment behind a null pointer check
> in nouveau_debugfs_pstate_get()
>   debugfs: Use seq_putc()
> in nouveau_debugfs_pstate_get()
>   debugfs: Replace five seq_printf() calls by seq_puts()
> in nouveau_debugfs_pstate_get()
>   power_budget: Move an expression into a macro call parameter
> in nvbios_power_budget_header()
>   clk: Move a variable assignment behind a null pointer check
> in nvkm_pstate_new()
>   pci: Move a variable assignment behind condition checks
> in nvkm_pcie_set_link()
>   pci: Move an expression into a function call parameter
> in nvkm_pcie_set_link()
>   therm: Move an assignment statement behind a null pointer check
> in two functions
>
>  drivers/gpu/drm/nouveau/nouveau_debugfs.c | 19 ++-
>  .../nouveau/nvkm/subdev/bios/power_budget.c   |  3 +--
>  .../gpu/drm/nouveau/nvkm/subdev/clk/base.c|  2 +-
>  .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c|  7 +++
>  .../drm/nouveau/nvkm/subdev/therm/fanpwm.c|  2 +-
>  .../drm/nouveau/nvkm/subdev/therm/fantog.c|  2 +-
>  6 files changed, 17 insertions(+), 18 deletions(-)
>
> --
> 2.40.0
>



Re: [PATCH v4 5/5] drm/test: Add test cases for drm_rect_rotate_inv()

2023-04-17 Thread Maíra Canal

On 4/6/23 08:53, Arthur Grillo wrote:

Insert a parameterized test for the drm_rect_rotate_inv() to ensure its
correctness and prevent future regressions. The test covers all rotation
modes.

It uses the same test cases from drm_test_rect_rotate().

Signed-off-by: Arthur Grillo 


Thanks for the patch!

Reviewed-by: Maíra Canal 

Best Regards,
- Maíra Canal


---
  drivers/gpu/drm/tests/drm_rect_test.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/tests/drm_rect_test.c 
b/drivers/gpu/drm/tests/drm_rect_test.c
index 1269dfc8b756..6d85e78ba903 100644
--- a/drivers/gpu/drm/tests/drm_rect_test.c
+++ b/drivers/gpu/drm/tests/drm_rect_test.c
@@ -543,6 +543,16 @@ static void drm_test_rect_rotate(struct kunit *test)
drm_rect_compare(test, , >expected);
  }
  
+static void drm_test_rect_rotate_inv(struct kunit *test)

+{
+   const struct drm_rect_rotate_case *params = test->param_value;
+   struct drm_rect r = params->expected;
+
+   drm_rect_rotate_inv(, params->width, params->height, 
params->rotation);
+
+   drm_rect_compare(test, , >rect);
+}
+
  static struct kunit_case drm_rect_tests[] = {
KUNIT_CASE(drm_test_rect_clip_scaled_div_by_zero),
KUNIT_CASE(drm_test_rect_clip_scaled_not_clipped),
@@ -552,6 +562,7 @@ static struct kunit_case drm_rect_tests[] = {
KUNIT_CASE_PARAM(drm_test_rect_calc_hscale, drm_rect_hscale_gen_params),
KUNIT_CASE_PARAM(drm_test_rect_calc_vscale, drm_rect_vscale_gen_params),
KUNIT_CASE_PARAM(drm_test_rect_rotate, drm_rect_rotate_gen_params),
+   KUNIT_CASE_PARAM(drm_test_rect_rotate_inv, drm_rect_rotate_gen_params),
{ }
  };
  


Re: [PATCH v4 4/5] drm/tests: Add test cases for drm_rect_rotate()

2023-04-17 Thread Maíra Canal

On 4/6/23 08:53, Arthur Grillo wrote:

Insert a parameterized test for the drm_rect_rotate() to ensure
correctness and prevent future regressions.

All possible rotation modes are covered by the test.

Signed-off-by: Arthur Grillo 


Thanks for the patch!

Reviewed-by: Maíra Canal 

Best Regards,
- Maíra Canal


---
  drivers/gpu/drm/tests/drm_rect_test.c | 72 +++
  1 file changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/tests/drm_rect_test.c 
b/drivers/gpu/drm/tests/drm_rect_test.c
index a1fd9b2c5128..1269dfc8b756 100644
--- a/drivers/gpu/drm/tests/drm_rect_test.c
+++ b/drivers/gpu/drm/tests/drm_rect_test.c
@@ -8,6 +8,7 @@
  #include 
  
  #include 

+#include 
  
  #include 

  #include 
@@ -472,6 +473,76 @@ static void drm_test_rect_calc_vscale(struct kunit *test)
KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
  }
  
+struct drm_rect_rotate_case {

+   const char *name;
+   unsigned int rotation;
+   struct drm_rect rect;
+   int width, height;
+   struct drm_rect expected;
+};
+
+static const struct drm_rect_rotate_case drm_rect_rotate_cases[] = {
+   {
+   .name = "reflect-x",
+   .rotation = DRM_MODE_REFLECT_X,
+   .rect = DRM_RECT_INIT(0, 0, 5, 5),
+   .width = 5, .height = 10,
+   .expected = DRM_RECT_INIT(0, 0, 5, 5),
+   },
+   {
+   .name = "reflect-y",
+   .rotation = DRM_MODE_REFLECT_Y,
+   .rect = DRM_RECT_INIT(0, 0, 5, 5),
+   .width = 5, .height = 10,
+   .expected = DRM_RECT_INIT(0, 5, 5, 5),
+   },
+   {
+   .name = "rotate-0",
+   .rotation = DRM_MODE_ROTATE_0,
+   .rect = DRM_RECT_INIT(0, 0, 5, 5),
+   .width = 5, .height = 10,
+   .expected = DRM_RECT_INIT(0, 0, 5, 5),
+   },
+   {
+   .name = "rotate-90",
+   .rotation = DRM_MODE_ROTATE_90,
+   .rect = DRM_RECT_INIT(0, 0, 5, 10),
+   .width = 5, .height = 10,
+   .expected = DRM_RECT_INIT(0, 0, 10, 5),
+   },
+   {
+   .name = "rotate-180",
+   .rotation = DRM_MODE_ROTATE_180,
+   .rect = DRM_RECT_INIT(0, 0, 5, 10),
+   .width = 5, .height = 10,
+   .expected = DRM_RECT_INIT(0, 0, 5, 10),
+   },
+   {
+   .name = "rotate-270",
+   .rotation = DRM_MODE_ROTATE_270,
+   .rect = DRM_RECT_INIT(0, 0, 5, 10),
+   .width = 5, .height = 10,
+   .expected = DRM_RECT_INIT(0, 0, 10, 5),
+   },
+};
+
+static void drm_rect_rotate_case_desc(const struct drm_rect_rotate_case *t, 
char *desc)
+{
+   strscpy(desc, t->name, KUNIT_PARAM_DESC_SIZE);
+}
+
+KUNIT_ARRAY_PARAM(drm_rect_rotate, drm_rect_rotate_cases, 
drm_rect_rotate_case_desc);
+
+static void drm_test_rect_rotate(struct kunit *test)
+{
+   const struct drm_rect_rotate_case *params = test->param_value;
+   struct drm_rect r = params->rect;
+
+   drm_rect_rotate(, params->width, params->height, params->rotation);
+
+   drm_rect_compare(test, , >expected);
+}
+
  static struct kunit_case drm_rect_tests[] = {
KUNIT_CASE(drm_test_rect_clip_scaled_div_by_zero),
KUNIT_CASE(drm_test_rect_clip_scaled_not_clipped),
@@ -480,6 +551,7 @@ static struct kunit_case drm_rect_tests[] = {
KUNIT_CASE_PARAM(drm_test_rect_intersect, 
drm_rect_intersect_gen_params),
KUNIT_CASE_PARAM(drm_test_rect_calc_hscale, drm_rect_hscale_gen_params),
KUNIT_CASE_PARAM(drm_test_rect_calc_vscale, drm_rect_vscale_gen_params),
+   KUNIT_CASE_PARAM(drm_test_rect_rotate, drm_rect_rotate_gen_params),
{ }
  };
  


Re: [RFC 3/6] drm: Add fdinfo memory stats

2023-04-17 Thread Christian König




Am 17.04.23 um 17:56 schrieb Tvrtko Ursulin:

From: Tvrtko Ursulin 

Add support to dump GEM stats to fdinfo.

Signed-off-by: Tvrtko Ursulin 
---
  Documentation/gpu/drm-usage-stats.rst | 12 +++
  drivers/gpu/drm/drm_file.c| 52 +++
  include/drm/drm_drv.h |  7 
  include/drm/drm_file.h|  8 +
  4 files changed, 79 insertions(+)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index 2ab32c40e93c..8273a41b2fb0 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -21,6 +21,7 @@ File format specification
  
  - File shall contain one key value pair per one line of text.

  - Colon character (`:`) must be used to delimit keys and values.
+- Caret (`^`) is also a reserved character.
  - All keys shall be prefixed with `drm-`.
  - Whitespace between the delimiter and first non-whitespace character shall be
ignored when parsing.
@@ -105,6 +106,17 @@ object belong to this client, in the respective memory 
region.
  Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
  indicating kibi- or mebi-bytes.
  
+- drm-memory-^size:   [KiB|MiB]

+- drm-memory-^shared: [KiB|MiB]
+- drm-memory-^resident:   [KiB|MiB]
+- drm-memory-^purgeable:  [KiB|MiB]
+- drm-memory-^active: [KiB|MiB]


What exactly does size/shared/active mean here?

If it means what I think it does I don't see how TTM based drivers 
should track that in the first place.


Christian.


+
+Resident category is identical to the drm-memory- key and two should be
+mutually exclusive.
+
+TODO more description text...
+
  - drm-cycles- 
  
  Engine identifier string must be the same as the one specified in the

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 37b4f76a5191..e202f79e816d 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -42,6 +42,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include "drm_crtc_internal.h"

@@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct 
drm_pending_event *e)
  }
  EXPORT_SYMBOL(drm_send_event);
  
+static void

+print_stat(struct drm_printer *p, const char *stat, const char *region, u64 sz)
+{
+   const char *units[] = {"", " KiB", " MiB"};
+   unsigned int u;
+
+   if (sz == ~0ull) /* Not supported by the driver. */
+   return;
+
+   for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
+   if (sz < SZ_1K)
+   break;
+   sz = div_u64(sz, SZ_1K);
+   }
+
+   drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
+  region, stat, sz, units[u]);
+}
+
+static void print_memory_stats(struct drm_printer *p, struct drm_file *file)
+{
+   struct drm_device *dev = file->minor->dev;
+   struct drm_fdinfo_memory_stat *stats;
+   unsigned int num, i;
+   char **regions;
+
+   regions = dev->driver->query_fdinfo_memory_regions(dev, );
+
+   stats = kcalloc(num, sizeof(*stats), GFP_KERNEL);
+   if (!stats)
+   return;
+
+   dev->driver->query_fdinfo_memory_stats(file, stats);
+
+   for (i = 0; i < num; i++) {
+   if (!regions[i]) /* Allow sparse name arrays. */
+   continue;
+
+   print_stat(p, "size", regions[i], stats[i].size);
+   print_stat(p, "shared", regions[i], stats[i].shared);
+   print_stat(p, "resident", regions[i], stats[i].resident);
+   print_stat(p, "purgeable", regions[i], stats[i].purgeable);
+   print_stat(p, "active", regions[i], stats[i].active);
+   }
+
+   kfree(stats);
+}
+
  /**
   * drm_show_fdinfo - helper for drm file fops
   * @seq_file: output stream
@@ -900,6 +949,9 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
  
  	if (dev->driver->show_fdinfo)

dev->driver->show_fdinfo(, file);
+
+   if (dev->driver->query_fdinfo_memory_regions)
+   print_memory_stats(, file);
  }
  EXPORT_SYMBOL(drm_show_fdinfo);
  
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h

index 89e2706cac56..ccc1cd98d2aa 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -35,6 +35,7 @@
  #include 
  
  struct drm_file;

+struct drm_fdinfo_memory_stat;
  struct drm_gem_object;
  struct drm_master;
  struct drm_minor;
@@ -408,6 +409,12 @@ struct drm_driver {
 */
void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
  
+	char ** (*query_fdinfo_memory_regions)(struct drm_device *dev,

+  unsigned int *num);
+
+   void (*query_fdinfo_memory_stats)(struct drm_file *f,
+ struct drm_fdinfo_memory_stat *stat);
+
/** @major: driver major number */
int major;
/** @minor: driver minor number */
diff --git a/include/drm/drm_file.h 

Re: [PATCH v4 3/5] drm/tests: Add test cases for drm_rect_calc_vscale()

2023-04-17 Thread Maíra Canal

On 4/6/23 08:53, Arthur Grillo wrote:

Insert parameterized test for the drm_rect_calc_vscale() to ensure
correctness and prevent future regressions. Besides the test for the
usual case, tests the exceptions.

It uses the same struct from drm_rect_calc_hscale().

Signed-off-by: Arthur Grillo 
---
  drivers/gpu/drm/tests/drm_rect_test.c | 59 +++
  1 file changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/tests/drm_rect_test.c 
b/drivers/gpu/drm/tests/drm_rect_test.c
index 44150545c1bc..a1fd9b2c5128 100644
--- a/drivers/gpu/drm/tests/drm_rect_test.c
+++ b/drivers/gpu/drm/tests/drm_rect_test.c
@@ -414,6 +414,64 @@ static void drm_test_rect_calc_hscale(struct kunit *test)
KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
  }
  
+static const struct drm_rect_scale_case drm_rect_vscale_cases[] = {

+   {
+   .name = "normal use",
+   .src = DRM_RECT_INIT(0, 0, 0, 2 << 16),
+   .dst = DRM_RECT_INIT(0, 0, 0, 1 << 16),
+   .min_range = 0, .max_range = INT_MAX,
+   .expected_scaling_factor = 2,
+   },
+   {
+   .name = "out of max range",
+   .src = DRM_RECT_INIT(0, 0, 0, 10 << 16),
+   .dst = DRM_RECT_INIT(0, 0, 0, 1 << 16),
+   .min_range = 3, .max_range = 5,
+   .expected_scaling_factor = -ERANGE,
+   },
+   {
+   .name = "out of min range",
+   .src = DRM_RECT_INIT(0, 0, 0, 2 << 16),
+   .dst = DRM_RECT_INIT(0, 0, 0, 1 << 16),
+   .min_range = 3, .max_range = 5,
+   .expected_scaling_factor = -ERANGE,
+   },
+   {
+   .name = "zero dst height",
+   .src = DRM_RECT_INIT(0, 0, 0, 2 << 16),
+   .dst = DRM_RECT_INIT(0, 0, 0, 0 << 16),
+   .min_range = 0, .max_range = INT_MAX,
+   .expected_scaling_factor = 0,
+   },
+   {
+   .name = "negative src height",
+   .src = DRM_RECT_INIT(0, 0, 0, -(1 << 16)),
+   .dst = DRM_RECT_INIT(0, 0, 0, 1 << 16),
+   .min_range = 0, .max_range = INT_MAX,
+   .expected_scaling_factor = -EINVAL,
+   },
+   {
+   .name = "negative dst height",
+   .src = DRM_RECT_INIT(0, 0, 0, 1 << 16),
+   .dst = DRM_RECT_INIT(0, 0, 0, -(1 << 16)),
+   .min_range = 0, .max_range = INT_MAX,
+   .expected_scaling_factor = -EINVAL,
+   },
+};
+


Would it possible to use the same parameter array for vscale and hscale?

Best Regards,
- Maíra Canal


+KUNIT_ARRAY_PARAM(drm_rect_vscale, drm_rect_vscale_cases, 
drm_rect_scale_case_desc);
+
+static void drm_test_rect_calc_vscale(struct kunit *test)
+{
+   const struct drm_rect_scale_case *params = test->param_value;
+   int scaling_factor;
+
+   scaling_factor = drm_rect_calc_vscale(>src, >dst,
+ params->min_range, 
params->max_range);
+
+   KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
+}
+
  static struct kunit_case drm_rect_tests[] = {
KUNIT_CASE(drm_test_rect_clip_scaled_div_by_zero),
KUNIT_CASE(drm_test_rect_clip_scaled_not_clipped),
@@ -421,6 +479,7 @@ static struct kunit_case drm_rect_tests[] = {
KUNIT_CASE(drm_test_rect_clip_scaled_signed_vs_unsigned),
KUNIT_CASE_PARAM(drm_test_rect_intersect, 
drm_rect_intersect_gen_params),
KUNIT_CASE_PARAM(drm_test_rect_calc_hscale, drm_rect_hscale_gen_params),
+   KUNIT_CASE_PARAM(drm_test_rect_calc_vscale, drm_rect_vscale_gen_params),
{ }
  };
  


Re: [PATCH v4 1/5] drm/tests: Add test cases for drm_rect_intersect()

2023-04-17 Thread Maíra Canal

On 4/6/23 08:53, Arthur Grillo wrote:

Insert parameterized tests for the drm_rect_intersect() to ensure
correctness and prevent future regressions.

Also, create a helper for testing if two drm_rects are equal.

Signed-off-by: Arthur Grillo 


Thanks for the patch!

Reviewed-by: Maíra Canal 

Best Regards,
- Maíra Canal


---
  drivers/gpu/drm/tests/drm_rect_test.c | 148 ++
  1 file changed, 148 insertions(+)

diff --git a/drivers/gpu/drm/tests/drm_rect_test.c 
b/drivers/gpu/drm/tests/drm_rect_test.c
index e9809ea32696..33584f63be37 100644
--- a/drivers/gpu/drm/tests/drm_rect_test.c
+++ b/drivers/gpu/drm/tests/drm_rect_test.c
@@ -9,6 +9,17 @@
  
  #include 
  
+#include 

+
+static void drm_rect_compare(struct kunit *test, const struct drm_rect *r,
+const struct drm_rect *expected)
+{
+   KUNIT_EXPECT_EQ(test, r->x1, expected->x1);
+   KUNIT_EXPECT_EQ(test, r->y1, expected->y1);
+   KUNIT_EXPECT_EQ(test, drm_rect_width(r), drm_rect_width(expected));
+   KUNIT_EXPECT_EQ(test, drm_rect_height(r), drm_rect_height(expected));
+}
+
  static void drm_test_rect_clip_scaled_div_by_zero(struct kunit *test)
  {
struct drm_rect src, dst, clip;
@@ -196,11 +207,148 @@ static void 
drm_test_rect_clip_scaled_signed_vs_unsigned(struct kunit *test)
KUNIT_EXPECT_FALSE_MSG(test, drm_rect_visible(), "Source should not be 
visible\n");
  }
  
+struct drm_rect_intersect_case {

+   const char *description;
+   struct drm_rect r1, r2;
+   bool should_be_visible;
+   struct drm_rect expected_intersection;
+};
+
+static const struct drm_rect_intersect_case drm_rect_intersect_cases[] = {
+   {
+   .description = "top-left x bottom-right",
+   .r1 = DRM_RECT_INIT(1, 1, 2, 2),
+   .r2 = DRM_RECT_INIT(0, 0, 2, 2),
+   .should_be_visible = true,
+   .expected_intersection = DRM_RECT_INIT(1, 1, 1, 1),
+   },
+   {
+   .description = "top-right x bottom-left",
+   .r1 = DRM_RECT_INIT(0, 0, 2, 2),
+   .r2 = DRM_RECT_INIT(1, -1, 2, 2),
+   .should_be_visible = true,
+   .expected_intersection = DRM_RECT_INIT(1, 0, 1, 1),
+   },
+   {
+   .description = "bottom-left x top-right",
+   .r1 = DRM_RECT_INIT(1, -1, 2, 2),
+   .r2 = DRM_RECT_INIT(0, 0, 2, 2),
+   .should_be_visible = true,
+   .expected_intersection = DRM_RECT_INIT(1, 0, 1, 1),
+   },
+   {
+   .description = "bottom-right x top-left",
+   .r1 = DRM_RECT_INIT(0, 0, 2, 2),
+   .r2 = DRM_RECT_INIT(1, 1, 2, 2),
+   .should_be_visible = true,
+   .expected_intersection = DRM_RECT_INIT(1, 1, 1, 1),
+   },
+   {
+   .description = "right x left",
+   .r1 = DRM_RECT_INIT(0, 0, 2, 1),
+   .r2 = DRM_RECT_INIT(1, 0, 3, 1),
+   .should_be_visible = true,
+   .expected_intersection = DRM_RECT_INIT(1, 0, 1, 1),
+   },
+   {
+   .description = "left x right",
+   .r1 = DRM_RECT_INIT(1, 0, 3, 1),
+   .r2 = DRM_RECT_INIT(0, 0, 2, 1),
+   .should_be_visible = true,
+   .expected_intersection = DRM_RECT_INIT(1, 0, 1, 1),
+   },
+   {
+   .description = "up x bottom",
+   .r1 = DRM_RECT_INIT(0, 0, 1, 2),
+   .r2 = DRM_RECT_INIT(0, -1, 1, 3),
+   .should_be_visible = true,
+   .expected_intersection = DRM_RECT_INIT(0, 0, 1, 2),
+   },
+   {
+   .description = "bottom x up",
+   .r1 = DRM_RECT_INIT(0, -1, 1, 3),
+   .r2 = DRM_RECT_INIT(0, 0, 1, 2),
+   .should_be_visible = true,
+   .expected_intersection = DRM_RECT_INIT(0, 0, 1, 2),
+   },
+   {
+   .description = "touching corner",
+   .r1 = DRM_RECT_INIT(0, 0, 1, 1),
+   .r2 = DRM_RECT_INIT(1, 1, 2, 2),
+   .should_be_visible = false,
+   .expected_intersection = DRM_RECT_INIT(1, 1, 0, 0),
+   },
+   {
+   .description = "touching side",
+   .r1 = DRM_RECT_INIT(0, 0, 1, 1),
+   .r2 = DRM_RECT_INIT(1, 0, 1, 1),
+   .should_be_visible = false,
+   .expected_intersection = DRM_RECT_INIT(1, 0, 0, 1),
+   },
+   {
+   .description = "equal rects",
+   .r1 = DRM_RECT_INIT(0, 0, 2, 2),
+   .r2 = DRM_RECT_INIT(0, 0, 2, 2),
+   .should_be_visible = true,
+   .expected_intersection = DRM_RECT_INIT(0, 0, 2, 2),
+   },
+   {
+   .description = "inside another",
+   .r1 = DRM_RECT_INIT(0, 0, 2, 2),
+   .r2 = DRM_RECT_INIT(1, 1, 1, 1),
+   .should_be_visible = true,
+ 

Re: [PATCH v3 6/7] drm: Add fdinfo memory stats

2023-04-17 Thread Rob Clark
On Mon, Apr 17, 2023 at 7:20 AM Tvrtko Ursulin
 wrote:
>
>
> On 17/04/2023 14:42, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 4:10 AM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 16/04/2023 08:48, Daniel Vetter wrote:
> >>> On Fri, Apr 14, 2023 at 06:40:27AM -0700, Rob Clark wrote:
>  On Fri, Apr 14, 2023 at 1:57 AM Tvrtko Ursulin
>   wrote:
> >
> >
> > On 13/04/2023 21:05, Daniel Vetter wrote:
> >> On Thu, Apr 13, 2023 at 05:40:21PM +0100, Tvrtko Ursulin wrote:
> >>>
> >>> On 13/04/2023 14:27, Daniel Vetter wrote:
>  On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
> >
> > On 12/04/2023 20:18, Daniel Vetter wrote:
> >> On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> >>> On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter  
> >>> wrote:
> 
>  On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> > On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 11/04/2023 23:56, Rob Clark wrote:
> >>> From: Rob Clark 
> >>>
> >>> Add support to dump GEM stats to fdinfo.
> >>>
> >>> v2: Fix typos, change size units to match docs, use div_u64
> >>> v3: Do it in core
> >>>
> >>> Signed-off-by: Rob Clark 
> >>> Reviewed-by: Emil Velikov 
> >>> ---
> >>>Documentation/gpu/drm-usage-stats.rst | 21 
> >>>drivers/gpu/drm/drm_file.c| 76 
> >>> +++
> >>>include/drm/drm_file.h|  1 +
> >>>include/drm/drm_gem.h | 19 +++
> >>>4 files changed, 117 insertions(+)
> >>>
> >>> diff --git a/Documentation/gpu/drm-usage-stats.rst 
> >>> b/Documentation/gpu/drm-usage-stats.rst
> >>> index b46327356e80..b5e7802532ed 100644
> >>> --- a/Documentation/gpu/drm-usage-stats.rst
> >>> +++ b/Documentation/gpu/drm-usage-stats.rst
> >>> @@ -105,6 +105,27 @@ object belong to this client, in the 
> >>> respective memory region.
> >>>Default unit shall be bytes with optional unit 
> >>> specifiers of 'KiB' or 'MiB'
> >>>indicating kibi- or mebi-bytes.
> >>>
> >>> +- drm-shared-memory:  [KiB|MiB]
> >>> +
> >>> +The total size of buffers that are shared with another file 
> >>> (ie. have more
> >>> +than a single handle).
> >>> +
> >>> +- drm-private-memory:  [KiB|MiB]
> >>> +
> >>> +The total size of buffers that are not shared with another 
> >>> file.
> >>> +
> >>> +- drm-resident-memory:  [KiB|MiB]
> >>> +
> >>> +The total size of buffers that are resident in system memory.
> >>
> >> I think this naming maybe does not work best with the existing
> >> drm-memory- keys.
> >
> > Actually, it was very deliberate not to conflict with the 
> > existing
> > drm-memory- keys ;-)
> >
> > I wouldn't have preferred drm-memory-{active,resident,...} but 
> > it
> > could be mis-parsed by existing userspace so my hands were a 
> > bit tied.
> >
> >> How about introduce the concept of a memory region from the 
> >> start and
> >> use naming similar like we do for engines?
> >>
> >> drm-memory-$CATEGORY-$REGION: ...
> >>
> >> Then we document a bunch of categories and their semantics, 
> >> for instance:
> >>
> >> 'size' - All reachable objects
> >> 'shared' - Subset of 'size' with handle_count > 1
> >> 'resident' - Objects with backing store
> >> 'active' - Objects in use, subset of resident
> >> 'purgeable' - Or inactive? Subset of resident.
> >>
> >> We keep the same semantics as with process memory accounting 
> >> (if I got
> >> it right) which could be desirable for a simplified mental 
> >> model.
> >>
> >> (AMD needs to remind me of their 'drm-memory-...' keys 
> >> semantics. If we
> >> correctly captured this in the first round it should be 
> >> equivalent to
> >> 'resident' above. In any case we can document no category is 
> >> equal to
> >> which category, and at most one of the two must be output.)
> >>
> >> Region 

[RFC 5/6] drm/msm: Add basic memory stats

2023-04-17 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Use DRM helpers for implementing basic memory stats.

Signed-off-by: Tvrtko Ursulin 
Cc: Rob Clark 
---
 drivers/gpu/drm/msm/msm_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 060c7689a739..7662103b5999 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1090,6 +1090,10 @@ static const struct drm_driver msm_driver = {
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
.gem_prime_mmap = msm_gem_prime_mmap,
+#ifdef CONFIG_PROC_FS
+   .query_fdinfo_memory_regions = drm_query_fdinfo_system_region,
+   .query_fdinfo_memory_stats = drm_query_fdinfo_system_memory,
+#endif
 #ifdef CONFIG_DEBUG_FS
.debugfs_init   = msm_debugfs_init,
 #endif
-- 
2.37.2



[RFC 6/6] drm/i915: Implement fdinfo memory stats printing

2023-04-17 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Show how more driver specific set of memory stats could be shown,
more specifically where object can reside in multiple regions, showing all
the supported stats, and where there is more to show than just user visible
objects.

WIP...

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_driver.c |   5 ++
 drivers/gpu/drm/i915/i915_drm_client.c | 102 +
 drivers/gpu/drm/i915/i915_drm_client.h |   8 ++
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 4 files changed, 117 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 6493548c69bf..4c70206cbc27 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver = {
.dumb_create = i915_gem_dumb_create,
.dumb_map_offset = i915_gem_dumb_mmap_offset,
 
+#ifdef CONFIG_PROC_FS
+   .query_fdinfo_memory_regions = i915_query_fdinfo_memory_regions,
+   .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
+#endif
+
.ioctls = i915_ioctls,
.num_ioctls = ARRAY_SIZE(i915_ioctls),
.fops = _driver_fops,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index c654984189f7..65857c68bdb3 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -12,6 +12,7 @@
 #include 
 
 #include "gem/i915_gem_context.h"
+#include "intel_memory_region.h"
 #include "i915_drm_client.h"
 #include "i915_file_private.h"
 #include "i915_gem.h"
@@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct 
drm_file *file)
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
show_client_class(p, i915, file_priv->client, i);
 }
+
+char **
+i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int *num)
+{
+   struct drm_i915_private *i915 = to_i915(dev);
+   struct intel_memory_region *mr;
+   enum intel_region_id id;
+
+   /* FIXME move to init */
+   for_each_memory_region(mr, i915, id) {
+   if (!i915->mm.region_names[id])
+   i915->mm.region_names[id] = mr->name;
+   }
+
+   *num = id;
+
+   return i915->mm.region_names;
+}
+
+static void
+add_obj(struct drm_i915_gem_object *obj, struct drm_fdinfo_memory_stat *stats)
+{
+struct intel_memory_region *mr;
+   u64 sz = obj->base.size;
+enum intel_region_id id;
+   unsigned int i;
+
+   if (!obj)
+   return;
+
+   /* Attribute size and shared to all possible memory regions. */
+   for (i = 0; i < obj->mm.n_placements; i++) {
+   mr = obj->mm.placements[i];
+   id = mr->id;
+
+   stats[id].size += sz;
+   if (obj->base.handle_count > 1)
+   stats[id].shared += sz;
+   }
+
+   /* Attribute other categories to only the current region. */
+   mr = obj->mm.region;
+   if (mr)
+   id = mr->id;
+   else
+   id = INTEL_REGION_SMEM;
+
+   if (!i915_gem_object_has_pages(obj))
+   return;
+
+   stats[id].resident += sz;
+
+   if (!dma_resv_test_signaled(obj->base.resv, dma_resv_usage_rw(true)))
+   stats[id].active += sz;
+   else if (i915_gem_object_is_shrinkable(obj) &&
+   obj->mm.madv == I915_MADV_DONTNEED)
+   stats[id].purgeable += sz;
+}
+
+void
+i915_query_fdinfo_memory_stats(struct drm_file *file,
+  struct drm_fdinfo_memory_stat *stats)
+{
+   struct drm_i915_file_private *file_priv = file->driver_priv;
+   struct i915_drm_client *client = file_priv->client;
+   struct drm_gem_object *drm_obj;
+   struct i915_gem_context *ctx;
+   int id;
+
+   /*
+* FIXME - we can do this better and in fewer passes if we are to start
+* exporting proper memory stats.
+*/
+
+   /* User created objects */
+   spin_lock(>table_lock);
+   idr_for_each_entry(>object_idr, drm_obj, id)
+   add_obj(to_intel_bo(drm_obj), stats);
+   spin_unlock(>table_lock);
+
+   /* Contexts, rings, timelines, page tables, ... */
+   rcu_read_lock();
+   list_for_each_entry_rcu(ctx, >ctx_list, client_link) {
+   struct i915_gem_engines_iter it;
+   struct intel_context *ce;
+
+   for_each_gem_engine(ce, rcu_dereference(ctx->engines), it) {
+   /* FIXME races?! */
+   if (ce->state)
+   add_obj(ce->state->obj, stats);
+   if (ce->timeline && ce->timeline->hwsp_ggtt)
+   add_obj(ce->timeline->hwsp_ggtt->obj, stats);
+   if (ce->ring && ce->ring->vma)
+   add_obj(ce->ring->vma->obj, stats);
+   }

[RFC 2/6] drm/i915: Use the fdinfo helper

2023-04-17 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Use the common fdinfo helper for printing the basics. Remove now unused
client id allocation code.

Signed-off-by: Tvrtko Ursulin 
Cc: Rob Clark 
---
 drivers/gpu/drm/i915/i915_driver.c |  6 +--
 drivers/gpu/drm/i915/i915_drm_client.c | 65 --
 drivers/gpu/drm/i915/i915_drm_client.h | 22 ++---
 drivers/gpu/drm/i915/i915_drv.h|  2 -
 drivers/gpu/drm/i915/i915_gem.c|  6 +--
 5 files changed, 18 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index a52db8a80900..6493548c69bf 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -244,8 +244,6 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
if (ret < 0)
goto err_rootgt;
 
-   i915_drm_clients_init(_priv->clients, dev_priv);
-
i915_gem_init_early(dev_priv);
 
/* This must be called before any calls to HAS_PCH_* */
@@ -279,7 +277,6 @@ static void i915_driver_late_release(struct 
drm_i915_private *dev_priv)
intel_power_domains_cleanup(dev_priv);
i915_gem_cleanup_early(dev_priv);
intel_gt_driver_late_release_all(dev_priv);
-   i915_drm_clients_fini(_priv->clients);
intel_region_ttm_device_fini(dev_priv);
vlv_suspend_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
@@ -1700,7 +1697,7 @@ static const struct file_operations i915_driver_fops = {
.compat_ioctl = i915_ioc32_compat_ioctl,
.llseek = noop_llseek,
 #ifdef CONFIG_PROC_FS
-   .show_fdinfo = i915_drm_client_fdinfo,
+   .show_fdinfo = drm_show_fdinfo,
 #endif
 };
 
@@ -1800,6 +1797,7 @@ static const struct drm_driver i915_drm_driver = {
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
+   .show_fdinfo = i915_drm_client_fdinfo,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index e8fa172ebe5e..c654984189f7 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -17,64 +17,29 @@
 #include "i915_gem.h"
 #include "i915_utils.h"
 
-void i915_drm_clients_init(struct i915_drm_clients *clients,
-  struct drm_i915_private *i915)
-{
-   clients->i915 = i915;
-   clients->next_id = 0;
-
-   xa_init_flags(>xarray, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ);
-}
-
-struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients)
+struct i915_drm_client *i915_drm_client_alloc(void)
 {
struct i915_drm_client *client;
-   struct xarray *xa = >xarray;
-   int ret;
 
client = kzalloc(sizeof(*client), GFP_KERNEL);
if (!client)
-   return ERR_PTR(-ENOMEM);
-
-   xa_lock_irq(xa);
-   ret = __xa_alloc_cyclic(xa, >id, client, xa_limit_32b,
-   >next_id, GFP_KERNEL);
-   xa_unlock_irq(xa);
-   if (ret < 0)
-   goto err;
+   return NULL;
 
kref_init(>kref);
spin_lock_init(>ctx_lock);
INIT_LIST_HEAD(>ctx_list);
-   client->clients = clients;
 
return client;
-
-err:
-   kfree(client);
-
-   return ERR_PTR(ret);
 }
 
 void __i915_drm_client_free(struct kref *kref)
 {
struct i915_drm_client *client =
container_of(kref, typeof(*client), kref);
-   struct xarray *xa = >clients->xarray;
-   unsigned long flags;
 
-   xa_lock_irqsave(xa, flags);
-   __xa_erase(xa, client->id);
-   xa_unlock_irqrestore(xa, flags);
kfree(client);
 }
 
-void i915_drm_clients_fini(struct i915_drm_clients *clients)
-{
-   GEM_BUG_ON(!xa_empty(>xarray));
-   xa_destroy(>xarray);
-}
-
 #ifdef CONFIG_PROC_FS
 static const char * const uabi_class_names[] = {
[I915_ENGINE_CLASS_RENDER] = "render",
@@ -101,38 +66,34 @@ static u64 busy_add(struct i915_gem_context *ctx, unsigned 
int class)
 }
 
 static void
-show_client_class(struct seq_file *m,
+show_client_class(struct drm_printer *p,
+ struct drm_i915_private *i915,
  struct i915_drm_client *client,
  unsigned int class)
 {
-   const struct list_head *list = >ctx_list;
+   const unsigned int capacity = i915->engine_uabi_class_count[class];
u64 total = atomic64_read(>past_runtime[class]);
-   const unsigned int capacity =
-   client->clients->i915->engine_uabi_class_count[class];
struct i915_gem_context *ctx;
 
rcu_read_lock();
-   list_for_each_entry_rcu(ctx, list, client_link)
+   list_for_each_entry_rcu(ctx, >ctx_list, client_link)
total += busy_add(ctx, class);
rcu_read_unlock();
 
if (capacity)
-   

  1   2   3   >